I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken.
I think it's better to talk about *directory* prefixes here.
Ciao
I'll have to think about this one... should be fixable, but might take some new bookkeeping code to keep different objects disambiguated...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Yep, I have to look at (and try to understand) that... I'll bump that up on my dolist :)
cheers M
On Fri, Oct 27, 2006 at 01:29:16AM -0400, Hans-Christoph Steiner wrote:
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Ok, so I just found something that may or may not be a problem, but its not clean at least. Once you instantiate an object with the namespace prefix, that class gets added to the namespace. For example, follow these steps: _ _ _ _ |split| - no go - - - - [iemlib/split] - makes an object
[split] - makes another instance of iemlib's [split]
This isn't new, this happened in 0.39.2. But I think its something to think about, and its related to IOhannes' patch. In that patch, IIRC, the whole name with namespace prefix and class name is used at the classname, at least for the canvas name. Perhaps that's what needs to happen throughout?
.hc
On Oct 27, 2006, at 11:48 AM, Miller Puckette wrote:
Yep, I have to look at (and try to understand) that... I'll bump that up on my dolist :)
cheers M
On Fri, Oct 27, 2006 at 01:29:16AM -0400, Hans-Christoph Steiner wrote:
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
--
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
That's been bothering me too... it's a race to see which 'split' gets hold of the basename.
But I can see mixing patches which use |split| with others that use disambiguated names like |iemlib/split| which I think will cause trouble if the name "split" isn't made available...
dunno.
M
On Sat, Oct 28, 2006 at 08:24:16PM -0400, Hans-Christoph Steiner wrote:
Ok, so I just found something that may or may not be a problem, but its not clean at least. Once you instantiate an object with the namespace prefix, that class gets added to the namespace. For example, follow these steps: _ _ _ _ |split| - no go
[iemlib/split] - makes an object
[split] - makes another instance of iemlib's [split]
This isn't new, this happened in 0.39.2. But I think its something to think about, and its related to IOhannes' patch. In that patch, IIRC, the whole name with namespace prefix and class name is used at the classname, at least for the canvas name. Perhaps that's what needs to happen throughout?
.hc
On Oct 27, 2006, at 11:48 AM, Miller Puckette wrote:
Yep, I have to look at (and try to understand) that... I'll bump that up on my dolist :)
cheers M
On Fri, Oct 27, 2006 at 01:29:16AM -0400, Hans-Christoph Steiner wrote:
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
--
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Ok, just to be pedantic: we agree that [split] should be separate from [iemlib/split], so the question is then the implementation.
.hc
On Oct 28, 2006, at 8:40 PM, Miller Puckette wrote:
That's been bothering me too... it's a race to see which 'split' gets hold of the basename.
But I can see mixing patches which use |split| with others that use disambiguated names like |iemlib/split| which I think will cause trouble if the name "split" isn't made available...
dunno.
M
On Sat, Oct 28, 2006 at 08:24:16PM -0400, Hans-Christoph Steiner wrote:
Ok, so I just found something that may or may not be a problem, but its not clean at least. Once you instantiate an object with the namespace prefix, that class gets added to the namespace. For example, follow these steps: _ _ _ _ |split| - no go
[iemlib/split] - makes an object
[split] - makes another instance of iemlib's [split]
This isn't new, this happened in 0.39.2. But I think its something to think about, and its related to IOhannes' patch. In that patch, IIRC, the whole name with namespace prefix and class name is used at the classname, at least for the canvas name. Perhaps that's what needs to happen throughout?
.hc
On Oct 27, 2006, at 11:48 AM, Miller Puckette wrote:
Yep, I have to look at (and try to understand) that... I'll bump that up on my dolist :)
cheers M
On Fri, Oct 27, 2006 at 01:29:16AM -0400, Hans-Christoph Steiner wrote:
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote:
I was just looking into the new canvas-based env and [declare] stuff. The canvas-specific path stuff is definitely a step in the right direction. But as it is now, namespace prefixes are totally broken. It is no longer possible to use [prefix/classname] syntax, which is essential to the namespaces because it is the only way that two classes with the same root classname could be used in the same patch, i.e. like this, where each object is a different class:
[prepend] [cxc/prepend] [cyclone/prepend]
This is because with the new sys_onloadlist() functionality that checks to see whether a class has already been loaded. It only uses the direct classname, not the prefix also.
.hc
--
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
--
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic
I see... so iemlib/split should then _never_ be available as plain split. That makes sense.
On Mon, Oct 30, 2006 at 03:39:58PM -0500, Hans-Christoph Steiner wrote:
Ok, just to be pedantic: we agree that [split] should be separate from [iemlib/split], so the question is then the implementation.
.hc
On Oct 28, 2006, at 8:40 PM, Miller Puckette wrote:
That's been bothering me too... it's a race to see which 'split' gets hold of the basename.
But I can see mixing patches which use |split| with others that use disambiguated names like |iemlib/split| which I think will cause trouble if the name "split" isn't made available...
dunno.
M
On Sat, Oct 28, 2006 at 08:24:16PM -0400, Hans-Christoph Steiner wrote:
Ok, so I just found something that may or may not be a problem, but its not clean at least. Once you instantiate an object with the namespace prefix, that class gets added to the namespace. For example, follow these steps: _ _ _ _ |split| - no go
[iemlib/split] - makes an object
[split] - makes another instance of iemlib's [split]
This isn't new, this happened in 0.39.2. But I think its something to think about, and its related to IOhannes' patch. In that patch, IIRC, the whole name with namespace prefix and class name is used at the classname, at least for the canvas name. Perhaps that's what needs to happen throughout?
.hc
On Oct 27, 2006, at 11:48 AM, Miller Puckette wrote:
Yep, I have to look at (and try to understand) that... I'll bump that up on my dolist :)
cheers M
On Fri, Oct 27, 2006 at 01:29:16AM -0400, Hans-Christoph Steiner wrote:
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
This should now be fixed in CVS (branch stable_0_40)...
cheers Miller
On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner wrote: > >I was just looking into the new canvas-based env and [declare] >stuff. The canvas-specific path stuff is definitely a step in >the >right direction. But as it is now, namespace prefixes are >totally >broken. It is no longer possible to use [prefix/classname] >syntax, >which is essential to the namespaces because it is the only way >that >two classes with the same root classname could be used in the >same >patch, i.e. like this, where each object is a different class: > >[prepend] >[cxc/prepend] >[cyclone/prepend] > >This is because with the new sys_onloadlist() functionality that >checks to see whether a class has already been loaded. It only >uses >the direct classname, not the prefix also. > >.hc > >----------------------------------------------------------------- >-- >-- >--- > >"[W]e have invented the technology to eliminate scarcity, but we >are >deliberately throwing it away to benefit those who profit from >scarcity." -John Gilmore > > > >_______________________________________________ >PD-dev mailing list >PD-dev@iem.at >http://lists.puredata.info/listinfo/pd-dev
--
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Access to computers should be unlimited and total. - the hacker ethic
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
.hc
On Oct 30, 2006, at 3:41 PM, Miller Puckette wrote:
I see... so iemlib/split should then _never_ be available as plain split. That makes sense.
On Mon, Oct 30, 2006 at 03:39:58PM -0500, Hans-Christoph Steiner wrote:
Ok, just to be pedantic: we agree that [split] should be separate from [iemlib/split], so the question is then the implementation.
.hc
On Oct 28, 2006, at 8:40 PM, Miller Puckette wrote:
That's been bothering me too... it's a race to see which 'split' gets hold of the basename.
But I can see mixing patches which use |split| with others that use disambiguated names like |iemlib/split| which I think will cause trouble if the name "split" isn't made available...
dunno.
M
On Sat, Oct 28, 2006 at 08:24:16PM -0400, Hans-Christoph Steiner wrote:
Ok, so I just found something that may or may not be a problem, but its not clean at least. Once you instantiate an object with the namespace prefix, that class gets added to the namespace. For example, follow these steps: _ _ _ _ |split| - no go
[iemlib/split] - makes an object
[split] - makes another instance of iemlib's [split]
This isn't new, this happened in 0.39.2. But I think its something to think about, and its related to IOhannes' patch. In that patch, IIRC, the whole name with namespace prefix and class name is used at the classname, at least for the canvas name. Perhaps that's what needs to happen throughout?
.hc
On Oct 27, 2006, at 11:48 AM, Miller Puckette wrote:
Yep, I have to look at (and try to understand) that... I'll bump that up on my dolist :)
cheers M
On Fri, Oct 27, 2006 at 01:29:16AM -0400, Hans-Christoph Steiner wrote:
I did a quick check, seems to work again. Will report again if there are problems.
How about the patch that IOhannes submitted a while aback making the the astraction-canvas use the prefix and classname? That is also important since it puts objects written in Pd on the same footing at C objects.
http://sourceforge.net/tracker/index.php? func=detail&aid=1403917&group_id=55736&atid=478072
.hc
On Oct 25, 2006, at 5:39 PM, Miller Puckette wrote:
> This should now be fixed in CVS (branch stable_0_40)... > > cheers > Miller > > On Fri, Oct 13, 2006 at 05:19:00PM -0400, Hans-Christoph Steiner > wrote: >> >> I was just looking into the new canvas-based env and [declare] >> stuff. The canvas-specific path stuff is definitely a step in >> the >> right direction. But as it is now, namespace prefixes are >> totally >> broken. It is no longer possible to use [prefix/classname] >> syntax, >> which is essential to the namespaces because it is the only way >> that >> two classes with the same root classname could be used in the >> same >> patch, i.e. like this, where each object is a different class: >> >> [prepend] >> [cxc/prepend] >> [cyclone/prepend] >> >> This is because with the new sys_onloadlist() functionality >> that >> checks to see whether a class has already been loaded. It only >> uses >> the direct classname, not the prefix also. >> >> .hc >> >> --------------------------------------------------------------- >> -- >> -- >> -- >> --- >> >> "[W]e have invented the technology to eliminate scarcity, >> but we >> are >> deliberately throwing it away to benefit those who profit from >> scarcity." -John Gilmore >> >> >> >> _______________________________________________ >> PD-dev mailing list >> PD-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev
--
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
--
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Access to computers should be unlimited and total. - the hacker ethic
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
Syntax suggestion: what about [declare -import iemlib]?
Ciao
On Wed, 1 Nov 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
Syntax suggestion: what about [declare -import iemlib]?
Some consensus on how to do things like that ("keyword arguments") ould help:
1. In Flext/Jitter style: [declare @import iemlib].
2. In Unix/Tcl/Toxy style: [declare -import iemlib].
3. In GridFlow style: [declare, import iemlib], where "import" is a selector and the name of a method, and the comma is like [initbang].
The use of "@" to mean "attribute" may remind of Ruby, but in Ruby, "@" is a kind of variable, not a kind of argument.
The GridFlow style relies on the ability to replace keyword arguments of a constructor by a bunch of little messages that modify the object just after it's constructed (this is not always possible).
One of (1) and (2) is redundant. Then I wouldn't know which of that or (3) to pick. The (3) has the important concept that every option is runtime-configurable. That might not be an issue for [declare], but that is an issue for other object classes that [declare] would be consistent with.
How would you specify multiple imports? It may make the difference between Unix style and Tcl style:
[declare -import foo -import bar] <- unix [declare -import {foo bar}] <- tcl
because in tcl style, every time an option is specified, it has to completely override the existing option of the same name: it can't add up like pd's -lib -path -helppath. Pd doesn't accept {} so here are some possible replacements:
[declare -import (foo bar)] <- GF-style nested lists [declare -import foo bar] <- use dash-prefixed symbols as delimiters [declare, import foo bar] <- use comma as delimiter
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 1, 2006, at 9:02 AM, Mathieu Bouchard wrote:
On Wed, 1 Nov 2006, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
Syntax suggestion: what about [declare -import iemlib]?
Some consensus on how to do things like that ("keyword arguments") ould help:
In Flext/Jitter style: [declare @import iemlib].
In Unix/Tcl/Toxy style: [declare -import iemlib].
In GridFlow style: [declare, import iemlib], where "import" is a
selector and the name of a method, and the comma is like [initbang].
The use of "@" to mean "attribute" may remind of Ruby, but in Ruby, "@" is a kind of variable, not a kind of argument.
The GridFlow style relies on the ability to replace keyword arguments of a constructor by a bunch of little messages that modify the object just after it's constructed (this is not always possible).
One of (1) and (2) is redundant. Then I wouldn't know which of that or (3) to pick. The (3) has the important concept that every option is runtime-configurable. That might not be an issue for [declare], but that is an issue for other object classes that [declare] would be consistent with.
How would you specify multiple imports? It may make the difference between Unix style and Tcl style:
[declare -import foo -import bar] <- unix [declare -import {foo bar}] <- tcl
because in tcl style, every time an option is specified, it has to completely override the existing option of the same name: it can't add up like pd's -lib -path -helppath. Pd doesn't accept {} so here are some possible replacements:
[declare -import (foo bar)] <- GF-style nested lists [declare -import foo bar] <- use dash-prefixed symbols as delimiters [declare, import foo bar] <- use comma as delimiter
One very important aspect of Pd is its very minimal syntax. I think its quite important to preserve that. I definitely agree we should have a standard way of doing this kind of thing, but I don't really like any of the above options. Pd is not Ruby, Tcl, C, UNIX, etc. and it shouldn't follow those conventions without really good reasons to break the current syntax.
Adding commas and () in object boxes is totally unprecedented and I can't see any benefit. Perhaps this extended syntax is useful in other situations, but I think this situation could easily be taken care of using only current syntax:
patch-local ----------- [import foo bar] [path foo bar]
global ------ [global_import foo bar] [global_path foo bar]
I think it could make more sense to have the global settings controlled by messages. These settings are already controlled separately from the patch itself and hidden in the preferecne panels and files, so it terms of the patch representing the run state, I don't think it would make a difference; that stuff is outside of the realm of the patch. So it could look like this:
[;pd import foo bar( [;pd path foo bar(
.hc
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote:
[declare -import (foo bar)] <- GF-style nested lists [declare -import foo bar] <- use dash-prefixed symbols as delimiters [declare, import foo bar] <- use comma as delimiter
One very important aspect of Pd is its very minimal syntax.
It depends on which part of Pd you're looking at. Let's say that you're looking at everything that confirms your point; then you're not looking at datastructures. For example:
[plot -y amp(0:100)(0:100) a 500 2 5 30]
I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
I think its quite important to preserve that.
Pd's syntax doesn't so much deserve to be called "simple" ... "simplistic" is more like it. Any non-recursive grammar is bound to get to a dead-end in which small syntax hacks proliferate.
but I don't really like any of the above options. Pd is not Ruby, Tcl, C, UNIX, etc. and it shouldn't follow those conventions without really good reasons to break the current syntax.
This is called "Not Invented Here", the concept that one system should not borrow conventions from another system. It's an important concept that has been used for designing many systems, and ironically, one that many systems designers have borrowed from each other. (http://en.wikipedia.org/wiki/Not_Invented_Here)
It's not possible to break the current syntax because there's no current syntax.
Adding commas and () in object boxes is totally unprecedented
GridFlow is a precedent for both initbang commas and nested lists, but it doesn't count because it was not designed by Miller. There is also precedent for @ keywords in the work of Thomas Grill and also of Joshua K Clayton but it doesn't count because it was not designed by Miller. There is also precedent for - keywords in the work of Krzysztof Czaja but it doesn't count because it was not designed by Miller.
and I can't see any benefit.
because it's not designed by Miller and because you're not thinking about any of the other object classes that could benefit from those syntax extensions. Even though [plot] would have needed it, [plot] introduces its own precedent which is sufficient justification by itself, because it was designed by Miller.
I definitely agree we should have a standard way of doing this kind of thing,
By reading you, I doubt that you mean that we should have a standard way of doing keyword arguments. Is it that you are only thinking about namespaces and nothing else? I'm not only thinking about namespaces. You're replying to a mail where more than just namespaces are considered.
Perhaps this extended syntax is useful in other situations, but I think this situation could easily be taken care of using only current syntax:
Right, we don't absolutely need keyword arguments, nested lists and initbang messages in objectboxes. I'm only talking about those things because a syntax similar to keyword arguments has been proposed and because I've seen similar patterns occur in the pd world, but I don't mean the pd world that has just Miller in it, I mean all externals, and not just the subset of pd-extended that agrees with Miller's practice (minus [plot]).
I think it could make more sense to have the global settings controlled by messages.
[;pd import foo bar( [;pd path foo bar(
[import foo bar( | [s $0-canvas]
[namecanvas $0-canvas]
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 1, 2006, at 7:30 PM, Mathieu Bouchard wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote:
[declare -import (foo bar)] <- GF-style nested lists [declare -import foo bar] <- use dash-prefixed symbols as delimiters [declare, import foo bar] <- use comma as delimiter
One very important aspect of Pd is its very minimal syntax.
It depends on which part of Pd you're looking at. Let's say that you're looking at everything that confirms your point; then you're not looking at datastructures. For example:
[plot -y amp(0:100)(0:100) a 500 2 5 30]
I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax?
I don't quite get the scaling stuff, so I guess its hard to see why it needs to be done that way. Perhaps there could be a scaling standard variable like float x, float y, and float w. It could be an array of 4 values, or two values, a ratio and offset.
Another difference between [declare] and data structures/gridflow is that obstensibly, [declare] will be used everywhere, while DS/GF would be a special topic. For special areas, special syntax is perhaps more excusable than something used everywhere.
.hc
I think its quite important to preserve that.
Pd's syntax doesn't so much deserve to be called "simple" ... "simplistic" is more like it. Any non-recursive grammar is bound to get to a dead-end in which small syntax hacks proliferate.
but I don't really like any of the above options. Pd is not Ruby, Tcl, C, UNIX, etc. and it shouldn't follow those conventions without really good reasons to break the current syntax.
This is called "Not Invented Here", the concept that one system should not borrow conventions from another system. It's an important concept that has been used for designing many systems, and ironically, one that many systems designers have borrowed from each other. (http://en.wikipedia.org/wiki/Not_Invented_Here)
It's not possible to break the current syntax because there's no current syntax.
Adding commas and () in object boxes is totally unprecedented
GridFlow is a precedent for both initbang commas and nested lists, but it doesn't count because it was not designed by Miller. There is also precedent for @ keywords in the work of Thomas Grill and also of Joshua K Clayton but it doesn't count because it was not designed by Miller. There is also precedent for - keywords in the work of Krzysztof Czaja but it doesn't count because it was not designed by Miller.
and I can't see any benefit.
because it's not designed by Miller and because you're not thinking about any of the other object classes that could benefit from those syntax extensions. Even though [plot] would have needed it, [plot] introduces its own precedent which is sufficient justification by itself, because it was designed by Miller.
I definitely agree we should have a standard way of doing this kind of thing,
By reading you, I doubt that you mean that we should have a standard way of doing keyword arguments. Is it that you are only thinking about namespaces and nothing else? I'm not only thinking about namespaces. You're replying to a mail where more than just namespaces are considered.
Perhaps this extended syntax is useful in other situations, but I think this situation could easily be taken care of using only current syntax:
Right, we don't absolutely need keyword arguments, nested lists and initbang messages in objectboxes. I'm only talking about those things because a syntax similar to keyword arguments has been proposed and because I've seen similar patterns occur in the pd world, but I don't mean the pd world that has just Miller in it, I mean all externals, and not just the subset of pd-extended that agrees with Miller's practice (minus [plot]).
I think it could make more sense to have the global settings controlled by messages.
[;pd import foo bar( [;pd path foo bar(
[import foo bar( | [s $0-canvas]
[namecanvas $0-canvas]
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
On Wed, Nov 01, 2006 at 10:39:50PM -0500, Hans-Christoph Steiner wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote: I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax?
I would say that datastructures should be considered amongst things that are "in common usage". It's simply not possible to use datastructures for visualising audio data without the scaling syntax, and I think there's a good reason that Miller made the syntax look like that - it's not possible to do it without some kind of custom syntax like that. Datastructures are part of the Pd core.
Incidentally, I also think this highlights the need for a poll of the Pd list at some point so we can get some idea of what users are using what externals, abstraction sets, libraries, etc. I would love to see the numbers, and it would probably be useful for Miller to see what is popular about Pd in a quantifiable scientific way.
I don't quite get the scaling stuff, so I guess its hard to see why it needs to be done that way. Perhaps there could be a scaling standard variable like float x, float y, and float w. It could be an array of 4 values, or two values, a ratio and offset.
I think you should read up on DS some more and try using the scaling yourself.
Another difference between [declare] and data structures/gridflow is that obstensibly, [declare] will be used everywhere, while DS/GF would be a special topic. For special areas, special syntax is perhaps more excusable than something used everywhere.
In my opinion datastructures should stay core to Pd as more and more people create GOP datastructure abstractions for others to use. It's possible to make amazing custom GUIs that will work with vanilla Pd without requiring users to compile/install complicated externals.
Best,
Chris, your friendly neighbourhood DS advocate. ;)
------------------- chris@mccormick.cx http://mccormick.cx
On Thu Nov 02, 2006 at 02:02:52PM +0800, Chris McCormick wrote:
On Wed, Nov 01, 2006 at 10:39:50PM -0500, Hans-Christoph Steiner wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote: I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax?
I would say that datastructures should be considered amongst things that are "in common usage". It's simply not possible to use datastructures for visualising audio data without the scaling syntax, and I think there's a good reason that Miller made the syntax look like that - it's not possible to do it without some kind of custom syntax like that.
so youre advocating arbitrary microformatting on a per-case basis instead of fixing the pd syntax so its not necessary?
hpoefully i just misread.. how do you generate/parse -y amp(0:100)(0:100) easily. maybe the nonexistent regexp external?
Datastructures are part of the Pd core.
Incidentally, I also think this highlights the need for a poll of the Pd list at some point so we can get some idea of what users are using what externals, abstraction sets, libraries, etc. I would love to see the numbers, and it would probably be useful for Miller to see what is popular about Pd in a quantifiable scientific way.
what about an opt-in usage statistics 'phone home'. initng does this for example.. firefox just does it without even asking..
I don't quite get the scaling stuff, so I guess its hard to see why it needs to be done that way. Perhaps there could be a scaling standard variable like float x, float y, and float w. It could be an array of 4 values, or two values, a ratio and offset.
I think you should read up on DS some more and try using the scaling yourself.
Another difference between [declare] and data structures/gridflow is that obstensibly, [declare] will be used everywhere, while DS/GF would be a special topic. For special areas, special syntax is perhaps more excusable than something used everywhere.
In my opinion datastructures should stay core to Pd as more and more people create GOP datastructure abstractions for others to use. It's possible to make amazing custom GUIs that will work with vanilla Pd without requiring users to compile/install complicated externals.
is it? that would be great. but i think its currently a pipedream...
Best,
Chris, your friendly neighbourhood DS advocate. ;)
chris@mccormick.cx http://mccormick.cx
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Nov 2, 2006, at 2:08 AM, carmen wrote:
On Thu Nov 02, 2006 at 02:02:52PM +0800, Chris McCormick wrote:
On Wed, Nov 01, 2006 at 10:39:50PM -0500, Hans-Christoph Steiner wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote: I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax?
I would say that datastructures should be considered amongst things that are "in common usage". It's simply not possible to use datastructures for visualising audio data without the scaling syntax, and I think there's a good reason that Miller made the syntax look like that - it's not possible to do it without some kind of custom syntax like that.
so youre advocating arbitrary microformatting on a per-case basis instead of fixing the pd syntax so its not necessary?
hpoefully i just misread.. how do you generate/parse -y amp(0:100) (0:100) easily. maybe the nonexistent regexp external?
Datastructures are part of the Pd core.
Incidentally, I also think this highlights the need for a poll of the Pd list at some point so we can get some idea of what users are using what externals, abstraction sets, libraries, etc. I would love to see the numbers, and it would probably be useful for Miller to see what is popular about Pd in a quantifiable scientific way.
what about an opt-in usage statistics 'phone home'. initng does this for example.. firefox just does it without even asking..
Funny, I was just thinking about something like that. It would be cool to know how many people are using Pd. If you code it, I'll include it in Pd-extended. Then maybe it could make it into devel or MAIN.
Right now, there have been roughly 17,000 downloads of the last Pd- extended release, according to SourceForge:
http://sourceforge.net/project/showfiles.php? group_id=55736&package_id=76013
I'd like to know how many people use it, and for what.
.hc
I don't quite get the scaling stuff, so I guess its hard to see why it needs to be done that way. Perhaps there could be a scaling standard variable like float x, float y, and float w. It could be an array of 4 values, or two values, a ratio and offset.
I think you should read up on DS some more and try using the scaling yourself.
Another difference between [declare] and data structures/gridflow is that obstensibly, [declare] will be used everywhere, while DS/GF would be a special topic. For special areas, special syntax is perhaps more excusable than something used everywhere.
In my opinion datastructures should stay core to Pd as more and more people create GOP datastructure abstractions for others to use. It's possible to make amazing custom GUIs that will work with vanilla Pd without requiring users to compile/install complicated externals.
is it? that would be great. but i think its currently a pipedream...
Best,
Chris, your friendly neighbourhood DS advocate. ;)
chris@mccormick.cx http://mccormick.cx
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Incidentally, I also think this highlights the need for a poll of the Pd list at some point so we can get some idea of what users are using what externals, abstraction sets, libraries, etc. I would love to see the numbers, and it would probably be useful for Miller to see what is popular about Pd in a quantifiable scientific way.
what about an opt-in usage statistics 'phone home'. initng does this for example.. firefox just does it without even asking..
Funny, I was just thinking about something like that. It would be cool to know how many people are using Pd. If you code it, I'll include it in Pd-extended. Then maybe it could make it into devel or MAIN.
this doesn't add any useful functionality for the user and is using the means of adware/spyware/activation ... it will definitely not make it into devel as long i still have a write access to the cvs ...
tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow
On 3 Nov 2006, at 08:54, Tim Blechmann wrote:
this doesn't add any useful functionality for the user and is using the means of adware/spyware/activation ... it will definitely not make it into devel as long i still have a write access to the cvs ...
They're talking about an opt-in, which could simply be part of an installation process.
Threatening proposals with write access is silly and politically unsound.
d
-- David Plans Casal main at davidcasal dot com http://www.davidcasal.com
On Nov 3, 2006, at 3:54 AM, Tim Blechmann wrote:
Incidentally, I also think this highlights the need for a poll of the Pd list at some point so we can get some idea of what users are using what externals, abstraction sets, libraries, etc. I would love to see the numbers, and it would probably be useful for Miller to see what is popular about Pd in a quantifiable scientific way.
what about an opt-in usage statistics 'phone home'. initng does this for example.. firefox just does it without even asking..
Funny, I was just thinking about something like that. It would be cool to know how many people are using Pd. If you code it, I'll include it in Pd-extended. Then maybe it could make it into devel or MAIN.
this doesn't add any useful functionality for the user and is using the means of adware/spyware/activation ... it will definitely not make it into devel as long i still have a write access to the cvs ...
Do you think we do this because we have a secret desire to be big brother? The whole point would be to improve the user experience. If we know what people are using, then we can better target our limited resources.
I am completely aware of the privacy issues. Doing this in an open- source way helps that a lot. I don't think anyone wants to track people. But there are well established ways of getting such data in an anonymous way. Plus I think that we would actually increase people's privacy by creating real working models of anonymous data gathering that people can point to when large corporations and governments say that it can't be done.
.hc
------------------------------------------------------------------------
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
On Thu, 2 Nov 2006, Hans-Christoph Steiner wrote:
Right now, there have been roughly 17,000 downloads of the last Pd-extended release, according to SourceForge: http://sourceforge.net/project/showfiles.php?group_id=55736&package_id=7... I'd like to know how many people use it, and for what.
I bet that 16,000 of them were made by Cycling74 to make us feel overconfident. ;)
The pd-list has only 1457 subscribers. pd-dev has 506 subscribers. A lot of them have subscription disabled, possibly because the email address has changed and MailMan never really removes subscribers. For example, pd-list has only 1002 enabled subscribers.
pdmtl has 145 addresses (but only 7 disabled addresses because i removed most bouncing addresses recently)
pd@listas.xicnet.com has 32 addresses. I think that the pd-graz list is smaller than that but somehow I never can find the mailman page in less than 5 minutes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Fri, Nov 03, 2006 at 10:43:31AM -0500, Mathieu Bouchard wrote:
On Thu, 2 Nov 2006, Hans-Christoph Steiner wrote:
Right now, there have been roughly 17,000 downloads of the last Pd-extended release, according to SourceForge: http://sourceforge.net/project/showfiles.php?group_id=55736&package_id=7... I'd like to know how many people use it, and for what.
I bet that 16,000 of them were made by Cycling74 to make us feel overconfident. ;)
Hehe
The pd-list has only 1457 subscribers. pd-dev has 506 subscribers. A lot of them have subscription disabled, possibly because the email address has changed and MailMan never really removes subscribers. For example, pd-list has only 1002 enabled subscribers.
I am not sure that number of subscribers to the mailing list is an accurate representation of number of current users. I know from releases of my own software in the past, the subscriber to download ratio is always very very low. I hypothesise that a majority of software users are interested only in the software itself, and don't know/don't care about the community, or don't like mailing lists.
1000 users on the mailing list is a good sample for a survey though! Attached is a survey, please have a look and add to it, change it, whatever. I think Hans probably has a good idea of all the different sets of externals and libraries out there since he does packaging of them all. I was not sure whether or not to include questions about sex/age/whatever because I'm not sure if it's relevant, or even offensive. It would be cool to make this into a web form on the plone site, but I don't know anything about that, so I've CC'ed this to the pd-web list.
I am against the idea of Pd 'phoning home' for the same reasons as Tim, and I think it would be too hard to get the code into all the different versions of Pd out there anyway.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Nov 3, 2006, at 8:20 PM, Chris McCormick wrote:
On Fri, Nov 03, 2006 at 10:43:31AM -0500, Mathieu Bouchard wrote:
On Thu, 2 Nov 2006, Hans-Christoph Steiner wrote:
Right now, there have been roughly 17,000 downloads of the last Pd-extended release, according to SourceForge: http://sourceforge.net/project/showfiles.php? group_id=55736&package_id=76013 I'd like to know how many people use it, and for what.
I bet that 16,000 of them were made by Cycling74 to make us feel overconfident. ;)
Hehe
The pd-list has only 1457 subscribers. pd-dev has 506 subscribers. A lot of them have subscription disabled, possibly because the email address has changed and MailMan never really removes subscribers. For example, pd-list has only 1002 enabled subscribers.
I am not sure that number of subscribers to the mailing list is an accurate representation of number of current users. I know from releases of my own software in the past, the subscriber to download ratio is always very very low. I hypothesise that a majority of software users are interested only in the software itself, and don't know/don't care about the community, or don't like mailing lists.
1000 users on the mailing list is a good sample for a survey though! Attached is a survey, please have a look and add to it, change it, whatever. I think Hans probably has a good idea of all the different sets of externals and libraries out there since he does packaging of them all. I was not sure whether or not to include questions about sex/age/whatever because I'm not sure if it's relevant, or even offensive. It would be cool to make this into a web form on the plone site, but I don't know anything about that, so I've CC'ed this to the pd-web list.
I am against the idea of Pd 'phoning home' for the same reasons as Tim,
I am a strong advocate of privacy, and I think this can be done without any violation of privacy. There are a number of ways to do this:
- having it an opt-in - make it overt (i.e. pops up a window to ask permission each time) - make the code open-source (people can see exactly what it is doing) - make the unique ID a resettable random number (i.e. stored in prefs)
If you have cookie support turned on in your browser, then you are being tracked. 99% of people allow cookies at least some of the time. Most of the time none of the above conditions apply to how websites use cookies.
Then, on top of this, I think it is very good to have working examples of how to do this while maintaining privacy. Right now, companies, governments, etc. implement such systems with few privacy protections because its easier and there aren't working examples of how to do it better.
and I think it would be too hard to get the code into all the different versions of Pd out there anyway.
It would be trivial to get the code into Pd-extended.
.hc
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Sat, Nov 11, 2006 at 06:21:50PM -0500, Hans-Christoph Steiner wrote:
I am against the idea of Pd 'phoning home' for the same reasons as Tim,
I am a strong advocate of privacy, and I think this can be done without any violation of privacy. There are a number of ways to do this:
- having it an opt-in
- make it overt (i.e. pops up a window to ask permission each time)
- make the code open-source (people can see exactly what it is doing)
- make the unique ID a resettable random number (i.e. stored in prefs)
If you have cookie support turned on in your browser, then you are being tracked. 99% of people allow cookies at least some of the time. Most of the time none of the above conditions apply to how websites use cookies.
Then, on top of this, I think it is very good to have working examples of how to do this while maintaining privacy. Right now, companies, governments, etc. implement such systems with few privacy protections because its easier and there aren't working examples of how to do it better.
Sounds like Debian's "popularity contest". Ok, I'm convinced.
and I think it would be too hard to get the code into all the different versions of Pd out there anyway.
It would be trivial to get the code into Pd-extended.
Cool!
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
The pd-list has only 1457 subscribers. pd-dev has 506 subscribers. A lot of them have subscription disabled, possibly because the email address has changed and MailMan never really removes subscribers. For example, pd-list has only 1002 enabled subscribers.
These are more than the subscribers to the linux-audio-user/-dev list.
Ciao
On Thu, Nov 02, 2006 at 07:08:04AM +0000, carmen wrote:
On Thu Nov 02, 2006 at 02:02:52PM +0800, Chris McCormick wrote:
On Wed, Nov 01, 2006 at 10:39:50PM -0500, Hans-Christoph Steiner wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote: I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax?
I would say that datastructures should be considered amongst things that are "in common usage". It's simply not possible to use datastructures for visualising audio data without the scaling syntax, and I think there's a good reason that Miller made the syntax look like that - it's not possible to do it without some kind of custom syntax like that.
so youre advocating arbitrary microformatting on a per-case basis instead of fixing the pd syntax so its not necessary?
I am not advocating anything except to say that datastructures are part of the core of the language and should not be dismissed as an edge case, and that an "arbitary microformatting" of some kind is neccesary to implement that feature since the existing syntax couldn't handle it.
I think you are saying that there should be some greater more intuitive/unified syntax that includes the ability to do this kind of thing implicitly, right? So that future syntax changes wouldn't be neccesary?
hpoefully i just misread.. how do you generate/parse -y amp(0:100)(0:100) easily. maybe the nonexistent regexp external?
I am not sure what you mean by generate/parse it. Are you talking about self-modifying patches?
In my opinion datastructures should stay core to Pd as more and more people create GOP datastructure abstractions for others to use. It's possible to make amazing custom GUIs that will work with vanilla Pd without requiring users to compile/install complicated externals.
is it? that would be great. but i think its currently a pipedream...
I guess it's subjective but I think some of the GOP datastructure abstractions out there have amazing GUIs that work with vanilla Pd without requiring users to compile/install complicated externals. Want examples? Check out Frank's work.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
I guess it's subjective but I think some of the GOP datastructure abstractions out there have amazing GUIs that work with vanilla Pd without requiring users to compile/install complicated externals. Want examples? Check out Frank's work.
I'm only doing toys. A new toy is attached (requires 0.40): a simple slider made with DS. It has some redraw problems: moving the object will not move the GOP'ped data structures, until a redraw is forced externally or manually.
Also [pd subpatches] seem to be broken somewhat if you enable the "hide object name" property, which doesn't get saved into the patch (if the subpatch name has a $0).
Ciao
On Nov 4, 2006, at 1:38 PM, Frank Barknecht wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
I guess it's subjective but I think some of the GOP datastructure abstractions out there have amazing GUIs that work with vanilla Pd without requiring users to compile/install complicated externals. Want examples? Check out Frank's work.
I'm only doing toys. A new toy is attached (requires 0.40): a simple slider made with DS. It has some redraw problems: moving the object will not move the GOP'ped data structures, until a redraw is forced externally or manually.
Also [pd subpatches] seem to be broken somewhat if you enable the "hide object name" property, which doesn't get saved into the patch (if the subpatch name has a $0).
That's nice, it would be great to have state-saving built-in too. But for some reason on Mac OS X, the slider part doesn't show up on the help patch. But it does if I open up the object itself.
Oh, I see, its the annoying cross-platform size differences. That needs to be fixed so bad... hmm... I started on it, but didn't quite get there..
.hc
------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But for some reason on Mac OS X, the slider part doesn't show up on the help patch. But it does if I open up the object itself.
Actually I have opened two bug reports against this already. The main reason is that data structures in GOP subpatches break the "hide object name" property of a canvas.
Ciao
On Sat, 4 Nov 2006, IOhannes m zmoelnig wrote:
carmen wrote:
hpoefully i just misread.. how do you generate/parse -y amp(0:100)(0:100) easily. maybe the nonexistent regexp external?
which non-existent [regexp] external do you refer to? the one in zexy?
Or maybe he means [regsub] from GridFlow...
Whichever of our two externals exists less.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I advocate use of consistent syntax all over pd. Consistency is more important than minimality. If pd's syntax is too minimal, it encourages small syntax hacks that aren't portable to the rest of the pd system, such as -y amp(0:100)(0:100).
That is strange, I hadn't seen that before. I also have not seen gridflow before. I should say, then I am talking about things in common usage. There is definitely a lot of stuff shoe-horned into some of those draw and plot boxes. I wonder how to make that stuff work without the new syntax?
(Optional) keyword arguments are a long-term wishlist item, because only having positional arguments is not very comfortable. It would be great to have a corresponding object or syntax to read out keyword arguments in abstractions. I think, Thomas Grill write somthing like that for the flext-syntax. From a qwertz-keyboard user's view I would prefer the "-key" syntax over flext's "@key" syntax. Gridflow's syntax looks quite interesting, though unusual. I need to think more about it.
Ciao
Hi all,
(Optional) keyword arguments are a long-term wishlist item, because only having positional arguments is not very comfortable. It would be great to have a corresponding object or syntax to read out keyword arguments in abstractions. I think, Thomas Grill write somthing like that for the flext-syntax.
it's in the cvs in externals/grill/absattr
From a qwertz-keyboard user's view I would prefer the "-key" syntax over flext's "@key" syntax.
i only chose that because it's already known in the patcher world, due to Max/Jitter. I didn't want to introduce another standard, when there's no real reason to do that.
greetings, Thomas
-- Thomas Grill http://grrrr.org
On Thu, 2 Nov 2006, Frank Barknecht wrote:
(Optional) keyword arguments are a long-term wishlist item, because only having positional arguments is not very comfortable. It would be great to have a corresponding object or syntax to read out keyword arguments in abstractions. I think, Thomas Grill write somthing like that for the flext-syntax.
GridFlow has a class called [args] which is meant to handle all kinds of args, but currently doesn't support that kind of argument yet.
Gridflow's syntax looks quite interesting, though unusual.
You see, in Pd messageboxes, the comma means "then send the following message to the receiver", whereas in GF objectboxes, the comma means "then send the following message to the receiver". That's unusual, eh?
The only irregularity is in which object is the receiver: the messresponder vs the newly-created object.
To see it as unusual you have to be picky.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 1, 2006, at 6:29 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
Syntax suggestion: what about [declare -import iemlib]?
First off, how would this be different than [declare -lib]? [import] just loads libs.
Personally, I think the syntax of [declare] is inconsistent. Nowhere else in Pd are cmd line style arguments used in object boxes. They are used a couple of places in message boxes, but I think that suffers from the similar problems. It just doesn't feel right to me, doesn't feel Pd-ish.
For [declare], I think it could make a lot more sense as an interface to split it up into separate object boxes for paths and libs. I guess this is still experimental since as far as I can tell, [declare] suffers from the same limitation as [import]: it must be the first object loaded to work properly.
One thing that might make sense for the global settings -stdlib and - stdpath is to make them message based, like [;pd lib zexy( or [;pd path /path/to/my/extra( With those in place, the flags wouldn't be needed.
.hc
------------------------------------------------------------------------
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Well, 'declare' actually sets the patch up to do the path and lib fixes before it loads any objects (including the declare itself).
I'm in agreement that the syntax is strange. I preferred to use a single name "declare" in order not to hog up any more new names than necessary. Perhaps a better syntax would be "declare lib [name]" instead of "declare -lib [name]" -- I could make declare take either one.
cheers M
On Wed, Nov 01, 2006 at 01:12:30PM -0500, Hans-Christoph Steiner wrote:
On Nov 1, 2006, at 6:29 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
Syntax suggestion: what about [declare -import iemlib]?
First off, how would this be different than [declare -lib]? [import] just loads libs.
Personally, I think the syntax of [declare] is inconsistent. Nowhere else in Pd are cmd line style arguments used in object boxes. They are used a couple of places in message boxes, but I think that suffers from the similar problems. It just doesn't feel right to me, doesn't feel Pd-ish.
For [declare], I think it could make a lot more sense as an interface to split it up into separate object boxes for paths and libs. I guess this is still experimental since as far as I can tell, [declare] suffers from the same limitation as [import]: it must be the first object loaded to work properly.
One thing that might make sense for the global settings -stdlib and - stdpath is to make them message based, like [;pd lib zexy( or [;pd path /path/to/my/extra( With those in place, the flags wouldn't be needed.
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Nov 1, 2006, at 1:28 PM, Miller Puckette wrote:
Well, 'declare' actually sets the patch up to do the path and lib fixes before it loads any objects (including the declare itself).
Ah, excellent! I see, [declare] always inserts itself at the top of the object list in the file.
I'm in agreement that the syntax is strange. I preferred to use a single name "declare" in order not to hog up any more new names than necessary. Perhaps a better syntax would be "declare lib [name]" instead of "declare -lib [name]" -- I could make declare take either one.
I think two names is not such a big deal if there are real namespaces. There are basically very few reserved words in Pd. I think most of the current core objects could be split out into a separate lib.
Here's the list of reserved words for objects that I can think of:
[pd] [inlet] [outlet] [inlet~] [outlet~] [declare] ([path] and [import] would be a possibility)
In theory, [pd] and [declare] could be the only reserved words, with everything else in libraries. Then [pd], [path], and [import] would not be a hard list to workaround. I started a list on the wiki page, please add more if you think of some:
http://puredata.org/dev/PdNamespaces
.hc
cheers M
On Wed, Nov 01, 2006 at 01:12:30PM -0500, Hans-Christoph Steiner wrote:
On Nov 1, 2006, at 6:29 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Then to make iemlib/split.pd_darwin work as [split], one would use [declare iemlib] or [import iemlib].
Syntax suggestion: what about [declare -import iemlib]?
First off, how would this be different than [declare -lib]? [import] just loads libs.
Personally, I think the syntax of [declare] is inconsistent. Nowhere else in Pd are cmd line style arguments used in object boxes. They are used a couple of places in message boxes, but I think that suffers from the similar problems. It just doesn't feel right to me, doesn't feel Pd-ish.
For [declare], I think it could make a lot more sense as an interface to split it up into separate object boxes for paths and libs. I guess this is still experimental since as far as I can tell, [declare] suffers from the same limitation as [import]: it must be the first object loaded to work properly.
One thing that might make sense for the global settings -stdlib and - stdpath is to make them message based, like [;pd lib zexy( or [;pd path /path/to/my/extra( With those in place, the flags wouldn't be needed.
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote:
First off, how would this be different than [declare -lib]?
Actually, what does [declare] do?... I just remember some of the discussions about it vaguely, but if something's been implemented in pd lately, I haven't tried it.
Personally, I think the syntax of [declare] is inconsistent. Nowhere else in Pd are cmd line style arguments used in object boxes.
They're used in Krzysztof Czaja's TOXY. I'm sorry if you only mean what Miller does. I don't think that a decision about this should only consider Miller's practice and no-one else's.
It just doesn't feel right to me, doesn't feel Pd-ish.
It doesn't feel Miller-ish.
[import] just loads libs.
To get my approval, any kind of namespace solution should be local, so that what is imported by one canvas does not affect what is imported by another canvas, except if it's a subcanvas ([pd] or [page]). In other words, the boundary of a $0 is the boundary that [import] should not trespass.
One thing that might make sense for the global settings -stdlib and -stdpath is to make them message based, like [;pd lib zexy( or [;pd path /path/to/my/extra( With those in place, the flags wouldn't be needed.
I don't have anything against runtime configuration of pd's global settings, there just have to be a local setting or it doesn't deserve to be called namespaces.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Nov 1, 2006, at 6:49 PM, Mathieu Bouchard wrote:
On Wed, 1 Nov 2006, Hans-Christoph Steiner wrote:
First off, how would this be different than [declare -lib]?
Actually, what does [declare] do?... I just remember some of the discussions about it vaguely, but if something's been implemented in pd lately, I haven't tried it.
Um, RTFM? There's a help patch, its pretty clear.
Personally, I think the syntax of [declare] is inconsistent. Nowhere else in Pd are cmd line style arguments used in object boxes.
They're used in Krzysztof Czaja's TOXY. I'm sorry if you only mean what Miller does. I don't think that a decision about this should only consider Miller's practice and no-one else's.
Sorry, that one slipped by me. Doesn't change my overall opinion.
It just doesn't feel right to me, doesn't feel Pd-ish.
It doesn't feel Miller-ish.
[import] just loads libs.
To get my approval, any kind of namespace solution should be local, so that what is imported by one canvas does not affect what is imported by another canvas, except if it's a subcanvas ([pd] or [page]). In other words, the boundary of a $0 is the boundary that [import] should not trespass.
I don't think that anyone disagrees with that. But there is, and should be, local settings. There are global settings also. That's probably needed for transitional support, and there might be a decent argument for keeping them in general.
One thing that might make sense for the global settings -stdlib and -stdpath is to make them message based, like [;pd lib zexy( or [;pd path /path/to/my/extra( With those in place, the flags wouldn't be needed.
I don't have anything against runtime configuration of pd's global settings, there just have to be a local setting or it doesn't deserve to be called namespaces.
[declare] does both local and global.
.hc
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.