[Pharo-project] 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
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
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
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
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
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 <dhenrich@vmware.com> 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
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 <eliot.miranda@gmail.com> 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 <dhenrich@vmware.com> 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
On Tue, Dec 7, 2010 at 11:59 AM, Lukas Renggli <renggli@gmail.com> 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 <eliot.miranda@gmail.com> 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 <dhenrich@vmware.com> 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
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 <dhenrich@vmware.com <mailto:dhenrich@vmware.com>> 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
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<dhenrich@vmware.com <mailto:dhenrich@vmware.com>> 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
Hi Eliot, On 7 December 2010 20:48, Eliot Miranda <eliot.miranda@gmail.com> 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
On Tue, Dec 7, 2010 at 12:09 PM, Michael Haupt <mhaupt@gmail.com> wrote:
Hi Eliot,
On 7 December 2010 20:48, Eliot Miranda <eliot.miranda@gmail.com> 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
Hi Eliot, On 7 December 2010 21:23, Eliot Miranda <eliot.miranda@gmail.com> 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
participants (6)
-
Adrian Lienhard -
Dale Henrichs -
David T. Lewis -
Eliot Miranda -
Lukas Renggli -
Michael Haupt