inferno programmer's notebook

NAME lab 90 - Multicast DNS and Zeroconf (client portion) NOTES While using synthetic file systems to publish services works great, you still need to know where your server is. This information can be provided from a shared ndb/local or even DHCP, but there are plenty of scenarios I have run into where I don't control the DHCP server and distributing ndb/local is tedious. In working with Blue Gene the problem becomes a bit worse in that we don't know apriori which portion of the machine (and therefore which IP address) we will get. Further complicating this is the fact that our front-end node (where we run Inferno) is established by a load balancer, and there are potentially 5 of us running our own file servers. So not only do we need to know how to get to the front end node, but how to get to the right front-end node. While some form of simple broadcast service discovery may have been sufficient, I decided to take the time to see what it would take to add multicast DNS an...

NAME lab 88 - degrees of freedom NOTES The Vitanuova downloads page has historical snapshots of Inferno source from 1996 to 2003 containing all three editions before Inferno went open source. I was curious to see how well Inferno has sustained a standard set of interfaces over the last ten years so I downloaded all of them and poked around. The biggest overall change came with 4th edition, when many parts of the system were upgraded, including the Styx protocol, several builtin modules, dis format, the limbo language and VM. Also, significantly, Inferno adopted open source licenses granting developers the freedom to modify any part of the system: something that might impact sustainability for good or ill. While every edition prior to 4th has had some interfaces changed, these changes did not break backwards compatibility. A 3rd edition emu can run dis code from the 1st edition archive. The difference between 3rd and 4th was large enough that limbo code needed to be ported,...

NAME lab 87 - mux for nintendo ds NOTES In an earlier post I talked about updating mux to 4th edition Inferno in the hope of one day running it on a Nintendo DS. Well, Inferno is now booting on the DS so I got to try it for real. I started with getting the mux window manager working in standard inferno. Then I changed the resolution down to 256x192 and tried to get everything to fit. The files in this lab include the version of mux I ended up putting in the nds file running on the DS. Things to try if you download it. Rocker moves up and down selection. 'A' key enters, 'B' key backs out back up to the higher level. 'Start' key returns to the top level menu. Try Today's Newspaper, and The Thisburgh has the only working graphic. Under news, click through to actually read an article. Under games, try connect4. Audio control would look cool if any of the graphics actually came in. The Financial Reports gives a ticker. It scrolls slowly only becau...

NAME lab 86 - srv NOTES This from a post on 9fans , and also on Tip O' the Day % dc >[0=1] | echo 0 > /srv/desk Plan 9's srv(3) acts as a bulletin board for open file descriptors, other namespaces see all the files in srv, and so can read and write to /srv/desk. Inferno has srv(3) which is a file2chan registry, but is also visible to all namespaces on the host. (see also srv9(3) ) The current implementation of sh-file2chan(1) does not allow the above. The closest I got was, % load file2chan % calc >[0=1] | {file2chan /chan/desk {rblock; putrdata &} {fetchwdata > /fd/0}} & % stream -b 1 /chan/desk % echo 1+1 > /chan/desk I tried implementing a command equivalent to srv(4) on Plan 9. It takes a command block or network address and post it in the srv registry. % srv {calc >[1=0]} /chan/desk It using an existing '#s' instance if there is one, else binds a new one. Now we can open a console to /chan/desk from another window % ...

NAME lab 85 - stowage NOTES In an earlier post I defined a venti-lite based on two shell scripts, getclump and putclump, that stored files in a content addressed repository, which in that instance was just an append-only gzip tar archive with an index. After learning a little about the git SCM , this lab re-writes those scripts to use a repository layout more like git's. The key thing to know about the git repository is that it uses sha1sum(1) content addressing and that it stores the objects as regular files in a filesystem using the hash as the directory and filename, objects/hh/hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh In the objects directory is 256 directories named for every 2 character prefix of the sha1hash of the object. The filename is the remaining 38 characters of the hash. Putclump calculates the hash, slices it to make the prefix and filename, tests if the file already exists, and if not writes the compressed data to the new file. Here is the important part...

NAME lab 84 - gridfs pattern (mapreduce) NOTES I've mentioned mapreduce in previous posts . It makes a good example application for thinking about grid computing. This lab is also about mapreduce although the point here is to illustrate an inferno pattern for grid computing. I'll call it here the gridfs pattern. Say you have a grid of compute nodes and you want to distribute and coordinate work among them. For the gridfs pattern you construct a synthetic file system that will get exported to all the nodes. The file system is the master process and all clients to the file system are workers. Both cpu(1) and rcmd(1) use the rstyxd(8) protocol that exports the local namespace when running remote jobs. To implement the gridfs pattern we bind our master fs into our local namespace so it gets exported when we run multiple workers across our compute grid. A very simple example of this pattern is explained in the Simple Grid Tutorial Part 2 . I export a named pipe with a pro...

NAME lab 83 - lcmd local cpu NOTES While thinking of the Simple Grid Tutorial Part 1 and Part 2 , I wondered whether I could implement the equivalent of rcmd(1) but for a local emu launched using os(1). For example, lcmd math/linbench 100 would launch a new emu, export the local fs to it through a pipe rather than a network socket, and run the command in that namespace. The idea seemed simple, no apparent obstacles, but it actually took me a couple of evenings to get it to work. So I'm posting it more because of the effort rather than its value. First lets look at what rcmd does, ignoring the networking. Given its arguments it builds a string, calculates its length + 1, and writes the length then the string to a file descriptor, then exports the local namespace to the same file descriptor. Well that part is easy to do in sh(1). Here it is as a braced block assuming all work is done on file descriptor 1. fn lcmd { load expr string args := $* s := sh -c ${quote $...

NAME lab 82, again - txt2iaf NOTES After thinking the matter a little, I finally wrote the txt2iaf app. This allows to use any text file, with one or two columns of data, to be converted to an iaf file that can be played using auplay(1). Now, my sound analysis goes something like this: 1. Record something using a microphone. For now, I only record stuff using some app in Windows (Sound Recorder) or Linux (arecord(1)). This is because Inferno has some issues when trying to record something from /dev/audio: an annoying tick every so often that wrecks my sound analysis intentions. Maybe, I can help to fix this problem, probably related with buffering. 2. Convert the wav file obtained to an iaf file, using wav2iaf(1). 3. Get the data from the iaf file to a text format, using iaf2txt(?). 4. Read data from the text file using any data analysis package. 5. Do whatever you want to with the data. 6. If you wish or need to, output the data in a text file. 7. Using txt2iaf(?), create an iaf file...

NAME lab 82 - iaf2txt and iaf2wav NOTES Currently, a couple of my friends and I are playing a little with human voices. For this purpose I wrote two applications to convert iaf files to plain text and to the wav audio format. Both apps support the standard iaf files as described in audio(6), except for the encoding: only PCM is supported for now. Why in the world would one need a text file converted from an iaf? Well... text files are easier to handle with data analysis software like the R programming language. I know MATLAB supports working with wav files directly, but there are mainly two reasons I needed an iaf to txt converter: 1. I do no use MATLAB. 2. When I wrote the iaf2txt app there was not an iaf to wav converter. Maybe R can handle wav files directly, but I do not know. I am not really sure if I need a text to iaf converter, but I am thinking about this issue. So far I do not need one. FILES lab 82 code

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...

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 /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-B91A93F3BDDD" codebase="http://ww...

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 ...

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

NAME bazaar development mode NOTES I've created a new group for Acme:SAC development. http://groups.google.com/group/acme-sac acme-sac@googlegroups.com 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.

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] http://cm.bell-labs.com/cm/cs/tpop [2] synth from acme-sac under appl/synth FILES inferno-lab bachm.mp3 (the original bach file bach.mp3 )

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 The svn script relies in hp, to convert the Inferno paths to host paths, so here is hp: cat > $home/dis/sh/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\// {s|/n/(.)/|\1:\\\\|p; q;} s|^|'^$emuroot^'|p;' } }{ # host letters subst # hls="{ns | sed -n '/#U.+/ s|^bind -. ''#U(.*)'' (.*)|s\|\2\|\1/\|p|p'} for p in $* { cleanname -d `{pwd} $p | sed -n ' /^\/n\// {s|/n/l...

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 ...

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...