February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Tudor Girba

Hi, I tried to load it but it does not work because PharoMorphicObject is missing. Could you add this code to some repository instead of sending it by mail? With this occasion you would make the license clear as well :) Cheers, Doru On 26 Feb 2012, at 17:08, S Krish wrote: > Hopefully this should be good to play on a Pharo 1.3 image. > > It does not work, as expected, in Pharo 1.4 image.. as > > MorphTreeColumn>> > rowMorphFor: aNode > > "the rowMorphGetSelector defaults to nil in Pharo 1.3.. !. but is a block Pharo 1.4.. can hack this to see the same effect.." > > I have a hacked.. version for Pharo 1.4 .. but let me figure out the wirings of MorphTreeColumn better to share it for 1.4 > > > On Sat, Feb 25, 2012 at 9:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > can you send the code that we play with it because I would like to learn how you do that. > > Stef > > On Feb 24, 2012, at 7:02 PM, S Krish wrote: > > > I love Pharo's ability to mould/ twist in spare time something that is > > imminently usable.. > > > > Just playing around over an hour plus, I find this tree view grouping > > more convinient than current browsers in giving a coherent view that > > easily extends: > > > > All editable code text morphs, spreading over to mutliple worlds one > > can traverse too if needed. or appears on tab anyways for each group. > > > > a) Package, Class, Category , Hierarchy levels. > > > > b) Senders, implementors .. > > > > c) Arbitrary groups of methods if one desires to.. > > > > Can also include some class definition info bubble/ reduce noise > > through some more optimization to make it optimized > > > > ... we can have a little customizations too to get a good grip of the > > whole as well as the part. > > > > But I agree, Gaucho / Code Bubbles are nice, but I am afraid fo > > fragmented view it will still represented. May be each will have > > little twist of his predilictions and cannot be highly generalized. > > > > > > On 2/24/12, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 24 February 2012 00:18, Matias Garcia Isaia <mgarciaisaia(a)gmail.com> > >> wrote: > >>> On Thu, Feb 23, 2012 at 5:08 PM, Mariano Martinez Peck > >>> <marianopeck(a)gmail.com> wrote: > >>>> Nooo!!! he comes from Java!! he starts with index 0. Kill him!!! ;) > >>> > >>> Ooops... Time to get a new identity :) > >>> > >>> > >>> On 23 February 2012 19:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >>> wrote: > >>>> Sure we know. > >>>> And we also know that it requires effort and lot of people are talking. > >>> > >>> I know there's a loooong way to see what CodeBubbles can do, and that > >>> requires to do a big effort, but imagined that some kind of > >>> alternative - I'm not sure that CB is **exactly** what I want (sure > >>> Java-ers want to see **something more** than just a file pimped with > >>> colours, but Smalltalk **allready has** much more than a text file - > >>> have real code) - could be very less effort-consuming. Making the > >>> current browser (Nautilus? - newbie here :) ) pop a new > >>> Â¿window?Â¿morph? showing a method instead of updating a single pane > >>> (the current one showing method's source) don't seems to be so "far" > >>> away to me. > >>> > >>> Of course that's my point of view, based on what I imagine that could > >>> be. I should spend some time to see how it is implemented, and to see > >>> if it really is that simple, but anyway trust you if you say is a huge > >>> effort... > >>> > >> > >> Well, popping out a new morph every time you clicking around is easy part. > >> The hard part is to make this stuff really consistent and easy to use > >> for navigation and development. > >> It requires far more serious work than just spending 2 hours > >> implementing "bubbling" behavior. > >> > >>> > >>> Cheers :) > >>> > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > >> > > <Pharo_CodeBrowser01.JPG> > > > > <PackageTree-Browser-Experiment-skrish.5.mcz> -- www.tudorgirba.com Innovation comes in least expected form. That is, if it is expected, it already happened.

Feb. 26, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by GÃ¶ran Krampe

Hi folks! On 02/26/2012 11:33 AM, Marcus Denker wrote: > > On Feb 26, 2012, at 11:24 AM, StÃ©phane Ducasse wrote: > >> Hi hannes >> >> I tried to understand the purpose of your emails but I could not. >> - So do you suggest that we all stop Smalltalk and move to javascript? >> - What is your motivation? >> - This is good for us to know that but then so what? >> - Does it help us anyhow to make pharo better? >> - Did you try to port the code to Squeak? >> - Do you know if the global handling of coordinates have been changed? >> We can spend our life looking why other people are doing or we can invent OUR future. Indeed - but one also needs to be "aware" of inspiration sources. Personally I am *not* interested in Morphic on js, other than a fun project. But it is still *interesting*. Does it help Pharo become better if we know stuff about the rest of the world? I hope so :) > For the "Lets all just do JavaScript". There was a very, uhm , disappointed blog post by > Gilad after they did the javascript implementation of NewSpeak... > > JavaScript is *not* a good implementation language for languages. Especially not if > you want to do something new. If you build on top of JS, you will be very very contraint > in what is possible... and the things *I* want to build in the future with Pharo > are just impossible to do on top of javascript. Definitely. If we take Amber for example, how is Amber interesting? To me it is about being able to build "HTML5 stuff" in Smalltalk but also "in a Smalltalk way" which means interactively in a Smalltalk "live" IDE. So is Amber the end-all-final-solution? Of course not! But it has its "niche" and coupled with Pharo on the server side etc, it gives us a new very interesting "Smalltalk all the way" application stack for the web. regards, GÃ¶ran PS. Inspiration is everywhere - for example, in Amber (just to pick a source of inspiration) the "senders of" and "implementors of" is the same button: "references", and it then shows both senders and implementors at the same time. Simple, trivial and quite nice.

Feb. 26, 2012

Re: [Pharo-project] eCompletion working in latest 1.4

by Tudor Girba

Thanks, Stef. I tested it in 14361, and it works well. Cheers, Doru On 26 Feb 2012, at 17:12, StÃ©phane Ducasse wrote: > Hi guys > > This version of ecompletion will work on pharo1.4 (i.e. enhanced shout packages) and new text editor (so cool). > > MCHttpRepository > location: 'http://ss3.gemstone.com/ss/NEC' > user: '' > password: '' > > Feedback is welcome of course. > > I'm currently renaming the classes to avoid clashes and I will clean it a bit and check OCompletion. > > Stef -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

Feb. 26, 2012

Re: [Pharo-project] selectionForDoitAsStream smells

by Nicolas Cellier

One of the area of high interaction is Parser>>correctSelector:wordIntervals:exprInterval:ifAbort: which has to then to deal with (self startIndex - 1) offset. It will have to be fixed too. Nicolas Le 26 fÃ©vrier 2012 21:54, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > > On Feb 26, 2012, at 9:41 PM, Nicolas Cellier wrote: > >> Compare this which is like old squeak selectionAsStream >> >> SmalltalkEditor>>selectionForDoitAsStream >> Â Â Â ^ ReadWriteStream >> Â Â Â Â Â Â Â on: self string >> Â Â Â Â Â Â Â from: self startIndex >> Â Â Â Â Â Â Â to: self stopIndex - 1 >> >> and this which has been changed conforming to Cuis >> >> TextEditor>>selectionAsStream >> Â Â Â "Answer a ReadStream on the text in the paragraph that is currently >> Â Â Â selected." >> >> Â Â Â ^ReadStream >> Â Â Â Â Â Â Â on: (self string copyFrom: self startIndex to: self stopIndex - 1) >> >> (or self selection asString readStream) >> The two differ. >> The former stream position starts at editor startIndex - 1, while the >> later stream position starts at 0. >> The stream position is used by the Compiler/Parser for notifying the >> SmalltalkEditor (or TextMorph) requestor. >> >> Now look at SmalltalkEditor>>notify: aString at: anInteger in: aStream >> Â Â Â "The compilation of text failed. The syntax error is noted as the argument, >> Â Â Â aString. Insert it in the text at starting character position anInteger." >> >> Â Â Â | pos | >> Â Â Â pos := self selectionInterval notEmpty >> Â Â Â Â Â Â Â ifTrue: [self startIndex + anInteger - 1 ] >> Â Â Â Â Â Â Â ifFalse: [anInteger]. >> Â Â Â self insertAndSelect: aString at: (pos max: 1) >> >> You see that it adds (startIndex - 1) to the error message insertion >> position which is a Cuis change. >> (The old ParagraphEditor did not). >> >> When #notify:at:in: is used for evaluating #selectionAsStream, all is >> OK, the (startIndex - 1) is added only once. >> But when it is used with #selectionForDoitAsStream, the offset is >> counted twice (because already in the stream location passed in >> anInteger parameter). >> >> I guess the hack #selectionForDoitAsStream that undo the Cuis clean-up >> has been added because some other part of Parser/Encoder/Compiler is >> messing with the requestor selection (like highlighting some part of >> the source for user interaction in case of ambiguity). >> Tthis is not a valid workaround. >> >> In Squeak, I did revert the Cuis clean-up just to keep some simple >> compatibility with ParagraphEditor, but Pharo does not care about >> that, so it should apply full simplification. >> I suggest removing #selectionForDoitAsStream, and replace senders with >> #selectionAsStream. >> Then if there are some other feature broken we'll fix'em. >> OK? > > Sure!!! > >> >> Nicolas >> > >

Feb. 26, 2012

Re: [Pharo-project] selectionForDoitAsStream smells

by StÃ©phane Ducasse

On Feb 26, 2012, at 9:41 PM, Nicolas Cellier wrote: > Compare this which is like old squeak selectionAsStream > > SmalltalkEditor>>selectionForDoitAsStream > ^ ReadWriteStream > on: self string > from: self startIndex > to: self stopIndex - 1 > > and this which has been changed conforming to Cuis > > TextEditor>>selectionAsStream > "Answer a ReadStream on the text in the paragraph that is currently > selected." > > ^ReadStream > on: (self string copyFrom: self startIndex to: self stopIndex - 1) > > (or self selection asString readStream) > The two differ. > The former stream position starts at editor startIndex - 1, while the > later stream position starts at 0. > The stream position is used by the Compiler/Parser for notifying the > SmalltalkEditor (or TextMorph) requestor. > > Now look at SmalltalkEditor>>notify: aString at: anInteger in: aStream > "The compilation of text failed. The syntax error is noted as the argument, > aString. Insert it in the text at starting character position anInteger." > > | pos | > pos := self selectionInterval notEmpty > ifTrue: [self startIndex + anInteger - 1 ] > ifFalse: [anInteger]. > self insertAndSelect: aString at: (pos max: 1) > > You see that it adds (startIndex - 1) to the error message insertion > position which is a Cuis change. > (The old ParagraphEditor did not). > > When #notify:at:in: is used for evaluating #selectionAsStream, all is > OK, the (startIndex - 1) is added only once. > But when it is used with #selectionForDoitAsStream, the offset is > counted twice (because already in the stream location passed in > anInteger parameter). > > I guess the hack #selectionForDoitAsStream that undo the Cuis clean-up > has been added because some other part of Parser/Encoder/Compiler is > messing with the requestor selection (like highlighting some part of > the source for user interaction in case of ambiguity). > Tthis is not a valid workaround. > > In Squeak, I did revert the Cuis clean-up just to keep some simple > compatibility with ParagraphEditor, but Pharo does not care about > that, so it should apply full simplification. > I suggest removing #selectionForDoitAsStream, and replace senders with > #selectionAsStream. > Then if there are some other feature broken we'll fix'em. > OK? Sure!!! > > Nicolas >

Feb. 26, 2012

[Pharo-project] selectionForDoitAsStream smells

by Nicolas Cellier

Compare this which is like old squeak selectionAsStream SmalltalkEditor>>selectionForDoitAsStream ^ ReadWriteStream on: self string from: self startIndex to: self stopIndex - 1 and this which has been changed conforming to Cuis TextEditor>>selectionAsStream "Answer a ReadStream on the text in the paragraph that is currently selected." ^ReadStream on: (self string copyFrom: self startIndex to: self stopIndex - 1) (or self selection asString readStream) The two differ. The former stream position starts at editor startIndex - 1, while the later stream position starts at 0. The stream position is used by the Compiler/Parser for notifying the SmalltalkEditor (or TextMorph) requestor. Now look at SmalltalkEditor>>notify: aString at: anInteger in: aStream "The compilation of text failed. The syntax error is noted as the argument, aString. Insert it in the text at starting character position anInteger." | pos | pos := self selectionInterval notEmpty ifTrue: [self startIndex + anInteger - 1 ] ifFalse: [anInteger]. self insertAndSelect: aString at: (pos max: 1) You see that it adds (startIndex - 1) to the error message insertion position which is a Cuis change. (The old ParagraphEditor did not). When #notify:at:in: is used for evaluating #selectionAsStream, all is OK, the (startIndex - 1) is added only once. But when it is used with #selectionForDoitAsStream, the offset is counted twice (because already in the stream location passed in anInteger parameter). I guess the hack #selectionForDoitAsStream that undo the Cuis clean-up has been added because some other part of Parser/Encoder/Compiler is messing with the requestor selection (like highlighting some part of the source for user interaction in case of ambiguity). Tthis is not a valid workaround. In Squeak, I did revert the Cuis clean-up just to keep some simple compatibility with ParagraphEditor, but Pharo does not care about that, so it should apply full simplification. I suggest removing #selectionForDoitAsStream, and replace senders with #selectionAsStream. Then if there are some other feature broken we'll fix'em. OK? Nicolas

Feb. 26, 2012

Re: [Pharo-project] [Pharo-users] Nautilus version 4.0.4

by Mariano Martinez Peck

> Ben, don't forget to cc pharo-users ;) > > > I do not get it :S > > When you do an ANN, do not only send it to pharo-project(a)lists.gforge.inria.fr but also to pharo-users(a)lists.gforge.inria.fr > > > Thanks again, > > Ben > > > Cheers > > > >> >> Gofer it >> url: 'http://ss3.gemstone.com/ss/Nautilus'; >> package: 'ConfigurationOfNautilus'; >> load. >> >> (Smalltalk at: #ConfigurationOfNautilus) loadRelease. >> >> >> >>> Thx, >>> >>> Sven >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Feb. 26, 2012

[Pharo-project] [update 1.4] #14362

by Marcus Denker

14362 ----- Issue 5402: AbstractTool fix http://code.google.com/p/pharo/issues/detail?id=5402 Issue 5403: remove some more references of #blockCopy: http://code.google.com/p/pharo/issues/detail?id=5403 -- Marcus Denker -- http://marcusdenker.de

Feb. 26, 2012

Re: [Pharo-project] So I broke 8k req/s today

by Sven Van Caekenberghe

On 25 Feb 2012, at 19:21, Philippe Marschall wrote: > On 25.02.2012 17:47, Sven Van Caekenberghe wrote: >> Philippe , >> >> That is incredibly fast, I just tried and I can't even get plain apache2 serve the static.html that fast over the local network ! > > It's not over the network, it's on the local machine. Keep-alive makes a big difference. Yes, I meant 127.0.0.1. And yes keep alive is necessary. >> When I have more time, I really have to try to repeat your results with your code ( as well as study the code ;-) >> >> Can you please provide the main pointers again ? > > - get the image from [1] > - in Apache 2.2 you set up AJP the way you set up an HTTP reverse proxy, the protocol is just ajp:// instead of http:// > - load Seaside-Benchmark from [2] > - see the class side of WASmallRequestHandler (2 byte response), WAFastRequestHandler (16k response, seaside.st homepage) and WADwBenchHandler (dw-bench) to register the request handlers > > [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/lastSuccessfulBuild/artif… > [2] http://www.squeaksource.com/Seaside31Addons OK, Thanks! Sven

Feb. 26, 2012

Re: [Pharo-project] Nautilus version 4.0.4

by Mariano Martinez Peck

On Sun, Feb 26, 2012 at 7:04 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Feb 26, 2012 at 6:57 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > >> Ben, >> >> On 26 Feb 2012, at 18:28, Benjamin wrote: >> >> > Hi guys, >> > >> > I really want to thank you all for your feedbacks which give me the >> will to always add cool features to Nautilus. >> > >> > Thanks to that, let me introduce the new stable version with some new >> features: >> > >> > - better groups (now the granularity is method and no longer class) >> > - better algorithm for coloring protocols and methods >> > - more menu entries and shortcuts >> > - Monticello integration >> > - OCompletion integration >> > - a lot of new icons :) >> > >> > (and some cleans in the code but ^^) >> > >> > >> > Thanks every one for your good energy :) >> > >> > >> > Ben >> >> Great! >> >> Can you put up a page somewhere describing the official way to get >> Nautilus with all its goodies loaded or how to update it correctly ? I know >> there is the CI image, but there seems to be some confusion around the >> ConfigurationOfNautilus. >> >> > I have a blog post in the owen...but just a little piece ;) > > As promise, here it is: http://marianopeck.wordpress.com/2012/02/26/nautilus-the-reborn-of-the-syst… Ben, don't forget to cc pharo-users ;) Cheers > > Gofer it > url: 'http://ss3.gemstone.com/ss/Nautilus'; > package: 'ConfigurationOfNautilus'; > load. > > (Smalltalk at: #ConfigurationOfNautilus) loadRelease. > > > >> Thx, >> >> Sven >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Feb. 26, 2012