[PD] array size (was Re: arraysize)
Jonathan Wilkes
jancsika at yahoo.com
Wed Oct 3 17:43:04 CEST 2012
----- Original Message -----
> From: Miller Puckette <msp at ucsd.edu>
> To: Cyrille Henry <ch at chnry.net>
> Cc: pd-list at iem.at
> Sent: Wednesday, October 3, 2012 11:03 AM
> Subject: Re: [PD] array size (was Re: arraysize)
>
> Problem is, it's a bug - I want to fix it :)
Please allow the users that
want non-buggy behavior to get non-buggy behavior
automatically, and require the other set to s/hip~/hip-pre-0.44~/ or
whatever the name will be (and I'm assuming you're going to continue
to support both versions).
-Jonathan
>
> M
>
> On Wed, Oct 03, 2012 at 11:44:47AM +0200, Cyrille Henry wrote:
>> 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
>> >
>>
>> _______________________________________________
>> 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