IOhannes wrote:

Martin Peach wrote:

...

Have a look at the source for [mrpeach/which] in svn. I took some code from Pd internals and it calls some more, but maybe not _way_ too much.

thanks for the hints, but this is even more "ugly" (no harm intended) than what i already have. i really want to be agnostic about which extension the library has (just image miller adds a new extension; or hans removes .l_i386 from PdX and i will actually find the wrong binary)

Well it's the same 'ugly' code that Pd itself uses. I simply copied the extension list from Pd source. I guess you could just access the list directly and then not worry about it changing in the future. The code for [which] tries all possible extensions for the current OS and opens the first one that exists. Pd does the same thing, or at least the version in svn does. Probably if the relevant functions were exposed in m_pd.h they could all be used in situ.

Martin

martin.peach@sympatico.ca wrote:

...

thanks for the hints, but this is even more "ugly" (no harm intended) than what i already have. i really want to be agnostic about which extension the library has (just image miller adds a new extension; or hans removes .l_i386 from PdX and i will actually find the wrong binary)

Well it's the same 'ugly' code that Pd itself uses. I simply copied the extension list from Pd source.

you got me wrong. i know that it is copied from Pd sources and i have no problem with how Pd implements this. however, i want to find out where Pd got the file from, and just trying to do the same as (a specific version of) Pd and hope to end up with the same result is what i consider "ugly". (if i want to know what you get by multiplying 54234*6533 then it is no use to calculate it myself; either of us can make an error in the calculation and then my result will tell me nothing about yours)

I guess you could just access the list directly and then not worry about it changing in the future. The code for [which] tries all possible extensions for the current OS and opens the first one that exists. Pd does the same thing, or at least the version in svn does.

that is the problem. when running [which] with an older version of Pd (say: 0.39) and you have concurrent .pd_linux and .l_i386 lying around, then you might eventually get the wrong result (as you find .l_i386 for which Pd-0.39 doesn't care at all)

Probably if the relevant functions were exposed in m_pd.h they could all be used in situ.

yep, this is along the lines i was thinking. my approach with querying the class about it's "externdir" member is very much what i want (and do), it's only that this can only be found in private headers. (resulting in both compile-time and compatibility problems). you could have a look at my code at https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem/src/Base/GemSetu...

i was wondering whether i have overlooked a way to query private members of a class. probably we can tell miller into something like int class_getmember(t_class*c, t_symbol*id, t_atom*result); which would allow the developers to access existing private members (the funtion would return an error-code if the "id" did not name an existing member (or at least one that Pd knows about)

this seems to be more elegant than adding a bunch of functions like char* class_getname(t_class*c)

mfgasdr IOhannes