All of this worked great until the first apt package update, which installed a new version of GRUB, the boot manager. This apparently messed up the Windows 7 bootloader so that it could no longer boot the Linux filesystem, and my reading the Ubuntu forums didn't inspire much hope of ever getting it to work. In order to recover my 3 days worth of work, I had to create a rescue CD, mount NTFS, and then mount the virtual Linux filesystem within it. Then partition the drive to add a new Linux partition, rsync the data over to the new partition, and configure a boot loader for a more conventional dual-boot system. This took about a day to figure out.
In any case, I now have Ubuntu working well, although I haven't yet learned how to set up the boot table needed to boot back into Windows. That can wait for the moment. I have Google Chrome and Eclipse humming along nicely, with sufficient tweaking and customization that I can be decently productive. The fact that I am able to type this email relatively fast, with no illumination on the keyboard is an indicator that from a form-factor standpoint this laptop was the right choice. And it's nice and light - the case is carbon fiber.
(BTW, with regards to Chrome - at first I had planned to just get by with Firefox, and I spent a couple of days using that. But I'd gotten used to using Chrome at work - in particular, the "control-T + start typing" gesture to open a new tab and search is surprisingly addictive. So I broke down and installed Chrome and I find that I am a lot happier.)
In any case, I was able to spend the rest of the week focused on the reason that I got the laptop in the first place: Getting Tart to compile and run under an operating system other than Darwin/OS X. That took a while, but I was finally able to check in a version that runs all tests on Linux as well as OS X. One issue that bit me a number of times is that the order of link libraries is significant under Linux, but not under OS X - although I think that's probably more a function of the version of GCC that's available on those systems.
In addition to all that, I worked on a number of other minor Tart issues - during those periods where I was stumped on getting it to compile and run on Linux. One thing that I have been working on is a rough sketch of a "pure Tart" garbage collector. Recent changes in the Tart language (or more precisely, in the "unsafe" mode language extensions) have led me to the belief that the performance penalty for writing the collector in Tart might not be as significant as I originally estimated.
Of course, some parts, such as the mutex code, will have to be written in C unless I can figure a way to get Tart to call POSIX and Win32 functions directly. But the collector algorithms might not have to be. At least, when I look at the Tart classes, and their C++ equivalents, I can imagine how the code would be generated in either case and I'm thinking that it might not be that different. The biggest hurdle will be dealing with pointers that have flags in the low bits - i'll probably have to add some special compiler intrinsics to deal with that case. There are plenty of other potential bottlenecks to performance that I can perceive, but those bottlenecks would be present in a C/C++ implementation as well as a Tart one.
The advantage of writing a Tart GC is that it will stress the language design in a way that I would like it to be stressed - that is, the challenge of writing efficient low-level code. The disadvantage is that it's less likely that someone will come along and re-use my GC for another language (and hopefully improve it in the process) - in other words, there might be less eyeballs on the code. However, at this point it's by no means certain that such additional eyeballs will ever manifest.
Another thing I've done (which is not checked in yet) is created an Eclipse plugin for Tart source code. It handles syntax highlighting and a few other minor editing tweaks like auto-indentation. It doesn't handle reformatting or refactoring of any of the advanced stuff. Sadly, it appears that the Eclipse framework doesn't handle this in a generalized way - meaning that each different language has to define it's own AST, Parser, and refactoring engine. Thus, JDT, CDT and PyDev - for example - are all separate plugins that don't share any code other than the basic Eclipse platform.
For now, the plugin is good enough to edit Tart code with, and I'm hoping that some Eclipse enthusiast will come along and finish what I've started :)
--
-- Talin
-- Talin
No comments:
Post a Comment