On 09/27/2012 10:02 AM, Lorenzo Sutton wrote:

On 27/09/12 15:13, IOhannes m zmoelnig wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

last night hans and me finally setup a replacement machine for apt.puredata.info[1], the ultimate source for Pd-extended on Debian-based systems (Debian, Ubuntu, Linux/Mint,...)[2].

it is now hosted on the puredata.info portal/mailinglist server, courtesy of iem.

Wow cool, Thanks! Lorenzo

The aim is to have packages for all Debian/Ubuntu/Mint releases in both i386 and and amd64 (i.e. 32-bit and 64-bit), then hopefully some other architectures for Debian (armel, armhf, etc).

.hc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

IMHO, arraysize is very useful because it has a memorable name. "I need to find the size of an array... oh, [arraysize]".

.hc

On 09/27/2012 02:13 PM, Jonathan Wilkes wrote:

Please change the description for the package "pd-arraysize"

"This object is deprecated. Use [expr size("array-name")] which works out of the box for Pd Extended, Pd Vanilla, and Pd-l2ork."

-Jonathan

----- Original Message -----

...

From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-announce@iem.at Cc: Sent: Thursday, September 27, 2012 9:13 AM Subject: [PD] [PD-announce] apt.puredata.info is back!

last night hans and me finally setup a replacement machine for apt.puredata.info[1], the ultimate source for Pd-extended on Debian-based systems (Debian, Ubuntu, Li fgmasdfnux/Mint,...)[2].

it is now hosted on the puredata.info portal/mailinglist server, courtesy of iem.

fgmasdf IOhannes

[1] http://apt.puredata.info/ [2] http://puredata.info/docs/faq/debian

...

---

Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce

---

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

If someone wants to write patches that work on vanilla anywhere, then there is a point. If people are already using Pd-extended or Debian then I honestly don't see the point, arraysize is already there, like many other externals.

For me, apt-get install pd-arraysize is far easier than trying to remember that [expr] trick. And thankfully we can write externals, so we can have choice. :-)

.hc

On 09/27/2012 03:00 PM, Jonathan Wilkes wrote:

That feature comes at the expense of compatibility, which normally wouldn't be an issue _except_ that Pd Vanilla already has the same functionality. So let's encourage use of the more compatible way using [expr], which is clearly documented and supports the _exact_ same features as arraysize.

-Jonathan

...

---

From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Sent: Thursday, September 27, 2012 2:24 PM Subject: Re: [PD] [PD-announce] apt.puredata.info is back!

IMHO, arraysize is very useful because it has a memorable name. "I

...

need to find the size of an array... oh, [arraysize]".

.hc

On 09/27/2012 02:13 PM, Jonathan Wilkes wrote:

...

...

...

Please change the description for the package "pd-arraysize"

"This object is deprecated. Use [expr size("array-name")] which works out of the box for Pd Extended, Pd Vanilla, and Pd-l2ork."

-Jonathan

----- Original Message -----

...

From: IOhannes m zmoelnig zmoelnig@iem.at To: pd-announce@iem.at Cc: Sent: Thursday, September 27, 2012 9:13 AM Subject: [PD] [PD-announce] apt.puredata.info is back!

last night hans and me finally setup a replacement machine

for

...

...

apt.puredata.info[1], the ultimate source for Pd-extended on Debian-based systems (Debian, Ubuntu, Li fgmasdfnux/Mint,...)[2].

it is now hosted on the puredata.info portal/mailinglist

server,

...

...

courtesy of iem.

fgmasdf IOhannes

[1] http://apt.puredata.info/ [2] http://puredata.info/docs/faq/debian

...

---

Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce

---

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

...

Sorry to further complicate this -

I'm now trying to design a multipurpose object "array" for pd vanilla that would allow one to say [array size] and use "table" or "data structure" arrays intercahngeably.

I think though, that rather than marking arraysize as "obsolete" one could simply note that it has an equivalent available in Pd vanilla - that need carry no value judgement as to whether people should be using vanilla or extended.

cheers M

On Thu, Sep 27, 2012 at 12:23:35PM -0700, Jonathan Wilkes wrote:

...

---

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, September 27, 2012 3:03 PM Subject: arraysize WAS apt.puredata.info is back!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

If someone wants to write patches that work on vanilla anywhere,

    then there is a point.

_Everybody_ wants to write patches that work on vanilla everywhere.

When we can't we try to figure out a course of action, but when we can (without employing wild hacks) we should.

...

If people are already using Pd-extended or

    Debian then I honestly don't see the point, arraysize is already     there, like many other externals.

It's like you wrote above.  People _do_ want patches to be as cross-platform as possible. (Not if.)

...

For me, apt-get install pd-arraysize is far easier than trying to

    remember that [expr] trick.  And thankfully we can write externals,     so we can have choice. :-)

If it were a wild hack I'd agree, but it's not.  It is a standard operator for [expr] that's been there for ages and is clearly documented.

And who is this mythical user that looks to the Debian repositories to figure out how to do something in a programming language? (Hm, I'm not getting audio output, let's open up Synaptic and search 20,000 mostly non-related packages for a solution...)

-Jonathan

...

.hc

On 09/27/2012 03:00 PM, Jonathan Wilkes wrote:

...

That feature comes at the expense of compatibility, which normally wouldn't be an issue _except_ that Pd Vanilla already has the same functionality. So let's

      encourage

...

...

use of the more compatible way using [expr], which is clearly documented and supports the _exact_ same features as arraysize.

-Jonathan

...

---

From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Sent: Thursday, September 27, 2012 2:24 PM Subject: Re: [PD] [PD-announce] apt.puredata.info is

      back!

...

...

...

IMHO, arraysize is very useful because it has a memorable

      name. "I

...

...

...

need to find the size of an array... oh, [arraysize]".

.hc

On 09/27/2012 02:13 PM, Jonathan Wilkes wrote:

...

...

...

Please change the description for the package "pd-arraysize"

"This object is deprecated. Use [expr

      size("array-name")]

...

...

...

...

...

which works out of the box for Pd Extended, Pd

      Vanilla,

...

...

...

...

...

and Pd-l2ork."

-Jonathan

----- Original Message ----- > From: IOhannes m zmoelnig zmoelnig@iem.at > To: pd-announce@iem.at > Cc: > Sent: Thursday, September 27, 2012 9:13 AM > Subject: [PD] [PD-announce]

      apt.puredata.info is back!

...

...

...

...

...

> last night hans and me finally setup a

      replacement machine

...

...

...

for

...

...

apt.puredata.info[1], the ultimate source for

      Pd-extended on

...

...

...

...

...

Debian-based systems (Debian, Ubuntu, Li fgmasdfnux/Mint,...)[2].

it is now hosted on the puredata.info

      portal/mailinglist

...

...

...

server,

...

...

courtesy of iem.

fgmasdf IOhannes

[1] http://apt.puredata.info/ [2] http://puredata.info/docs/faq/debian > > >

      _______________________________________________

...

...

...

...

...

> Pd-announce mailing list > Pd-announce@iem.at > http://lists.puredata.info/listinfo/pd-announce > >

      _______________________________________________

...

...

...

...

...

> 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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCAAGBQJQZKLqAAoJEJ8P5Yc3S76BpMwP/ipER+0Af2ZQ+ruexNeN0KUq /giclGGz9Gg7yUmKYcrW369ko9UqRXmxQGAY2HHbBUWuWo6lWQ2XD+RKEVkUN9lz w78S/gXb28FHzyiiRAtibL6Q2pYtyb8VebUW+iiLTtWnkzjbIKO6iPE3lsIsSYzK x4y6cwTRNYcWM7UO7Ja0DpZie7/sAgkUNYlCMwzfugFZRZ91bW9Xf9rNovxZu9lH py7mVFJ9iUI2h6Nyzpvdvp95ukfDneQK4JgmbXLWEdYhMGZd2uokeLgsohfP89Sf e60Pv1s9YuiarA1MBBudm15egWHLbhLVU1vb3VH4uOpZXh3Uf5u3z/luo73T+udx RzInWh0Su0WSmnWYU4yABo+F0eFAGNDH+AxdEdtxsKm0X3AP7RFZaqUmdut96NE9 NMMd7UKytG8zKs+a6hCOLqqL/DrBxpYmwrxAhPNRd8hMA+WmWxISyhrBoHsgOjb+ oHIccb6xUVmg5wafyuQMqTaPtTtDt2y3DCyb4gcOGEoHTXJcztA7nd2RYGnf0eZ5 0jfix5ykyP/Wau4dlyNT4J569BgS0XQkZw0RlP2mIAJose6pGpDtKpwvzSEZrleE i6ZvCbC3NGzfY4HFhS6XcXzXWDTmHFLb17gvQNyzjQwKTgvzxJ58YEswUTM5LXVD Q8VO11kW70gDLmPU/GnL =uAcd -----END PGP SIGNATURE-----

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On Thu, Sep 27, 2012 at 01:42:51PM -0700, Jonathan Wilkes wrote:

...

---

From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at Sent: Thursday, September 27, 2012 3:59 PM Subject: Re: [PD] arraysize WAS apt.puredata.info is back!

Sorry to further complicate this -

I'm now trying to design a multipurpose object "array" for pd vanilla that would allow one to say [array size] and use "table" or "data structure" arrays intercahngeably.

Interesting.  Will this allow a data structure array to be used by [tab*~] objects?  That's one thing that would make ds arrays very valuable (think of all the queries to the list about how to get different colored arrays, for example) but I never figured out an easy way to do it.

BTW, I've got a patch somewhere that did mouseover/mouseout notifications to [struct] but I can't seem to find it now.  I also tried outputting pointer x/y location with "click" events to [struct] but couldn't get it working right for GOP stuff.

-Jonathan

Yeah, I'm hoping to completely unify arrays in structs with "table" arrays - wish me luck :)

Good idea about the mouseovers - I think Pd is doing all teh work anyhow so it should be made available. The whole data thing needs lots and lots more thinking.

cheers Miller

Sounds like a good complication :). I think a general array toolkit would be very useful. I'm not a fan of expanding the use of Tcl syntax in Pd tho (i.e. commands with subcommands).

Pd syntax is nice and simple with always the first word being the command and the rest being the args. [list ...] is the only except to this that I can think of, and certainly the only exception included in pd-vanilla.

How about just naming them like [tabsize], [tabfoo], etc since there already are lots of [tab...] objects. Or anything to minimize the confusion between the 'array', 'table', and 'tab*' objects. Since there is [table] and [tab*], the menu item Put -> Array could be renamed to "Put visual table (array)" or something like that, then the word table/tab would be pretty consistent throughout Pd.

It may seem trivial, but I've spent a lot of time explaining why the objects for reading arrays all start with 'tab'.

.hc

On 09/27/2012 03:59 PM, Miller Puckette wrote:

Sorry to further complicate this -

I'm now trying to design a multipurpose object "array" for pd vanilla that would allow one to say [array size] and use "table" or "data structure" arrays intercahngeably.

I think though, that rather than marking arraysize as "obsolete" one could simply note that it has an equivalent available in Pd vanilla - that need carry no value judgement as to whether people should be using vanilla or extended.

cheers M

On Thu, Sep 27, 2012 at 12:23:35PM -0700, Jonathan Wilkes wrote:

...

...

---

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, September 27, 2012 3:03 PM Subject: arraysize WAS apt.puredata.info is back!

If someone wants to write patches that work on vanilla anywhere,

...

...

then there is a point.

_Everybody_ wants to write patches that work on vanilla everywhere.

When we can't we try to figure out a course of action, but when we can (without employing wild hacks) we should.

If people are already using Pd-extended or

...

...

Debian then I honestly don't see the point, arraysize is already there, like many other externals.

It's like you wrote above. People _do_ want patches to be as

cross-platform

...

...

as possible. (Not if.)

For me, apt-get install pd-arraysize is far easier than trying to

...

...

remember that [expr] trick. And thankfully we can write externals, so we can have choice. :-)

If it were a wild hack I'd agree, but it's not. It is a standard

operator for

...

...

[expr] that's been there for ages and is clearly documented.

And who is this mythical user that looks to the Debian repositories to figure out how to do something in a programming language? (Hm, I'm not getting audio output, let's open up Synaptic and search 20,000 mostly non-related packages for a solution...)

-Jonathan

.hc

On 09/27/2012 03:00 PM, Jonathan Wilkes wrote:

...

...

...

...

That feature comes at the expense of compatibility, which normally wouldn't be an issue _except_ that Pd Vanilla already has the same functionality. So let's

encourage

...

...

use of the more compatible way using [expr], which is clearly documented and supports the _exact_ same features as arraysize.

-Jonathan

...

---

From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Sent: Thursday, September 27, 2012 2:24 PM Subject: Re: [PD] [PD-announce] apt.puredata.info is

back!

...

...

...

IMHO, arraysize is very useful because it has a memorable

name. "I

...

...

...

need to find the size of an array... oh, [arraysize]".

.hc

On 09/27/2012 02:13 PM, Jonathan Wilkes wrote:

...

>> Please change the description for the package >> "pd-arraysize" >> >> "This object is deprecated. Use [expr

size("array-name")]

...

...

...

>> which works out of the box for Pd Extended, Pd

Vanilla,

...

...

...

>> and Pd-l2ork." >> >> -Jonathan >> >> >> >> ----- Original Message ----- >>> From: IOhannes m zmoelnig zmoelnig@iem.at >>> To: pd-announce@iem.at >>> Cc: >>> Sent: Thursday, September 27, 2012 9:13 AM >>> Subject: [PD] [PD-announce]

apt.puredata.info is back!

...

...

...

>>> >> last night hans and me finally setup a

replacement machine

...

...

...

for >> apt.puredata.info[1], the ultimate source for

Pd-extended on

...

...

...

>> Debian-based systems (Debian, Ubuntu, Li >> fgmasdfnux/Mint,...)[2]. >> >> it is now hosted on the puredata.info

portal/mailinglist

...

...

...

server, >> courtesy of iem. >> >> fgmasdf >> IOhannes >> >> >> >> [1] http://apt.puredata.info/ >> [2] http://puredata.info/docs/faq/debian >>> >>> >>>

---

...

...

...

>>> Pd-announce mailing list >>> Pd-announce@iem.at >>> http://lists.puredata.info/listinfo/pd-announce >>> >>>

---

...

...

...

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

----- Original Message -----

From: Miller Puckette msp@ucsd.edu To: Hans-Christoph Steiner hans@at.or.at Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, September 27, 2012 8:01 PM Subject: Re: [PD] arraysize WAS apt.puredata.info is back!

Hmm... I agree there's bad confusion between array and table in Pd nomenclature.  I've tried to use "table" for a specifically floating-point array, and "array" for the more general thing, but I think I've been less than consistent (case in point, the "array" menu which creates what I would call a "table".

One idea might be to use the name [tab] instead of [array], as in [tab size] - then [tabwrite] could get a synonym, [tab write], etc.

This is also mixed up in my trying to design a new [text] that would replace and vastly extend [textfile] - so the three multifarious object names would then be [list] [tab]/[array] and [text].

The [table] object could be vastly extended: [table foo] would be equivalent to [tab define foo] and you could say for instance, [tab define foo -struct my-struct -save -range 0 100]

If you're not requiring the user to name the array "z" and requiring "z" to have a float field "y" then you would need

[tab define foo -struct my-struct -array z -y y]

where "-y" defines which field to use as the independent variable in the table (similar to "-y" in [plot]).

(But, oops, that use of 'tab' would really be what I've been tring to use 'array' for in that it would presumably not be an array of floats.)

Too much to think about... that's why it takes so many years to get the thing written...

cheers Miller

On Thu, Sep 27, 2012 at 06:19:40PM -0400, Hans-Christoph Steiner wrote:

...

Sounds like a good complication :).  I think a general array toolkit would be very useful.  I'm not a fan of expanding the use of Tcl syntax in Pd tho (i.e. commands with subcommands).

Pd syntax is nice and simple with always the first word being the command and the rest being the args.  [list ...] is the only except to this that I can think of, and certainly the only exception included in pd-vanilla.

How about just naming them like [tabsize], [tabfoo], etc since there already are lots of [tab...] objects.  Or anything to minimize the confusion between the 'array', 'table', and 'tab*'

objects.  Since there

...

is [table] and [tab*], the menu item Put -> Array could be renamed to "Put visual table (array)" or something like that, then the word table/tab would be pretty consistent throughout Pd.

It may seem trivial, but I've spent a lot of time explaining why the objects for reading arrays all start with 'tab'.

.hc

On 09/27/2012 03:59 PM, Miller Puckette wrote:

...

Sorry to further complicate this -

I'm now trying to design a multipurpose object "array"

for pd

...

...

vanilla that would allow one to say [array size] and use

"table" or

...

...

"data structure" arrays intercahngeably.

I think though, that rather than marking arraysize as

"obsolete" one

...

...

could simply note that it has an equivalent available in Pd vanilla - that need carry no value judgement as to whether people should be

using

...

...

vanilla or extended.

cheers M

On Thu, Sep 27, 2012 at 12:23:35PM -0700, Jonathan Wilkes wrote:

...

...

---

From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Thursday, September 27, 2012 3:03 PM Subject: arraysize WAS apt.puredata.info is back!

If someone wants to write patches that work on vanilla anywhere,

...

...

then there is a point.

_Everybody_ wants to write patches that work on vanilla

everywhere.

...

...

...

...

When we can't we try to figure out a course of action,

but when we

...

...

...

...

can (without employing wild hacks) we should.

If people are already using Pd-extended or

...

...

Debian then I honestly don't see the point, arraysize is

already

...

...

...

...

there, like many other externals.

It's like you wrote above. People _do_ want patches to be

as

...

cross-platform

...

...

...

as possible. (Not if.)

For me, apt-get install pd-arraysize is far easier than trying to

...

...

remember that [expr] trick. And thankfully we can write

externals,

...

...

...

...

so we can have choice. :-)

If it were a wild hack I'd agree, but it's not. It is

a standard

...

operator for

...

...

...

[expr] that's been there for ages and is clearly

documented.

...

...

...

...

And who is this mythical user that looks to the Debian

repositories

...

...

...

...

to figure out how to do something in a programming language? (Hm, I'm not getting audio output, let's open up

Synaptic and search

...

...

...

...

20,000 mostly non-related packages for a solution...)

-Jonathan

.hc

On 09/27/2012 03:00 PM, Jonathan Wilkes wrote:

...

...

...

> That feature comes at the expense of compatibility,

which

...

...

...

...

...

> normally wouldn't be an issue _except_ that Pd > Vanilla already has the same functionality. So

let's

...

...

...

...

encourage

...

> use of the more compatible way using [expr], which is > clearly documented and supports the _exact_ same

features

...

...

...

...

...

> as arraysize. > > -Jonathan > > > > >> ________________________________ >> From: Hans-Christoph Steiner

hans@at.or.at

...

...

...

...

...

>> To: pd-list@iem.at >> Sent: Thursday, September 27, 2012 2:24 PM >> Subject: Re: [PD] [PD-announce] apt.puredata.info

is

...

...

...

...

back!

...

>> >> >> > > IMHO, arraysize is very useful because it has a

memorable

...

...

...

...

name. "I

...

>> need to find the size of an array... oh,

[arraysize]".

...

...

...

...

...

> > .hc > > On 09/27/2012 02:13 PM, Jonathan Wilkes wrote: >>>> Please change the description for the

package

...

...

...

...

...

>>>> "pd-arraysize" >>>> >>>> "This object is deprecated. Use

[expr

...

...

...

...

size("array-name")]

...

>>>> which works out of the box for Pd

Extended, Pd

...

...

...

...

Vanilla,

...

>>>> and Pd-l2ork." >>>> >>>> -Jonathan >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: IOhannes m zmoelnig

zmoelnig@iem.at

...

...

...

...

...

>>>>> To: pd-announce@iem.at >>>>> Cc: >>>>> Sent: Thursday, September 27, 2012

9:13 AM

...

...

...

...

...

>>>>> Subject: [PD] [PD-announce]

apt.puredata.info is back!

...

>>>>> >>>> last night hans and me finally setup a

replacement machine

...

>> for >>>> apt.puredata.info[1], the ultimate source

for

...

...

...

...

Pd-extended on

...

>>>> Debian-based systems (Debian, Ubuntu, Li >>>> fgmasdfnux/Mint,...)[2]. >>>> >>>> it is now hosted on the puredata.info

portal/mailinglist

...

>> server, >>>> courtesy of iem. >>>> >>>> fgmasdf >>>> IOhannes >>>> >>>> >>>> >>>> [1] http://apt.puredata.info/ >>>> [2] http://puredata.info/docs/faq/debian >>>>> >>>>> >>>>>

---

...

>>>>> Pd-announce mailing list >>>>> Pd-announce@iem.at >>>>>

http://lists.puredata.info/listinfo/pd-announce

...

...

...

...

...

>>>>> >>>>>

---

...

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

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

----- Original Message -----

From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at Sent: Thursday, September 27, 2012 10:27 PM Subject: Re: [PD] arraysize WAS apt.puredata.info is back!

...

...

The [table] object could be vastly extended: [table foo] would be

equivalent

...

...

to [tab define foo] and you could say for instance, [tab define foo -struct my-struct -save -range 0 100]

If you're not requiring the user to name the array "z" and

requiring

...

"z" to have a float field "y" then you would need

[tab define foo -struct my-struct -array z -y y

where "-y" defines which field to use as the independent variable in the table (similar to "-y" in [plot]).

I'm thinking in the above that foo would be an array of items of my-structs, not a struct with an array such as 'z' inside it.

In that case would [tab write foo] take an index number in the right inlet and a list of field values in the left?

Another way of invoking tab would allow you to attach a name temporarily or permanently to an array within a struct (provided via a pointer message). Then indeed you'd need the field name such as 'z'.

cheers M

On 09/28/2012 02:01 AM, Miller Puckette wrote:

Hmm... I agree there's bad confusion between array and table in Pd nomenclature. I've tried to use "table" for a specifically floating-point array, and "array" for the more general thing, but I think I've been less than consistent (case in point, the "array" menu which creates what I would call a "table".

One idea might be to use the name [tab] instead of [array], as in [tab size] - then [tabwrite] could get a synonym, [tab write], etc.

i'm quite with hans here: what exactly do we gain from having an object [tab write], instead of [tabwrite]? and i totally fail to see how [tab size] is superior to [tabsize].

in terms of remembering the names, they see quite on par; it is made clear that those objects belong to the same family regardless of whether the prefix is "tab" "tab " or "tab_", as long as there is a common short prefix; in terms of typing there is one more character to type; and from the implementation side, it needlessly compilates the object-lookup mechanism, as can be seen in the current implementation of the "list" family of objects (where the objectcreator is made aware of an object named "list\ size", but this object is practically never requested from the objectmaker, and instead the constructor function of "list" has to re-implement the dispatching.

it's not that "foo bar" is bad by itself; i just don't see that it is anywhere better than what we already have.

fgmasdr IOhannes

Well, I'm persuadable on this front. I'm concerned with unduly hogging the object namespace - in general, every time I add an object name I potentially introduce incompatiblities with someone's abstraction that might have the same name. And there are 50 or so new classes (!) to provide. I don't even have a list yet (no pun intended)

cheers M

On Fri, Sep 28, 2012 at 10:01:40AM -0400, Hans-Christoph Steiner wrote:

On 09/28/2012 04:00 AM, IOhannes m zmölnig wrote:

...

On 09/28/2012 02:01 AM, Miller Puckette wrote:

...

Hmm... I agree there's bad confusion between array and table in Pd nomenclature. I've tried to use "table" for a specifically floating-point array, and "array" for the more general thing, but I think I've been less than consistent (case in point, the "array" menu which creates what I would call a "table".

One idea might be to use the name [tab] instead of [array], as in [tab size] - then [tabwrite] could get a synonym, [tab write], etc.

i'm quite with hans here: what exactly do we gain from having an object [tab write], instead of [tabwrite]? and i totally fail to see how [tab size] is superior to [tabsize].

in terms of remembering the names, they see quite on par; it is made clear that those objects belong to the same family regardless of whether the prefix is "tab" "tab " or "tab_", as long as there is a common short prefix; in terms of typing there is one more character to type; and from the implementation side, it needlessly compilates the object-lookup mechanism, as can be seen in the current implementation of the "list" family of objects (where the objectcreator is made aware of an object named "list\ size", but this object is practically never requested from the objectmaker, and instead the constructor function of "list" has to re-implement the dispatching.

it's not that "foo bar" is bad by itself; i just don't see that it is anywhere better than what we already have.

And to hammer on this point some more, this subcommand syntax complicates the implementation, as IOhannes points out, and complicates the syntax. Its very nice to be able to say "Pd syntax is like sentences where the first word is the command and the rest of the words are data for that command." For all the newbies that I have taught from all sorts of realms, from 10 year olds to practicing architects, this is something that has really quickly clicked with basically everyone. In my intro teaching, I avoid [list] for exactly this reason, because I'd have to explain the exception to this simple "first word is the command" rule, and some people are always confused by it.

And from an advanced users point of view, the simpler the rules of the syntax are, the brain space is taken up managing all of the exceptions to nice, simple rules. And that means less brain space for far more interesting things.

.hc

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 09/28/2012 11:43 AM, Claude Heiland-Allen wrote:

On 28/09/12 16:23, Miller Puckette wrote:

...

Well, I'm persuadable on this front. I'm concerned with unduly hogging the object namespace - in general, every time I add an object name I potentially introduce incompatiblities with someone's abstraction that might have the same name. And there are 50 or so new classes (!) to provide. I don't even have a list yet (no pun intended)

Perhaps it would be better to refactor the object / abstraction / binary / loading / namespace mechanism first, something along the lines of an old discussion I had with HCS:

http://claudiusmaximus.goto10.org/cm/2010-07-16_pure-data_libraries_conversa...

Once that is fixed to something less baroque/crufty then it should be easier for everyone to go nuts and have their own namespaces without clobbering or hogging anything, and make patches more portable between Pd variants.

I have no time to work on this for the forseeable future, but it's something that needs doing sooner rather than later...

I totally agree with this. I think the easiest place to start would be to rework the load order, so that instead of going by file type, it goes by directory. Right now, the load order first looks for .pd_linux files in every dir in the path, then looks for .pd files in every dir in the path.

Instead it should start by searching or .pd_linux and .pd in the patch's own dir, then .pd_linux and .pd the canvas-local path, then .pd_linux and .pd in the global path, then .pd_linux and .pd in the built-in path.

Currently, if you don't know that there is a 'foo.pd_linux' installed in your path, and your project folder includes 'foo.pd', your project will always load 'foo.pd_linux'.

.hc

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

in regards to (3), would there have ever been a case where someone would have deliberately used the zero padding of upsampled inlet as a 'feature' that their patch depended on????

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

But there's the trickier problem that static variables would be shared across all the versions - avan if you can somehow not get different functions ala sighip_setup() with the same names not to step all over each other (I'm not convinced that's possible).

Somehow the c library (libc) and the math library (libm) manage to exist on only one version - I think that's a modle we should try to follow here.

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

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

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

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

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

For the hip~ problem, I'm fine with just fixing it in 0.44, leaving it as hip~, and being done with it. I agree with Jonathan: the default behavior should be the non-buggy behavior.

The issue I am addressing is the -pre-0.44-hip idea and other ideas for providing backwards compatibility. Namespaces provide a nice, clean technique for doing this, on top of other advantages. And if we implement them right, people will only need to know about them if then need to do advanced things like running a patch in 0.44 while using a 0.42 compatibility mode.

Most users are just going to see the [import] or [declare] statement in a patch. I think that's proven to be a much more newbie-friendly way to load external libraries than command line flags, especially on Mac and Windows.

Namespaces are part of general programming, and are essential unless you are willing to greatly limit the domain the language is used for. I think we can implement namespaces that are simple and Pdish. I think we're close. Even C requires the use of a crufty form of namespaces. Try writing a C program without a single #include.

.hc

On 10/02/2012 08:33 PM, Miller Puckette wrote:

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

I think you can't fix a bug in a core object and retain complete backwards compatibility in terms of the audio result of old patches, unless you implement a "pre-0.44 mode" or something. But why would you want to do that? Perhaps a method can be used to switch between the two modes in hip~, but that might introduce a small overhead.

I think the integrity of the objects in terms of what they should do is more important than total backwards compatibilty - old patches will still load, but they may not sound _exactly_ the same. Personally I'd like hip~ to do highpass filtering properly, and so my expectation when I invoke hip~ is that it will do exactly that. Having a patch that "works like this but I don't know why" is a bad thing. I'd be sure to find the tiny DC component a nuisance at some point.

Ed

For the hip~ problem, I'm fine with just fixing it in 0.44, leaving it as hip~, and being done with it.  I agree with Jonathan: the default behavior should be the non-buggy behavior.

The issue I am addressing is the -pre-0.44-hip idea and other ideas for providing backwards compatibility.  Namespaces provide a nice, clean technique for doing this, on top of other advantages.  And if we implement them right, people will only need to know about them if then need to do advanced things like running a patch in 0.44 while using a 0.42 compatibility mode.

Most users are just going to see the [import] or [declare] statement in a patch.  I think that's proven to be a much more newbie-friendly way to load external libraries than command line flags, especially on Mac and Windows.

Namespaces are part of general programming, and are essential unless you are willing to greatly limit the domain the language is used for.  I think we can implement namespaces that are simple and Pdish.  I think we're close.  Even C requires the use of a crufty form of namespaces. Try writing a C program without a single #include.

.hc

On 10/02/2012 08:33 PM, Miller Puckette wrote:

...

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