November 2005 - Glasgow-haskell-users

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

25 Nov '05

On 23 November 2005 15:02, kahl(a)cas.mcmaster.ca wrote: > > > 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. > > I think I had that effect exactly when using -ddump-minimal-imports Thanks, that is now fixed. Cheers, Simon

1 0

still has jump to fast entry point (ghc-5)
by Malcolm Wallace 24 Nov '05

24 Nov '05

I know this will be going back a bit, but I have a problem with compiling some code with ghc-5.04.3. The same code goes through ghc-6.2 with no problems, and until recently there were no problems with ghc-5.04.3 either. But a recent code change has caused the following warning messages from ghc-5.04.3: still has jump to fast entry point: r4HK_entry: leal 12(%ebp), %eax cmpl 84(%ebx), %eax jbe .L55 movl $r4HK_closure, %esi movl -4(%ebx), %eax .L56: jmp *%eax .L55: movl 4(%ebp), %esi addl $12, %ebp movl $r4HK_fast2, %eax jmp .L56 There are about 350kb of very similar messages: still has jump to fast entry point: r3R_entry: still has jump to fast entry point: s4K3_entry: and so on. Does anyone have any idea what these mean, and how I might go about fixing them? Although they are only warnings, I'd like my software to continue to be portable to older versions of ghc if possible. Regards, Malcolm

1 0

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

24 Nov '05

... > > 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? > > Sorry, that bundle is the output from our nightly build > process, and we > sometimes test specific gcc versions to ensure compatibility. You can > use '-pgmc gcc-3.3.4', or build the sources yourself using ghc 6.4.1. thanks. I was only afraid that it was newly introduced incompatibility, thanks for explanations. There *is* newly introduced incompatibility, though, so PUGS is not built with a following message: .... No context is allowed on a GADT-style data declaration (You can put a context on each contructor, though.) Build failed: 256 at util/build_pugs.pl line 86. But this is probably a subject of different question. Best regards, Vadim.

1 0

RE: Checking for WHNF (a horrible naughty thing)
by Simon Marlow 24 Nov '05

24 Nov '05

On 23 November 2005 18:29, Sigbjorn Finne wrote: > The appended snippet might help.. > > --sigbjorn > > -- whnf.hs > import Foreign.StablePtr > import System.IO.Unsafe > > isWHNF :: a -> Bool > isWHNF a = unsafePerformIO $ do > stl <- newStablePtr a > rc <- isWhnf stl > freeStablePtr stl > return (rc /= 0) > > foreign import ccall safe "isWhnf" isWhnf :: StablePtr a -> IO Int > > /* whnf.c */ > #include "Rts.h" > int > isWhnf(StgStablePtr st) > { > StgClosure* c = (StgClosure*)(stable_ptr_table[(StgWord)st].addr); > return !(closure_THUNK(c)); > } using deRefStablePtr() would be slightly better. Also, you should consider whether you want indirections to be counted as WHNF or not. Also, I think you can make that foreign import "unsafe" (safe will be slow). For more speed you could implement it directly as a primitive. Cheers, Simon

1 0

RE: problem using ghc-6.5.20051122-i386-unknown-linux.tar.bz2
by Simon Marlow 24 Nov '05

24 Nov '05

On 23 November 2005 18:00, Konovalov, Vadim wrote: > 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? Sorry, that bundle is the output from our nightly build process, and we sometimes test specific gcc versions to ensure compatibility. You can use '-pgmc gcc-3.3.4', or build the sources yourself using ghc 6.4.1. Cheers, Simon

1 0

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