On GNU/Linux and Windows, -stdpath work like this: [declare - stdpath ../extra/<somedir>]. On Mac OS X, you need to omit the "../", i.e. [declare -stdpath extra/<somedir>]. Since that means that [declare] with -stdpath has broken behavior, I want to suggest a change that would make it more intuitive but would break on all platforms:
Right now, I don't see any reason why -stdpath should include the "../ extra" part. Since all externals have been included in "pd/extra" by convention for a long time, it seems to me that it would make the most sense to make -stdpath relative to "/path/to/pd/extra". (I remember many years ago some people using an 'externs' folder, but I haven't seen/heard that in years). This would make the above [declare] like this:
[declare -stdpath <somedir>]
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
.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.
i am very much in favor of that change and i _don't_ care about any backwards compatibility issues, since [declare] has been proven to be very unreliable anyway. better to change it early, before usage of it is widely spread.
personally i think, that your suggestion is the layout, that makes most sense and it is intuitive to use.
roman
On Thu, 2008-05-29 at 00:34 +0200, Hans-Christoph Steiner wrote:
On GNU/Linux and Windows, -stdpath work like this: [declare - stdpath ../extra/<somedir>]. On Mac OS X, you need to omit the "../", i.e. [declare -stdpath extra/<somedir>]. Since that means that [declare] with -stdpath has broken behavior, I want to suggest a change that would make it more intuitive but would break on all platforms:
Right now, I don't see any reason why -stdpath should include the "../ extra" part. Since all externals have been included in "pd/extra" by convention for a long time, it seems to me that it would make the most sense to make -stdpath relative to "/path/to/pd/extra". (I remember many years ago some people using an 'externs' folder, but I haven't seen/heard that in years). This would make the above [declare] like this:
[declare -stdpath <somedir>]
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
.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
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
while we're at it: i noticed, that pd's path on linux pd is hardcoded into the binary, which means, that [declare -std*] doesn't work as expected, if you choose a different install directory (without recompiling), whereas on windows there is no hardcoded path of its own, which, IMO, is good, because you are free to put your pd binaries whereever you want. on windows it is easily possible to distribute a pd based project on a cd and run it directly from there, where this would cause troubles on linux. is that something, that could be fixed? or is there a well-founded reason for this?
roman
On Thu, 2008-05-29 at 01:22 +0200, Roman Haefeli wrote:
i am very much in favor of that change and i _don't_ care about any backwards compatibility issues, since [declare] has been proven to be very unreliable anyway. better to change it early, before usage of it is widely spread.
personally i think, that your suggestion is the layout, that makes most sense and it is intuitive to use.
roman
On Thu, 2008-05-29 at 00:34 +0200, Hans-Christoph Steiner wrote:
On GNU/Linux and Windows, -stdpath work like this: [declare - stdpath ../extra/<somedir>]. On Mac OS X, you need to omit the "../", i.e. [declare -stdpath extra/<somedir>]. Since that means that [declare] with -stdpath has broken behavior, I want to suggest a change that would make it more intuitive but would break on all platforms:
Right now, I don't see any reason why -stdpath should include the "../ extra" part. Since all externals have been included in "pd/extra" by convention for a long time, it seems to me that it would make the most sense to make -stdpath relative to "/path/to/pd/extra". (I remember many years ago some people using an 'externs' folder, but I haven't seen/heard that in years). This would make the above [declare] like this:
[declare -stdpath <somedir>]
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
.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
___________________________________________________________ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
I don't think there is any reason for this behavior on GNU/Linux besides it just hasn't been implemented. It wouldn't be too hard to implement, if anyone is interested in trying.
.hc
On May 29, 2008, at 1:51 AM, Roman Haefeli wrote:
while we're at it: i noticed, that pd's path on linux pd is hardcoded into the binary, which means, that [declare -std*] doesn't work as expected, if you choose a different install directory (without recompiling), whereas on windows there is no hardcoded path of its own, which, IMO, is good, because you are free to put your pd binaries whereever you want. on windows it is easily possible to distribute a pd based project on a cd and run it directly from there, where this would cause troubles on linux. is that something, that could be fixed? or is there a well-founded reason for this?
roman
On Thu, 2008-05-29 at 01:22 +0200, Roman Haefeli wrote:
i am very much in favor of that change and i _don't_ care about any backwards compatibility issues, since [declare] has been proven to be very unreliable anyway. better to change it early, before usage of it is widely spread.
personally i think, that your suggestion is the layout, that makes most sense and it is intuitive to use.
roman
On Thu, 2008-05-29 at 00:34 +0200, Hans-Christoph Steiner wrote:
On GNU/Linux and Windows, -stdpath work like this: [declare - stdpath ../extra/<somedir>]. On Mac OS X, you need to omit the "../", i.e. [declare -stdpath extra/<somedir>]. Since that means that [declare] with -stdpath has broken behavior, I want to suggest a change that would make it more intuitive but would break on all platforms:
Right now, I don't see any reason why -stdpath should include the "../ extra" part. Since all externals have been included in "pd/ extra" by convention for a long time, it seems to me that it would make the most sense to make -stdpath relative to "/path/to/pd/extra". (I remember many years ago some people using an 'externs' folder, but I haven't seen/heard that in years). This would make the above [declare] like this:
[declare -stdpath <somedir>]
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
.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
___________________________________________________________ Der frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
------------------------------------------------------------------------ ----
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
I agree with Roman. Just got a question, below.
On 29/05/2008, at 0.34, Hans-Christoph Steiner wrote:
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
How does that work when, say, Gem is installed into '/path/to/pd/ extra/Gem/Gem.<platform>'? Is it [declare -stdlib Gem/Gem] or [declare -stdlib Gem]?
I think the later fits your simplicity-layout for the '-stdpath' option, but i thought that then the lib need be directly in "extra" not in a subfolder there of? If so would that then mean that one are to do both [declare -stdpath Gem] _and_ [declare -stdlib Gem] in the same Pd-patch for that to work?
Steffen Juul wrote:
I agree with Roman. Just got a question, below.
On 29/05/2008, at 0.34, Hans-Christoph Steiner wrote:
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
How does that work when, say, Gem is installed into '/path/to/pd/ extra/Gem/Gem.<platform>'? Is it [declare -stdlib Gem/Gem] or [declare -stdlib Gem]?
both are valid. Pd searches for <libname>.<ext> as well as <libname>/<libname>.<ext>
I think the later fits your simplicity-layout for the '-stdpath' option, but i thought that then the lib need be directly in "extra" not in a subfolder there of? If so would that then mean that one are to do both [declare -stdpath Gem] _and_ [declare -stdlib Gem] in the same Pd-patch for that to work?
you would have to do that anyhow, since Gem comes with abstractions that are living in extra/Gem/. i have no real solution for this yet: one possibility would be to add the path to the binary to the searchpaths once the library is loaded (similar to [import]); the code is already there in Gem (but usually disabled at compile-time, iirc)
mfg.asdr IOhannes
the help patch of declare says -stdpath is relative to Pd. this does not necessarily mean it has to be the pd binary, it could mean, the Pd root directory, which would be the folder that contains bin and extra. but certainly not relative to the extra directory of pd.
I think -stdpath extra/somedir is the way to go. but without the "../". (maybe that is only because I am used to it from mac.) but I also think people will want to include things that are not necessarily in extra.
marius.
Hans-Christoph Steiner wrote:
On GNU/Linux and Windows, -stdpath work like this: [declare - stdpath ../extra/<somedir>]. On Mac OS X, you need to omit the "../", i.e. [declare -stdpath extra/<somedir>]. Since that means that [declare] with -stdpath has broken behavior, I want to suggest a change that would make it more intuitive but would break on all platforms:
Right now, I don't see any reason why -stdpath should include the "../ extra" part. Since all externals have been included in "pd/extra" by convention for a long time, it seems to me that it would make the most sense to make -stdpath relative to "/path/to/pd/extra". (I remember many years ago some people using an 'externs' folder, but I haven't seen/heard that in years). This would make the above [declare] like this:
[declare -stdpath <somedir>]
I think the same would apply to -stdlib:
[declare -stdlib <somedir>]
.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
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
marius schebella -
Roman Haefeli -
Steffen Juul