Eliot,
To riff a little bit on the idea...the notion is to not export to the OS
but to model the OS from within Smalltalk...so we would write the unix
tools in Smalltalk ....
/vm might be a mount point for proc-style access to vm parameters
/Smalltalk might be a mount point for accessing structured/named objects
So the idea of stash is to pull the shell into Smalltalk and then
provide the types of tools you are talking about but all from within
Smalltalk ... staying completely within Smalltalk means that we don't
have to squeeze Smalltalk fit onto the disk, the nodes in the directory
structure would be objects, so they wouldn't be bounded by bytes...
using the "file system model" gives us a different model to use for
working with in-image artifacts that has it's advantages while also
providing a familiar model for folks that are new to Smalltalk...
Dale
On 12/07/2010 11:48 AM, Eliot Miranda wrote:
Dale,
I'm not sure if this is part of your idea, but would it be cool if
you could build this as a virtual file interface so that a Smalltalk
image could be mounted and searched using unix tools? Sort of like your
idea inside-out.
Eliot
On Tue, Dec 7, 2010 at 10:30 AM, Dale Henrichs <[email protected]
<mailto:[email protected]>> wrote:
I was thinking about a number of things in the shower this morning
and then it occurred to me that it would be interesting to create a
shell environment INSIDE a Smalltalk vm.
It wouldn't be a complete environment, but it would include a small
set of standard unix utilities:
- awk
- sed
- grep
the "directory structure" would be the package structure in the
image (or maybe multiple views on the image contents) with the basic
idea that you 'cd' into a class where there is a 'file' that
contains the class attributes. you then 'cd instance/all' and you
are in a "directory" of methods where you can 'vi at:put:' and have
a vi-like editor come up on the source of the at:put: method of
course awk, grep, and sed work on all of these 'source files'...
there would be 'executable files' that are simply workspaces ...
I know that folks have externalized files, but I don't know if
anyone has internalized the shell environment ...
The reason for internalizing the shell is that it becomes easy to
transition to the debugger and other traditional browsers/windows.
The big reason for internalizing the shell is to provide a unix-like
interface for Smalltalk that might make transition to the Smalltalk
tools easier for folks new to Smalltalk.
The secondary reason (and probably just as important) for
internalizing the shell, is that the hard-core Smalltalk developers
might actually find some utility in using the "smalltalk shell" in
the normal course of development and if hard-core developers use it,
it will be maintained and might lead to other interesting things...
The idea is that the entire "smalltalk shell" would be implemented
in Smalltalk so you could bring up browsers with a command ...
I've been thinking wistfully back to the days when I lived inside of
Emacs in the days before every terminal had a mouse ... back then I
put my hands on the keyboard at the start of the day and they stayed
there the entire day all window navigation was done via the keyboard
... I lost all of that once I started doing development in Smalltalk...
Anyway that about covers todays "ideas from the shower"...
Dale
