Re: status report

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Thu, May 10, 2007 at 11:15:26PM -0700, Ben Pfaff wrote:
>      The last week or so I've been cleaning up the simpler-proc branch
>      for review and eventual merging.  I think that this process will
>      probably take another week or two.
>      
>      I've also done some performance regression testing on
>      simpler-proc versus the main branch and discovered some places
>      where simpler-proc performance was bad, especially in sorting.  I
>      fixed the worst of it but there's still a little needed
>      improvement before it'll be ready for merge.  Probably only a few
>      hours worth of work there though.
>
> Do you anticipate the merge to be an atomic operation, or can it be
> done piecemeal?

I hope to make much of it piecemeal and non-disruptive.  Some
parts of it will probably require some "atomicity".

At the moment I'm contemplating breaking it up into a series of
individually atomic patches, using a patch management system such
as Quilt, and then getting the individual patches reviewed before
starting to do commits.

> Last time I looked, the data sheet in the GUI was non-functional in
> the simpler-proc branch.  If the new datasheet/casereader is
> reasonably stable, then perhaps now is the time to start looking at
> this.  I'm coming to the conclusion that the stuff in lib/gtksheet is
> overcomplicated, largely due to its legacy from the gtk-extra
> library.   My current feeling is that we should cut out all the
> features of gtksheet that we're never likely to use.  This should make
> it leaner and easier to work on.  

I guess there are two issues here.  First the GUI in the
simpler-proc branch.  I have modified it only enough to hook it
into the datasheet code and make it compile.  I haven't even
tried running it and so as you say I imagine it doesn't work.  I
will be sure to debug it before proposing a merge, although it's
possible that I'll need some debugging help.

Second the idea of cutting up gtksheet.  Is this independent of
the simpler-proc merge or is there some connection?

> It looks good.  I think that some of the appendices from the user
> manual should be moved there.

Yes, I've done that too in my working tree.

>              * Pintos: My educational operating system used at
>                Stanford and elsewhere.  I'm currently working to
>                integrate the contribution of a USB mass storage layer,
>                which allows students to demonstrate their projects on
>                real machines by running the OS off a USB flash drive.
>                This is considerably more impressive than running
>                inside a virtual machine as they currently do, so it
>                seems worthwhile, but I'm very picky about what I put
>                into Pintos so I'm having to do a lot of refactoring
>                work.
>
> Does that mean Pintos will be able to run on the OLPC?  or could it in
> the future?

I think that I may have been unintentionally misleading here.  By
"educational OS" I don't mean an OS that runs educational
software, I mean an OS designed to help teach computer science
students how to design and build operating systems.

I don't know much about the OLPC hardware.  If it has a legacy
PC-compatible chipset and a UHCI-compatible USB controller
accessible via PCI, then it would probably work.
-- 
Ben Pfaff
address@hidden