inferno programmer's notebook

NAME lab 64 - Chat NOTES Chat is an acme client that connects to the chatsrv filesystem. This is a very basic text chat service. It is considerably simpler than the Irc client. Part of the reason I did this was to have a simpler client I could use to help debug some of the acme interaction, and help me improve Irc. Another reason was a recent urge I had to setup some private communication channels, merely for privacy's sake. Chatsrv is part of the demo code under /appl/demo . I borrowed code from /appl/demo/chat.b and the Irc client I ported from Russ. A chatsrv service is running on tcp!canto.hopto.org!6683. But I've only allowed rc4_256 encryption to use the service, and of course you need a certificate from the canto.hopto.org signer ( Getting Started ). To mount the service within acme and start Chat Local mount -C rc4_256 tcp!canto.hopto.org!6683 /n/chat Chat /n/chat Note that the simplest client can be run inside wm/sh, or win: % {cat & cat >[1=0]...

NAME lab 63 - Calendar NOTES I wrote a little calendar client for acme based on Inferno's wm/calendar(1). It uses rawdbfs(1) in the same way to store calendar entries. The calendar window displays a month much like cal(1), and has commands Next and Prev to move between months. Days that have calendar entries have a plus superscript symbol. Right click on the days of the month to open and edit a calendar entry. To use it make sure you have a directory /mnt/schedule, and a file in your home directory called, schedule. mkdir /mnt/schedule touch schedule Calendar schedule Or Local rawdbfs schedule /mnt/schedule Calendar FILES caerwyn.com/lab/63

NAME general update NOTES I've been quiet for a while so I'll give a general update to things I've been working on. I've been doing little bits on lots of different things, but no substantial progress on any one thing. Basically nothing to merit a release of working code. I'll just itemize the stuff. The Slashdot of acme:sac made me want to improve a lot of things. Ems setup a project on sourceforge to host the distribution when I get it completed. There were several things I want to include in the next release, such as acme debug client, an acme web client, and an acme factotum client. I fixed the bug, at least running on my version of XP compile emu, that caused emu to crash. Basically XP didn't like the trap handling code that used inline asm. I removed the inline asm and registered a general trap handler, and that seemed to work fine. I did some more testing on the acme debugger client. In doing so, I think I found another way of crashing acme, so tha...

NAME lab 62 - software synth CSP style NOTES This is the next iteration of my software synth code for Inferno. Of particular note is the embrace of CSP style as implementation technique. This was true of the code in lab 60. But this time much more of it actually works and the basic framework, the interfaces, are in place for me to extend it further. I think it makes a nice show case of CSP style programming. I thought my lexis database did too (lab 34) but this code is probably easier and more fun to play with. I want to post this now before I move onto the next phase, which may add a lot more complexity but won't illustrate any better the CSP style of programming in this application. You are encouraged to edit this code to create your own synthesizer, and use that as a way into studying CSP style. This synth comes with a basic GUI. Here is a screen shot. The GUI is bare bones, designed just so that it very easy to add new knobs for the control of filters. (One of the thin...

NAME lab 61 javascript tool NOTES In this lab I wanted to get a standalone javascript interpreter for general scripting use within inferno. [Deleted a section on reasons why I'd want to do this based on the mix of languages already available--it's not that interesting and is just me trying to rationalize why I like javascript] There is already a javascript interpreter in inferno as part of the charon web browser. All I'd need to do is add a small set of host objects to interface with the OS. In this lab I haven't included all the host objects I'd want; not even a fraction. This is just the setup, the beginnings of a javascript tool. The only host object I've added is System which contains three functions: getline , print , and readFile . Getline reads a line from stdin and returns it as a string. Print writes a string to stdout. ReadFile reads the in the contents of a file and returns it as a string. Suggestions on what the host objects to add are we...

NAME lab 60 - sequencer using channels NOTES In the comments to lab 53 Rog suggested using channels to parse buffers between processes in place of the one-sample-at-a-time technique I was using in my earlier DSP attempts. This lab is an attempt at Rog's suggestion. It's one limbo file that acts as a simple sequencer and generates it's own voices. Each instrument should have an interface: f: fn(c: chan of (array of real, chan of array of real), ctl: chan of (int, real)); This function is spawned and control messages are sent on the ctl channel, and the request for samples and the response channel are sent down c . It really requires jit to be turned on to sound acceptable. Here's a sample setup, % bind -a '#A' /dev % echo 1 > /dev/jit % sequencer4 /dev/audio Uncomment sequencer.b4:60 to add a little echo to the music. I think I'm getting closer to Rog's ideas, but I'm not sure I'm still exploiting it to the fu...

NAME lab 59 - acme stand alone complex NOTES A project that's been on my mind for quite a while is to package Inferno's acme as a stand alone editor. I only had Windows in mind as a target host, but the work should be quite easy to reproduce on other hosts. I wanted the editor to blend well with the host system, and work as a substitute for other popular programmer editors such as vim, emacs, or jedit. Acme and Inferno being already stable and mature, there were only a few things I felt needed to be in place for this to work. cut & paste between the host and acme (lab 55) acme to resize with the host window dead simple packaging and install of acme on windows. This lab covers the code to do the acme resize with host windows. I copied the code from /emu/port/devpointer.c and made devwmsz.c . The code is almost identical except for the name changes. This device holds a short queue of window resize events and serves a file /dev/wmsize that's the same fo...

NAME lab 58 - dried dung NOTES "Even as the clock ticks, better and better computer support for the creative spirit is evolving." - Dan Ingalls. How does computer support evolve and interact with the creative spirit? Doug Englebart tackled a related question, "How can a computer support a problem solver's intellect?" Englebart's solution was a form of recursion called Bootstrapping. Build tools to help build better tools. The better tools would augment the programmers abilities to help them on their way to bootstrap the next system. A significant aspect of the bootstrapping philosophy was that the researchers used the tools they build. The Smalltalk researchers took those ideas to heart. The Design Principles of Smalltalk followed this evolution cycle explicitly: Build an application program within the current system (make an observation) Based on that experience, redesign the language (formulate a theory) Build a new system based on the new design (m...

NAME lab 57 - createuser NOTES I've tried setting up some services for the Inferno community. See Getting Started on the Inferno wiki for how to create a user id. There is a public signer, registry, and kfs. If you mount the registry you might find a couple more. Use the certificates for your services too. You can create an id, get a certificate and announce some of your own services using the registry then anyone else using the same signer should be able to mount your service. Acme makes a remarkable collaborative environment. With wiki and irc clients and the shared kfs, a common naming convention for mounted services, it's a wonderful thing to type paths or commands using one or these channels and have others read and execute the commands. I hope these servcies and the Acme environment mean people interested in inferno and connect in new ways. Most of the services are commands that come with the standard Inferno. What I had to create for this experiment is the create...

NAME lab 56 - acme web NOTES I started using charon again because I wanted a web browser that started faster and used less memory than firefox. I wanted the browser to check my gmail account and scan reddit etc. But after implementing cut & paste (lab 55) I found it frustrating all over again to not be able to cut & paste from charon. So I started looking for a solution to that. I began by just dumping the text to stdout. Since I was always starting charon from inside acme the stdout would go to an acme window. Then I thought I might as well write directly to a new acme window, so I built an acme client to charon. Then I added the links handling, which was pretty easy, and tada! a charon hack turns into an acme web browser. And a surprisingly good one too, since charon is doing all the work. The links appear in acme as superscript numbers to the anchor text. Right-click on the number or word to follow the link. Only one link can be handled at a time. You can minimize cha...

NAME lab 55 - cut & paste NOTES this work includes some enhancements for running inferno hosted on windows. these are small details, but do seem to make a difference. first is cut & paste between host and inferno. I copied the code from drawterm to do this. the file /dev/snarf contains the windows clipboard. typically one would say bind /dev/snarf /chan/snarf and everything works just great. second is window resizing. in this case the host window is resized but the inferno windows all stay the same. but this still improves it. it's nice to be able to resize the window. however, for this to work the toolbar needs to be moved to the top instead of the bottom of the screen. finally, i added /dev/fullscreen . writing anything to the file cases inferno to toggle fullscreen mode. to use the changes copy devarch.c and win.c to /emu/Nt , and devcons.c to /emu/port . FILES caerwyn.com/lab/55

NAME lab 54 - mux for 4th Edition NOTES Noah Evans is working on the GBA port. Inferno running on GBA and DS would be cool to see. It's exciting to think about the possibilities of running inferno on small mobile devices, especially if networking is included because that would draw on the strengths of inferno. Inferno has already been ported to at least one PDA: the ipaq. But as far as I know there are no applications designed for use on a mobile device. Running acme or wm/sh on such a thing isn't worth making the port for. A GUI dedicated to the architecture has to be developed. Let's use DS as an example, but also imagine mobile phones/PDAs, where we assume Inferno networking is available to the application developer. What applications are useful to run on the DS? (games count as useful) What's the GUI going to look like? The device's constraints make an interesting challenge. Given a 240x160 resolution and cursor keys and A/B/L/R keys a new GUI and styl...

NAME lab 53 - granulator NOTES I want to revisit the DSP code I worked on in earlier labs (3, 4, 5, 6, 7, 10, 12, and 13). The STK C++ library it's based upon has been updated since then. The latest versions include an implementation of a granulator, which is something I've wanted to do for a while. Granulation samples the music at tiny intervals then plays the grains back as many overlapping voices. With granulation the music speed can be dramatically slowed down but still retain its pitch. A good example of this is 9 beet stretch a granulation of Beethoven's 9th symphony played over 24 hours. I often listen to it at work. It blocks out surrounding chit-chat, and it isn't as distracting to me as most music. I can't listen to pop or classical music because I get tired of the repetition or else the music might interrupt my train of thought. With granulated music I can setup a playlist of three hours of barely interesting noise and get into "the zone...

NAME lab 52 - text files NOTES Some limbo programs can be replaced with shell one liners, and others can be replaced with more general programs that reduce the limbo line count but increase functionality. I'll look at the few I've discovered. The /prog filesystem exposes a textual interface that allows existing software tools to work with it. This implies I do not need a custom set of limbo tools to read and write to this filesystem. For example, ps is a 61 line limbo program, but I can do the same thing in one line of shell, fn ps {sed '' /prog/*/status |sort -n} This is the great power of Inferno. Simple textual interfaces exposed as files and a small set of software tools working together. Therefore, I can also try rewriting kill and broke . In this case I make the functionality more like Plan 9. Each command writes to output the commands that can be sent back to the shell to actually perform the kill action. fn kill { sed -n '/' ^ $1 ^ '/s/^ +...

NAME lab 51 - plumbing from firefox NOTES I often want to copy and paste text from the firefox browser into my Acme session. Copy and paste isn't implemented for hosted Inferno. It could be implemented easily enough, but not in a general way for all hosted environments, and there might be more interesting ideas to explore especially when including plumber in the mix. To solve my particular problem, getting text from the browser to Acme, I created a bookmarklet that opens a window on a URL that I serve from my Inferno session. The URL http://localhost/magic/plumb is a shell script that calls the plumb command to open the query string in Acme. plumb -d edit -a action showdata -a filename /httpd/plumb $"msg >[2=1] I have a modified httpd that calls shell scripts and sets environment variables to the cgi data from the query string. In this case msg is a query parameter. I install a plumb bookmarket (drag it to toolbar), then I can select text in Firefox, click on t...

NAME lab 50 - structural expressions NOTES Sometimes I write some code but I'll let it sit for ages because I can't do the lab write-up for it. I think it's probably better to just throw it out there and get on with the next thing. This is one of those labs. Maybe I'll come back and edit it more if I end up using the tool. I've been reading again Rob Pike's Structural Regular Expressions paper. It suggests variations on existing tools (sort, grep, diff and awk) where applying structural expressions might make the tools more versatile or change their character entirely. Inferno is missing awk and though it can be run externally I still feel such a tool ought to exist within Inferno. Text manipulation, software tools, filters, regular expressions, pattern-action languages: these make up the core of what I think Inferno should be about. If there's a specific user I have in mind for Inferno it's me, and my main use for it is as a programming environmen...

NAME lab 49 - wrappers NOTES Acme is the hub of my activity where all my tools are at hand. It is inconvenient to have to step outside it while working on a task. But it is impractical to port all the tools I need into Inferno. However, Inferno is an integrating environment. It is oftentimes easy to put a wrapper around an external tool so that it is usable within Acme. In this lab I show a few examples of putting wrappers around external tools so that they blend in to the Inferno environment and work together with Inferno's tools. The first, very simple example is awk . fn awk {os awk $*} With this definition it is only possible to use awk as a filter without naming files as command line arguments. But this is often good enough. Very often I work on my laptop which has NT as the host os. But I need to use dict and spell all the time, and my laptop doesn't have these installed. I integrate these tools into my environment by running emu on a Plan9 or Linux machine a...

NAME lab 48 - symbol NOTES I'm clearing out the backlog and found this lab's code, which is really a continuation of earlier labs on the lispy-shell (26, 27, 28). I felt that where I was going with lab 28 wasn't working out, or was just going to end up looking like scsh (if I was lucky, and as smart as Olin Shivers). This attempt is more a mathematica-like-shell, and for a while was looking better, in that it fit in better with the existing sh, but now I've decided against it too. I'm posting it here just to record what I've done. I'll try and explain at the end why I don't like this approach anymore. In Mathematica everthing is an expression of the form f[x,y] which translates quite easily into the shell expression f x y Because of Inferno sh's command blocks, we can directly support the nesting in expressions: % Head {f x y} f % Head {f;x;y} List # a sequence of commands {f;x;y} is # represented as {List f x y} in "FullForm" And...

NAME lab 47 - self tk NOTES I was inspired by watching a video about Sun's Self system, which also inspired Squeak's morphic user interface. The scripts in this lab were an attempt to get tk windows serving a file that described themselves, so that the file could be copied to disk, and later run to recreate the window. Here's an example. % ./text /chan/tk.239 % cp /chan/tk.239 t1 % run t1 You should now have two text windows open. Edit either one of them, then copy and run them again. Both the contents and the position of each window should be saved and restored. Right-clicking in the window brings up the titlebar, whichs pops up underneath the window because it is the last thing packed into the tk widget. Right-clicking again makes it disappear. One of the ideas being explored is that a set of widgets can be configured and placed on the screen then all the /chan/tk.* files copied to a directory that acts as a stored workspace, to be later restored with all the widg...

NAME lab 46 - vac script NOTES This lab is an answer to Jack's question in the comments of lab 41. The putclump/getclump scripts can be made to work with blocks of data. The shell script for this lab, vac , will write a kfs file system to a venti-lite archive in blocks, taking advantage of block level redundancy. This is demonstration rather that something truly useful. It literally takes hours to store a 64MB kfs file system in venti-lite using this script. Note also, that it is trivial to implement putclump/getclump using the venti(2) module in inferno and store the blocks in a real venti archive. And this script will work the same way. I've also included a vcat script to readout the kfs filesystem in one go. I started writing a file2chan interface so I could run disk/kfs directly against the venti-lite archive, but didn't finish it. I've attached that too (clumpchan). Exercise for the reader is to finish it. FILES caerwyn.com/lab/46 2005/1207 I updated vac ...