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

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

by StÃ©phane Ducasse

>> > > 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. this is why we will have fun when nicolas arrives to lille to work with us :) > > 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. Did you notice that in pharo Cmd + M also work on classes since long time ago and Cmd+ N also :) ? >

Feb. 27, 2012

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

by Philippe Marschall

On 02/25/2012 05:47 PM, 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 ! > > When I have more time, I really have to try to repeat your results with your code ( as well as study the code ;-) The biggest thing is probably the recycling of the response buffers. Each worker thread has a response buffer that is reused. I found that request handling is very sensitive to allocation. There is a direct correlation between removing allocation and handling more requests and having a bigger throughput. The more allocation you can remove the better. Especially things like Stream >> #contents. There is also some code to have buffers that can efficiently work on both ByteArray and ByteString. Cheers Philippe

Feb. 27, 2012

[Pharo-project] [update 1.4] #14363

by Marcus Denker

14363 ----- Issue 5405: Little Refactor in AbstractTool>>#RemoveClasses: http://code.google.com/p/pharo/issues/detail?id=5405 Issue 4549: Unable to open the Test Runner menu on OS X http://code.google.com/p/pharo/issues/detail?id=4549 Issue 5359: Class Search popup shortcut to open in a new browser http://code.google.com/p/pharo/issues/detail?id=5359 -- Marcus Denker -- http://marcusdenker.de

Feb. 27, 2012

[Pharo-project] Reddit entry for Spoon demo

by Lawson English

For those that missed it, Craig has a new voice-over presentation of Spoon. Please vote for the reddit entry: http://www.reddit.com/r/programming/comments/q7772/spoon_a_new_way_of_deali… L.

Feb. 27, 2012

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

by S Krish

http://www.squeaksource.com/PharoGoodies Name: PackageTree-Browser-Experiment-skrish.1 Pharo 1.3 compatible May require overriding/ hack MorphTreeColumn>>rowMorphFor: .. .. rowMorph := aNode rowMorphForColumn: self. ... to make it work for 1.4 till I figure out cleaner way. On Mon, Feb 27, 2012 at 3:58 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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. 27, 2012

Re: [Pharo-project] Emergency evaluator refresh problem

by Eliot Miranda

On Sat, Feb 25, 2012 at 6:44 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Feb 24, 2012, at 7:46 PM, Usman Bhatti wrote: > > > After exiting from emergency evaluator in pharo, pharo desktop/home is > not repainted/refreshed. Is it an issue or a feature? > > > > I think when the evaluator pops up people just don't care about details > like that anymore. > (I mean, something *horrible* whent wrong and everyone is happy to just ne > able to rescue the image... > refresh then is just not on your mind). > and might be a really bad idea given that the image is in a barely surviving state (at least its able to run the emergency evaluator). > > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > -- best, Eliot

Feb. 27, 2012

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

by Krishsmalltalk

Sure.... I will do that Sudhakar krishnamachari Extn 91-40403012 Cell 9902104814 On Feb 27, 2012, at 3:58 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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. 27, 2012

Re: [Pharo-project] fun with NBOpenGL

by chadwick

ok I get it now, it doesn't make sense, and the generated method names in NBOpenGL are more descriptive than both their C and OpenCroquet equivalents: color3f_red: green: blue: vs glColour3f(?,?,?) & glColor3f: with: with:) . It would be easy to write code to transcribe C example code into NBOpenGL Smalltalk anyway if anyone really needed to copy-paste example code. On Mon, Feb 27, 2012 at 1:46 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 February 2012 17:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> > >> > >> Also, I remember in OpenCroquet Squeak could parse positional arguments > of the form ogl glThis(x,y,x); glThat(x,y,z); -- doesn't it make sense to > bring this back, since most of the OpenGL code examples on the internet are > in this form ? > > > > I guess that you want to know since you ask: the answer is NO! > > It makes no sense to do that. > > When it was a time to decide what syntax to use we had a discussion > about it, and Croquet guys said, that they prefer normal keyword based > syntax, despite they > having this syntax extension for positional arguments. > NBOpenGL methods are generated from opengl specs. and its easy to > change the output of generator, > without doing monkey work of rewriting 2000+ methods. > So, if you can't live without it, you can create own bindings with any > other syntax you want by changing the > code generator: > > http://www.squeaksource.com/OpenGLSpecs > > > > >> On an unrelated note, I'm confused by this > ConfigurationOf/Gofer/Montecello system. How do people new to Pharo find > out what these URLs and special configuration loading code are ? > > > > Read the monticello and metacello chapters on pharo by example 2 > > > > and look at MetacelloRepository. > > > >> Seems like everyone is just copying and pasting code from forums into > workspaces. Couldn't these code fragments for loading configurations be > loaded automatically via a URL or something ? > > > > > > > > -- > Best regards, > Igor Stasenko. > >

Feb. 27, 2012

Re: [Pharo-project] selectionForDoitAsStream smells

by Nicolas Cellier

There is also http://code.google.com/p/pharo/issues/detail?id=5404 in the same corner. Give you a pleasure, remove these 5 lines of code! Le 27 fÃ©vrier 2012 00:58, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > http://code.google.com/p/pharo/issues/detail?id=5406 > > SmalltalkEditor>>notify:at:in: is wrong and has been reverted in Cuis too. > > I have a plan explained in above issue if we want to get rid of > ReadStream on:from:to: > > Nicolas > > Le 26 fÃ©vrier 2012 21:57, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >> 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. 27, 2012

Re: [Pharo-project] selectionForDoitAsStream smells

by Nicolas Cellier

http://code.google.com/p/pharo/issues/detail?id=5406 SmalltalkEditor>>notify:at:in: is wrong and has been reverted in Cuis too. I have a plan explained in above issue if we want to get rid of ReadStream on:from:to: Nicolas Le 26 fÃ©vrier 2012 21:57, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > 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