Re: New language support : Vala

[Abderrahim KITOUNI <a.kitouni@gmail.com>]

2009/2/7 Tom Tromey <tromey@redhat.com>:
> I took a quick look through the patch and there are definitely things
> in there that won't apply today.  So, I suggest updating to CVS gdb
> and resubmitting.
I'll try to do it.
>
> Also, I noticed a fair amount of code not conforming to GNU standards
> -- missing spaces, spaces in the wrong places, comments that are not
> full sentences; IOW, the usual sorts of nits.  This will all come up
> in any eventual review, so I'd recommend taking a stab at fixing these
> beforehand.
I'll try to see (I thought it was ok).
>
> Any new file needs a copyright header.
I didn't know what to put in, I've sent it for a preliminary review.
>
> All new functions ought to have an introductory comment explaining
> their purpose, arguments, and return value.
ok
>
> For the stack.c change, I suggest a new language function that returns
> true if the symbol ought to be printed.  Other languages can always
> return 1.
I just didn't want to do big changes.
>
> I'm also not so sure about the valops.c change or the gdbtypes.c
> change.  In general I think explicit checks of the current language
> ought to be avoided in generic code.
OK, I'll try to put these in separate changes (eventually adding
functions to language definitions)
>
> I wonder whether some of this is better done in Python.  For instance,
> perhaps specialized value-printing stuff could be done using a Python
> pretty-printer.  (This code isn't in gdb CVS yet, but is coming
> soon... and you can use it today by checking out from Archer.)  My
> thinking here is that this might benefit all glib users, not just
> Vala.  But this is just an idea, I won't insist on it.
Maybe.
>
> Alternatively, I wonder whether some of the generic changes could be
> made unnecessary by having a real Vala parser.
I don't think so, but I'll try to minimize them.
I'll try to break the patch up into several little patches, that will
ease reviewing.

Regards,
Abderrahim