John Darrington <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ pspp-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/pspp-dev
