----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Cyrille Henry ch@chnry.net Cc: pd-list@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@iem.at mailing list >>>>>>>>>>UNSUBSCRIBE and account-management
-> http://lists.puredata.info/listinfo/pd-list
>>> _______________________________________________
>>>>>>>>Pd-list@iem.at mailing list >>>>>>>>UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>> > >_______________________________________________ >Pd-list@iem.at mailing list >UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list