----- Original Message ----- > From: Ed Kelly <[email protected]> > To: Hans-Christoph Steiner <[email protected]>; Miller Puckette <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Wednesday, October 3, 2012 11:56 PM > Subject: Re: [PD] array size (was Re: arraysize) > > 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.
Did you? > > 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
