Bugs item #1738708, was opened at 2007-06-17 12:53 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1738708...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: won't open files with $0 in file name
Initial Comment:
In Pd-0.40-2, it won't open a file that has a $0 in the filename. This works fine on Pd-0.39.2-extended-rc4 and Pd-0.39-2.
This is on Mac OS X/Intel 10.4.9
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2007-06-18 18:05
Message: Logged In: YES user_id=27104 Originator: YES
The original example file should be called "array with $0.pd".
As for how to handle these, I don't think we should do anything special for abstractions, they can be left as is, otherwise it'll induce confusion, IMHO. I am just thinking that people's patches might have something like "this patch earned me $2.pd" and they would like to be able to open it.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar) Date: 2007-06-18 05:03
Message: Logged In: YES user_id=569446 Originator: NO
If you move the $0 in the filename to the front of the filename like $0-file.pd, then no version of Pd I know of can open them from the menu, including pd-extended. All Pd-versions open the file using the command line quite okay, but even then saving the file still doesn't work.
Ths isn't restricted to $0, the same also happens for other dollar-variables like $1-file.pd.
Maybe the more interesting question is: How should Pd deal with these filenames? $1 for example is treated as a variable in object names, that is replaced by the abstraction argument. If I use an abstraction [$1-file] then in fact I'm trying to load a file depending on the value of $1 in Pd-space, for example "0-file.pd". To be able to actually use the dollar in the object name, we'd need a more general escaping mechanism which would allow using an abstraction with an escaped dollar sign, for example [$1-file]. This however is a much bigger problem to solve in a smart (or in a stupid) way.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-06-18 03:45
Message: Logged In: YES user_id=564396 Originator: NO
so this time to concentrate on objects with "$0" in them, e.g. [parent$0] or [array-with-$0]
these do not load anymore on recent versions of pd, since the $0 is expanded at runtime, therefore pd is in fact looking for an object e.g. [parent1004] (which it cannot find). i do not see any solution for this, unless you do not want in-symbol expansion of $args (which i think we all agreed is a good thing to have).
obviously one could make a special rule for $0 in object names (this is: the 0th argument of an object box; all other arguments should be treated "normally"); but i do think that this is counterproductive ($args are complicated to understand anyhow; adding exception rules will make things only worse)
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-06-18 03:40
Message: Logged In: YES user_id=564396 Originator: NO
could you add an example? i am not sure how you try to open the file: - via the file->open menu? - via a message? - as abstraction? - ...?
what is the expected behaviour in the light of the extended $arg-expansion? (e.g is it related to the [parent$0] problem? there won't be a solution for this until we there is an escaping mechanism)
i am not sure i can reproduce any problem with the attached file on 0.40-1: it downloads as "array" (without extension), so i had to rename it to array.pd; but i guess this has exactly undone the problem you described.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1738708...
SourceForge.net wrote:
The original example file should be called "array with $0.pd".
still frank is right when he says you shouldn't upload filenames with spaces to the sf tracker... and i add that you shouldn't use filenames with spaces at all. (though you could try to name your directories "AUX", which is fun too...)
As for how to handle these, I don't think we should do anything special for abstractions, they can be left as is, otherwise it'll induce confusion, IMHO. I am just thinking that people's patches might have something like "this patch earned me $2.pd" and they would like to be able to open it.
so you are rather suggesting that people should be able to File->Open any file that they can find via the filebrowser? but not necessarily be able to use them as abstractions? e.g. filenames with spaces map very badly to classnames (even though it is possible).
i basically agree.
(but then i never made a big distinction between patches and abstractions (on the filesystem level): all my abstractions started as standalone patches; many standalone patches evolved into abstractions. this needs extra work if the patch-filename is something i cannot use as an abstraction name.)
mh.adft IOhannes
IOhannes m zmoelnig wrote:
still frank is right when he says you shouldn't upload filenames with spaces to the sf tracker... and i add that you shouldn't use filenames with spaces at all. (though you could try to name your directories "AUX", which is fun too...)
on rereading this, i want to add that "you" is no-one particular, but rather anyone.
so you are rather suggesting that people should be able to File->Open
here the "you" is someone special.
fmga.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
so you are rather suggesting that people should be able to File->Open any file that they can find via the filebrowser? but not necessarily be able to use them as abstractions? e.g. filenames with spaces map very badly to classnames (even though it is possible).
i basically agree.
I agree, too, because that's the best reason I heard so far to finally get rid of [namecanvas] for real. ;)
Ciao
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I agree, too, because that's the best reason I heard so far to finally get rid of [namecanvas] for real. ;)
Ah, sorry, I had my thoughts reversed. Please ignore my remark.
Ciao
-
Frank Barknecht -
IOhannes m zmoelnig -
SourceForge.net