![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kpreidImplementing the stream-IO interfaces for E. It's mostly complete, but there's an executing-blocking-code-in-the-wrong-thread bug which Shouldn't Be Happening. I'm inclined to think it's a bug in E, except that the code explicitly does things which break E's reference discipline and I'm not sure that it isn't due to that.
An RDF parsing/processing library in E, which was the subject of the previous post. Stalled because I found the design didn't allow for provenance/contexts in merged graphs.
Recently discovered: Lion Kimbro's OneBigSoup project (weblog, wiki). Lots of ideas here.
Goal, roughly: More interconnection between existing Internet-based social tools.
Pieces I'm finding interesting: LocalNames, UniversalLineInterface
I've been helping Lion with ULI tools (DICT protocol gateway, support for ULI over HTTP GET when appropriate), and talking about capability security principles.
Though I can't imagine any specific use for it yet, I wrote a ULI client on Waterpoint - $local.uli.
The current implementation of E is absurdly slow. It's an interpreter, mostly unoptimized, implemented in Java.
My project: E implemented in Common Lisp—translating E to CL code and implementing ELib with CLOS.
Many Common Lisp implementations compile source to machine code at runtime, and a sufficiently clever translation of E code should benefit from this.
Status: The Kernel-E to CL translator is mostly complete. I have a crude Updoc implementation in CL, which I use for testing the other parts. ELib is only as complete as I've needed to test the translator.
Micro-status: Trying to figure out why var x := 2; x := x returns 0 instead of 2, and yet sets the variable correctly for later code.
