You are currently browsing the monthly archive for October 2008.

The embarrassment of riches truly astounds in the domain of ahem ‘very small’ lisp implementations… and who am I to refuse to fill an obvious missing link in the series?  We got small covered…

Yes, I have in fact begun a super cut down lisp implementation for vfuncs, which I think will be a nice way to express such idioms as map [hey, lisp invented map, right? – maybe not, better check ]

I’ve uploaded the new files atto.c, atto.h, attotest.c to the vfuncs project page – grab v0.6.7.

Some of the earlier blog comments around vfuncs got me to wondering.. How would you implement closure and currying in straight C so it could be used in useful array verbs?  It seems what you need is to replace some verb params with values from the ‘environment’.  That way the verb can use both runtime args and design time args easily… I did hack up something, but it began to look more and more like I was writing an interpreter… so I decided the ‘honest, unenlightened hacker’ way to proceed was to actually _write_ an interpreter for as simple a language as I could think of…

The core guts of lisp is, well – calling functions with args, when any of those args could be a const, a variable or another function.  So, the atto-kernel of lisp is something like this grammar [a comment pasted from the C source] –

//      expr : left func args right // (func arg0 arg1 arg2 )
//      args : arg args | empty // args is any length 0..n
//      arg  : ident | const | expr // each arg can be an expr itself – nested calls

In the spirit of ‘start small, get it working and add features’, this cut-down grammar allows you to parse expressions like the following –

//     “(sqrt (add (sqr 3.0) (sqr 4.0)) )”

This is the ‘lisp way’ – everything is in prefix notation ie. (* a b) not (a * b).  You get used to it, and it is very consistent [and the reason lisp macros are more part of the language than say C/C++ macros].

Read the rest of this entry »

After seeing some discussion about Kernel Tracing tools in the recent Linux Kernel Summit…I found this great tech-talk.

Dtrace is like ‘TiVo for the Kernel’ … its been included in FreeBSD and Solaris, but Linux is unlikely to embed it directly due to the incompatibility of the GPL with Dtrace’s licence.

Great Dtrace google talk video by one of the developers Bryan Cantrell [his blog here]…

Hilarious discussion of seeing into all the abstract layered levels that is software, nice demo tracing into both kernel and user space programs.

At the end he talks a while about how to view into scripting languages – normally you’d just see rbeval [for ruby] or the JVM implementation – but he decribes how to extend further to Dtrace into scripting Environments.   Superb!

He makes some frank comments about the political situation of porting Dtrace to Linux.

Perhaps solution is to make a clean room GPL  impl from the external API.. watch this space.

Whats immediately apparent from this talk is how useful Dtrace is for developers and sysadmins.

[ fyi, Im working on an ‘attolisp’ scripting implementation for vfuncs.. hmm.. now how to instrument it?  Can you believe nanolisp, picolisp and femtolisp project names were taken! what an embarrassment of riches! :]