Hmm, interesting. If I intend to give it a try, will there be a mentor for a GSOC project? Or should I start doing it alone?
On Thu, Apr 1, 2010 at 8:37 PM, Max Bolingbroke <[email protected]> wrote: > I still believe that it would much simpler to get some stack traces > out of GHC by just reporting what chain of thunks we are currently > forcing when we get an error. This just requires a way of reifying the > existing STG stack in some user-readable way. > > What it doesn't give you is lexical call stacks of any form, but many > people have pursued that goal and failed. The STG stack only tells you > the "dynamic" call stack, and will omit any frames removed due to e.g. > tail recursion optimisation, but at least it gives you *some* > information about where your "head []" error is coming from! > > For those interested, there is more discussion of the idea at > http://hackage.haskell.org/trac/ghc/ticket/3693 > > Cheers, > Max > > On 1 April 2010 18:22, Thomas Schilling <[email protected]> wrote: >> The DrScheme debugger shows backtraces as arrows in the source code. >> It took some getting used to, but it doesn't seem like a bad idea. I >> believe Leksah has some sort of graphical frontend for the GHCi >> debugger, but I haven't tried it out myself yet. Maybe you can build >> on top of that. >> >> Stack traces are rather difficult to implement. Tristan Allwood >> implemented stack trace support as a GHC Core plugin (see his 2009 >> Haskell Symposium paper) but it required quite a lot of recompilation. >> His stack traces also didn't record any values, just source >> locations. He also had some problems with the way mutually recursive >> functions with type classes were desugared and, as so often, CAFs >> (constant applicative forms). >> So if you propose to work on that you should have a good idea how to >> overcome such issues it in your application. >> >> Another problem with stack traces turned on is that they may lead to >> space leaks. I don't know how big of an issue this is in practise, >> but I'm pretty sure you can't just keep them turned on all the time. >> The GHCi debugger has a tracing mode that can be turned on explicitly >> and allows you to "go back in time" if you hit a break point or error. >> I believe a good front-end could make this a much more widely used >> feature. >> >> On 1 April 2010 17:39, Mihai Maruseac <[email protected]> wrote: >>> So, should I change the topic of the project to stack traces instead >>> of visual GUI representation? If this were the case, I will have to >>> find a way to represent those traces in a way that even a beginner can >>> read and understand (my GUI approach was for the beginners). >>> >>> -- >>> Mihai Maruseac >>> >>> On Wed, Mar 31, 2010 at 6:40 PM, Jason Dagit <[email protected]> wrote: >>>> >>>> >>>> On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow <[email protected]> wrote: >>>>> >>>>> On 30/03/2010 20:57, Mihai Maruseac wrote: >>>>> >>>>>> I'd like to introduce my idea for the Haskell GSOC of this year. In >>>>>> fact, you already know about it, since I've talked about it here on >>>>>> the haskell-cafe, on my blog and on reddit (even on #haskell one day). >>>>>> >>>>>> Basically, what I'm trying to do is a new debugger for Haskell, one >>>>>> that would be very intuitive for beginners, a graphical one. I've >>>>>> given some examples and more details on my blog [0], [1], also linked >>>>>> on reditt and other places. >>>>>> >>>>>> This is not the application, I'm posting this only to receive some >>>>>> kind of feedback before writing it. I know that it seems to be a >>>>>> little too ambitious but I do think that I can divide the work into >>>>>> sessions and finish what I'll start this summer during the next year >>>>>> and following. >>>>>> >>>>>> [0]: http://pgraycode.wordpress.com/2010/03/20/haskell-project-idea/ >>>>>> [1]: >>>>>> http://pgraycode.wordpress.com/2010/03/24/visual-haskell-debugger-part-2/ >>>>>> >>>>>> Thanks for your attention, >>>>> >>>>> My concerns would be: >>>>> >>>>> - it doesn't look like it would scale very well beyond small >>>>> examples, the graphical representation would very quickly >>>>> get unwieldy, unless you have some heavyweight UI stuff >>>>> to make it navigable. >>>>> >>>>> - it's too ambitious >>>>> >>>>> - have you looked around to see what kind of debugging tools >>>>> people are asking for? The most oft-requested feature is >>>>> stack traces, and there's lots of scope for doing something >>>>> there (but also many corpses littering the battlefield, >>>>> so watch out!) >>>> >>>> I would be much more interested in seeing the foundations improved than I >>>> would be in having nice things built on them. In other words, I agree with >>>> Simon that stack traces would be many times more valuable to me than >>>> graphical representations. Once the foundations are robust, then we can >>>> build nice things on top of them. >>>> >>>> Perhaps the reason you're interested in graphical representations is >>>> because >>>> you want to help people 'visualize', or understand, the problem. Not all >>>> visualizations need to be graphical in the GUI sense. It's really about >>>> representing things in a way that helps humans reason about it. Getting >>>> the >>>> right information to people as they need it is probably the best place to >>>> start. >>>> >>>> Jason >>>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> >> -- >> Push the envelope. Watch it bend. >> _______________________________________________ >> Haskell-Cafe mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
