On 1 Apr 2010, at 18:39, Mihai Maruseac wrote: > 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?
I'm sure Simon Marlow could mentor you except maybe if there are too many GHC-related GSoC projects. I could do mentor this as well. Or maybe Max. I don't think finding a mentor will be a problem. GHC's runtime stack actually uses the same data layout for both stack and heap objects, so you might be able to extend unpackClosure# to build something like Vacuum[1] (or extend it). [1]: http://moonpatio.com/vacuum/ > > On Thu, Apr 1, 2010 at 8:37 PM, Max Bolingbroke > <batterseapo...@hotmail.com> 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 <nomin...@googlemail.com> 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 <mihai.marus...@gmail.com> 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 <da...@codersbase.com> wrote: >>>>> >>>>> >>>>> On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow <marlo...@gmail.com> 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 >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> >>> >>> -- >>> Push the envelope. Watch it bend. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe