There is a problem on Windows that has me stumped. If you open a file with a non-ASCII character in the name or path using "pd -open" it works fine. If you open it using File -> Open, then it freezes Pd. If you print the filename to the Pd window right before its sent to Pd, it prints properly:
C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd
But running "pd.com -d 3" shows:
pd open comma,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop; open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory comma,co├╝├╝├╝mma.pd: No such file or directory
So somewhere in the network receiving the unicode is going wrong, but only on Windows. Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas?
.hc
I've tried with extended-20120720 on windows vista, menu open doesn't crash but console says:
"Ignoring 'C:/Users/patko/Desktop/comma,coüüümmat,.pd': doesn't look like a Pd-file"
while in cmd it opens the non ascii file with "pd -open "comma,coΓΌΓΌΓΌmmat,.pd" after using tab key of course.
Colet Patrice
----- Mail original -----
De: "Hans-Christoph Steiner" hans@at.or.at À: "pd-dev@iem.at List" pd-dev@iem.at Envoyé: Jeudi 6 Décembre 2012 05:14:58 Objet: [PD-dev] UTF-8 problems on Windows
There is a problem on Windows that has me stumped. If you open a file with a non-ASCII character in the name or path using "pd -open" it works fine. If you open it using File -> Open, then it freezes Pd. If you print the filename to the Pd window right before its sent to Pd, it prints properly:
C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd
But running "pd.com -d 3" shows:
pd open comma,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop; open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory comma,co├╝├╝├╝mma.pd: No such file or directory
So somewhere in the network receiving the unicode is going wrong, but only on Windows. Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas?
.hc _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Hans
I probably have nothing useful to add, but just last week I got a report from someone using a patch of mine on Windows, experiencing troubles with opening certain sound files. It turned out, that it was also related to non-ASCII characters in the name of those files. Pd didn't crash, though, but the sound files didn't load. I hadn't have the opportunity to look at it myself yet (no access to a win comp), but I'm glad to see it confirmed. I'd be happy to see it fixed, though probably my only contribution would be limited to testing.
Roman
On Mit, 2012-12-05 at 23:14 -0500, Hans-Christoph Steiner wrote:
There is a problem on Windows that has me stumped. If you open a file with a non-ASCII character in the name or path using "pd -open" it works fine. If you open it using File -> Open, then it freezes Pd. If you print the filename to the Pd window right before its sent to Pd, it prints properly:
C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd
But running "pd.com -d 3" shows:
pd open comma,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop; open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory comma,co├╝├╝├╝mma.pd: No such file or directory
So somewhere in the network receiving the unicode is going wrong, but only on Windows. Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas?
.hc _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I am pretty sure I found the root cause of it. Windows uses UCS-2 as its character encoding, but Pd is all UTF-8 internally. Tcl is also all UTF-8, so that works nicely. I believe that GNU/Linux and Mac OS X use UTF-8 for filenames as well.
It looks like the solution is converting the filenames from UTF-8 to UCS-2 (16-bit wchar_t) whenever there is an open() call, and using _wopen() instead.
http://stackoverflow.com/questions/3298569/difference-between-mbcs-and-utf-8...
.hc
On Dec 6, 2012, at 2:37 PM, Roman Haefeli wrote:
Hi Hans
I probably have nothing useful to add, but just last week I got a report from someone using a patch of mine on Windows, experiencing troubles with opening certain sound files. It turned out, that it was also related to non-ASCII characters in the name of those files. Pd didn't crash, though, but the sound files didn't load. I hadn't have the opportunity to look at it myself yet (no access to a win comp), but I'm glad to see it confirmed. I'd be happy to see it fixed, though probably my only contribution would be limited to testing.
Roman
On Mit, 2012-12-05 at 23:14 -0500, Hans-Christoph Steiner wrote:
There is a problem on Windows that has me stumped. If you open a file with a non-ASCII character in the name or path using "pd -open" it works fine. If you open it using File -> Open, then it freezes Pd. If you print the filename to the Pd window right before its sent to Pd, it prints properly:
C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd
But running "pd.com -d 3" shows:
pd open comma,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop; open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory comma,co├╝├╝├╝mma.pd: No such file or directory
So somewhere in the network receiving the unicode is going wrong, but only on Windows. Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas?
.hc _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Hans,
I found an article mentioning that _wopen() is deprecated.. http://msdn.microsoft.com/en-us/library/z0kc8e3z%28v=vs.80%29.aspx
Well, the reason I thought of doing a quick search on this was that I recall Microsoft C/C++ functions beginning with underscores recommended to be called with substitute macros to keep the code portable between architectures, but that is according to my rusted memory..
Thanks for spotting that. The replacement, _wsopen_s(), does not seem available in MinGW. From what I know, Microsoft doesn't ever remove functions from their APIs, but just marks them as deprecated.
.hc
On Dec 8, 2012, at 12:08 AM, PSPunch wrote:
Hi Hans,
I found an article mentioning that _wopen() is deprecated.. http://msdn.microsoft.com/en-us/library/z0kc8e3z%28v=vs.80%29.aspx
Well, the reason I thought of doing a quick search on this was that I recall Microsoft C/C++ functions beginning with underscores recommended to be called with substitute macros to keep the code portable between architectures, but that is according to my rusted memory..
-- David Shimamoto
(2012/12/07 12:06), Hans-Christoph Steiner wrote:
I am pretty sure I found the root cause of it. Windows uses UCS-2 as its character encoding, but Pd is all UTF-8 internally. Tcl is also all UTF-8, so that works nicely. I believe that GNU/Linux and Mac OS X use UTF-8 for filenames as well.
It looks like the solution is converting the filenames from UTF-8 to UCS-2 (16-bit wchar_t) whenever there is an open() call, and using _wopen() instead.
http://stackoverflow.com/questions/3298569/difference-between-mbcs-and-utf-8...
.hc
On Dec 6, 2012, at 2:37 PM, Roman Haefeli wrote:
Hi Hans
I probably have nothing useful to add, but just last week I got a report from someone using a patch of mine on Windows, experiencing troubles with opening certain sound files. It turned out, that it was also related to non-ASCII characters in the name of those files. Pd didn't crash, though, but the sound files didn't load. I hadn't have the opportunity to look at it myself yet (no access to a win comp), but I'm glad to see it confirmed. I'd be happy to see it fixed, though probably my only contribution would be limited to testing.
Roman
On Mit, 2012-12-05 at 23:14 -0500, Hans-Christoph Steiner wrote:
There is a problem on Windows that has me stumped. If you open a file with a non-ASCII character in the name or path using "pd -open" it works fine. If you open it using File -> Open, then it freezes Pd. If you print the filename to the Pd window right before its sent to Pd, it prints properly:
C:/Documents and Settings/pd/Desktop/comma,coüüümma.pd
But running "pd.com -d 3" shows:
pd open comma,co├╝├╝├╝mma.pd C:/Documents\ and\ Settings/pd/Desktop; open: C:/Documents and Settings/pd/Desktop/comma,co├╝├╝├╝mma.pd: No such file or directory comma,co├╝├╝├╝mma.pd: No such file or directory
So somewhere in the network receiving the unicode is going wrong, but only on Windows. Its a bad bug for anyone who uses non-ASCII letters on Windows. Any ideas?
.hc _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Hans-Christoph Steiner -
Patrice Colet -
PSPunch -
Roman Haefeli