On 16/06/2009 21:19, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 5:02:43 PM, you wrote:
I don't know how getArgs fits in here - should we be decoding argv using
the ACP?
myGetArgs = do
alloca $ \p_argc - do
p_argv_w- commandLineToArgvW getCommandLineW p_argc
On Thu, 2009-06-18 at 04:47 +0300, Yitzchak Gale wrote:
I wrote:
OK, would you like me to reflect this discussion in tickets?
Let's see, so far we have #3300, I don't see anything else.
Do you want two tickets, one each for WIndows/Unix? Or
four, separating the FilePath and getArgs
On 16/06/2009 21:19, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 5:02:43 PM, you wrote:
I don't know how getArgs fits in here - should we be decoding argv using
the ACP?
myGetArgs = do
alloca $ \p_argc - do
p_argv_w- commandLineToArgvW getCommandLineW p_argc
On 16/06/2009 17:06, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 7:54:02 PM, you wrote:
In fact there's not a lot left to convert in System.Directory, as you'll
see if you look at the code. Feel like helping?
these functions used there are ACP-only:
c_stat c_chmod
Hello Simon,
Wednesday, June 17, 2009, 11:55:15 AM, you wrote:
Right, so getArgs is already fine.
it's what i've found in Jun15 sources:
#ifdef __GLASGOW_HASKELL__
getArgs :: IO [String]
getArgs =
alloca $ \ p_argc -
alloca $ \ p_argv - do
getProgArgv p_argc p_argv
p-
On 17/06/2009 09:38, Bulat Ziganshin wrote:
Hello Simon,
Wednesday, June 17, 2009, 11:55:15 AM, you wrote:
Right, so getArgs is already fine.
it's what i've found in Jun15 sources:
#ifdef __GLASGOW_HASKELL__
getArgs :: IO [String]
getArgs =
alloca $ \ p_argc -
alloca $ \ p_argv - do
Hello Simon,
Wednesday, June 17, 2009, 12:01:11 PM, you wrote:
foreign import stdcall unsafe GetFullPathNameW
c_GetFullPathName :: LPCTSTR - DWORD - LPTSTR - Ptr LPTSTR - IO DWORD
you are right, i was troubled by unused GetFullPathNameA import in
System.Directory:
#if
Hello Simon,
Wednesday, June 17, 2009, 12:46:49 PM, you wrote:
I see, so you were previously quoting code from some other source.
from my program
Where did the GetCommandLineW version come from? Do you know of any
issues that would prevent us using it in GHC?
it should be as fine as any
I wrote:
I think the most important use cases that should not break are:
o open/read/write a FilePath from getArgs
o open/read/write a FilePath from getDirectoryContents
Simon Marlow wrote:
The following cases are currently broken:
* Calling openFile on a literal Unicode FilePath (note,
On 17/06/2009 13:21, Yitzchak Gale wrote:
I wrote:
I think the most important use cases that should not break are:
o open/read/write a FilePath from getArgs
o open/read/write a FilePath from getDirectoryContents
Simon Marlow wrote:
The following cases are currently broken:
* Calling
Simon Marlow marlo...@gmail.com writes:
Why only on Windows?
Just because it's a lot easier on Windows - all the OS APIs take
Unicode file paths, so it's obvious what to do. In contrast on Unix I
don't have a clear idea of how to proceed.
On Unix, all file APIs take [Word8] rather than
Simon Marlow wrote:
The following cases are currently broken...
I propose to fix these (on Windows). It will mean that your second case
above will be broken, until someone fixes getDirectoryContents...
...it's a lot easier on Windows...
on Unix I don't have a clear idea of how to proceed...
Ketil Malde wrote:
If we want to incorporate a translation layer, I think it's fair to
only support UTF-8 (ignoring locales), but provide a workaround for
invalid characters.
I disagree. Shells and GUI dialogs use the current locale.
I think most other modern programming languages do too, but
On 17/06/2009 15:03, Yitzchak Gale wrote:
Simon Marlow wrote:
The following cases are currently broken...
I propose to fix these (on Windows). It will mean that your second case
above will be broken, until someone fixes getDirectoryContents...
...it's a lot easier on Windows...
on Unix I
I wrote:
OK, would you like me to reflect this discussion in tickets?
Let's see, so far we have #3300, I don't see anything else.
Do you want two tickets, one each for WIndows/Unix? Or
four, separating the FilePath and getArgs issues?
Simon Marlow wrote:
One for each issue is usually
On 14/06/2009 05:56, Judah Jacobson wrote:
On Sat, Jun 13, 2009 at 8:41 PM, Shu-yu Guos...@rfrn.org wrote:
Hello all,
It seems like getDirectoryContents applies codepage conversion based
on the default program locale under Windows. What this means is that
if my default codepage is some kind
Hello Simon,
Tuesday, June 16, 2009, 3:30:31 PM, you wrote:
Care to submit a patch to put this in System.Directory, or better still
put the relevant functionality in System.Win32 and use it in
System.Directory?
Simon, it will somewhat broke openFile. let's see. there are 3 types
of
On 16/06/2009 12:42, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 3:30:31 PM, you wrote:
Care to submit a patch to put this in System.Directory, or better still
put the relevant functionality in System.Win32 and use it in
System.Directory?
Simon, it will somewhat broke
Simon Marlow wrote:
Care to submit a patch to put this in System.Directory, or better still
put the relevant functionality in System.Win32 and use it in
System.Directory?
Bulat Ziganshin wrote:
now getDirectoryContents return ACP (ansi code page) names so openFile
works for files 1) and 2).
Hello Simon,
Tuesday, June 16, 2009, 4:34:29 PM, you wrote:
Thanks for reminding me that openFile is also broken. It's easily
fixed, so I'll look into that.
i fear that it will leave GHC libs in inconsistent state that can
drive users mad. now at least there are some rules of brokeness. when
On 16/06/2009 13:46, Yitzchak Gale wrote:
Simon Marlow wrote:
Care to submit a patch to put this in System.Directory, or better still
put the relevant functionality in System.Win32 and use it in
System.Directory?
Bulat Ziganshin wrote:
now getDirectoryContents return ACP (ansi code page)
Hello Simon,
Tuesday, June 16, 2009, 5:02:43 PM, you wrote:
Also currently broken:
* calling removeFile on a FilePath you get from getDirectoryContents,
amongst other System.Directory operations
Fixing getDirectoryContents will fix these.
no. removeFile like anything else also uses
Hello Simon,
Tuesday, June 16, 2009, 7:30:55 PM, you wrote:
Actually we use a mixture of CRT functions and native Windows API,
gradually moving in the direction of the latter.
so file-related APIs are already unpredictable, and will remain in
this state for unknown amount of ghc versions
--
On 16/06/2009 16:44, Bulat Ziganshin wrote:
Hello Simon,
Tuesday, June 16, 2009, 7:30:55 PM, you wrote:
Actually we use a mixture of CRT functions and native Windows API,
gradually moving in the direction of the latter.
so file-related APIs are already unpredictable, and will remain in
this
Hello Simon,
Tuesday, June 16, 2009, 7:54:02 PM, you wrote:
In fact there's not a lot left to convert in System.Directory, as you'll
see if you look at the code. Feel like helping?
these functions used there are ACP-only:
c_stat c_chmod System.Win32.getFullPathName c_SearchPath
Hello Simon,
Tuesday, June 16, 2009, 5:02:43 PM, you wrote:
I don't know how getArgs fits in here - should we be decoding argv using
the ACP?
myGetArgs = do
alloca $ \p_argc - do
p_argv_w - commandLineToArgvW getCommandLineW p_argc
argc - peek p_argc
argv_w - peekArray (i
26 matches
Mail list logo
