[PD] array size (was Re: arraysize)

Cyrille Henry ch at chnry.net
Wed Oct 3 11:44:47 CEST 2012 

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