Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

+1

> Gesendet: Sonntag, 07. Januar 2018 um 20:58 Uhr
> Von: "Lucas Cordiviola" <lucard...@hotmail.com>
> An: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> I think Joao (the OP) is asking how to do in 2018 what he was doing back 
> on the “extended” years. IRRC he shares his lib which uses many other 
> objects from other libs.
> Now there should be a proper way to do that with the cocktail “Deken, 
> [declare] & namespace”.
> 
> Deken - ? (only issue I know is troubles adding path for pkgs that have 
> “-” in its name)
> 
> [Declare] - We should review 
> https://github.com/pure-data/pure-data/pull/205 because the proposed:
> 
> 1: search relatively to the calling patch
> 2: search the user's global paths
> 3: search Pd's system paths
> 
> Is a good one.
> 
> Namespace – Single binary libs should provide a way call [obj] using 
> namespace.
> 
> 
> 
> --
> 
> Mensaje telepatico asistido por maquinas.
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Lucas Cordiviola]

I think Joao (the OP) is asking how to do in 2018 what he was doing back 
on the “extended” years. IRRC he shares his lib which uses many other 
objects from other libs.
Now there should be a proper way to do that with the cocktail “Deken, 
[declare] & namespace”.

Deken - ? (only issue I know is troubles adding path for pkgs that have 
“-” in its name)

[Declare] - We should review 
https://github.com/pure-data/pure-data/pull/205 because the proposed:

1: search relatively to the calling patch
2: search the user's global paths
3: search Pd's system paths

Is a good one.

Namespace – Single binary libs should provide a way call [obj] using 
namespace.



--

Mensaje telepatico asistido por maquinas.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig :

> On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
> >
> > The compiled object from the lib listed in the path doesn't get called,
> and
> > the one specified in [declare] gets called instead.
> >
>
> repeat the test with two abstractions having loading libraries providing
> the same object.
> e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd
> uses a [gate] stub that prints "gate 2".
> load abs1.pd, after that abs2.pd (either manually, or by putting them
> into a master patch). observe the console.
>

ok, I actually have to say I don't get what this is supposed to test. I
just get "gate1" and "gate2" as I would expect and I don't see how it
relates to the previous discussion.

Now, since I have already replied to this giving the idea that I understood
it and that it made me see things I didn't know, I have to explain that I
had found them on my own and just assumed we were talking about the same
thing. But now that I actually tried to check it, I don't.

Sorry for the confusion. I'm actually on vacation visiting paradisiac
beaches of the brazilian northeast and shouldn't be trying to find time to
keep up with this :)

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-02 5:54 GMT-03:00 João Pais :

>
> Also: I imagine that there isn't a problem with repeated declarations?
> Inside each abstraction there is a [declare], and a patch can always use
> lots of them.
>

I don't think there is

>
> A suggestion: I can write [declare -stdlib x], and there will be no
> error message warning that the x library doesn't exist. Would it be
> good to have an error message, or even open deken to search for it?
>

added a request https://github.com/pure-data/pure-data/issues/281
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-06 13:35 GMT-03:00 Lucas Cordiviola <lucard...@hotmail.com>:

> I steel believe that the “best practice” is [foo/obj]. At least for
> sharing patches. At home or with live-patching is another story.
>

I've been responding to this thread and changing the focus to how declare
works and how should it work, but I haven't replied what I think it's the
best practice for sharing patches...

so +1 for namespaces

But personally, I hate using them for my own stuff. I don't use [declare]
either, cause it still doesn't quite work for me, and we've been discussing
ways to improve/enhance it, as I pointed in my first reply here on this
thread.

for my own stuff, I just try to rely on as few libraries as I can, and I
just don't use objects that have the same name and do different things, so
I'm just happy to not bother with any namespace/declare nonsense, I just
add the libraries to my path and enjoy them

cheers




>
> The only things that needs to get fixed are some single binary libs. To
> put some random example some objects on iemlib already work with
> [iemlib/obj] and others don't.
>
> Makes me think that if zexy and iemlib (and other single binary) support
> [foo/obj] every thing will be under control.
>
> I'm not a Gem user so I don't know if it has potential name clashes
>
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 1/6/2018 10:41 AM, Christof Ressi wrote:
> >> (which actually might be tricky depending on platform/how their system
> is set up).
> > exactly, that's why it's better not to make any assumptions. just tell
> users: "needs zexy, cyclone ..." and it's their responsibility to add the
> necessary search paths/load libs if necessary.
> >
> > and again:
> >
> >>> imagine you want to use both [foo/obj] and [bar/obj] in the same
> >>> abstraction. how could you possibly force on or the other with
> >>> declare?
> >
> >> Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr
> >> Von: "Derek Kwan" <derek.x.k...@gmail.com>
> >> An: "Alexandre Torres Porres" <por...@gmail.com>
> >> Cc: "Christof Ressi" <christof.re...@gmx.at>, Pd-List <
> pd-list@lists.iem.at>
> >> Betreff: Re: [PD] declare vs. namespaces - current best practice
> >>
> >>
> >>>> And to come back to my first remark here on this thread, if
> >>>> [declare] cannot always force a priority, shouldn't it?
> >>> I don't think so. [declare]'s job is to add paths to the search path
> >>> and load libraries. it has nothing to do with namespacing.
> >>>
> >>> imagine you want to use both [foo/obj] and [bar/obj] in the same
> >>> abstraction. how could you possibly force on or the other with
> >>> declare?
> >>>
> >> Well, I suppose one way of forcing the use of cyclone's gate without
> >> typing out the entire thing and dealing with this whole namespacing
> >> thing is to basically use the -noprefs flag when launching pd (and
> >> assuming the people you are distributing the patch to have Pd somewhere
> >> in their path which might be a big if, you can send along a shell script
> >> that launches pd with that flag for them) and using [declare] to control
> >> what gets loaded and what paths are added (which actually might be
> >> tricky depending on platform/how their system is set up). And of course
> >> not loading the prefs file affects more than just paths/loading...
> >>
> >> So maybe now that I type it out this isn't such a simple idea to
> >> implement haha, but maybe it could be helpful for some use cases...
> >>
> >> Derek
> >> --
> >> Derek Kwan
> >> www.derekxkwan.com
> >>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-06 7:53 GMT-03:00 Christof Ressi :

> > So this is still safe if you're sharing a patch to be first opened on
> its own.
>
> in other words: it's not safe at all ;-)
>

why not? If you first open Pd with a patch that uses [declare], from
someone who shared it, it'll be guaranteed that it works! Given that you
have the library, of course...



>
> > And to come back to my first remark here on this thread, if [declare]
> cannot always force a priority, shouldn't it?
>
> I don't think so. [declare]'s job is to add paths to the search path and
> load libraries. it has nothing to do with namespacing.


> imagine you want to use both [foo/obj] and [bar/obj] in the same
> abstraction. how could you possibly force on or the other with declare?
>

you can't, you can only do that with namespaces, alright, but this is still
a pretty specific use case, and I don't understand what it has to do with
the idea that [declare] should force a priority, which is something it
actually already does as I pointed out...

and ok, it doesn't always do that as we discussed and found out, but then
it's just a matter of "fixing" it...


>
> namespacing by definition involves some kind of extra typing (like it or
> not) to differentiate entities that otherwise would look the same. the
> current mechanism of prepending the folder name already supports that, only
> single-binary libraries are sometimes a problem. cyclone already shows how
> this can be dealt with effectivly by adding a second creator (e.g.
> "cyclone/gate")
>

cyclone doesn't have a second creator for "cyclone/gate". It is not a
single-binary library, but a mix of things, it has a) abstractions, b)
separately compiled objects and c) a single-binary sub pack. For "c" -
which is a library named "cyclone" (that loads non alphanumeric objects) -
we have a second creator, so, given that you first loaded the "cyclone"
(with declare or whatever) you can load an object like >~ as either just
[>~] or also as [cyclone/>~].

This way you can force namespaces into single binary packs.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-06 7:15 GMT-03:00 IOhannes m zmölnig :

> On 01/06/2018 04:04 AM, Alexandre Torres Porres wrote:
> > And to come back to my first remark here on this thread, if [declare]
> > cannot always force a priority, shouldn't it?
>
> maybe.
> it would require a complete rewrite of the the object loading, with a
> hierarchical class loading system.
> a non-trivial task.
>

cool, maybe it's time I open a new issue on github and we'll see where that
goes
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Lucas Cordiviola]

I steel believe that the “best practice” is [foo/obj]. At least for 
sharing patches. At home or with live-patching is another story.

The only things that needs to get fixed are some single binary libs. To 
put some random example some objects on iemlib already work with 
[iemlib/obj] and others don't.

Makes me think that if zexy and iemlib (and other single binary) support 
[foo/obj] every thing will be under control.

I'm not a Gem user so I don't know if it has potential name clashes



--

Mensaje telepatico asistido por maquinas.

On 1/6/2018 10:41 AM, Christof Ressi wrote:
>> (which actually might be tricky depending on platform/how their system is 
>> set up).
> exactly, that's why it's better not to make any assumptions. just tell users: 
> "needs zexy, cyclone ..." and it's their responsibility to add the necessary 
> search paths/load libs if necessary.
>
> and again:
>
>>> imagine you want to use both [foo/obj] and [bar/obj] in the same
>>> abstraction. how could you possibly force on or the other with
>>> declare?
>
>> Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr
>> Von: "Derek Kwan" <derek.x.k...@gmail.com>
>> An: "Alexandre Torres Porres" <por...@gmail.com>
>> Cc: "Christof Ressi" <christof.re...@gmx.at>, Pd-List <pd-list@lists.iem.at>
>> Betreff: Re: [PD] declare vs. namespaces - current best practice
>>
>>
>>>> And to come back to my first remark here on this thread, if
>>>> [declare] cannot always force a priority, shouldn't it?
>>> I don't think so. [declare]'s job is to add paths to the search path
>>> and load libraries. it has nothing to do with namespacing.
>>>
>>> imagine you want to use both [foo/obj] and [bar/obj] in the same
>>> abstraction. how could you possibly force on or the other with
>>> declare?
>>>
>> Well, I suppose one way of forcing the use of cyclone's gate without
>> typing out the entire thing and dealing with this whole namespacing
>> thing is to basically use the -noprefs flag when launching pd (and
>> assuming the people you are distributing the patch to have Pd somewhere
>> in their path which might be a big if, you can send along a shell script
>> that launches pd with that flag for them) and using [declare] to control
>> what gets loaded and what paths are added (which actually might be
>> tricky depending on platform/how their system is set up). And of course
>> not loading the prefs file affects more than just paths/loading...
>>
>> So maybe now that I type it out this isn't such a simple idea to
>> implement haha, but maybe it could be helpful for some use cases...
>>
>> Derek
>> -- 
>> Derek Kwan
>> www.derekxkwan.com
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

> (which actually might be tricky depending on platform/how their system is set 
> up). 

exactly, that's why it's better not to make any assumptions. just tell users: 
"needs zexy, cyclone ..." and it's their responsibility to add the necessary 
search paths/load libs if necessary.

and again:

> > imagine you want to use both [foo/obj] and [bar/obj] in the same
> > abstraction. how could you possibly force on or the other with
> > declare?


> Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr
> Von: "Derek Kwan" <derek.x.k...@gmail.com>
> An: "Alexandre Torres Porres" <por...@gmail.com>
> Cc: "Christof Ressi" <christof.re...@gmx.at>, Pd-List <pd-list@lists.iem.at>
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> 
> >> And to come back to my first remark here on this thread, if
> >> [declare] cannot always force a priority, shouldn't it?
> >
> > I don't think so. [declare]'s job is to add paths to the search path
> > and load libraries. it has nothing to do with namespacing.
> >
> > imagine you want to use both [foo/obj] and [bar/obj] in the same
> > abstraction. how could you possibly force on or the other with
> > declare?
> >
> 
> Well, I suppose one way of forcing the use of cyclone's gate without
> typing out the entire thing and dealing with this whole namespacing
> thing is to basically use the -noprefs flag when launching pd (and
> assuming the people you are distributing the patch to have Pd somewhere
> in their path which might be a big if, you can send along a shell script
> that launches pd with that flag for them) and using [declare] to control
> what gets loaded and what paths are added (which actually might be
> tricky depending on platform/how their system is set up). And of course
> not loading the prefs file affects more than just paths/loading...
> 
> So maybe now that I type it out this isn't such a simple idea to
> implement haha, but maybe it could be helpful for some use cases...
> 
> Derek
> -- 
> Derek Kwan
> www.derekxkwan.com
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Derek Kwan]

>> And to come back to my first remark here on this thread, if
>> [declare] cannot always force a priority, shouldn't it?
>
> I don't think so. [declare]'s job is to add paths to the search path
> and load libraries. it has nothing to do with namespacing.
>
> imagine you want to use both [foo/obj] and [bar/obj] in the same
> abstraction. how could you possibly force on or the other with
> declare?
>

Well, I suppose one way of forcing the use of cyclone's gate without
typing out the entire thing and dealing with this whole namespacing
thing is to basically use the -noprefs flag when launching pd (and
assuming the people you are distributing the patch to have Pd somewhere
in their path which might be a big if, you can send along a shell script
that launches pd with that flag for them) and using [declare] to control
what gets loaded and what paths are added (which actually might be
tricky depending on platform/how their system is set up). And of course
not loading the prefs file affects more than just paths/loading...

So maybe now that I type it out this isn't such a simple idea to
implement haha, but maybe it could be helpful for some use cases...

Derek
-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

edit: [declare] can (and is) also effectively used as a kind of C++ using 
directive or python wildcard import - which is sometimes useful but nonetheless 
eliminates namespacing.

> Gesendet: Samstag, 06. Januar 2018 um 11:53 Uhr
> Von: "Christof Ressi" <christof.re...@gmx.at>
> An: "Alexandre Torres Porres" <por...@gmail.com>
> Cc: Pd-List <pd-list@lists.iem.at>
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> > So this is still safe if you're sharing a patch to be first opened on its 
> > own. 
> 
> in other words: it's not safe at all ;-)
> 
> > And to come back to my first remark here on this thread, if [declare] 
> > cannot always force a priority, shouldn't it?
> 
> I don't think so. [declare]'s job is to add paths to the search path and load 
> libraries. it has nothing to do with namespacing.
> 
> imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. 
> how could you possibly force on or the other with declare?
> 
> namespacing by definition involves some kind of extra typing (like it or not) 
> to differentiate entities that otherwise would look the same. the current 
> mechanism of prepending the folder name already supports that, only 
> single-binary libraries are sometimes a problem. cyclone already shows how 
> this can be dealt with effectivly by adding a second creator (e.g. 
> "cyclone/gate")
>  
> Christof
> 
> Gesendet: Samstag, 06. Januar 2018 um 04:04 Uhr
> Von: "Alexandre Torres Porres" <por...@gmail.com>
> An: Pd-List <pd-list@lists.iem.at>
> Betreff: Re: [PD] declare vs. namespaces - current best practice
> 
> ok, that changes things a bit.
>  
> It is still true that [declare] will prioritize to first load an object from 
> that specified lib (let's call it lib1), even if there's another one (lib2) 
> with the same object listed in the path. But this only happens if none of 
> these objects have been called before.
>  
> So this is still safe if you're sharing a patch to be first opened on its 
> own. 
>  
> Now, things get hard to control if you've forced to load the object from lib2 
> beforehand, then try to load the other one from lib1 without a prefix and 
> trying to rely on [declare]. But this also depends wether it is an 
> abstraction or not, and, as I see it, that is inconsistent behaviour.
>  
> Not only that, but I could also ask wether this is more of an issue on how Pd 
> handles the object search than how [declare] works.
>  
> And to come back to my first remark here on this thread, if [declare] cannot 
> always force a priority, shouldn't it?
>  
> I would assume that's what it had to do.
>  
> cheers
>  
>  
>  
> 2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig 
> <zmoel...@iem.at[mailto:zmoel...@iem.at]>:On 01/05/2018 12:17 AM, Alexandre 
> Torres Porres wrote:
> >
> > The compiled object from the lib listed in the path doesn't get called, and
> > the one specified in [declare] gets called instead.
> >
> 
> repeat the test with two abstractions having loading libraries providing
> the same object.
> e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd
> uses a [gate] stub that prints "gate 2".
> load abs1.pd, after that abs2.pd (either manually, or by putting them
> into a master patch). observe the console.
> 
> fgamdsr
> IOhannes
> 
> 
> 
> ___
> Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>  ___ Pd-list@lists.iem.at mailing 
> list UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

> So this is still safe if you're sharing a patch to be first opened on its 
> own. 

in other words: it's not safe at all ;-)

> And to come back to my first remark here on this thread, if [declare] cannot 
> always force a priority, shouldn't it?

I don't think so. [declare]'s job is to add paths to the search path and load 
libraries. it has nothing to do with namespacing.

imagine you want to use both [foo/obj] and [bar/obj] in the same abstraction. 
how could you possibly force on or the other with declare?

namespacing by definition involves some kind of extra typing (like it or not) 
to differentiate entities that otherwise would look the same. the current 
mechanism of prepending the folder name already supports that, only 
single-binary libraries are sometimes a problem. cyclone already shows how this 
can be dealt with effectivly by adding a second creator (e.g. "cyclone/gate")
 
Christof

Gesendet: Samstag, 06. Januar 2018 um 04:04 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] declare vs. namespaces - current best practice

ok, that changes things a bit.
 
It is still true that [declare] will prioritize to first load an object from 
that specified lib (let's call it lib1), even if there's another one (lib2) 
with the same object listed in the path. But this only happens if none of these 
objects have been called before.
 
So this is still safe if you're sharing a patch to be first opened on its own. 
 
Now, things get hard to control if you've forced to load the object from lib2 
beforehand, then try to load the other one from lib1 without a prefix and 
trying to rely on [declare]. But this also depends wether it is an abstraction 
or not, and, as I see it, that is inconsistent behaviour.
 
Not only that, but I could also ask wether this is more of an issue on how Pd 
handles the object search than how [declare] works.
 
And to come back to my first remark here on this thread, if [declare] cannot 
always force a priority, shouldn't it?
 
I would assume that's what it had to do.
 
cheers
 
 
 
2018-01-04 20:36 GMT-03:00 IOhannes m zmölnig 
<zmoel...@iem.at[mailto:zmoel...@iem.at]>:On 01/05/2018 12:17 AM, Alexandre 
Torres Porres wrote:
>
> The compiled object from the lib listed in the path doesn't get called, and
> the one specified in [declare] gets called instead.
>

repeat the test with two abstractions having loading libraries providing
the same object.
e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd
uses a [gate] stub that prints "gate 2".
load abs1.pd, after that abs2.pd (either manually, or by putting them
into a master patch). observe the console.

fgamdsr
IOhannes



___
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/06/2018 04:04 AM, Alexandre Torres Porres wrote:
> And to come back to my first remark here on this thread, if [declare]
> cannot always force a priority, shouldn't it?

maybe.
it would require a complete rewrite of the the object loading, with a
hierarchical class loading system.
a non-trivial task.

gfamdsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/05/2018 12:36 AM, IOhannes m zmölnig wrote:
> repeat the test with two abstractions having loading libraries providing

this should of course read: "having loading libraring providing".
it's getting late...

gfasmrd
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/05/2018 12:17 AM, Alexandre Torres Porres wrote:
> 
> The compiled object from the lib listed in the path doesn't get called, and
> the one specified in [declare] gets called instead.
> 

repeat the test with two abstractions having loading libraries providing
the same object.
e.g. abs1.pd uses a [gate] stub that prints "gate 1", whereas abs2.pd
uses a [gate] stub that prints "gate 2".
load abs1.pd, after that abs2.pd (either manually, or by putting them
into a master patch). observe the console.

fgamdsr
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

how so? please elaborate...

In my example I had a dummy abstraction in a lib listed in the path, but
declare made it not call it.

are you saying this only happens cause it is an abstraction?

Because I made the test with a compiled object and I got the same
behaviour, no difference!

The compiled object from the lib listed in the path doesn't get called, and
the one specified in [declare] gets called instead.

cheers


2018-01-04 20:03 GMT-03:00 IOhannes m zmölnig :

> On 01/04/2018 11:56 PM, Alexandre Torres Porres wrote:
> > Therefore, using [declare] will avoid name collisions and not the
> opposite.
>
> only for abstractions.
>
> gfadsmr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/04/2018 11:56 PM, Alexandre Torres Porres wrote:
> Therefore, using [declare] will avoid name collisions and not the opposite.

only for abstractions.

gfadsmr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-04 18:41 GMT-03:00, Christof Ressi <christof.re...@gmx.at>:
>> (is there a difference in behaviour between them?)
>
> stdlib is relative to the 'standard paths' whereas path is relative to the
> current patch.
>
> my point is that the user could have their libraries in a totally different
> place so that none of [declare -path/-stdpath/-lib/-stdlib cyclone] will
> work.

I see, but this is kinda parallel, and we're currently discussing
changes to how the path works, as I referred to in the links I sent
before.

What I'm just questioning is wether using [declare] will force and
avoid name collisions. I went ahead and made a test to make sure if
what I said actually happens.

So, I created a dummy abstraction named gate, put it inside a library
that is listed in the path’s preferences, then I took cyclone out of
the listed paths.

Then what happens when I call [gate] is that it finds this dummy
abstraction instead!

Now, what I did next is I added [declare -path cyclone] (no -stdpath)
and [declare] now forces it to find [gate] from cyclone instead.

So, yeah, this is what I said it’d would and should do, so I checked
and it does happen for me.

Therefore, using [declare] will avoid name collisions and not the opposite.

cheers



>
> Gesendet: Donnerstag, 04. Januar 2018 um 22:14 Uhr
> Von: "Alexandre Torres Porres" <por...@gmail.com>
> An: "Christof Ressi" <christof.re...@gmx.at>
> Cc: pd-l...@mail.iem.at
> Betreff: Re: Re: [PD] declare vs. namespaces - current best practice
>
>
> 2018-01-02 12:37 GMT-03:00 Christof Ressi <christof.re...@gmx.at>:
>>
>> what do you mean by [declare cyclone]?
>>
>> in case you mean [declare -stdpath cyclone]:
>
>
> I meant adding a library as path or a lib, either in -stdpath / -path /
> -stdlib / -lib  (is there a difference in behaviour between them?)
>
>>
>> a) this would only work if cyclone is in the user's stdpath (which you
>> can't know as a library writer)
>
>
> why?
>
>>
>> b) it only adds the cyclone folder to the search path. writing [gate] is a
>> gamble because iemlib could be earlier in the search path (or the single
>> binary library could've been loaded).
>>
>>
>> Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
>> Von: "Alexandre Torres Porres" <por...@gmail.com>
>> An: "Christof Ressi" <christof.re...@gmx.at>
>> Cc: "João Pais" <jmmmp...@gmail.com>, pd-l...@mail.iem.at
>> Betreff: Re: [PD] declare vs. namespaces - current best practice
>>
>> questions
>>
>> 2018-01-02 8:02 GMT-03:00 Christof Ressi
>> <christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:Hi, I think in your
>> case you shouldn't need [declare] at all. [declare -stdlib somelib] makes
>> the assumption that 'somelib' is installed in one of Pd's standard paths.
>> This was maybe true for Pd extended where all libraries were in the /extra
>> folder but actually it could be any other folder (which the user added to
>> their search paths).
>>
>> IMHO, best practice is to explicitly list your dependencies and have the
>> user set them up correctly.
>>
>> regarding namespaces:
>>
>> In an abstraction library I would always use them if I can (unfortunately
>> it's not possible with externals which are part of a single binary
>> library). It eliminates the possibility that a wrong abstraction/external
>> is called. My favourite example:
>> Say that for some weird reason you're using [gate] from cyclone. If a
>> users happens to have iemlib earlier in their search path, all your
>> abstractions will have iemlib's [gate] object instead - which works
>> exactly the other way around! This actually happened to a friend of mine
>> :-D.
>>
>> won't [declare cyclone] force a priority of it over iemlib? If not,
>> shouldn't it?
>>
>> now, for related discussions on declare/standard paths,
>> see 
>> https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205]
>> & 
>> https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
>>
>> cheers,
>> happy 2018

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

> (is there a difference in behaviour between them?)

 

stdlib is relative to the 'standard paths' whereas path is relative to the current patch.

 

my point is that the user could have their libraries in a totally different place so that none of [declare -path/-stdpath/-lib/-stdlib cyclone] will work.

 

Gesendet: Donnerstag, 04. Januar 2018 um 22:14 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: pd-l...@mail.iem.at
Betreff: Re: Re: [PD] declare vs. namespaces - current best practice


 
 
2018-01-02 12:37 GMT-03:00 Christof Ressi <christof.re...@gmx.at>:

what do you mean by [declare cyclone]?

in case you mean [declare -stdpath cyclone]:

 

I meant adding a library as path or a lib, either in -stdpath / -path / -stdlib / -lib  (is there a difference in behaviour between them?)

 

a) this would only work if cyclone is in the user's stdpath (which you can't know as a library writer)

 

why?

 

b) it only adds the cyclone folder to the search path. writing [gate] is a gamble because iemlib could be earlier in the search path (or the single binary library could've been loaded).
 

Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: "João Pais" <jmmmp...@gmail.com>, pd-l...@mail.iem.at
Betreff: Re: [PD] declare vs. namespaces - current best practice

questions
 
2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the assumption that 'somelib' is installed in one of Pd's standard paths. This was maybe true for Pd extended where all libraries were in the /extra folder but actually it could be any other folder (which the user added to their search paths).

IMHO, best practice is to explicitly list your dependencies and have the user set them up correctly.

regarding namespaces:

In an abstraction library I would always use them if I can (unfortunately it's not possible with externals which are part of a single binary library). It eliminates the possibility that a wrong abstraction/external is called. My favourite example:
Say that for some weird reason you're using [gate] from cyclone. If a users happens to have iemlib earlier in their search path, all your abstractions will have iemlib's [gate] object instead - which works exactly the other way around! This actually happened to a friend of mine :-D.
 
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't it?
 
now, for related discussions on declare/standard paths, see https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205] & https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
 
cheers,
happy 2018








___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

2018-01-02 12:37 GMT-03:00 Christof Ressi <christof.re...@gmx.at>:

> what do you mean by [declare cyclone]?
>
> in case you mean [declare -stdpath cyclone]:
>

I meant adding a library as path or a lib, either in -stdpath / -path /
-stdlib / -lib  (is there a difference in behaviour between them?)


> a) this would only work if cyclone is in the user's stdpath (which you
> can't know as a library writer)
>

why?


> b) it only adds the cyclone folder to the search path. writing [gate] is a
> gamble because iemlib could be earlier in the search path (or the single
> binary library could've been loaded).
>
>
> Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
> Von: "Alexandre Torres Porres" <por...@gmail.com>
> An: "Christof Ressi" <christof.re...@gmx.at>
> Cc: "João Pais" <jmmmp...@gmail.com>, pd-l...@mail.iem.at
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> questions
>
> 2018-01-02 8:02 GMT-03:00 Christof Ressi <christof.re...@gmx.at[mailto:
> christof.re...@gmx.at]>:Hi, I think in your case you shouldn't need
> [declare] at all. [declare -stdlib somelib] makes the assumption that
> 'somelib' is installed in one of Pd's standard paths. This was maybe true
> for Pd extended where all libraries were in the /extra folder but actually
> it could be any other folder (which the user added to their search paths).
>
> IMHO, best practice is to explicitly list your dependencies and have the
> user set them up correctly.
>
> regarding namespaces:
>
> In an abstraction library I would always use them if I can (unfortunately
> it's not possible with externals which are part of a single binary
> library). It eliminates the possibility that a wrong abstraction/external
> is called. My favourite example:
> Say that for some weird reason you're using [gate] from cyclone. If a
> users happens to have iemlib earlier in their search path, all your
> abstractions will have iemlib's [gate] object instead - which works exactly
> the other way around! This actually happened to a friend of mine :-D.
>
> won't [declare cyclone] force a priority of it over iemlib? If not,
> shouldn't it?
>
> now, for related discussions on declare/standard paths, see
> https://github.com/pure-data/pure-data/pull/205[https:
> //github.com/pure-data/pure-data/pull/205] & https://github.com/pure-
> data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
>
> cheers,
> happy 2018
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[tim vets]

On Jan 3, 2018 10:24 PM, "Derek Kwan"  wrote:

"Christof Ressi"  writes:

>> and usually involves sort of prefixing or suffixing for every
>> abstraction/external.
>
> I've also done this in the past.
> namespacing by prepending the folder name has one advantage, though:
> it provides you the possibility to choose between the long (safe) and
> short (unsafe) name. short names are convenient in rapid prototyping
> while long names are preferable if things ought to be robust.
>
> but after all, it's a matter of taste I guess.
>

Interesting. I suppose this makes me think about more robust and defined
examples of namespacing. Taking python for instance where you can import
modules with shorter names with something like "import numpy as np" so
you can just type "np.array" instead of "numpy.array" each time or you
have the option to dump everything into the  global namespace which is
similar to the situation we have currently of just importing the path or
compiled library wholesale through "from numpy import *".

I'd imagine that implementing a system like this in Pd would be very^999 far
from trivial to implement, cause more confusion to the general end-user
than it's worth it just because users like me don't want to type
[cyclone/*] out every time (and there is already enough confusion about
not being able to instantiate anything in Gem/zexy/cyclone/etc.  even though
they've already installed them onto their computers), and probably break
everything which would be a huge no-no. but it is
interesting to think about =P.

Derek


maybe I'm stretching the topic here, but, how about tab-completion?


--
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Derek Kwan]

"Christof Ressi"  writes:

>> and usually involves sort of prefixing or suffixing for every
>> abstraction/external. 
>
> I've also done this in the past. 
> namespacing by prepending the folder name has one advantage, though:
> it provides you the possibility to choose between the long (safe) and
> short (unsafe) name. short names are convenient in rapid prototyping
> while long names are preferable if things ought to be robust.
>
> but after all, it's a matter of taste I guess.
>

Interesting. I suppose this makes me think about more robust and defined
examples of namespacing. Taking python for instance where you can import
modules with shorter names with something like "import numpy as np" so
you can just type "np.array" instead of "numpy.array" each time or you
have the option to dump everything into the  global namespace which is
similar to the situation we have currently of just importing the path or
compiled library wholesale through "from numpy import *".

I'd imagine that implementing a system like this in Pd would be very^999 far
from trivial to implement, cause more confusion to the general end-user
than it's worth it just because users like me don't want to type
[cyclone/*] out every time (and there is already enough confusion about
not being able to instantiate anything in Gem/zexy/cyclone/etc.  even though
they've already installed them onto their computers), and probably break
everything which would be a huge no-no. but it is
interesting to think about =P.

Derek

-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

> and usually involves sort of prefixing or suffixing for every
> abstraction/external. 

I've also done this in the past. 
namespacing by prepending the folder name has one advantage, though: it 
provides you the possibility to choose between the long (safe) and short 
(unsafe) name. short names are convenient in rapid prototyping while long names 
are preferable if things ought to be robust.

but after all, it's a matter of taste I guess.



> Gesendet: Mittwoch, 03. Januar 2018 um 13:15 Uhr
> Von: "Derek Kwan" <derek.x.k...@gmail.com>
> An: pd-l...@mail.iem.at
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> João Pais <jmmmp...@gmail.com> writes:
> 
> > Dear list,
> >
> > I'm trying to make my abstraction library vanilla-compatible, but
> > nevertheless I need to use some externals. Since I didn't keep up with
> > the vanilla progress the last years, I wanted to ask what is the best
> > method to make sure that all externals are loaded:
> > - use [declare ]?
> > - use namespaces such as [list-abs/list1]?
> 
> To jump into this discussion, I used to be a huge believer in doing the
> [library/object] thing and I still try to do it with libraries that
> aren't of my own creation because yes, there can be name collions and
> it's good to take steps to try to avoid it.
> 
> On the other hand, it is a lot of typing so when I can afford not to
> (usually with my own abstraction/external libraries and with my own
> personal patchese I don't necessarily intend on having other people
> use), I just forego that whole thing and either do a [declare] or just
> import the paths in my preferences.
> 
> One strategy I try to follow with my own libraries and a strategy I have
> seen others follow is to try to make the names as unique as possible
> (which isn't as good as the [library/object] strategy but perhaps good
> enough) and usually involves sort of prefixing or suffixing for every
> abstraction/external. In my case, I usually just prefix dk to everything
> so my bitcrushing abstraction becomes [dkbitcrush~]. Or I've sort of put
> all my list abstractiosn in their own little library so I prefix
> everything with pdkl- (pd + dk + l for list) so my mapping abstraction
> is called [pdkl-map].
> 
> Derek
> 
> -- 
> Derek Kwan
> www.derekxkwan.com
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Derek Kwan]

João Pais  writes:

> Dear list,
>
> I'm trying to make my abstraction library vanilla-compatible, but
> nevertheless I need to use some externals. Since I didn't keep up with
> the vanilla progress the last years, I wanted to ask what is the best
> method to make sure that all externals are loaded:
> - use [declare ]?
> - use namespaces such as [list-abs/list1]?

To jump into this discussion, I used to be a huge believer in doing the
[library/object] thing and I still try to do it with libraries that
aren't of my own creation because yes, there can be name collions and
it's good to take steps to try to avoid it.

On the other hand, it is a lot of typing so when I can afford not to
(usually with my own abstraction/external libraries and with my own
personal patchese I don't necessarily intend on having other people
use), I just forego that whole thing and either do a [declare] or just
import the paths in my preferences.

One strategy I try to follow with my own libraries and a strategy I have
seen others follow is to try to make the names as unique as possible
(which isn't as good as the [library/object] strategy but perhaps good
enough) and usually involves sort of prefixing or suffixing for every
abstraction/external. In my case, I usually just prefix dk to everything
so my bitcrushing abstraction becomes [dkbitcrush~]. Or I've sort of put
all my list abstractiosn in their own little library so I prefix
everything with pdkl- (pd + dk + l for list) so my mapping abstraction
is called [pdkl-map].

Derek

-- 
Derek Kwan
www.derekxkwan.com

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/02/2018 08:50 PM, Lucas Cordiviola wrote:
> I agree with Christof, [foo/obj] not only makes sure that that obj is 

i was talking sepcifically about [list-abs/list-splat].

mgfsard
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Lucas Cordiviola]

I agree with Christof, [foo/obj] not only makes sure that that obj is 
loaded, it also remind you or other one using your patch which library 
comes from and its name to find it in deken.


--

Mensaje telepatico asistido por maquinas.

On 1/2/2018 4:28 PM, Christof Ressi wrote:
>> i find [list-abs/list-splat] to be certainly bad practice.
> but why?
>
> just to be sure: we're talking about use in libraries. IMHO it's better to be 
> extra careful and add the namespace when possible.
>
> to answer Lucas' question about why both [cyclone/!-~] and [!-~] is working:
>
> looking at the source code, it turns out they have been doing exactly what I 
> just proposed: adding a creator with the prepended library name.
>
> just to give another real world example:
> someone writes a library and wants [wrap] from zexy (with the additional 
> second inlet). I'm loading both iemlib and zexy on startup and for some 
> reason iemlib's [wrap] happens to take precedence, breaking the library. the 
> library author doesn't have a chance to force the zexy version.
>
> I think this a big problem - which can be solved by what the cyclone 
> maintainers did. This is not so much important for zexy and iemlib (as they 
> are widely known and a library authors will always try to avoid name clashes 
> with them) but for future libraries. There are so many Pd libraries out there 
> and name clashes are almost guaranteed without some sort of namespacing.
>
>
>> Gesendet: Dienstag, 02. Januar 2018 um 19:53 Uhr
>> Von: "IOhannes m zmölnig" <zmoel...@iem.at>
>> An: pd-list@lists.iem.at
>> Betreff: Re: [PD] declare vs. namespaces - current best practice
>>
>> On 01/02/2018 07:34 PM, Lucas Cordiviola wrote:
>>> Happy 2018 list!!!
>>>
>>> IMO [foo/obj] is the “best practice”.
>> i find [list-abs/list-splat] to be certainly bad practice.
>>
>> i don't think there is one general "best practice" for these kind of
>> things (with the current state of affairs).
>>
>>> I'm having inconsistent results for single-binary libs (iemlib). Some obj 
>>> are working and some not. See pic attached.
>>>
>> because iemlib, even when compiled as a single-binary is *not only* a
>> single binary, but also comes with a number of abstractions.
>>
>> with iemlib and some other libs like zexy, but also Gem (which tries to
>> do that for you by magicking), the "best practice" is to load both the
>> library and add the path and then use the objects without a prefix (aka
>> namespace).
>>
>> fgmrdsa
>> IOhannes
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

> i find [list-abs/list-splat] to be certainly bad practice.

but why?

just to be sure: we're talking about use in libraries. IMHO it's better to be 
extra careful and add the namespace when possible.

to answer Lucas' question about why both [cyclone/!-~] and [!-~] is working:

looking at the source code, it turns out they have been doing exactly what I 
just proposed: adding a creator with the prepended library name.

just to give another real world example:
someone writes a library and wants [wrap] from zexy (with the additional second 
inlet). I'm loading both iemlib and zexy on startup and for some reason 
iemlib's [wrap] happens to take precedence, breaking the library. the library 
author doesn't have a chance to force the zexy version.

I think this a big problem - which can be solved by what the cyclone 
maintainers did. This is not so much important for zexy and iemlib (as they are 
widely known and a library authors will always try to avoid name clashes with 
them) but for future libraries. There are so many Pd libraries out there and 
name clashes are almost guaranteed without some sort of namespacing.


> Gesendet: Dienstag, 02. Januar 2018 um 19:53 Uhr
> Von: "IOhannes m zmölnig" <zmoel...@iem.at>
> An: pd-list@lists.iem.at
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> On 01/02/2018 07:34 PM, Lucas Cordiviola wrote:
> > Happy 2018 list!!!
> > 
> > IMO [foo/obj] is the “best practice”.
> 
> i find [list-abs/list-splat] to be certainly bad practice.
> 
> i don't think there is one general "best practice" for these kind of
> things (with the current state of affairs).
> 
> > I'm having inconsistent results for single-binary libs (iemlib). Some obj 
> > are working and some not. See pic attached.
> > 
> 
> because iemlib, even when compiled as a single-binary is *not only* a
> single binary, but also comes with a number of abstractions.
> 
> with iemlib and some other libs like zexy, but also Gem (which tries to
> do that for you by magicking), the "best practice" is to load both the
> library and add the path and then use the objects without a prefix (aka
> namespace).
> 
> fgmrdsa
> IOhannes
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[IOhannes m zmölnig]

On 01/02/2018 07:34 PM, Lucas Cordiviola wrote:
> Happy 2018 list!!!
> 
> IMO [foo/obj] is the “best practice”.

i find [list-abs/list-splat] to be certainly bad practice.

i don't think there is one general "best practice" for these kind of
things (with the current state of affairs).

> I'm having inconsistent results for single-binary libs (iemlib). Some obj are 
> working and some not. See pic attached.
> 

because iemlib, even when compiled as a single-binary is *not only* a
single binary, but also comes with a number of abstractions.

with iemlib and some other libs like zexy, but also Gem (which tries to
do that for you by magicking), the "best practice" is to load both the
library and add the path and then use the objects without a prefix (aka
namespace).

fgmrdsa
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Lucas Cordiviola]

Happy 2018 list!!!

IMO [foo/obj] is the “best practice”.

@Christof
I'm having inconsistent results for single-binary libs (iemlib). Some obj are 
working and some not. See pic attached.


[pic attached]


--

Mensaje telepatico asistido por maquinas.

On 1/2/2018 1:01 PM, Christof Ressi wrote:

the current situation with namespacing is a bit unsatisfying. let's assume 
there are libraries 'foo' and 'bar' which both have an object called 'obj'. if 
both are multi-binary libraries then both objects can be created with [foo/obj] 
and [bar/obj]. this doesn't work, however, with single-binary libraries. you 
have to write [obj] and if library 'foo' is loaded first, 'obj' from library 
'bar' can never be created.

a solution could be to encourage library writers who favor the single-binary 
style to add creators with the library name prepended, like

obj_class = class_new(gensym("obj"), (t_newmethod)obj_new,
  (t_method)obj_free, sizeof(t_obj), 0, A_GIMME,  0);
class_addcreator((t_newmethod)obj_new, gensym("foo/obj"), A_GIMME, 0);

so users have a chance to deal with possible name collisions.

IOhannes did this in zexy with [zexy/pack] and [zexy/unpack] (for slightly 
different reasons), that's where I got this idea.

having no real namespacing for single-binary libraries is actually a bit crazy, 
given the very generic names of many objects.




Gesendet: Dienstag, 02. Januar 2018 um 16:37 Uhr
Von: "Christof Ressi" <christof.re...@gmx.at><mailto:christof.re...@gmx.at>
An: "Alexandre Torres Porres" <por...@gmail.com><mailto:por...@gmail.com>
Cc: pd-l...@mail.iem.at<mailto:pd-l...@mail.iem.at>
Betreff: Re: [PD] declare vs. namespaces - current best practice

what do you mean by [declare cyclone]?

in case you mean [declare -stdpath cyclone]:
a) this would only work if cyclone is in the user's stdpath (which you can't 
know as a library writer)
b) it only adds the cyclone folder to the search path. writing [gate] is a 
gamble because iemlib could be earlier in the search path (or the single binary 
library could've been loaded).


Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com><mailto:por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at><mailto:christof.re...@gmx.at>
Cc: "João Pais" <jmmmp...@gmail.com><mailto:jmmmp...@gmail.com>, 
pd-l...@mail.iem.at<mailto:pd-l...@mail.iem.at>
Betreff: Re: [PD] declare vs. namespaces - current best practice

questions

2018-01-02 8:02 GMT-03:00 Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]><mailto:christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:Hi,
 I think in your case you shouldn't need [declare] at all. [declare -stdlib 
somelib] makes the assumption that 'somelib' is installed in one of Pd's 
standard paths. This was maybe true for Pd extended where all libraries were in 
the /extra folder but actually it could be any other folder (which the user 
added to their search paths).

IMHO, best practice is to explicitly list your dependencies and have the user 
set them up correctly.

regarding namespaces:

In an abstraction library I would always use them if I can (unfortunately it's 
not possible with externals which are part of a single binary library). It 
eliminates the possibility that a wrong abstraction/external is called. My 
favourite example:
Say that for some weird reason you're using [gate] from cyclone. If a users 
happens to have iemlib earlier in their search path, all your abstractions will 
have iemlib's [gate] object instead - which works exactly the other way around! 
This actually happened to a friend of mine :-D.

won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't 
it?

now, for related discussions on declare/standard paths, see 
https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205]
 & 
https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]

cheers,
happy 2018

___
Pd-list@lists.iem.at<mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at<mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

the current situation with namespacing is a bit unsatisfying. let's assume 
there are libraries 'foo' and 'bar' which both have an object called 'obj'. if 
both are multi-binary libraries then both objects can be created with [foo/obj] 
and [bar/obj]. this doesn't work, however, with single-binary libraries. you 
have to write [obj] and if library 'foo' is loaded first, 'obj' from library 
'bar' can never be created.

a solution could be to encourage library writers who favor the single-binary 
style to add creators with the library name prepended, like

obj_class = class_new(gensym("obj"), (t_newmethod)obj_new,
  (t_method)obj_free, sizeof(t_obj), 0, A_GIMME,  0);
class_addcreator((t_newmethod)obj_new, gensym("foo/obj"), A_GIMME, 0);

so users have a chance to deal with possible name collisions.

IOhannes did this in zexy with [zexy/pack] and [zexy/unpack] (for slightly 
different reasons), that's where I got this idea. 

having no real namespacing for single-binary libraries is actually a bit crazy, 
given the very generic names of many objects. 


> Gesendet: Dienstag, 02. Januar 2018 um 16:37 Uhr
> Von: "Christof Ressi" <christof.re...@gmx.at>
> An: "Alexandre Torres Porres" <por...@gmail.com>
> Cc: pd-l...@mail.iem.at
> Betreff: Re: [PD] declare vs. namespaces - current best practice
>
> what do you mean by [declare cyclone]?
> 
> in case you mean [declare -stdpath cyclone]: 
> a) this would only work if cyclone is in the user's stdpath (which you can't 
> know as a library writer)
> b) it only adds the cyclone folder to the search path. writing [gate] is a 
> gamble because iemlib could be earlier in the search path (or the single 
> binary library could've been loaded).
>  
> 
> Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
> Von: "Alexandre Torres Porres" <por...@gmail.com>
> An: "Christof Ressi" <christof.re...@gmx.at>
> Cc: "João Pais" <jmmmp...@gmail.com>, pd-l...@mail.iem.at
> Betreff: Re: [PD] declare vs. namespaces - current best practice
> 
> questions
>  
> 2018-01-02 8:02 GMT-03:00 Christof Ressi 
> <christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:Hi, I think in your 
> case you shouldn't need [declare] at all. [declare -stdlib somelib] makes the 
> assumption that 'somelib' is installed in one of Pd's standard paths. This 
> was maybe true for Pd extended where all libraries were in the /extra folder 
> but actually it could be any other folder (which the user added to their 
> search paths).
> 
> IMHO, best practice is to explicitly list your dependencies and have the user 
> set them up correctly.
> 
> regarding namespaces:
> 
> In an abstraction library I would always use them if I can (unfortunately 
> it's not possible with externals which are part of a single binary library). 
> It eliminates the possibility that a wrong abstraction/external is called. My 
> favourite example:
> Say that for some weird reason you're using [gate] from cyclone. If a users 
> happens to have iemlib earlier in their search path, all your abstractions 
> will have iemlib's [gate] object instead - which works exactly the other way 
> around! This actually happened to a friend of mine :-D.
>  
> won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't 
> it?
>  
> now, for related discussions on declare/standard paths, see 
> https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205]
>  & 
> https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
>  
> cheers,
> happy 2018
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

what do you mean by [declare cyclone]?

in case you mean [declare -stdpath cyclone]: 
a) this would only work if cyclone is in the user's stdpath (which you can't 
know as a library writer)
b) it only adds the cyclone folder to the search path. writing [gate] is a 
gamble because iemlib could be earlier in the search path (or the single binary 
library could've been loaded).
 

Gesendet: Dienstag, 02. Januar 2018 um 15:58 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: "João Pais" <jmmmp...@gmail.com>, pd-l...@mail.iem.at
Betreff: Re: [PD] declare vs. namespaces - current best practice

questions
 
2018-01-02 8:02 GMT-03:00 Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]>:Hi, I think in your case 
you shouldn't need [declare] at all. [declare -stdlib somelib] makes the 
assumption that 'somelib' is installed in one of Pd's standard paths. This was 
maybe true for Pd extended where all libraries were in the /extra folder but 
actually it could be any other folder (which the user added to their search 
paths).

IMHO, best practice is to explicitly list your dependencies and have the user 
set them up correctly.

regarding namespaces:

In an abstraction library I would always use them if I can (unfortunately it's 
not possible with externals which are part of a single binary library). It 
eliminates the possibility that a wrong abstraction/external is called. My 
favourite example:
Say that for some weird reason you're using [gate] from cyclone. If a users 
happens to have iemlib earlier in their search path, all your abstractions will 
have iemlib's [gate] object instead - which works exactly the other way around! 
This actually happened to a friend of mine :-D.
 
won't [declare cyclone] force a priority of it over iemlib? If not, shouldn't 
it?
 
now, for related discussions on declare/standard paths, see 
https://github.com/pure-data/pure-data/pull/205[https://github.com/pure-data/pure-data/pull/205]
 & 
https://github.com/pure-data/pure-data/pull/183[https://github.com/pure-data/pure-data/pull/183]
 
cheers,
happy 2018

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Alexandre Torres Porres]

questions

2018-01-02 8:02 GMT-03:00 Christof Ressi :

> Hi, I think in your case you shouldn't need [declare] at all. [declare
> -stdlib somelib] makes the assumption that 'somelib' is installed in one of
> Pd's standard paths. This was maybe true for Pd extended where all
> libraries were in the /extra folder but actually it could be any other
> folder (which the user added to their search paths).
>
> IMHO, best practice is to explicitly list your dependencies and have the
> user set them up correctly.
>
> regarding namespaces:
>
> In an abstraction library I would always use them if I can (unfortunately
> it's not possible with externals which are part of a single binary
> library). It eliminates the possibility that a wrong abstraction/external
> is called. My favourite example:
> Say that for some weird reason you're using [gate] from cyclone. If a
> users happens to have iemlib earlier in their search path, all your
> abstractions will have iemlib's [gate] object instead - which works exactly
> the other way around! This actually happened to a friend of mine :-D.
>

won't [declare cyclone] force a priority of it over iemlib? If not,
shouldn't it?

now, for related discussions on declare/standard paths, see
https://github.com/pure-data/pure-data/pull/205 &
https://github.com/pure-data/pure-data/pull/183

cheers,
happy 2018
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] declare vs. namespaces - current best practice

[Christof Ressi]

Hi, I think in your case you shouldn't need [declare] at all. [declare -stdlib 
somelib] makes the assumption that 'somelib' is installed in one of Pd's 
standard paths. This was maybe true for Pd extended where all libraries were in 
the /extra folder but actually it could be any other folder (which the user 
added to their search paths).

IMHO, best practice is to explicitly list your dependencies and have the user 
set them up correctly. 

regarding namespaces:

In an abstraction library I would always use them if I can (unfortunately it's 
not possible with externals which are part of a single binary library). It 
eliminates the possibility that a wrong abstraction/external is called. My 
favourite example:
Say that for some weird reason you're using [gate] from cyclone. If a users 
happens to have iemlib earlier in their search path, all your abstractions will 
have iemlib's [gate] object instead - which works exactly the other way around! 
This actually happened to a friend of mine :-D.

writing [cyclone/gate] has two advantages: 1) better documentation, 2) forces 
the cyclone version to be called and warns if the cyclone version is not found 
(instead of loading another external/abstraction with the same name which 
happens to be in the search path)

Christof



Gesendet: Dienstag, 02. Januar 2018 um 09:54 Uhr
Von: "João Pais" <jmmmp...@gmail.com>
An: pd-l...@mail.iem.at
Betreff: [PD] declare vs. namespaces - current best practice

Dear list,
 I'm trying to make my abstraction library vanilla-compatible, but nevertheless 
I need to use some externals. Since I didn't keep up with the vanilla progress 
the last years, I wanted to ask what is the best method to make sure that all 
externals are loaded:- use [declare ]?- use namespaces such as 
[list-abs/list1]?
 I imagine that for libraries compiled into one external file the best 
alternative is declare, such as with Gem: [declare -stdlib Gem -stdlib zexy]. 
But for cases where the objects are separated, is there a 
conceptual/political/pratical difference between declaring and using namespaces 
in the object name?(I'm used to namespaces so that I know immediately from 
which library the object comes, but I can change that)
 Adding to that: I'm still using mainly Pd-ext, and trying to branch out to 
vanilla and purr-data. Which is the best method to try to be compatible with 
these 3 distributions?E.g. [declare -stdlib Gem -stdlib zexy] works quite well 
on van+ext, but [declare -stdlib iemmatrix] doesn't in pd-ext; I must add a 
[iemmatrix] object to load the library. Is this a iemmatrix bug, or the 
[declare] object from pd-ext is too old?
 
Also: I imagine that there isn't a problem with repeated declarations? Inside 
each abstraction there is a [declare], and a patch can always use lots of them.
 
A suggestion: I can write [declare -stdlib x], and there will be no error 
message warning that the x library doesn't exist. Would it be good to have 
an error message, or even open deken to search for it?
 Best,
 Joao

 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] declare vs. namespaces - current best practice

[João Pais]

Dear list,

I'm trying to make my abstraction library vanilla-compatible, but
nevertheless I need to use some externals. Since I didn't keep up with the
vanilla progress the last years, I wanted to ask what is the best method to
make sure that all externals are loaded:
- use [declare ]?
- use namespaces such as [list-abs/list1]?

I imagine that for libraries compiled into one external file the best
alternative is declare, such as with Gem: [declare -stdlib Gem -stdlib
zexy]. But for cases where the objects are separated, is there a
conceptual/political/pratical difference between declaring and using
namespaces in the object name?
(I'm used to namespaces so that I know immediately from which library the
object comes, but I can change that)

Adding to that: I'm still using mainly Pd-ext, and trying to branch out to
vanilla and purr-data. Which is the best method to try to be compatible
with these 3 distributions?
E.g. [declare -stdlib Gem -stdlib zexy] works quite well on van+ext, but
[declare -stdlib iemmatrix] doesn't in pd-ext; I must add a [iemmatrix]
object to load the library. Is this a iemmatrix bug, or the [declare]
object from pd-ext is too old?

Also: I imagine that there isn't a problem with repeated declarations?
Inside each abstraction there is a [declare], and a patch can always use
lots of them.

A suggestion: I can write [declare -stdlib x], and there will be no
error message warning that the x library doesn't exist. Would it be
good to have an error message, or even open deken to search for it?

Best,

Joao

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list