I think you can't fix a bug in a core object and retain complete backwards compatibility in terms of the audio result of old patches, unless you implement a "pre-0.44 mode" or something. But why would you want to do that? Perhaps a method can be used to switch between the two modes in hip~, but that might introduce a small overhead.
I think the integrity of the objects in terms of what they should do is more important than total backwards compatibilty - old patches will still load, but they may not sound _exactly_ the same. Personally I'd like hip~ to do highpass filtering properly, and so my expectation when I invoke hip~ is that it will do exactly that. Having a patch that "works like this but I don't know why" is a bad thing. I'd be sure to find the tiny DC component a nuisance at some point. Ed >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. > >.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
