Hi Ingo,
Good one! I stand corrected, you don't need something evil to achieve it,
just another way of looking at it.
Your code fails on the fourth example though, because name has a value of
none. Just making a small change, it works
sub-rule: [
"<WON:" (print name) to end |
(
if next-part <> "" [if not name [name: copy ""]
append name join "<" next-part]
)
skip copy next-part to "<"
]
Brett
----- Original Message -----
From: "Ingo Hohmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 11:53 PM
Subject: [REBOL] Re: 'Parse is peculiar! - more details
> Hi Brett,
>
> here's my take, assuming that "<WON:" is sure not to be in the name-string
> (and it is the only thing you can be sure about ...
>
> line1: {Lets find "Ju<l>ie<1234><WON:90966776>"}
> main-rule: [ (next-part: "") thru {"} copy name to {<} some sub-rule to
end ]
> sub-rule: [ "<WON:" (print name) to end
> | (if next-part <> "" [append name join "<" next-part] ) skip
copy next-part to "<" ]
>
> >> parse line1 main-rule
> Ju<l>i<97868769>
>
> OK, what do I do?
>
> in main-rule first create an empty-string next-part (no copy needed, as
the
> string is not changed, the word gets assigned to new strings later on)
>
> Up to copy name it's the same as before, but then we go into the sub-rule.
>
> when entering sub-rule we are right before the "<" so we can test if it is
> "<WON:" by chance, if it is, w're done, print the name, and go to the end.
>
> If it's not "<WON:" we first test if next-part is still "" (first pass)
and
> we either do nothing, or append a "<" and next-part to the name", then we
> skip over the "<" (remember? that's where we entered the sub-rule!) and
then
> we copy the next-part of the name to the next "<" the rule ends here, but
> we've told parse to check this rule multiple times (some), so we just
reenter
> the sub-rule ...
>
>
> I hope this helps,
>
> Ingo
>
>
>
>
> Once upon a time Brett Handley spoketh thus:
> > > L 09/22/2000 - 15:37:25: "*`Ultimate_Master`*<4718>" <WON:26073391>"
> > connected, ip
> > > "202.54.232.2"
> > > L 09/22/2000 - 15:43:10: "[IMPREA]Smart-Gun!!<4723><WON:23014199>"
> > connected, ip
> > > "220.34.24.3"
> > > L 09/22/2000 - 15:47:30: "{[FrAg]}-MaN-<4727><WON:19220729>"
connected, ip
> > "132.76.43.24"
> > >
> > > L 09/22/2000 - 15:49:22: "<Usyd> H4XX0R<124><WON:20007739>" connected,
ip
> > "160.34.64.112"
> > >
> > > As you can see the game appears to impose few restrictions on the
range of
> > characters and
> > > spaces allowed in a name. It's also a stupid log format.
> >
> > Hmm. I agree really ugly log format...
> >
> > It really isn't the best example for getting confident on parse.
> >
> > But I can see it would be really good to get it to work :)
> >
> >
> > >Therefore I need the
> > > following behavoir from 'parse:
> > >
> > > go thru {"} then copy all text to name until the UID pattern "< some
> > digits >" is found.
> > > I don't want the UID included in 'name though. In the lines above that
> > would mean 'name
> > > is set to "*`Ultimate_Master`*", "[IMPREA]Smart-Gun!!",
"{[FrAg]}-MaN-"
> > and "<Usyd>
> > > H4XX0R" respectively.
> > >
> > > I don't want to go thru the UID I want to go 'to it, but still get a
'true
> > result.
> >
> > Is that log line you gave for Ultimate_Master accurate? There seems to
be a
> > double-quote after the UID.
> >
> > The problem that I can see is that somebody might have a name like
<4444>.
> > They might get really wierd and do something like <4444><4444> as a name
as
> > well.
> >
> > The only consistency I can see for determining what is really after the
name
> > is the string that starts <WON:
> >
> > So I reckon on the basis of what I've seen, the only way to get the name
> > accurately is to find the UID accurately and to do that requires
searching
> > backwards from before the <WON: for a <UID>.
> >
> > The problem here is parse won't do this neatly in one go.
> >
> > One idea then is to get parse to caputure from the beginning of the name
> > throught to the <WON and then call itself to process the internal bit -
my
> > worry with this is to know if parse is reenterant or not.
> >
> > Or better use parse to do as before but instead of calling itself, use
find
> > instead. I know you are trying to avoid find, but it may actually be the
> > simplest to code and understand.
> >
> > Alternatively you could probably get parse to backtrack in a fashion by
> > creating a truly evil parse rule. I managed to do this once but as I
said -
> > it is truly evil (modifies the input stream and other horrors). :)
> >
> > Anyway I'll wait to hear your thoughts and to find out if that
double-quote
> > was real or not.
> >
> > Brett.
> >
> > --
> > To unsubscribe from this list, please send an email to
> > [EMAIL PROTECTED] with "unsubscribe" in the
> > subject, without the quotes.
> >
>
> --
> do http://www.2b1.de/
> _ . _
> ingo@)|_ /| _| _ <We ARE all ONE www._|_o _ _ ._ _
> www./_|_) |o(_|(/_ We ARE all FREE> ingo@| |(_|o(_)| (_|
> ._| ._|
> --
> 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.
