inferno programmer's notebook

NAME lab 15 - cluster file DESCRIPTION I'm still curious about layering of filesystems. Ds (3) was an example I looked at before writing signalfs. Another example was cryptfs (lab 2). Ds currently resides in /os/port/devds.c. A while ago I moved it into /emu/port/devds.c but hadn't made any use of it. I have wanted to use it for a rudimentary cluster file system, so I ported ds to limbo to play with distributed files and further explore files that are built from layering of other file systems. I translated the C code and used styxservers to manage the simple, one level namespace. Here's some testing. This is really as much as I've tested it so far. % for (i in `{seq 0 9}) {zeros -v $i 1024 8 > /tmp/chunk ^$i} % echo cat c1 /tmp/chunk2 /tmp/chunk3 >ds/ctl % echo cat c0 /tmp/chunk0 /tmp/chunk1 >ds/ctl % echo mirror m0 ds/c0 ds/c1 > ds/ctl % cat ds/ctl cat c1 /tmp/chunk2 /tmp/c

NAME lab 14 - map reduce functional grid programming DESCRIPTION I read about Google's MapReduce from Rob Pike's interview at slashdot. At the same time I've been studying Inferno's alphabet-grid (1) and am wondering if I can implement map reduce using alphabet. Here's an imaginary example % - {rng , | remote | mapreduce "{tq -1rm /n/tick/tick.bt} "{tock } | /create /tmp/result } Suppose that tick.bt is a log of time spent on tasks where each record is the timestamp, task and number of seconds spent on the task that instance. Rng produces 1 or more date ranges. Remote converts type /fd to an endpoint. Mapreduce will then split a date range, such as one year, into M smaller date ranges. For each subrange it calls rexec passing it the address of an available node, the subrange and map function as parameters.

NAME lab 13 - implement the flute instrument from STK. DESCRIPTION I implemented more of the STK library but his time as a straight forward translation to a limbo module. Much of the protected classes and filters are in dsp.b as ADTs. They all share a similar interface that includes functions mk for building the object and tick for processing the next sample. The instruments are generally larger to implement but follow the same interface. They can be plugged into a signal module and then read and controlled from within signalfs. I've included a few simple modules that can be used to start a new instrument. I also tried to implement the more complicated Flute. It's close, but still doesn't sound right. It all needs a lot more debugging. To test the flute, % signalfs -a /mnt/dsp % echo add flute.dis flute > /mnt/dsp/ctl % sequencer /mnt/dsp/flute < bach.ski > /dev/aud

No code to post tonight because it's unfinished. I'm converting all of STK to limbo, but not directly into signalfs. I'm creating a module that will contain all the sound sources, filters, and effects in the STK, with one ADT for each sound. This can then be used by signalfs to serve a file, which can be a combination of any of the ADTs, or by any other limbo app. Rog has suggested an alternative application using the shell alphabet. I will try this once the library is written. Rog pointed out how inefficient signalfs is in its current form. I agree; the performance is terrible, which makes it compleletly unusable for realtime sound support. This re-implementation will improve performance. But any hardcore DSP programmer is only likely to snicker at our attempt to implement DSP in limbo. At the end of the day I'm doing this to create a framework for ease of experimenting with DSP, not to create a sound system that will out perform all others. That is the tradeoff

NAME lab 12 - implement an oscilloscope for signals from signalfs. DESCRIPTION I implemented an oscilloscope called scope to view the signals produced by signalfs, or other PCM data such as an iaf file stripped of it's header. % scope < bach.raw > /dev/null It writes it's input to it's output, but it doesn't sound very good if directed to /dev/audio . It writes small blocks of samples with small delays between writes, making it sound very choppy. Scope tries to draw 25 frames a second, getting a tick from a timer, and reads 1/25th of a second of samples from the input, then draws it on a Tk panel. This is might be useful when recording input from a microphone % scope < /dev/audio > out.raw It takes as parameter the sample rate and number of channels, stereo or mono. CONCLUSION Not being able to listen and see the waveform at the same time mak

I spent the time this evening downloading the Microsoft C/C++ toolkit and the SDK. I have only built emu for linux and plan9 so far. So it's time to start building an XP version. I also expect to be modifying the audio driver to add some more advanced features, such as 8 channels. While waiting for the downloads I found this site about audio networking interesting. A DTMF decoder would be a nice lab to do some night. I tried compiling the inferno distribution for XP. I'm missing LIB.exe. I used link /lib instead. Got most of it compiled, including emu.

NAME lab 10 - delay line DESCRIPTION I am continuing to add signal modules to signalfs copying the implementations from stk. Today I'm working on the delay line, and whatever else I can implement in two hours. The delay line does not fit the model of signals I have created so far. From the STK it looks like it is used more as a utilitly class than a standalone filter. Its used by the echo class which actually does the mix of the current input with the delayed input. I could of course do the same thing and have delay as functions with the dsp module. Trying to use the delay, or echo, brings up a number of issues. How am I going to stack multiple filters ontop one another and still be able to ctrl each one independently? To access to each ctl file I'd need to know the conversation number. This might be tricky to find out if I have multiple instruments each being built from man

NAME lab 9 - create tmap image directly instead of using Tk DESCRIPTION I modified tmap to use draw-image (2) because using tk (2) commands to create so many rectangles was slow and used a lot of main memory. The changes were straight forward. The Tk cmd TkCmd(t, sprint(".fc.c create rectangle %.1f %.1f %.1f %.1f " + " -fill #%s -outline black -width %.2f", r.x, r.y, r.x+r.w, r.y+r.h, dc[depth], 0.5)); becomes rect := Rect((int r.x, int r.y), (int(r.x+r.w), int(r.y+r.h))); img.draw(rect, t.display.color(dc[depth]), nil, (0,0)); img.border(rect, 1, t.display.black, (0,0)); where img is the global Image destination. I then update the image on the canvas tk->putimage(t, "tmap", img, nil); tk->cmd(t, ".fc.c coords tmap 0 0; update"); tmap is the name of the image previously created with image (9) and associated with canvas (9). CONCLUSION It works much faster

NAME Music band spree client and engine DESCRIPTION I have been reading through spree code and wondering what engines I could write to learn more about this type of filesystem. Here is one idea that incorporates signalfs . The aim is to create a distributed electronic music band. Each player is a client to spree and can create instrument objects and play notes on these instruments. The other players will have the instruments and sounds replicated locally by their spree client; and similarly instruments and notes they play are heard by the other musicians. Each spree client runs a separate signalfs but with a common set of signal modules. The spree action commands will be SKINI with extra commands for creating and configuring the instruments. The spree engine manages the shared configuration of instruments. Note events are broadcast to all players. The spree client is therefore a ty

Here is a new tmap.b with the memory leak removed. I just needed to call Tk cmd delete all on the canvas to remove all the old rectangles. And finally a screenshot of tmap using output from du -a / on the root of the Inferno distribution. You can see a file and it's path highlighted in red. I've played about with the coloring a bit, but haven't found anything I really liked. The current scheme is for colors to represent depth. It goes from dark blue to light blue, through greens and yellows and ends on red for the deepest nodes.