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
