Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Back to the Advanced Port stuff again

 [1/18] from: ptretter::primary::net at: 10-Jan-2001 11:56


Ok. I still see a problem in trying to access the 'word. I'm back to you guru's. I have written a little code to provide an example: -------------------------------------------------------------- name: "Paul" waitports: [] name: make set-word! :name myport: [ scheme: 'tcp host: "irc.mcs.net" port-id: 6667 ] my-open-port: open/lines/no-wait myport mold name :my-open-port append waitports get make word! :name ------------------------------------------------------------------------- Now if I do:
>> found? find waitports paul
== true Not a problem since I know to look for "paul". But what if I didnt know that Paul was assigned to name and that this was done dynamically during program execution. How what I probe the port to get this information. Paul Tretter

 [2/18] from: al:bri:xtra at: 11-Jan-2001 7:31


> Not a problem since I know to look for "paul". But what if I didnt know
that Paul was assigned to name and that this was done dynamically during program execution. How what I probe the port to get this information. The general solution is to put your words in a special block just for this purpose. Something like:
>> name: "Paul"
== "Paul"
>> name: to word! name
== Paul
>> WaitPorts: make block! 0
== []
>> myport: open %test.txt >> set name myport
Caution: The above line really needs to be done in it's own context, not in Rebol's context. Consider: Name: "print" ... But I have to go to work now. Any one?
>> probe paul
make object! [ scheme: 'file host: none (escape)
>> append waitports 'Paul
== [Paul]
>> aport: first waitports
== Paul
>> probe get aport
make object! [ scheme: 'file (escape)
>>
I hope that helps! Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [3/18] from: al:bri:xtra at: 11-Jan-2001 15:30


> I actually tried what your referring to and got the same result. There is
no way to find the word bound to the port yet its binding to the port does in fact exist. Simply iterate over the block and find the word that equals the port in question. foreach port waitports [ if port = ThePortInQuestion [print :port] ] That should enable you to get the word in question. Probably better is to discard this approach entirely and merely use the following: WaitPorts: reduce [ "Paul" open %test.txt "User" open %blah.txt "YourNickNamehere" open YourPorthere ] I hope that helps! Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [4/18] from: ptretter:primary at: 10-Jan-2001 22:18


Lets forget about alternative methods for doing this another way for a moment and explain where I can find the word that is bound to the port object given only the object. This is really what I seek to know. Paul Tretter

 [5/18] from: ptretter:primary at: 10-Jan-2001 22:16


Andrew, Maybe you miss my point Andrew. What if you dont know its "paul" or know at all. In other words your at the discretion of the script working in a block of ports assigned dynamically. Paul Tretter

 [6/18] from: rebol:techscribe at: 10-Jan-2001 22:35


Hi Paul, you wrote:
> Lets forget about alternative methods for doing this another way for a > moment and explain where I can find the word that is bound to the port > object given only the object. This is really what I seek to know.
you apparently are not understanding what you are saying. You say "the word that is bound to the port object"! Who is bound to whom? The word is bound. To whom? To the port-object! The port-object is NOT bound to the word! You cannot make a reverse lookup from object to word, because "the port-object is not bound to the word" means that the object does not know that there is a word, that the word is paul, and that paul is bound to the object! Again, paul is bound to the object, the object is NOT bound to paul, it is a one-way relationship, where the word "knows" what it's bound to - that's what a word is there for anyway - but the value - here an object - does not have the faintest idea that it is bound to anything, nor must it be bound to anything (you can have a value that is not bound to anything. Unfortunately the garbage collector will pick it up quite soon ...) If your design is based around the assumption that you want to associate some kind of name value, paul, or gordon, or whatever, with an object programmatically, by turning the name - ie paul - into a set-word! value programmatically - make set-word! :name - and then associating it with the port object, or whatever value, - name: "Paul" new-port: make set-word! :name new-port make port! port-object then you have a DESIGN BUG! Your idea was that by associating the set-word! (here Paul:) with the port-object! you would be able to follow this association backwards, from the port back to the set-word!, here Paul:. You cannot! It's a one-way street. paul -> port-object. Period. Now backwards following Got it? Now, can we talk about alternative methods? Hope this helps, Elan

 [7/18] from: al:bri:xtra at: 11-Jan-2001 19:47


Paul Tretter wrote:
> Lets forget about alternative methods for doing this another way for a
moment and explain where I can find the word that is bound to the port object given only the object. This is really what I seek to know.
> Maybe you miss my point Andrew. What if you dont know its "paul" or know
at all. In other words your at the discretion of the script working in a block of ports assigned dynamically. Here's something simple to illustrate:
>> o1: make object! [m: "Object one!"] >> o2: make object! [m: "Object two!"] >> One: o1 >> Two: o2 >> o1 >> probe o1
make object! [ m: "Object one!" ]
>> probe One
make object! [ m: "Object one!" ] Both 'o1 and 'One refer to: make object! [m: "Object one!"]. Both 'o2 and 'Two refer to: make object! [m: "Object two!"]. Now given the object containing [m: "Object one!"], can I find out what word(s) are refering to it? No, not _directly_. But if one is busy assigning words to objects, one should also store them so they can't "get away". For example:
>> B: make block! 0
== []
>> append B 'One
== [One]
>> append B 'Two
== [One Two]
>> B0: reduce copy B
== [ make object! [ m: "Object one!" ] make object! [ m: "Object two!" ]]
>> b0
== [ make object! [ m: "Object one!" ] make object! [ m: "Object two!" ]]
>> b
== [One Two] In 'b are the words and 'b0 are the objects. Unless you shuffle or sort the blocks, B/1 and B2 still refer to their objects:
>> probe get b/1
make object! [ m: "Object one!" ]
>> probe get b/2
make object! [ m: "Object two!" ] If you still have problems, please let us know. I hope that helps! Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [8/18] from: al:bri:xtra at: 11-Jan-2001 19:50


Paul -> Object That's all. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [9/18] from: ptretter:primary at: 11-Jan-2001 7:34


I understand what your saying about the words. I was on IRC last night chatting about this topic and will most likely end up setting up the ports objects to contain a reference to the username to make functional a portion of my script. I have been enlightened greatly in this topic though. interesting enough is that when we did a print first waitports we returned 'irc-open-port. When we stepped through the waitports block to the next position and did a probe next first waitports we did not return the word which we believe was because the script was reducing before appending the port object to the block at some point. Paul Tretter

 [10/18] from: ptretter:primary at: 10-Jan-2001 14:12


Andrew, I actually tried what your referring to and got the same result. There is no way to find the word bound to the port yet its binding to the port does in fact exist. Any REBOL staffers want a crack at this one. Paul Tretter

 [11/18] from: rebol:techscribe at: 11-Jan-2001 9:31


Hi Paul, you wrote:
> interesting enough is that when we did a print first waitports we returned > 'irc-open-port. When we stepped through the waitports block to the next > position and did a probe next first waitports we did not return the word > which we believe was because the script was reducing before appending the > port object to the block at some point.
That behavior is indeed very interesting. Do you happen to still have the code segment that exhibited this behavior? What I would be interested in is the line in which irc-opent-port is added to waitports, the lines in which other port objects are added to the port, and the line in which the waitports block is probed, first with "firts", and then with next. TIA, Elan

 [12/18] from: g:santilli:tiscalinet:it at: 11-Jan-2001 19:29


Hello Paul! On 11-Gen-01, you wrote: PT> Lets forget about alternative methods for doing this another PT> way for a moment and explain where I can find the word that PT> is bound to the port object given only the object. This is PT> really what I seek to know. I'd suggest you to change your approach; in a similar script I'm using a block of objects (users), each of them has a PORT word referring to its port; PORT/LOCALS is set to refer back to the user object, so that you can access the user from the port too (when you receive a message from the port). You could simply set PORT/LOCALS to the nick. Anyway, if you really want to know (one of) the word(s) that refer(s) to your port in the global context, you can do it this way: words: first system/words values: second system/words if pos: find values port [ print first at words index? pos ] Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [13/18] from: holger:rebol at: 11-Jan-2001 12:30


On Thu, Jan 11, 2001 at 07:29:59PM +0200, Gabriele Santilli wrote:
> I'd suggest you to change your approach; in a similar script I'm > using a block of objects (users), each of them has a PORT word > referring to its port; PORT/LOCALS is set to refer back to the > user object, so that you can access the user from the port too > (when you receive a message from the port).
Please don't use port/locals for that. port/locals is used internally by many protocols (http, ftp etc.), and will be used by even more protocols (including plain TCP in async mode) in the future. The appropriate place for user references in ports is port/user-data. All current experimental builds should have this field in ports. -- Holger Kruse [holger--rebol--com]

 [14/18] from: ptretter:primary at: 11-Jan-2001 17:15


This is the method we determined was most appropriate to use the user-data path to make the irc bot script work. Paul Tretter

 [15/18] from: ptretter:primary at: 11-Jan-2001 17:23


Actually, the waitports is defined as an empty block at the begining of the script: waitports: [] then later... waitports: [irc-open-port] I only do the probing when I excape from the programs execution on the waitports block. I usually do that while waitports contains the appended dcc ports. Im not to worried about the ports as I have the user-data path within the port object. I also downloaded the internet draft for MSN Messenger Protocol version 1.0 today and hope to add that to my irc bot so that it can relay internet messages within the bot to someones MSN account. I should run into a whole batch of new questions for everyone. Move over eggdrop....soon a better alternative will be here.

 [16/18] from: rebol:techscribe at: 11-Jan-2001 22:30


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

 [17/18] from: ptretter:primary at: 12-Jan-2001 10:06


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

 [18/18] from: g:santilli:tiscalinet:it at: 12-Jan-2001 18:47


Hello Holger! On 11-Gen-01, you wrote: HK> Please don't use port/locals for that. port/locals is used HK> internally by many protocols (http, ftp etc.), and will be HK> used by even more protocols (including plain TCP in async HK> mode) in the future. Whoops, now that you make me think of it... protocols have the TCP port in port/sub-port, so there's nothing to stop REBOL from using it... I'll have to fix Chat to use USER-DATA (didn't notice that, thanks!). Very very sorry, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/