Elan you understood perfectly. And yes waitports: [] was a container for
appending and removing ports. Your help was perfect. Thanks for taking the
time to understand this. I hope you join us on EFNET #rebolgod sometime to
help us with other code problem or just to participate. I will be sending
you the full script to date if you would like to try it out and see what we
have been talking about.
Paul Tretter
----- Original Message -----
From: "Elan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 12, 2001 12:30 AM
Subject: [REBOL] Re: Back to the Advanced Port stuff again
> Hi Paul,
>
> To make this a little more interesting for you, I've included code that
> shows you how you can add the words associated with the ports to the
> block, instead of adding the ports themself, so that all ports will be
> contained in wait-ports like your irc-open-port. I understand that is
> what was troubling you?
>
> you wrote:
> >
> > Actually, the waitports is defined as an empty block at the begining of
the
> > script:
> >
> > waitports: []
> > then later...
> > waitports: [irc-open-port]
>
> Do you use the first definition (waitports: []) for any purpose before
> it is defined as waitports: [irc-open-port]? If not, note that the first
> definition does not accomplish anything.
>
> I assume that at a later point in time you add ports to wait-ports using
> the insert or the append function.
>
> 1. waitports: []
> What happens here is that you are associating the word waitports with an
> empty literal block. If you want you can now begin to insert or append
> stuff to the block, (or remove and search for appended stuff) and so on.
> This literal block will survive as long as the word waitports (or a
> different word) are associated with it, or if it is referenced from
> within a function, an object, or a block, as long as that function,
> block ... is being referenced by a word (chain of references), or itself
> is referenced in a block ... which in turn is referenced by a word. As
> soon as all "live" references to the literal block are consumed by the
> garbage collector (unset 'waitports, for instance) the literal block
> will be garbage collected.
>
> 2. waitports: [irc-open-port]
> a) Now the empty literal block in 1 is no longer bound by waitports, and
> it will be garbage-collected (unless there was a previous step in which
> the block became associated with some other live value, such as a
> difference word, or "live" block ...). The literal block that you just
> abandoned will be garbage- collected and with it all its contents, with
> exception of stuff that additionally associated with (or bound to) some
> other surviving value ...)
>
> b) waitports is now assigned to a block that contains a word. Note that
> nothing happens with the word irc-open-port in the block. Most notably
> it is not automatically replaced by its value. Therefore, if you probe
> the block, the word irc-open-port will be reported as the contents of
> the block and not the value that irc-open-port is bound to.
> If you subsequently add other ports to the block using insert or append,
> the values (and not the words) will be added. A simple example:
>
> >> a: 1 ;- Step 1
> >> b: 2 ;- Step 2
> >> c: [a] ;- Step 3
> >> append c b ;- Step 4
>
> The block in step 3 "protects" the word a that it contains. The word is
> not replaced by its value, and the block assigned to c contains the word
> a. Note that a does not even have to have been associated with a value.
> x: [y] will work, even if y was not previously associated with any
> value.
>
> What happens in step 4? The function append is evaluated. This function
> expects two arguments, a series type, and some other value. REBOL looks
> at the input stream and designates the two tokens following append as
> appends arguments. REBOL determins that c is a block, it replaces the
> word c by its value, namely the block, and determines that the block c
> fulfills append's requirement for a series type value as its first
> argument. REBOL needs a second argument for append, and finds the word
> b. This word (like c) is replaced by its value (namely 2) and the
> integer 2 is passed to append as its second argument. The resulting
> block c is
> >> c
> == [a 2]
>
> The a that was already "packaged" in the block was never evaluated, and
> therefore it continues to exist as an unevaluated word. The word b never
> reached the block, because it was replaced by its value, 2, before it
> was passed to append which inserted 2 (and not b) in the tail of block
> c. Therefore the value associated with b, namely 2, is the second
> element of the block c.
>
> The same thing is probably happening in your case. When you associate
> waitports with the block [irc-open-port] the word irc-open-port is not
> evaluated, i.e., it is not replaced by its value, and therefore it the
> first element of the block. I think it's understood by now.
>
> So, what do you do in order to have a block waitports which uniformly
> contains either ports, or words that evaluate to ports?
>
> 1. ... uniformly contains ports:
> >> waitports: []
> >> insert waitports irc-open-port
> In this example irc-open-port is evaluated and its value (the
> port-object) will be inserted, not the word itself.
> Another option:
> >> waitports: reduce [irc-open-port]
> The reduce function returns a block in which the word irc-open-port has
> been replaced by its value.
>
> 2. ... uniformly contains WORDS that evaluate to port objects:
> >> waitports: [irc-open-port]
> Ok, we know by now that the block protects the word irc-open-port, it is
> not evaluated, and therefore the block associated with waitports is
> currently
> >> waitports
> == [irc-open-port]
>
> How about the other ports? Simple. Assuming that you are using the
> string "Paul" which identifies the user Paul as set-word! that will be
> associated with a port:
>
> >> user: "Paul"
> >> word: to set-word! join user "s-open-port"
> == Pauls-open-port:
> >> word make port-object! [ .... ]
>
> >> append waitports to word! :word
> == []
>
> >> probe waitports
> == [irc-open-port Pauls-open-port]
>
> Great, now how do you get the port associated with Pauls-open-port?
> There are different ways:
>
> >> second reduce wait-orts
> >> get second waitports ;- less compute-intensive if you have a lot of
ports
> >> get waitports/2
> >> first find wait-ports 'Pauls-open-port ;- will return the word
Pauls-open-port
> == Pauls-open-port
> >> get first find wait-ports 'Pauls-open-port ;- will get the port
associated with Pauls-open-port
>
> But if you don't know that its "Paul" s-open-port? Here:
>
> >> get first find wait-ports to word! join user "s-open-port"
>
> Hope this helps,
>
> Elan
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
>
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
