HGL ang GHC on Win32
When I compile a program using GHC 5.02.2 on Windows 200 using HGL, using the following command line: > ghc --make HelloWorld.hs -o HelloWorld.exe -package concurrent -package win32 -ic:\GraphicsLibrary\lib\win32 it compiles fine, but then when I run the exe, the window starts out initially as wide as my screen and only as tall as the title bar, regardless of what is passed as the dimensions to openWindow. What gives? If I resize the window everything works fine, but in my own application resizing the window causes it to report some error about arithmetic being bigger than 32 bits... Any ideas? - Hal -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: MacOS X GHC Status
> 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
MacOS X GHC Status
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Windows: calling a process from Haskell
Hello Simon PJ, Simon Peyton-Jones wrote: > > 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. No, I got no reply. I think the answer to the question "How much of the Posix library works under Windows" is "None", because the current binary distribution of ghc for Windows is compiled without cygwin support and so can't do the Posix stuff. In the end I downloaded some example C code from Microsoft's web site and adapted it to suit my needs, planning to access it via the FFI. (The whole idea looks like being abandoned anyway because of the lack of cooperation of another program.) By the way, Simon PJ, I shall be on holiday from Monday until after Easter so can't do any more myself on tracking down that multi-parameter type classes problem, unfortunately. Best wishes, George ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Windows: calling a process from Haskell
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:[EMAIL PROTECTED]] | Sent: 01 March 2002 16:15 | To: [EMAIL PROTECTED] | 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 | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
