inferno programmer's notebook

NAME lab 105 - automount NOTES A small modification to mntgen yields an automounter which automatically mounts a server based on path name. This is a fairly crude proof of concept with hardwired port numbers and top-level mount path -- but it would be fairly easy to make it a bit more robust. Essentially, I just added a mount command to the code which dynamically adds the directory node to the mntgen tree on reference. Then I made the file system handling call its own thread so that the mount could reference the synthetic without locking up the original single threaded synthetic file server. One problem is that unknown servers take some time to respond with file note found, which is less than desirable. Fixing this and other annoyances is left as an exercise for the reader. EXAMPLE % ls /amnt % mount {automnt} /amnt % ls /amnt % ls /amnt/localhost/usr/inferno /amnt/localhost/usr/inferno/9cpu /amnt/localhost/usr/inferno/README /amnt/localhost/usr/inferno/charon /amnt/localhos...

NAME lab 104 - ducts: bi-directional mount channels NOTES Hi there, I want to talk to you about ducts. Are your ducts old fashion, out of date? In this lab, I'll walk through a little facility I built to allow me to have bi-directional mounts over a single file descriptor channel. The nature of the way I access my Blue Gene environment requires me to do an awful lot over a single communications channel. I wanted the ability to both access the target node's file system while simultaneously exporting mine, while only using a single file descriptor. To facilitate this, I wrote a little 9P-knowledgeable multiplexor which directs T-msgs to an export thread and R-msgs to a mount thread while multiplexing the responses from those threads back onto the same file descriptor. The initial implementation of the base mechanism was relatively simple until I had to start considering how to clean things up when I started unmounting directories on one side or both. The liberal use of sys-...

NAME lab 103 - python content assist NOTES Building on lab 102 I've started to write an acme client for python content-assist in python. I read the code for python's IDLE editor and pulled some pieces out of that to help with my implementation. The AutoComplete.py and CallTip.py modules are copied out of idlelib and reduced to just the functions I needed. Just as in lab 102 the acme client is implemented using pyxp to connect to the acme file system. In an acme editor window execute PyAssist. Start typing some python. After typing a dot the client will display available attributes for the module. Continue typing and it will reduce the list to those names with a matching prefix. Press the Tab key to complete a name or prefix depending on whether there is one or more names. After typing an open parenthesis the client will show the call tip for the function. The client implements an Import command so that more python modules can be added to the namespace. PyAssist ...

NAME lab 102 - python acme client NOTES A recent post to 9phackers announced Pyxp , another implementation of Styx in Python. I immediately downloaded Pyxp and tried it out. I had no trouble using it so I started thinking about python clients I could write. Python is still new to me so writing a styx client was an excuse to get more practice. I started with an acme client. I translated the acmewin limbo module I use for most acme-sac clients to python. Below is a simple example opening a new acme window and doing some operations on it. from acmewin import Acmewin win = Acmewin() win.writebody("hello, world!\n\n\n") win.tagwrite("Hello") win.writebody("goodbye") win.replace("/goodbye/", "GOODBYE") win.select(",") win.show() Remember to export the namespace before trying it out. % styxlisten -A 'tcp!*!localhost' export / % textclient.py I recently saw on Hacker News a repost of Peter Norvig's spelli...

NAME lab 101 - limbo B+ tree NOTES This lab is an implementation of a B+ tree. It is code from a much older lab that was overly complicated and buggy. I pulled the B+ tree code out, tried to fix the bugs and clean it up. The interface is roughly the same as dbm(2). Here is a synopsis. include "btree.m"; btreem := load Btreem Btreem->PATH; Datum, Btree: import Btreem; Btree: adt { create: fn(file: string, perm: int): ref Btree; open: fn(file: string, flags: int): ref Btree; fetch: fn(b: self ref Btree, key: Datum): Datum; delete: fn(b: self ref Btree, key: Datum): int; store: fn(b: self ref Btree, key: Datum, val: Datum):int; firstkey: fn(b: self ref Btree): Datum; nextkey: fn(b: self ref Btree, key: Datum): Datum; flush: fn(b: self ref Btree); close: fn(b: self ref Btree); }; init: fn(); Like Dbm the keys and values are stored as arrays of bytes, and being a B+tree the values are stored only in the leaf nodes. The maximum key and val size is 255 each...

NAME lab 100 - limbo tags NOTES I've been playing more with exuberant ctags . It's possible to make ctags recognize limbo source code using regular expressions to identify symbols we want tagged. Here's a command I defined called ltags . It will search for functions, assuming the function name is not preceded by spaces, and, more reliably, find adt and module definitions: #!/dis/sh os -t ( /n/D/ctags57/ctags.exe -n '--tag-relative=yes' '--langdef=limbo' '--langmap=limbo:.b.m' '--regex-limbo=/^([a-zA-Z][a-zA-Z0-9]+)\(.*\)/\1/m/' '--regex-limbo=/([a-zA-Z][a-zA-Z0-9]+) *: *adt */\1/t/' '--regex-limbo=/([a-zA-Z][a-zA-Z0-9]+) *: *module */\1/c/' $* ) Try running it under /, and use relative path names: % cd / % ltags -R appl module And open the acme client Ctag /tags I added a command "Tag" to the Ctag program that will find and print all matching symbols to the name given as argumen...

NAME lab 99 - catching up with inferno-os NOTES I had fallen way behind in keeping acme-sac code up to date with inferno-os. I tried to correct that this week by merging changes and adding files from inferno-os. I wrote a script, part of this labs files , to check the differences between inferno-os and acme-sac. I'm hoping by using this script I'll stay up to date with inferno-os as changes are made. The script compares sub-trees, such as the limbo source code hierarchy, the C source code, the manual pages, and the /lib directory. It prints out commands to diff the files or copy the file over. % inf inferno synchronization: appl show changed limbo files sys show changed C source files man show changed man pages lib show changed /lib files cmd show changed sh scripts below /dis update refresh file tree info for local and remote adiff adiff selected file with inferno-os equivalent diff diff selected file with inferno-os equiv...

NAME lab 98 - acme Ctag NOTES Ctag is a new client for acme that reads the tags file generated by ctags. In particular I worked with Exuberant Ctags on windows. While working on acme content-assist in lab 94 I thought a next possible step was using ctags for code completion. So in writing this program I wanted to explore using exuberant ctags by doing something easier, that is by providing assistance with code navigation. Exuberant ctags understands many languages, but for the current effort I tried it on Java and Python. For example, I generated tags for the python standard libraries, cd:/Python30 ctags -R --excmd=number --exclude=test Then run the client on the tags file, Ctag /n/D/Python30/tags What you start with is a blank window. In the tagline is a File command. Give it an argument of a filename which it will grep for in the ctags file. File mailbox It will then show all classes and methods within matching files. You can right-click on a method name to open ...

NAME lab 97 - acme Navigator NOTES I created a simple directory browser for acme. Called Navigator, it opens directories in the same window. This makes descending deep but unfamiliar directory hierarchies easier because it avoids the proliferation of windows that clutter the desktop. The client understands the command Pin for creating a standard acme directory window for the current directory (to pin the current directory to the desktop). This is an example for a rather simple client for acme. FILES inferno-lab/97

NAME lab 96 - acme color schemes NOTES The inferno version of acme always contained some code to configure the acme color scheme, but I'm not sure if it always, if ever worked. I modified the code a little in acme-sac to make the color configuration work. And I came up with a few new schemes. The schemes are checked into acme-sac under /acme/color . To use a different scheme add a line like this to your $home/lib/profile run /acme/color/evening Running the "evening" scheme will make acme look like this. The configuration files sets a few environment variables of the following form: acme-fg-text-0='#000000' This sets the foreground text color in the body text to black. It's possible to mix two colors, as for the standard acme background. acme-bg-text-0='#FFFFAA/#FFFFFF' Another simple scheme is "bw" for black and white. There is also a file /acme/color/standard for the default acme color scheme which can be copied tweaked...

NAME lab 95 - acme side-by-side diff NOTES Here's a script I wrote to help do side-by-side diffs in Acme. Run adiff as normal inside acme. And then in the adiff output window type the command NextDiff. Executing this command will step through each diff in the adiff output and highlight the changed region in each file. The script will highlight each line, avoiding the cursor jump to highlighted regions as happens by plumbing or right-clicking on a file pattern. Though the cursor jump will occur the first time the diffed files are opened, for subsequent execution of NextDiff for diffs within the same files the cursor will remain over the NextDiff command and the highlighted regions will change with file scrolling to show at least part of the changed regions. When the files first open you'll still need to manually arrange the files side by side. There is no acme API for window placement. However, the command will save some amount of scrolling, clicking, and mouse moveme...

NAME lab 94 - acme content assist NOTES This lab explores a way of implementing content assist for acme. I've focused on the user interface and how that might work inside acme and not specific language support. The command is called Assist. Launch it within an editor window and it will provide assistance for that window only. A new window will open and while you type in the edit window Assist will attempt to match the currently typed word against the content of /lib/words using the command look(1). The results are displayed in the +Assist window. With results in the +Assist window and with focus still in the editor window type Ctrl-l to step down through the results. Each result will be selected in turn and the selection will wrap around to the top. To choose a selection and replace the currently edited word with the selected text type Ctrl-k. The Assist command also supports file completions. Start typing a path in the edit window and type Ctrl-y to show file completions i...

NAME Google Summer of Code 2009 NOTES Plan 9 has been accepted this year as a mentoring organization for Google Summer of Code . The Plan 9 group accepts projects to do with the operating system Plan 9 from Bell Labs and from related technologies such as Inferno, Plan 9 from User Space, v9fs, 9vx, and Glendix. If you're a student and you like any of these technologies you should apply immediately to the GSoC with your a project proposal. You can take any of the ideas you've seen explored in this blog and build on them, or develop your own ideas and take Plan 9/Inferno into new territory. I would love to see projects that extend Acme-SAC such as with content-assist or syntax highlighting. Or new Inferno applications in particular for the Nintendo DS. Inferno is an "integrating environment" so try integrating Inferno with Eclipse, Python, or Ruby. The deadline for student project proposals is April 3rd, so you need to be quick. There is so much cool stuff you cou...

NAME lab 92 - vxinferno NOTES In this lab I create a new Inferno builtin module that calls the vx32 library and get a minimal system working that runs native x86 code, with system calls redirected to inferno's system calls and therefore making the inferno namespace visible to the sandboxed code. Vx32 is a new user-level sandboxing library by Bryan Ford and Russ Cox. From the vx32 paper , "Vx32 is a multipurpose user-level sandbox that enables any application to load and safely execute one or more guest plug-ins, confining each guest to a system call API controlled by the host application and to a restricted memory region within the host’s address space." Inferno, being a virtual operating system, provides its own system call API to limbo applications. The same system calls are available as a C API for use by native libraries that appear as builtin modules or devices within the inferno environment. This C API is a natural fit for building a Vx32 sandbox allo...