hi,
seems the [image] object (in flatspace) does not like spaces in folder or file names. if any folder in the path name has a space, image will not find the file. maybe this is known, but it is very annoying. again, intel mac, this time all pd versions (0.39, 0.40).
I would like to know if it is better to send such problems only as a bug report from the source forge site?
marius.
wether this is considered as a bug or not, i would avoid spaces in pathes, when working with pd. though spaces work sometimes, there are many cases, where spaces in symbols (pathes or filenames) cause trouble. for example, it is possible to let [openpanel] spit out a symbol, that contains spaces, but as soon as such a symbol is sent over net ([netsend]/[netreceive]), the symbol is converted to a list.
roman
On Wed, 2007-08-08 at 21:41 -0400, marius schebella wrote:
hi,
seems the [image] object (in flatspace) does not like spaces in folder or file names. if any folder in the path name has a space, image will not find the file. maybe this is known, but it is very annoying. again, intel mac, this time all pd versions (0.39, 0.40).
I would like to know if it is better to send such problems only as a bug report from the source forge site?
marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
yes, the lack of an escape character is a pain, but in this particular case I am not using the path at all. it is a local file, in the same folder as the patch. it is not a pd problem, but i suppose a bug in image. the image object is a very simple (and old) object, but it is also quite powerful. marius. ps.:another powerful ui object it pddplink.
Roman Haefeli wrote:
wether this is considered as a bug or not, i would avoid spaces in pathes, when working with pd. though spaces work sometimes, there are many cases, where spaces in symbols (pathes or filenames) cause trouble. for example, it is possible to let [openpanel] spit out a symbol, that contains spaces, but as soon as such a symbol is sent over net ([netsend]/[netreceive]), the symbol is converted to a list.
roman
On Wed, 2007-08-08 at 21:41 -0400, marius schebella wrote:
hi,
seems the [image] object (in flatspace) does not like spaces in folder or file names. if any folder in the path name has a space, image will not find the file. maybe this is known, but it is very annoying. again, intel mac, this time all pd versions (0.39, 0.40).
I would like to know if it is better to send such problems only as a bug report from the source forge site?
marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 2007-08-08 at 22:43 -0400, marius schebella wrote:
it is not a pd problem, but i suppose a bug in image.
though i don't know the internals of pd, i wouldn't be so sure about that. i don't know, if this is true, but i could imagine that pd passes an argument, that contains spaces, as several arguments to the external. so it could still be, that [image] would work correctly, but gets the filename as several arguments.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Wed, 2007-08-08 at 22:43 -0400, marius schebella wrote:
it is not a pd problem, but i suppose a bug in image.
though i don't know the internals of pd, i wouldn't be so sure about that. i don't know, if this is true, but i could imagine that pd passes an argument, that contains spaces, as several arguments to the external. so it could still be, that [image] would work correctly, but gets the filename as several arguments.
If the diff I just posted to SF is correct (I didn't do real tests, just confirmed that it fixes Marius' problem) it's just a tiny bug in image.c that's trivial to fix.
Frank Barknecht _ ______footils.org_ __goto10.org__
thanks, frank! does that diff make it automatically to the autobuilds? then I can test it. but I believe you probably fixed it. thanks! marius.
Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
On Wed, 2007-08-08 at 22:43 -0400, marius schebella wrote:
it is not a pd problem, but i suppose a bug in image.
though i don't know the internals of pd, i wouldn't be so sure about that. i don't know, if this is true, but i could imagine that pd passes an argument, that contains spaces, as several arguments to the external. so it could still be, that [image] would work correctly, but gets the filename as several arguments.
If the diff I just posted to SF is correct (I didn't do real tests, just confirmed that it fixes Marius' problem) it's just a tiny bug in image.c that's trivial to fix.
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
thanks, frank! does that diff make it automatically to the autobuilds? then I can test it. but I believe you probably fixed it. thanks!
It's not checked into the CVS. If you're on Linux, I could send you a binary, but I guess, you're not, otherwise you could probably compile it yourself ...
Frank Barknecht _ ______footils.org_ __goto10.org__
oh frank, forcing me into osx compiling...! ok, I got vanilla pd 0.41 compiled, it is not different than compiling on linux, although you have to do it from inside the .app structure. but I am stuck now, because I want to compile ggee now and don't know how to do that. I got the source from cvs. I didn't know how to apply the diff via shell command, but I changed that one line manually. but there is no configure skript, and just running make does not do it. where can I get a working makefile? or what do I need next? sorry for asking beginners questions for the 100th time. marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
thanks, frank! does that diff make it automatically to the autobuilds? then I can test it. but I believe you probably fixed it. thanks!
It's not checked into the CVS. If you're on Linux, I could send you a binary, but I guess, you're not, otherwise you could probably compile it yourself ...
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
oh frank, forcing me into osx compiling...! ok, I got vanilla pd 0.41 compiled, it is not different than compiling on linux, although you have to do it from inside the .app structure. but I am stuck now, because I want to compile ggee now and don't know how to do that. I got the source from cvs. I didn't know how to apply the diff via shell command, but I changed that one line manually. but there is no configure skript, and just running make does not do it. where can I get a working makefile? or what do I need next? sorry for asking beginners questions for the 100th time. marius.
I used the old build system: Go to /CVS/externals/build/darwin/ and type "make image.pd_darwin".
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I used the old build system: Go to /CVS/externals/build/darwin/ and type "make image.pd_darwin".
Ciao
that's all? I went to /CVS/externals/build/darwin/ and typed "make image.pd_darwin". all I get is make: *** No rule to make target `image.pd_darwin'. Stop. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
Frank Barknecht wrote:
I used the old build system: Go to /CVS/externals/build/darwin/ and type "make image.pd_darwin".
Ciao
that's all? I went to /CVS/externals/build/darwin/ and typed "make image.pd_darwin". all I get is make: *** No rule to make target `image.pd_darwin'. Stop.
Hm, no idea. But what the heck: I checked in my tiny change. If it breaks anything, I can always undo it again later. It should show up in the next autobuild.
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo Marius!
I would like to know if it is better to send such problems only as a bug report from the source forge site?
Don't think that its a bug, more a limitation of pd. You can:
a shell script)
with spaces) and then send it to the image object
LG Georg
On Thu, 9 Aug 2007, Georg Holzmann wrote:
I would like to know if it is better to send such problems only as a bug report from the source forge site?
Don't think that its a bug, more a limitation of pd.
Yes, let's ensure that pd remains buggy!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Georg Holzmann wrote:
Don't think that its a bug, more a limitation of pd.
as long as nobody knew about it, it was a bug (because the program would react unexpectedly in some situation). when it was discovered and documented you could call it limitation, but now, after frank looked at it, it is fixed.
You can:
- rename all spaces in your filenames with "_" (which is quite easy with
a shell script)
- make your path-symbol e.g. in python-pyext (where you can make strings
with spaces) and then send it to the image object
I was not talking about [pix_image], but [image] (originally in ggee).
marius.
On Thu, 2007-08-09 at 09:56 -0400, marius schebella wrote:
Georg Holzmann wrote:
Don't think that its a bug, more a limitation of pd.
as long as nobody knew about it, it was a bug (because the program would react unexpectedly in some situation).
(this is a bad definition of 'bug')
this is, what i was trying to say: you cannot expect symbols with spaces to work in pd (or can i? correct me, if i am wrong) using spaces is always a hack. that is why expressed uncertainty about this behaviour being a bug.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
this is, what i was trying to say: you cannot expect symbols with spaces to work in pd (or can i? correct me, if i am wrong) using spaces is always a hack. that is why expressed uncertainty about this behaviour being a bug.
Marius problem is not a space in a symbol in Pd land, but a space, created by [image] internally, which isn't escaped propely. To reproduce the bug try this:
$ mkdir "/tmp/space channel 5" $ cp ulala.gif "/tmp/space channel 5" $ cd "/tmp/space channel 5" $ pd &
and try to create an object [image ulala.gif]. This won't create!
But if you do a
$ mv "/tmp/space channel 5" /tmp/rez
and try the same thing again inside "/tmp/rez", [image ulala.gif] will create just fine.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 2007-08-09 at 19:08 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
this is, what i was trying to say: you cannot expect symbols with spaces to work in pd (or can i? correct me, if i am wrong) using spaces is always a hack. that is why expressed uncertainty about this behaviour being a bug.
Marius problem is not a space in a symbol in Pd land, but a space, created by [image] internally, which isn't escaped propely. To reproduce the bug try this:
$ mkdir "/tmp/space channel 5" $ cp ulala.gif "/tmp/space channel 5" $ cd "/tmp/space channel 5" $ pd &
and try to create an object [image ulala.gif]. This won't create!
But if you do a
$ mv "/tmp/space channel 5" /tmp/rez
and try the same thing again inside "/tmp/rez", [image ulala.gif] will create just fine.
ah, ok
thanks for clarification.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On_Thu,_9_Aug_2007,_Roman_Haefeli_wrote:>_this_is,_what_i_was_trying_to_say:_you_cannot_expect_symbols_with_spaces_to_work_in_pd_(or_can_i?_correct_me,_if_i_am_wrong)_using_spaces_is_always_a_hack._that_is_why_expressed_uncertainty_about_this_behaviour_being_a_bug.
Yes,_using_spaces_is_always_a_hack_because_one_can_write_everything_one_needs_to_write_using_only_underscores_just_like_this.|_Mathieu_Bouchard_-_tél:+1.514.383.3801,_Montréal_QC_Canada
Mathieu Bouchard schrieb:
On_Thu,_9_Aug_2007,_Roman_Haefeli_wrote:>_this_is,_what_i_was_trying_to_say:_you_cannot_expect_symbols_with_spaces_to_work_in_pd_(or_can_i?_correct_me,_if_i_am_wrong)_using_spaces_is_always_a_hack._that_is_why_expressed_uncertainty_about_this_behaviour_being_a_bug.
Yes,_using_spaces_is_always_a_hack_because_one_can_write_everything_one_needs_to_write_using_only_underscores_just_like_this.|_Mathieu_Bouchard_-_tél:+1.514.383.3801,_Montréal_QC_Canada
your_comments_are_always_the_best_ones_..._;)
LG Georg
On Thu, 2007-08-09 at 14:35 -0400, Mathieu Bouchard wrote:
On_Thu,_9_Aug_2007,_Roman_Haefeli_wrote:> [...] _using_spaces_is_always_a_hack. [...]
correction:
creating and dealing with spaces in puredata requires bad hacks.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de