- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NewInspector

by Frederic Pluquet

Fixed in the last version. Thanks for feedback Alex. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Thu, Jun 18, 2009 at 10:28 PM, Alexandre Bergel < Alexandre.Bergel(a)inria.fr> wrote: > Hi! > > When I right-click in the workspace panel of a newinspector I get a > rollback 'The getMenuSelector must be a 1- or 2-keyword symbol' > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by StÃ©phane Ducasse

I should say that I hate the popups "do you want to do that or remove this variable but wait it is assigned tooo." May be we should have a menu clean code! but for now let is accept it > Hi, > I have made some changes to pharo to make it more tdd oriented. I > want to share them with you to know your opinion and then make the > code public. > The changes I made are: > > 1) When there is an error, the debugger opens directly. Reason: I > found that I always press Debug when an error occurs in the Notifier > window. Question: Should this option be a preference? I'm not sure in fact because when you are not in TDD you just often close the predebug. but we could change. > 2) The debugger opens in a big window. Reason: I always want to > debug! and I want to see as much as possible when debugging. Before > I found myself making the debugger window bigger all the time larger but not to big :) > 3) When compiling a method that sends a message not defined, it does > not ask anymore if I want to change it. Reason: When doing TDD we > work top-down, so we are always sending messages that are not > defined and that we are going to define when running the test. > Question: Should this option be a preference? No preference. Now if the system could guess typos :) > 4) I added an option to save and run the test from the code pane of > the omni browser (ctr+t). If the test fails, opens a debugger to fix > it. Reason: It is very handful Yes right now when you do alt-t you run the test but you cannot get a debugger on them. I would love to click to run the tests get a small widgets with the result of the execution and that I can rerun or get a debugger on the tests. > 5) I added an option to save and step a test from the code pane of > the omni browser (ctrl+r). Reason: It is very handful (Problem: The > debugger does not work well with breakpoints...) > 6) I added a debugCase: message to TestResult and make some changes > to the omni browser to show the result of debugging a test. Reason: > Before, when debugging a test the browser was showing the test as > not runned. sounds interesting > 7) When running a test, the defualtAction of the MessageNotUndertood > exception will ask you if you want to implement the method (if the > receiver is not nil) so you don't have to select that option from > the debugger stack list menu. Reason: When running a test 95% of the > time a message not understood will be implemented and answering yes > or no is easier that going to the stack menu of the debugger to > select the option implement. in Squeak we could show the class and its superclass. > > What do you think? Comments welcome. > Bye, > Hernan. > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 19, 2009

Re: [Pharo-project] how do I rename a package?

by StÃ©phane Ducasse

this is also my impression even if lukas will argue that we will lose the apckage history :) On Jun 18, 2009, at 10:11 AM, Oscar Nierstrasz wrote: > > I discovered to my astonishment that there is no contextual menu item > in either the MC browser or the OB system browser to rename a package! > > I know how to move all classes and methods from one package to another > programmatically, but shouldn't there be a way to rename a package? > > http://scg.unibe.ch/wiki/faq/pharofaq/howToMoveCodeBetweenPackages > > Couldn't figure out how to do this. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by Denis Kudriashov

1) When there is an error, the debugger opens directly. Reason: I found that > I always press Debug when an error occurs in the Notifier window. Question: > Should this option be a preference? > I like VW behavior. There are three buttons: debug, run, step. When I do debug and there is an error in some test, the debugger opens directly. And when I press debugger proceed, tests continue execution. When I do run, all failed tests are collected to the list. And button "show failed" appears. When I do step the debugger open on the begin of test. I think it is ideal browser behavior for TDD support. In some squeak version (maiby 3.8) there is special services fo this. But now it is absent

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by laurent laffont

Hi, It means Test Driven Development. It defines the process of writing the unit test before writing the "real code". The steps are roughly: 1. write a test for a feature you want. For example, "when I add a Movie instance to an empty Movies collection, then Movies size should increase by one" 2. check your test fails (in most cases) as you still haven't implement your feature 3. write the real code (the simplest that should make your test pass) 4. check your test pass 5. refactor both real code and test code, generally searching for code duplication. This enables that: - most of your code and cases is tested - simpler code - confidence in your code - quicker development as you immediately know when something breaks, thus less debugging. A book I've learned a lot from is Dave Astels's Test Driven Development: A practical guide. Laurent Laffont On Fri, Jun 19, 2009 at 8:58 AM, Alain Plantec <alain.plantec(a)free.fr>wrote: > sorry but what is the meaning of "TDD" ? > Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by Norbert Hartl

On Fri, 2009-06-19 at 08:58 +0200, Alain Plantec wrote: > sorry but what is the meaning of "TDD" ? It is test driven development. Norbert

June 19, 2009

Re: [Pharo-project] Making pharo more tdd oriented

by Alain Plantec

sorry but what is the meaning of "TDD" ? Alain

June 19, 2009

Re: [Pharo-project] Monticello merge tool fail - need strikethrough for deleted code - be friendly to red-green colour blind people!

by StÃ©phane Ducasse

ok can you open a ticket and put gary in cc? because you are right I worked with two color blind people Stef On Jun 18, 2009, at 10:02 AM, Oscar Nierstrasz wrote: > > Hi Folks, > > While updating the Monticello chapter of Pharo By Example to the > current Pharo GUI, I discovered that diffs in the merge tool (and > elsewhere) no longer show deleted code struck through, but only in > red, with new code in green. > > This is a major fail for colour blind people! It also does not show > when printed in grey-scale. > > Can we have the strike-through back? It is an important visual cue. > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 19, 2009

Re: [Pharo-project] idea to have a better methodFinder :)

by StÃ©phane Ducasse

I have to check it :) but may be it should be part of the pragma core package. Stef On Jun 18, 2009, at 8:05 AM, Alain Plantec wrote: > PragmaCollector could be very useful for the purpose of collecting > pragma for a MethodFinder (or other client) > I can provide more help if needed. > Alain > > > Marcus Denker a Ã©crit : >> On 17.06.2009, at 16:16, Bernardo Ezequiel Contreras wrote: >> >> >>> where can i find Pragma? do you have a link? >>> because i couldnt find it. >>> >>> >> >> Pragma is a class. Can be found in Squeak 3.9 and Pharo, it was >> introduced to Smalltalk >> in VisualWorks, I think, and brought to Squeak by Lukas in 3.9 (put >> on >> top of a property >> interface for methods inspired by Tweak). >> >> The idea is the following: In Smalltalk, there is a special syntax >> for >> Primitives: >> >> + aNumber >> >> <primitive: 1> >> ^ super + aNumber >> >> >> Why not provide a more general concept where we can use the >> <selector: >> arg> syntax to put meta-annotations >> in methods? And that's what pragmas are. (Conversely, in Squeak 3.9 >> and Pharo, primitives are pragmas and not >> special syntax). >> >> tt >> <hello: #world> >> >> >> is perfectly fine. For what can this now be used? One idea is meta- >> annotations. For example, SLint is a useful >> code-critic tool. But sometimes, it's wrong. So you can put a Pragma >> that communicates to SUnit: please don't >> report the problem X, because I decided it is none. >> Another example would be the MethodFinder. The example-mode of the >> method finder allows you to give an example >> and executes all methods of the system to find one that does what >> your >> example requests. >> >> e.g. 3. 4. 7 >> >> it finds 3 + 4, 3 bitOr: 4 and 3 bitXor: 4. >> >> Of course, executing just every method could lead to problems if the >> method has side-effects. (Like, quitting the >> image). Thus, the MethodFinder has lists of methods that should not >> be >> called (#noteDangerous). Of course, this >> means that all selectors are hard-coded. And one can not use this >> valuable information for other cases. >> One thing to think about would be to add a "this method has a bad >> side- >> effect" annotation. (maybe. Maybe this will >> not scale and just clutter the system. But it's worth a try). >> >> Back to Pragma: on the class-side there are some convenience methods, >> e.g. >> >> Pragma allNamed: #primitive: in: SmallInteger >> >> returns all pragmas in class SmallInteger. (and the pragma references >> the method it is installed in, which in >> turn knows it's class and selector). >> >> Marcus >> >> -- >> Marcus Denker - http://marcusdenker.de >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> 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

June 19, 2009

Re: [Pharo-project] MIT ScaledDecimal (Issue 816) has not been integrated correctly

by StÃ©phane Ducasse

OK I reopen the ticket so that other can see it. stef On Jun 17, 2009, at 9:09 PM, Nicolas Cellier wrote: > (SystemNavigation default allMethodsSelect: [:meth | > | hasABadLiteral | > hasABadLiteral := false. > meth literalsDo: [:lit | > (lit class = ScaledDecimal and: [lit numerator isNil or: > [lit denominator isNil]]) > ifTrue: [hasABadLiteral := true]]. > hasABadLiteral]) > do: [:m | > m actualClass recompile: m methodSymbol from: m actualClass] > > > 2009/6/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Ok nicolas > Sorry for the problem. > > I guess that I will wait for the code snippet > > stef writing should be writing a boring report for a month ago :) > > On Jun 17, 2009, at 3:09 PM, Nicolas Cellier wrote: > > > in update10307 (script385) related to > > http://code.google.com/p/pharo/issues/detail?id=816 : > > > > ScaledDecimal2-Part1-nice.1.cs had a postscript to mutate old > > instances to new instances and not losse existing ScaledDecimals (at > > least the literals in ScaledDecimalTests). > > > > This has not been applied, so some ScaledDecimal now have a nil > > numerator and denominator. > > This makes some tests fail. > > > > Cure: detect and recompile these methods having a broken > > ScaledDecimal literal. > > I don't have time to give a code snippet by now... > > > > Nicolas > > > > _______________________________________________ > > 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

June 19, 2009