Mattijs

Hi, I have the following problem, I hope I'll be able to describe it accurately.

I split a string and save the tokens in an array of atoms:

        post("adding %s", result);

        SETSYM(&argv[argc], gensym(result));

        result = strtok( NULL, delims );

When I output the resulting array of atoms out a list outlet and print it, the list looks healthy.

I then send the array of atoms to a [bondo n] object:

typedmess(b->b_firstin, gensym("request"), argc, argv);

[bondo n] outputs as expected, 'request atom1 atom2 etc'. [bondo n] is connected to a [route request]. After the route the list is split and the first item is sent to a coll:

This first item is equal to an index in the coll, which means the coll should output the data that is stored in the matching entry. But it doesn't (*this is my problem*).

So I guess my question is: how is this possible? I input a symbol in a coll that contains a matching entry but the coll doesn't output the appropriate data.

The coll was populated by another object that stored this entry like so:

typedmess(b->b_firstin, gensym("store"), 2, argv);

Furthermore, I ran into the following: when I use cnmat's [printit] to print both messages (the one that enters the coll from the bondo object and the one stored as index in the coll, which are equal), I get the following output in the max window, respectively:

printit: received MESSAGE "myLib[1]" (0x1f60ef8, s_thing 0x0) with 0 argument(s):

printit: received MESSAGE "myLib[1]" (0x1f60e74, s_thing 0x0) with 0 argument(s):

Assuming that the hexadecimal value represents the pointer I conclude that both messages, even though the strings are equal, still have a different entry in the symbol table.

If there is an expert (which I am not) that recognizes anything obscure in the code above or in my approach, please let me know. Any help or insight would be warmly appreciated!

	char *str;
	str = path->s_name;
	char delims[] = ".";
	char *result = NULL;
	result = strtok( str, delims );
	while( result != NULL ) 
	{
		post("adding %s", result);
		SETSYM(&argv[argc], gensym(result));
		result = strtok( NULL, delims );
		argc = argc + 1;
	}

t_atom argv[2];
SETSYM(argv, x->name);
SETSYM(argv + 1, x->id);
typedmess(b->b_firstin, gensym("store"), 2, argv);

printit: received MESSAGE "myLib[1]" (0x1f60ef8, s_thing 0x0) with 0 argument(s):
printit: received MESSAGE "myLib[1]" (0x1f60e74, s_thing 0x0) with 0 argument(s):

new-entry-generated-in-symbol-table-for-a-string-that-is-already-added

Allright, I spotted one big mistake in the code of my previous post. I assumed strtok would leave the original string intact. This is clearly not the case. So now I copy the string with strcpy before tokenizing it and the problem is gone. I don't understand why though, so any piece of advice is still welcome.

You might be interested to know that this even visibly affected the arguments in the object box of the abstraction that contained my object (!!). The path symbol that I parse was received by my object via the #1 argument inside an abstraction. After parsing the string of this symbol with strtok, and saving and reopening the patch, suddenly only the first part of the path argument was visible in my abstraction's object box. I assume I was directly changing the patcher's binbuf..?

Where does your t_symbol *path come from? Is that user input? If so, 

that may be the problem: you shouldn't make any modifications to 

incoming data, thinking of it as read-only.

void blah(t_myob *x, t_symbol *s, long ac, t_atom *av);

You should not touch s, ac, or av. Well, ac doesn't really matter, 

but you don't want to monkey around with the contents of the t_symbol 

or t_atom *s, since other objects (message boxes, for example) may be 

Am 10.06.2007 um 11:58 schrieb Mattijs Kneppers:

> I don't understand why though, so any piece of advice is still 

Where does your t_symbol *path come from? Is that user input? If so,  
that may be the problem: you shouldn't make any modifications to  
incoming data, thinking of it as read-only.

You should not touch s, ac, or av. Well, ac doesn't really matter,  
but you don't want to monkey around with the contents of the t_symbol  
or t_atom *s, since other objects (message boxes, for example) may be  
using them.

> I don't understand why though, so any piece of advice is still  
> welcome.


Quote: Jeremy Bernstein wrote on Sun, 10 June 2007 12:15

----------------------------------------------------

> Where does your t_symbol *path come from? Is that user input? If so, 

> that may be the problem: you shouldn't make any modifications to 

> incoming data, thinking of it as read-only.

> void blah(t_myob *x, t_symbol *s, long ac, t_atom *av);

> You should not touch s, ac, or av. Well, ac doesn't really matter, 

> but you don't want to monkey around with the contents of the t_symbol 

> or t_atom *s, since other objects (message boxes, for example) may be 

This is exactly what happened, why my object boxes suddenly changed their own arguments :p Thanks for the confirmation. Kindof confusing at start but I see how it works now.

Btw this doesn't explain why there appeared two different symbols with an equal s_name, right?

> Am 10.06.2007 um 11:58 schrieb Mattijs Kneppers:

> > I don't understand why though, so any piece of advice is still 

Quote: Jeremy Bernstein wrote on Sun, 10 June 2007 12:15
----------------------------------------------------
> Where does your t_symbol *path come from? Is that user input? If so,  
> that may be the problem: you shouldn't make any modifications to  
> incoming data, thinking of it as read-only.
>
> If your function is:
>
> void blah(t_myob *x, t_symbol *s, long ac, t_atom *av);
>
> You should not touch s, ac, or av. Well, ac doesn't really matter,  
> but you don't want to monkey around with the contents of the t_symbol  
> or t_atom *s, since other objects (message boxes, for example) may be  
> using them.
>
> jb

>
> Am 10.06.2007 um 11:58 schrieb Mattijs Kneppers:
>
> > I don't understand why though, so any piece of advice is still  
> > welcome.
>
>
----------------------------------------------------


You were corrupting memory. Results when you do this are generally 

unpredictable. On some systems, Max probably crashes. On others, it 

Am 10.06.2007 um 17:39 schrieb Mattijs Kneppers:

> Btw this doesn't explain why there appeared two different symbols 

You were corrupting memory. Results when you do this are generally  
unpredictable. On some systems, Max probably crashes. On others, it  
all works fine.

> Btw this doesn't explain why there appeared two different symbols  
> with an equal s_name, right?


Quote: Mattijs wrote on Mon, 11 June 2007 03:39

> This is exactly what happened, why my object boxes suddenly 

> changed their own arguments :p Thanks for the confirmation.

Funny. I was coding exactly the same thing on Friday, and initially made exactly the same mistake with strtok(). Seeing the patcher arguments change after a save/reload is quite amusing.

Mattijs - I'm quite close to a working object that encapsulates almost all of the javascript functionality I prototyped in the "oo" thread. I need to do a little work today to get the oo.call and oo.method abstractions communicating as directly as possible (without send/forward/receive), then I will post back in that thread.

Quote: Mattijs wrote on Mon, 11 June 2007 03:39
----------------------------------------------------
> This is exactly what happened, why my object boxes suddenly 
> changed their own arguments :p Thanks for the confirmation. 

Mattijs - I'm quite close to a working object that encapsulates almost all of the javascript functionality I prototyped in the "oo" thread. I need to do a little work today to get the oo.call and oo.method abstractions communicating as directly as possible (without send/forward/receive), then I will post back in that thread.


Quote: johnpitcairn wrote on Sun, 10 June 2007 23:46

> Quote: Mattijs wrote on Mon, 11 June 2007 03:39

> ----------------------------------------------------

> > This is exactly what happened, why my object boxes suddenly 

> > changed their own arguments :p Thanks for the confirmation. 

> Funny. I was coding exactly the same thing on Friday, and initially made exactly the same mistake with strtok(). Seeing the patcher arguments change after a save/reload is quite amusing.

> Mattijs - I'm quite close to a working object that encapsulates almost all of the javascript functionality I prototyped in the "oo" thread. I need to do a little work today to get the oo.call and oo.method abstractions communicating as directly as possible (without send/forward/receive), then I will post back in that thread.

I just (a few minutes ago) fixed the last bug and finished recreating the functionality of the javascripts of my last example in the oo thread. I wanted to recreate the objects to do exactly the same as the javascripts in order to have a clear comparison in the tests so that we can say something about js vs external.

I'll have to clean some code and maybe add some error checks but then we'll be able to benchmark the exact same patch but with the js objects replaced with externals. I'm curious about the performance. In fact I can't wait to do the tests now but I reallly need the sleep.

Well well. The same patch that took 1 second to load now gives me 117 ms. That's certainly much better. And the timer gives 60 ms interval where I remember something like 300ms with js. On a powerbook G4 1.25 GHz.

However, it's 1:30 am, I'll have to do this again tomorrow before I can say anything sensible about it.

Hope I can get back to the oo thread real soon.

Quote: johnpitcairn wrote on Sun, 10 June 2007 23:46
----------------------------------------------------
> Quote: Mattijs wrote on Mon, 11 June 2007 03:39
> ----------------------------------------------------
> > This is exactly what happened, why my object boxes suddenly 
> > changed their own arguments :p Thanks for the confirmation. 
>
> Funny. I was coding exactly the same thing on Friday, and initially made exactly the same mistake with strtok(). Seeing the patcher arguments change after a save/reload is quite amusing.

>
> Mattijs - I'm quite close to a working object that encapsulates almost all of the javascript functionality I prototyped in the "oo" thread. I need to do a little work today to get the oo.call and oo.method abstractions communicating as directly as possible (without send/forward/receive), then I will post back in that thread.

Yep, I did a quick test fairly early in the development and without doing call path validation, I got a massive improvement over the js version. I figured we could ignore the path validation in that result since there were only a few instances of that. I do have the validation working now. More soon, back in the oo thread.

new entry generated in symbol table for a string that is already added