I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately.
Try it in tomorrow's builds and let me know if you think its useful.
.hc
Mistrust authority - promote decentralization. - the hacker ethic
Le 2011-12-01 à 00:21:00, Hans-Christoph Steiner a écrit :
I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately.
When there's a [path] object that has taken effect, and you go to the Path dialogue and save, does it also save the folder name that was just added by the [path] object ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Dec 1, 2011, at 12:32 AM, Mathieu Bouchard wrote:
Le 2011-12-01 à 00:21:00, Hans-Christoph Steiner a écrit :
I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately.
When there's a [path] object that has taken effect, and you go to the Path dialogue and save, does it also save the folder name that was just added by the [path] object ?
[path] only touches the canvas-local path, so it doesn't affect the global path that is set with "pd -path" and "Path..." prefs.
.hc
There is no way to peace, peace is the way. -A.J. Muste
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hmm, my usual 2 remarks:
On 2011-12-01 06:21, Hans-Christoph Steiner wrote:
I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately.
#1 do you think "path" is a good name, or will people confuse that with "getdir"? probably [searchpath] would be more meaningful.
#2 how does this object relate to the quest to eliminate path settings alltogether? i thought "-path" is really only for nerds like me who feel unable to use standard paths :-)
#3 could anybody tell me why [declare] does not take immediate effect?
fgmasrd IOhannes
Hi IOhannes
On Thu, 2011-12-01 at 11:45 +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hmm, my usual 2 remarks:
On 2011-12-01 06:21, Hans-Christoph Steiner wrote:
#2 how does this object relate to the quest to eliminate path settings alltogether? i thought "-path" is really only for nerds like me who feel unable to use standard paths :-)
Currently to only way to enable paths relative to patch is using [declare], which does not take immediate effect. As I understand, [path] is supposed to replace [declare -path], so it provides an alternative (immediate) way to load (non-standard) paths. So it helps at least as much as [declare] to eliminate any global path settings and let the patch handle the paths by itself.
#3 could anybody tell me why [declare] does not take immediate effect?
I'll try to explain the way of how (I think) [declare] works.
When you create a [declare] object somewhere in your patch, it just does nothing at all at this moment. Only when you save your patch, Pd will parse the patch and thus look for any [declare] objects and insert right after the first line of the file one additional line per declare object like this:
#X declare -stdpath extra/osc;
Please note, there is still the original:
#X obj 12 72 declare -stdpath extra/osc;
line somewhere in the patch, which refers to the actual [declare] object.
When loading the patch the next time, Pd will find the '#X declare' line and enable libraries and paths accordingly _before_ the rest of the patch is loaded. This is why [declare] does not take immediate effect.
Roman
P.S.: This (IMHO, a bit kludgey) way of how [declare] works is also the reason, why abstractions containing [declare] objects pollute the most parent patch, when the latter is saved, which is IMHO a relatively serious bug. Please refer to [1] for more details. [1] http://sourceforge.net/tracker/?func=detail&aid=2251387&group_id=557...
On Dec 1, 2011, at 5:45 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hmm, my usual 2 remarks:
On 2011-12-01 06:21, Hans-Christoph Steiner wrote:
I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately.
#1 do you think "path" is a good name, or will people confuse that with "getdir"? probably [searchpath] would be more meaningful.
I'm not stuck on the name 'path', but I do insist on consistency. The prefs are called "Path...", the [declare] flag is called -path, and the command line arg is called -path.
#2 how does this object relate to the quest to eliminate path settings alltogether? i thought "-path" is really only for nerds like me who feel unable to use standard paths :-)
It makes sense to be able to set a project-specific folder for libs included with the project. I've actually been thinking that we should set one more default path: a path relative to the patch for embedding libs in a standard way. It could just be "." or it could be "abs", "lib", or something like that.
#3 could anybody tell me why [declare] does not take immediate effect?
Check declare_new() in g_canvas.c
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 17:34, Hans-Christoph Steiner wrote:
#1 do you think "path" is a good name, or will people confuse that with "getdir"? probably [searchpath] would be more meaningful.
I'm not stuck on the name 'path', but I do insist on consistency. The prefs are called "Path...", the [declare] flag is called -path, and the command line arg is called -path.
so why is [import] not called [lib]?
while i beg for consistency myself, you must not forget the context where things appear. "path" in the context of starting an application can well mean something different than in the context of creating a programme, dealing with sound files. also i would not mind renaming the "Path..." to "Search paths..." in the prefs panel (i would object in the startup flags, for compatibility reasons)
#3 could anybody tell me why [declare] does not take immediate effect?
Check declare_new() in g_canvas.c
this question was not a technical one. i understand the implementation and its implications pretty well. nevertheless, i find the behaviour confusing and unintuitive. to rephrase my question: #3 could anybody tell me, why [declare] is implemented in a way that it doesn't take immediate effect?
fmasdr IOhannes
On Dec 1, 2011, at 1:09 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 17:34, Hans-Christoph Steiner wrote:
#1 do you think "path" is a good name, or will people confuse that with "getdir"? probably [searchpath] would be more meaningful.
I'm not stuck on the name 'path', but I do insist on consistency. The prefs are called "Path...", the [declare] flag is called -path, and the command line arg is called -path.
so why is [import] not called [lib]?
while i beg for consistency myself, you must not forget the context where things appear. "path" in the context of starting an application can well mean something different than in the context of creating a programme, dealing with sound files. also i would not mind renaming the "Path..." to "Search paths..." in the prefs panel (i would object in the startup flags, for compatibility reasons)
The prefs are called "Startup..." and the cmd line and [declare] flag is called "-lib", so its less consistent than "path". I chose the name 'import' because its commonly used for loading libs in a number of langauges like Java and Python.
#3 could anybody tell me why [declare] does not take immediate effect?
Check declare_new() in g_canvas.c
this question was not a technical one. i understand the implementation and its implications pretty well. nevertheless, i find the behaviour confusing and unintuitive. to rephrase my question: #3 could anybody tell me, why [declare] is implemented in a way that it doesn't take immediate effect?
Its a tricky problem because if you have a patch, then you add [declare], [path] or [import] to it it could modify how the existing part of the patch is loaded the next time its opened since the #X declare stuff would then be loaded first.
It seems to me that ideally, [declare], [import], [path], etc. would reload the patch when instantiated the first time so that the patch would always behave the same. But then the patch would loose its state, so there would have to be a special condition of reloading where it saves the state, reloads, then puts the state info back in.
.hc
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 19:41, Hans-Christoph Steiner wrote:
The prefs are called "Startup..." and the cmd line and [declare] flag is called "-lib", so its less consistent than "path". I chose the name 'import' because its commonly used for loading libs in a number of langauges like Java and Python.
i'm not saying that "import" is a bad name. actually i think it is a good name. i'm only saying that "path" might be a sub-optimal name. e.g [split_path] won't split the "path" you are talking about in [path], though the consistency suggests it.
otoh, your argument about the labels in the prefs are a bit void, given that they are meant to be translated. i don't see much consistency if "Pfad..." refers to the same as [path], but [path] and [split_path] are unrelated.
fgmasdr IOhannes
On Dec 1, 2011, at 2:08 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 19:41, Hans-Christoph Steiner wrote:
The prefs are called "Startup..." and the cmd line and [declare] flag is called "-lib", so its less consistent than "path". I chose the name 'import' because its commonly used for loading libs in a number of langauges like Java and Python.
i'm not saying that "import" is a bad name. actually i think it is a good name. i'm only saying that "path" might be a sub-optimal name. e.g [split_path] won't split the "path" you are talking about in [path], though the consistency suggests it.
otoh, your argument about the labels in the prefs are a bit void, given that they are meant to be translated. i don't see much consistency if "Pfad..." refers to the same as [path], but [path] and [split_path] are unrelated.
I think [split_path] is not well named.
.hc
¡El pueblo unido jamás será vencido!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 19:41, Hans-Christoph Steiner wrote:
#3 could anybody tell me, why [declare] is implemented in a way that it doesn't take immediate effect?
Its a tricky problem because if you have a patch, then you add [declare], [path] or [import] to it it could modify how the existing part of the patch is loaded the next time its opened since the #X declare stuff would then be loaded first.
actually i don't see much problems here. if i create a patch with a [loadbang]->[; pd quit( then the patch will behave differently during creation time (it will do nothing) and during runtime (it will quit Pd). if i want to have the effect at creation time, i can manually bang whatever is connected to [loadbang].
otoh, when i add [declare -path foo/], this is usually because i found out that a certain path is missing, and i cannot proceed with patching, until that path is added. the current situation makes it really complicated for people who had no clue what they wanted to do when they started Pd.
fgamsdr IOhannes
On Dec 1, 2011, at 2:14 PM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-01 19:41, Hans-Christoph Steiner wrote:
#3 could anybody tell me, why [declare] is implemented in a way that it doesn't take immediate effect?
Its a tricky problem because if you have a patch, then you add [declare], [path] or [import] to it it could modify how the existing part of the patch is loaded the next time its opened since the #X declare stuff would then be loaded first.
actually i don't see much problems here. if i create a patch with a [loadbang]->[; pd quit( then the patch will behave differently during creation time (it will do nothing) and during runtime (it will quit Pd). if i want to have the effect at creation time, i can manually bang whatever is connected to [loadbang].
otoh, when i add [declare -path foo/], this is usually because i found out that a certain path is missing, and i cannot proceed with patching, until that path is added. the current situation makes it really complicated for people who had no clue what they wanted to do when they started Pd.
I think its better to have it added immediately, that's one reason why I wrote [import] and [path]. But its far from the ideal behavior. One example of where it could cause problems is when it causes a different object to be loaded under a given name, i.e.:
[foo] [import foolib2]
[foo] could be already loaded from foolib1, then when this patch is reloaded, it'll be from foolib2.
.hc
There is no way to peace, peace is the way. -A.J. Muste
Le 2011-12-01 à 19:09:00, IOhannes m zmoelnig a écrit :
so why is [import] not called [lib]?
good point...
while i beg for consistency myself, you must not forget the context where things appear. "path" in the context of starting an application can well mean something different than in the context of creating a programme, dealing with sound files. also i would not mind renaming the "Path..." to "Search paths..." in the prefs panel (i would object in the startup flags, for compatibility reasons)
Also another good point...
Though, would you rename -path to -searchpath as well ? (possibly as an alias for compatibility, just like -nosound is -noaudio).
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2011-12-01 à 11:34:00, Hans-Christoph Steiner a écrit :
On Dec 1, 2011, at 5:45 AM, IOhannes m zmoelnig wrote:
#1 do you think "path" is a good name, or will people confuse that with "getdir"? probably [searchpath] would be more meaningful.
I'm not stuck on the name 'path', but I do insist on consistency. The prefs are called "Path...", the [declare] flag is called -path, and the command line arg is called -path.
the C interface to the path is named «sys_searchpath». I suppose that this is where Johannes got his idea from.
I'm not advocating for it though. It's best to stick with what the user knows when there are no reasons to do it otherwise. There are often reasons to do it otherwise, but this doesn't seem like one.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Thu, 2011-12-01 at 00:21 -0500, Hans-Christoph Steiner wrote:
I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately.
Try it in tomorrow's builds and let me know if you think its useful.
.hc
Wow, thanks! I'll try it out as soon as possible.
Roman
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Roman Haefeli