![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Programming observation #2
Monday, February 20th, 2006 22:31If your translation of a program from language X to language Y has a bug even though the translation can’t possibly be wrong in that spot, check whether the original has the same bug.
Programming observation #1
Saturday, February 18th, 2006 20:20Many kinds of nonworking programs take much less time to run than the related working program. This is very useful when one is attempting to achieve the working program and one already has a sufficient means of distinguishing them.
Old WireWorld
Wednesday, October 26th, 2005 17:45When I used the Apple IIgs, I played with an implementation of an extension of the WireWorld cellular automaton.
My previous entry contains the programs I recently wrote to decode my old pattern files. (If you read it earlier: I've now updated it to include a full SHR converter.)
These were originally created in 1996-1998, except for “Sample.Fix”, which is a trivial modification of a pattern which came with the program.
The extensions are rather complex in the details, but essentially, green cells are crossovers (horizontally moving electrons don't interact with vertical wires, etc.) and cyan cells are switches (electrons arriving on the wire that ends at the switch break or join the wire that (typically) crosses the switch).
( More patterns )
connected quotes
Saturday, June 18th, 2005 22:11(Occasionally a computer scientist will get nervous about writing a paper or working on a proposal having to do with garbage collection. In cases like this, the phrase storage reclamation tends to be used. It means the same thing.)
… Memory locations…are just wires turned sideways in time.
— The Connection Machine, W. Daniel Hillis
(I’m sure some connection can be made to Henry Baker's work, but I don’t feel up to trying to do so.)
Project #4 update
Monday, October 11th, 2004 02:38Micro-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.
Between those statements in the actual test script was:
? x := 0
Sigh/yay. Now that the existing tests are working, I can get back to adding (tests for) support for more of E and ELib.
Implementing 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.
