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! _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list