I woke up this morning to find out that I had won the $299 AbiWord patch prize! Thanks to all the people at SourceGear who made it possible for me to have so much fun working on AbiWord. According to the wee kly news, I tried to lose the prize by reversing an old consensus. I'd better calm down with these contraversial changes :/.
One of the only problems of the week from AbiWord that is still not completed is the Printing accented characters on UNIX challenge. I made some significant progress in debuging the code today. It has been very confusing since I know that gnome-print works with accented characters, and when I dropped in its parseAFM implementation the problem still existed. The conclusion that I am forced to draw is that either something is wrong with our font metrics files or that AbiWord doesn't use the widths tables correctly. Right now I am persuing the first theory. From the code of gnome-print, I've observed some differences between how it calculates character widths and how AbiWord does. They're pretty minor differences but I'm slowly checking them all out. However, it is possible that this is a bug in parseAFM that weirdly enough is affecting AbiWord but non gnome-print. If anyone knows any other GPL-compatible implementations of parseAFM, I want to try them! The misprinting of accented characters is a big problem that hits me whenever I print out French homework and I like to fix problems that affect me a lot more than those that don't. I also have a strong hatred towards all of the anti-WYSIWYG bugs - I'm not a big fan of WYSIWYG, especially Page Layout mode, but when it claims to be WYSIWYG and is not, I'm not very happy. The most infamous of these bugs is #514. It is another one that affects me a lot because I use tabs for outlines and this bug has forced me to manually break lines early to prevent disasterous print results. Maybe I will tackle this if/when I resolve the PostScript accents problem.
Cool thing of the day:Vapour. I always thought that OS's would always have the same design. Today I talked to the author of this slick, operating system that's in development on EFNet #lisp. I found his design for this operating system amazing. Essensially, rather than a trusted kernel in memory, there is a trusted compiler in memory. You feed LISP sources into the compiler, and it produces a native binary in the linear address space of the computer's RAM. Since LISP has no pointers, it cannot arbitrarily touch memory. There are a few mallicious things that could be done with LISP but I imagine that the compiler will be very strict about these. Everything runs in supervisor space since the compiler only lets things that wouldn't crash the computer run anyway. These binaries that the compiler produces are not really excecutable binaries, but there is one binary per function that any process can use. I use the word "process" losely, as processes on Vapour are more like threads running off the operating system. All functions are stored in memory and unused ones are swapped out, making the disk a giant swap partition. The OS will be completely self-hosting, and will be writen in its own native langauage (a dialect of Scheme). Of course, device drivers will need more permission than normal functions, and this will be handled by a form of superuser (this is my understanding but I may be wrong).
You may ask why this design would be any better than a monolythic kernel. Aside from being a very interesting architecture where all code can be shared and the system can guarentee that processes are safe to run, the author claims that such a system would cause a massive speed boost of about 8x in I/O, and there would be better IPC. Also, if you like LISP, this OS would turn your PC into the ultimate LISP machine.
I'm really looking forward to seeing how this project turns out. I was told "Give us 6 months to get the compiler self-hosting. That's the hard part." Once this becomes bootable for interested hackers, I'll have to give this a whirl. Right now the compiler r