Hey,
I posted this on gem-dev before, IOhannes suggested that it might be related to the mrpeach string patch, which is included in the Pd-0.40.3-extended auto-builds:
class_addmethod: 0x2af5480 consistency check failed: class_addmethod: GEMglProgramStringARB_string: bad argument types
class_addmethod: 0x2b43260 consistency check failed: class_addmethod: text2d_string: bad argument types
class_addmethod: 0x2b43260 consistency check failed: class_addmethod: text3d_string: bad argument types
class_addmethod: 0x2b43260 consistency check failed: class_addmethod: textextruded_string: bad argument types
class_addmethod: 0x2b43260 consistency check failed: class_addmethod: textoutline_string: bad argument types
h.c
------------------------------------------------------------------------ ----
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
Hey,
I posted this on gem-dev before, IOhannes suggested that it might be related to the mrpeach string patch, which is included in the Pd-0.40.3-extended auto-builds:
I wonder why...I quickly looked at the gem source but couldn't find these symbols. For instance,
class_addmethod: 0x2b43260 consistency check failed: class_addmethod: textextruded_string: bad argument types
The only place in the gem090 code I find anything at all like this is at line 90 of textextruded.cpp:
void textextruded :: obj_setupCallback(t_class *classPtr) { class_addmethod(classPtr, (t_method)&textextruded::depthMessCallback, gensym("depth"), A_FLOAT, A_NULL); }
I don't see anything relating to string here...but maybe that's not where the error is coming from.
Martin
Quoting Martin Peach martin.peach@sympatico.ca:
I don't see anything relating to string here...but maybe that's not where the error is coming from.
the joys of inheritance; look at Base/TextBase.cpp...
apart from that: i have no proof that it is really your strings patch that makes Gem behave weird. it was only an assumption based upon the fact, that on my machines i don't get this error and i don't have your patch applied.
a quick test would be to use pd-extended's Gem with a vanilla pd.
fma.dr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Quoting zmoelnig@iem.at:
a quick test would be to use pd-extended's Gem with a vanilla pd.
ok, i now did following tests:
bin/pd from pd-extended with Gem from pd-extended: the error occurs
bin/pd from pd-extended with Gem from my local disk: the error occurs
bin/pd vanilla with Gem from pd-extended: the error does not occur
bin/pd vanilla with Gem from my local disk: the error does not occur
so the problem seems to be related to (not necessarily caused by) something in the pd-extended binary. the first thing that comes to my mind is still related to "string"s, and this is unfortunately mrpeach's string-patch.
fmga.dsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
zmoelnig@iem.at wrote:
ok, i now did following tests:
bin/pd from pd-extended with Gem from pd-extended: the error occurs
bin/pd from pd-extended with Gem from my local disk: the error occurs
bin/pd vanilla with Gem from pd-extended: the error does not occur
bin/pd vanilla with Gem from my local disk: the error does not occur
so the problem seems to be related to (not necessarily caused by) something in the pd-extended binary. the first thing that comes to my mind is still related to "string"s, and this is unfortunately mrpeach's string-patch.
All the string patch does is establish a string type and let pd route string messages to their handlers if they exist (so far only the [str] external has them). If you don't use that type, it should have no effect. It doesn't really have anything to do with strings either, the string atoms are just pointers to something. It would be interesting to see how that could interfere with Gem...possibly there's a name clash somewhere, or Gem is expecting to see a specific memory structure within pd, say where the list of types is maintained.
Martin
Martin Peach wrote:
zmoelnig@iem.at wrote:
ok, i now did following tests:
bin/pd from pd-extended with Gem from pd-extended: the error occurs
bin/pd from pd-extended with Gem from my local disk: the error occurs
bin/pd vanilla with Gem from pd-extended: the error does not occur
bin/pd vanilla with Gem from my local disk: the error does not occur
so the problem seems to be related to (not necessarily caused by) something in the pd-extended binary. the first thing that comes to my mind is still related to "string"s, and this is unfortunately mrpeach's string-patch.
All the string patch does is establish a string type and let pd route string messages to their handlers if they exist (so far only the [str] external has them). If you don't use that type, it should have no effect. It doesn't really have anything to do with strings either, the string atoms are just pointers to something. It would be interesting to see how that could interfere with Gem...possibly there's a name clash somewhere, or Gem is expecting to see a specific memory structure within pd, say where the list of types is maintained.
no, Gem uses pd's gpointer for it's data (which per se is a problem, but it is unrelated to the name clash)
i have finally made this test: use pd from CVS and applied _only_ the string-patch (patch-#1646604) (ok, this is not entirely true, i have also applied 2 very minor patches (#1826144 and #1822943) which do not have _anything_ to do with strings (e.g. the symbol "string" does not appear anywhere...)
i compile this version of Pd and load my Gem et voila: class_addmethod: 0xb7c06540 consistency check failed: class_addmethod: textoutline_string: bad argument types ...
i consider this as prove that the problem is related to both Gem and your string-patch (and nothing else)
apart from that, Pd behaves weird now: if i create a messagebox [string hallo( and click on it (with nothing connected) i get an error "error: messresponder: no method for string so far..."
mfg.asdr IOhannes
On Nov 6, 2007, at 5:05 PM, Martin Peach wrote:
zmoelnig@iem.at wrote:
ok, i now did following tests:
bin/pd from pd-extended with Gem from pd-extended: the error occurs
bin/pd from pd-extended with Gem from my local disk: the error occurs
bin/pd vanilla with Gem from pd-extended: the error does not occur
bin/pd vanilla with Gem from my local disk: the error does not occur
so the problem seems to be related to (not necessarily caused by) something in the pd-extended binary. the first thing that comes to my mind is still related to "string"s, and this is unfortunately mrpeach's string-patch.
All the string patch does is establish a string type and let pd route string messages to their handlers if they exist (so far only the [str] external has them). If you don't use that type, it should have no effect. It doesn't really have anything to do with strings either, the string atoms are just pointers to something. It would be interesting to see how that could interfere with Gem...possibly there's a name clash somewhere, or Gem is expecting to see a specific memory structure within pd, say where the list of types is maintained.
Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all:
consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol widget's error: creation failure ... you might be able to track this down from the Find menu. see standard error for details widget's error: creation failure see standard error for details widget q snd -width 100 ... couldn't create
I checked this patch into the branch-v0-40-extended pd/src, so Martin, if you want to work directly there to fix this, please feel free to commit to that branch. Just make sure that you don't commit to MAIN :). Then ultimately, the patch should be updated.
.hc
------------------------------------------------------------------------ ----
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
On Nov 6, 2007, at 5:05 PM, Martin Peach wrote:
zmoelnig@iem.at wrote:
ok, i now did following tests:
bin/pd from pd-extended with Gem from pd-extended: the error occurs
bin/pd from pd-extended with Gem from my local disk: the error occurs
bin/pd vanilla with Gem from pd-extended: the error does not occur
bin/pd vanilla with Gem from my local disk: the error does not occur
so the problem seems to be related to (not necessarily caused by) something in the pd-extended binary. the first thing that comes to my mind is still related to "string"s, and this is unfortunately mrpeach's string-patch.
All the string patch does is establish a string type and let pd route string messages to their handlers if they exist (so far only the [str] external has them). If you don't use that type, it should have no effect. It doesn't really have anything to do with strings either, the string atoms are just pointers to something. It would be interesting to see how that could interfere with Gem...possibly there's a name clash somewhere, or Gem is expecting to see a specific memory structure within pd, say where the list of types is maintained.
Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all:
consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol widget's error: creation failure ... you might be able to track this down from the Find menu. see standard error for details widget's error: creation failure see standard error for details widget q snd -width 100 ... couldn't create
Well OK, I'm still not clear on why the string patch should be the cause any of that. Yesterday I committed a change to the patch which just involves renaming string to blob. I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?)
I checked this patch into the branch-v0-40-extended pd/src, so Martin, if you want to work directly there to fix this, please feel free to commit to that branch. Just make sure that you don't commit to MAIN :). Then ultimately, the patch should be updated.
Which patch did you check in?
Martin
On Nov 8, 2007, at 3:53 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Nov 6, 2007, at 5:05 PM, Martin Peach wrote:
zmoelnig@iem.at wrote:
ok, i now did following tests:
bin/pd from pd-extended with Gem from pd-extended: the error occurs
bin/pd from pd-extended with Gem from my local disk: the error occurs
bin/pd vanilla with Gem from pd-extended: the error does not occur
bin/pd vanilla with Gem from my local disk: the error does not occur
so the problem seems to be related to (not necessarily caused by) something in the pd-extended binary. the first thing that comes to my mind is still related to "string"s, and this is unfortunately mrpeach's string-patch.
All the string patch does is establish a string type and let pd route string messages to their handlers if they exist (so far only the [str] external has them). If you don't use that type, it should have no effect. It doesn't really have anything to do with strings either, the string atoms are just pointers to something. It would be interesting to see how that could interfere with Gem...possibly there's a name clash somewhere, or Gem is expecting to see a specific memory structure within pd, say where the list of types is maintained.
Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all:
consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol consistency check failed: widget_anything consistency check failed: widget_symbol consistency check failed: widget_symbol widget's error: creation failure ... you might be able to track this down from the Find menu. see standard error for details widget's error: creation failure see standard error for details widget q snd -width 100 ... couldn't create
Well OK, I'm still not clear on why the string patch should be the cause any of that. Yesterday I committed a change to the patch which just involves renaming string to blob. I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?)
Ok, now I think the widget thing is separate because it also exists in Pd-0.39.3-extended, which definitely does not have the string patch.
I checked this patch into the branch-v0-40-extended pd/src, so Martin, if you want to work directly there to fix this, please feel free to commit to that branch. Just make sure that you don't commit to MAIN :). Then ultimately, the patch should be updated.
Which patch did you check in?
Martin
Everything that is currently in packages/patches.
.hc
------------------------------------------------------------------------ ----
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
hi
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all:
Well OK, I'm still not clear on why the string patch should be the cause any of that.
i don't think that your string patch has anything to do with _that_ one.
Yesterday I committed a change to the patch which just involves renaming string to blob.
i think the problem is, that your patch introduces "reserved" symbols in the first place. personally i would remove the entire [string <...>( message and replace it by a [list <...>( (don't use a special selector)
I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?)
no, it's a pd thing. you also get this when you use weird (that is: non pd-ish, user-defined) atoms and pd doesn't know how to handle them.
i am currently thinking of a proposal for user-defined atom-types, which can be registered like classes and then be used by objects like [str],... and (that is the important thing) do not interfere with each other. i need this for a separate project, and it would be a cool feature for pd to have.
fmgsard. IOhannes
IOhannes m zmoelnig wrote:
i think the problem is, that your patch introduces "reserved" symbols in the first place. personally i would remove the entire [string <...>( message and replace it by a [list <...>( (don't use a special selector)
I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?)
no, it's a pd thing. you also get this when you use weird (that is: non pd-ish, user-defined) atoms and pd doesn't know how to handle them.
The particular error "consistency check failed: class_addmethod: text2d_string: bad argument types" is generated in class_addmethod in m_class.c whenever the arguments don't match the type.
For example adding a list method but not giving A_GIMME as the expected type: else if (sel == &s_list) { if (argtype != A_GIMME) goto phooey; class_addlist(c, fn); }
phooey prints the consistency check error:
phooey: bug("class_addmethod: %s_%s: bad argument types\n", c->c_name->s_name, sel->s_name);
So an error like
consistency check failed: class_addmethod: text2d_string: bad argument types
is caused when the expected arguments to text2d_String don't match the type. It has absolutely nothing to do with the existence of a string/blob type unless text2dstring wants string/blob arguments. Maybe the patch is not being applied properly? Why does this happen only with gem when the patch has been applied for the last 6 months and nothing else has broken?
Martin
Martin Peach wrote:
is caused when the expected arguments to text2d_String don't match the type. It has absolutely nothing to do with the existence of a string/blob type unless text2dstring wants string/blob arguments.
the [text3d]... objects expect a "string" message with pdstrings (according to moocows stuff). your string-patch adds a special message "string" for your strings. i think that is where the problem comes in: A_GIMME != A_STRING
Maybe the patch is not being applied properly? Why does this happen only with gem when the patch has been applied for the last 6 months and nothing else has broken?
that's a good question. it is likely that the problem occurs with pd-0.40 (and there was no pd-0.40 before)
fgmadr IOhannes
IOhannes m zmoelnig wrote:
the [text3d]... objects expect a "string" message with pdstrings (according to moocows stuff).
OK, so the message [string( is being interpreted by pd as a selector for A_STRING instead of just a message "string", because "string" has become a reserved word.
your string-patch adds a special message "string" for your strings. i think that is where the problem comes in: A_GIMME != A_STRING
The latest version of the patch in cvs calls it A_BLOB instead of A_STRING. Does this resolve the issue? Or will it cause [blob( messages to go wrong?
Martin
Martin Peach wrote:
IOhannes m zmoelnig wrote:
the [text3d]... objects expect a "string" message with pdstrings (according to moocows stuff).
OK, so the message [string( is being interpreted by pd as a selector for A_STRING instead of just a message "string", because "string" has become a reserved word.
correct.
my proposal is therefore to entirely skip reserved words when introducing new types and solely rely on the atom-type (A_BLOB), rather than the list selector.
do you have any strong reason why you need to reserve a selector when introducing a new atom-type? (apart from: "that was the way it seemed to be done")
your string-patch adds a special message "string" for your strings. i think that is where the problem comes in: A_GIMME != A_STRING
The latest version of the patch in cvs calls it A_BLOB instead of A_STRING. Does this resolve the issue? Or will it cause [blob( messages to go wrong?
the problem is not with A_BLOB vs A_STRING, but with use of selectors. see above.
fmasdr. IOhannes
IOhannes m zmoelnig wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
the [text3d]... objects expect a "string" message with pdstrings (according to moocows stuff).
OK, so the message [string( is being interpreted by pd as a selector for A_STRING instead of just a message "string", because "string" has become a reserved word.
correct.
my proposal is therefore to entirely skip reserved words when introducing new types and solely rely on the atom-type (A_BLOB), rather than the list selector.
Fair enough, but that would mean changing the pd API, for instance the class_addmethod function, which wants a selector. Pd seems to use the type A_BLOB in some places and the selector s_blob in others, I'm not sure if it could be made to use only the type without breaking all the currently existing externals.
do you have any strong reason why you need to reserve a selector when introducing a new atom-type? (apart from: "that was the way it seemed to be done")
That's right. I basically copied the way it was done for floats and lists. I tried not using a selector but things didn't work properly, like class_addmethod. If you can see how it could be made to work without the selector, please let us know.
your string-patch adds a special message "string" for your strings. i think that is where the problem comes in: A_GIMME != A_STRING
The latest version of the patch in cvs calls it A_BLOB instead of A_STRING. Does this resolve the issue? Or will it cause [blob( messages to go wrong?
the problem is not with A_BLOB vs A_STRING, but with use of selectors. see above.
True, I forgot to mention that I also changed the "string" selector to "blob".
Martin
morning all,
On 2007-11-09 21:28:57, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
Martin Peach wrote:
is caused when the expected arguments to text2d_String don't match the type. It has absolutely nothing to do with the existence of a string/blob type unless text2dstring wants string/blob arguments.
the [text3d]... objects expect a "string" message with pdstrings (according to moocows stuff). your string-patch adds a special message "string" for your strings. i think that is where the problem comes in: A_GIMME != A_STRING
not having followed this thread too closely, i feel somewhat loathe to enter it now; i just wanted to explicitly renounce any and all claims to the selector "string" for pdstring-style lists of floats in favor of Martin's string atoms. nothing i've done with (pdstring+gem) has gotten beyond the sandbox stage, so changing selectors (e.g. to "asciilist", "pdstring", whatever) for list-of-floats messages would suffice i think. [string2any] itself doesn't care about selectors, and [any2string] currently just spits out a "list", so i'm pretty flexible...
marmosets, Bryan
On Nov 9, 2007, at 7:47 AM, IOhannes m zmoelnig wrote:
hi
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all:
Well OK, I'm still not clear on why the string patch should be the cause any of that.
i don't think that your string patch has anything to do with _that_ one.
Yesterday I committed a change to the patch which just involves renaming string to blob.
i think the problem is, that your patch introduces "reserved" symbols in the first place. personally i would remove the entire [string <...>( message and replace it by a [list <...>( (don't use a special selector)
I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?)
no, it's a pd thing. you also get this when you use weird (that is: non pd-ish, user-defined) atoms and pd doesn't know how to handle them.
i am currently thinking of a proposal for user-defined atom-types, which can be registered like classes and then be used by objects like [str],... and (that is the important thing) do not interfere with each other. i need this for a separate project, and it would be a cool feature for pd to have.
What kind of other atom types are you thinking? Like int? I suppose to make Pd into a full-fledged programming language, it would be useful to be able to support things like 128-bit floats, 32-bit ints, etc..
It would be good to have a clean way to support new atom types like strings, it also seems that this feature could open up a big can of worms.
.hc
------------------------------------------------------------------------ ----
If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson
Hans-Christoph Steiner wrote:
On Nov 9, 2007, at 7:47 AM, IOhannes m zmoelnig wrote:
hi
Martin Peach wrote:
Hans-Christoph Steiner wrote:
Unfortunately, looks like I found another similar bug when loading [widget]. But [widget] fails to load at all:
Well OK, I'm still not clear on why the string patch should be the cause any of that.
i don't think that your string patch has anything to do with _that_ one.
Yesterday I committed a change to the patch which just involves renaming string to blob.
i think the problem is, that your patch introduces "reserved" symbols in the first place. personally i would remove the entire [string <...>( message and replace it by a [list <...>( (don't use a special selector)
I would like to know if the problems go away with that. (What's a consistency check? It's c++, right?)
no, it's a pd thing. you also get this when you use weird (that is: non pd-ish, user-defined) atoms and pd doesn't know how to handle them.
i am currently thinking of a proposal for user-defined atom-types, which can be registered like classes and then be used by objects like [str],... and (that is the important thing) do not interfere with each other. i need this for a separate project, and it would be a cool feature for pd to have.
What kind of other atom types are you thinking? Like int? I suppose to make Pd into a full-fledged programming language, it would be useful to be able to support things like 128-bit floats, 32-bit ints, etc..
It would be good to have a clean way to support new atom types like strings, it also seems that this feature could open up a big can of worms.
I don't know why my posts are not getting through but the last one I sent explained where the consistency check error is coming from, and there is just no way it could be caused by the string type unless the patch is being improperly applied or gem is trying to use a string type, but then it should cause pd to not compile. Why did the string patch work for everything except gem for the past 6 months if it supposedly breaks everything?
Martin
Hans-Christoph Steiner wrote:
What kind of other atom types are you thinking? Like int? I suppose to make Pd into a full-fledged programming language, it would be useful to be able to support things like 128-bit floats, 32-bit ints, etc..
well, yes, but that is not my concern now. i would rather have that pd's native floating point format to be settable at compile time, but that is something completely different.
what i would like to have is more along strings, gem-states,... and other complex stuff. i am not thinking about types that can be defined within the pd environment, but rather outside (in C,...)
though the former might be interesting too...
It would be good to have a clean way to support new atom types like strings, it also seems that this feature could open up a big can of worms.
how?
mgadr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
What kind of other atom types are you thinking? Like int? I suppose to make Pd into a full-fledged programming language, it would be useful to be able to support things like 128-bit floats, 32-bit ints, etc..
well, yes, but that is not my concern now. i would rather have that pd's native floating point format to be settable at compile time, but that is something completely different.
what i would like to have is more along strings, gem-states,... and other complex stuff. i am not thinking about types that can be defined within the pd environment, but rather outside (in C,...)
The string/blob patch already allows you to do this. The atom is just a pointer. The application can use the pointer any way it likes. And as I said, I'm still not convinced that it causes trouble for code that doesn't use it.
Maritn
Martin Peach wrote:
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The string/blob patch already allows you to do this. The atom is just a pointer. The application can use the pointer any way it likes. And as I said, I'm still not convinced that it causes trouble for code that doesn't use it.
how will your [str] object handle an incoming gemlist? how will a gem-object using your blobs handle an incoming "string"?
f.art IOhannes
IOhannes m zmoelnig wrote:
how will your [str] object handle an incoming gemlist?
If it's passed as a "string", a pointer to a block of bytes with a definite length, then it will process it the same way as any other block of bytes, perhaps not usefully.
how will a gem-object using your blobs handle an incoming "string"?
It would need to verify that the incoming "string" data was of the right kind. Possibly the first few bytes would be some kind of selector. The data is in bytes just the same as a file or stdin stream, so its meaning and format is up to the user. Martin
Martin Peach wrote:
IOhannes m zmoelnig wrote:
how will your [str] object handle an incoming gemlist?
If it's passed as a "string", a pointer to a block of bytes with a definite length, then it will process it the same way as any other block of bytes, perhaps not usefully.
right.
how will a gem-object using your blobs handle an incoming "string"?
It would need to verify that the incoming "string" data was of the right kind. Possibly the first few bytes would be some kind of selector. The data
right.
this is the problem i want to address. pd already has a typed atoms, why would one want to add atoms of "unknown" type and then implement an extra type-check in each and every object/library that introduces a new type.
what happens if 2 different types chose the same magic bytes to determine whether the data is "correct"?
i would like to have a dynamic assignment of "atom-types" to user-defined types.
mfg.asdr IOhannes
IOhannes m zmoelnig wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
how will your [str] object handle an incoming gemlist?
If it's passed as a "string", a pointer to a block of bytes with a definite length, then it will process it the same way as any other block of bytes, perhaps not usefully.
right.
how will a gem-object using your blobs handle an incoming "string"?
It would need to verify that the incoming "string" data was of the right kind. Possibly the first few bytes would be some kind of selector. The data
right.
this is the problem i want to address. pd already has a typed atoms, why would one want to add atoms of "unknown" type and then implement an extra type-check in each and every object/library that introduces a new type.
I suppose because the surgery required to add a type to pd is not easy, and requires patching the source, so just adding a single 'unknown' type that requires the external to do the type-checking is easier. If the atoms were not restricted in size it would be easy to just add another field to identify the type. The way things are it might be better to modify the blob type from: typedef struct _blob /* pointer to a blob */ { unsigned long s_length; /* length of blob in bytes */ unsigned char *s_data; /* pointer to 1st byte of blob */ } t_blob;
to: typedef struct _blob /* pointer to a blob */ { t_symbol *blob_type; void *blob; /* pointer to blob */ } t_blob; then after verifying that the blob_type is the right one, the blob could be accessed according to its expected structure. In the case of string blobs the blob type would be "string" and the blob itself would be a struct consisting of the length and the pointer to the data. You still have the problem of name conflicts, just as with the different "counter" objects, but there is no way of avoiding that in every case, apart from having a central repository of registered names or a dispenser of "globally unique identifiers".
Martin
Martin Peach wrote:
IOhannes m zmoelnig wrote:
I suppose because the surgery required to add a type to pd is not easy, and requires patching the source, so just adding a single 'unknown' type that requires the external to do the type-checking is easier. If the
why?
when patching the core is needed (which i agree that it is), then we could just go the whole length
atoms were not restricted in size it would be easy to just add another field to identify the type. The way things are it might be better to modify the blob type from: typedef struct _blob /* pointer to a blob */ { unsigned long s_length; /* length of blob in bytes */ unsigned char *s_data; /* pointer to 1st byte of blob */ } t_blob;
to: typedef struct _blob /* pointer to a blob */ { t_symbol *blob_type; void *blob; /* pointer to blob */ } t_blob;
still i don't understand why you would want a blob to have 2 types: A_BLOB and blob_type. iirc, atom.a_type is (int), which gives us a huge wealth of possible types and no need to add another type-system.
then after verifying that the blob_type is the right one, the blob could be accessed according to its expected structure. In the case of string blobs the blob type would be "string" and the blob itself would be a struct consisting of the length and the pointer to the data. You still have the problem of name conflicts, just as with the different "counter" objects, but there is no way of avoiding that in every case, apart from having a central repository of registered names or a dispenser of "globally unique identifiers".
i think this could be solved if you don't insist on giving a symbolic name, and have a way to share a variable across your objects.
furthermore, even with names, the good news is, that you can chose an arbitrary name (which nobody but the C-programmer has to remember), which is a lot easier than with object-names. for instance, one could (by convention), use globally unique identifiers.
fgmads.r IOhannes
IOhannes m zmölnig wrote:
Martin Peach wrote:
IOhannes m zmoelnig wrote:
I suppose because the surgery required to add a type to pd is not easy, and requires patching the source, so just adding a single 'unknown' type that requires the external to do the type-checking is easier. If the
why?
when patching the core is needed (which i agree that it is), then we could just go the whole length
Sure! I did the string/blob as a first attempt to see if it could be done. I'd be quite happy to see it done better.
atoms were not restricted in size it would be easy to just add another field to identify the type. The way things are it might be better to modify the blob type from: typedef struct _blob /* pointer to a blob */ { unsigned long s_length; /* length of blob in bytes */ unsigned char *s_data; /* pointer to 1st byte of blob */ } t_blob;
to: typedef struct _blob /* pointer to a blob */ { t_symbol *blob_type; void *blob; /* pointer to blob */ } t_blob;
still i don't understand why you would want a blob to have 2 types: A_BLOB and blob_type. iirc, atom.a_type is (int), which gives us a huge wealth of possible types and no need to add another type-system.
Well because A_BLOB is the type that can be anything, and blob_type is the particular type. The pd core needs to be patched for every new A_THING, but externals could handle the different blob_types without passing through the core. The A_BLOB handler just calls the user-defined function for its own blobs, or a default when there is none. Probably it's unnecessary to have the blob_type registered in the core as long as pd passes A_BLOB messages around properly. I was thinking that the class_addmethod function needed the s_blob symbol but it probably would work without it.
then after verifying that the blob_type is the right one, the blob could be accessed according to its expected structure. In the case of string blobs the blob type would be "string" and the blob itself would be a struct consisting of the length and the pointer to the data. You still have the problem of name conflicts, just as with the different "counter" objects, but there is no way of avoiding that in every case, apart from having a central repository of registered names or a dispenser of "globally unique identifiers".
i think this could be solved if you don't insist on giving a symbolic name, and have a way to share a variable across your objects.
Whatever it is has to be 8 bytes long and contain a pointer to something (4 bytes) as well as a way to know what kind of thing the data is. It could be an int or a pointer to a symbol or something else.
furthermore, even with names, the good news is, that you can chose an arbitrary name (which nobody but the C-programmer has to remember), which is a lot easier than with object-names. for instance, one could (by convention), use globally unique identifiers.
Maybe something like:
typedef struct _blob /* pointer to a blob */ { int s_guid; /* unique identifier for this type of blob */ void *s_data; /* pointer to 1st byte of blob */ } t_blob;
Then an external would ignore blobs with guids it doesn't recognize. The s_data for a "string" would be defined inside the str external as: typedef struct _string_blob /* pointer to a string blob */ { unsigned long str_length; /* length of string in bytes */ unsigned char *str_data; /* pointer to 1st byte of string */ } string_blob;
and if you had a t_blob pointer b it would access the first byte of the string as ((string_blob *)(b->s_data))->str_data[0]
Martin
-
Bryan Jurish -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach -
zmoelnig＠iem.at