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

Re: [Pharo-project] Unwanted blank lines

by Henrik Johansen

Figure out the line ending used by the file, then specify that AS the lineEndingConvention on the stream before you import. Cheers, Henry Den 26. juli 2010 kl. 16:58 skrev "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Hello all, > > In recent weeks, the code that I have exported from Dolphin and imported in Pharo (both via SIF) has ended up double spaced. In small amounts, it's not a big problem, but I just exported 980k of code and don't look forward to fixing that up after the fact. This could turn out to be due to cr/lf/lf sequences or something (looking at the .sif file using a hex editor comes to mind). > > Any suggestions for where you might look for the problem or a workaround? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 26, 2010

[Pharo-project] Unwanted blank lines

by Schwab,Wilhelm K

Hello all, In recent weeks, the code that I have exported from Dolphin and imported in Pharo (both via SIF) has ended up double spaced. In small amounts, it's not a big problem, but I just exported 980k of code and don't look forward to fixing that up after the fact. This could turn out to be due to cr/lf/lf sequences or something (looking at the .sif file using a hex editor comes to mind). Any suggestions for where you might look for the problem or a workaround? Bill

July 26, 2010

Re: [Pharo-project] why "maximize" does not fills all the window in1.1?

by Gary Chambers

For Mariano's side note... http://code.google.com/p/pharo/issues/detail?id=2716 Regards, Gary ----- Original Message ----- From: Mariano Abel Coca To: Pharo-project(a)lists.gforge.inria.fr Sent: Thursday, July 08, 2010 9:01 PM Subject: Re: [Pharo-project] why "maximize" does not fills all the window in1.1? What would be great is not using the squeak menu inside the world, but drawing it on the system window. More like mac's, that is integrated in the global menu. In Linux there is a GlobalMenuApplet for Gnome Panels that works like mac's Global Menu, and removes the menu from the windows and merges on the pannel. It's a nice advance to a mac interface. (That and CairoDock, of course) I don't have a clue about how to do it, but dreaming is free. :) Cheers, Mariano. 2010/7/8 Mariano Martinez Peck <marianopeck(a)gmail.com> On Thu, Jul 8, 2010 at 10:30 AM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: Carla F. Griggio wrote: > > Hahaha, good point, Wilhelm :P > > It kind of bothered me at first, but then I noticed it was more > confortable to open the World Menu, although I thought "maybe there's > another way to open the World menu where I don't need the background to be > visible". Is there? > > If not, I agree that there should be a way to do it without depending on > the background. But in the meantime, not maximizing the windows to full > screen helps. > I was thinking that a while ago as well. How about a top menu-bar like the Apple Menu like this (see screen mockup)? http://forum.world.st/file/n2281990/World_Menu.png This is cool. You did it? is it working ? because we have HostMenus-Mac, but it is only MacOS. Cheers Mariano On a side note, there's another small thing which has been bothering me is that even though I really like the Mac theme and look and feel the Red/Yellow/Green Close/Min/Max buttons don't indicate which one is which on a mouse-over so you need to know which color does what. I liked the windows button I saw in one of the Smalltalk Medicine Show video's. It still had a nice look-n-feel but the icons actually had more meaning. http://forum.world.st/file/n2281990/Better_Window_Icons.png -- View this message in context: http://forum.world.st/why-maximize-does-not-fills-all-the-window-in-1-1-tp2… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ 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

July 26, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by laurent laffont

On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Ideally, we should not tag long tests. The system should be smart enough to > characterize a test as long. If it takes more than 200ms, then it is long. > Autotest should then offer me to include long test or not in the automatic > test execution. > > Using tags means that I have to go over each method test and tag them. This > is a costly effort that is likely to not work in practice. > > We have > -=-=-=-=-=-=-=-=-=-=-=-= > TestCase class>>newTestDictionary > ^ Dictionary new at: #timeStamp put: TimeStamp now; > at: #passed put: Set new; > at: #failures put: Set new; > at: #errors put: Set new; > yourself > -=-=-=-=-=-=-=-=-=-=-=-= > > Maybe it should be extended with > -=-=-=-=-=-=-=-=-=-=-=-= > at: #long put: Set new > -=-=-=-=-=-=-=-=-=-=-=-= > > I guess the tweak in SUnit to identify long tests should not be that hard > to implement. > Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive). I also think that execution time is not the only criteria. For example, Autotest can have a "feedback deadline" of 2 seconds. That means it can run: - 2 tests of 1 second - 20 tests of 100 ms So knowing execution times, Autotest can run as many tests as it can, starting from fastest to lowest. It seems that JUnitMax do this way. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > Cheers, > Alexandre > > > On 26 Jul 2010, at 07:44, laurent laffont wrote: > > > > > On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > I have been using Autotest for a while already. I greatly reduce the > window switching. This is cool. > > However, I have to disable Autotest when the tests take time to execute. > > > > > > An idea is to be able to tag tests with pragmas to put them in > categories. So we can have a LongRunning category which is not run by > default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2) > > > > Then SUnit could be enhanced to show these categories. Useful to quickly > select all tests related to a project for example; or run only performance > tests. > > > > > > How would you name the tag ? Where the implementation should go ? > (TestCase ?) > > > > > > Laurent. > > > > > > Alexandre > > > > > > On 15 Jun 2010, at 21:41, laurent laffont wrote: > > > > > Hi Alexandre, > > > > > > I've reorganized Autotest to write tests. The tests now run in a thread > with lower priority. Thanks for feedback. > > > > > > Cheers, > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > > Hi Laurent, > > > > > > I tried to program while having AutoTest running. > > > More importantly than the interface, I experienced some problem with > long executing tests. Basically, these tests should not be executed while I > am programming. Or at least in a thread of a lesser priority. Am I the only > one to experience this? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > > > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > Hi Laurent, > > > > > > > > I like Autotest. It is true that I always execute the test after > modifying it. > > > > There are three horizontal panes. Why so? Is it just to open a > debugger when necessary? > > > > > > > > I want to be able to open a debugger from autotest. I agree the GUI > is crap now. > > > > > > > > > > > > We could imagine one standalone button instead with a green color to > say the test I just edited is green, and yellow or red when it fails. In > that case, clicking on the button open a debugger. > > > > > > > > I just feel the window of autotest takes a lot of space in the > screen, without having a real benefit. > > > > > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how > to make GUI now :) > > > > > > > > If you look at Autotest package, AutotestView is just the GUI, so we > can implement several GUI and see the best solution. I need to take the time > to do it, repository is read / write so feel free to commit :) > > > > > > > > What I want to have is a dashboard docked on one side of the screen > which acts like you're driving a car. It's always visible, you have to be > able to look quickly at it as when you check the speed of your car, adjust > your drive, .... > > > > > > > > Also another problem with the current version if that if a test > fails, change it and fails again, you don't see it has run (nothing moves in > the GUI). > > > > > > > > Finally, another problem is that you see that a test has failed, but > you don't know why (SUnit TestRunner has the same problem). I want to > display the exception message too. > > > > > > > > Thanks a lot for feedback. > > > > > > > > Laurent Laffont > > > > > > > > http://pharocasts.blogspot.com/ > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > > > > > Cheers, > > > > Alexandre > > > > > > > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > > > > > Hi, > > > > > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and > no tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta > image. > > > > > > > > > > Load it: > > > > > Gofer new > > > > > squeaksource: 'Autotest'; > > > > > package: 'Autotest'; > > > > > load > > > > > > > > > > Open it: > > > > > AutotestView open > > > > > (there's en entry in WorldMenu > Tools) > > > > > > > > > > And change a tested method to see the results. > > > > > > > > > > There's a bug I need to find, maybe someone knows: > > > > > - Change Bag>>occurrencesOf: > > > > > - Autotest gives: > > > > > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 > unexpected passes > > > > > Failures: > > > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > > > > > Errors: > > > > > CollectionRootTest>>#testBasicCollect > > > > > CollectionRootTest>>#testDoWithout > > > > > > > > > > but in SUnit CollectionRootTest gives > > > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes ?? > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Laurent Laffont > > > > > > > > > > http://pharocasts.blogspot.com/ > > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > > The idea is excellent. > > > > > > > > > > Cheers, > > > > > Alexandre > > > > > > > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > > > > You may have a lot of noise. > > > > > > > > > > > > > > I guess that Ruby uses files as a unit of > development/deployment. The closest Smalltalk/Pharo has is the class and the > package. > > > > > > > > > > > > > > I would suggest that TestCase which would use this feature use > some pragma/method to identify/declare which classes/packages this test > depends upon. Then the "autotest" framework would register such tests and > listen for changes in the given classes/packages, launching required tests > whenever a change happen. > > > > > > > > > > > > > > Additionally, one could declare such a pragma on a single test > method, when this test should be run for a specific class. > > > > > > > > > > > > > > Of course, you also to take care of long running tests, which > you probably want to exclude from auto-testing. > > > > > > > > > > > > I see autotest in Pharo in a slighly different way: When I press > save in the Monticello browser, I have a popup menu which asks me whether > (i) I want to run all the tests or (ii) only the tests that cover that I > changed from the last version. > > > > > > > > > > > > Does this make sense? > > > > > > > > > > > > Please no popup :) What I like in ruby autotest is that I can > quickly look at test results if I want (or not) without stop writing. Often > you want to see your tests failing, as you type / save code. I don't have to > stop writing, click a button, wait test results, go again.... testing is > done in background and I just see notifications whether it's OK or not. > > > > > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which > has the same name as the code file, but you can customize this behavior. For > autotest-rails: > > > > > > "A simplified version of Autotest heuristics in this mode would > be: > > > > > > When changing a test file, only this file is run (e.g. > test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > > > When changing a model file, only associated unit test file is run > (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > > > When changing a controller file, associated functional test file > is run (e.g.app/controllers/foo_controller.rb > âtest/functional/foo_controller_test.rb). > > > > > > When changing a fixture file, associated unit test and functional > test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb > +test/functional/foo_controller_test.rb). > > > > > > When changing a helper file, associated functional test file is > run (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > > > When changing application_helper.rb file all functional test > files are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > > > When changing a file under the config directory, all tests are > run." > > > > > > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > _______________________________________________ > > > > > > Pharo-project mailing list > > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > -- > > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > > 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 > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > 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 > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > 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 > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > 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 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 >

July 26, 2010

Re: [Pharo-project] cog-based image crashes on mac

by Lukas Renggli

>>> The image I got is based on the sources from 27.06.2010. >> >> You may be missing some image-side changes. The CogVM was open sourced on >> 20.06.2010. > > Actually, where should I get the complete image-side changes from? I have > those prepared by Lukas a while ago. Yeah, these are the complete ones from the repository adapted to Pharo. Maybe these same socket related crashes that randomly appear with Seaside images? nanosleep: Invalid argument Exited with exit code: 1 Lukas -- Lukas Renggli www.lukas-renggli.ch

July 26, 2010

Re: [Pharo-project] cog-based image crashes on mac

by Tudor Girba

Hi, On 25 Jul 2010, at 17:32, Levente Uzonyi wrote: > On Sun, 25 Jul 2010, Tudor Girba wrote: > >> Hi, >> >> I have been using the Cog VM exclusively for several months now, >> and from > > Did you get a VM from Teleplace before it was open sourced? No. I directly got the sources from SVN and compile them for Mac. Is there an official Cog VM compiled for Mac? >> time to time it crashes on me without leaving any trace in debug log. >> >> One frequent cause for the crash that I noticed is dealing with >> Monticello (both reading and writing). Does anyone experience >> similar things? Am I doing something wrong? > > IIRC this issue was fixed in VMMaker-oscog.17. I am not sure what this means :). >> The image I got is based on the sources from 27.06.2010. > > You may be missing some image-side changes. The CogVM was open > sourced on 20.06.2010. Actually, where should I get the complete image-side changes from? I have those prepared by Lukas a while ago. Cheers, Doru > Levente > >> >> Perhaps a more general idea: given that this VM brings an important >> improvement, do we want to have a more concerted effort to beta- >> test it? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "It's not how it is, it is how we see it." >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

July 26, 2010

[Pharo-project] [update 1.2] #12066

by Marcus Denker

12066 ----- Issue 2712: Once Issue 2715: remove three methods from Object: evaluateUnloggedForSelf, stringRepresentation, stringForReadout Issue 2529: FreeTypeFont>>veryDeepCopyWith: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 26, 2010

[Pharo-project] Reporting error to end users

by Alexandre Bergel

Hi! I feel that Object>>error: is a bit too low level. I tried to write a method errorEndUser: -=-=-=-=-=-=-=-=-=-=-=-= Object>>errorEndUser: aString "Open a end user friendly error notification" | answer | answer := UIManager default confirm: aString, String cr, String cr, 'Do you want to open a debugger?'. answer ifTrue: [ self error: aString ] ifFalse: [ Processor terminateActive ] -=-=-=-=-=-=-=-=-=-=-=-= But doing a Processor terminateActive freezes the image. I need to do a cmd-. to make it live again. Any idea how I can simply interrupt the current process without opening a debugger? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 26, 2010

Re: [Pharo-project] Comparing floats

by Alexandre Bergel

Excellent! Thanks! Cheers, Alexandre On 26 Jul 2010, at 10:29, Marcus Denker wrote: > > On Jul 26, 2010, at 10:24 AM, Alexandre Bergel wrote: > >> Hi! >> >> In one of my test, I want to check the equality of an array of floats. >> The following goes yellow: >> self assert: (service outgoingLinks collect: #bandwidth) asArray = #(0.876846926482685 14.7478812578828). >> >> But this one goes green: >> self assert: (service outgoingLinks collect: #bandwidth) asArray printString = '#(0.876846926482685 14.7478812578828)' . >> >> Any idea how I can avoid a conversion to strings? >> > > > there is a method #closeTo: on Float that compares in a way that should be ok for tests like this. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 26, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Serge Stinckwich

On Mon, Jul 26, 2010 at 2:05 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > 2010/7/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Sun, Jul 25, 2010 at 4:02 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >>> >>> Hm, the link doesn't work for me. I just get an empty response... >>> >> >> https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip >> >> works ok here > > Works ok for me also. > > 9764 tests, 9693 passes, 53 expected failures, 17 failures, 1 error > on Mac OS X 10.6.4. Most of the failures reported are inside RBSpellingRuleTest. > Tests like: > > testPerfectSentence > Â Â Â Â | result | > Â Â Â Â result := self checker > Â Â Â Â Â Â Â Â check: 'This is an english sentence without problems.'. > Â Â Â Â self assert: result isCollection. > Â Â Â Â self assert: result isEmpty > > could not work on my machine, because by default i'm using the french > speller ... > I made some modifications to switch the speller to english and came > back to the original language after the tests. I put my modifications > here: http://code.google.com/p/pharo/issues/detail?id=2714 > > After that all RBSpellingRuleTest are green. Hum in fact no ... there is still some problems. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 26, 2010