Regexp unable to grok words like 'list' and 'float' in a list ?
Hi there,
I'm puzzled; an object generates quite a list of text lines and in order to pick out the stuff I want I figured a regexp is the best approach. However, it looks like regexp can't handle lines with words like "list" or "float" in them, yet this behavior isn't consistent so I'm wondering if this is a bug or something I'm overlooking.
Proof of concept follows below.
If you click the first message object it'll grab 'Song' as it is supposed to. If you click the second it'll output nothing and clicking the third triggers an error.
Its something I fail to understand since in the last case "float" is part of the whole sentence going into regexp. So I don't see why it still seems to be triggered by it.
Thanks in advance for any help you can provide me with!
These words are reserved in Max (and many other programming languages). You might want to capitalize them, or use different symbols or something.
-Ben
could it be that because the object responds to messages like "float" and "list", it's not possible to have that within your message without it getting confused or expecting an actual float or list to follow?
(i would think "float" and "list" internally are t_symbols? i could be wrong...)
EDIT: answered just as i posted this. that helps me understand, too, thanks.
________________________________
*Never fear, Noob4Life was never here!*
@Ben: Unfortunately I have no control over the data coming in. Although I already recognized them as being reserved I was hoping it wouldn't matter when processing text like this.
Alas, time to find a work around :-)
Both of you thanks very much for your quick response!
not sure if this is helpful but maybe you could turn the list into a symbol and look for matches to trigger output:
If something like that doesn't work, feel free to post your patch, maybe we can find something that works for your goals.
-Ben
Thanks Ben but I already solved it.
Yet as I said before, this behavior really is /very/ inconsistent.
Check out this patch; different regexp but same message object. And no more errors.. I'm really getting a feeling to have hit on a bug somewhere, but can't pinpoint it as of yet.
Main difference between this regexp and the previous one is the usage of \s instead of plain spaces, putting the whole lot between "" /and/ the usages of 'string literals' so to speak.
Already gave using \s and "" in the old regexp a try but that doesn't change anything. So I get the feeling that it starts going haywire as soon as it needs to compare strings. In a way it makes some sense, yet its not what I'm used to ;-)
Alas, this is my solution so far:
seems like the two patches are very different. The first one is passing out 'list' or 'float' to the print object and the second one is passing out 'song_length' and 'info type' to the print object.
You run into problems when you try to pass a message that is just 'float' or just 'list' to an object. Internally in the regexp, it looks to me as if it is doing exactly what it is supposed to do.
Glad you found a solution that works for you, but feel free to pass along any potential issues you see with the way this stuff works, happy to take a look.
FWIW, using your original patch, here is a tricky way to do it by using a substitute "list %1":
-Ben