Hi Miller,
There's also the separate bug about the %s not having a corresponding variable.
I fixed it in Pd-l2ork and put a patch on the tracker, but I'm not sure where
expr~ upstream actually resides.
Also, do note that there is probably a discrepancy between what the loader is
willing to try to load, and what a class is willing to do inside the *_new
function. In my test, Pd's loader has no problem with Pd-extended's 0.43
"extra/expr~". But as far as expr_new is concerned, it doesn't recognize that
string. Yet it also defaults to creating an [expr] object instead of bailing.
I think an error inside *_new should end in a broken object, or at the least
should warn the user what class it is defaulting to.
Furthermore, I can't see a use case for the loader sending the full or libdir
path as part of the symbol. Is there one? Expr as well as a lot of internal
objects assume an unprefixed creator name. If Hans or someone else actually
ships a Pd-extended with a separate "vanilla" libdir, expect to see a bunch of
unnecessary breakage for no apparent gain.
-Jonathan
On Sunday, October 12, 2014 5:41 PM, Miller Puckette <[email protected]> wrote:
HI all -
I tried making expr take just the filename without the path in the test,
and got an unintended consequence I can't understand (if you make both an
expr and an expr~, for instance, the .so gets loaded twice).
So I backed off from that but t least fied the error message. so for now
at least, in vanilla at least, it isn't possible to invoke expr (etc.)
via path.
I don't know if there are ther external objects like expr in that there
are symlinks (or copies) of the binary by different names that the object
uses to disambiguate itself. I rather doubt it, but OTOH there's a lot of
stuff out there.
cheers
Miller
On Sun, Oct 12, 2014 at 01:52:23PM -0700, Jonathan Wilkes via Pd-list wrote:
> Hi list,
> It seems expr isn't compatible with the libdir format. The code in expr_new
> of vexp_if.c checks for unprefixed creator names, so if the user typed
> "expr~/expr~" or "extra/expr~" or even
> "the_libdir_that_I_put_in_my_patch_directory/expr~", the logic defaults to
> creating an expr_class instead of an expr_tilde_class. It also outputs an
> error.
>
>
> Also, the error it outputs has a bug itself-- there is no corresponding
> variable for the %s in this line:
> post("expr_new: bad object name '%s'");
>
> That will often cause a crash on 32-bit systems. I wasn't able to crash on a
> 64-bit system, although that %s will output a bunch of garbage characters to
> the Pd window.
>
> Obviously expr (and probably a lot of other code) expect the creator to be
> the same as what the class author specified in the setup routine. So Pd
> should deliver that symbol without the libdir prefix to the *_new function
> for that class.
>
> I tested on Pd 0.43 from Sourceforge on a 32-bit Wheezy machine, plus
> Pd-l2ork which forked at 0.42. Has Pd Vanilla addressed this problem since
> then?
>
> -Jonathan
> _______________________________________________
> [email protected] mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
