[PD-dev] library finding it's own path?
IOhannes m zmölnig
zmoelnig at iem.at
Thu Apr 23 23:36:07 CEST 2009
martin.peach at 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
you could have a look at my code at
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
More information about the Pd-dev