On Tue, Dec 7, 2010 at 11:59 AM, Lukas Renggli <[email protected]> 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 <[email protected]> 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]> > 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 > >
