----- Original Message ----- > From: Miller Puckette <[email protected]> > To: Cyrille Henry <[email protected]> > Cc: [email protected] > Sent: Wednesday, October 3, 2012 11:03 AM > Subject: Re: [PD] array size (was Re: arraysize) > > Problem is, it's a bug - I want to fix it :) Please allow the users that want non-buggy behavior to get non-buggy behavior automatically, and require the other set to s/hip~/hip-pre-0.44~/ or whatever the name will be (and I'm assuming you're going to continue to support both versions). -Jonathan
> > M > > On Wed, Oct 03, 2012 at 11:44:47AM +0200, Cyrille Henry wrote: >> hello, >> >> since externals can override internals, why not leaving hip~ untouched, and > providing a corrected hip~ that is installed in pd/extra/0.44 >> one can just remove path > 0.43 it pd preference (or even using start-up > flag) to have the old hip~, or keeping path untouched to have latest version > of > pd objects. >> >> cheers >> c >> >> >> Le 03/10/2012 02:33, Miller Puckette a écrit : >> >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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
