dave leith

I have been needing to use regexp and the jit.str.regexp alot lately. There

is one inconsistency (at least) that I don't understand. It has to do with

formatting the expressions with or without a @ Can somehelp here?

I have been needing to use regexp and the jit.str.regexp alot lately. There
is one inconsistency (at least)  that I don't understand. It has to do with
formatting the expressions with or without a @  Can somehelp here?

baffled-regexp-inconsistencies-why

On 9 nov. 06, at 06:54, Dave Leith wrote:

> I have been needing to use regexp and the jit.str.regexp alot 

> lately. There is one inconsistency (at least) that I don't 

> understand. It has to do with formatting the expressions with or 

your problem have nothing to do with regexp, but it's related to the 

attributes. Attributes allow you to create an object with special 

behavior (instead of sending the messages via a message box and a 

loadbang.... or a loadmess). The syntax is the "@" sign followed by 

the name of the attributes and its arguments as you did on the left 

side of your patch. One cool thing about the attributes is that you 

can see what are the currents "values" of them while ctrl+option 

+click (alt+right click on windows) on the object.

About the "why is there a no match outlet", look at the patch bellow, 

it removes the aiff extension on a "file" if it exists. If you can 

get the no match, it's easier to deal with, if the regurlar 

> I have been needing to use regexp and the jit.str.regexp alot  
> lately. There is one inconsistency (at least)  that I don't  
> understand. It has to do with formatting the expressions with or  
> without a @  Can somehelp here?

Hi,
your problem have nothing to do with regexp, but it's related to the  
attributes. Attributes allow you to create an object with special  
behavior (instead of sending the messages via a message box and a  
loadbang.... or a loadmess). The syntax is the "@" sign followed by  
the name of the attributes and its arguments as you did on the left  
side of your patch. One cool thing about the attributes is that you  
can see what are the currents "values" of them while ctrl+option 
+click (alt+right click on windows) on the object.

About the "why is there a no match outlet", look at the patch bellow,  
it removes the aiff extension on a "file" if it exists. If you can  
get the no match, it's easier to deal with, if the regurlar  
expression failed.

I still think there there are a few very strange things happening here. (I

was aware of the attributes as I work with Jitter.) I have modified your

patch to show these and hopefully clarified my patch to show also. Sorry for

being thick about this I have 'big' plans for using the nomatch output. I

> On 9 nov. 06, at 06:54, Dave Leith wrote:

> I have been needing to use regexp and the jit.str.regexp alot lately.

> There is one inconsistency (at least) that I don't understand. It has to do

> with formatting the expressions with or without a @ Can somehelp here?

> your problem have nothing to do with regexp, but it's related to the

> attributes. Attributes allow you to create an object with special behavior

> (instead of sending the messages via a message box and a loadbang.... or a

> loadmess). The syntax is the "@" sign followed by the name of the attributes

> and its arguments as you did on the left side of your patch. One cool thing

> about the attributes is that you can see what are the currents "values" of

> them while ctrl+option+click (alt+right click on windows) on the object.

> About the "why is there a no match outlet", look at the patch bellow, it

> removes the aiff extension on a "file" if it exists. If you can get the no

> match, it's easier to deal with, if the regurlar expression failed.

> #P newex 635 475 62 196617 prepend set;

> #P message 672 391 43 196617 titi.aiff;

> #P newex 635 425 202 196617 regexp @re ([^.]+)\\.aiff @substitute %1;

I still think there there are a few very strange things happening here. (I
was aware of the attributes as I work with Jitter.) I have modified your
patch to show these and hopefully clarified my patch to show also. Sorry for
being thick about this I have 'big' plans for using the nomatch output. I
hope you can help.

On 11/9/06, Emmanuel Jourdan  wrote:
>
> On 9 nov. 06, at 06:54, Dave Leith wrote:
>
> I have been needing to use regexp and the jit.str.regexp alot lately.
> There is one inconsistency (at least)  that I don't understand. It has to do
> with formatting the expressions with or without a @  Can somehelp here?
>
>
> Hi,
> your problem have nothing to do with regexp, but it's related to the
> attributes. Attributes allow you to create an object with special behavior
> (instead of sending the messages via a message box and a loadbang.... or a
> loadmess). The syntax is the "@" sign followed by the name of the attributes
> and its arguments as you did on the left side of your patch. One cool thing
> about the attributes is that you can see what are the currents "values" of
> them while ctrl+option+click (alt+right click on windows) on the object.
>
> About the "why is there a no match outlet", look at the patch bellow, it
> removes the aiff extension on a "file" if it exists. If you can get the no
> match, it's easier to deal with, if the regurlar expression failed.
>
> HTH,
> ej
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 635 501 26 196617 toto;
> #P newex 635 475 62 196617 prepend set;
> #P message 672 391 43 196617 titi.aiff;
> #P message 635 392 26 196617 toto;
> #P newex 635 425 202 196617 regexp @re ([^.]+)\\.aiff @substitute %1;
> #P fasten 0 3 3 0 784 454;
> #P connect 0 0 3 0;
> #P connect 2 0 0 0;
> #P connect 1 0 0 0;
> #P connect 3 0 4 0;
> #P window clipboard copycount 5;
>
>
>
>
>

On 9 nov. 06, at 19:02, Dave Leith wrote:

> I still think there there are a few very strange things happening 

> here. (I was aware of the attributes as I work with Jitter.) I have 

> modified your patch to show these and hopefully clarified my patch 

> to show also. Sorry for being thick about this I have 'big' plans 

> for using the nomatch output. I hope you can help.

I can't speak about the getstate/getattribute, I can imagine this 

come with the OBEX externals stuff (Jeremy?). But I still doesn't 

understand why you don't use the attributes for the regexp object, 

the way you write the arguments it can't work. try the following:

2) ctrl+alt+click and look at the re and substitues attributes : it 

says it is looking for the string "re" and it'll substitute by "d"...

For the other part (see patch bellow), don't forget there's plenty of 

ways to extract the same information with a regular expression. Some 

are more efficient than other, and some may works faster but won't 

support possibility. You've to design the regular expression 

specially for the type of inputs you'll have. The "titi.aiff.aiff" 

didn't work because, I wasn't expected this as input, now it's 

supported, but there's still some issues (if the first extension is 

not aiff for example) but it's a choice (a compromise at least).

> Thanks Emmanuel
>
> I still think there there are a few very strange things happening  
> here. (I was aware of the attributes as I work with Jitter.) I have  
> modified your patch to show these and hopefully clarified my patch  
> to show also. Sorry for being thick about this I have 'big' plans  
> for using the nomatch output. I hope you can help.

I can't speak about the getstate/getattribute, I can imagine this  
come with the OBEX externals stuff (Jeremy?). But I still doesn't  
understand why you don't use the attributes for the regexp object,  
the way you write the arguments it can't work. try the following:

1) with this object in your patch:
regexp re \d substitute " "

2) ctrl+alt+click and look at the re and substitues attributes : it  
says it is looking for the string "re" and it'll substitute by "d"...

For the other part (see patch bellow), don't forget there's plenty of  
ways to extract the same information with a regular expression. Some  
are more efficient than other, and some may works faster but won't  
support possibility. You've to design the regular expression  
specially for the type of inputs you'll have. The "titi.aiff.aiff"  
didn't work because, I wasn't expected this as input, now it's  
supported, but there's still some issues (if the first extension is  
not aiff for example) but it's a choice (a compromise at least).

> On 9 nov. 06, at 19:02, Dave Leith wrote:

> > I still think there there are a few very strange things happening

> > here. (I was aware of the attributes as I work with Jitter.) I have

> > modified your patch to show these and hopefully clarified my patch

> I can't speak about the getstate/getattribute, I can imagine this

> come with the OBEX externals stuff (Jeremy?). But I still doesn't

> understand why you don't use the attributes for the regexp object,

> the way you write the arguments it can't work. try the following:

> 2) ctrl+alt+click and look at the re and substitues attributes : it

> says it is looking for the string "re" and it'll substitute by "d"...

For the other part (see patch bellow), don't forget there's plenty of

> ways to extract the same information with a regular expression. Some

> are more efficient than other, and some may works faster but won't

> support possibility. You've to design the regular expression

> specially for the type of inputs you'll have. The "titi.aiff.aiff"

> didn't work because, I wasn't expected this as input, now it's

> supported, but there's still some issues (if the first extension is

> not aiff for example) but it's a choice (a compromise at least).

Yah, thanks here too. Still can't figure out why my example finds 2

substitutions but then outputs an unmatched output (like I made yours do).

For my purposes here it will be alright. It does seem to be how you write

> #P hidden newex 309 277 68 196617 loadmess set;

> #P newex 400 281 62 196617 prepend set;

> #P message 220 100 62 196617 titi.aiff.aiff;

> #P newex 523 268 62 196617 prepend set;

> #P newex 220 338 62 196617 prepend set;

> #P message 262 155 47 196617 tutu.aiff;

> #P newex 220 217 251 196617 regexp @re ([^.]+)\\.aiff.* @substitute

On 11/9/06, Emmanuel Jourdan  wrote:
>
> On 9 nov. 06, at 19:02, Dave Leith wrote:
>
> > Thanks Emmanuel
> >
> > I still think there there are a few very strange things happening
> > here. (I was aware of the attributes as I work with Jitter.) I have
> > modified your patch to show these and hopefully clarified my patch
>
> I can't speak about the getstate/getattribute, I can imagine this
> come with the OBEX externals stuff (Jeremy?). But I still doesn't
> understand why you don't use the attributes for the regexp object,
> the way you write the arguments it can't work. try the following:
>
> 1) with this object in your patch:
> regexp re \d substitute " "
>
> 2) ctrl+alt+click and look at the re and substitues attributes : it
> says it is looking for the string "re" and it'll substitute by "d"...

For the other part (see patch bellow), don't forget there's plenty of
> ways to extract the same information with a regular expression. Some
> are more efficient than other, and some may works faster but won't
> support possibility. You've to design the regular expression
> specially for the type of inputs you'll have. The "titi.aiff.aiff"
> didn't work because, I wasn't expected this as input, now it's
> supported, but there's still some issues (if the first extension is
> not aiff for example) but it's a choice (a compromise at least).

Yah, thanks here too. Still can't figure out why my example finds 2
substitutions but then outputs an unmatched output (like I made yours do).
For my purposes here it will be alright. It does seem to be how you write
the RE rules.

Best,
> ej
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P hidden newex 309 277 68 196617 loadmess set;
> #P button 429 252 15 0;
> #P message 400 307 75 196617 toto;
> #P newex 400 281 62 196617 prepend set;
> #P message 220 100 62 196617 titi.aiff.aiff;
> #P newex 523 268 62 196617 prepend set;
> #P window linecount 0;
> #P message 523 306 50 196617;
> #P window linecount 1;
> #P message 220 364 75 196617 titi;
> #P newex 220 338 62 196617 prepend set;
> #P message 262 155 47 196617 tutu.aiff;
> #P message 237 128 26 196617 toto;
> #P newex 220 217 251 196617 regexp @re ([^.]+)\\.aiff.* @substitute
> %1;
> #P connect 3 0 4 0;
> #P connect 6 0 5 0;
> #P connect 8 0 9 0;
> #P connect 7 0 0 0;
> #P connect 1 0 0 0;
> #P connect 2 0 0 0;
> #P connect 0 0 3 0;
> #P connect 0 3 10 0;
> #P connect 0 3 8 0;
> #P connect 0 4 6 0;
> #P hidden connect 11 0 5 0;
> #P hidden connect 11 0 9 0;
> #P hidden connect 11 0 4 0;
> #P window clipboard copycount 12;
>
>

Baffled!! Regexp inconsistencies. Why?