[Haskell-cafe] Re: GSOC Haskell Project

Thu Apr 1 13:58:06 EDT 2010

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
> <batterseapower at 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 <nominolo at 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.maruseac at 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 <dagit at codersbase.com> wrote:
>>>>> 
>>>>> 
>>>>> On Wed, Mar 31, 2010 at 7:21 AM, Simon Marlow <marlowsd at 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 at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Push the envelope.  Watch it bend.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> 
>>> 
>> 