Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ RegExp VM
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
3
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #30 on Wed 28 Apr 2004 05:26 AM (UTC) |
| Message
| But if you think about it, that's the only way for the regular expression to behave coherently. You can't have a wildcard for every line in the list, simply because you don't know how many lines there are.
Again let's consider:
^Inventory:$(.*?)^$
This time note that I have the non-greedy specifier. This regular expression will match on "Inventory:" followed by a newline followed by anything followed by a blank line.
How are you going to express the notion of making a new wildcard for every line?
It seems to me that the cleanest solution is to just get the set of lines matched, split them by newline, and then do whatever you need to do with each line.
Furthermore, let's assume you wanted to have a sword in your inventory. You could check that like so:
^Inventory:$(.*?)sword(.*?)^$
So I'm not sure what the problem is. You say that we have to go looking in the bucket for what we were looking for... well... let's be more precise, what were we looking for and we can't we find it with the current method?
I'd imagine that a scripting function could be added that given a block of text, returns an array of each line. Basically a split function, that operates on newlines. Would that solve your problem? |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Shadowfyr
USA (1,791 posts) Bio
|
| Date
| Reply #31 on Wed 28 Apr 2004 05:48 PM (UTC) Amended on Wed 28 Apr 2004 05:51 PM (UTC) by Shadowfyr
|
| Message
| Geeze.. I think you are still missing the point. lol Both our methods can do the same thing, mine just doesn't need the bucket. Having a script function that returns an array? Umm. Try 'split'... Anyway, I just said I thought taking extra time to create and search a buffer, that mine doesn't need, is inelegant and a hack. This doesn't mean it doesn't work. Inelegant means clumsy and excessive when another method could be more efficient, hack in this case means "the first thing that came to mind", rather than the most efficient solution. I can't see how forcing the user to define a buffer to search, even when the trigger is absolutely and undeniably not greedy, can ever be called efficient or elegant, therefore at the very least *some* other method must be better, even if you don't agree it is mine.
The only thing that mine does that is a hack is the third option for immediately acting on each matched line. Some goofy thing that generates an array from a bloc kof lines is still a hack, since you are not handling the lines as they arrive, in fact it is what you end up doing if you want to do anything useful with Nick's output anyway. No, it doesn't solve any problem I see with the design.
It isn't about "if" they can both do the same things, it is about how they do them and the overhead they introduce that can slow down operation of what, up to this point, has been a client that strives to avoid things that can seriously slow it down.
But again, this is a mute point. I doubt I could successfully write a pre-parser and without a working version of mine, Nick's can and will get the job done. My personal opinion is simply that we are paying a higher price for the behavior than we might have if my system could have been developed instead. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #32 on Wed 28 Apr 2004 06:34 PM (UTC) |
| Message
| | Well, fine, the point may be moot. Nonetheless, I still think that you are trying to do something that just can't be correct in all cases. The day you bring me a working program or algorithm, I'll be convinced; until then let us agree to disagree on the feasibility of your project. :) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
| Date
| Reply #33 on Wed 28 Apr 2004 09:34 PM (UTC) |
| Message
| Yes, perhaps time to stop discussing it. :)
I don't think my method is perfect, however it was quick and easy to do - easier than some sort of on-the-fly state machine, and the easy solution has the advantage of simplicity, and simplicity has the advantage that it is likely to have less bugs.
For those that recall the many, many, discussions we had in the past about multi-line triggers and why they are hard to do, this forum thread confirms that it is a problem that doesn't have a quick, simple solution.
It reminds me of the saying:
Quote:
For every problem there is a Solution. Neat, Simple, Wrong!
My solution, which is now available for playing with, may not be the neatest in the world, but if it works to easily process stat rolls, or player stats, or inventory lists, or multi-line room descriptions, then I will be happy. :) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
78,522 views.
This is page 3, subject is 3 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
3
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top