[PD] expr compatibility with libdir format

[Jonathan Wilkes]

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 <msp at ucsd.edu> 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

> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141012/78346eba/attachment.html>