[PD] array size (was Re: arraysize)

Hans-Christoph Steiner hans at at.or.at
Wed Oct 3 02:24:19 CEST 2012

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.


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 
>>>>>>>> _______________________________________________
>>>>>>>> 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