hi all, hi IOhannes
after having installed pd 0.42.0test5, i assumed to have discovered a behaviour change of [unpack] and [pack], until i noticed:
a) zexy comes with its own version of [pack] and [unpack]. why are they called the same? i really don't get that.
b) in pd 0.42.0test5 they seem to override the built-in classes. is this a bug? if yes, pd's or zexy's?
c) the zexy versions can explicitly be called by using the 'zexy/' prefix. how is that possible, although zexy was compiled as multi class library? is that _the_ solution to have multiclass libs and separate namespaces at the same time?
it's definitely not backwards compatibility safe to replace all built-in [pack]/[unpack] by the zexy versions, since the zexy versions reads the 'f' and 's' literally and thus some patches produce lots of errors (due to inlets receiving 'f' instead of '0', for instance).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
hm.. only now, i see that overriding built-ins seems to be intentional. when starting pd with loading zexy, i get:
warning: class 'pack' overwritten; old one renamed 'pack_aliased' warning: class 'unpack' overwritten; old one renamed 'unpack_aliased'
and pd's built-in [pack] can be instantiated with [pack_aliased]
?????????
roman
On Tue, 2008-11-04 at 21:42 +0100, Roman Haefeli wrote:
hi all, hi IOhannes
after having installed pd 0.42.0test5, i assumed to have discovered a behaviour change of [unpack] and [pack], until i noticed:
a) zexy comes with its own version of [pack] and [unpack]. why are they called the same? i really don't get that.
b) in pd 0.42.0test5 they seem to override the built-in classes. is this a bug? if yes, pd's or zexy's?
c) the zexy versions can explicitly be called by using the 'zexy/' prefix. how is that possible, although zexy was compiled as multi class library? is that _the_ solution to have multiclass libs and separate namespaces at the same time?
it's definitely not backwards compatibility safe to replace all built-in [pack]/[unpack] by the zexy versions, since the zexy versions reads the 'f' and 's' literally and thus some patches produce lots of errors (due to inlets receiving 'f' instead of '0', for instance).
roman
___________________________________________________________ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
hm.. only now, i see that overriding built-ins seems to be intentional.
yes, this has been calimed to be a feature: http://lists.puredata.info/pipermail/pd-dev/2008-06/011846.html
i still don't believe it really is. it might be better to add an explicit way to override builtins (or pre-loaded externals).
when starting pd with loading zexy, i get:
warning: class 'pack' overwritten; old one renamed 'pack_aliased' warning: class 'unpack' overwritten; old one renamed 'unpack_aliased'
and pd's built-in [pack] can be instantiated with [pack_aliased]
?????????
the fun starts when yet another library claims the name [pack].
mfgad.sr IOhannes
Well, what I want to be able to do is put max-compatible objects into Pd vanilla (such as gate and scale) without breaking libraries. However, I didn't realize there were libraries out there that named things the same as Pd built-ins, with the intention of not ever getting instantiated under the original name.
Maybe, if zexy/pack and zexy/unpack are only meant to be called using their "path" names, it would be better to specify them as "zexy/pack" etc. in class_new()?
If it isn't possible to alias objects with external libraries, I don't see how I can ever add a class to Pd once some library appears that uses the same name.
Ideas, anyone?
thanks Miller
On Wed, Nov 05, 2008 at 09:23:02AM +0100, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
hm.. only now, i see that overriding built-ins seems to be intentional.
yes, this has been calimed to be a feature: http://lists.puredata.info/pipermail/pd-dev/2008-06/011846.html
i still don't believe it really is. it might be better to add an explicit way to override builtins (or pre-loaded externals).
when starting pd with loading zexy, i get:
warning: class 'pack' overwritten; old one renamed 'pack_aliased' warning: class 'unpack' overwritten; old one renamed 'unpack_aliased'
and pd's built-in [pack] can be instantiated with [pack_aliased]
?????????
the fun starts when yet another library claims the name [pack].
mfgad.sr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, Nov 05, 2008 at 11:39:51AM -0800, Miller Puckette wrote:
Well, what I want to be able to do is put max-compatible objects into Pd vanilla (such as gate and scale) without breaking libraries. However, I didn't realize there were libraries out there that named things the same as Pd built-ins, with the intention of not ever getting instantiated under the original name.
Maybe, if zexy/pack and zexy/unpack are only meant to be called using their "path" names, it would be better to specify them as "zexy/pack" etc. in class_new()?
If it isn't possible to alias objects with external libraries, I don't see how I can ever add a class to Pd once some library appears that uses the same name.
Ideas, anyone?
Hi Miller,
This problem has been 100% solved already:
http://www.network-theory.co.uk/docs/pylang/importstatement.html
The described way of doing things is a win-win for developers and for users; both get maximum flexibility. I can't think of any good reason why we are still debating this and [declare] and [import] on this list.
Example:
[from max import gate]
[from max import scale]
[from zexy import *]
then
[gate]
[scale]
[pack] <- inbuilt is overridden
and
[import max]
[import zexy]
then
[max/gate]
[max/scale]
[zexy/pack] <- inbuilt isn't overridden
I hope this doesn't come across too blunt or unconstructive; I just want to see this issue get solved and disappear.
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
This problem has been 100% solved already:
http://www.network-theory.co.uk/docs/pylang/importstatement.html
The described way of doing things is a win-win for developers and for users; both get maximum flexibility. I can't think of any good reason why we are still debating this and [declare] and [import] on this list.
However: as I understand Miller's intentions, [declare] is not meant to be the same as [import]! [declare -*path] modifies the full Pd search path, which includes the search path for files that are not objects, e.g. soundfiles with no complete path for [soundfiler]. [import] however - if I understand Hans' intentions correctly - only modifies the object search path and loaded libraries.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Thu, Nov 06, 2008 at 01:36:27PM +0100, Frank Barknecht wrote:
Chris McCormick hat gesagt: // Chris McCormick wrote:
This problem has been 100% solved already:
http://www.network-theory.co.uk/docs/pylang/importstatement.html
The described way of doing things is a win-win for developers and for users; both get maximum flexibility. I can't think of any good reason why we are still debating this and [declare] and [import] on this list.
However: as I understand Miller's intentions, [declare] is not meant to be the same as [import]! [declare -*path] modifies the full Pd search path, which includes the search path for files that are not objects, e.g. soundfiles with no complete path for [soundfiler]. [import] however - if I understand Hans' intentions correctly - only modifies the object search path and loaded libraries.
Ok yes, I see. Please excuse my ignorance in that regard. Though I still think that we can look at other languages that have solved this issue. Sorry for my weak contribution! :/
Chris.
On Nov 6, 2008, at 7:36 AM, Frank Barknecht wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
This problem has been 100% solved already:
http://www.network-theory.co.uk/docs/pylang/importstatement.html
The described way of doing things is a win-win for developers and for users; both get maximum flexibility. I can't think of any good reason why we are still debating this and [declare] and [import] on this
list.However: as I understand Miller's intentions, [declare] is not meant to be the same as [import]! [declare -*path] modifies the full Pd search path, which includes the search path for files that are not objects, e.g. soundfiles with no complete path for [soundfiler]. [import] however - if I understand Hans' intentions correctly - only modifies the object search path and loaded libraries.
Minor correction: canvas-local namespace and global namespace,
instead of "object search path". Or you could say, per-patch search
path, etc.
I think python is a decent model, but I think the namespace/import
stuff in Python is too complicated for Pd. Here's how I think it
should work:
canvas-local namespace per patch and global namespace
the namespaces should be consulted whenever creating an instance,
not only when loading a class. That means that if I [import zexy]
then use [drip], [drip] won't work in a new patch since 'zexy' hasn't
been imported into that class namespace.
- the exact same mechanism should be used for all objectclasses,
there should be no distinction here between "internal" and "external"
in terms of the library format and the namespace (except, of course,
a small set of "builtins" or reserved words).
I think that this override stuff will be quite confusing to keep
track of and use. Plus it'll require reversing the order of the lookups.
.hc
Ciao
Frank Barknecht Do You RjDj.me? _
______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
Miller Puckette wrote:
Well, what I want to be able to do is put max-compatible objects into Pd vanilla (such as gate and scale) without breaking libraries. However, I didn't realize there were libraries out there that named things the same as Pd built-ins, with the intention of not ever getting instantiated under the original name.
Maybe, if zexy/pack and zexy/unpack are only meant to be called using their "path" names, it would be better to specify them as "zexy/pack" etc. in class_new()?
yes, that's what i am doing now (after the bug report).
however, this is a hack to avoid the problem rather than a solution to it.
fgmasdr IOhannes
Roman Haefeli wrote:
hi all, hi IOhannes
after having installed pd 0.42.0test5, i assumed to have discovered a behaviour change of [unpack] and [pack], until i noticed:
a) zexy comes with its own version of [pack] and [unpack]. why are they called the same? i really don't get that.
because they are meant as a better (but obviously buggy) replacement of pack.
b) in pd 0.42.0test5 they seem to override the built-in classes. is this a bug? if yes, pd's or zexy's?
it's a feature of Pd.
c) the zexy versions can explicitly be called by using the 'zexy/' prefix. how is that possible, although zexy was compiled as multi class library? is that _the_ solution to have multiclass libs and separate namespaces at the same time?
this is because zexy's [pack] explicitely asks to be named [zexy/pack].
the reason for this is, that i wanted to make explicit that this is not the built-in pack. so people could basically chose which flavour they wanted. the other reason is of course, that prior to 0.42, there was no way to overwrite a built-in, so i had to come up with a different name (and [zexy/pack] was somehow more appealing than anything else).
now all of this would not be a problem, if my object's "primary" name would not be "pack" - which it is in order to express the intention of this object. it was a safe thing to do in the olde days :-) (and it would be even less a problem if it behaved comaptible with the original [pack])
i will fix the name-clash asap.
the more interesting thing would be an idea to make zexy's pack really compatible with the built-in version. the best thing i can currently come up with is to make zexy's pack interprete its arguments differently. e.g. [zexy/pack f s] would output [list f s( and zexy's [pack f s] would output [list 0 symbol( but still would output [list s 0( when somebody would send a [list s 0( _into_ this object.
fmga.fdas IOhannes
-
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette -
Roman Haefeli