This is the mail archive of the
mailing list for the Archer project.
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Fri, 25 Jul 2008 14:43:17 -0600
- Subject: Tasks
- Reply-to: Tom Tromey <tromey at redhat dot com>
I started to look at breaking down the roadmap into discrete tasks.
Here's a rough draft. It is a bit concise since the initial tasks
have are investigatory... IMO we need to know a bit more and should
try to get some rough estimates on them so we can clump them into
- Set up bugzilla
- Set up git
- Set up auto-builder and patch tester.
BTW we can use the GCC Compile Farm for this if we like.
The first two are actual tasks, I'll do those.
The third one I can do, too, unless somebody is eager to do it.
* Expression parsing.
I think the first thing here is a good look at what we should aim to
do. Should we try to fix bugs? Or try for the full implementation?
Or both in parallel? If we're fixing bugs, what kind of thing are
we unlikely to be able to fix? If the full implementation, how big
a job is that really? In both cases, what dependencies do we have
This is probably the single biggest item.
Maybe a couple people should look at this..?
* Exceptions. Look at the existing longjmp stuff, come up with an
estimate for the new work. Also look at the current state of the
various "catch" commands, maybe look though gnats to see if anything
is known to be broken.
* Pretty-printing. My plan here has been:
- Merge in the existing python work
- Make it possible to associate a 'struct type' with a given Python
object, in the non-MI case (the MI case is already in
there... FWIW we'd want to use the same Python objects to handle
- Update 'print' to use this object if it exists
- Add 'print/r' (r == 'raw') to bypass the pretty-printer
- Write a bunch of pretty-printers for libstdc++. There are some
good examples to start from (some on the wiki)
So, for estimation we need to look at the size of some of these
parts, and also whether anything is missing.
* Smarter demangling. Figure out what this really means :). Look in
gdb bugzilla for info. Write some test cases. Look at gcc
* Scalability and shared libraries. Profile some examples. Figure
out what is wrong. Jan has some information here.
* Froggy. IMO too early to start looking at this for gdb... Chris,
Phil, Roland -- do you agree?
* GCC changes. I think the task list here should come from the above.
But, once we have that list of dependencies it would be worth making
another pass through GCC bugzilla to see what we are missing. So,
we can leave this one for a bit.
* Fedora patches. I think we can look at this as a case of patch
review... comments on this? So, no immediate investigation to do.
* For scripting and write-it-in-C++, I don't think we need to do
anything right away.
So, I think everybody should take an item, send a note to the list
about which you are going to do, and then later send a note about the
outcome -- a rough idea of what is involved, how big the changes are,
These estimates are just to help guide us in scheduling things. Given
that and our general newness to gdb, I would say give them a one month
I'll take whatever task nobody else wants.