hi
originally i wanted to write the following feature-request: using [declare] to load libraries (e.g. [declare -lib mylib]) works nicely. however, when i have several abstractions all depending on the same library (and thus all have an instance of [declare -lib mylib]), i get an error "mylib: already loaded" for each abstraction depending on "mylib" but the first. would it be possible to suppress this warning? (i don't see a reason to keep it)
i wrote a wee example to illustrate this behaviour, and while doing so i noticed a real weirdness: when i save a patch holding an abstraction with a [declare -lib mylib], this parent patch will also have the "#X declare -lib mylib" line (without a direct representation in the patch) what is even weirder is, that it gets an additional line for each abstraction containing a [declare]. e.g. if i have 4 instances of an abstraction in my patch, i will get 4 additional declare-lines. loading this patch, i will get 7 errors that "mylib: already loaded" (4 warnings from the abstractions; 3 warnings from the patch; only the 1st declare-line in the patch gets evaluated properly)
is this by design? or is it a "bug"? (i cannot see any harm right now, but it is a bit annoying)
all this is happening with Pd-0.41-0test11 on linux.
fgmasdr. IOhannes
Hmm. It never occured to me that people would want to put declare objects inside abstractions (I think it's unwise to do so because there's no way to contain the declare object's effects to within the abstraction.)
That it's adding stuff to the parent patch is a serious bug; there's no reason to believe that putting declare in abstractions is doing a useful thing at all at present!
cheers Miller
On Wed, Jan 23, 2008 at 04:58:38PM +0100, IOhannes m zmoelnig wrote:
hi
originally i wanted to write the following feature-request: using [declare] to load libraries (e.g. [declare -lib mylib]) works nicely. however, when i have several abstractions all depending on the same library (and thus all have an instance of [declare -lib mylib]), i get an error "mylib: already loaded" for each abstraction depending on "mylib" but the first. would it be possible to suppress this warning? (i don't see a reason to keep it)
i wrote a wee example to illustrate this behaviour, and while doing so i noticed a real weirdness: when i save a patch holding an abstraction with a [declare -lib mylib], this parent patch will also have the "#X declare -lib mylib" line (without a direct representation in the patch) what is even weirder is, that it gets an additional line for each abstraction containing a [declare]. e.g. if i have 4 instances of an abstraction in my patch, i will get 4 additional declare-lines. loading this patch, i will get 7 errors that "mylib: already loaded" (4 warnings from the abstractions; 3 warnings from the patch; only the 1st declare-line in the patch gets evaluated properly)
is this by design? or is it a "bug"? (i cannot see any harm right now, but it is a bit annoying)
all this is happening with Pd-0.41-0test11 on linux.
fgmasdr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo!
Hmm. It never occured to me that people would want to put declare objects inside abstractions (I think it's unwise to do so because there's no way to contain the declare object's effects to within the abstraction.)
IMHO using declare in abstractions should be done (reusability ...), otherwise also the declare object itself would make much less sense ...
If you write a library in C you also use #include in this library and not in the main program where you are using the lib.
LG Georg
On Wed, 2008-01-23 at 08:25 -0800, Miller Puckette wrote:
Hmm. It never occured to me that people would want to put declare objects inside abstractions (I think it's unwise to do so because there's no way to contain the declare object's effects to within the abstraction.)
That it's adding stuff to the parent patch is a serious bug; there's no reason to believe that putting declare in abstractions is doing a useful thing at all at present!
please don't feel offended, but did you seriously test [declare] within abstractions? i did test [declare -stdpath] in pd-0.40.3 (see my mail in pd-dev [1]) and it works as at least i would expect it: it adds the path to the abstractions search pathes only, but not to the parent patch. if this is _not_ the expected behaviour, then lets define some [declare] test environment for all different flags in order to avoid declare confusions in the future.
[1] http://lists.puredata.info/pipermail/pd-dev/2008-01/010643.html
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
No, I never tried, thinking, as I do, that it couldn't possibly work :)
Anyway, I can't imagine changing it so close to a release, since anything that could be considered "correct" would take months of testing to get working correctly, so, like it or not, I think I have to try to figure out what it does and make sre it keeps doing that.
cheers Miller
On Wed, Jan 23, 2008 at 05:48:50PM +0100, Roman Haefeli wrote:
On Wed, 2008-01-23 at 08:25 -0800, Miller Puckette wrote:
Hmm. It never occured to me that people would want to put declare objects inside abstractions (I think it's unwise to do so because there's no way to contain the declare object's effects to within the abstraction.)
That it's adding stuff to the parent patch is a serious bug; there's no reason to believe that putting declare in abstractions is doing a useful thing at all at present!
please don't feel offended, but did you seriously test [declare] within abstractions? i did test [declare -stdpath] in pd-0.40.3 (see my mail in pd-dev [1]) and it works as at least i would expect it: it adds the path to the abstractions search pathes only, but not to the parent patch. if this is _not_ the expected behaviour, then lets define some [declare] test environment for all different flags in order to avoid declare confusions in the future.
[1] http://lists.puredata.info/pipermail/pd-dev/2008-01/010643.html
roman
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2008-01-23 at 10:54 -0800, Miller Puckette wrote:
No, I never tried, thinking, as I do, that it couldn't possibly work :)
Anyway, I can't imagine changing it so close to a release, since anything that could be considered "correct" would take months of testing to get working correctly, so, like it or not, I think I have to try to figure out what it does and make sre it keeps doing that.
good news!
if i can help you in anyway (e.g. documenting as accurately as possible how [declare] behaves), i'd be glad to do so. i am very much convinced, that [declare] is a useful class and worth a lot of effort to make it work.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
good news!
if i can help you in anyway (e.g. documenting as accurately as possible how [declare] behaves), i'd be glad to do so. i am very much convinced, that [declare] is a useful class and worth a lot of effort to make it work.
roman
Yeah, I find it very useful too. (even though I've never tried it in an abstraction :)
M
I think very few people are using [declare]. I think Pd would be
much better off with a well functioning [declare] than just freezing
the current functionality.
.hc
On Jan 23, 2008, at 1:54 PM, Miller Puckette wrote:
No, I never tried, thinking, as I do, that it couldn't possibly
work :)Anyway, I can't imagine changing it so close to a release, since
anything that could be considered "correct" would take months of testing to get working correctly, so, like it or not, I think I have to try to
figure out what it does and make sre it keeps doing that.cheers Miller
On Wed, Jan 23, 2008 at 05:48:50PM +0100, Roman Haefeli wrote:
On Wed, 2008-01-23 at 08:25 -0800, Miller Puckette wrote:
Hmm. It never occured to me that people would want to put
declare objects inside abstractions (I think it's unwise to do so because there's
no way to contain the declare object's effects to within the abstraction.)That it's adding stuff to the parent patch is a serious bug;
there's no reason to believe that putting declare in abstractions is doing a
useful thing at all at present!please don't feel offended, but did you seriously test [declare]
within abstractions? i did test [declare -stdpath] in pd-0.40.3 (see my
mail in pd-dev [1]) and it works as at least i would expect it: it adds
the path to the abstractions search pathes only, but not to the parent
patch. if this is _not_ the expected behaviour, then lets define some [declare] test environment for all different flags in order to avoid declare confusions in the future.[1] http://lists.puredata.info/pipermail/pd-dev/2008-01/010643.html
roman
___________________________________________________________ Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo!
Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
http://at.or.at/hans/
-
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette -
Roman Haefeli