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

Jun 9, 2007 at 10:12pm

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

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:

long argc = 0;
t_atom argv[256];

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;
}

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:

#P newex 34 62 71 196617 route request;
#P newex 34 43 43 196617 bondo n;
#P newex 34 81 51 196617 zl slice 1;
#N coll ;
#P newobj 34 100 53 196617 coll;
#P objectname coll;
#P connect 2 0 3 0;
#P connect 3 0 1 0;
#P connect 1 0 0 0;

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:

t_atom argv[2];
SETSYM(argv, x->name);
SETSYM(argv + 1, x->id);
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 0×0) with 0 argument(s):
printit: received MESSAGE “myLib[1]” (0x1f60e74, s_thing 0×0) 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!

Thanks,
Mattijs

#32387
Jun 10, 2007 at 9:58am

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..?

Mattijs

#106428
Jun 10, 2007 at 10:15am

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.

#106429
Jun 10, 2007 at 3:39pm

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

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?

Mattijs

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

#106430
Jun 10, 2007 at 3:55pm

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

jb

Am 10.06.2007 um 17:39 schrieb Mattijs Kneppers:

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

#106431
Jun 10, 2007 at 9:46pm

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.

#106432
Jun 10, 2007 at 11:27pm

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.

Hey, that’s a funny coincidence.

>
> 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.

Ok. I’ll do one now.

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.

Best,
Mattijs

#106433
Jun 10, 2007 at 11:39pm

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.

#106434

You must be logged in to reply to this topic.