[PD] Namespaces (was Re: array size (was Re: arraysize))
Jonathan Wilkes
jancsika at yahoo.com
Wed Oct 3 22:42:10 CEST 2012
When someone decides to implement this, please kill two birds
with one stone by having a look at Tim Blechmann's "bindable
objects" scope from Nova:
http://tim.klingt.org/publications/tim_blechmann_nova.pdf
(2.1.4, p. 16)
In my limited understanding this is _exactly_ the system you
want for namespaces-- that is, if you have [import lib2.0] on
patch foo, and patch foo has abstraction [bar] inside which
there is an [import lib1.0], you want [bar]'s environment to
have lib1.0 and not lib2.0. That's how his bindable object
system works (i.e., scope for send/receive-symbols). He
overloaded the [declare] object in order to achieve this but
it's not necessary to do that-- it could be a completely different
class name in order to implement this functionality, I'm just
saying that at the core of it these two are the same problem.
BTW-- there are two revisions I'd make for his bindable objects
that don't necessarily have to apply to library namespaces:
1) the ability to define a receive-symbol in the scope of an
abstraction class, as opposed to an instance. Example: I want
to send a message inside abstraction [bar] using [s blah] and
have it sent to every "blah" receiver in every extant [bar]
abstraction in this Pd instance.
2) the ability to define a receive-symbol in the scope of a
libdir. Example: I want to send a message inside abstraction [bar]
(which belongs to library "somelib") using [s blah] and have it sent to
every "blah" receiver in every extant object that is part of the
"somelib" library. A real world example is your GLOBAL_PDDP_DSP_STATUS
thing in PDDP (which doesn't actually work because you can't query the
current dsp status).
Both #1/#2 are doable using iemguts (plus maybe a few other externals) OR
my canvas get patch. I can make a demo patch for the latter if you'd like.
-Jonathan
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Miller Puckette <msp at ucsd.edu>
> Cc: pd-list at iem.at
> Sent: Wednesday, October 3, 2012 2:45 PM
> Subject: Re: [PD] array size (was Re: arraysize)
>
>
> For the hip~ problem, I'm fine with just fixing it in 0.44, leaving it
> as hip~, and being done with it. I agree with Jonathan: the default
> behavior should be the non-buggy behavior.
>
> The issue I am addressing is the -pre-0.44-hip idea and other ideas for
> providing backwards compatibility. Namespaces provide a nice, clean
> technique for doing this, on top of other advantages. And if we
> implement them right, people will only need to know about them if then
> need to do advanced things like running a patch in 0.44 while using a
> 0.42 compatibility mode.
>
> Most users are just going to see the [import] or [declare] statement in
> a patch. I think that's proven to be a much more newbie-friendly way to
> load external libraries than command line flags, especially on Mac and
> Windows.
>
> Namespaces are part of general programming, and are essential unless you
> are willing to greatly limit the domain the language is used for. I
> think we can implement namespaces that are simple and Pdish. I think
> we're close. Even C requires the use of a crufty form of namespaces.
> Try writing a C program without a single #include.
A few questions:
patch foo has [import lib2.0] on it as well as abstraction [foo]. Inside [foo]
>
> .hc
>
> On 10/02/2012 08:33 PM, Miller Puckette wrote:
>> Right, the two demands I'm trying to reconcile are keeping the name
>> hip~ (so that old patches remain comprehensible) and yet making hip~
>> work correctly -- it's a bug fix. Seems to me one ought to be able to
> fix
>> bugs without diving into library version confusion.
>>
>> I think namespaces are very useful to expert programmers but are likely to
>> be confusing to many Pd users -- and its not that much of a necessity if
>> indeed c (in which Pd and linux are implemented) didn't need to have
>> them.
>>
>> cheers
>> Miller
>>
>> On Tue, Oct 02, 2012 at 08:24:19PM -0400, Hans-Christoph Steiner wrote:
>>> If you think that's the preferrable approach, then shouldn't it
> be
>>> [newhip~]? One thing libc did not do is break backwards compatibility
>>> of functions. I think the libc example is a better approach than the
>>> -pre-0.44-hip flag or the aliasing to work around the existing versions
>>> of [pow].
>>>
>>> My central point is that Pd should have a fully functioning namespace
>>> like modern languages do (C++, Obj-C, Java, Python, Ruby, Lua, Haskell,
>>> etc. etc.) That's one lesson that we've learned from C. Part
> of that
>>> is having a standard library that can be overridden. Then if people
>>> want to have old versions of the standard library, they can easily be
>>> accomodated by adding the version number to the name of the library.
>>>
>>> .hc
>>>
>>> On 10/02/2012 07:02 PM, Miller Puckette wrote:
>>>> The libc way is just to have one libc and kludge your way through
>>>> compatibility problems. For instance, seek() had to be replaced
> with lseek(),
>>>> gets and fgets were left with not-quite-the-same behavior, errno
> was
>>>> magically adapted to become a macro that grabbed a thread variable
> when
>>>> threads appeared, etc. It's not pretty but way preferable to
> having
>>>> several versions of libc - what a nightmare that would have been.
>>>>
>>>> cheers
>>>> Miller
>>>>
>>>> On Tue, Oct 02, 2012 at 06:48:46PM -0400, Hans-Christoph Steiner
> wrote:
>>>>> Is the static variable you are talking about the "static
> t_class"
>>>>> declaration in the class C files?
>>>>>
>>>>> What's the libc way?
>>>>>
>>>>> The -pre-0.44-hip way would be easy to implement, but it has a
> number of
>>>>> problems:
>>>>>
>>>>> - there will be many flags like this, -pre-0.42-pow, etc. etc.
>>>>>
>>>>> - there will be no way to specify in the patch that it should
> use a
>>>>> specific version of hip~, pow~, etc. That adds complexity to
> the patch
>>>>> setups since each patch will need an accompanying script for
> launching
>>>>> Pd properly and means Pd programmers have to learn non-Pd
> things like
>>>>> scripting to do this.
>>>>>
>>>>> .hc
>>>>>
>>>>> On 10/02/2012 06:39 PM, Miller Puckette wrote:
>>>>>> Actually I think my previous post was wrong - what I was
> unable to do was
>>>>>> get different sets of static variables for dlopen() - ing
> the _same file
>>>>>> twice_ -- which isn't what we're talking about
> here.
>>>>>>
>>>>>> But still, I think the libc way is much simpler and likely
> to be much more
>>>>>> robust.
>>>>>>
>>>>>> cheers
>>>>>> M
>>>>>>
>>>>>> On Tue, Oct 02, 2012 at 06:13:32PM -0400, Hans-Christoph
> Steiner wrote:
>>>>>>> Since Pd manually loads the libraries (.pd_linux), it
> can also manually
>>>>>>> map a given function address to the s_thing in the
> symbol table. There
>>>>>>> is no need to load the symbols in a .pd_linux in the
> sense of a public
>>>>>>> shared library, and therefore no nameclashes. Pd could
> get the address
>>>>>>> of the new() function using dlsym() and store that
> wherever. This is
>>>>>>> already happening for the setup() function, so we can
> do the same thing
>>>>>>> to map the new() function to a symbol..
>>>>>>>
>>>>>>> So for example, pd could map the new() function to the
> fully qualified
>>>>>>> name in the symbol table, i.e
> "vanilla-0.42.5/hip~", then only in the
>>>>>>> canvas_local namespace would the symbol
> "hip~" be mapped to the new()
>>>>>>> function.
>>>>>>>
>>>>>>> .hc
>>>>>>>
>>>>>>> On 10/02/2012 05:09 PM, Miller Puckette wrote:
>>>>>>>> I'm not sure that any of the Windows, MaacOS,
> and linux dynamic loading
>>>>>>>> systems will support having multiple versions of a
> library loaded in the
>>>>>>>> same address space. But here's a simpler way
> anyhow: libraries such as
>>>>>>>> vanilla could maintain compatibility by querying
> the version number of
>>>>>>>> the patch at run time.
>>>>>>>>
>>>>>>>> In the case of hip~ I'm genuinely not sure
> whether the "correct" behavior
>>>>>>>> would then be to revert to the old behavior for all
> old patches or only on
>>>>>>>> request. The confusing scenario I worry about is
> that you have a patch with
>>>>>>>> an old hip~ object in it, save it from 0.44, and
> then have it switch to the
>>>>>>>> new behavior next time it's loaded.
>>>>>>>>
>>>>>>>> I think I have found ad hoc ways to fix the other
> problems without breaking
>>>>>>>> old patches.
>>>>>>>>
>>>>>>>> cheers
>>>>>>>> Miller
>>>>>>>>
>>>>>>>> n Tue, Oct 02, 2012 at 11:36:47AM -0400,
> Hans-Christoph Steiner wrote:
>>>>>>>>> I think having a compatibility version stamp in
> the patch is a good
>>>>>>>>> idea. This ties in well with the experiments
> I've been doing with
>>>>>>>>> splitting out all of the objects from pd
> itself. If all of the core
>>>>>>>>> objects are a standard library, then that means
> its easy to choose which
>>>>>>>>> version of the standard library that a patch is
> using. In Pd-extended,
>>>>>>>>> this is called the 'vanilla' lib, and
> its been included in some form
>>>>>>>>> since 0.42.
>>>>>>>>>
>>>>>>>>> Then if a patch has a compatibility version
> stamp in it, Pd can
>>>>>>>>> automatically look to see if it has a copy of
> that version of the
>>>>>>>>> standard library, and load it. Otherwise, it
> would load the version
>>>>>>>>> closest to that, and throw a warning, or
> optionally that could be
>>>>>>>>> considered an error.
>>>>>>>>>
>>>>>>>>> To make this work well, the key missing feature
> is the ability to change
>>>>>>>>> which loaded library an object name maps to in
> the canvas-local
>>>>>>>>> namespace. Currently, once an object name is
> mapped to a loaded
>>>>>>>>> .pd_linux, that is a global association. This
> is needed so that patches
>>>>>>>>> using different standard libs can be open at
> the same time.
>>>>>>>>>
>>>>>>>>> Then making the versioned standard libs would
> be pretty easy, mostly
>>>>>>>>> just bundling the right .c files into a lib.
>>>>>>>>>
>>>>>>>>> .hc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 10/02/2012 11:15 AM, Miller Puckette wrote:
>>>>>>>>>> This is in my long-range plan but
> hasn't yet risen to the level of "urgent".
>>>>>>>>>> However, this migth be a good moment to get
> started on this because several
>>>>>>>>>> other backward- and even
> forward-imcompatible needs are also rising to the
>>>>>>>>>> fore:
>>>>>>>>>>
>>>>>>>>>> 1. there's a bug in hip~ - its DC gain
> is slightly (and possibly considerably)
>>>>>>>>>> greater than 1. "fixing" this
> will change the audio output of older patches,
>>>>>>>>>> usually much too slightly to matter, but
> there will have to b a "-pre-0.44-hip"
>>>>>>>>>> flag or something to allow strict back
> compatibility;
>>>>>>>>>>
>>>>>>>>>> 2. There's no place in the pre-0.43
> file format to alow specifying individual
>>>>>>>>>> box widths and font sizes; I put an
> "f" (=format) message to the canvas
>>>>>>>>>> object in 0.43 so that in 0.44 I can make
> it set font size and box width and
>>>>>>>>>> perhaps leave an opening for other
> formatting info.
>>>>>>>>>>
>>>>>>>>>> 3. the upsampling inlet~ by default
> zero-pads its input. This is incorrect as
>>>>>>>>>> its DC gain is less than one. (Try using
> that as input to a phasor~ for
>>>>>>>>>> instance - bad surprise!) I want to change
> the default so that it acts like
>>>>>>>>>> a sample-and-hold, which I believe is an
> option now. To preserve back
>>>>>>>>>> compatibility I'd keep all the
> "upsampling methods" in place but only change
>>>>>>>>>> default behavior for patches with a 0.44 or
> later version stamped on them.
>>>>>>>>>>
>>>>>>>>>> Each of these presents a different spin on
> the age-old issue of keeping
>>>>>>>>>> total back compatibility in place, even
> when the compatibility is to preserve
>>>>>>>>>> a big as in (1) and (3) - and arguably in
> the file searching too; I'm not sure
>>>>>>>>>> whether to regard that as a bug or just
> over-hasty design.
>>>>>>>>>>
>>>>>>>>>> cheers
>>>>>>>>>> Miller
>>>>>>>>>>
>>>>>>>>>>> Here's a good sketch of the
> idea
>>>>>>>>>>>
> (http://puredata.info/dev/PdSearchPath):
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Proposed Functionality
>>>>>>>>>>>
>>>>>>>>>>> for path in paths do -- the core
> does this bit
>>>>>>>>>>> for loader in loaders do
>>>>>>>>>>> loader(path, library, object)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Existing Functionality
>>>>>>>>>>>
>>>>>>>>>>> for loader in loaders do
>>>>>>>>>>> for path in paths do -- the loader
> does this bit
>>>>>>>>>>> loader(path, library, object)
>>>>>>>>>>>
>>>>>>>>>>> .hc
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
> _______________________________________________
>>>>>>>>>>> Pd-list at iem.at mailing list
>>>>>>>>>>> UNSUBSCRIBE and account-management
> -> http://lists.puredata.info/listinfo/pd-list
>>>>>>>>> _______________________________________________
>>>>>>>>> Pd-list at iem.at mailing list
>>>>>>>>> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
More information about the Pd-list
mailing list