Building scripts

[1/15] from: brett::codeconscious::com at: 16-Jan-2002 22:34

Currently for my various rebsite scripts I use load-thru as a way of re-using code. Sometimes I think it would be nice to have all functions contained within a single script, but obviously maintenance would be a pain. Rugby's build idea attracted me. It might be nice to have a library of code snippets which can be assembled/generated into scripts on demand. Ie reuse of code via direct inclusion. One advantage over my current re-use technique would be that the scripts would only instantiate what was required to make them run rather than, as is now, potentially creating functions, etc that are never evaluated. Directly including code is not for every system, but for many situations has very useful properties. Given that Rebol scripts are destined to fly over the net such a system would be quite useful. Brett.

[2/15] from: ryanc:iesco-dms at: 16-Jan-2002 10:19

This would be a nice feature in a rebol editor, hmmm... --Ryan Brett Handley wrote:

> Currently for my various rebsite scripts I use load-thru as a way of > re-using code.

<<quoted lines omitted: 14>>

> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 The contradiction so puzzling to the ordinary way of thinking comes from the fact that we have to use language to communicate our inner experience which in its very nature transcends lingistics. -D.T. Suzuki

[3/15] from: chalz:earthlink at: 16-Jan-2002 13:27

I'm just making sure I get fully what you're asking. Essentially, something like Java's method of including libraries like import x.y.z for more 'refined' control of what's included? Only, instead of copying the extraneous code into the compiled result, do something more like (I'm not using totally proper REBOL, I know; demonstration purpose): math: link rdb://math.rlib ... ... result: math/tally arg1 arg2 Where 'rdb' refers to a site and port for a REBOL database, and 'rlib' refers to REBOL library, and accessing a specific function within the math.rlib could be used like accessing a member of a block. Of course, it would require the script be executed in a networked environment (you could re-define the REBOL library database with rdb://anothersite.com/inet.rlib) of some flavor - but most people executing REBOL already are. Is this what you mean? I asked Carl about this a while back, but it was kind of long - he might have skipped it, or taken me for someone who never looked at IOS ;) --Charles

[4/15] from: greggirwin:mindspring at: 16-Jan-2002 11:50

Hi Brett, << Directly including code is not for every system, but for many situations has very useful properties. Given that Rebol scripts are destined to fly over the net such a system would be quite useful. >> One of the most exciting things to me, about REBOL, is imagining the tools that are going to grow up around it to facilitate the construction of substantial systems. There are bound to be uses for a "package compiler" that does what you suggest (and what some existing REBOL tools do to at least some extent) but I can see many other possibilities as well for systems that are dynamic and extensible. Imagine a system that has everything extraneous stripped out of it but maintains stubs so that, in the event of failure, debugging support could be dynamically loaded. --Gregg

[5/15] from: ryanc:iesco-dms at: 16-Jan-2002 13:34

While not quite what your getting at, you might check out http://www.reboltech.com/library/scripts/build-pack.r --Ryan Gregg Irwin wrote:

> Hi Brett, > << Directly including code is not for every system, but for many situations

<<quoted lines omitted: 14>>

> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.

[6/15] from: brett:codeconscious at: 17-Jan-2002 7:59

Hi Charles,

> Is this what you mean?

Yes and no. I like the idea of the library being a db listening on a port. But it should be only one of the possibilities. It might be just a script of functions - like a member of a block. Though the library structure could be hiearchical too if that is a better organisation of reusable things. So there is an addressing issue - how does one refer to the thing wanted. Then there is the execution model - when is the code included. I'd like to be able to build a script - the result being a script with no library references. I might do that when I'm rebuilding my website/rebsite for lots of scripts or I might want to do it on demand in response to a CGI request for the script with some parameterisation. Other possibilities abound. In summary, I guess my interest is in: (a) how to address reusable code snippets (b) how to compose the new script from reusable snippets and the specifics of the script wanted. (c) being able to do so for a variety of situations - code is data after all. Regards, Brett.

[7/15] from: rotenca:telvia:it at: 17-Jan-2002 16:36

Hi Brett,

> In summary, I guess my interest is in: > (a) how to address reusable code snippets > (b) how to compose the new script from reusable snippets and the specifics > of the script wanted. > (c) being able to do so for a variety of situations - code is data after > all.

I find interesting your proposal. But we should design specifics of import/export/store before trying something. An example of basic design: we could use normal scripts in a specific dir. The library program find in them the global words used, and then when you ask for a given function it do all the script in which the given global word is defined: import librarydir db-select will do the file librarydir/dbms.r --- Ciao Romano

[8/15] from: chalz::earthlink::net at: 17-Jan-2002 23:49

Re: Including Script Libs (was: Building scripts)

> Hi Charles,

Yo Brett.

> > Is this what you mean? > > Yes and no.

Heh. It was an idea which came to me late one night while reading over some REBOL. Kind of one of those "Why don't they do <this> like <that>?"

> Then there is the execution model - when is the code included. I'd like to > be able to build a script - the result being a script with no library > references. I might do that when I'm rebuilding my website/rebsite for

lots

> of scripts or I might want to do it on demand in response to a CGI request > for the script with some parameterisation. Other possibilities abound.

Sounds like something... hm.. someone mentioned earlier something to be used in a REBOL editor - when saving the script, you could have it include any referenced functions, or simply have it 'paste in' functions that you need at the head of the script. Heh, like an included: [] block of functions.

> In summary, I guess my interest is in: > (a) how to address reusable code snippets

That is certainly an issue. Would the target remote library (for instance) be a normal REBOL script, or a collection of REBOL functions with/out the REBOL [] header? So many options..

> (b) how to compose the new script from reusable snippets and the specifics > of the script wanted. > (c) being able to do so for a variety of situations - code is data after > all.

A rather large deal if you want any flexibility. Certainly beyond my (current) skills.. --Charles

[9/15] from: zokie:libero:it at: 19-Jan-2002 15:07

Re: Building scripts

Hello Brett On 16-Gen-02, Brett Handley wrote:

> Sometimes I think it would be nice to have all functions contained within > a single script, but obviously maintenance would be a pain. Rugby's build

To spread my scripts as stand-alone script I had thought: 1) make a self-installing script 2) join manualy all used scripts in to one. 3) make a rebol-script to do the dirty job for me Becouse my scope is to realize as soon as possible the third of above options, I had designed all my script to be easily included. After Reabol's header are present command like: do %path/to/script01.r do %path/to/script02.r .... do %path/to/script0n.r All included scripts are only declaration & definition of functions. Functions will be used by code into the main script, which contain specific functions and special function called as the script, which embeddes all the main-code, and the last code line of the script launch main-function with arguments if needed. Doing so it is easy to do cut'n'paste with a text-editor, but will be even simple to make a script which collect all external script used by current script and the make all substitution, using recursion it is possible resolve deep inclution like script05.r includes script03., which includes... We could split in 2 phases all the job. The first joins all scripts, the second strips all unused functions from the stand-alone script.

> via direct inclusion. One advantage over my current re-use technique would > be that the scripts would only instantiate what was required to make them > run rather than, as is now, potentially creating functions, etc that are > never evaluated.

I had begin to collect all my funtion, grouping them in to specific libraries, so I have a directory called zTools which is contains these re-usable scripts. Now there are few script ready, but more will come: string-Tools.r internet-Tools.r block-Tools.r I include them (do %/rebol/zTools/....) every time I need a function yet developed & debugged :) now all this is only an idea, but if you like we can develope it. Regards -- "Where did you get all those facts!?!"

[10/15] from: brett:codeconscious at: 20-Jan-2002 12:34

> Becouse my scope is to realize as soon as possible the third of above > options, I had designed all my script to be easily included. After

Reabol's

> header are present command like: > do %path/to/script01.r

<<quoted lines omitted: 6>>

> embeddes all the main-code, and the last code line of the script launch > main-function with arguments if needed.

I have done something similar too. Though I use the word "use-script" instead of "do". This way I can redefine use-script according to the context the script is running in.

> Doing so it is easy to do cut'n'paste with a text-editor, but will be even > simple to make a script which collect all external script used by current > script and the make all substitution, using recursion it is possible > resolve deep inclution like script05.r includes script03., which > includes...

That's an interesting idea. I could already use "use-script" as my marker for script replacement. Another interesting idea is that in the same replacement fashion, use-script could create a function definition that makes a Rugby call. Romano had this idea: import librarydir db-select ; will do the file librarydir/dbms.r In this example import provides a naming service - it searches the library for the function. Plus it runs the file. I'm also unsure how the mooted rebol modules functionality will impact on this. So some interesting ideas: Where does your function definition live? [ in a block, in a script, in rugby ] How do you find it? [Using a naming service, a consistent directory structure, etc.] Brett.

[11/15] from: rotenca:telvia:it at: 20-Jan-2002 17:22

Hi Brett

> So some interesting ideas: > > Where does your function definition live? [ in a block, in a script, in > rugby ] > How do you find it? [Using a naming service, a consistent directory > structure, etc.]

Perhaps we could put in the header block of the file: Export: [["func1" 1.0.0] ["func2" 2.0.0] ["func2" 0.0.1]] The export block could be expanded to keep other things (comment...). A library parser could read the header of every file in the dir to find func name / func version and if match, to do all the script. import librarydir "func1" 0.0.0 The script could contain another import statement. Import shoul trace scripts to not do the same script twice and discover circular inclusions. --- Ciao Romano

[12/15] from: zokie:libero:it at: 21-Jan-2002 13:38

Hello Brett On 20-Gen-02, Brett Handley wrote:

> I have done something similar too. Though I use the word "use-script" > instead of "do". This way I can redefine use-script > according to the context the script is running in.

Yes! I start with idea to write a command "smat-include", which is a complex form of DO: to check, when online, if the script was changed then download newest release.

> That's an interesting idea. I could already use "use-script" as my marker > for script replacement.

Yes, we can define all marker we need :)

> Another interesting idea is that in the same replacement fashion, > use-script could create a function definition that makes a Rugby call.

I'm sorry, but the only thing that I know about Rugby is that exists :)

> Where does your function definition live? [ in a block, in a script, > in rugby ]

You must consider that I'm a newbie to Rebol's programming, my works are too candind, so function definitions are alive in work session. I attach a stripped script of mine: REBOL [Title: "internet-Tools.r"] do %string-Tools.r net-db: [ [id "windows" job "gateway"] [id "a1200t" job "connected"] ] gateway?: func [machine] [...] get-ip: does [...] online?: does [...] cgi-decoder: func [args [any-string!] "Starts at first argument word" /local list equate value name val plus-to-space] [...] get-next-email-name: func [gnen-path [file!]] [...] prepare-simple-email: func [pse-recipients [block! email!] pse-subject [string!] pse-body [string!] pse-path [file!]] [...] submit-emails: func [se-path [file!] se-org [string!] se-reply [string! email!]] [...] check-mailbox: func [user [string!] pass [string!] server [url! string!]] [...] catch-emails: func [user [string!] pass [string!] server [url! string!] ce-path [file!]] [...] old-catch-emails: func [user [string!] pass [string!] server [url! string!] ce-path [file!]] [...] get-return-path: func [grp-data [string! block!]] [...] get-net: does [...]

> How do you find it? [Using a naming service, a consistent directory > structure, etc.]

Pheraps, the best way should be scan files and collect everything before: func, does, function, ...; re-scan full assembled script and mark all un-used functions and then strip off them. Regards -- "Where did you get all those facts!?!"

[13/15] from: zokie:libero:it at: 21-Jan-2002 14:02

Hello Romano On 20-Gen-02, Romano Paolo Tenca wrote:

> Perhaps we could put in the header block of the file: > > Export: [["func1" 1.0.0] ["func2" 2.0.0] ["func2" 0.0.1]]

Yes, this may simplify dirty jobs, but including by hand all declared functions in the header is a tedious job. Please read even my other mail: the "builder" script should collect all declared functions into code by parsing it, so it is secure that no typing error or authors's forgetfullness will rise bugges :)

> Import shoul trace scripts to not do the same script twice and discover > circular inclusions.

This is easy to achieve, "builder" script collects (before to start real reforming process) included script name and appends into a block like this one: a: [%/a/first.r %/b/second.r %/a/first.r] by using sort command, it becomes: [%/a/first.r %/a/first.r %/b/second.r] Now with a simple foreach-cycle, "builder" discards every double file recall. Isn't it easy? :) Regards -- "Where did you get all those facts!?!"

[14/15] from: rotenca:telvia:it at: 22-Jan-2002 20:13

Ciao Francesco,

> > Perhaps we could put in the header block of the file: > > > > Export: [["func1" 1.0.0] ["func2" 2.0.0] ["func2" 0.0.1]] > > Yes, this may simplify dirty jobs, but including by hand all declared > functions in the header is a tedious job.

Was my first idea but i saw that someone wanted to make some check about version and something else.

> Please read even my other mail: the "builder" script should collect all > declared functions into code by parsing it, so it is secure that no typing > error or authors's forgetfullness will rise bugges :)

It is the direct solution, but code must be written like a simple collection of functions. If you embed functions in objects and set them with the 'set instruction: rebol[] contex [ set 'myfunc does [none] ] the parser must do an hard work to understand the code and find the 'myfunc definition.

> by using sort command, it becomes: > > [%/a/first.r %/a/first.r %/b/second.r] > > Now with a simple foreach-cycle, "builder" discards every double file > recall. > > Isn't it easy? :)

Yes, with 'unique also more. But to collect the files name you must do the files to execute the new import func, so we can't collect all the inclusions before do-ing the scripts. --- Ciao Romano

[15/15] from: nitsch-lists:netcologne at: 22-Jan-2002 22:00

RE: [REBOL] Building scripts iam working on this too some times ;-) my best solution is: 1) copy all scripts locally. keep the url and the original source and look for a good diff. (is windiff now somewhere deep on the cd?). keep three dirs, modified, used original, newest-original, so you can see what changes and addapt it. newest-original can be updated by rebol then automatic. quick: insert-downloader copy-url click-right desktop-icon ;-) 2) let the script do the building work. at the beginning of script do/args %my-build-pack.r [do file] ;based on carls %build-pack.r /embed[your source here] %my-build-pack .r has a list of all sub-scripts and builds the target, then does its debug-argument. so you dont test different version (for example in/out-script-images). use some marker like /embed . in carls script instead of his loading for example: something like <- script: load/all file -> script: compose [ REBOL (reduce [script/2] ) (select script /embed) ] then at %build-pack.r end do system/script/args so you can give some test-code for after building. with simple do its 'none, so build only ;-) http://www.reboltech.com/library/scripts/build-pack.r and http://jove.prohosting.com/~screbol/reb/build-pack-i.r that also has a little "follow 'needs" code inside. but thats currently style-r. my monitor grows to 17 with it.. -Volker [brett--codeconscious--com] wrote:

Notes

Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted