<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-01-06 13:35 GMT-03:00 Lucas Cordiviola <span dir="ltr"><<a href="mailto:lucarda27@hotmail.com" target="_blank">lucarda27@hotmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I steel believe that the “best practice” is [foo/obj]. At least for<br>
sharing patches. At home or with live-patching is another story.<br></blockquote><div><br></div><div>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...</div><div><br></div><div>so +1 for namespaces</div><div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>cheers </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The only things that needs to get fixed are some single binary libs. To<br>
put some random example some objects on iemlib already work with<br>
[iemlib/obj] and others don't.<br>
<br>
Makes me think that if zexy and iemlib (and other single binary) support<br>
[foo/obj] every thing will be under control.<br>
<br>
I'm not a Gem user so I don't know if it has potential name clashes<br>
<span class="im HOEnZb"><br>
<br>
<br>
--<br>
<br>
Mensaje telepatico asistido por maquinas.<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 1/6/2018 10:41 AM, Christof Ressi wrote:<br>
>> (which actually might be tricky depending on platform/how their system is set up).<br>
> 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.<br>
><br>
> and again:<br>
><br>
>>> imagine you want to use both [foo/obj] and [bar/obj] in the same<br>
>>> abstraction. how could you possibly force on or the other with<br>
>>> declare?<br>
><br>
>> Gesendet: Samstag, 06. Januar 2018 um 12:53 Uhr<br>
>> Von: "Derek Kwan" <<a href="mailto:derek.x.kwan@gmail.com">derek.x.kwan@gmail.com</a>><br>
>> An: "Alexandre Torres Porres" <<a href="mailto:porres@gmail.com">porres@gmail.com</a>><br>
>> Cc: "Christof Ressi" <<a href="mailto:christof.ressi@gmx.at">christof.ressi@gmx.at</a>>, Pd-List <<a href="mailto:pd-list@lists.iem.at">pd-list@lists.iem.at</a>><br>
>> Betreff: Re: [PD] declare vs. namespaces - current best practice<br>
>><br>
>><br>
>>>> And to come back to my first remark here on this thread, if<br>
>>>> [declare] cannot always force a priority, shouldn't it?<br>
>>> I don't think so. [declare]'s job is to add paths to the search path<br>
>>> and load libraries. it has nothing to do with namespacing.<br>
>>><br>
>>> imagine you want to use both [foo/obj] and [bar/obj] in the same<br>
>>> abstraction. how could you possibly force on or the other with<br>
>>> declare?<br>
>>><br>
>> Well, I suppose one way of forcing the use of cyclone's gate without<br>
>> typing out the entire thing and dealing with this whole namespacing<br>
>> thing is to basically use the -noprefs flag when launching pd (and<br>
>> assuming the people you are distributing the patch to have Pd somewhere<br>
>> in their path which might be a big if, you can send along a shell script<br>
>> that launches pd with that flag for them) and using [declare] to control<br>
>> what gets loaded and what paths are added (which actually might be<br>
>> tricky depending on platform/how their system is set up). And of course<br>
>> not loading the prefs file affects more than just paths/loading...<br>
>><br>
>> So maybe now that I type it out this isn't such a simple idea to<br>
>> implement haha, but maybe it could be helpful for some use cases...<br>
>><br>
>> Derek<br>
>> --<br>
>> Derek Kwan<br>
>> <a href="http://www.derekxkwan.com" rel="noreferrer" target="_blank">www.derekxkwan.com</a><br>
>><br>
> ______________________________<wbr>_________________<br>
> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
<br>
______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div></div>