Monday, November 28, 2005

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.

And so, because of command blocks and this simple represenation of expressions, any arbitrarily complex structure can be represented in sh syntax and a sh module that implemented the core set of Mathematica commands could be used to symbolically manipulate that data.

Another crucial idea of Mathematica is its peculiar "infinite evaluation" system; it keeps evaluating an expression until it no longer changes. I implemented IEval builtin which takes the output of a command and evaluates it again until the output is the same as the input.

% IEval {Point 1 2 3}
{Point 1 2 3}

But I stopped short of implementing the evaluation system described in the Mathematica docs. It was at this point that I realized what I was doing was just a pipeline from sh to sh, and that maybe the commands should read standard input for symbolic data. And then maybe they should be programmable using regular expressions and accept an arbitrary text stream instead of specifically structured text based on sh syntax. And at that point I'm back with the UNIX philosophy of software tools.

So I arrived at the point where even though symbol would fit within sh it might not fit within Inferno. From this exercise I think I have a better appreciation of the existing set of Inferno software tools. It is not always obvious how they are applied to a problem. But sometimes one needs to take a long trip around the computer science field before one can understand their generality, and that a command block is just quoted text; and quoted text is just a text stream.

FILES

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 widgets in the exact same configuration.

I've included attempts at a few others, such as scale, button, and canvas. Most of the functionality is in the tklib sh file.

This is a first cut. To show the 'self' idea translated in a way appropriate (maybe) to the file/shell/software tools experience. A different notation for the files might be more appropriate.

FILES

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

2005/1207

I updated vac and clumpchan fixing a couple small bugs in each. Clumpchan does work but only by reading one block at a time, which is not suitable for kfs. I think it would be well worth translating these scripts into limbo, but still keeping them non-server based, venti-lite, then a useful set of tools would come of it.

Wednesday, November 09, 2005

NAME

lab 45 - full screen

NOTES

I've been wanting to use inferno as a full-screen application on Nt. I don't know too much about the windows API but I took a peek at how Squeak does it. And that was enough to get it to work. This is a first pass at doing it. It should probably be done with parameters to emu. Ideally the inferno host window would be resizable with some way of switching to full screen and window while emu is running.

Just copy the win.c file to your /emu/Nt directory and build. The -g option to emu needs to be the current settings for your monitor.

The other files in this lab are the wmclient, tkclien,t and titlebar to make wm windows look more rio-like. I had done this in an earlier lab, but the wmclient code didn't work properly. The wmclient works properly now. But there's no backdrop menu for window control, which makes it a little difficult to hide and exit the windows.