'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
Locked
'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 |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 > |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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. |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 > > |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
On Tue, Dec 7, 2010 at 11:59 AM, Lukas Renggli <[hidden email]> wrote: See the FTP Server framework on SqueakSource: 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
|
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 > > |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
On Tue, Dec 7, 2010 at 12:09 PM, Michael Haupt <[hidden email]> wrote: Hi Eliot, What's needed to write the client in Smalltalk? best Eliot
|
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 |
Re: 'stash' a Smalltalk shell or what happens when you let your mind wander in the shower....
|
|
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 >> >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |