On Mar 20, 2012, at 3:41 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-03-19 21:03, Hans-Christoph Steiner wrote:
Yes, in scripts/ in pure-data SVN. You're best bet for getting Gem to accept the meta files is to submit them to the pd-gem tracker. For this release of Pd-extended 0.43, Gem is already imported into the pd-extended/0.43 branch in SVN, so you can commit directly there.
while of course i have no problem with including a Gem-meta.pd, i think i remember that there where problems related to that simplistic approach.
Gem (as is and will stay for the foreseeable future), is a single-binary-multiple-object library. adding a "Gem-meta.pd" will make [import Gem] search for and find "Gem/Gem-meta.pd" and happily report the Gem libdir(!) to be loaded while this is really not enough to make Gem do anything at all. I assume that people will then complain that Gem is "broken" because it doesn't work even though [import] reports it should, while really only the import mechanism cannot deal with Gem's reality.
my suggestion to make the -meta.pd patches something like proper "__init__" thingies, allowing a library to bootstrap itself where unfortunately turned down (i'm sure for good reasons).
so this is the reason why there is no Gem-meta.pd (yet). if my assumptions above are not true or don't matter, i guess there is no reason to not add it.
I did a quick test, I just added a blank Gem-meta.pd file to Gem in Pd-extended. It did not seem to prevent Gem from loading, either using [import Gem] and "pd -noprefs" or just the default loading of Gem via the prefs.
I think that Gem/Gem.pd_linux comes before Gem/Gem-meta.pd in the list of priorties.
.hc
Access to computers should be unlimited and total. - the hacker ethic