<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1443041410138_6105">And a question to make sure I understand what you're proposing:</div><div id="yui_3_16_0_1_1443041410138_6146"><br></div><div id="yui_3_16_0_1_1443041410138_6106" dir="ltr">Inside "foo.pd", I have a single object [bar]</div><div id="yui_3_16_0_1_1443041410138_6107" dir="ltr"><br></div><div id="yui_3_16_0_1_1443041410138_6115" dir="ltr">"foo.pd" lives in directory /home/blah</div><div id="yui_3_16_0_1_1443041410138_6147" dir="ltr"><br></div><div id="yui_3_16_0_1_1443041410138_6182" dir="ltr">The only other file in /home/blah is "bar.pd"</div><div id="yui_3_16_0_1_1443041410138_6183" dir="ltr"><br></div><div id="yui_3_16_0_1_1443041410138_6221" dir="ltr">Under your revision of the loading mechanism, when I load "foo.pd" is [bar] guaranteed to be loaded from /home/blah/bar.pd ?</div><div id="yui_3_16_0_1_1443041410138_6224" dir="ltr"><br></div><div id="yui_3_16_0_1_1443041410138_6223" dir="ltr">-Jonathan<br></div><div id="yui_3_16_0_1_1443041410138_6108" dir="ltr"><br></div><div id="yui_3_16_0_1_1443041410138_6109"><span></span></div> <br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font face="Arial" size="2"> On Wednesday, September 23, 2015 5:05 PM, Jonathan Wilkes <jancsika@yahoo.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container"><div id="yiv6026572884"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yiv6026572884yui_3_16_0_1_1443041410138_3480">Oh man, I was absolutely dreading addressing all that loading mess, so I'm excited to see you're tackling it.</div><div id="yiv6026572884yui_3_16_0_1_1443041410138_3450"><br clear="none"></div><div id="yiv6026572884yui_3_16_0_1_1443041410138_3416">Question:</div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3415">what does it mean to "tag" an objectname with "abstraction"?</div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3449"><br clear="none"></div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3481">Another question:</div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3519">How were you planning to implement canvas-local loading? (Or did you have a plan in mind?)</div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3606"><br clear="none"></div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3607">-Jonathan<br clear="none"></div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3518"><br clear="none"></div><div dir="ltr" id="yiv6026572884yui_3_16_0_1_1443041410138_3517"><br clear="none"></div><div id="yiv6026572884yui_3_16_0_1_1443041410138_3345"><span></span></div> <br clear="none"><div class="yiv6026572884qtdSeparateBR"><br clear="none"><br clear="none"></div><div class="yiv6026572884yahoo_quoted" style="display:block;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div class="yiv6026572884yqt5459578024" id="yiv6026572884yqtfd73887"><div dir="ltr"> <font face="Arial" size="2"> On Wednesday, September 23, 2015 4:20 PM, IOhannes m zmölnig <zmoelnig@iem.at> wrote:<br clear="none"> </font> </div> <br clear="none"><br clear="none"> <div class="yiv6026572884y_msg_container">hi miller et all,<br clear="none"><br clear="none">the current implementation of Pd's loading mechanism works as follows:<br clear="none"><br clear="none">- each registered loader is asked whether they can handle a given<br clear="none">objectclass<br clear="none">- each loader in turn searches the entire (canvas-enhanced) path for<br clear="none">files matching their pattern (eg.g. "*.pd_linux", or "*.pd_lua")<br clear="none">- if all fails, Pd searches the entire (canvas-enhanced) path for<br clear="none">abstractions.<br clear="none"><br clear="none">e.g.<br clear="none"> /A/x.pd_linux<br clear="none"> /B/x.pd_linux<br clear="none"> /C/x.pd_linux<br clear="none"> /A/x.pd_lua<br clear="none"> /B/x.pd_lua<br clear="none"> /C/x.pd_lua<br clear="none"> /A/x.pd<br clear="none"> /B/x.pd<br clear="none"> /C/x.pd<br clear="none"><br clear="none"><br clear="none">this has a number of disadvantages, mainly:<br clear="none"><br clear="none">- the associated loader has a higher priority then the path.<br clear="none">this means that it is nigh¹ impossible to override a binary external<br clear="none">(e.g. "*.pd_darwin") installed system-wide (e.g. in extra/) with a<br clear="none">user-provided alternative (e.g. a pd_lua implementation in the current<br clear="none">patch path).<br clear="none"><br clear="none">- abstractions (arguably the most used external classes) have an extra<br clear="none">load time penalty, since each time a new (abstraction-provided) object<br clear="none">is created, Pd will first search the entire path for binaries,<br clear="none">lua-scripts and what not.<br clear="none"><br clear="none"><br clear="none">iirc, this has been discussed at length, and the proper solution for<br clear="none">this is to change the loading mechanism, so that paths have a higher<br clear="none">that loaders:<br clear="none">Pd shall iterate over each search-path and ask the loaders whether there<br clear="none">is something for them in there.<br clear="none"><br clear="none">this way an abstraction in a "-path" enhanced searchpath is always found<br clear="none">early in the search, AND it can shadow an external in a later search path.<br clear="none"><br clear="none">e.g.<br clear="none"> /A/x.pd_linux<br clear="none"> /A/x.pd_lua<br clear="none"> /A/x.pd<br clear="none"> /B/x.pd_linux<br clear="none"> /B/x.pd_lua<br clear="none"> /B/x.pd<br clear="none"> /C/x.pd_linux<br clear="none"> /C/x.pd_lua<br clear="none"> /C/x.pd<br clear="none"><br clear="none"><br clear="none"><br clear="none">so i have taken the liberty and implement that (i'll submit the patches<br clear="none">in a second).<br clear="none"><br clear="none">here's a few observations:<br clear="none"><br clear="none">compatibility with legacy loaders<br clear="none">===<br clear="none">the new implementation needs an API that tells the loaders where they<br clear="none">should look for.<br clear="none">rather than create a new API, i used the existing one and enhanced the<br clear="none">callback function with a new argument <path>, so we now have:<br clear="none"> int loader_callback(t_canvas*c, char*name, char*path);<br clear="none"><br clear="none">the good thing about this is that it is actually backward compatible (at<br clear="none">least with sane calling conventions, as on my tested linux system).<br clear="none">legacy loaders will simply ignore the <path> argument, and continue to<br clear="none">search their files in the entire path.<br clear="none">this will result in an overall performance degredation (while loading<br clear="none">objects), as the legacy loaders will call the entire search path for<br clear="none">each element in the search path :-(<br clear="none">the good news is that:<br clear="none">- the legacy loaders will continue to work!<br clear="none">- the performance degredation will only happen if legacy loaders are<br clear="none">involved.<br clear="none">- the performance degredation will be at *load time*, so should not be<br clear="none">too important<br clear="none">- there are only very few (known) loaders, so they should be fixed in no<br clear="none">time<br clear="none"><br clear="none"><br clear="none">abstraction loading<br clear="none">===<br clear="none">one big change is that abstractions are now loaded via a proper "loader"<br clear="none">(rather than via some special handling as fallback)<br clear="none">this implies that whenever the abstraction-loader wins (that is, a given<br clear="none">objectname can first be resolved via an abstraction), this objectname is<br clear="none">tagged as "abstraction".<br clear="none">when another object of the same name is created, the loader competition<br clear="none">will not take place any more, and instead the object will be loaded<br clear="none">immediately as "abstraction" (the current implementation then still<br clear="none">searches the entire path for the .pd file)<br clear="none">this has two side effects:<br clear="none">- until now it was possible to replace "future instances" of an<br clear="none">abstraction-object with externals.<br clear="none">e.g. imagine that [foo] is resolved via ~/pd-externals/foo.pd. if<br clear="none">someone installs a foo.pd_linux into ~/pd-externals/ during the Pd<br clear="none">session, then the next time someone creates [foo] it will be the external!<br clear="none">whether you like that behaviour or not, my implementation prevents it<br clear="none">(however it is still possible to change the actual abstraction; e.g. if<br clear="none">[foo] is resolved via /usr/lib/pd/extra/foo.pd and somebody saves a<br clear="none">foo.pd into ~/pd-externals/, then the next time someone creates [foo] it<br clear="none">will be the abstraction in ~/pd-externals/!)<br clear="none">- since this means that we don't need to search the entire path for<br clear="none">externals (that have not been there when we looked a second ago)<br clear="none">whenever we create another instance of our abstraction, patches<br clear="none">generally load faster (esp. when an abstraction is used often).<br clear="none">the speedup is not tremendous, about 3x; but still...<br clear="none"><br clear="none"><br clear="none">canvas path iterator<br clear="none">===<br clear="none">to ease the implementation (and to avoid code duplication), i introduced<br clear="none">an iterator, that will call a callback function for each searchpath of a<br clear="none">canvas.<br clear="none">this is now also used in canvas_open(), but might be useful elsewhere.<br clear="none"><br clear="none"><br clear="none">interactive use of declare<br clear="none">===<br clear="none">as a side effect (and not strictly related to the loading problem), i<br clear="none">fixed [declare] so that creating a [declare -path foo] would allow you<br clear="none">to *immediately* use the foo/ path.<br clear="none">i always found it *very* annoying that you had to close/open the<br clear="none">abstraction for [declare] to have an effect.<br clear="none">(this functionality is disabled while the patch is currently /loading/)<br clear="none"><br clear="none"><br clear="none">not done<br clear="none">===<br clear="none">what i wanted to do as well, but haven't gotten around was proper<br clear="none">canvas-local library loading, so you could do [declare -lib<br clear="none">foo/bla]+[bla] in one abstraction and [declare -lib moo/bla]+[bla] in<br clear="none">another abstraction and the two [bla] objectclasses would refer to<br clear="none">different externals.<br clear="none"><br clear="none"><br clear="none"><br clear="none">hmm, that mail is already quite long. and i have forgotten what else i<br clear="none">wanted to say.<br clear="none"><br clear="none">in any case, i would like to hear your opinion on all this.<br clear="none"><br clear="none">in the meantime i'll submit the 4 patches of this implementation to the<br clear="none">sf tracker.<br clear="none"><br clear="none">gfamds<br clear="none">IOhannes<br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none"><br clear="none">¹ ah well, for certain use-cases one could disable the standard<br clear="none">searchpaths altogether; not.<br clear="none"><br clear="none">_______________________________________________<br clear="none">Pd-dev mailing list<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:Pd-dev@lists.iem.at" target="_blank" href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a><br clear="none"><a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-dev">http://lists.puredata.info/listinfo/pd-dev</a><br clear="none"><br clear="none"><br clear="none"></div> </div></div><div class="yiv6026572884yqt5459578024" id="yiv6026572884yqtfd16001"> </div></div><div class="yiv6026572884yqt5459578024" id="yiv6026572884yqtfd98339"> </div></div></div></div></div><br><br></div> </div> </div> </div></div></body></html>