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