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:
- 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.or.at To: Miller Puckette msp@ucsd.edu Cc: pd-list@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@iem.at mailing list >>>>> UNSUBSCRIBE and account-management
-> http://lists.puredata.info/listinfo/pd-list
>>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list