Showing posts from 2007


NAME trainspotting NOTES I want to tell you about my new hobby. I've started to collect inferno emulators. It's a little like trainspotting where the aim is to "spot" a certain type of emulator compiled to run for a particular platform. You get points for running the emulator yourself and bonus points for building the emulator yourself. Unlike trainspotting, I've come to think this hobby might not be completely pointless. So far my collection is not large. I can only claim to have run hosted emu on Plan9, MacOSX, Linux, Solaris, and Nt. Even so, I'm proud of it and would like to add more hosts. Imagine for a moment a collection of emulators that runs on every host, past and present, and with the social organization to port it to all significant future hosts. Wouldn't such a collection be valuable to others? For example, say you are interested in digital preservation, if you could write a program in limbo to interpret your special file format this col

lab 80 - drawterm plugin

NAME lab 80 - drawterm plugin NOTES This post is to show it is possible to use the inferno IE plugin to drawterm to plan9. All the programs involved are part of standard Inferno. These are the steps I did to get this running locally. It does need factotum etc, so you need to export a file system with all the pieces you need. % listen -vA 'tcp!*!7070' {export '#U/'} For the net you'd probably do this using an unauth'd readonly kfs, for example. Then you need a drawterm script % cat /drawterm #!/dis/sh bind -b /n/remote/dis /dis bind -a /n/remote / bind /n/remote/lib /lib mkdir /n/remote/n/9win bind -a /n/remote/n /n auth/factotum load std autoload=std getlines < /n/remote/factotum {echo $line} > /mnt/factotum/ctl bind /n/remote/ndb.local /lib/ndb/local ndb/cs 9cpu -h tcp!fir -r -c 'bind -b /mnt/term/n/9win /dev; bind -a /mnt/term/dev /dev; exec rio' And then you need the HTML <OBJECT classid="clsid:3A274C9A-1E70-435a-8A63-B

lab 79 - acme javascript

NAME lab 79 - acme javascript NOTES I'm excited about today's lab. I hope others pick up on this and experiment with it because I think some cool acme clients would come of it. The idea behind this lab is to mix together acme, javascript and json web services. I've been poking around at inferno's javascript, hoping to improve it. The best way of doing that is to start using it more heavily. In earlier labs I created a tool called js that ran javascript scripts outside of charon. But without knowing what set of host objects to build it has languished. Looking to use javascript more, I've been taking another look at web services APIs, and noticing that JSON is getting strong support, especially from Google and Yahoo. I'm pleased about this, since the SOAP stuff looked so horrid. So I really want to pull JSON web services into inferno using javascript. But web services don't work too well when text is just output to the command line, they need more

lab 78 - dynamic dispatch

NAME lab 78 - dynamic dispatch NOTES While experimenting with creating my own alphabet-like interfaces I found this technique, which I think is fascinating, and I hope to use it soon in further experiments with persistent mounts, something I'll blog about in the future. Here's a definition of a pick ADT that has some primitive types (I've left out the complete set to keep it short), and some helper functions to get the value from the pick. Value: adt { getfd: fn(v: self ref Value): ref Sys->FD; gets: fn(v: self ref Value): string; send: fn(v: self ref Value, r: ref Value); pick { S => i: string; F => i: ref Sys->FD; O => i: chan of ref Value; } }; The thing to notice here is the recursive definition of the ADT. We don't need to define chan of string or chan of FD. The Value.O type is a channel that can handle anything of ref Value, all our primitive types including ... chan of ref Value. So given a v : ref Value, we'd get, sa


NAME biomimicry NOTES The acme-sac tarballs I've been working on producing are intended to be compact, contain all the source, and be runnable once it is unpacked at its destination. The complete copy of it's own source means it can grow and adapt to its own environment. It can also create and host the tarballs of itself, thereby replicating and dispersing itself. This structure makes me think of spores. The running acme-sac instance on my laptop is creating spores which I'm casting out from my laptop across the internet hoping that new copies will unpack in fertile soil and form new living cells that themselves can grow and reproduce. This analogy is not new. And there are books on biomimicry for subjects other than computing. The question I have is, if the analogy is followed further and more explicitly what will be the results? Or put another way, should large software systems intentionally use biomimicry as a architectural solution? Alan Kay has used t


NAME emulators NOTES It's an emulated world. Emulators I've used just within the last 12 months. QEMU: Plan9, Linux BeebEm: BBC Micro RedSquirrel: RiscOs 3.1 VisualBoyAdvance: GBA DeSMuMe: Nintendo DS Smalltalk VM: Squeak Lisp VM: Scheme Dis: Inferno JVM: Java Microsoft CLR: .NET

bazaar development mode

NAME bazaar development mode NOTES I've created a new group for Acme:SAC development. The purpose is to develop acme-sac in the open by following the bazaar development model; all code changes are submitted as patches through the list; frequent releases of tarballs; and releases of both stable and experimental trees. Hopefully this means developers maintaining their own trees can cherry pick patches from the list. It doesn't require synchronization through source control system or membership to any project. For example, if you maintain your own inferno-os tree and see a fix you want, you can just apply the patch from the email using gnu patch. All that is required for someone to contribute is a download of an acme-sac tarball , a diff of their code change and email the list.

lab 77 - the unexpected markov

NAME lab 77 - the unexpected markov NOTES This is another unexpected use (again) of the markov program from the `The Practice of Programming', section 3.9 [1]. I wrote an implementation of markov under Limbo, and had fun feeding it with any texts (books, articles, interviews, novels ...). But recently I've been also playing with caerwyn's synth [2] which included in acme-sac, and thought why not feeding markov with music? Find out the answer by yourselves, I'll just provide some small hints in the accompanying guide file. Enjoy! [1] [2] synth from acme-sac under appl/synth FILES inferno-lab bachm.mp3 (the original bach file bach.mp3 )

lab 76 - using svn with gcode projects

NAME This is not a typical lab, instead are some suggestions to work with svn repos (the ones provided by gcode); like inferno-lab or the rest of Inferno related projects at gcode . NOTES To work with svn the easiest way is to install subversion under the host os and write a wrapper to have the svn command available under Inferno, like: cat > $home/dis/sh/svn << EOF #!/dis/sh load std wdir=`{hp `{pwd}} if {~ $emuhost Nt}{ os -d $wdir svn $* | tr -d ' ' }{ os -d $wdir svn $* } EOF The svn script relies in hp, to convert the Inferno paths to host paths, so here is hp: cat > $home/dis/sh/hp << EOF #!/dis/sh.dis # convert a inferno path to valid host path for os(1) load std if {no $*}{ echo 'usage: hp # to get host path' } if {~ $emuhost Nt}{ fn slashpath () { sed 's|\\|\\\\|g'; } # put two where there's one emuroot=`{echo $emuroot | slashpath | slashpath} for p in $* { cleanname -d `{pwd} $p | sed -n ' /^\/n\// {

lab 75 - scope & experiments

NAME lab75 - scope & experiments DESCRIPTION Since i did lab 67 i've been trying to improve/fix the t3 port and experiment with it. So this post has small report of the T3 port status, and some experiments under Inferno; note that they're not dependent of the handheld. T3 PORT Some of the thing i've fixed are: t3 touchscreen : Perform corrections to make it work as it should, this was important since it has direct impact on using Acme, and the rest of the system. blank the lcd : Added code to turn off the lcd while playing music, so battery lasts longer. To do so i added an blank command to the devapm.c written by Alexander Syschev, and wrote a blight script that manages the lcd backlight,to control this from acme. Since this changes apply to the t3 port, they can be found under lab 67 of the inferno-lab While i haven't been able to fix the following segfaults, i've been able to obtain dumps and open them with gdb. So i've been able to find

lab 74 - effective inferno

NAME lab 74 - effective inferno NOTES I read the Effective Java book recently. Every language needs a book that describes how to use it effectively. I wish there was a book for Effective Inferno. Although common techniques may work in Inferno I know for sure there are some uncommon ones that may work better. I'll try and describe at least one recipe that could be a chapter in that book. To people who've asked me what distinguishes Inferno, I've answered that it's the concurrent language Limbo, or that it's a portable OS that runs on a VM, or that it uses the Styx protocol to create a distributed system, or that it's about software tools that work together with the Inferno shell. These are the ingredients; on their own they are not unique to inferno. Limbo looks very like C and to a newbie it's not obvious what is special about it. There a lots of little niceties that make Limbo pleasant to use, e.g., array slicing and tuples, but these are det

lab 73 - MIDI

NAME lab 73 - MIDI NOTES I've written a module to read MIDI format files. I needed this because I wanted more input for my software synthesizer. I was getting bored listening to the same old track, and I haven't yet come up with any computer generated music. This seemed like a quick and easy option to get a large amount of music to listen to. The code reads in the whole MIDI file and stores it in memory, using an ADT for the Header that contains an array of Tracks and each Track has an array of Events. I also wrote a midi2skini command that interleaves the multiple MIDI tracks into a single stream of skini messages for the synthesizer (see earlier labs). It sorts and orders the events converting tick delta to realtime. I've been trying this out on some bach midi files . It's been working quite nicely with the organ like sounds produced by the inferno synth. % echo 1 > /dev/jit % midi2skini bwv988-aria.mid | sequencer ... You need JIT enabled when using the sequence

lab 72 - wikipedia

NAME lab 72 - wikipedia NOTES I've been working on modifying dict to use the Wikipedia database. I mentioned this in lab 70. So here's what I've got so far. It's not beautiful; the wiki syntax parser needs a lot of work The general idea is I want to use acme-sac as a Wikipedia browser. But there are other reasons too, such as gaining experience of using inferno to work on some large text databases. Acme brings some nice things to a database like Wikipedia. Because of the nature of acme you don't have to rely on people making wiki links to find other articles. You can right-select almost any text to search the index. Right-selecting single words often opens a Wikipedia disambiguation page. If you want to get this working try following the steps below. You need to use the latest acme-sac copy from svn. It has some fixes to support big files, including Acme.exe, otherwise none of this will work. Download the Wikipedia database . This site will explain about

lab 71 - pruning

NAME lab 71 - pruning NOTES I've tried to reduce acme-sac source tree to what I consider the core. I'm cutting out dead wood to encourage new growth. Except that what counts as dead wood is highly debatable. I removed files I tended not to use, but my well traveled paths through inferno are not necessarily going to match yours. So while acme-sac still stands alone, it depends on the larger world of inferno-os for diversity and range of applications. The smaller mass of code is intended to have less inertia. Not only can a programmer more easily understand it all, but he can also make changes system wide and so turn it to new directions. For example, if a new system library were to be imagined that could be applied to the whole limbo code set, the size of the code should not present so much resistance that an individual would not attempt it. This reduction effort started in lab 58. The source from that became acme-sac. The recent "right-sizing" removed a lot of

software temples

NAME software temples NOTES I've been listening to the seminars about long term thinking from the Long Now Foundation. I highly recommend them. The purpose of these seminars is to encourage long term thinking. They succeed at that. For the last few weeks as I've been listening to them I've been contemplating the future of software and the history of civilization. I can't say that I've ever been interested in history. But after attempting to look forward more than 100 years it only now occurs to me what a good idea it is to look backwards far enough to see the patterns and cycles in human history. Some of the seminars are inspiring. Danny Hillis talks about his progress in constructing a clock that will run for 10,000 years. At first it sounds insane, but after listening to him I can't help but admire him and what he's doing. The real purpose of such a scheme is to trick yourself into a different kind of thinking. Similar to the idea of forcing change

lab 70 - dict

NAME lab 70 - dict NOTES I ported Plan 9's dict to Inferno. At the moment it works with the Project Gutenberg dictionary and Roget's Thesaurus. Of course, since I'm an acme fan, I also ported adict to browse the dictionaries in acme. I've been looking to collect plain text databases that would fill a small portable 60GB drive. Then use acme as a plain text browser. When I've thought about Inferno as a system I've paid too much attention to the code and not to the data it might work on. Collecting databases is an attempt to broaden my view. Two databases to start with are Wikipedia (8GB uncompressed not including images) and the whole of Project Gutenberg (4GB compressed). I've started working on getting a local copy of wikipedia to display in acme using dict. I got this working for a small subset of wikipedia, the first 1GB, just to try things out. It works well enough that I'm now working on the complete archive.

lab 69 - menuhit

NAME lab 69 - menuhit NOTES After removing Tk I still needed some menu functionality. If you look carefully at the picture in my last post you'll see the little green menu! I ported menuhit from plan9 and made it a module in inferno. I've used it in a few wm commands checked into svn. Because I'm Tk-less I don't have the tk toolbar so menuhit, like rio, is the way of controlling window operations, basic stuff like exiting from clock. Why no Tk? I didn't do this because I hated Tk and the programming interface. But I didn't like the way it looked. I use acme-sac the whole time so I essentially stoped using an Tk based commands. Also, I thought there's no way I'd ever give an end-user an application that used Tk. So I removed it just to see what would happen next. The most immediate consequence is a lurch towards rio like interface. But I don't think that's the end state. I'm also looking at the browser as an end-user interface

lab 68 - stand alone charon

NAME lab 68 - stand alone charon NOTES I've definitely got behind in blogging my Inferno work. And it's not that I haven't been doing anything. I'm just not putting in the effort to write stuff up. Salva has been carrying the ball and thanks to him for the last few posts. I'm going to try posting more regularly but smaller things. A lot of my recent work has been going into acme-sac. I've checked code into svn at If my posts describe work I've checked in there I won't include the files as part of the blog. Today's post is a pretty picture. The story is I removed Tk from acme-sac and then worked through the consequences. One of them was to get charon working without Tk, which turned out to be not that hard. Whereas Acme is an interface for programmers, I think this is a great interface for end users.