[PD] import vs namespace

Hans-Christoph Steiner hans at eds.org
Tue Apr 8 17:40:13 CEST 2008


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 at 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!






More information about the Pd-list mailing list