'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Dale Henrichs
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

Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Adrian Lienhard
I like it :)

Adrian

On Dec 7, 2010, at 19:30 , Dale Henrichs 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
>


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

David T. Lewis
In reply to this post by Dale Henrichs
You mean like this?

  http://wiki.squeak.org/squeak/1914
  http://www.squeaksource.com/CommandShell/

Load OSProcess, then load CommandShell, then load CommandShellPharo.

World menu -> open... -> Command shell

On Tue, Dec 07, 2010 at 10:30:30AM -0800, Dale Henrichs 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

There are a few "commands" such as help, edit, fc, and inspect that are
implemented in Smalltalk. The general approach is to first try evaluating
an expression as a doIt, then check if it's a "command" written in
Smalltalk, else assume it's an external command, so expand the path
do globbing, and run the resulting command and arguments under OSProcess.
The doIt's, Smalltalk commands, and external programs can all be
pipelined as with a unix shell, so you can for example run "ls | edit"
to pipe the output of /bin/ls into the Smalltalk "edit" command in the
image.

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

Yes, that's how it works.

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

I'm pretty sure that's how I came up with the idea too ;-)

Dave


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Eliot Miranda-2
In reply to this post by Dale Henrichs
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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Dale Henrichs
In reply to this post by David T. Lewis
Dave,

Not quite ... I assume that the framework could be used for stash, but
the big difference in my mind is that for stash there would be _no
attempt_ to connect to the underlying OS ... so no OSProcess would be
desired...eveything in the stash shell would be a simulation of the Unix
environment

The basic idea of stash is to model the Smalltalk class environment as
one or more directory structures and to actually implement
vi/awk/sed/grep/etc. in smalltalk to operate on those directory
structures thereby providing a familiar environment for newbies to ease
their way into Smalltalk rather than having to take a full plunge ...

This isn't to say that Command Shell isn't neat for what it does:)

Dale


On 12/07/2010 11:24 AM, David T. Lewis wrote:

> You mean like this?
>
>    http://wiki.squeak.org/squeak/1914
>    http://www.squeaksource.com/CommandShell/
>
> Load OSProcess, then load CommandShell, then load CommandShellPharo.
>
> World menu ->  open... ->  Command shell
>
> On Tue, Dec 07, 2010 at 10:30:30AM -0800, Dale Henrichs 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
>
> There are a few "commands" such as help, edit, fc, and inspect that are
> implemented in Smalltalk. The general approach is to first try evaluating
> an expression as a doIt, then check if it's a "command" written in
> Smalltalk, else assume it's an external command, so expand the path
> do globbing, and run the resulting command and arguments under OSProcess.
> The doIt's, Smalltalk commands, and external programs can all be
> pipelined as with a unix shell, so you can for example run "ls | edit"
> to pipe the output of /bin/ls into the Smalltalk "edit" command in the
> image.
>
>>
>> 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 ...
>
> Yes, that's how it works.
>
>>
>> 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
>
> I'm pretty sure that's how I came up with the idea too ;-)
>
> Dave
>
>


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Lukas Renggli
In reply to this post by Eliot Miranda-2
See the FTP Server framework on SqueakSource:

     http://www.squeaksource.com/FTPServer

If I remember correctly it includes a server example that provides
access to classes and methods; and that can be mounted into the
filesystem.

Lukas

On 7 December 2010 20:48, Eliot Miranda <[hidden email]> 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 <[hidden email]> 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
>>
>
>



--
Lukas Renggli
www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Eliot Miranda-2


On Tue, Dec 7, 2010 at 11:59 AM, Lukas Renggli <[hidden email]> wrote:
See the FTP Server framework on SqueakSource:

    http://www.squeaksource.com/FTPServer

If I remember correctly it includes a server example that provides
access to classes and methods; and that can be mounted into the
filesystem.

Cool!  Another reason why packages on SqueakSource *really* *badly* need overview comments.  The project names don't tell you at all what these things do.  Most frustrating. 

Eliot


Lukas

On 7 December 2010 20:48, Eliot Miranda <[hidden email]> 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 <[hidden email]> 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
>>
>
>



--
Lukas Renggli
www.lukas-renggli.ch


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Dale Henrichs
In reply to this post by Eliot Miranda-2
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 <[hidden email]
> <mailto:[hidden email]>> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Michael Haupt-3
In reply to this post by Eliot Miranda-2
Hi Eliot,

On 7 December 2010 20:48, Eliot Miranda <[hidden email]> wrote:
>     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.

there is a SqueakFS project on SqueakSource. Probably what you mean. ;-)

It uses userfs on Mac OS X to "mount" a Squeak image and make the
classes etc. available as directories and files. It's read-only. The
client is written in Python.

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Eliot Miranda-2


On Tue, Dec 7, 2010 at 12:09 PM, Michael Haupt <[hidden email]> wrote:
Hi Eliot,

On 7 December 2010 20:48, Eliot Miranda <[hidden email]> wrote:
>     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.

there is a SqueakFS project on SqueakSource. Probably what you mean. ;-)

It uses userfs on Mac OS X to "mount" a Squeak image and make the
classes etc. available as directories and files. It's read-only. The
client is written in Python.

What's needed to write the client in Smalltalk?

best
Eliot
 

Best,

Michael


Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Michael Haupt-3
Hi Eliot,

On 7 December 2010 21:23, Eliot Miranda <[hidden email]> wrote:
> What's needed to write the client in Smalltalk?

hmmm ... I would have to look up the FUSE (not userfs as stated
earlier, sorry) documentation again to be absolutely sure, but it
seems Alien *might* suffice.

Squeak would have to register itself with libfuse and listen on a
socket for OS requests to the "file system" it hosts. For details, see
http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/, and especially (about
the innards) http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/callbacks.html

Best,

Michael

Reply | Threaded
Open this post in threaded view
|

Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....

Dale Henrichs
In reply to this post by Dale Henrichs
Another example of what I'm thinking about:

   cd /Monticello/SqueakSource/MetacelloRepository
   cd ConfigurationOfMetacello-DaleHenrichs.489
   vi version10:

or

   cd /Monticello/GemSource/MetacelloRepository
   grep ConfigurationOfOB *.*

shell-style manipulation of artifacts that will never be exported to the
OS file system...

Dale

On 12/07/2010 12:08 PM, Dale Henrichs wrote:

> 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<[hidden email]
>> <mailto:[hidden email]>>  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
>>
>>
>
>