- Glasgow-haskell-users

Concurrent Haskell (GHC) and Win32 Applications ?
by Antony Blakey 09 Mar '02

09 Mar '02

Hi, I'm experimenting with GHC as a platform for writing a Win32 GUI application, and I've hit what I think is a brick wall. The problem I think is with the lightweight thread implementation - Win32 calls can (and will) block the OS thread that makes the call, which blocks the entire system. Given that I'm wanting to write a network server with a Win32 GUI, this is obviously a Bad Thing. So, does any know if I missing some vital piece of information? I am using the following reduced test case, which I don't think is clueless. import Win32 import Concurrent endless:: Char -> IO () endless c = do { putChar c; endless c } main = do { task1; task2; endless 'b' } where task1 = forkIO ( do { messageBox nullHANDLE "Hey" "Yeah" mB_OK; return () } ) task2 = forkIO ( endless 'a' ) It does intersperse the 'a' and 'b' output nicely, but stops while the message box is on the screen. I'm not keen on writing a seperate GUI management thread in C++ and linking - the point is to do all of this in Haskell and write an application indistinguishable from a C++ GUI app e.g. imagine Simon Peyton Jones' sample webserver with a realtime GUI monitor. Thanks in advance for any pointers!

2 1

Great investment for foreign residents 4986chZG8-753WYWl15
by Abigail6551b44＠hint.no 08 Mar '02

08 Mar '02

1 0

RE: MacOS X GHC Status
by Simon Marlow 08 Mar '02

08 Mar '02

> Some programs work, including green-card and some HOpenGL programs. > > GHC, compiled with my registerized version, crashes. > At some point, there is pointer on the Stg Stack that points > into data space. > However, it doesn't point to a closure. In points to a place just > after the last data symbol in of one GHC module, and before the next > (there's quite some stuff between those two modules, and I have no > idea what the linker puts there). > The word at that position is definitely not a valid info pointer, it > points about 300 megabytes above the heap (into unmapped space). > MacOS X doesn't yet support watchpoints, so I still have no idea > "who" put this strange pointer onto the stack. Under what conditions > are pointers into data space > put on the stack? Any ideas how I could go about debugging this? How > can I possibly ever find out what code is putting this nonsense value > on the stack? These things are particularly tedious to debug (or fun and rewarding, depending on your particular inclinations :-). The first thing to do is compile the RTS with debugging support: there are two lines to copy from config.mk into your build.mk, namely the settings for GhcRtsHcOpts and GhcRtsCcOpts. When you have this, you can turn on heap sanity checking with -D128, which occasionally finds bugs closer to the point at which they occur. In particular if there's a bug in GC it'll probably show up right after the GC in which it occurs, rather than later on during execution. The only pointers into data space that should be on the stack are pointers to static closures. The other things on the stack are pointers to text space (info tables), and pointers into heap space (dynamic closures). > For now, I'll try to find some smaller programs that crash, too. Yes, that's a good idea. I usually make sure the whole nofib suite goes through before attempting to bootstrap a compiler. Cheers, Simon

1 0

MacOS X GHC Status
by Wolfgang Thaller 08 Mar '02

08 Mar '02

Some programs work, including green-card and some HOpenGL programs. GHC, compiled with my registerized version, crashes. At some point, there is pointer on the Stg Stack that points into data space. However, it doesn't point to a closure. In points to a place just after the last data symbol in of one GHC module, and before the next (there's quite some stuff between those two modules, and I have no idea what the linker puts there). The word at that position is definitely not a valid info pointer, it points about 300 megabytes above the heap (into unmapped space). MacOS X doesn't yet support watchpoints, so I still have no idea "who" put this strange pointer onto the stack. Under what conditions are pointers into data space put on the stack? Any ideas how I could go about debugging this? How can I possibly ever find out what code is putting this nonsense value on the stack? For now, I'll try to find some smaller programs that crash, too. Wolfgang

1 0

RE: Windows: calling a process from Haskell
by Simon Peyton-Jones 08 Mar '02

08 Mar '02

Did you get a reply to this? I assume you use a function from the Posix library. Sigbjorn may have comments on how much of it works on Windows. Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 01 March 2002 16:15 | To: glasgow-haskell-users(a)haskell.org | Subject: Windows: calling a process from Haskell | | | How do I start up a new process in Windows without stopping | the world (as I presume System.system will do)? | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

2 1

Build problem under cygwin
by David Duke 07 Mar '02

07 Mar '02

I'm trying to build ghc 5.02.2 under cygwin (2.125.2.10), using gcc rather than an existing Haskell compiler. I'm running with gnu make version 3.79.1 I configured with --prefix=D:/haskell/ghc (where I've installed the package), and --enable-win32-dlls. The make process is failing (ultimately) because the genprimopcode command is being invoked before (apparently) it has been compiled. Looking back through the trace, the makefile in genprimcode is running, but then failing: should this not have terminated the entire build? syslib text -O -c Main.hs -o Main.o syslib: not found make[3]: [Main.o] Error 127 (ignored) o genprimopcode -syslib text -O Main.o o: not found make[3]: [genprimopcode] Error 127 (ignored) M -optdep-f -optdep.depend -osuf o -syslib text -O Main.hs M: not found make[3]: [depend] Error 127 (ignored) Somehow, it looks like the "syslib" compiler option is being incorrectly intrpreted as a make command. Looking further into the make result, a number of other commands are also failing with an ignored error 127, e.g. ==fptools== make boot - --unix - --no-print-directory -r; in /cygdrive/d/haskell/ghc/ghc/utils/hsc2hs ------------------------------------------------------------------------ M -optdep-f -optdep.depend -osuf o -package util -cpp -O Config.hs KludgedSy stem.hs Main.hs Config.hs M: not found make[3]: [depend] Error 127 (ignored) Again, it looks somehow that a command issued from a makefile is being truncated. I would be grateful for any comments or suggestions. thanks, David Duke -- Dr. David Duke Email: D.Duke(a)bath.ac.uk Department of Computer Science Web: www.bath.ac.uk/~masdad/ University of Bath Tel: +44 1225 323 407 Bath, BA2 7AY U.K. Fax: +44 1225 323 493

1 0

RE: Weird Activation Records (Fixed!)
by Simon Marlow 07 Mar '02

07 Mar '02

> If got the mangler to produce working code at least in some cases - I > still have to chase after a segfault in one larger program that I > tried to compile. That's great news! > Due too my lack of Perl knowledge, I didn't yet manage to remove the > jumps from the slow to the fast entry points, and a function called > __DISCARD__ must be present for linking (it's never called, though). > Should the old PowerPC code in the mangler be kept there? It assumes > a slightly different assembler dialect and a completely different > linker, and as it just asks for $TargetPlatform =~ /^powerpc|rs6000/, > it keeps getting in the way... Sure, by all means remove this code. It hasn't been used for years, and we can always resurrect it from the repository if necessary. Cheers, Simon

1 0

RE: Weird Activation Records (RTS wizards, please help!)
by Simon Marlow 06 Mar '02

06 Mar '02

> I can't seem to get the Garbage Collector to work properly on MacOS X. > When a program triggers the Garbage Collector, it aborts with the > following message: > a.out: fatal error: scavenge_stack: weird activation record > found on stack: 0 I'd be willing to bet large amounts of money that this is due to the macro LOOKS_LIKE_GHC_INFO() returning the wrong value. Read the comments in ghc/rts/Storage.h, particularly the sections on "Address space layout macros" and "Macros for distinguishing code pointers from data pointers". In the latter section, unregisterised compilation on MacOS X should be using Plan C. (Sigbjorn - did you already solve this one?) Cheers, Simon

3 2

Weird Activation Records (RTS wizards, please help!)
by Wolfgang Thaller 06 Mar '02

06 Mar '02

I can't seem to get the Garbage Collector to work properly on MacOS X. When a program triggers the Garbage Collector, it aborts with the following message: a.out: fatal error: scavenge_stack: weird activation record found on stack: 0 The same error happens both in unregistered mode and using my half-finished powerpc mangler (BTW, Hello World already works in registered mode!). In unregistered mode, I have also observed different numbers instead of zero in the error message. I'm positive that the problem is in the basic day-to-day workings of the STG machine. main = print $ length $ [1..5000000] -- aborts the first time GC is invoked It has nothing to do with the libs, I can replace length and the list generation with my own functions and print with a foreign import, and the result stays the same: crash on first GC, fine otherwise. Now I'm stuck. Are there any reasonably up-to-date docs on what a "normal" activation record should look like? The file GC.c is not exactly the kind of code that I understand the first time that I read it... One of my random guesses is that there is a problem with struct alignment, which has more padding on PPC than on Intel --- on the other hand, GHC is supposed to work on Sparc, and that doesn't use Intel alignment either, AFAIK (does the HEAD currently work on Sparc? The ghc-5.03 snapshot on the download page seems to have only intel versions). Can anyone give me any hints? Wolfgang

1 0

RE: Raw Sockets
by dominic.j.steinitz＠britishairways.com 06 Mar '02

06 Mar '02

Simon, Thanks. On Linux I get [dom@lhrtba8fd85 ping]$ test5 Protocol name: icmp Protocol aliases: ["ICMP"] Protocol number: 1 Fail: permission denied Action: socket Reason: privileged operation as expected but on W98 I get C:\Dom\haskell\ping>main Protocol name: icmp Protocol aliases: ["ICMP"] Protocol number: 1398538241 Fail: failed Action: socket Reason: No error I would have expected success. I haven't got access to C tools so I can't see if I would get the same if I used the C sockets API. Dominic. "Simon Marlow" <simonmar(a)microsoft.com>@haskell.org on 04/03/2002 16:24:44 Sent by: glasgow-haskell-users-admin(a)haskell.org To: <dominic.j.steinitz cc: <glasgow-haskell-users bcc: Subject: RE: Raw Sockets > It looks like you want SOCK_RAW, not AF_RAW. GHC does support this, > with the 'Raw' socket type, something like this: > > proto <- getProtocolByName "icmp" > s <- socket AF_INT Raw proto should be: s <- socket AF_INET Raw (protoNumber proto) and of course you have to be root to send raw packets to the network. Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ------------------------------------------------------------------------------------------------- Save time by using an eTicket and our Self-Service Check-in Kiosks. For more information go to http://www.britishairways.com/eservice1

1 0