[Haskell-cafe] Re: GSOC Haskell Project

[Mihai Maruseac]

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
<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
>>
>>
>