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 David T. Lewis

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] IRC monthly meeting + project description

by StÃ©phane Ducasse

yes join this is now starting. On Dec 7, 2010, at 7:20 PM, Guillermo Polito wrote: > This channel http://webchat.freenode.net/?channels=pharo-project? I have the afternoon free and I'd like to join :) > > On Tue, Dec 7, 2010 at 2:27 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Dec 7, 2010, at 2:43 PM, StÃ©phane Ducasse wrote: > > > Ok so at 20h00 we get our first IRC meeting. See U there. > > > > I have tickets for a concert tonight... lille orchestra playing la Symphonie fantastique > So I can not join. (or maybe afterwards) > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Dec. 7, 2010

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

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

Dec. 7, 2010

Re: [Pharo-project] Fwd: [Vm-dev] Image freeze because handleTimerEvent and Seaside process gone?!

by Eliot Miranda

On Tue, Dec 7, 2010 at 3:41 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > One change that I don't understand, although it probably is unrelated, is > in [2]: > > > > LargePositiveInteger removeSelector: #=! > > LargePositiveInteger removeSelector: #bitAnd:! > > LargePositiveInteger removeSelector: #bitOr:! > > LargePositiveInteger removeSelector: #bitShift:! > > LargePositiveInteger removeSelector: #bitXor:! > > LargePositiveInteger removeSelector: #'~='! > > > > Why would one want to remove these primitive calls from large integers? > > AFAIK, Cog needs those. > That's right. Those methods used SmallInteger primitives (7, 8, 14, 15, 16 & 17) and in Cog SmallInteger primitives only work on SmallIntegers, not on up to 64-bit LargeIntegers; i.e. they don't bother to test the receiver for being a SmallInteger and hence crash if installed on LargeInteger. I probably made a mistake in deciding to save a tag test, but I did. Instead these methods should use the relevant LargeInteger primitives. The issue is I think those are missing in the standard VM. See primitives 27 28 34 35 36 & 37 primitiveEqualLargeIntegers, primitiveNotEqualLargeIntegers, primitiveBitAndLargeIntegers, primitiveBitOrLargeIntegers, primitiveBitXorLargeIntegers, primitiveBitShiftLargeIntegers in the Cog VM and perhaps the standard VM. If they're missing in teh standard VM it should be fine to redefine those methods to include the 27 28 34 35 36 & 37 primitive numbers. If they're defined differently someone needs to check that using those numbers works in the standard VM. HTH Eliot > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Dec. 7, 2010

Re: [Pharo-project] Pharo integration in enterprise feedback

by GermÃ¡n Arduino

2010/12/7 Dale Henrichs <dhenrich(a)vmware.com>: > Okay ... I've got another little rant... > > Smalltalk improves developer productivity ... pure and simple ... the reason that developing in Smalltalk is fun is that there is very little that gets in between the developer and the solution of a problem ... the debugger, inspector and all of the tools mean that a developer can focus on the problem at hand ... the dynamic nature of Smalltalk means that I can add instance variables and change interfaces without having to fight the compiler or the tools ... or lose track of what I am doing .... > Full, full agree. This is the more important difference I think. > With that said (here comes the rant:) ... the _enterprise_ is not necessarily interested in developer productivity...productive developers is way down the list for the enterprise ... just look at the waste (not just in software) in a typical corporation ... (end of rant) ... > Again agree. A typical corp have lots of programmers, most of time without a real coordination and not really worried by productivity (even when they say the opposite). > Smaller companies (not at the enterprise level) _are_ interested in developer productivity, so that should be the sweet spot for Smalltalk and there is work to be done to make Smalltalk more attractive to those Smaller companies and it seems that Pharo is headed in the right direction to become more attractive ... Note that many development groups within the enterprise operate like smaller companies, it's just that a CTO of a Fortune 500 company isn't going to wholesale switch his company from using Java to using Smalltalk (at least not this year:)... > I talked about this thing on my talk in Smalltalks2010, commenting my own experience as an independent software producer and here, in this context, the productiviy is a key factor (At least 2-1 against any language I know, in my own experience). The other factor is related with the understanding of the systems, even the complex ones, were small companies as mine need to understand the whole system to be developed/sold to a customer Disclaimer to CÃ©sar: I know I'm not talking about Enterprise (Big companies) but still. > Oh and GemStone also has enterprise customers who don't necessarily advertise their Smalltalk success stories. > > Dale > > On Dec 6, 2010, at 11:00 PM, laurent laffont wrote: > > > I agree on the feeling, I only think we all miss a very important > tactical point here: in what realm is Smalltalk superior to other > technologies? > > > > Fun :) > > Laurent > > > > > > > The issue some cool and kicking creatures could have been done is not > enough, we need also to be certain we can get newcomers and have them > quickly up to speed in doing so. _That_ has lead other ('younger') > languages to their present status. > > -- > Cesar Rabak > > > > >

Dec. 7, 2010

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

by 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

Dec. 7, 2010

Re: [Pharo-project] IRC monthly meeting + project description

by Guillermo Polito

This channel http://webchat.freenode.net/?channels=pharo-project? I have the afternoon free and I'd like to join :) On Tue, Dec 7, 2010 at 2:27 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Dec 7, 2010, at 2:43 PM, StÃ©phane Ducasse wrote: > > > Ok so at 20h00 we get our first IRC meeting. See U there. > > > > I have tickets for a concert tonight... lille orchestra playing la > Symphonie fantastique > So I can not join. (or maybe afterwards) > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Dec. 7, 2010

Re: [Pharo-project] Bad characters in update package names

by Schwab,Wilhelm K

Gary, Seeing that code reminds me of something in my backup system. My move to Linux was not complete without it, and Pharo plus OS Process does the job fairly well. One quirk involves spaces and ()[] in file names; there are probably others I have yet to find. For the cp command, I look for these characters and wrap the file name in double quotes to allow the copy to work. Perhaps there is room for this in each of the file directory classes, and for an option to detect problems and not fix them. In my case, the file needs to be copied; I just need to do what one would do from a terminal to get it to work, and that will arise elsewhere. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2(a)btinternet.com] Sent: Tuesday, December 07, 2010 11:40 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Bad characters in update package names After a bit of digging the following was found: http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx Assuming we are not concerned with allowing ascii 0..31 in alternate data streams (an interesting concept I have used, though rather esoteric) then the following should do: DosFileDirectory>> checkName: aFileName fixErrors: fixing "Check if the file name contains any invalid characters" | fName badChars hasBadChars | fName := super checkName: aFileName fixErrors: fixing. badChars := (#( $: $< $> $| $/ $\ $? $* $"), ((0 to: 31) collect: [:n | n asCharacter])) asSet. hasBadChars := fName includesAnyOf: badChars. (hasBadChars and:[fixing not]) ifTrue:[^self error:'Invalid file name']. hasBadChars ifFalse:[^ fName]. ^ fName collect: [:char | (badChars includes: char) ifTrue:[$#] ifFalse:[char]] Regards, Gary

Dec. 7, 2010

Re: [Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

by pharo＠googlecode.com

Comment #1 on issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 Slice in the inbox: Name: SLICE-Issue-3385-TextEditor-doest-not-understand-model-GuillermoPolito.1 Author: GuillermoPolito Time: 7 December 2010, 3:01:23 pm UUID: c0ba6fe0-6c3a-e643-a568-76649f598ee9 Ancestors: Dependencies: System-Text-GuillermoPolito.116 Added accessor

Dec. 7, 2010

[Pharo-project] Issue 3385 in pharo: TextEditor doest not understand #model

by pharo＠googlecode.com

Status: Accepted Owner: guillermopolito New issue 3385 by guillermopolito: TextEditor doest not understand #model http://code.google.com/p/pharo/issues/detail?id=3385 The accessor should be added to load last version of OCompletion in Core 1.2

Dec. 7, 2010