August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by Nicolas Cellier

2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote: > >> 2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> Hi >>> >>> I would like that we do an analysis of what should stay in implementors >>> >>> Here are the menus in 1.2 and 1.4 >>> >> >> Note that the menu titles are misleading. >> In previous implementation, 'Implementors of...(m)' did mean >> implementor of this message or any message called by this method. > > I did not pay attention to that because I always type the code but I see now. > >> In current implementation, 'Implementors of...(m)' does mean >> implementor of this message and only this message. >> Same for 'senders of ...(n)'. >> >> That's the main grief I got because this break the browsing chain. >> If I want to see implementors/senders of a sub message, then I have to: >> - select the message in text field, then click cmd+m or cmd+n > > this is what I do :) > Then also remove implementors/senders from the method list menu... >> - if the message is multiple keyword, then this won't work... > > We should fix that for any place in the system foo: #yyy to: does not find foo:to: :( > This requires a minimal parsing of surrounding text, maybe shout like style is enough. >> Â I have to open a finder, copy some text, paste in the finder then >> click one of the matching methods... >> That's many more clicks than previous implementation. > > Ok we will fix that. > > >> >> To define a "good" UI you must not only think in term of available >> feature, other views matter: >> - homogeneity of presentation / action >> - number of clicks for accessing a feature >> - auto-discovery of features rather than implicit knowledge > > Yes. > >>> Please comment so that we can add what is really used. >>> As a general comment I would avoid to do everything with a single tool. >>> >> >> Err. I think the contrary. >> Every such view is a browser with a specific filter on displayed code. >> The first function of a browser is browsing. >> Removing browsing capabilities from these views make em become dead >> ends (look and close). >> To restore the navigation chain, user must pass thru textual copy/paste. >> Ubiquitous browsing is a strength of Smalltalk IDE, no? > > Yes but do we need spawn subprotocol? and friends. All instances... > So let us focus on the most 40% most important features and add them to the browsers. > So there should be a reasonable amount of used functionality. > > So let us know what you use most of the time or less and this will be good. > > Stef > This reflects my very personnal use for the browsing category : 5) vital alt+b / alt+N (otherwise I have to type self/print it/select it/alt+b in Text) 4) often used: alt+m alt+n (including sub messages) alt+v (my own right to make mistake) inst var refs/defs (though I also browse it from text with alt+shift+n for refs) 3) casually used: alt+h - local implementors/senders - alt+i inheritance - class var ref/defs 2) rarely used; none 1) never used: all the rest For actions: 4) remove method (x) 3) toggle break on entry (it's not recommended for some kernel UI messages) 2) fileOut (but in some rare cases this is valuable, it must be able to filOut the whole list if there is no selection) - change category 1) all the rest But there is a bias, everything accessible thru more... will be less often used by construction. Of course, my flow is a bit different when using OB/RB. I'm not biggest OB fan, but I wonder like Marcus if maintaining two browsers is sustainable. 1) You have complaints from Lukas because of OB regressions at each upgrade 2) You get complaints for removed features from end users. A recipe for maximizing the complaints ;) While you could integrate OB in dev, core developers would fix OB on the fly and commit to local Pharo/PharoInbox. Then Lukas would select/correct/merge available fixes and officialize them on a new ConfigurationOfOB. Nicolas

Aug. 9, 2011

Re: [Pharo-project] [Seaside] Seaside on Pharo-Kernel

by Mariano Martinez Peck

Wow. This is awesome: a working Seaside image in 4.3 MB. On Tue, Aug 9, 2011 at 3:11 PM, Pavel Krivanek <squeak3(a)continentalbrno.cz>wrote: > There is a prepared image: > > > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Seas… > > -- Pavel > > On Tue, Aug 9, 2011 at 3:03 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > Hi Pavel, > > > > This is really cool! > > > > Sven > > > > On 09 Aug 2011, at 12:52, Pavel Krivanek wrote: > > > >> Hi, > >> > >> there's possible to load Seaside to the Pharo-Kernel. > >> > >> 1) Load PharoKernel-Gofer image from CI server > >> ( > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Gofe… > ) > >> > >> 2) run the image with seaside.st script as an argument. That will > >> create about 4.1 MB image with basic Seaside packages and basic > >> examples. > >> > >> 3) run the image with run.st script (note that starting of the server > >> in the seaside.st script will hang, currently I have no idea why). > >> > >> 4) see if everything works at > http://localhost:8080/examples/examplebrowser > >> > >> Cheers, > >> -- Pavel > >> <run.st><seaside.st>_______________________________________________ > >> seaside mailing list > >> seaside(a)lists.squeakfoundation.org > >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > > seaside mailing list > > seaside(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Mariano http://marianopeck.wordpress.com

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by Gary Chambers

>Note that the menu titles are misleading. >In previous implementation, 'Implementors of...(m)' did mean >implementor of this message or any message called by this method. >In current implementation, 'Implementors of...(m)' does mean >implementor of this message and only this message. >Same for 'senders of ...(n)'. I also prefer the choice of actually sent messages to be picked from a list. A discontinuity with the standard browsers that is becoming irksome for me... For multi keywords it is possible to use the keyboard (both keyboard AND mouse should be available, not just one or the other) if you select a range that includes all keyword components... I also miss "Browse hierarchy" from implementors, for what it's worth. Not against improvements to the tools but feedback on changes should be expected! Regards, Gary

Aug. 9, 2011

Re: [Pharo-project] About configurationOfPharoRB

by Dale Henrichs

Stef, I think I will have to make a new release defining attributes for Pharo 1.4... This is related to Metacello Issue 146[1]. Pharo1.4 would be a good place to introduce a method to define the Metacello attributes for the platform ... I think if you arrange to hang a method off of SmallImage (?) called defaultMetacelloPlatformAttributes that returned the following collection: ^#(#squeakCommon #pharo #'pharo1.x' #'pharo1.4.x') Then I could make a quick release of Metacello 1.0-beta.1.30.1 that would use that method and you'd be in business... Dale [1] http://code.google.com/p/metacello/issues/detail?id=146 ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Sunday, August 7, 2011 1:30:14 PM | Subject: Re: [Pharo-project] About configurationOfPharoRB | | Dale | | I added | | stable: spec | <symbolicVersion: #stable> | | spec for: #'pharo1.0.x' version: '1.2.1'. | spec for: #'pharo1.1.x' version: '1.5'. | spec for: #'pharo1.2.x' version: '1.7'. | spec for: #'pharo1.3.x' version: '1.7'. | spec for: #'pharo1.4.x' version: '1.8'. | spec for: #'squeak4.x' version: '1.6'. | | and a new baseline and version but when I do | | | (ConfigurationOfRefactoringBrowser project version: #'stable') load | | I get an error. | | Do you have an idea? | | Stef | | | | version18: spec | <version: '1.8' imports: #('1.8-baseline' )> | | spec for: #'common' do: [ | spec blessing: #'release'. | spec description: 'RefactoringBrowser for pharo 1.4 alpha. For this | version we just move the place to look for Refactoring-Changes. | Now there is a project for RB for pharo: It is called PharoRB'. | spec author: 'StephaneDucasse'. | spec timestamp: '2011-08-07T21:54:25+00:00'. "DateAndTime now | asString" | ]. | | spec for: #'pharo' do: [ | spec | | package: 'AST-Core' with: 'AST-Core-lr.87'; | package: 'AST-Tests-Core' with: 'AST-Tests-Core-lr.11'; | | package: 'AST-Semantic' with: 'AST-Semantic-lr.15'; | package: 'AST-Tests-Semantic' with: 'AST-Tests-Semantic-lr.3'; | | package: 'Refactoring-Environment' with: | 'Refactoring-Environment-lr.7'; | package: 'Refactoring-Tests-Environment' with: | 'Refactoring-Tests-Environment-lr.1'; | | package: 'Refactoring-Changes' with: | 'Refactoring-Changes-GuillermoPolito.17'; | package: 'Refactoring-Tests-Changes' with: | 'Refactoring-Tests-Changes-lr.14'; | | package: 'Refactoring-Core' with: 'Refactoring-Core-lr.153'; | package: 'Refactoring-Tests-Core' with: | 'Refactoring-Tests-Core-lr.51'; | | package: 'Refactoring-Critics' with: 'Refactoring-Critics-lr.9'; | package: 'Refactoring-Tests-Critics' with: | 'Refactoring-Tests-Critics-lr.3'; | | package: 'Refactoring-Spelling' with: | 'Refactoring-Spelling-pmm.25'; | package: 'Refactoring-Tests-Spelling' with: | 'Refactoring-Tests-Spelling-lr.6'. | | ]. | | spec for: #'squeak' do: [ | spec description: 'Squeak support based on Squeak4.2-Trunk-10628'. | spec | package: 'AST-Core' with: 'AST-Core-lr.85'; | package: 'AST-Semantic' with: 'AST-Semantic-lr.15'; | package: 'Refactoring-Core' with: 'Refactoring-Core-lr.153'; | package: 'Refactoring-Environment' with: | 'Refactoring-Environment-lr.4'; | package: 'Refactoring-Critics' with: 'Refactoring-Critics-lr.4'; | package: 'Refactoring-Spelling' with: | 'Refactoring-Spelling-lr.23'; | package: 'Refactoring-Changes' with: 'Refactoring-Changes-lr.16']. | spec for: #'gemstone' do: [ | spec author: 'DaleHenrichs'. | spec project: 'GsCore' with: '0.241'. | spec | package: 'AST-Core' with: 'AST-Core-DaleHenrichs.84'; | package: 'AST-Tests-Core' with: | 'AST-Tests-Core-DaleHenrichs.11'.]. |

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by StÃ©phane Ducasse

On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote: > 2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hi >> >> I would like that we do an analysis of what should stay in implementors >> >> Here are the menus in 1.2 and 1.4 >> > > Note that the menu titles are misleading. > In previous implementation, 'Implementors of...(m)' did mean > implementor of this message or any message called by this method. I did not pay attention to that because I always type the code but I see now. > In current implementation, 'Implementors of...(m)' does mean > implementor of this message and only this message. > Same for 'senders of ...(n)'. > > That's the main grief I got because this break the browsing chain. > If I want to see implementors/senders of a sub message, then I have to: > - select the message in text field, then click cmd+m or cmd+n this is what I do :) > - if the message is multiple keyword, then this won't work... We should fix that for any place in the system foo: #yyy to: does not find foo:to: :( > I have to open a finder, copy some text, paste in the finder then > click one of the matching methods... > That's many more clicks than previous implementation. Ok we will fix that. > > To define a "good" UI you must not only think in term of available > feature, other views matter: > - homogeneity of presentation / action > - number of clicks for accessing a feature > - auto-discovery of features rather than implicit knowledge Yes. >> Please comment so that we can add what is really used. >> As a general comment I would avoid to do everything with a single tool. >> > > Err. I think the contrary. > Every such view is a browser with a specific filter on displayed code. > The first function of a browser is browsing. > Removing browsing capabilities from these views make em become dead > ends (look and close). > To restore the navigation chain, user must pass thru textual copy/paste. > Ubiquitous browsing is a strength of Smalltalk IDE, no? Yes but do we need spawn subprotocol? and friends. All instances... So let us focus on the most 40% most important features and add them to the browsers. So there should be a reasonable amount of used functionality. So let us know what you use most of the time or less and this will be good. Stef

Aug. 9, 2011

[Pharo-project] [update 1.4] #14079

by StÃ©phane Ducasse

14079 ----- - Issue 4550: methodSymbol is a bad name for selector. Couple more fixes - Fix methodClass of RGMethodDefinition Stef

Aug. 9, 2011

Re: [Pharo-project] What are the useful operations of implementors/senders that you use

by Nicolas Cellier

2011/8/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi > > I would like that we do an analysis of what should stay in implementors > > Here are the menus in 1.2 and 1.4 > Note that the menu titles are misleading. In previous implementation, 'Implementors of...(m)' did mean implementor of this message or any message called by this method. In current implementation, 'Implementors of...(m)' does mean implementor of this message and only this message. Same for 'senders of ...(n)'. That's the main grief I got because this break the browsing chain. If I want to see implementors/senders of a sub message, then I have to: - select the message in text field, then click cmd+m or cmd+n - if the message is multiple keyword, then this won't work... I have to open a finder, copy some text, paste in the finder then click one of the matching methods... That's many more clicks than previous implementation. To define a "good" UI you must not only think in term of available feature, other views matter: - homogeneity of presentation / action - number of clicks for accessing a feature - auto-discovery of features rather than implicit knowledge > Please comment so that we can add what is really used. > As a general comment I would avoid to do everything with a single tool. > Err. I think the contrary. Every such view is a browser with a specific filter on displayed code. The first function of a browser is browsing. Removing browsing capabilities from these views make em become dead ends (look and close). To restore the navigation chain, user must pass thru textual copy/paste. Ubiquitous browsing is a strength of Smalltalk IDE, no? > Stef > > >

Aug. 9, 2011

Re: [Pharo-project] PharoCore 1.3: Implementors browser broken

by Lukas Renggli

Created: http://code.google.com/p/pharo/issues/detail?id=4611 On 8 August 2011 22:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks > >> I just noticed that the implementors browser in Pharo Core 1.3 does >> not show any kind of warning if a variable is not declared. > > I know that I fixed a bug in 1.4 when executing a comment. > >> Also parse errors result in the fatal SyntaxError window. > > Yes I want kill that one too. Marcus told me that he has fun with petitparser and made a lot of progress for the decompiler. > So opal is getting closer and closer... I should continue to work on Rpackage argh. > >> >> I thought I report it here before I forget it again, because the bug >> tracker is in read-only mode right now. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 9, 2011

Re: [Pharo-project] Shout in Pharo 1.3

by Lukas Renggli

Done: http://code.google.com/p/pharo/issues/detail?id=4609 On 9 August 2011 13:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I would like to know too. > Alain is on holiday else he could tell us. > Can you open a ticket and put alain on cc? > > Stef > > >> Does anybody has a version of Shout that correctly works in the >> traditional tools in Pharo 1.3? >> >> I tried various versions of Shout, but could not find one that worked >> correctly in the traditional tools. The problem I see is that Shout is >> not properly setup/updated anymore, i.e. it does not callback to the >> model (#shoutAboutToStyle:). When the browser/debugger changes the >> method/definition/comment highlighting is not enabled/disabled and the >> context is not changed. >> >> Does anybody have a working version of Shout and/or knows how to >> easily make it work? >> >> It works in OB because I subclassed 3 editor classes and undone the >> "new" way of how highlighting works. I thought I bring this up again, >> because as far as I see there is still the same problem ... >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 9, 2011

[Pharo-project] News about NativeBoost

by Igor Stasenko

Hello, Major news: NativeBoost now working on Macs! The main problem with Mac OS platform was that it requires a stack alignment discipline, while other platforms don't. So, i had to extend the assembler to make sure that all external calls will be made with properly aligned stack. Also, i spent time to improve error handling. Since in Cog/Stack VMs we having nice primitive error code, now it can report what caused a failure in more detail, than just failing a primitive and leaving a language side to guess what gone wrong. There's a lot of other small changes, like new tests, more examples etc.. But i don't want to describe them all (and frankly i don't remember all of them ;) Things not yet working: The callbacks to language side is not functional (i have to revise this code to synchronize it with callback machinery in Cog VMs). The callbacks to native code working well (of course, because it don't needs to deal with VM-specific stuff ;) The prebuilt VMs, which contain a NativeBoost plugin are now on Jenkins server. These VMs will be built automatically each time there is code update for Cog VMs (in same way as all continuous integration jobs). The only difference between original Cog VMs and Cog+NativeBoost VMs is that they contain NativeBoost plugin. So, you can use these VMs instead of Cog VMs if you like. You can download VMs from here: https://ci.lille.inria.fr/pharo/view/NativeBoost/ To install NativeBoost into your image follow instructions on: http://code.google.com/p/nativeboost/wiki/Installation -- Best regards, Igor Stasenko AKA sig.

Aug. 9, 2011