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.
--
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
[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