[PD] import vs namespace
Derek Holzer
derek at umatic.nl
Tue Apr 8 17:45:35 CEST 2008
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 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!
>
>
>
--
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 72:
"Find a safe part and use it as an anchor"
More information about the Pd-list
mailing list