On Wed, Sep 19, 2007 at 10:24:24PM +0100, Neil Mitchell wrote:

Hi Peter,

...

So I grabbed ghc-6.7.20070824 (=the latest one for Windows I could find) and the "extra-libs", compiled and installed the GLUT package (which I needed), but when I compile my library, I get

Could not find module `Data.Map': it is a member of package containers-0.1, which is hidden

All dependencies etc. have changed when going to 6.7/6.8 - you are probably better off using 6.6.1 for now.

I also don't think that the debugger will help you track down infinite loop style errors. You might be better off posting the code and asking for help.

You said 0% CPU. That's *very* important. It means that you are using the threaded runtime (GHCi?), and that you triggered a blackhole. You should be able to handle this by compiling your program with -prof (do *not* use -threaded!), and running with +RTS -xc. With luck, that will give you a backtrace to the infinite loop. PS. blackholes are a serious dark corner of GHC's execution model, chances are better than even that if you try to use the debugger for this you will discover a new and (for you) crippling bug. I wouldn't recommend it. Stefan

Thanks for the info, very interesting. Yes, I'm using GHCi, and I'm using forkOS, and I'm using OpenGL... Since I'm used to write heavily multi-threaded/multi-core code in imperative languages, I would like to understand more about the existing execution models, and those "black holes"... Understanding the low-level details helps a lot for me. Actually the problem was caused by (yet another) strict pattern match in my code, which should have been lazy. I find it strange that this would cause 0% CPU time... But then again I don't understand the details of how GHCi/GHC works. I did read the book "Modern Compiler Design" (http://www.cs.vu.nl/~dick/MCD.html) which implements a basic Haskell interpreter & compiler, so I got an introduction. Anyway, it's a very good learning experience for me to "redo" FRP from scratch, as I encounter all pitfalls (such as the need for memoization when using recursive streams, the need for lazy pattern matching, the space leaks sneaking up on you, etc). Once I get to understand these in detail, I'll try to re-read the existing papers on FRP, which I hardly understood initially :-) Thanks, Peter Stefan O'Rear wrote:

On Wed, Sep 19, 2007 at 10:24:24PM +0100, Neil Mitchell wrote:

...

Hi Peter,

...

So I grabbed ghc-6.7.20070824 (=the latest one for Windows I could find) and the "extra-libs", compiled and installed the GLUT package (which I needed), but when I compile my library, I get

Could not find module `Data.Map': it is a member of package containers-0.1, which is hidden

All dependencies etc. have changed when going to 6.7/6.8 - you are probably better off using 6.6.1 for now.

I also don't think that the debugger will help you track down infinite loop style errors. You might be better off posting the code and asking for help.

You said 0% CPU. That's *very* important. It means that you are using the threaded runtime (GHCi?), and that you triggered a blackhole. You should be able to handle this by compiling your program with -prof (do *not* use -threaded!), and running with +RTS -xc. With luck, that will give you a backtrace to the infinite loop.

PS. blackholes are a serious dark corner of GHC's execution model, chances are better than even that if you try to use the debugger for this you will discover a new and (for you) crippling bug. I wouldn't recommend it.

Stefan

On Fri, Sep 21, 2007 at 05:40:59PM -0300, Felipe Almeida Lessa wrote:

On 9/21/07, Peter Verswyvelen wrote:

...

Since I'm used to write heavily multi-threaded/multi-core code in imperative languages, I would like to understand more about the existing execution models, and those "black holes"... Understanding the low-level details helps a lot for me.

I think you want to know about the STG, the Spineless Tagless G-Machine. If I'm correct, that's how GHC works behind the scenes.

STG is a very pretty island, but it's just that - an island. If you want to see the Big Picture, I can only recommend SPJ's 1987 (except for the optimization section, almost everything is still true) book: http://research.microsoft.com/~simonpj/papers/slpj-book-1987/slpj-book-1987.... Stefan

Hello Peter, Saturday, September 22, 2007, 1:41:44 AM, you wrote:

Is this still up-to-date with the way GHC/GHCi work internally? Then I'll certainly check it out.

you should look at SPJ papers' page. it contains section with ghc-implementation details. just a few papers from there, sorted by publication time: Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine. [http://research.microsoft.com/copyright/accept.asp?path=/users/simonpj/paper...] [http://www.haskell.org/ghc/docs/papers/run-time-system.ps.gz] Making a fast curry: push/enter vs. eval/apply for higher-order languages [http://www.haskell.org/~simonmar/papers/eval-apply.pdf] -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Super, really looking forward to GHC 6.8.1 then. Is it ready for primetime on Windows? Again, someone should really build an IDE around all these goodies, but yes, that is a massive undertaking. Cheers, Peter

The debugger in 6.8.1 can also help to track down loops and deadlocks. Set -fbreak-on-error, run the program using :trace, and hit Control-C when it hangs. Then :history will give you a list of the most recently-visited points in your program, so you can step back and inspect the values of variables.

Cheers, Simon

...

All dependencies etc. have changed when going to 6.7/6.8 - you are probably better off using 6.6.1 for now.

That's a petty. I really would like to experiment with the debugger :-)

Me too! A proper release of GHC 6.8 is very nearby, so you should get your wish then. Thanks Neil