- Glasgow-haskell-users

GHC 6.6 for OS X using MacPorts
by Gregory Wright 29 Oct '06

29 Oct '06

Hi, GHC 6.6 is now available for OS X systems on both Intel and PowerPC processors using the MacPorts infrastructure. The compiler is built from source, using a binary bootstrap compiler. OS X versions 10.3 (Panther) and 10.4 (Tiger) are supported for PowerPC processors; for Intel processors, version 10.4. MacPorts (formerly Darwinports) is a packaging system for managing builds of unix-compatible software on OS X. For more information on MacPorts, see http://www.macports.org/ A new ghc-devel port will soon be available for those who just have to live on the bleeding edge. Best Wishes, Greg Gregory Wright Antiope Associates LLC gwright(a)antiope.com

3 8

OS X - Haskell to Objective-C Binding on GHC 6.6
by Charlie Conklin 26 Oct '06

26 Oct '06

Is anyone out there running OS X and using HOC and GHC 6.6? I took the latest from cvs and got some way toward getting it to compile by changing the code to: 1. reflect changes regarding packages, i.e. adding -package-name to the pertinent makefiles, and accommodating the changed signature of Language.Haskell.TH.Syntax mkNameG_v and mkNameG_tc 2. replacing the obsolete names used from Data.Set which have been removed from GHC 6.6. At that point HOC was able to get to the point where it parses the ObjC headers, but it then choked on compiling the generated .hs files, some of which seem to have invalid constructions like: -- enum definitions $(declareAnonymousCEnum [("NSFileNoSuchFileError", 4),("NSFileLockingError", 255),("NSFileReadUnknownError", 256),("NSFileReadNoPermissionError", 257),("NSFileReadInvalidFileNameError", 25,("NSFileReadCorruptFileError", 259),("NSFileReadNoSuchFileError", 260),("NSFileReadInapplicableStringEncodingError", 261),("NSFileReadUnsupportedSchemeError", 262),("NSFileWriteUnknownError", 512),("NSFileWriteNoPermissionError", 513),("NSFileWriteInvalidFileNameError", 514),("NSFileWriteInapplicableStringEncodingError", 517),("NSFileWriteUnsupportedSchemeError", 51,("NSFileWriteOutOfSpaceError", 640),("NSKeyValueValidationError", 1024),("NSFormattingError", 204,("NSUserCancelledError", 3072),("NSFileErrorMinimum", 0),("NSFileErrorMaximum", 1023),("NSValidationErrorMinimum", 1024),("NSValidationErrorMaximum", 2047),("NSFormattingErrorMinimum", 204,("NSFormattingErrorMaximum", 2559)]) I'm a complete beginner to Hasell, and at this point I'm a bit stuck. Any help would be much appreciated! Cheers, - Charlie

3 3

Difference between errorCalls and userErrors
by Andreas Marth 26 Oct '06

26 Oct '06

Hi! In module Control.Exception there are the exception predicates errorCalls and userErrors defined. Is there any difference between them? Which one? Thanks for any explanations, and maybe it should be documented in more detail? Kind regards, Andreas

2 1

GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
by Michael Marte 25 Oct '06

25 Oct '06

Hello *, before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's. I wrapped up some Haskell modules in a Win32 DLL. Loading the DLL dynamically (with LoadLibrary) works fine. However, whether I actually use the library or not, the program (an application with MFC GUI) crashes upon termination. To find the reason for the crash, I added a new function for unloading the DLL using FreeLibrary. FreeLibrary works fine, however the program crashes when it returns to the main event loop. Interestingly, when I reload the library (FreeLibrary followed by LoadLibrary) the program continues working. However, every reload cycle causes the virtual size of the process to increase by about 300K and the fourth reload fails with the error message "getMBlock: VirtualAlloc failed with: 8" (appears in a message window) accompanied by many repetitions of the message "Timer proc: wait failed -- error code: 6" (appears on stderr) and followed by the message "getMBlocks: misaligned block returned" (again in a message window). Then the programm crashes. Development takes place on Windows XP Professional using MS Visual Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side to the Haskell heap. I build the DLL using the command ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o dllMain.c dllMain.c looks as follows: #include <windows.h> #include <Rts.h> extern void __stginit_EUzu3820zu85(void); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain(HANDLE hModule, DWORD reason, void* reserved) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Foo); return TRUE; } else if (reason == DLL_PROCESS_DETACH) { shutdownHaskell(); } return TRUE; } I played around with hs_exit instead of shutdownHaskell, I moved initialization and clean-up from DllMain to my library loader, nothing helps. Even doing no clean-up whatsoever does not change the behaviour. Any ideas? Michael

7 16

GHC 6.6 using stale stub.c files
by Juan Carlos Arevalo Baeza 24 Oct '06

24 Oct '06

I tried recompiling a little (big?) Win32 binding library I had made, when the official one wasn't working for me. It had a bunch of generated stubs files in it (I'm not 100% sure what they are for). The problem is that, not even with -fforce-recomp (much better name, thanx!) will GHC regenerate those files (I think that's normal), but still it tries to use them if they are there. I get errors like these: Win32Test_stub.c: In function `Main_d4n0': Win32Test_stub.c:14:0: error: too few arguments to function `rts_mkPtr' Win32Test_stub.c:14:0: warning: passing arg 1 of `rts_apply' from incompatible pointer type Win32Test_stub.c:14:0: error: too few arguments to function `rts_apply' Win32Test_stub.c:14:0: warning: passing arg 1 of `rts_mkWord32' makes pointer from integer without a cast (etc, etc... lots of them). The stub file is old: C:\Documents and Settings\JCAB\My Documents\Haskell>dir Win32Test_stub.c Volume in drive C has no label. Volume Serial Number is A0CD-B8F4 Directory of C:\Documents and Settings\JCAB\My Documents\Haskell 08/18/2005 12:15 AM 637 Win32Test_stub.c 1 File(s) 637 bytes 0 Dir(s) 151,815,680,000 bytes free And yes, I'm on Windows. There are some stubs files that were regenerated: C:\Documents and Settings\JCAB\My Documents\Haskell>dir Win32\Window\Types_stub.c Volume in drive C has no label. Volume Serial Number is A0CD-B8F4 Directory of C:\Documents and Settings\JCAB\My Documents\Haskell\Win32\Window 10/22/2006 05:05 PM 717 Types_stub.c 1 File(s) 717 bytes 0 Dir(s) 151,803,375,616 bytes free So I suppose the no-longer-needed stubs files were related to the modules that made use of this Win32.Window.Types module I had here. I guess GHC doesn't need those any more, but it just tries to use any stub files it finds. It probably shouldn't use them, and it should probably even delete them, unless it generated them, at least when -fforce-recomp is specified. I'm moving on. I made a copy of all the files, so let me know if you need a repro. Deleting the stubs files fixes the problem. I haven't seen anything about this in the documentation, but maybe I just didn't look in the right places. Thanx! JCAB

2 4

Debugging on Mac OS X
by Luke Worth 24 Oct '06

24 Oct '06

Hi all, I just installed GHC 6.6 using the PPC binary installer on Mac OS X. I'm having some trouble getting debuggers to work; I have tried both plargleflarp (buddha) and Hat. Neither of them will compile on GHC 6.6 on Mac yet. For anyone in the same situation, how do you survive? I know of no other method of debugging Haskell programs, aside from manually running chunks of the code from within GHCi - but that makes it very difficult to debug nested 'where' functions. Thanks in advance Luke Worth

3 2

Heap representation evil
by Brandon Moore 24 Oct '06

24 Oct '06

Thinking to take advantage of fortuitous heap layout of some Haskell values for interfacing with C, I've written the following function: addressOf :: a -> Ptr () addressOf x = x `seq` unsafeCoerce# (Box x) data Box x = Box x For example, data A = A {-# UNPACK #-} !(Ptr Word8) {-# UNPACK #-} !CInt main = let a = A nullPtr 12 p = addressOf a `plusPtr` 4 in do x <- peek p :: IO Int y <- peek p :: IO Int print (x, y) prints (0, 12) One thing I don't understand is that this fails if I use Just rather than inventing my box type. I suppose the info table for Just is set up to support a vectored return for pattern matching on Maybe? (the commentary isn't very clear here. The section http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution#Re… says, in full: "Return Convention Direct Returns Vectored Returns" ) The reason I'm messing about with this stuff is that I'm pretty sure passing p to C code would give a usable pointer to struct a {char *; int;}; Obviously my plot will be spoiled if the GC comes along and relocates the value while C code is trying to use it. Are there any other pitfalls with this approach? A different and in all likelihood saner approach is building up more tools for manipulating pointers to C data from Haskell, perhaps along the lines of cmucl's support for "Alien Objects". http://www.math.sunysb.edu/~sorin/online-docs/cmucl/aliens.html The main reason to even think about touching the heap representation of Haskell objects is so that the values can be manipulated by pure code, pattern matched, etc. Brandon

3 4

Benchmarking GHC
by Neil Mitchell 23 Oct '06

23 Oct '06

Hi, I want to benchmark GHC vs some other Haskell compilers, what flags should I use? I just want whichever package of flags is "good optimisation" - nothing unsafe, nothing that changes strictness properties, and a set of flags that is generally applicable - but slow compilation is fine. As far as the user guide says: * At the moment, -O2 is unlikely to produce better code than -O. * When we want to go for broke, we tend to use -O2 -fvia-C >From this I guess the answer is "-O2 -fvia-C"? I just wanted to check this information is still current before I start giving anyone any benchmark numbers. (for reference I'm on Windows, x86 Pentium 4/Athlon, if that makes a difference) Thanks Neil

10 17

ghc error
by Chad Scherrer 23 Oct '06

23 Oct '06

I tried compiling a file today using -O2, and it gave me this: /tmp/ghc10376_0/ghc10376_0.hc:5:20: HsTime.h: No such file or directory It compiled fine without the -O2. Am I missing some files? Where can I find what I need to make this work again? Thanks, -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

1 0

Concurrency issue with dynamic linker in GHC
by Vyacheslav Akhmechet 23 Oct '06

23 Oct '06

I am running ghc 6.4.2 on a Win32 machine. I'm using hs-plugins in one thread and a simple getLine loop in another. It appears that getLine blocks the hs-plugins thread on Win32 (this has been verified to work fine on freeBSD). I've tried various combinations of -threaded flag and forkIO/forkOS and always get the undesireable result. Below is the minimal test case. module Main where import Control.Concurrent import System.Plugins import System.IO -- Main loop main = do hSetBuffering stdout NoBuffering forkIO blah test <- getLine putStrLn test blah = do contents <- loadPlugin "Hello" putStrLn contents loadPlugin path = do status <- pdynload (path ++ ".o") [] [] "Prelude.String" "myTestSym" case status of (LoadSuccess _ res) -> return res (LoadFailure errors) -> return $ concat errors --------------------- Hello.hs -------------------- module Hello where myTestSym :: String myTestSym = "Hello 2!" Thanks!

4 17