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