OK, when I run into it again I'll let you know. Usually this happens in workshops, where other things need to get fixed first ;-)
d. Hans-Christoph Steiner wrote: > > Please file bug reports if you can't load abstractions that way. I > think there is one specific case where help patches don't load then, but > I don't remember off hand what it was. A bug report for that would also > be quite helpful. > > .hc > > On Apr 8, 2008, at 11:37 AM, Derek Holzer wrote: >> But this way doesn't load abstractions and help patches, AFAIK. >> >> d. >> >> Hans-Christoph Steiner wrote: >>> This is only the case on 0.40 and newer. [import] on 0.39 loads into >>> the global namespace. This stuff is currently alpha and not >>> complete, so it is not very clear. I think for the manual, the best >>> bet for Pd-extended is to use the [library/objectclass] format for >>> objectclasses that aren't loaded by default. That has been supported >>> by every version of Pd for a long time now (as long as you install >>> the libraries that way). >>> .hc >>> On Apr 8, 2008, at 9:22 AM, marius schebella wrote: >>>> as far as I understood [import] is the same as [declare -lib] and that >>>> only adds a library to the local namespace of a patch. see the help >>>> file >>>> for declare that comes with 0.41. >>>> you can declare your library relative to pd [declare -stdlib] or >>>> relative to the patch [declare -lib], but - as mentioned in the >>>> helpfile >>>> - the name stdpath is confusing!]. >>>> it is also not 100% clear, how this works in abstractions and if the >>>> behaviour will be consistent with future pd versions. >>>> there might be a chance that [import] really adds to the global >>>> namespace, but I don't think so. (otoh I don't know how to add >>>> something >>>> to the global namespace.) >>>> the idea was that you can use a certain objectclass in one patch and >>>> another one with the same name (but from another lib) in another patch. >>>> please correct me, if I'm wrong. >>>> marius. >>>> >>>> Derek Holzer wrote: >>>>> Hi all, >>>>> >>>>> it seems that the ways of dealing with externals and paths is >>>>> always in >>>>> flux! I would like to confirm a suspicion that, for the time being, >>>>> the >>>>> following works the way I think it does, assuming PD 0.39: >>>>> >>>>> [library/object] imports that specific object into global >>>>> namespace, and >>>>> can accommodate different objects with the same name from different >>>>> libs. This method does not allow access to help patches or >>>>> abstractions >>>>> in the library path. >>>>> >>>>> [import library] imports the whole library into global namespace, >>>>> including help patches and other abs (usually, although I have often >>>>> found this broken in Extended). It cannot accommodate different >>>>> objects >>>>> with the same name from different libs, as the last library imported >>>>> will have priority. >>>>> >>>>> Is this correct so far? Has anyone documented this any more >>>>> substantially anywhere? How does this change for 0.40? >>>>> >>>>> best! >>>>> d. >>>> >>>> >>>> _______________________________________________ >>>> PD-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>> ---------------------------------------------------------------------------- >>> >>> Computer science is no more related to the computer than astronomy is >>> related to the telescope. -Edsger Dykstra >> >> -- >> derek holzer ::: http://www.umatic.nl ::: >> http://blog.myspace.com/macumbista >> ---Oblique Strategy # 39: >> "Cut a vital connection" > > > > ---------------------------------------------------------------------------- > > > ¡El pueblo unido jamás será vencido! > > > -- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 72: "Find a safe part and use it as an anchor" _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list