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 a
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 usua
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 don't
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, bu
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 p
Simon Marlow 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 [Char]. By
> c
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 openF
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 FilePat
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 -> d
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 System.Wi
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
ar
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
On 16/06/2009 14:56, Bulat Ziganshin wrote:
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 thes
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) name
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
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 openFil
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 filena
17 matches
Mail list logo
