GSoC

GSoC

[Simon Marchi]

Hi everybody,

A friend of mine suggested that the GDB project should participate in 
the Google Summer of Code.  However, the deadline to register as a 
mentoring organization is this Thursday, in two days!  So we need to act 
fast if we want to participate.  From what I can see, the application 
process is relatively straightforward, but somebody needs to take care 
of it (I don't think it has to be the person who will be the mentor, 
since this may depend on the actual chosen project).  I can be that 
somebody if nobody else wants to.

First of all, I have seen that GDB has been accepted as a mentoring 
organization in the past:

  - https://sourceware.org/gdb/wiki/SummerOfCode2014/Ideas
  - https://sourceware.org/gdb/wiki/SummerOfCode2011/Ideas
  - https://sourceware.org/gdb/wiki/SummerOfCode2009/Proposal
  - https://sourceware.org/gdb/wiki/SummerOfCode2009/Ideas

It would be interesting to gather some feedback from those who lead this 
initiative in the past.  Would you suggest trying to go for it again?  
Why, why not?

About the actual projects ideas, I'm sure we will be able to collect 
good ideas from the members of the community.  There's always the 
ProjectIdeas page on the wiki [1] to get some inspiration.  On my side, 
there's the output colouring support which I'd like to see become a 
reality some day :).

Simon

[1] https://sourceware.org/gdb/wiki/ProjectIdeas

Re: GSoC

[Phil Muldoon]

On 07/02/17 21:00, Simon Marchi wrote:
> Hi everybody,
> 
> A friend of mine suggested that the GDB project should participate in the Google Summer of Code.  However, the deadline to register as a mentoring organization is this Thursday, in two days!  So we need to act fast if we want to participate.  From what I can see, the application process is relatively straightforward, but somebody needs to take care of it (I don't think it has to be the person who will be the mentor, since this may depend on the actual chosen project).  I can be that somebody if nobody else wants to.
> 
> First of all, I have seen that GDB has been accepted as a mentoring organization in the past:
> 
>  - https://sourceware.org/gdb/wiki/SummerOfCode2014/Ideas
>  - https://sourceware.org/gdb/wiki/SummerOfCode2011/Ideas
>  - https://sourceware.org/gdb/wiki/SummerOfCode2009/Proposal
>  - https://sourceware.org/gdb/wiki/SummerOfCode2009/Ideas
> 
> It would be interesting to gather some feedback from those who lead this initiative in the past.  Would you suggest trying to go for it again?  Why, why not?
> 
> About the actual projects ideas, I'm sure we will be able to collect good ideas from the members of the community.  There's always the ProjectIdeas page on the wiki [1] to get some inspiration.  On my side, there's the output colouring support which I'd like to see become a reality some day :).
> 
> Simon
> 
> [1] https://sourceware.org/gdb/wiki/ProjectIdeas
> 
> 

From an idea standpoint I'd love to see the underpinnings of inferior
control* capabilities from scripting languages. Perhaps a class that
registered scripting languages can call (currently Python and Guile)
to affect control of an inferior, with feedback, from an interface. It
would ideally abstract all the horrible details from the scripting
language.

Note, I do not think this will be an easy project, but it will
introduce the person to the community as, I think, they will have to
question it quite closely to implement the semantics and exceptions
involved in inferior control to an external interface.

Cheers,

Phil

* Inferior control being more than being a gdb.command call and hoping
  things go ok.

Re: GSoC

[Simon Marchi]

On 2017-02-07 16:40, Phil Muldoon wrote:
> From an idea standpoint I'd love to see the underpinnings of inferior
> control* capabilities from scripting languages. Perhaps a class that
> registered scripting languages can call (currently Python and Guile)
> to affect control of an inferior, with feedback, from an interface. It
> would ideally abstract all the horrible details from the scripting
> language.
> 
> Note, I do not think this will be an easy project, but it will
> introduce the person to the community as, I think, they will have to
> question it quite closely to implement the semantics and exceptions
> involved in inferior control to an external interface.
> 
> Cheers,
> 
> Phil
> 
> * Inferior control being more than being a gdb.command call and hoping
>   things go ok.

I think that's a great idea, it's something that a lot of people ask 
for.  I think it's a good thing to have project ideas that range from 
easy to difficult, as long as it's clearly documented so that the 
potential candidates make informed choices.

Simon

Re: GSoC

[Jose E. Marchesi]

    
    A friend of mine suggested that the GDB project should participate in
    the Google Summer of Code.  However, the deadline to register as a
    mentoring organization is this Thursday, in two days!  So we need to
    act fast if we want to participate.  From what I can see, the
    application process is relatively straightforward, but somebody needs
    to take care of it (I don't think it has to be the person who will be
    the mentor, since this may depend on the actual chosen project).  I
    can be that somebody if nobody else wants to.

Note that if for whatever reason you don't make it, or if you want to
avoid the overhead of organizing, GDB can still participate under the
GNU umbrella.

We already applied as a mentoring application, and are currently
collecting project ideas in summer-of-code@gnu.org.

Re: GSoC

[Simon Marchi]

On 2017-02-07 16:41, jose.marchesi@oracle.com wrote:
> A friend of mine suggested that the GDB project should participate in
>     the Google Summer of Code.  However, the deadline to register as a
>     mentoring organization is this Thursday, in two days!  So we need 
> to
>     act fast if we want to participate.  From what I can see, the
>     application process is relatively straightforward, but somebody 
> needs
>     to take care of it (I don't think it has to be the person who will 
> be
>     the mentor, since this may depend on the actual chosen project).  I
>     can be that somebody if nobody else wants to.
> 
> Note that if for whatever reason you don't make it, or if you want to
> avoid the overhead of organizing, GDB can still participate under the
> GNU umbrella.
> 
> We already applied as a mentoring application, and are currently
> collecting project ideas in summer-of-code@gnu.org.

Ok, good to know, thanks.  I think it's still a good idea for projects 
to apply on their own to increase visibility.

Simon

Re: GSoC

[Tom Tromey]

>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

Simon> It would be interesting to gather some feedback from those who lead
Simon> this initiative in the past.  Would you suggest trying to go for it
Simon> again?  Why, why not?

I did it in the past but stopped because I wasn't spending enough time
mentoring.  I think it is worth doing but you have to be more organized
and committed than I was.

Simon> On my side, there's the output colouring support which I'd like
Simon> to see become a reality some day :).

I actually did this, but I didn't submit it.  I got sort of mired in
design choices.

The first approach I took was to just hack some color stuff directly the
CLI ui-out, and add a way to "set color <mumble>" (I don't actually
remember exactly how I spelled this, and the branch is long gone).  This
required some hacks to get the column computation to be correct so that
wrapping wouldn't suffer.  I think I just made it so the color string,
whatever it was, was assumed not to take any space -- a hack since this
wasn't actually enforced.

This was a bit too inflexible for me so I abandoned it.


The second approach I took (I still have this branch) was to let the
Python layer insert an object that would replace the CLI ui-out object.
Then colorizing and other reformatting -- the Python ui-out object is
"MI-like" and so had access to more data -- could be done by writing
some Python code.

I liked this approach ok but it needed some hacks (maybe since obsoleted
due to Pedro's recent work, not sure).  Also I think it suffered because
there was no way to get the wrap hints into the Python layer.

And, finally, for something like "set color", there's no good way to
implement completion because there isn't a list of the table- and
column-names.  This could be done by introducing enums or something like
that, but at that point the patch is going to be beyond what I would
want to commit to.

Tom

Re: GSoC

[Simon Marchi]

On 2017-02-08 12:12, Tom Tromey wrote:
> Simon> It would be interesting to gather some feedback from those who 
> lead
> Simon> this initiative in the past.  Would you suggest trying to go for 
> it
> Simon> again?  Why, why not?
> 
> I did it in the past but stopped because I wasn't spending enough time
> mentoring.  I think it is worth doing but you have to be more organized
> and committed than I was.

Ok, thanks for your feedback.

So since nobody spoke against it, I'll submit an application today, 
we'll see where it leads.

> Simon> On my side, there's the output colouring support which I'd like
> Simon> to see become a reality some day :).
> 
> I actually did this, but I didn't submit it.  I got sort of mired in
> design choices.
> 
> The first approach I took was to just hack some color stuff directly 
> the
> CLI ui-out, and add a way to "set color <mumble>" (I don't actually
> remember exactly how I spelled this, and the branch is long gone).  
> This
> required some hacks to get the column computation to be correct so that
> wrapping wouldn't suffer.  I think I just made it so the color string,
> whatever it was, was assumed not to take any space -- a hack since this
> wasn't actually enforced.
> 
> This was a bit too inflexible for me so I abandoned it.
> 
> 
> The second approach I took (I still have this branch) was to let the
> Python layer insert an object that would replace the CLI ui-out object.
> Then colorizing and other reformatting -- the Python ui-out object is
> "MI-like" and so had access to more data -- could be done by writing
> some Python code.
> 
> I liked this approach ok but it needed some hacks (maybe since 
> obsoleted
> due to Pedro's recent work, not sure).  Also I think it suffered 
> because
> there was no way to get the wrap hints into the Python layer.

Well first of all, what is your idea of how the coloring should be?

As a first step, I am envisioning, at least as a first step, to have 
symbols, value, file paths, etc, each printed in their own color, so 
that it's easy stop quickly spot the relevant information in a printout. 
  I have made a mockup here:

   http://nova.polymtl.ca/~simark/ssg/filemC7ZUZ.png

However I have found that it's easy to go overboard with it, at which 
point it looses of it usefulness, despite being a nice Christmas tree:

   http://nova.polymtl.ca/~simark/ssg/fileEv2diU.png

> And, finally, for something like "set color", there's no good way to
> implement completion because there isn't a list of the table- and
> column-names.  This could be done by introducing enums or something 
> like
> that, but at that point the patch is going to be beyond what I would
> want to commit to.

I don't understand this part.  Which tables/columns?

Thanks!

Simon

Re: GSoC

[Tom Tromey]

>>>>> "Simon" == Simon Marchi <simon.marchi@polymtl.ca> writes:

Simon> Well first of all, what is your idea of how the coloring should be?

I was more focused on infrastructure, not the defaults.  So I just left
it all to the user.  In fact my branch doesn't actually even have the
colorizing code, just the Python ui-out stuff; I have a separate .py
file that I use for experimenting.

Now that I look at that file again I do see a wrap_hint method, so maybe
the wrapping wasn't really a problem like I'd thought.  Hard to recall.
Also I see I didn't even really try to implement "set color" in this
code, so I must have just been changing the Python by hand.  Haha.

If you want to see the branch I can push it.

Simon>   http://nova.polymtl.ca/~simark/ssg/filemC7ZUZ.png

Looks nice.

>> And, finally, for something like "set color", there's no good way to
>> implement completion because there isn't a list of the table- and
>> column-names.  This could be done by introducing enums or something
>> like
>> that, but at that point the patch is going to be beyond what I would
>> want to commit to.

Simon> I don't understand this part.  Which tables/columns?

My approach is based on reusing ui-out stuff, the idea being to
associate a color with the ui-out table (or tuple or list) name and the
field name.

I suppose this wouldn't actually work for value printing, since that
doesn't use ui-out.  So maybe some other design is needed; or maybe
value printing needs to be changed a bit.

Tom

Re: GSoC

[Simon Marchi]

On 2017-02-09 10:47, Simon Marchi wrote:
> So since nobody spoke against it, I'll submit an application today,
> we'll see where it leads.

Ah damnit, "Applications closed February 9, 2017".  I guess they meant 
"exclusively" when they said the deadline was Feb 9...