inferno programmer's notebook

NAME Inferno emu on Palm Tungsten T3 (and under similar palm handhelds, see notes). DESCRIPTION This lab collects some personal/informal notes that I took while setting up setup Inferno emu running hosted on a T3, the main reasons for doing this are: Wanted to experiment with Inferno Get tired of the 'traditional' way of using a computer and by extension a handheld (both POS and Linux), and wanting to employ my time in more useful things. after some time using Inferno i've noticed that it has all I need, and the pieces that Inferno doesn't have (ogg, mp3, etc.) can be borrowed from the host OS (Linux). The first section covers the hardware available on the T3, the second section talks about how to setup Linux on the T3, and finishes talking about the setup of Inferno itself to perform some typical tasks, which includes brief notes on how to compile and run emu on T3. Ha...

NAME lab 66 - useful tools NOTES This is a light lab about writting some useful day-to-day tools, mainly language and music playing tools. gask is a simple script for doing searches with google, which is nice when you want to consult something while writting a text, it returns the output in textual form so it can be used/plumbed etc. the next tools are for rapidly looking definitions in english/spanish/... on a dictionary, and they're handy when you aren't a native speaker. trgg (translate google) allows you to translate between any pair of languages that are supported by google, the usage of the command is trgg 'sl|dl' text, or |trgg 'sl|dl' where: sl: is the source language (by default english) dl: is the destination language (by default spanish) while dorg does a search on the dictionaries using the services of www.dict.org site, dra...

NAME lab 65 - Man pages in Acme NOTES This lab's purpose is to have man-pages opened in acme automatically. Easiest way to do this is to allow plumb to get it's data piped from another program. So we can do: man2txt /man/sec/file | plumb -i -d edit -a action showdata -a filename '/man/file(sec)'; given that we want to plumb it to acme we have to set the destination port -d edit, and instruct acme to show the data with the tag set to the value of the filename argument. So now we can add to our plumbing rules something like: # man pages kind is text data matches '([a-zA-Z0-9\-]+)\(([0-9]+)\)' plumb alwaysstart man # nasty plumbing hack plumb start /dis/sh.dis -c '/usr/salva/dis/man -b $2 $1' where /usr/salva/dis/man is an adaptation of /rc/bin/man from Plan9, and in particular when invoked with the -b option does: man2txt $file | plumb -i -d edit -a action showdata -a filename '/man/'^${tl $*}^'('^${hd $*}^')' But if w...

NAME google hosting NOTES I've created a project on http://code.google.com to host the code for acme-sac. This the first time I've used svn for a project. But I like it so far. It's nice of google to do this. I like not having to worry about maintaining the source repository. I've uploaded most of the acme-sac distribution. Probably too much; I might be deleting portions of it, such as /appl/wm/*. I'm kinda torn about what to include and what to remove. I'll lean to removing too much to start, and add back it only the things that I find using. I've moved the code for emu to /sys. The mkfiles now assume the build is within Inferno using wrappers 9l, 9c, 9ar to the host system. I've only tried this and got it working on Nt. When I eventually get a Linux machine to do builds on I'll get it working on that too. But if anyone wants to help...

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