why not simply assign the port-id to an arbitrary variable and walkthru the
port array ?

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 08 January 2001 13:56
To: [EMAIL PROTECTED]
Subject: [REBOL] Re: Advanced port stuff



You might try checking out multisession.r on REBOL.org. I THINK it does
this (associating literal words to port objects in a 'waitports list)...

If not, what you might have to do is either do a 'find within the list of
'waitports, or keep a synchronized list (block) of literal words to match
the  'waitports list.

BTW to want this task does not imply that you have badly designed code IMO
- or even that a simpler solution exists. I do the same 'waitports list
scheme in my MUD and given the complexity of the desired task I see no way
around it.

Actually, what I do in the MUD (and I mention this because you may want to
do this also) is associate each 'port object in 'waitports with a  client
object (ie a "player" in my MUD). It would be nice if the 'port objects
could point to (ie reference) the associated client object, but alas it
doesn't and I haven't been brave enough to overuse one of the 'port
elements to do this (don't even know if I COULD). SO, I create a reference
to the associated 'port object from the client object when the port is
created. Then I perform an "ugly" loop through the client list to find the
matching client for a given 'port.

- Michael Jelinek





"Paul Tretter" <[EMAIL PROTECTED]>@rebol.com on 01/05/2001 08:53:46 AM

From: "Paul Tretter" <[EMAIL PROTECTED]>@rebol.com on 01/05/2001 08:53
      AM

Please respond to [EMAIL PROTECTED]

Sent by:  [EMAIL PROTECTED]

To:   <[EMAIL PROTECTED]>
cc:
Subject:  [REBOL] Re: Advanced port stuff


Ok, so far the answers relating to objects I have all ready known but
appreciate your input.  I think the complexity is that these objects are
port objects that have been added to a block. The block is referenced by
the
word 'waitports.  waitports contains the port objects which are appended to
it dynamically as the script runs.  For example if waitports contained
three
port objects - then the following:
>> print waitports
?port? ?port? ?port?

ok print now this:
>> print first waitports
irc-open-port

now I try moving the index to get the literal of the second port since the
first port responded correctly:
waitports: next waitports

>> print first waitports
?port?

I notice that it shows only one ?port? instead of two and it didnt give me
the literal word referencing that port object.  Is this a bug or is there
new information we need to document regarding objects appended to blocks
when they are port datatypes.

As you can see this script deals with IRC.  The first port in the block is
the port object for the irc server itself.  The next port and subsequent
ports are for dcc ports that are dynamically added to the block while the
script is online and active on irc.  These dcc ports objects are assigned
to
the nickname of the user on irc (since each user must have a unique
nickname
on the irc network).  This assignment was done with this function in my
script:

dcc-parser: does [
    if secured [
        if dcc-chat-flag [
            dcc-client: message/nick
            dcc-client-port: message/dataparse/5
            dcc-connect: [
                scheme: 'tcp
                host: dcc-ip
                port-id: to-integer dcc-client-port
            ]
            either error? error-dcc-open-client: try [dcc-open-client:
open/lines/direct/no-wait dcc-connect][
                error-dcc-open-client: disarm error-dcc-open-client
                error-proc error-dcc-open-client
            ][
                insert dcc-open-client read %help.txt
                dcctemp: :dcc-client
                dcctemp: make set-word! :dcctemp
                mold dcctemp :dcc-open-client
                append waitports get make word! copy :dcc-client
                dcc-chat-flag: off
                dcc-client-port: dcc-connect: none

            ]
        ]
    ]
]

message/nick above is the object containing the nickname of the user from
the ircparser function (not listed).  As you can see from the third line
from the bottom of the function the port is appended to waitports.  The
script does everything I want it to do.  However, I am getting ready to add
more code to this function to perform some logic based on the literals
within waitports block.  Thats is what Im having trouble determining since
its dynamically assigned during execution.  Hope this helps.

Paul Tretter




----- Original Message -----
From: "Andrew Martin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 05, 2001 2:28 AM
Subject: [REBOL] Re: Advanced port stuff


> Elan wrote:
> > 3. Your question bothers me. Why do you need to know which words
reference
> these objects? I suspect that there may be a conceptual bug involved in
your
> question. I.e. a more (REBOLlish) elegant = simpler solution may prevent
> this question from coming up altogether.
>
> I'd agree with this. It sounds like there's a design problem in the
script
> as the problem sounds confused.
>     Usually if you can write clearly what the problem is, the Rebol code
> becomes immediately apparent, as Rebol script "surfaces" in the
description
> of the problem. For example, in my earlier emails about the 'Fun
function,
> where Ladislav pointed out, IIRC, that 'fun needed to exclude
Arguments--the
> rebol script to solve the problem "surfaced" as:
>         Locals: exclude Locals Spec
>
> I hope that helps!
>
> Andrew Martin
> ICQ: 26227169 http://members.nbci.com/AndrewMartin/
> -><-
>
>
> --
> 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.






-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.



**********************************************************************
This email and any attachments may be confidential and the subject of 
legal professional privilege.  Any disclosure, use, storage or copying 
of this email without the consent of the sender is strictly prohibited.
Please notify the sender immediately if you are not the intended 
recipient and then delete the email from your inbox and do not 
disclose the contents to another person, use, copy or store the 
information in any medium. 
**********************************************************************
-- 
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the 
subject, without the quotes.

Reply via email to