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

[Pharo-project] How to change keyboard bindings
by Bart Veenstra Oct. 18, 2010

Oct. 18, 2010

HI list, Using VW and VAST a lot, I got used to the key bindings. For instance, I would like to use control-q for bringing up the inspector instead of alt-i. Could someone point me in the right direction where I can change the bindings? Also, It is often unclear when I should use Control or Alt. For instance: In the System Browser, I can use Alt-X to remove a method, and Control-B to browse the class, but both are shown between the parenthesis. Regards, Bart

1 0

[Pharo-project] Implementing a Timer: "newProcessWith: anArray" fails
by nullPointer Oct. 18, 2010

Oct. 18, 2010

Hi I do implementing a easy Timer class. The purpose of timer is launch events for UI thread and the process thread too when a interval of time is elapsed. My problem is throwned when I call the message #newProcessWith: from BlockClosure. I pass an array with a parameter, the instance of CLTimer class, which is used in the Closure process for launc the events. A error of not is valid the number of arguments is launched: 'This block accepts 1 argument, but was called with 0 arguments.' I donÂ´t understand very good the problem. I have pass an array with one element, and the Closure receives one parameter too... Basically the code: pvtGetNewProcessBlock ^[:timer || intervalDelay | [timer enabled] whileTrue:[ (Delay forMilliseconds: timer interval) wait. timer enabled ifTrue:[ timer raiseOnElapsedTimeForProcessThread: (timer getProcess). WorldState addDeferredUIMessage:[ timer raiseOnElapsedTimeForUIThread: (timer getProcess) ]. ] ]. ]. pvtStartProcess | processBlock | processBlock := self pvtGetNewProcessBlock. internalProcess := processBlock newProcessWith:{self}. internalProcess resume. PD. Exists some complete doc with the way for work with threads in Pharo/Squeak? I did see time ago a doc of Smalltalk processes, in french language, but I donÂ´t see in Google :( http://forum.world.st/file/n2999831/CLTimer.st CLTimer.st -- View this message in context: http://forum.world.st/Implementing-a-Timer-newProcessWith-anArray-fails-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 6

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2
by StÃ©phane Ducasse Oct. 18, 2010

Oct. 18, 2010

On Oct 17, 2010, at 1:00 PM, Mariano Martinez Peck wrote: > > > On Sun, Oct 17, 2010 at 10:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I have a question: > does shout support closing parenthesis behavior? > > > > I wonder the same. I don't see the difference between this and shout smart characters. so may be we could remove this and keep smart characters. Now that there is a setting we could try and see. > > > Stef > > On Oct 16, 2010, at 10:27 PM, Pavel Krivanek wrote: > > > Can we add a setting for it? (issue > > http://code.google.com/p/pharo/issues/detail?id=3113) > > > > Cheers, > > -- Pavel > > > > On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> thanks! > >> > >> > >> On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: > >> > >>> Hi , it was a enhancement i did starting from a Chris Muller enhancement for Squeak. > >>> > >>> ISSUE 2653. > >>> http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… > >>> > >>> I did a test, maybe a good start would be to see if its failing now. > >>> > >>> Fernando > >>> > >>> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > >>> > >>>> Hi Folks, > >>>> > >>>> Cuis doesn't include #autoEnclose, so I don't know how it should behave. > >>>> > >>>> Cheers, > >>>> Juan Vuletich > >>>> > >>>> Mariano Martinez Peck wrote: > >>>>> Guille, if I remember correctly (not sure), these new classes like > >>>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i > >>>>> think he is in the mailing list but not read it so frequently. So, for > >>>>> this issues maybe you can cc'ed him. > >>>>> > >>>>> Cheers > >>>>> > >>>>> Mariano > >>>>> > >>>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com > >>>>> <mailto:guillermopolito@gmail.com>> > >>>>> > >>>>> Here is the piece of code that's behaving weird > >>>>> > >>>>> TextEditor>>dispatchOn: > >>>>> > >>>>> ... > >>>>> ... > >>>>> char := aKeyboardEvent keyCharacter. > >>>>> openers := '([{'. > >>>>> closers := ')]}'. > >>>>> ( closers includes: char) ifTrue: [ self blinkPrevParen: > >>>>> char ]. > >>>>> result := self normalCharacter: aKeyboardEvent. > >>>>> (self class autoEnclose and: [ openers includes: char ]) > >>>>> not ifTrue: [ ^ result ]. > >>>>> suffix := closers at: (openers indexOf: char). > >>>>> paragraph text append: suffix asString. > >>>>> self moveCursor: [ : position | position ] forward: true > >>>>> specialBlock: [ : pos | "no special behavior" ] event: > >>>>> aKeyboardEvent . > >>>>> self userHasEdited. > >>>>> > >>>>> ------------------------------------- > >>>>> > >>>>> So, if I evaluate "TextEditor autoEnclose: false", it is stops > >>>>> behaving like that :) > >>>>> > >>>>> What should be the desired behavior? Having it configurable as it > >>>>> is today but fix the strange bracket adding? remove this behavior? > >>>>> I can't find now how ParagraphEditor did this. > >>>>> > >>>>> Guille > >>>>> > >>>>> > >>>>> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito > >>>>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > >>>>> > >>>>> Yes, the issue can be reduced to: > >>>>> > >>>>> open parenthesis (or brackets), then something else (anywhere > >>>>> in the editor). > >>>>> > >>>>> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com > >>>>> <mailto:marianopeck@gmail.com>> > >>>>> > >>>>> I detected a similar problem: > >>>>> > >>>>> once you type an opening parenthesis, and then something > >>>>> else, it adds a new one at the END of the code > >>>>> > >>>>> check http://code.google.com/p/pharo/issues/detail?id=2939 > >>>>> > >>>>> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com > >>>>> <mailto:guillermopolito@gmail.com>> > >>>>> > >>>>> http://code.google.com/p/pharo/issues/detail?id=3069 > >>>>> > >>>>> if you type: > >>>>> > >>>>> [] -> []] > >>>>> > >>>>> () -> ()) > >>>>> > >>>>> {} -> {}} > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Bye! > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> > >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------ > >>>>> > >>>>> > >>>>> No virus found in this incoming message. > >>>>> Checked by AVG - www.avg.com > >>>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: 10/08/10 03:34:00 > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] Missing Close in About Dialog
by StÃ©phane Ducasse Oct. 18, 2010

Oct. 18, 2010

thanks Bernhard :) Welcome too :) Stef (busy running). On Oct 17, 2010, at 4:30 PM, Bernhard Pieber wrote: > Ah, interesting! I just tested it again more thoroughly and I found out that it has to do with the size of the Pharo window. If I maximize it on my 30" display the dialog truncated so that the OK button is not visible. If I make the window is much smaller it appears. See http://dl.dropbox.com/u/6204244/Pharo%20About%20Dialog.png. > > Thanks for the fast response! > > Cheers, > Bernhard > > Am 17.10.2010 um 16:08 schrieb Schwab,Wilhelm K: > >> Are you sure? I see an OK button at the bottom right of About in an image that identifies itself the same way. >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bernhard Pieber [bernhard(a)pieber.com] >> Sent: Sunday, October 17, 2010 10:05 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Missing Close in About Dialog >> >> Dear Pharo Folks, >> >> It is a very minor thing but I wanted to let you know that the About Dialog (World Menu > System > Aboutâ¦) in the latest stable Pharo Dev image (Pharo-1.1.1-dev10.09.1) has not got any Close button. >> >> Cheers, >> Bernhard >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] PharoKernel #12196
by Pavel Krivanek Oct. 18, 2010

Oct. 18, 2010

Hi, I uploaded an updated version of PharoKernel: https://gforge.inria.fr/frs/download.php/27655/PharoKernel-1.2-12196.zip The patch.st file is now organized by related issues. Cheers, -- Pavel

1 0

Re: [Pharo-project] Speeding up Pharo 1.1
by StÃ©phane Ducasse Oct. 18, 2010

Oct. 18, 2010

On Oct 18, 2010, at 9:22 AM, Bart Veenstra wrote: > After MCMethodDefinition shutDown it looks like it is reacting a bit > faster to keyboard input. I often experience sluggishness in > autocompletion method. When I type in a name of a class in a > workspace, the autocomplete suggests 3 options. I want to choose the > middle, so I press down and after 3 seconds (or sometimes nothging > happens) it selects the class. The longer I have my image open, the > longer this will take :S Argh we should fix that. I will start to integrate enh of levente related to hasBinding.... but I'm not sure it will help. Stef > > > > > 2010/10/17 Igor Stasenko <siguctua(a)gmail.com>: >> Bart, >> can you try doing: >> >> MCMethodDefinition shutDown >> >> in your image? >> >> On 16 October 2010 14:48, Bart Veenstra <bart.veenstra(a)gmail.com> wrote: >>> Hi list, >>> >>> I have been working with Pharo for almost a month now, and I suspect >>> that the performance is degrading fast. UI tasks takes several seconds >>> to react to my keyboard. >>> >>> At work we use VAST and I have experience with VW as well and those >>> smalltaks react to my keyboard and mouse actions instantly. But Pharo >>> works very sluggish. >>> >>> My image is about 130MB because I have loaded all dutch postcode in >>> memory, but that should not affect the performance of general >>> operations like typing with the keyboard. I am not a fast typer, but >>> sometimes it takes seconds to show my keyboard input. I can't use the >>> down key to select the right method from suggestions, because it seems >>> to lockup completely. >>> >>> Are there ways to speedup Pharo? I would love to use cogVM but I >>> haven't got gemtools working on it... >>> >>> Will upgrading to 1.1.1 fix these issues? >>> >>> Is my OS (Windows 7-64bit) causing these issues? >>> >>> Regards, >>> >>> Bart >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] A Lazy Inspector?
by StÃ©phane Ducasse Oct. 18, 2010

Oct. 18, 2010

On Oct 18, 2010, at 4:40 AM, Oscar E A Callau wrote: > Hello all, > > I was wondering what actually the inspector does in the following case: > > When you explore (or inspect) the expression: Class environment > you get all classes in the system dictionary. If you navigate inside a class, for example AColorSelectorMorph, you can see all its properties and one of them is environment, if you go inside it, you get again all classes in the system dictionary. So, you can repeat this infinitely (or until you get run out of memory, I guess) > > Is it the behavior of a lazy inspector? If true, why I cannot inspect a mutually-recursive class definition, I do not understand what you mean by that. Normally if you define the two classes then you can browse navigate.... them without problem with the inspector. > like this: > > Object subclass: #Foo > instanceVariableNames: 'bar' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Foo>>initialize > bar:= Bar new > > Object subclass: #Bar > instanceVariableNames: 'foo' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Foo>>initialize > bar:= Foo new > > Thanks in advance. > > P.S.: How can I stop my execution in the pharo image when it is in a infinite loop? I can't remember what the shortcut was. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)
by StÃ©phane Ducasse Oct. 18, 2010

Oct. 18, 2010

>>> >>> >> >> Thanks, Levente for giving a feedback. >> Please, feel free to shape my classes in more complete from (such as >> proper naming), >> to make them ready for inclusion in both Squeak's and Pharo cores. >> I propose the following names: >> AtomicQueue (base class) -> AtomicCollection >> FIFOQueue -> AtomicQueue >> LIFOQueue -> AtomicStack >> If you, or anyone else having better suggestions, speak now :) > > > Sounds like good names. > > >> In any case, i'm am open to discuss further details and possible >> caveats of using new classes >> to anyone interested in using them. >> >> P.S. As a side note, i now can explain (to myself at first place), why >> i intuitively choosed to used atomic swap >> instead of CAS. >> Because it fits better fits with smalltalk language semantics: >> >> A swap operation in smalltalk implemented as two assignments: >> x := y. y := z. >> An assignments is basic operation, which have nothing to do with >> late-bound nature of language. >> Unless we going to introduce a meta-object protocol(s), which could >> turn a simple assignment >> into some message sends under the hood, it will remain a basic, >> early-bound operation. >> And even if we do, it is highly unlikely, that even then we will throw >> away the old, >> simple assignment, which identifies an assignment source & target at >> compile time. >> >> In contrast, a CAS operation , if written in smalltalk looks like: >> >> (a == b ) ifTrue: [ a := c ] >> >> so, it having two message sends (#== , #ifTrue:), and from strict, >> pure language perspective, >> this using a late-bound semantics (a message sends), >> and as any message send, the message result and behavior cannot be >> predicted at compile time >> and therefore its wrong to assume that such statement could be an >> atomic operation. >> >> Unless, of course, we introduce a new language syntax which will >> denote a CAS operation explicitly. >> >>> >>> Levente >>> >>> >>> snip >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > >

2 1

Oct. 18, 2010

12196 ----- - Issue 3121: LongTest API improvement. - Issue 3120: MultiByteFileStream class>>lineEndDefault. - Issue 3119: rounded and truncated for DateAndTime. - Issue 3126: Cleans do: symbol usage

1 0

[Pharo-project] pharo sprint / moose dojo - october 23-24, bern
by Tudor Girba Oct. 18, 2010

Oct. 18, 2010

Hi, We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): http://www.moosetechnology.org/events/2010-10-22-dojo For planning purposes, please let me know if you will attend. Cheers, Doru p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) http://choose.s-i.ch/events/forum2010 -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

2 6