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

Re: [Pharo-project] Global shortcut keys in Pharo

by Tony Fleig

A follow-up: I scanned the email threads mentioned in this thread. I tried to use Keymapper and it seemed way too complicated for the simple things I wanted to do. It wasn't obvious at all to me how to proceed once I had the GUI displayed and I encountered numerous errors while exploring it. After perusing the code a little, it seemed much more invasive than what I had in mind -- extensions and overrides in numerous classes. It seems to be a general approach for solving keystroke mapping not only at the global level, but in application-specific cases as well. I have placed my own GlobalKeys package on SqueakSource (http://www.squeaksource.com/GlobalKeys) It is much smaller and less ambitious than Keymapper, it only works on Pharo, and it is much less capable, but at least in my environment it does what I need without a lot of complication. Maybe someone else will find it useful as well. One of the joys of Smalltalk: if you don't like the way something works, change it or write your own. Regards, TF On Fri, Dec 3, 2010 at 8:19 PM, Tony Fleig <tony.fleig(a)gmail.com> wrote: > I find myself wanting global keyboard shortcuts for such things as > invoking an external browser, switching focus between windows, opening > new tool windows, executing various World menu options, executing my > own scripts, etc. > > After working for years in corporations doing Windows-based > development in Microsoft Visual Studio, I find the necessity of > constantly reaching for the mouse in Pharo to be cumbersome and > unproductive. > > I was able to add some shortcut keys to invoke commands that I > prepared by sending messages like this: > > Â Â World respondToCommand: $l bySending: #startExternalWebBrowser to: > TFCommands. > > However, this only works when no window has the keyboard focus. > > I followed the keystroke handling path in the debugger and I think I > can probably find a place to hook in some special handling for my > globally-accessible keystrokes. > > My questions are: > > 1. Has somebody already done this? > > 2. Is there a "standard" or "best practice" way of accomplishing this? > > Regards, > TF >

Dec. 9, 2010

Re: [Pharo-project] Where does Regex-Core and friends live

by Alexandre Bergel

hi Dale! I do not know about your need. But personally, if I have to deal with non trivial parsing, I will use PetitParser. Lukas made a tutorial last week and I am convinced. Cheers, Alexandre On 8 Dec 2010, at 20:57, Dale Henrichs wrote: > I am porting the latest Regex to GemStone and in the interest of Pharo compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo repository. > > In loading Regex-Tests-Core I found some compile errors (doubled '.', a common porting problem) in RxParserTest>>testTranslatingMatchesUsing and RxParserTest>>test, but I don't know where the home repository (other then Pharo) resides, where I could submit my updates. > > I've got a GemSource repository, but I'm actually hoping (haven't run tests yet:) that I will be able to use Regex-Core without making any GemStone-specific changes ... > > Dale > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 9, 2010

Re: [Pharo-project] Finder issue?

by Francisco Ortiz PeÃ±aloza

Ben, this could somewhat related to http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg36339.ht… Cheers, Francisco On Wed, Dec 8, 2010 at 7:56 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Dec 8, 2010, at 10:45 PM, Francisco Ortiz PeÃ±aloza wrote: > > Great! Didn't know that but what about AppRegistry? I didn't see much of > it, don't know if its an old idea or have a bad implementation but would it > be better to use some dynamic binding mechanism so given any other day > someone could change the editor globally like *MorphicTextEditor default * > works. > > hmm i think i'm missing something > > > AppRegistry was a good idea ages ago, but I do not know if it could really > be useful now ... > > I'll take a look at that ^^ > > > Ben > > > > Thanks, > Francisco > > On Wed, Dec 8, 2010 at 7:00 PM, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> >> On Dec 8, 2010, at 8:37 PM, Francisco Ortiz PeÃ±aloza wrote: >> >> Hi, >> >> after loading last Shout on PharoCore the new Finder isn't working >> properly. Let's see >> >> PluggableShoutMorph>>initialize registers Shout in AppRegistry as the >> default MorphicTextEditor but FinderUI>>buildSourceTextArea uses a >> PluggableTextMorph. >> >> I think it should be using the more dinamic *MorphicTextEditor default*insted of the hardcoded PluggableTextMorph. Am i right? >> >> >> In 1.2, it was panned that PluggableTextMorph and PluggableShoutMorph >> should been merged. In fact, I've posted a fix to allow PluggableTextMorph >> to handle text styling, this way Shout isn't needed anymore :) >> >> >> Thank you for your review, >> >> >> Ben >> >> > >

Dec. 9, 2010

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

by Guillermo Polito

Sorry, It'll fail until *Issue 3385 in pharo: TextEditor doest not understand #model* gets fixed. :S Cheers, Guille On Wed, Dec 8, 2010 at 8:48 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Dec 8, 2010, at 10:25 AM, Marcus Denker wrote: > > > On Dec 7, 2010, at 8:42 PM, Guillermo Polito wrote: > > 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? > > > Yes, will set up a build for 1.2 today. > > > I have set one up that takes 1.2 core, runs updates and then tries to build > dev > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/ > > It is failing right now. > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/2/console > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

Dec. 9, 2010

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

by Guillermo Polito

I agree with everyone in that OCompletion makes non sense with TextEditor. How can we make it work with SmalltalkEditor and avoid the case in the screenshot of Francisco? I can help you if you need it :). Cheers, Guille 2010/12/8 Levente Uzonyi <leves(a)elte.hu> > On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote: > > Levente, >> >> that's weird, i'm sending you a screenshot i'm running PharoCore 12271 >> with Ocompletion-ul.88 loaded >> > > Right, I forgot to change the ToolSet to ECToolSet. Now I see the problem. > > > >> I really like how you clear the way with these two questions, >> - should OCompletion be used in that panel? >> - should that panel use TextEditor instead of SmalltalkEditor? >> >> Using OCompletion is ok i think, in another email i said that having two >> way >> autocompletion with the TextEditor element and the recent WHATEVER used >> list >> above dont make sense to me, but some argue that they use their mouse to >> go >> to a recently used class. >> >> i think the finder window should be minimal, just the input text element >> -no >> recent used list- and have autocompletion (ie. web autocompletion). As web >> users we see that a lot, i will not miss the recent WHATEVER list. >> > > A big +1 (note that I'm not a Pharo user). If there's need for the recent > classes, then it should be available via a different menu item + shortcut. > > > >> On your second question, imho we're trying to find a Smalltalk class or >> Smalltalk WHATEVER, could be better to have a SmalltalkEditor instance >> instead of TextEditor one. >> > > If the idea is to keep this tool this way (recent classes list + no > autocompleter), then I'd probably change it to SmalltalkEditor. But adding > the method #model to TextMorph will "fix" this problem anyway. > > > Levente > > > >> Cheers, >> Francisco >> >> [image: PharoScreenshot.1.png] >> >> On Wed, Dec 8, 2010 at 4:20 AM, Alain Plantec <alain.plantec(a)free.fr> >> wrote: >> >> I agree with Levente. The basic completion (cmd-q) is also only usable >>> with >>> a SmalltalkEditor. >>> Cheers >>> Alain >>> >>> Le 08/12/2010 03:58, Levente Uzonyi a Ã©crit : >>> >>> On Wed, 8 Dec 2010, Francisco Ortiz Pe?aloza wrote: >>> >>>> >>>> So Levente you're saying that given the following use case you musn't >>>> add >>>> >>>>> #model to TextEditor but change TextEditor collaboration with an >>>>> instance >>>>> of >>>>> SmalltalkEditor >>>>> >>>>> OCompletion works well to edit code in the system browser as is, the >>>>> DNU >>>>> occurs when as an example you do a class find (Cmd+f) on SystemBrowser >>>>> and >>>>> you start typing on that "Class name or fragment" window looking for >>>>> something. >>>>> >>>>> >>>> Adding the accessor is fine of course, it may be useful for other things >>>> too. I'm saying that OCompletion is intended to work in places where >>>> code >>>> completion is necessary and those places are usually SmalltalkEditors. >>>> There >>>> are two things to think about: >>>> - should OCompletion be used in that panel? >>>> - should that panel use TextEditor instead of SmalltalkEditor? >>>> >>>> Btw using the latest version of PharoCore (12271) I can't reproduce the >>>> error in the way you described it. >>>> >>>> >>>> Levente >>>> >>>> >>>> Cheers, >>>>> Francisco >>>>> >>>>> On Tue, Dec 7, 2010 at 9:07 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>>> >>>>> On Tue, 7 Dec 2010, pharo(a)googlecode.com wrote: >>>>> >>>>>> >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> OCompletion shouldn't be used in a TextEditor. OCompletion is for >>>>>>> >>>>>> Smalltalk >>>>>> code completion, while TextEditor is intended to be a text editor (ask >>>>>> Juan). That's why OCompletion adds the model accessor to >>>>>> SmalltalkEditor >>>>>> and >>>>>> not to TextEditor. >>>>>> >>>>>> >>>>>> Levente >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>>

Dec. 9, 2010

[Pharo-project] Issue 3391 in pharo: BlockClosure>>assertWithDescription: sends #logFailure:

by pharo＠googlecode.com

Status: Accepted Owner: da...(a)teleport.com New issue 3391 by da...(a)teleport.com: BlockClosure>>assertWithDescription: sends #logFailure: http://code.google.com/p/pharo/issues/detail?id=3391 In a PharoCore image (Pharo1.1.1 #11414 or Pharo1.2a #12271) the only sender of #assertWithDescription: is RxMatcher>>split: ... which wouldn't be that bad, except that BlockClosure>>assertWithDescription: sends #logFailure: which is only implemented in TestCase .... Soooo, it appears that assertWithDescription: should only be sent from instances of TestCase (and send removed from RxMatcher>>split:) or the send of #logFailure: removed from BlockClosure>>assertWithDescription: ... Found this on in GemStone testing while trying to figure out a test case that would trigger a failure of #assertWithDescription:, which BTW, I couldn't do .... so the #assertWithDescription: is probably unnecessary (or we need a test case to trigger the assertion)...

Dec. 9, 2010

[Pharo-project] Where does Regex-Core and friends live

by Dale Henrichs

I am porting the latest Regex to GemStone and in the interest of Pharo compatibility, I found Regex-Core and and Regex-Tests-Core in the Pharo repository. In loading Regex-Tests-Core I found some compile errors (doubled '.', a common porting problem) in RxParserTest>>testTranslatingMatchesUsing and RxParserTest>>test, but I don't know where the home repository (other then Pharo) resides, where I could submit my updates. I've got a GemSource repository, but I'm actually hoping (haven't run tests yet:) that I will be able to use Regex-Core without making any GemStone-specific changes ... Dale

Dec. 8, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Levente Uzonyi

On Wed, 8 Dec 2010, Adrian Lienhard wrote: > > On Dec 8, 2010, at 22:33 , Levente Uzonyi wrote: > >> On Wed, 8 Dec 2010, Mariano Martinez Peck wrote: >> >> Well, I doubt if speed is really important, since you're loading everything at most once. And the current tools are really fast IMHO. The following numbers are from Squeak: >> [ Compiler recompileAll ] timeToRun. 29083. >> CompiledMethod allInstances size. 60701. >> [ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. 1133. >> So the compiler is compiling 2087 methods per second on average. You can load 53575 methods per second from a file on average. If it's zipped, than it may be a bit slower, say a factor of 2-3x slowdown. So you can still load and compile more than 1800 methods per second. I guess thats fast enough. >> >> Even if Fuel can be 10x faster, it doesn't really make a difference IMHO. > > It would be interesting to thoroughly profile MC to figure where it spends all its time (with large projects it gets very very slow, like several minutes to just show the merge diffs between two branches). I guess those days are over when MC spends minutes doing this, it's at most a few seconds for large packages. The 1.5MB Morphic package of Squeak can be compared to another really old version (changes) in 3 seconds. According to MessageTally 50% of the time is spend in getting the timeStamp for the methods. Levente > > Adrian >

Dec. 8, 2010

Re: [Pharo-project] Finder issue?

by Benjamin

On Dec 8, 2010, at 10:45 PM, Francisco Ortiz PeÃ±aloza wrote: > Great! Didn't know that but what about AppRegistry? I didn't see > much of it, don't know if its an old idea or have a bad > implementation but would it be better to use some dynamic binding > mechanism so given any other day someone could change the editor > globally like MorphicTextEditor default works. > > hmm i think i'm missing something AppRegistry was a good idea ages ago, but I do not know if it could really be useful now ... I'll take a look at that ^^ Ben > > Thanks, > Francisco > > On Wed, Dec 8, 2010 at 7:00 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com > > wrote: > > On Dec 8, 2010, at 8:37 PM, Francisco Ortiz PeÃ±aloza wrote: > >> Hi, >> >> after loading last Shout on PharoCore the new Finder isn't working >> properly. Let's see >> >> PluggableShoutMorph>>initialize registers Shout in AppRegistry as >> the default MorphicTextEditor but FinderUI>>buildSourceTextArea >> uses a PluggableTextMorph. >> >> I think it should be using the more dinamic MorphicTextEditor >> default insted of the hardcoded PluggableTextMorph. Am i right? > > In 1.2, it was panned that PluggableTextMorph and > PluggableShoutMorph should been merged. In fact, I've posted a fix > to allow PluggableTextMorph to handle text styling, this way Shout > isn't needed anymore :) > > > Thank you for your review, > > > Ben > >

Dec. 8, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Mariano Martinez Peck

On Wed, Dec 8, 2010 at 10:38 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Dec 8, 2010, at 22:33 , Levente Uzonyi wrote: > > > On Wed, 8 Dec 2010, Mariano Martinez Peck wrote: > > > > Well, I doubt if speed is really important, since you're loading > everything at most once. And the current tools are really fast IMHO. The > following numbers are from Squeak: > > [ Compiler recompileAll ] timeToRun. 29083. > > CompiledMethod allInstances size. 60701. > > [ CompiledMethod allInstancesDo: [ :each | each getSource ] ] timeToRun. > 1133. > > So the compiler is compiling 2087 methods per second on average. You can > load 53575 methods per second from a file on average. If it's zipped, than > it may be a bit slower, say a factor of 2-3x slowdown. So you can still load > and compile more than 1800 methods per second. I guess thats fast enough. > > > > Even if Fuel can be 10x faster, it doesn't really make a difference IMHO. > > It would be interesting to thoroughly profile MC to figure where it spends > all its time (with large projects it gets very very slow, like several > minutes to just show the merge diffs between two branches). > > > Exactly. That's why I was suggesting that maybe with a fast binary serializer this can be much faster.

Dec. 8, 2010