But there's the trickier problem that static variables would be shared across all the versions - avan if you can somehow not get different functions ala sighip_setup() with the same names not to step all over each other (I'm not convinced that's possible).
Somehow the c library (libc) and the math library (libm) manage to exist on only one version - I think that's a modle we should try to follow here. 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
