Problem is, it's a bug - I want to fix it :) 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
