- Glasgow-haskell-users

RE: Patch for Word64
by Simon Marlow 24 Nov '05

24 Nov '05

On 21 November 2005 14:57, Matt wrote: > I was doing some work with Word64 and noticed that it was about 3 > times slower than Int64. The reason appears to be expensive > conversions from Int64# to Word64# and vice versa. I modified the > libraries to remove the conversion overhead, and the result is that > Int64# and Word64# now have equal performance, at least on the domain > that I tested (==, +, -). > > I can't check into the tree, so I was told to send my changes to this > list. Could someone else check them in? I have attached a patch file > representing my changes. Thanks for the patch - but could you try this instead? int64ToWord64# = unsafeCoerce# word64ToInt64# = unsafeCoerce# this should reduce the cost of the conversions to zero, which is a simpler way to fix the performance bug (if it works). If you confirm that this also improves performance, I'll commit it. If not, I'll commit your patch instead. Cheers, Simon

3 3

RE: adding to GHC/win32 Handle operations support of Unicode filenamesand files larger than 4 GB
by Simon Marlow 24 Nov '05

24 Nov '05

This sounds like a good idea to me. As far as possible, we should keep the platform-dependence restricted to the implementation of one module (System.Posix.Internals will do, even though this isn't really POSIX any more). So System.Posix.Internals exports the CFilePath/CFileOffset types, and the foreign functions that operate on them. Alternatively (and perhaps this is better), we could hide the difference even further, and provide functions like rmDir :: FilePath -> IO CInt in System.Posix.Internals. Similarly for functions that operate on COff, they would take/return Integer (eg. we already have System.Posix.fdFileSize). As regards whether to use feature tests or just #ifdef mingw32_HOST_OS, in general feature tests are the right thing, but sometimes it doesn't buy you very much when there is (and always will be) only one platform that has some particular quirk. Writing a bunch of autoconf code that would, if we're lucky, handle properly the case when some future version of Windows removes the quirk, is not a good use of developer time. Furthermore, Windows hardly ever changes APIs, they just add new ones. So I don't see occasional use of #ifdef mingw32_HOST_OS as a big deal. It's more important to organise the codebase and make sure all the #ifdefs are behind suitable abstractions. Cheers, Simon On 21 November 2005 12:01, Bulat Ziganshin wrote: > Simon, what you will say about the following plan? > > ghc/win32 currently don't support operations with files with Unicode > filenames, nor it can tell/seek in files for positions larger than 4 > GB. it is because Unix-compatible functions open/fstat/tell/... that > is supported in Mingw32 works only with "char[]" for filenames and > off_t (which is 32 bit) for file sizes/positions > > half year ago i discussed with Simon Marlow how support for unicode > names and large files can be added to GHC. now i implemented my own > library for such files, and got an idea how this can incorporated to > GHC with minimal efforts: > > GHC currently uses CString type to represent C-land filenames and COff > type to represent C-land fileseizes/positions. We need to > systematically change these usages to CFilePath and CFileOffset, > respectively, defined as follows: > > #ifdef mingw32_HOST_OS > type CFilePath = LPCTSTR > type CFileOffset = Int64 > withCFilePath = withTString > peekCFilePath = peekTString > #else > type CFilePath = CString > type CFileOffset = COff > withCFilePath = withCString > peekCFilePath = peekCString > #endif > > and of course change using of withCString/peekCString, where it is > applied to filenames, to withCFilePath/peekCFilePath (this will touch > modules System.Posix.Internals, System.Directory, GHC.Handle) > > the last change needed is to conditionally define all "c_*" functions > in System.Posix.Internals, whose types contain references to filenames > or offsets: > > #ifdef mingw32_HOST_OS > foreign import ccall unsafe "HsBase.h _wrmdir" > c_rmdir :: CFilePath -> IO CInt > .... > #else > foreign import ccall unsafe "HsBase.h rmdir" > c_rmdir :: CFilePath -> IO CInt > .... > #endif > > (note that actual C function used is _wrmdir for Windows and rmdir for > Unix). of course, all such functions defined in HsBase.h, also need to > be defined conditionally, like: > > #ifdef mingw32_HOST_OS > INLINE time_t __hscore_st_mtime ( struct _stati64* st ) { return > st->st_mtime; } #else > INLINE time_t __hscore_st_mtime ( struct stat* st ) { return > st->st_mtime; } #endif > > That's all! of course, this will broke compatibility with current > programs which directly uses these c_* functions (c_open, c_lseek, > c_stat and > so on). this may be issue for some libs. are someone really use these > functions??? of course, we can go in another, fully > backward-compatible way, by adding some "f_*" functions and changing > high-level modules to work with these functions

2 2

GHC 6.6
by Jim Apple 24 Nov '05

24 Nov '05

Help build the anticipation: http://haskell.org/hawiki/GHC_206_2e6 Present text: GHC 6.6: Will be out before May 2006. Included: * Parallel GHC * Associated types with class Maybe: * Impredicativity * GADT & Typeclass interaction * Data types as kinds No: Jim

1 0

Checking for WHNF (a horrible naughty thing)
by Jan-Willem Maessen 23 Nov '05

23 Nov '05

I would like to do a horrible naughty thing (which I promise never to expose to the world). I would like to tell whether a term is in WHNF, without forcing evaluation of that term. Something like: isWHNF :: a -> Bool Is there a way of doing this? I can fake it with an IORef and much unsafeness, but I'm wondering if there's a safe-but-ugly way of doing the test in GHC. If you're curious, I'm trying to compact exactly the evaluated spine of a list without changing the list's laziness in any way. It remains to be seen whether this is even vaguely a good idea. :-) -Jan-Willem Maessen

2 1

problem using ghc-6.5.20051122-i386-unknown-linux.tar.bz2
by Konovalov, Vadim 23 Nov '05

23 Nov '05

I downloaded ghc-6.5.20051122-i386-unknown-linux.tar.bz2 and tried to use it (as bootstrap for building Haskell at first, but building Pugs fails the same way) It installed fine. My attempts to compile something with it result with a following error: ghc-6.5.20051122: could not execute: gcc-3.4.3 <<ghc: 16599408 bytes, 3 GCs, 123124/123124 avg/max bytes residency (1 samples), 15M in use, 0.00 IN IT (0.00 elapsed), 0.11 MUT (0.21 elapsed), 0.02 GC (0.03 elapsed) :ghc>> Indeed, the compiler I have has version gcc-3.3.4, and this mismatches with gcc-3.4.3, also How should I avoid this problem? Why having that precise requirement of GCC version? Best regards, Vadim.

1 0

RE: Problems with 6.x compilers
by Simon Marlow 23 Nov '05

23 Nov '05

On 22 November 2005 17:18, Michael Marte wrote: > I am having some annoying problems with the 6.x compilers: > > 6.4 and 6.4.1: When repeating a build (with ghc --make) all modules > are rebuild even if nothing has changed. With earlier compilers, > only linking takes place in this setting. Can I change this > behaviour? I cannot develop this way. Should not happen, if it does there is a bug. Can you tell us how to repeat the behaviour you're seeing? We aren't seeing any unecessary recompilation here. > 6.2 and up: The object file is named after the module, not after the > source file as in 5.04. As there are several main modules in my > project, each in its own source file, all I get is a big mess. Any > suggestions? The object file is named after the source file, unless you use -odir. The behaviour is clearly specified in the user's guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compila tion.html#output-files the behaviour has been through several revisions before we arrived at this, and I'm not keen to change it. You can have several Main modules in the same directory if you don't use -odir. If you do use -odir, then you need to use a different value for -odir for each different program. Alternatively use -main-is, as Bulat suggested (actually this is better, IMO). Cheers, Simon

3 2

RE: GHC targetting Java?
by Simon Marlow 23 Nov '05

23 Nov '05

On 23 November 2005 09:32, Simon Peyton-Jones wrote: >> On a similar note, how about the .NET support? Can it work on a >> platform where the only .NET support is Mono? > > This comes up regularly. Here's my message from Jan: > http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075 > 94.html Added to the FAQ. Cheers, Simon

1 0

RE: Patch: Add support for using --mk-dll with --make
by Simon Marlow 23 Nov '05

23 Nov '05

On 21 November 2005 22:03, Esa Ilari Vuokko wrote: > Attached small simple patch that allows using --mk-dll with --make. > Behaviour before patch was to link .exe instead .dll, as batchmode > simply called staticLink - now doMkDLL is called instead. > > * Add support for using --mk-dll with --make > > I changed documentation a bit, and moved --mk-dll from 4.17.3 > "Alternative modes of operation" into 4.17.21 "Linking options." > This documentation change isn't tested, as I don't have necessary > tools installed on my machine. But it *seems* harmless (and > I think, more intuitive.) Due to lack of tools, and because there's > little to say, I didn't touch 11.5. "Building and using Win32 DLLs." > > Patch should apply cleanly on cvs HEAD with patch -p0 under > fptools. Any comments are welcome. Committed, thanks! Simon

1 0

RE: GHC targetting Java?
by Simon Peyton-Jones 23 Nov '05

23 Nov '05

| On a similar note, how about the .NET support? Can it work on a | platform where the only .NET support is Mono? This comes up regularly. Here's my message from Jan: http://www.haskell.org/pipermail/glasgow-haskell-users/2005-January/0075 94.html Simon =========================== It'd make a lot of sense to give GHC a .NET back end, and it's a question that comes up regularly. The reason that we haven't done it here, at GHC HQ, is because it's a more substantial undertaking than might at first appear (see below). Furthermore, it'd permanently add a complete new back-end platform for us to maintain. Given our rather limited development effort (= Simon and me), we have so far not bitten the bullet, and we have no immediate plans to do so. It'd be a good, well-defined project for someone else to tackle, and there is some good groundwork already done: * Sigbjorn Finne did a simple interop implementation that allows a Haskell program to be compiled to native code (as now) but to call .NET programs via a variant of the FFI. I don't think this work is in active use, and I'd be surprised if it worked out of the box, but it could probably be revived with modest effort * Andre Santos and his colleagues at UFPE in Brazil are working on a .NET back end, that generates CLR IL, though I don't know where they are up to. * [This para wasn't in the original message] Nigel Perry and Oliver Hunt have a Haskell.NET prototype that works using GHC to compile to Core, and then compiling Core to NET. I'm not sure what stage it is at. * GHC.Net would be extra attractive if there was a Visual Studio integration for GHC. Substantial progress on this has been made in 2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and colleagues. There may be others that I don't know of. If anyone wants to join in this effort, do contact the above folk. And please keep us informed! Simon Here's a summary of why it's a non-trivial thing to do: * The first thing is to generate native CLR Intermediate Language (IL). That's not really hard. Requires thinking about representations for thunks and functions, and it may not be particularly efficient, but it can surely be done. An open question is about whether to generate verifiable IL or not. The trouble here is that Haskell's type system is more expressive than the CLR's in some ways, notably the use of higher-kinded type variables. So, to generate verifiable IL one is bound to need some run-time casts, and it's not clear how to minimise these. At first blush this is *all* you need do. But it isn't! * Next, you need to think about how to inter-operate with .NET libraries. You don't really want to write "foreign import..." for each and every import. You'd like GHC to read the CLR meta-data directly. But there are lots of tricky issues here; see the paper that Mark Shields and I wrote about "Object-oriented style overloading for Haskell". * Now you need to figure out how to implement GHC's primitive operations: the I/O monad arbitrary precision arithmetic concurrency exceptions finalisers stable pointers software transactional memory Not all of these are necessary, of course, but many are used in the libraries. The CLR supports many of them (e.g. concurrency) but with a very different cost model. * Last, you have to figure out what to do for the libraries. GHC has a pretty large library, and you either have to implement the primops on which the library is based (see previous point), or re-implement it. For example, GHC's implementation of I/O uses mutable state, concurrency, and more besides. For each module, you need to decide either to re-implement it using .NET primitives, or to implement the stuff the module is based on. These challenges are mostly broad rather than deep. But to get a production quality implementation that runs a substantial majority of Haskell programs "out of the box" requires a decent stab at all of them.

1 0

adding to GHC/win32 Handle operations support of Unicode filenames and files larger than 4 GB
by Bulat Ziganshin 22 Nov '05

22 Nov '05

Hello glasgow-haskell-users, Simon, what you will say about the following plan? ghc/win32 currently don't support operations with files with Unicode filenames, nor it can tell/seek in files for positions larger than 4 GB. it is because Unix-compatible functions open/fstat/tell/... that is supported in Mingw32 works only with "char[]" for filenames and off_t (which is 32 bit) for file sizes/positions half year ago i discussed with Simon Marlow how support for unicode names and large files can be added to GHC. now i implemented my own library for such files, and got an idea how this can incorporated to GHC with minimal efforts: GHC currently uses CString type to represent C-land filenames and COff type to represent C-land fileseizes/positions. We need to systematically change these usages to CFilePath and CFileOffset, respectively, defined as follows: #ifdef mingw32_HOST_OS type CFilePath = LPCTSTR type CFileOffset = Int64 withCFilePath = withTString peekCFilePath = peekTString #else type CFilePath = CString type CFileOffset = COff withCFilePath = withCString peekCFilePath = peekCString #endif and of course change using of withCString/peekCString, where it is applied to filenames, to withCFilePath/peekCFilePath (this will touch modules System.Posix.Internals, System.Directory, GHC.Handle) the last change needed is to conditionally define all "c_*" functions in System.Posix.Internals, whose types contain references to filenames or offsets: #ifdef mingw32_HOST_OS foreign import ccall unsafe "HsBase.h _wrmdir" c_rmdir :: CFilePath -> IO CInt .... #else foreign import ccall unsafe "HsBase.h rmdir" c_rmdir :: CFilePath -> IO CInt .... #endif (note that actual C function used is _wrmdir for Windows and rmdir for Unix). of course, all such functions defined in HsBase.h, also need to be defined conditionally, like: #ifdef mingw32_HOST_OS INLINE time_t __hscore_st_mtime ( struct _stati64* st ) { return st->st_mtime; } #else INLINE time_t __hscore_st_mtime ( struct stat* st ) { return st->st_mtime; } #endif That's all! of course, this will broke compatibility with current programs which directly uses these c_* functions (c_open, c_lseek, c_stat and so on). this may be issue for some libs. are someone really use these functions??? of course, we can go in another, fully backward-compatible way, by adding some "f_*" functions and changing high-level modules to work with these functions -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 2