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 <[email protected]> > To: Miller Puckette <[email protected]> > Cc: [email protected] > 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > _______________________________________________ >>>>>>>>>>> [email protected] mailing list >>>>>>>>>>> UNSUBSCRIBE and account-management > -> http://lists.puredata.info/listinfo/pd-list >>>>>>>>> _______________________________________________ >>>>>>>>> [email protected] mailing list >>>>>>>>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
