Sunday, September 30, 2007

FReT 0.4 is approaching

ASDF integration for FReT now works on at least one lisp implementation. Now to test with one other implementation, and do a 0.4 release. This one has been a long time coming. After that... use it for some real work and see if I consider it usable.

Otherwise this is going to have been a lot of wasted effort.

Tuesday, September 25, 2007

Troubles extending ASDF

ASDF is a huge improvement over system definition facilities that had preceded it. I always found mk:defsystem to be a bit of a monstrosity. But one of the great benefits I had expected from ASDF, extensibility, leaves a lot to be desired.

I have, after a long break, returned to integrating FReT into ASDF. I want to define an ASDF operation, along with other instrumentation, so that one can execute a FReT test suite directly through ASDF. For example, after loading FReT, one should be able to run:

(asdf:operate 'fret:fret-op 'fret-test)

This should execute the FReT test suites.

ASDF does not make this easy. ASDF does not perform any operations on components other than files. So you can't really ever instrument an arbitrary component to call an :after method. If you're loading a system, there is no way to know when you're done loading. So if I have a test suite defined on a component, and I want to test that component, I can't know when to run the test suite.

I found a way around that problem. I defined a virtual FReT source file that is added after the component is defined that depends on all other components in the system to test. I wanted to add the virtual file in the :after of initialize-instance of the fret::component class, which inherits from asdf:component. I was thwarted again. ASDF does not really do anything interesting in its make-instance method, only in its reinitialize-instance. The components however aren't even set here, but rather through a setf.

The manner in which I've had to implement this new operation seems quite convoluted. With a bit of forethought I imagine this could have been greatly simplified. For now I'm happy to have everything working.

Saturday, September 15, 2007

Working on FReT again

I've finally started work on FReT again. I want to actually start using it. Seems like such a waste to have put so much effort into getting so far, and then not being able to use it. I have yet to implement an essential feature of the software: being able to run a test suite/script through an ASDF operation. The ASDF operation must run an operation after a load has been performed on an instance of a module. For example, we would define a test definition for FReT itself as follows:

(defsystem fret-test
:class fret:system
:components ((:module test-support
:components ((:file "framework-tests-support"))))
:test-script fret::fret-test-script
:depends-on (fret))
Then, calling (asdf:operate 'fret:fret-op 'fret-test) should execute the test suite. fret:fret-op would be a subclass of asdf:load-op, and would only define an after method on whatever generic function signaled the completion of loading a testable module, in this case fret-test itself. I could have done without subclassing load-op, but then I would not be able to do a straight load.

The model here is that a system would be able to add a test suite into the primary system definition if it only had a set of simple tests. If the tests required any support code (as FReT's tests do) then we would have to introduce a separate system. Another reason we need to separate out the tester system for FReT is that the tester system cannot be declared without FReT. It is the only piece of software which would run into such a bootstrapping problem.

At present though it appears ASDF does not signal the completion of loading a module through any generic function. So I cannot know when I should run the test suite for a module, as I don't know when it has finished loading. I've posted a message on the mailing list asking for advice, as soon as I have some I'll be able to finish up my implementation.


Friday, September 14, 2007

Facebook, here I am!

Some time ago I got around to creating a profile in Facebook, when a friend invited me to do something or the other on there. No, I really don't remember the circumstances. Now I'm a bit addicted to Facebook, despite certain annoyances in how it pushes applications you're using on to your friends. (Yes, I realize that would work for some, but everyone doesn't work the same way.)

I'm fascinated with the simplicity of Facebook's architecture, and the power it produces. Each application is basically a function you can apply to data, which is the list of your friends. Each use of an application generates a message to all your data. There's a bit of window dressing to go along with this basic idea, such as being able to search for friends and applications, managing email, etc. But there really doesn't seem to be that much more to it. The only other social networking site I've tried is LinkedIn, which by contrast seems quite static. But then it does so much more with that static structure. Would it be possible to implement LinkedIn on Facebook?

Performance tuning in lisp

The more I use Lisp, the more I appreciate it. Recently I had to tune up the performance of a knowledge based application running on Allegro CL. We made extensive use of a reasoner. The reasoner, being a reasoner, had to be general purpose. Our application used a subset of the reasoner. The manner in which we went about performance tuning could possibly be done with any language capable of introspection, but this is just about lisp.

Broadly speaking, I see two approaches to tuning performance: use a better algorithm, and cache intermediate results. Given that the reasoner was essentially a library, we didn't have sufficient understanding to perform serious algorithmic tuning. However, there was a lot we could do with caching.

Consider that in a full frame based reasoner, a general purpose application could be creating arbitrary knowledge. At no point can we make a "closed world assumption" and optimize certain behaviors of the reasoner. However, an application using the reasoner does know when to make such assumptions. For example, we may enter a phase of computation where we're not creating any new classes, or creating any new slots. In our case, we never create any slots after compile time. So we can safely start caching the results of all computations performed on slots. For example, computing the inverse of a slot can potentially be a complex operation, but since we know we aren't going to see any operations on slots we can start caching these slot inverses.

Here's where Lisp comes in. The function that computes slot inverses is a library function that we don't control. Given that we can manipulate the symbol table, however, we can create a wrapper around the function body, and setf the wrapper to the symbol's function value. This will not catch all types of uses of the slot inversion function. It catches most of them though, and the result is a noticeable performance improvement. So, not only does Lisp allow us to apply targeted optimizations in software we have ourselves written, but it also allows us to apply optimizations in software we've inherited as libraries, based on the usage pattern of those libraries in the final application.

Wednesday, September 12, 2007

New toy!

I recently got myself a new lens: the Canon 10-22mm EF-S. I always wanted a wide lens, but couldn't find anything suitable given the reduced sensor size. I looked around and picked out three: the Sigma 12-24mm, Tamron 11-18mm, and the Canon. The Canon is the most expensive of the three, but the quality of the images I'm getting from it is exceptional. (Especially after getting a friend's help in cleaning out the camera sensor! Very important!) The salesperson that helped me out at Calumet steered me away from the Sigma, due to sample variance. The Sigma though has the distinction of being a full frame lens with that wide a view. The glass though has to bulge out to the extent that putting any sort of filter on it is impossible. The Tamron turned out to be a good lens, but much clunkier. And noisier.

I've now taken a few photos with the lens. Problem's right now with the photographer, and not the lens. We recently took a trip to Mt Tam, and went up to the east peak. I tried taking some wide landscape shots. Getting close enough to the edge to get an unobstructed view was difficult for me, given my fear of heights. So many of the images turned out rather unsatisfactory. I also tried on Mission Peak, and I think had more luck there. Still a lot to learn. Exciting!!

Monday, September 3, 2007

New toys, virtual and real

I've got myself a couple of new toys: I've started playing with facebook, and I got myself a Canon EF-S 10-22mm lens, which in 35mm equivalent is 16-35mm.

I'm impressed with facebook. There's of course the social aspect of facebook that's been beaten to death. The site however is well put together, especially the manner in which applications work within the relatively clean UI. (There's a lot in the UI, but that's OK.)

As for my non-virtual toy... I spent a lot of time agonizing over which lens to get: Sigma 12-24mm, Tamron 11-18mm, or the Canon. With a Canon 30D, given the small sensor size, getting a wide angle is difficult. I wanted to get down to about 2omm, but regular lenses don't cut it. And I didn't want a lens that's specifically designed for the small sensor size, since that would make graduating to a full frame camera difficult. (Not that there's any reason to believe that's going to happen any time soon, but just in case...) The Sigma fits a full frame camera, but the chromatic aberration seems quite bad. Plus I've heard Sigma has a real problem with sample variance. The Tamron was quite nice, but the feel of the lens was clunky compared to the cannon. The cannon was smoother and faster, both mechanically and optically. It was also more expensive.

I got the lens on Saturday. We went to Mission Peak that day, and took a few photographs. I'm in the process of sorting through them, and I'll eventually put them on my gallery on Picasaweb. The short of it is that the lens is great, but the photographer isn't. I have a lot to learn if I'm going to use this lens well. I think I got a couple of decent shots out of it.


Simulated worlds, and agents therein

I had started working on implementing a simulated world based on a discrete event simulator ages ago. I've finally started working on the software again. It's taken a bit of work to get going on it again. The code is strangely complex, and I'm now getting re-acquainted with my intentions when I had put it together that way. I'm struggling with the implementation of the simplest agent, one that perceives the artificial worlds, and is able to act in it. Just getting the notions of simulated world, perception and action worked out are turning out to be quite challenging. I'm looking forward to getting this simple agent model working, I haven't designed any AI software from scratch in a long time, so this is rather exciting.