Showing posts from February, 2006

lab 57 - createuser

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

lab 56 - acme web

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

lab 55 - cut & paste

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

lab 54 - mux for 4th Edition

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

lab 53 - granulator

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&quo

lab 52 - text files

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/^ +