inferno programmer's notebook

NAME lab 91 - using freetype NOTES While fiddling with Charon's fonts and wondering what work would be involved to replace the whole set I decided to take a quick look at the freetype module. This lab documents some of my progress. A recent post to the acme-sac mail-list pointed me to the DejaVu fonts . They are derived from Bitstream Vera Fonts but with more characters. It includes various styles: Sans, Serif, Italic, Oblique, Bold, and Mono, making it a good choice for Charon. At first I considered converting the whole set over to Inferno format. There is a program to convert TrueType fonts to the inferno format. But the program is designed to run on Plan 9 and I don't have a ready Plan 9 environment anymore. So the effort of setting up an environment, compiling and fixing problems I know exist in the conversion tool, creating font files for all the styles, and in a variety of sizes, and I was ready to look for an easier solution. The Freetype library is compiled i

NAME lab 89 - electroquongton NOTES The code for this lab was something I was playing with to display on a Nintendo DS. It uses the mux window manager and the prefab module builtin. Because of the dependency on the builtin, which isn't usually part of the inferno-os standard emu build, I've included a muxemu.exe for Windows in this labs code. To launch the code run the following, % muxemu -r . -g256x384 /dis/mux/mux.dis and on the screen you should see this, Move up and down using keys 'i' and 'm'. Enter a selection using the 'Enter' key and return to the main menu by pressing the spacebar. I'm not experienced with the draw(2) API so I started with screens for board games. I was experimenting using transparency effects. The look I was going for was Electroplankton for Nintendo DS. I tried to get shapes with edges that blended out into a graded background and some simple animations of shapes pulsing. The one serious application I w

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