Can you try on you osx [declare -lib jit_expr] or [declare -lib full/path/to/jit_expr]?

I'm not sure if -stdlib is currently covering the .../documents/pd/externals/* on all platforms.

see https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files for the paths that -stdlib covers.

there's a discussion here : https://github.com/pure-data/pure-data/pull/205

---

I think there will be no name clashes if you keep your [jit_expr] naming. If you use [expr] it will clash with Pd's [expr].

--

Mensaje telepatico asistido por maquinas.

On 2/21/2018 1:50 PM, Alex wrote: I have an external I've created that I've put into: /Users/alex/Documents/Pd/externals/jit_expr/ the binary is called "jit_expr.pd_darwin"

xnor-work:~/projects/perfect/center$ ls /Users/alex/Documents/Pd/externals/jit_expr/ LICENSE-parser LICENSE-pd LICENSE-xnor jit_expr-help.pd jit_expr.pd_darwin

In the binary, the externals themselves are named "jit/expr" "jit/expr~" and "jit/fexpr~"

On my work, osX machine, when I [declare -stdlib jit_expr] I then fail to create [jit/expr] On my home, linux machine, where my external folder is located at /home/alex/.local/lib/pd/externals/jit_expr and appropriately named jit_expr.pd_linux I succeed to create [jit/expr] after [declare -stdlib jit_expr]

Is this a bug am I not following some naming convention that I should be?

I could see wanting to put my external in a folder called "jit" and then naming them "expr", "expr~" etc but I could imagine "jit" is more likely to collide and so "jit_expr" seemed more reasonable. maybe I should just call the whole thing "jit_expr", and just call the objects "expr" etc without the prefix in the code and then be able to create [jit_expr/expr] with no declare because it'll be in the stdlib already? Am I confusing conventions that exist for single binary libraries with multiple objects and binaries with only one?

Either way, should I file a bug that the behavior isn't the same on osx and linux?

thanks, Alex

_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev

2018-02-21 13:50 GMT-03:00 Alex x37v.alex@gmail.com:

I have an external I've created that I've put into: /Users/alex/Documents/Pd/externals/jit_expr/ the binary is called "jit_expr.pd_darwin" (...) when I [declare -stdlib jit_expr] I then fail to create [jit/expr] On my home, linux machine, where my external folder is located at /home/alex/.local/lib/pd/externals/jit_expr and appropriately named jit_expr.pd_linux I succeed to create [jit/expr] after [declare -stdlib jit_expr]

Is this a bug am I not following some naming convention that I should be?

Yes, I would call it a bug, of some sort.

The way things are now in regards to what a standard path is or should be is unclear to most people. And when the recent addition of the folder ~ /Documents/Pd/externals (as you're using) was being included for macOS I really thought it should be then included as a new "standard path" - as you did too right now - and made a Pull Request for it, but it got rejected.

As it turns out, from the discussion on that Pull Request, the "Standard Path" is only supposed to be the "extra" folder.

This is ok, as long as it's made clear, and in fact, if you check Pd's manual, that's all you'll see, that the "standard folder" IS the "extra" folder. But is known by several Pd users that Pd has actually got other standard paths, for macOS, Windows and Linux. The one you are using for externals in Linux is actually considered by Pd a "standard folder", so this works there, but not in ~/Pd/Documents on a mac!

I still don't know why these extra standard folders came about, since the idea is that only "extra" should be a standard folder. I guess this was somehow included by "accident", or "unnoticed". But I know how the Pd community site has long well documented and talked about the existence of such additional standard folders. Maybe it was a practice from Pd Extended that somehow got into Pd? I don't know...

All I know is that we have this confusing scenario, and I've recently wrote a well detailed documentation on how to manage externals in Pd. But I'm holding it back until we have this situation better cleared out. There are also parallel discussions and suggestions being made currently to Pd, so I'm also waiting to see how that goes. See this for instance: https://github.com/pure-data/pure-data/pull/205

And the exact same issue as you pointed out was already opened on Pd's github as well, here it is: https://github.com/pure-data/pure-data/issues/237

It was closed cause, well, this is known and intentional, but I still think we have more to do. Regarding this conflicting and confusion situation about additional and "standard paths" that are in conflict to Pd's own documentation, I have a new PR suggesting to just get rid of them here: https://github.com/pure-data/pure-data/pull/183

Cause, as I see it, we either clean this up, or we have all these current and known paths as "standard paths" and document them as so, and also include the new ~/Pd/Documents/externals on mac as a new one - but since that already got rejected, cleaning up is the only way to go as I see it.

2018-02-21 14:39 GMT-03:00 Alex x37v.alex@gmail.com:

[declare -lib jit_expr] worked on my osx machine.

Yeah, well, so, as I said, you should not bother to use "-stdlib" or "-stdpath" unless you were using the "extra" folder, so this is what you should do indeed.

cheers