November 2005 - Glasgow-haskell-users

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

Problems with 6.x compilers
by Michael Marte 22 Nov '05

22 Nov '05

Hello, 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. 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? Thank you, Michael

2 1

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

22 Nov '05

It was never fully functional, and is now seriously bit-rotted. But the vestiges are still there if anyone feels like resurrecting it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of John Goerzen | Sent: 22 November 2005 16:43 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC targetting Java? | | Hi, | | I just noticed the GhcWithJavaGen in mk/config.mk. It sounds | interesting and useful. I decided to switch it on and experiment, but: | | Could not find module `PrimRep': | use -v to see a list of the files searched for | (imported from javaGen/JavaGen.lhs) | | It seems that I'm missing some needed files. Any idea where I'd find | them? Any other reference on the Java target from GHC? | | (This is GHC 6.4.1) | | Thanks, | | -- John | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

GHC targetting Java?
by John Goerzen 22 Nov '05

22 Nov '05

Hi, I just noticed the GhcWithJavaGen in mk/config.mk. It sounds interesting and useful. I decided to switch it on and experiment, but: Could not find module `PrimRep': use -v to see a list of the files searched for (imported from javaGen/JavaGen.lhs) It seems that I'm missing some needed files. Any idea where I'd find them? Any other reference on the Java target from GHC? (This is GHC 6.4.1) Thanks, -- John

1 0

RE: Broken build
by Simon Peyton-Jones 22 Nov '05

22 Nov '05

I believe I have fixed this. (It was my fault, late last week.) I'm compiling now to test. Meanwhile it'd be worth your having another go. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Dinko Tenev | Sent: 20 November 2005 14:07 | To: glasgow-haskell-users(a)haskell.org | Subject: Broken build | | I updated from HEAD recently, and got some strange error messages | while building the stuff under libraries/X11: | | ../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches | -fwarn-unused-imports -cpp -fffi -Iinclude -I/usr/X11R6/include | -ignore-package X11 -O -dcore-lint -W -fno-warn-unused-matches | -fwarn-unused-imports -keep-hc-files -package base -fgenerics -c | Graphics/X11/Xlib/Font.hs -o Graphics/X11/Xlib/Font.o -ohi | Graphics/X11/Xlib/Font.hi | | Font.hsc:70:0: | Unacceptable argument type in foreign declaration: Display | When checking declaration: | foreign import ccall unsafe "static HsXlib.h &XQueryFont" queryFont :: Display | -> Font | -> IO FontStruct | | ...as well as several others for the same file, along the same lines. | | I am none the wiser by the messages, but the comment for | ghc/compiler/prelude/TysWiredIn.lhs#rev1.75 seems to be related. Is | this a regression? | | BTW, could someone give me a clue what the point is with a type like | the one mentioned? | | Regards, | Dinko | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Patch: Add support for using --mk-dll with --make
by Esa Ilari Vuokko 21 Nov '05

21 Nov '05

Hi! 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. Thanks in advance, --Esa

1 0