Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to have their own custom "#X declare" data.
- allow objectclasses to register their own declaration key words, like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
------------------------------------------------------------------------ ----
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
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote:
Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to have
their own custom "#X declare" data.
- allow objectclasses to register their own declaration key words,
like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all.
/full/path/names do not work on osx. (see my latest bugreports /follow ups on this). http://sourceforge.net/tracker/index.php?func=detail&aid=1917574&gro... marius.
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
In Pd as I see it there is no inherent distinction between a main patch and an abstraction. Even a patch designed as "main patch" can become an abstraction quickly, for example if I make a toplevel performance patch that loads other "main patches" as abstractions. If [declare] only works in the new main patch, I will have to manually collect all dependencies from the sub-abstractions again, which is tedious, duplicate work, if they all include appropriate [declare]s already.
An open question is how to deal with conflicts, i.e. what to do when the toplevel patch declares "-path /to/zexy/" and an abstration used in that patch declares "-path /to/cyclone" and both try to use [urn] which acts differently in zexy and cyclone.
As many things in Pd are global per default (value, send/receive, arrays, ...) it may make sense to add something like a "-localpath" option to [declare], so that abstraction authors could add their local settings to a canvas, while still accepting toplevel declarations:
"toplevel patch": [declare -path /to/zexy] [urn] <= zexy's urn [abstraction1] [abstraction2]
"abstration1": [declare -localpath /to/cyclone] [urn] <= cyclone's urn [abstraction1a]
"abstration1a inside abs. 1": no "declare" [urn] <= zexy's urn, as abs. 1 only uses -localpath
"abstration2": [declare -path /to/cyclone] [urn] <= zexy's urn, if main patch declares "zexy", cyclone's urn otherwise [abstraction2a]
"abstration2a inside abs. 2": no "declare" [urn] <= as in abs. 2.
But actually I would feel more comfortable if all settings would be local to a canvas. For example "abstraction2a" from above would act differently depending on the toplevel patc.
All local would conflict with your usage so far, though. OTOH it seems [import] tries to be just that (never used it, though): A modifier for the local canvas only, so maybe we can use both?
Ciao
I think a main patch should inherit it's path/lib settings to all abstractions used inside it, unless declared otherwise in the abstraction itself. is there a problem with that? maybe this does not work because abstractions are loaded before the main patch, so the information does not get parsed before abstractions are loaded? but the main patch is always read first, no? wasn't declare meant to declare local namespaces only? marius.
Frank Barknecht wrote:
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
In Pd as I see it there is no inherent distinction between a main patch and an abstraction. Even a patch designed as "main patch" can become an abstraction quickly, for example if I make a toplevel performance patch that loads other "main patches" as abstractions. If [declare] only works in the new main patch, I will have to manually collect all dependencies from the sub-abstractions again, which is tedious, duplicate work, if they all include appropriate [declare]s already.
An open question is how to deal with conflicts, i.e. what to do when the toplevel patch declares "-path /to/zexy/" and an abstration used in that patch declares "-path /to/cyclone" and both try to use [urn] which acts differently in zexy and cyclone.
As many things in Pd are global per default (value, send/receive, arrays, ...) it may make sense to add something like a "-localpath" option to [declare], so that abstraction authors could add their local settings to a canvas, while still accepting toplevel declarations:
"toplevel patch": [declare -path /to/zexy] [urn] <= zexy's urn [abstraction1] [abstraction2]
"abstration1": [declare -localpath /to/cyclone] [urn] <= cyclone's urn [abstraction1a] "abstration1a inside abs. 1": no "declare" [urn] <= zexy's urn, as abs. 1 only uses -localpath "abstration2": [declare -path /to/cyclone] [urn] <= zexy's urn, if main patch declares "zexy", cyclone's urn otherwise [abstraction2a] "abstration2a inside abs. 2": no "declare" [urn] <= as in abs. 2.But actually I would feel more comfortable if all settings would be local to a canvas. For example "abstraction2a" from above would act differently depending on the toplevel patc.
All local would conflict with your usage so far, though. OTOH it seems [import] tries to be just that (never used it, though): A modifier for the local canvas only, so maybe we can use both?
Ciao
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote:
Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to have
their own custom "#X declare" data.
- allow objectclasses to register their own declaration key words,
like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote:
Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to have
their own custom "#X declare" data.
- allow objectclasses to register their own declaration key words,
like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote:
Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to have
their own custom "#X declare" data.
- allow objectclasses to register their own declaration key words,
like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
OK, I took most of the patch (not the "realpath()" call which seems unrelated) and uploaded to SVN, unless I'm mistaken.
cheers Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner wrote:
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote:
Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to have
their own custom "#X declare" data.
- allow objectclasses to register their own declaration key words,
like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/ pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare - lib] and the libdir loader.
I can't see any problems that realpath() might cause.
.hc
On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
OK, I took most of the patch (not the "realpath()" call which seems unrelated) and uploaded to SVN, unless I'm mistaken.
cheers Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner wrote:
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote:
Hey,
So I am diving into the whole canvas-local namespace and [declare] issue these days. I like the new "#X declare"/ canvas_savedeclarationsto() functionality, I think it could be useful for a lot of things. I was thinking of making an API to use it in externals, something like sys_register_loader(). I have two questions, first, how entrenched is the current behavior of [declare]? It currently is only semi-functional, and I think few people use it.
The second is how to structure this for general use. I have thought of two ways:
- make "declare" the key word and allow other objectclasses to
have their own custom "#X declare" data.
- allow objectclasses to register their own declaration key
words, like [import] could have "#X import".
The first would mean changing the behavior of [declare], the second could lead to a big mess...
.hc
--
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
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
--
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
I might have missed it, but I didn't see that realpath() itself made it into the patch... ?
M
On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner wrote:
The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/ pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare - lib] and the libdir loader.
I can't see any problems that realpath() might cause.
.hc
On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
OK, I took most of the patch (not the "realpath()" call which seems unrelated) and uploaded to SVN, unless I'm mistaken.
cheers Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner wrote:
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
Hi all,
I use 'declare' all the time.. don't think it's semifunctional at all. I think the questions about how declares should act inside abstractions are hard to resolve; in my own usage (and in the way I suggest others might want to use declare) it's always in the main patch, as a way to show the patch what libraries, etc, it needs.
cheers Miller
On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner wrote: > >Hey, > >So I am diving into the whole canvas-local namespace and >[declare] >issue these days. I like the new "#X declare"/ >canvas_savedeclarationsto() functionality, I think it could be >useful >for a lot of things. I was thinking of making an API to use >it in >externals, something like sys_register_loader(). I have two >questions, first, how entrenched is the current behavior of >[declare]? It currently is only semi-functional, and I think few >people use it. > >The second is how to structure this for general use. I have >thought >of two ways: > >- make "declare" the key word and allow other objectclasses to >have >their own custom "#X declare" data. > >- allow objectclasses to register their own declaration key >words, >like [import] could have "#X import". > >The first would mean changing the behavior of [declare], the >second >could lead to a big mess... > >.hc > > >----------------------------------------------------------------- >-- >----- >---- > >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 > > > >_______________________________________________ >PD-dev mailing list >PD-dev@iem.at >http://lists.puredata.info/listinfo/pd-dev
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
--
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
The only real change to s_main.c in that path is the addition of realpath(). It seems that the function there is just copying the strings back and forth between sbuf and sbuf2, so I just added one more iteration of that back and forth for realpath().
.hc
On May 22, 2008, at 9:25 PM, Miller Puckette wrote:
I might have missed it, but I didn't see that realpath() itself made it into the patch... ?
M
On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner wrote:
The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/ pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare - lib] and the libdir loader.
I can't see any problems that realpath() might cause.
.hc
On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
OK, I took most of the patch (not the "realpath()" call which seems unrelated) and uploaded to SVN, unless I'm mistaken.
cheers Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner wrote:
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
The "semi-functional" part is the full paths that Marius mentioned.
Then the other question is how to use something like "#X declare"/ canvas_savedeclarationsto() in externals. I'd like to create an [import] modelled after Python's import does, so I'd like to use "#X declare"/canvas_savedeclarationsto() with it.
.hc
On May 19, 2008, at 6:33 PM, Miller Puckette wrote:
> Hi all, > > I use 'declare' all the time.. don't think it's > semifunctional at > all. > I think the questions about how declares should act inside > abstractions > are hard to resolve; in my own usage (and in the way I suggest > others might > want to use declare) it's always in the main patch, as a way to > show the > patch what libraries, etc, it needs. > > cheers > Miller > > On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner > wrote: >> >> Hey, >> >> So I am diving into the whole canvas-local namespace and >> [declare] >> issue these days. I like the new "#X declare"/ >> canvas_savedeclarationsto() functionality, I think it could be >> useful >> for a lot of things. I was thinking of making an API to use >> it in >> externals, something like sys_register_loader(). I have two >> questions, first, how entrenched is the current behavior of >> [declare]? It currently is only semi-functional, and I >> think few >> people use it. >> >> The second is how to structure this for general use. I have >> thought >> of two ways: >> >> - make "declare" the key word and allow other objectclasses to >> have >> their own custom "#X declare" data. >> >> - allow objectclasses to register their own declaration key >> words, >> like [import] could have "#X import". >> >> The first would mean changing the behavior of [declare], the >> second >> could lead to a big mess... >> >> .hc >> >> >> --------------------------------------------------------------- >> -- >> -- >> ----- >> ---- >> >> 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 >> >> >> >> _______________________________________________ >> PD-dev mailing list >> PD-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
--
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
------------------------------------------------------------------------ ----
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
I finally realized realpath() is a pre-existing function. (I imagined it was sitting in another source file that didn't make it to the patch)
but.. "man realpath" says "Avoid using this function. It is broken by design..." so I'm sceptical of the idea. Anyway, why can't [import] just make the call if it needs it?
cheers M
On Thu, May 22, 2008 at 09:33:14PM +0200, Hans-Christoph Steiner wrote:
The only real change to s_main.c in that path is the addition of realpath(). It seems that the function there is just copying the strings back and forth between sbuf and sbuf2, so I just added one more iteration of that back and forth for realpath().
.hc
On May 22, 2008, at 9:25 PM, Miller Puckette wrote:
I might have missed it, but I didn't see that realpath() itself made it into the patch... ?
M
On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner wrote:
The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/ pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare - lib] and the libdir loader.
I can't see any problems that realpath() might cause.
.hc
On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
OK, I took most of the patch (not the "realpath()" call which seems unrelated) and uploaded to SVN, unless I'm mistaken.
cheers Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner wrote:
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
I think I fixed the full paths bug, here's the commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9856
.hc
On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote:
> >I think this issue is pretty clear, and the languages that I know >would fall along the lines of "each patch/abstraction has its own >namespace" or in other words "#include only affects the one .c >file", "import only affects the one .py file", etc. So I agree >with Frank. Global settings are global, and canvas-local >settings >are local to the original file. > >The "semi-functional" part is the full paths that Marius >mentioned. > >Then the other question is how to use something like "#X >declare"/ >canvas_savedeclarationsto() in externals. I'd like to create an >[import] modelled after Python's import does, so I'd like to use >"#X declare"/canvas_savedeclarationsto() with it. > >.hc > >On May 19, 2008, at 6:33 PM, Miller Puckette wrote: > >>Hi all, >> >>I use 'declare' all the time.. don't think it's >>semifunctional at >>all. >>I think the questions about how declares should act inside >>abstractions >>are hard to resolve; in my own usage (and in the way I suggest >>others might >>want to use declare) it's always in the main patch, as a way to >>show the >>patch what libraries, etc, it needs. >> >>cheers >>Miller >> >>On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph Steiner >>wrote: >>> >>>Hey, >>> >>>So I am diving into the whole canvas-local namespace and >>>[declare] >>>issue these days. I like the new "#X declare"/ >>>canvas_savedeclarationsto() functionality, I think it could be >>>useful >>>for a lot of things. I was thinking of making an API to use >>>it in >>>externals, something like sys_register_loader(). I have two >>>questions, first, how entrenched is the current behavior of >>>[declare]? It currently is only semi-functional, and I >>>think few >>>people use it. >>> >>>The second is how to structure this for general use. I have >>>thought >>>of two ways: >>> >>>- make "declare" the key word and allow other objectclasses to >>>have >>>their own custom "#X declare" data. >>> >>>- allow objectclasses to register their own declaration key >>>words, >>>like [import] could have "#X import". >>> >>>The first would mean changing the behavior of [declare], the >>>second >>>could lead to a big mess... >>> >>>.hc >>> >>> >>>--------------------------------------------------------------- >>>-- >>>-- >>>----- >>>---- >>> >>>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 >>> >>> >>> >>>_______________________________________________ >>>PD-dev mailing list >>>PD-dev@iem.at >>>http://lists.puredata.info/listinfo/pd-dev > > > >----------------------------------------------------------------- >-- >-- >------- > >News is what people want to keep hidden and everything else is >publicity. - Bill Moyers > >
--
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
To quote the whole text:
Avoid using this function. It is broken by design since (unless using the non- standard resolved_path == NULL feature) it is impossible to determine a suitable size for the output buffer, resolved_path. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing memory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded.
I think whoever wrote that man page is really splitting hairs there, the FreeBSD/Mac OS X man page has no complaints about it. They are complaining that PATH_MAX _might_ not be defined. But on GNU/Linux, MinGW, and FreeBSD/Mac OS X, FILENAME_MAX _is_ defined. So just use FILENAME_MAX to allocate the buffer that realpath() uses (which was already happening anyway in s_main.c, but with MAXPDSTRING instead). It's a widely implemented POSIX function, how much more standard do you want? ;)
I think that Pd should give reliable information in the publically defined API (ok, s_stuff.h, but still). For example, it makes life easier in a lot of ways if you can count on sys_libdir being an absolute path, rather than making every other bit of code that might every use a path that is based on sys_libdir check to make sure that it is indeed absolute. The vast majority of the time, sys_libdir is an absolute path, and AFAIK, on Windows it is always an absolute path.
.hc
On May 22, 2008, at 9:44 PM, Miller Puckette wrote:
I finally realized realpath() is a pre-existing function. (I imagined it was sitting in another source file that didn't make it to the patch)
but.. "man realpath" says "Avoid using this function. It is broken by design..." so I'm sceptical of the idea. Anyway, why can't [import] just make the call if it needs it?
cheers M
On Thu, May 22, 2008 at 09:33:14PM +0200, Hans-Christoph Steiner wrote:
The only real change to s_main.c in that path is the addition of realpath(). It seems that the function there is just copying the strings back and forth between sbuf and sbuf2, so I just added one more iteration of that back and forth for realpath().
.hc
On May 22, 2008, at 9:25 PM, Miller Puckette wrote:
I might have missed it, but I didn't see that realpath() itself made it into the patch... ?
M
On Thu, May 22, 2008 at 09:22:12PM +0200, Hans-Christoph Steiner wrote:
The realpath() is definitely related. If you start Pd using a relative path, like I do when doing dev work (e.g. make && ../bin/ pd), then sys_libdir will be a relative path. That means it is impossible to make absolute paths using sys_libdir, which is what I need to do to make [import] work, or loading libdirs with [declare - lib] and the libdir loader.
I can't see any problems that realpath() might cause.
.hc
On May 22, 2008, at 8:45 PM, Miller Puckette wrote:
OK, I took most of the patch (not the "realpath()" call which seems unrelated) and uploaded to SVN, unless I'm mistaken.
cheers Miller
On Wed, May 21, 2008 at 08:22:23PM +0200, Hans-Christoph Steiner wrote:
I was looking into this a bit more, and from what I can tell, the canvas-local path (ce_path) is always relative to the path of the parent patch. Here's the commit for pd-extended that adds support for absolute paths:
http://pure-data.svn.sourceforge.net/viewvc/pure-data? view=rev&revision=9862
Also, I submitted a patch:
http://sourceforge.net/tracker/index.php? func=detail&aid=1917574&group_id=55736&atid=478072
.hc
On May 19, 2008, at 9:42 PM, Hans-Christoph Steiner wrote:
> > I think I fixed the full paths bug, here's the commit: > > http://pure-data.svn.sourceforge.net/viewvc/pure-data? > view=rev&revision=9856 > > .hc > > On May 19, 2008, at 8:03 PM, Hans-Christoph Steiner wrote: > >> >> I think this issue is pretty clear, and the languages that I >> know >> would fall along the lines of "each patch/abstraction has >> its own >> namespace" or in other words "#include only affects the one .c >> file", "import only affects the one .py file", etc. So I >> agree >> with Frank. Global settings are global, and canvas-local >> settings >> are local to the original file. >> >> The "semi-functional" part is the full paths that Marius >> mentioned. >> >> Then the other question is how to use something like "#X >> declare"/ >> canvas_savedeclarationsto() in externals. I'd like to >> create an >> [import] modelled after Python's import does, so I'd like to >> use >> "#X declare"/canvas_savedeclarationsto() with it. >> >> .hc >> >> On May 19, 2008, at 6:33 PM, Miller Puckette wrote: >> >>> Hi all, >>> >>> I use 'declare' all the time.. don't think it's >>> semifunctional at >>> all. >>> I think the questions about how declares should act inside >>> abstractions >>> are hard to resolve; in my own usage (and in the way I suggest >>> others might >>> want to use declare) it's always in the main patch, as a >>> way to >>> show the >>> patch what libraries, etc, it needs. >>> >>> cheers >>> Miller >>> >>> On Mon, May 19, 2008 at 06:28:31PM +0200, Hans-Christoph >>> Steiner >>> wrote: >>>> >>>> Hey, >>>> >>>> So I am diving into the whole canvas-local namespace and >>>> [declare] >>>> issue these days. I like the new "#X declare"/ >>>> canvas_savedeclarationsto() functionality, I think it >>>> could be >>>> useful >>>> for a lot of things. I was thinking of making an API to use >>>> it in >>>> externals, something like sys_register_loader(). I have two >>>> questions, first, how entrenched is the current behavior of >>>> [declare]? It currently is only semi-functional, and I >>>> think few >>>> people use it. >>>> >>>> The second is how to structure this for general use. I have >>>> thought >>>> of two ways: >>>> >>>> - make "declare" the key word and allow other >>>> objectclasses to >>>> have >>>> their own custom "#X declare" data. >>>> >>>> - allow objectclasses to register their own declaration key >>>> words, >>>> like [import] could have "#X import". >>>> >>>> The first would mean changing the behavior of [declare], the >>>> second >>>> could lead to a big mess... >>>> >>>> .hc >>>> >>>> >>>> ------------------------------------------------------------- >>>> -- >>>> -- >>>> -- >>>> ----- >>>> ---- >>>> >>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> PD-dev mailing list >>>> PD-dev@iem.at >>>> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> --------------------------------------------------------------- >> -- >> -- >> -- >> ------- >> >> News is what people want to keep hidden and everything else is >> publicity. - Bill Moyers >> >> > > > > > ---------------------------------------------------------------- > -- > -- > -- > ------ > > You can't steal a gift. Bird gave the world his music, and if > you > can hear it, you can have it. - Dizzy Gillespie > > >
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
--
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
I think, it's not yet "pretty clear" at all otherwise we wouldn't discuss this issue so often. Here are some random thoughts on the topic.
The languages you mentioned have something like a scope, they know global and local variables. In Pd, everything is global and there is no local scope as far as I can see. Even $0 evaluates to a global value, that is easily accessed from the outside of an abstraction. So you cannot just take a concept from, say, Python and include it one-to-one in Pd - it has to be adapted. (Also Pd has more in common with LISP or Lua than with C or Python IMO, so we should look there first.)
Currently [declare] modifies global settings like path and loaded libraries, that you normally modify outside of a patch with .pdsettings/.pdrc or command line options. That's simple and beautiful at first, but has the ugly side effect of conflicting declares, that need to be resolved. Having the toplevel [declare] win over other declarations is simple as well, but not that beautiful anymore as it makes writing abstractions more error prone because they cannot rely anymore on their own declarations being valid. So in the end I'd agree with you that we would (also?) need a way to modify settings in a non-global way. As far as I see it, we'd have two places for doing this: We could use a restricted scope for such declarations either
a) per abstraction i.e. in a region where $0 is equal. b) per subpatch: [pd zexy-is-loaded-here]
It could also be realised with messages sent to "pd-subname", but that's probably not a good idea because of execution order problems. Or is it?
Ciao
On May 20, 2008, at 8:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
I think, it's not yet "pretty clear" at all otherwise we wouldn't discuss this issue so often. Here are some random thoughts on the topic.
The languages you mentioned have something like a scope, they know global and local variables. In Pd, everything is global and there is no local scope as far as I can see. Even $0 evaluates to a global value, that is easily accessed from the outside of an abstraction. So you cannot just take a concept from, say, Python and include it one-to-one in Pd - it has to be adapted. (Also Pd has more in common with LISP or Lua than with C or Python IMO, so we should look there first.)
I don't know Lisp or Lua, so I can't speak to that. Please do give examples. Basically, I think that every objectclass should have its own namespace. That fits into the core idea of objectclasses being distinct, reusable modules of code. If the parent patch affects an abstraction, that makes the objectclass dependant on the parent patch, which is not a good thing.
Currently [declare] modifies global settings like path and loaded libraries, that you normally modify outside of a patch with .pdsettings/.pdrc or command line options. That's simple and beautiful at first, but has the ugly side effect of conflicting declares, that need to be resolved. Having the toplevel [declare] win over other declarations is simple as well, but not that beautiful anymore as it makes writing abstractions more error prone because they cannot rely anymore on their own declarations being valid. So in the end I'd agree with you that we would (also?) need a way to modify settings in a non-global way. As far as I see it, we'd have two places for doing this: We could use a restricted scope for such declarations either
a) per abstraction i.e. in a region where $0 is equal. b) per subpatch: [pd zexy-is-loaded-here]
It could also be realised with messages sent to "pd-subname", but that's probably not a good idea because of execution order problems. Or is it?
[declare -std*] modifies the global namespace [declare] with -lib and -path modify the canvas-local namespace. I think it should be like this:
- global namespace is global - local namespace for each distinct canvas (parent patch and abstractions)
Tcl has namespaces that can be used across procedure/class, provided you import them into procedure/class. I suppose Pd could have that too, so you could set dependencies across a whole project. But I don't see this as being especially useful in Pd, and it would add complexity.
If I write an objectclass (aka abstraction), I only want to have to think about what libs that objectclass needs. I don't want to think about how those libs related to other files in the project at that point. Having the local namespace per objectclass/abstraction allows for this.
.hc
Ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
[declare -std*] modifies the global namespace [declare] with -lib and -path modify the canvas-local namespace.
Not according to the help-file for declare, where the only difference between the options with "std" and those without is how the arguments are evaluated: "relative to the patch" for the naked, "relative to Pd" for the "std"-decorated versions of the options. There's nothing about scope in the help file (and I'm currently not taking into account how declare works in reality, as that is deliberatly restricted in 0.41)
Tcl has namespaces that can be used across procedure/class, provided you import them into procedure/class. I suppose Pd could have that too, so you could set dependencies across a whole project. But I don't see this as being especially useful in Pd, and it would add complexity.
If I write an objectclass (aka abstraction), I only want to have to think about what libs that objectclass needs. I don't want to think about how those libs related to other files in the project at that point. Having the local namespace per objectclass/abstraction allows for this.
Agreed. But it seems that's not what [declare] does ATM or was intended to do when Miller wrote it, while [import] was designed to do it, IIR. Lets not confuse the two.
Ciao
On May 20, 2008, at 2:12 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
[declare -std*] modifies the global namespace [declare] with -lib and -path modify the canvas-local namespace.
Not according to the help-file for declare, where the only difference between the options with "std" and those without is how the arguments are evaluated: "relative to the patch" for the naked, "relative to Pd" for the "std"-decorated versions of the options. There's nothing about scope in the help file (and I'm currently not taking into account how declare works in reality, as that is deliberatly restricted in 0.41)
I got it a bit mixed up the first time, -lib and -stdlib change the canvas-local path, and -path and -stdpath change the global path. According to the C code, that is what it does. Check out canvas_declare(), starting at line 1478:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/pd/src/ g_canvas.c?view=markup
This means append to the canvas-local search path(e->ce_path):
e->ce_path = namelist_append(e->ce_path, strbuf, 0);
.hc
Tcl has namespaces that can be used across procedure/class, provided you import them into procedure/class. I suppose Pd could have that too, so you could set dependencies across a whole project. But I don't see this as being especially useful in Pd, and it would add complexity.
If I write an objectclass (aka abstraction), I only want to have to think about what libs that objectclass needs. I don't want to think about how those libs related to other files in the project at that point. Having the local namespace per objectclass/abstraction allows for this.
Agreed. But it seems that's not what [declare] does ATM or was intended to do when Miller wrote it, while [import] was designed to do it, IIR. Lets not confuse the two.
Ciao
Frank Barknecht
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
On May 20, 2008, at 8:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
I think, it's not yet "pretty clear" at all otherwise we wouldn't discuss this issue so often. Here are some random thoughts on the topic.
The languages you mentioned have something like a scope, they know global and local variables. In Pd, everything is global and there is no local scope as far as I can see. Even $0 evaluates to a global value, that is easily accessed from the outside of an abstraction. So you cannot just take a concept from, say, Python and include it one-to-one in Pd - it has to be adapted. (Also Pd has more in common with LISP or Lua than with C or Python IMO, so we should look there first.)
I don't know Lisp or Lua, so I can't speak to that. Please do give examples. Basically, I think that every objectclass should have its own namespace. That fits into the core idea of objectclasses being distinct, reusable modules of code. If the parent patch affects an abstraction, that makes the objectclass dependant on the parent patch, which is not a good thing.
but if you use an abstraction inside another object, then all the variables of the parent patch should be available in the abstraction. additionally the local variables of the subpatch have higher priority and can overwrite the settings of the parent patche.
object1 declares to use urn from cycling -- by default all abstractions created inside object1 would also use urn from cycling, except if an abstraction declares to use urn from zexy.
Currently [declare] modifies global settings like path and loaded libraries, that you normally modify outside of a patch with .pdsettings/.pdrc or command line options. That's simple and beautiful at first, but has the ugly side effect of conflicting declares, that need to be resolved. Having the toplevel [declare] win over other declarations is simple as well, but not that beautiful anymore as it makes writing abstractions more error prone because they cannot rely anymore on their own declarations being valid. So in the end I'd agree with you that we would (also?) need a way to modify settings in a non-global way. As far as I see it, we'd have two places for doing this: We could use a restricted scope for such declarations either
a) per abstraction i.e. in a region where $0 is equal. b) per subpatch: [pd zexy-is-loaded-here]
It could also be realised with messages sent to "pd-subname", but that's probably not a good idea because of execution order problems. Or is it?
[declare -std*] modifies the global namespace [declare] with -lib and -path modify the canvas-local namespace.
I think "std" is misleading naming here! see the help file for declare. std here means that the path is relatice to the pd bin directory, it has nothing to do with global or local. marius.
On May 20, 2008, at 3:43 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
On May 20, 2008, at 8:54 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think this issue is pretty clear, and the languages that I know would fall along the lines of "each patch/abstraction has its own namespace" or in other words "#include only affects the one .c file", "import only affects the one .py file", etc. So I agree with Frank. Global settings are global, and canvas-local settings are local to the original file.
I think, it's not yet "pretty clear" at all otherwise we wouldn't discuss this issue so often. Here are some random thoughts on the topic.
The languages you mentioned have something like a scope, they know global and local variables. In Pd, everything is global and there is no local scope as far as I can see. Even $0 evaluates to a global value, that is easily accessed from the outside of an abstraction. So you cannot just take a concept from, say, Python and include it one-to-one in Pd - it has to be adapted. (Also Pd has more in common with LISP or Lua than with C or Python IMO, so we should look there first.)
I don't know Lisp or Lua, so I can't speak to that. Please do give examples. Basically, I think that every objectclass should have its own namespace. That fits into the core idea of objectclasses being distinct, reusable modules of code. If the parent patch affects an abstraction, that makes the objectclass dependant on the parent patch, which is not a good thing.
but if you use an abstraction inside another object, then all the variables of the parent patch should be available in the abstraction. additionally the local variables of the subpatch have higher priority and can overwrite the settings of the parent patche.
object1 declares to use urn from cycling -- by default all abstractions created inside object1 would also use urn from cycling, except if an abstraction declares to use urn from zexy.
This is exactly what I think would be a bad idea, then the objectclass/abstraction depends on the parent patch. Therefore the abstraction's/objectclass' functionality could change depending on which parent patch it was used with.
If this kind of functionality was really desired, there could be namespaces like in Tcl which could be imported on their own. But this would add a lot complexity with little gain, IMHO.
.hc
Currently [declare] modifies global settings like path and loaded libraries, that you normally modify outside of a patch with .pdsettings/.pdrc or command line options. That's simple and beautiful at first, but has the ugly side effect of conflicting declares, that need to be resolved. Having the toplevel [declare] win over other declarations is simple as well, but not that beautiful anymore as it makes writing abstractions more error prone because they cannot rely anymore on their own declarations being valid. So in the end I'd agree with you that we would (also?) need a way to modify settings in a non-global way. As far as I see it, we'd have two places for doing this: We could use a restricted scope for such declarations either
a) per abstraction i.e. in a region where $0 is equal. b) per subpatch: [pd zexy-is-loaded-here]
It could also be realised with messages sent to "pd-subname", but that's probably not a good idea because of execution order problems. Or is it?
[declare -std*] modifies the global namespace [declare] with -lib and -path modify the canvas-local namespace.
I think "std" is misleading naming here! see the help file for declare. std here means that the path is relatice to the pd bin directory, it has nothing to do with global or local. marius.
------------------------------------------------------------------------ ----
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hans-Christoph Steiner wrote:
On May 20, 2008, at 3:43 PM, marius schebella wrote:
but if you use an abstraction inside another object, then all the variables of the parent patch should be available in the abstraction. additionally the local variables of the subpatch have higher priority and can overwrite the settings of the parent patche.
object1 declares to use urn from cycling -- by default all abstractions created inside object1 would also use urn from cycling, except if an abstraction declares to use urn from zexy.
This is exactly what I think would be a bad idea, then the objectclass/abstraction depends on the parent patch. Therefore the abstraction's/objectclass' functionality could change depending on which parent patch it was used with.
If this kind of functionality was really desired, there could be namespaces like in Tcl which could be imported on their own. But this would add a lot complexity with little gain, IMHO.
no, if you write a standalone abstraction, then you put a declare inside the *abstraction*, so that it is independent from the parent patch. but maybe I am wrong: here is what you are suggesting: you have a patch, named mypatch that includes an abstraction called abstraction1. you declare to use zexy for your patch. but then, instead of declaring this for your whole project you are proposing that all abstractions inside your patch should fall back to an arbitrary namespace (defined by individual startup flags) and not to the settings of the parent patch. that does not make sense to me.
startup flag: -lib cyclone MYPATCH [ - declare zexy - // this is the namespace of mypatch, urn is the urn from zexy - abstraction1 [ --- // not using a declare here means urn is taken from cyclone - ] ]
I think there is a rule that says something like "keep the namespace for a variable as local as possible." marius.
On May 20, 2008, at 5:55 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
On May 20, 2008, at 3:43 PM, marius schebella wrote:
but if you use an abstraction inside another object, then all the variables of the parent patch should be available in the abstraction. additionally the local variables of the subpatch have higher priority and can overwrite the settings of the parent patche.
object1 declares to use urn from cycling -- by default all abstractions created inside object1 would also use urn from cycling, except if an abstraction declares to use urn from zexy.
This is exactly what I think would be a bad idea, then the objectclass/abstraction depends on the parent patch. Therefore the abstraction's/objectclass' functionality could change depending on which parent patch it was used with. If this kind of functionality was really desired, there could be namespaces like in Tcl which could be imported on their own. But this would add a lot complexity with little gain, IMHO.
no, if you write a standalone abstraction, then you put a declare inside the *abstraction*, so that it is independent from the parent patch. but maybe I am wrong: here is what you are suggesting: you have a patch, named mypatch that includes an abstraction called abstraction1. you declare to use zexy for your patch. but then, instead of declaring this for your whole project you are proposing that all abstractions inside your patch should fall back to an arbitrary namespace (defined by individual startup flags) and not to the settings of the parent patch. that does not make sense to me.
startup flag: -lib cyclone MYPATCH [
- declare zexy
- // this is the namespace of mypatch, urn is the urn from zexy
- abstraction1 [
--- // not using a declare here means urn is taken from cyclone
- ]
]
I think there is a rule that says something like "keep the namespace for a variable as local as possible." marius.
I am saying that the namespaces should either have effect globally or only for one patch/abstraction/objectclass.
.hc
------------------------------------------------------------------------ ----
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
-
Frank Barknecht -
Hans-Christoph Steiner -
marius schebella -
Miller Puckette