Regexp unable to grok words like 'list' and 'float' in a list ?
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!
----------begin_max5_patcher---------- 394.3ocyUFsaBBCEF9ZLw2gllcw1hyPgg.6t8LrKmtkJTwt.sDZMiMyd2WaQ TTPilLmdA8P9OG372OfCK62yBNkWRDPvSfWAVVKUJVFMshUsfELCWFkhElBg Lxm7oe.GrJmjTJM54ETlbsLM1Hpp7ATvZ0YblTP+lnygbFZWqyVjQYoDooCn Fp7ExZ40EmikQyorj2KHQxJuiBQpaF.4aqCtd5UG04fIM6LCmY5L74BJNEZx 7S+d5nJL3nIPFQHvIj1HfxlwAxuxIfYobb2v.cZvvoaXfN.LbBFo2+gg50.W CXBZxhp6i1mUW.Ddw3TJUzIl7N+Tx1cCk78upozKbVRWTx8rSIjsei2kBubT ZeScJHIjxbvX3aav0sCu+taFC67yu+jQQdGhXipFE8nYTDxMr8rn1LavNGmB CqpElRYsljarmNwNjUvWTDU27UXAf1zzXhPRYXIkyZVjZNNnw1XNMNlv1Zzb FMNmq9MvJi.lr+m2Gu2Pa218XtKh27tdsl6+i0zBpvu.ezi0S. -----------end_max5_patcher-----------
These words are reserved in Max (and many other programming languages). You might want to capitalize them, or use different symbols or something.
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:
----------begin_max5_patcher---------- 544.3oc2VFrbaBCDF9L7TnQmc8fPRX6bqW5odqGqyzAajcTFPhAIO0oYx6dQ BHA6DDjIFbZOXzn0KZ+2OjVsO56A2HOxTPvMfeB77dz2yyZxXvqdtGLK931z Xk0Mnf8a4l6gyp9KM6n1ZNufKzMVyi0auiK1+qB1Vc0hGtXdvLPHlZFvD6jf 4AfaqeEdhcYJW5ufhZVGwgLtHkosQFUabmTnEwYLq+esfGm1xc4Aci+As7Ww +i0eT37.i0m78MOlMvbNioTw6YuJo+NW4LmqRZzxHaRGNmZlzQRSeyjN7clz MPpxj9gbVkTfvmCZdASwD5XMWJZIVJp5iBFYFBpe77aMhT7aoxXWXD0fQ6.t dRGXjbkwHAguRX7GRw9dO.1rWbkSHhmJHdAvQG0izR0CYajo8SDjcftxUIoU WjJRWUfTTFUFXMjK1IAlXCLaXVCOwzNyQwyrkVVjaMreNRrDDibBRxEAjjNA 4rV+lhCcmgNGTJxVdcg84Rryien+gN90OXRceIIwRjpMOKbVam9eEVFT45Pa 6RKcVs9yPwZqOvTt37dIsYlw9orRIOTrsIB0EXAujcILklKrWs1xGxI9bGOI gIZ2nWFOIWV1EZsD.29le2FphHCPQlKJmXIg5SRSOkB6SRzIURmEtNzTz6SS g3HS26gU2t0ZxGUrjQPrnWzGssXoeTwhGAwNRfcHRc0jtuj9oSQlFMFUIUN4 I++BfOPwmB -----------end_max5_patcher-----------
If something like that doesn’t work, feel free to post your patch, maybe we can find something that works for your goals.
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:
----------begin_max5_patcher---------- 377.3ocyT0sSCBCF8ZVxdGZZ7BcYRnvla3c9bnSSG7MVMPKg1EQW7c21x5j8 mtkL+gD3ibNes8vgS6xtc7vSE0fDitEcOxyaoFwyhYP7b.d3BZcRNUZaDW.R IMCv8WQpfZkkfwmIPpWKAzrbAUstAVpkVL84qIiViNSvUR1afgiD5G3v4KJX 7bPYWrvVnhEJGLwAWRUIyY7rmpfDUymwfXhdxPgAiMkwQlmD86nItA0LQFg1 LBL9SNip3zBKC9tJFMGaYduaGSUW5ezFEGdQ+MuqOUVw362cFbZtCY+tSvW4 NAAV24lQlRzvFqps6bNcfCFUjBspxAdlZ9gCKw+3YknQiakUHAC++EVpfLnt D83k98t5A8kzum+E6M7DdVBOCOB6JJtkcsY5YW6p+V2mh80zKNmw24PJq7LD aYpRwhpD2h6NxA0RgofTw3TESva2U3lcMmklB7M1MUvRKE5ctqTBZxg+We7h yrrjuUbC9SDW7ujwY.zkO.xhyI. -----------end_max5_patcher-----------
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":
----------begin_max5_patcher---------- 416.3ocyUFsSCBCEF9Z3onoQSTCtPggayqzmAuzMML3LVMPKgVhnK6cWZA1v IagXlycAkzCGN++mOZNrxz.OmW.BL5dzyHCiUlFF5Pp.F06MvI9EAw9BcZXF 7Ne9aXqpGIgBoNbZFkIahllABfI8kTN60LHPVIvnICrsPjwNpa10KnY0uDKO gxhAoVFRcvEblj4m.ZMdLi5GuQCeYvRJKpU8Id55aqKsqdiSaEng5xTZ+acs wakkmKaz0tktB5mZcIk9UEcsooZwpmfJADB+H3GjhxVvQxORAzhXtuD2U667 qZ+ICaZYKzX2JV2c66Lr61uA6UgTlrpzX7lpbRHSLUbLACgrELiFcHv3cdyk m3rniHW7ZcdYxgvh6+IV1yDmLHBJRQSwurkOWM3lquXJF8fHetPRk4RnLA0o IzkjoX7QdTycZz43YenQMjtYm2dYm0NW8gk5bJaT1tCy0dWE+6.VvyyBZTr1 kns1ODJoGSO+tUNpglsRZIMLDXsmZlPCS4k+Gn1CnYc90tuVxsGVhbRcj2Ym iTCx+SsT4l0leIffjaH -----------end_max5_patcher-----------