This time to the right list!
At 02:49 PM 4/2/00 -0800, you wrote:
>How do I make a value global? That is, so that
>it can be "seen" by any code in a file, include
>user-define functions?
>
>I would also welcome advice as to the pro and cons
>of using globals, as well as when best to use
>them, and what under what circumstances where such
>usage would be a bad idea.
>
>thank in advance.
>tim
I was wondering about that too. Maybe if I reply to this we can get Allen,
Andrew, Gabriele, pekr, Robert, or Volker to give a definitive answer...
Just another newbie here, also trying to improve my style... So forgive me
if I'm covering the same ground you've been over... Mostly I'm just
thinking out loud about this topic, areas where I assume there is a more
accurate explanation I've marked with a (?) symbol...
If you define words after the Rebol[] block at the head of your script,
myscript.r
Rebol[]
my_global_1: [1 2 3 4]
my_global_2: "abcd"
and then
do %myscript.r
my_global_1 and my_global_2 will be added to system/words (?), and
available to all scripts that run afterwards in that Rebol window. They
will occupy space in memory until you close the Rebol window, regardless if
they are used frequently or used rarely.
As a programmer you have to keep track of them and their side effects. You
don't want to have to deal with more of them than you need to. Throughout
your entire program, you can have lots and lots of variables, but the
number of variables at any given moment should be low; the variables you
don't yet need shouldn't be loaded, and the variables you're finished with
should be freed from memory.
As Rebol reads through a script, when it encounters begin-block symbol (
"[" ) it sets aside a special place (?) for any variables that are
subsequently defined. When Rebol encounters the corresponding end-block
symbol ( "]" ) all the variables in that special place are freed(?). So, to
keep the number of variables low, you want to insure that variables are
defined as late as possible, and freed as early as possible. The way to do
this is to divide your script into blocks ( "func" blocks ), and do not
introduce variables until you reach the block you need them.
Get the user's guide available from
do http://www.rebol.com/users-guide.r
on the page expfunctions.html, there is a very short section on func
blocks, also read about scope.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
That raises another question. How do you make variables seen by other Rebol
windows?
Let's imagine that you're doing some very intense calculation (e.g.
creating a fractal image, calculating pi, removing noise from a sound file,
etc.) and you start your Rebol script on a machine that you know has some
kind of limitation (e.g. your account has a time limit, or the hard drive
has very little remaining space, or the operating system has low system
resources, etc.). You want to stop for now and continue later in a better
environment.
One way to do this might be to save all your variables to a file, email it
to the other machine (or machines, if you have more than one), and then
reload the variables later in that better environment, and then run your
script again.
What are some other alternative ways of running scripts across multiple
machines? An eventual goal might be a "Beowulf"-style massively parallel
multiple processing system held together by Rebol.
>
>At 01:19 PM 4/2/00 -0700, you wrote:
>>Hi t,
>>
>>A file! type is a filename with a leading % character. Example: %myfile.r
>>%/c/mydir/. A file! may be any type of file, including a directory.
>>
>>A port! datatype is a low-level i/o abstraction that REBOL uses to
>>serialize different types of i/o channels, such as files (here we are not
>>talking about the filename, but access to the file's contents), and socket
>>i/o.
>>
>>The access to ports is typically controlled by protocols that define how
>>information is read and written to a port, and also commonly implement some
>>convenient navigation functions for the port's datastream, such as first,
>>next, insert, pick, etc. These functions work in a sensible way on a port!
>>datatype. They enable you to treat ports as though they were series values
>>(i.e. blocks, paths, hashes ...) to a degree, hence the term serialize is
>>used to describe this type of access to i/o channels.
>>
>>There are some limitations, since not all ports lend themselves to being
>>treated as a series effectively with respect to all series! functions.
>>
>>I haven't been following this thread, so I don't know why you are using
>>ports. Generally speaking, it is often more convenient to use higher level
>>functions when dealing with files, then accessing them as ports. read,
>>write, read/lines, write/append write/lines, write/append/lines, save,
>>load, come to mind. All of these functions take a filename (type file!),
>>and do not require that you manage the file on the port level, for instance
>>with respect to positioning, etc.
>>
>>
>>Hope this helps.
>>
>>
>>
>>;- Elan >> [: - )]
>>
>>
>
>
