[PD] array size (was Re: arraysize)

Miller Puckette msp at ucsd.edu
Wed Oct 3 00:28:49 CEST 2012


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 
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Pd-list at iem.at mailing list
> >>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>
> >> _______________________________________________
> >> Pd-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 



More information about the Pd-list mailing list