December 2010 - Pharo-dev - lists.pharo.org

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

by Dale Henrichs

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(a)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 > >

Dec. 7, 2010

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

by Eliot Miranda

On Tue, Dec 7, 2010 at 11:59 AM, Lukas Renggli <renggli(a)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(a)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(a)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 > >

Dec. 7, 2010

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

by Lukas Renggli

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(a)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(a)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

Dec. 7, 2010

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

by Dale Henrichs

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

Dec. 7, 2010

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

by Eliot Miranda

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(a)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 > >

Dec. 7, 2010

Re: [Pharo-project] Issue 1809 in pharo: Nice to have : auto-format on save

by pharo＠googlecode.com

Updates: Status: closed Comment #6 on issue 1809 by stephane.ducasse: Nice to have : auto-format on save http://code.google.com/p/pharo/issues/detail?id=1809 (No comment was entered for this change.)

Dec. 7, 2010

Re: [Pharo-project] Popularity or not of smalltalk?

by James Ladd

Thank you all for the pointers. Luckily the IDE company has promised to write a plugin for Smalltalk this Janurary. For me, the initial plugin may not be what Smalltalkers like but over time I'm going to enhance it to give the same functionality as the current Code Browser. My goal is to bring more people to Smalltalk and if that means a few changes to what an 'old school' smalltalkers expect, then I am ok with that. Rgs, James.

Dec. 7, 2010

Re: [Pharo-project] Issue 1809 in pharo: Nice to have : auto-format on save

by pharo＠googlecode.com

Updates: Status: Fixed Comment #5 on issue 1809 by renggli: Nice to have : auto-format on save http://code.google.com/p/pharo/issues/detail?id=1809 This was implemented at ESUG 2010: Refactoring Engine -> Auto Format on Accept Note: There is also Refactoring Engine -> Auto Format on Display

Dec. 7, 2010

[Pharo-project] [ANN] 1.2 Dev Packages are loading :)

by Guillermo Polito

Ok, I've done some fixes to OB and OC, and committed them to PharoTaskForces as a temporary solution. To load current configuration: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. (ConfigurationOfPharo project version: '1.2-beta2') load. Can Hudson help us in building Dev images? Cheers PS: I've noticed a little bug in OB, I attach a screenshot. On Tue, Dec 7, 2010 at 3:36 AM, Alain Plantec <alain.plantec(a)free.fr> wrote: > Le 07/12/2010 07:04, Guillermo Polito a Ã©crit : > > Well I've gone very far by now :). >> >> I created a configuration that at least loads :P. >> >> There are two problems so far: >> >> 1) ECompletion + TextEditor. ECompletion sends #model to TextEditor and >> It does not understands it. It is easily fixed adding the accessor. >> 2) Opening an omnibrowser throws a MessageNotUnderstood: >> TextMorphForShoutEditor>>findText. Which I will have a look tomorrow. >> > > See issue 3288, there is a .cs for that I guess. > 3288 <http://code.google.com/p/pharo/issues/detail?id=3288> > > Cheers > Alain > > >> The version of ConfigurationOfPharo is 1.2-beta2 >> >> I've to sleep now :). >> Tomorrow I'll open an issue for 1) if everyone agrees. With whom should I >> talk to get 2) fixed? Lukas, Alain? >> >> Cheers! >> > > >

Dec. 7, 2010

Re: [Pharo-project] Dictionary responds to #add:, #addAll: but shouldNotImplement #remove: and #remove:ifAbsent

by Nicolas Cellier

I agree with Igor, best implementation of remove: is self error: 'Dictionary cannot #remove:, please use #removeKey:' Dictionary have two faces: - a bag of values indexed thru a set of keys - a set of associations (at least in st80 when association = was only testing the key) The second form is historical and IMO kind of private implementation details. Moreover, now that Association = is also based on values, the second form is not even more true. The strange thing is to define #add: in Dictionary. Normally we cannot add a value without a key index. Thus the right protocol for dictionary is #at:put: IMO, #add: intention was private, as Association should have been. But for conveniency we decided to let this #add: protocol survive. For remove:, you have two options: - provide any Object (Dictionary is a Bag of values) Then, remove is self associationsDo: [:e | e value = anObject ifTrue: [self removeKey: e key. ^anObject]]. ^absentBlock value. But then, you don't have symmetry with add: and remove:, so is it of any use ? - provide an association... But, then, what do you expect: Dictionary new add: #a -> 1; remove: #a -> 2 Nicolas 2010/12/7 Igor Stasenko <siguctua(a)gmail.com>: > On 7 December 2010 12:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> Hello, jaayer. >>>> >>>> The point about Dictionary inconsistency was raised multiple times before. >>>> I was among ones of those who did that couple of years ago. >>>> What can i say? >>>> While it is much better to have consistency, >>>> in fact it doesn't really changes much. I don't think that #remove: in >>>> a form you proposed will be any userful. >>>> I would really keep it simply #shouldNotImplement , because it is >>>> unclear what is a least surprising behavior of this method for >>>> Dictionary. >> >> Igor why? >> >> why remove: does not take the same argument than add: and does what it should? >> > > because with collection you can do: > > collection copy do: [:xx Â | collection remove: xx ]. > or > collection removeAll: (collection select: [:each | each isOdd ] ) > > but not with dictionary. > So i don't see much reason fixing #remove: because we never going to > fix #do: anyways, which makes > all beautiful manipulations with collections useless for dictionary. > > >>>> One might argue, that its more userful to make it same as #removeKey:, >>>> other one could point that its should be symmetrical to #add: , >>> >>> #add: is not part of the ANSI <abstractDictionary> protocol. It is, however, part of the ANSI <extensibleCollection> protocol: >>> add: >>> addAll: >>> remove: >>> remove:ifAbsent: >>> removeAll: >>> >>> One could make the argument that if Dictionary elects to implement part of it, it might as well implement the rest too. >>> >>>> but hey, then #do: should be also symmetrical to #add: , isnt? And so >>>> it should iterate over associations , not just values. So, it is a can >>>> of worms, once you open it , you can never finish the endless >>>> discussions :) >>>> It is just works in a way how we like (defined). It is like an >>>> imaginary numbers in math where sqrt(-1) == i and basta :) >>> >>> Right... I wasn't planning on going there, but are we basically stuck with #do:, #select: #collect:, #includes: and other such messages operating on the Dictionary's values rather than its associations, forever? >> >> I hope not. >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 7, 2010