[PD] array size (was Re: arraysize)

[Hans-Christoph Steiner]

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