November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] Rio File/Directory

by Keith Hodges

Just to let you guys know, A while back I did the work of moving Rio over to use classes File and Directory, and String>>asFile and String>>AsDirectory. I am tempted to leave it that way for now (i dont have time to do otherwise for a bit) since I do want to propose it as a standard thing that could be in Squeak/Pharo/Whatever. Code size stats: self compiledSize: 'File-Kernel'. 6906 (for Kernel Images) self compiledSize: 'File-Base'. 8215 (includes some ftp remote directory support) self compiledSize: 'Files-Directories'. 11471 self compiledSize: 'FileMan-Core'. 7098 self compiledSize: 'Network-RemoteDirectory'. 21481 regards Keith

Nov. 23, 2008

[Pharo-project] OB Button colors

by Torsten Bergmann

When loading polymorph with Watery2 theme and SuperOB using the ScriptLoader the buttons in OB tend to become green again after some clicking ... Bye Torsten -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Nov. 23, 2008

[Pharo-project] Alien FFI

by Torsten Bergmann

There is now a squeaksource project for Alien - the new FFI. See http://www.squeaksource.com/Alien.html -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Nov. 23, 2008

[Pharo-project] Seaside29 and pharo

by Torsten Bergmann

Since the pharo website [1] proposes that an important test for Pharo is running Seaside applications there is now a new Script Loader package 669 for loading Seaside 2.9/Comanche in the pharo inbox [2]. It's based on [3], but always loads newest Seaside packages. BTW: only one test failed so far WAColorTest>>testFromStringThreeDigit - which is OK according to [4]. Nice! Have fun Torsten [1] http://pharo.googlecode.com [2] http://www.squeaksource.com/PharoInbox.html [3] http://lists.squeakfoundation.org/pipermail/seaside-dev/2008-November/00187… [4] http://lists.squeakfoundation.org/pipermail/seaside-dev/2008-November/00198… -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Nov. 23, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by StÃ©phane Ducasse

Thanks a lot simon This is great to see that fixed and get this great icon support for our tests :) Stef On Nov 22, 2008, at 10:24 PM, Simon Denier wrote: > The new update in PharoInbox should deal with the previous problem: > - no more author popup when browsing some TestCase > - update test history after running tests from OB > > SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.6.mcz > > On 22 nov. 08, at 18:33, StÃ©phane Ducasse wrote: > >> Ok I see so in that case removing the authorname can be a good >> compromised >> >> Stef >> On Nov 22, 2008, at 4:02 PM, Simon Denier wrote: >> >>> >>> On 22 nov. 08, at 13:08, Adrian Lienhard wrote: >>> >>>> The reason is that TestCase class >> #methodChanged: is executed >>>> each time a method is modified or compiled and it then creates >>>> for each test case class a new dictionary that stores the author >>>> name (and if not set, this will trigger the popup). This >>>> dictionary is then stored in another dictionary in a class >>>> variable... >>> >>> Actually this is something related. Whenever you browse a TestCase >>> class, OB scans the test history to look for previous results. If >>> test results are not present, then an empty dictionary of results >>> is sent back. But this dictionary is still initialized with a >>> timestamp and the author name, so the name box can raise. >>> >>> Do we need the author name in test results? It's good for >>> traceability, but too much hassle. Easy to fix anyway. >>> >>>> >>>> >>>> Adrian >>>> >>>> On Nov 22, 2008, at 12:43 , StÃ©phane Ducasse wrote: >>>> >>>>> simon, alex and others >>>>> can you check why the author name is asked while it should not? >>>>> This is annoying and I would like to see that fixed. >>>>> >>>>> Stef >>>>> >>>>> On Nov 19, 2008, at 10:02 PM, Simon Denier wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> Just to notify a new enhancement to review in the PharoInbox. >>>>>> >>>>>> SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.2 >>>>>> >>>>>> >>>>>> Short doc: >>>>>> >>>>>> Add: >>>>>> - support history for test runs as well as progression filter >>>>>> to show test in progression, regression >>>>>> - support icons in OB to show the current state of a test: >>>>>> passed, failed, progressed, regressed... >>>>>> >>>>>> History support: >>>>>> - whenever some test cases run from the TestRunner, their >>>>>> results are stored in a class side variable TestResult >>>>>> class>>History >>>>>> - contextual menu for history in TestRunner>>error pane: >>>>>> 1) History: access submenu to TestRunner instance history: can >>>>>> save and show progress between results ran in the same >>>>>> TestRunner; lost when this particular instance of TestRunner is >>>>>> closed >>>>>> 2) Store results as progress reference: create/update a >>>>>> lastStoredRun method on the class side of each TestCase which >>>>>> have just been run, containing the results >>>>>> 3) Show progress: make a diff between the last run and the >>>>>> lastStoredRun, showing progress or regress in tests (new >>>>>> passed, new failures, new errors) >>>>>> >>>>>> The idea is that whenever you are satisfied with the current >>>>>> results of some of your tests, you can save this state as a >>>>>> reference point with the 'Store results...' action. >>>>>> This reference point can be compared with subsequent test >>>>>> results to show your progression or regression. >>>>>> >>>>>> Test results are stored in a class side variable some are kept >>>>>> local to your image. Reference results are stored in a special >>>>>> method for each TestCase, so that they are saved with their >>>>>> package and can be used as a common reference for package >>>>>> developers. So a good practice is to store the latest test >>>>>> results as reference before committing your changes. >>>>>> >>>>>> >>>>>> Icons support: >>>>>> OB Package browser now has icons for test methods in TestCase >>>>>> subclasses: >>>>>> - green circle: test has passed in the last run >>>>>> - red circle: test has failed >>>>>> - half green/half red circle: state unknown, test has no >>>>>> history or test has changed since last run >>>>>> - (no icon): test has raised an error >>>>>> - upside green arrow: test has progressed since last reference >>>>>> run >>>>>> - downside blue triangle: test has regressed since last >>>>>> reference run >>>>>> >>>>>> A test is in progression if it goes from error or failure to >>>>>> passed state. >>>>>> A test is in regression if it goes from passed to error or >>>>>> failure state. >>>>>> >>>>>> The last two icons have other meanings with methods not related >>>>>> to test, so we should change them whenever someone has better >>>>>> icons. >>>>>> >>>>>> Authors: Alexandre Bergel, Simon Denier, David RÃ¶thlisberger >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 22, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by Simon Denier

The new update in PharoInbox should deal with the previous problem: - no more author popup when browsing some TestCase - update test history after running tests from OB SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.6.mcz On 22 nov. 08, at 18:33, StÃ©phane Ducasse wrote: > Ok I see so in that case removing the authorname can be a good > compromised > > Stef > On Nov 22, 2008, at 4:02 PM, Simon Denier wrote: > >> >> On 22 nov. 08, at 13:08, Adrian Lienhard wrote: >> >>> The reason is that TestCase class >> #methodChanged: is executed >>> each time a method is modified or compiled and it then creates for >>> each test case class a new dictionary that stores the author name >>> (and if not set, this will trigger the popup). This dictionary is >>> then stored in another dictionary in a class variable... >> >> Actually this is something related. Whenever you browse a TestCase >> class, OB scans the test history to look for previous results. If >> test results are not present, then an empty dictionary of results >> is sent back. But this dictionary is still initialized with a >> timestamp and the author name, so the name box can raise. >> >> Do we need the author name in test results? It's good for >> traceability, but too much hassle. Easy to fix anyway. >> >>> >>> >>> Adrian >>> >>> On Nov 22, 2008, at 12:43 , StÃ©phane Ducasse wrote: >>> >>>> simon, alex and others >>>> can you check why the author name is asked while it should not? >>>> This is annoying and I would like to see that fixed. >>>> >>>> Stef >>>> >>>> On Nov 19, 2008, at 10:02 PM, Simon Denier wrote: >>>> >>>>> Hi all >>>>> >>>>> Just to notify a new enhancement to review in the PharoInbox. >>>>> >>>>> SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.2 >>>>> >>>>> >>>>> Short doc: >>>>> >>>>> Add: >>>>> - support history for test runs as well as progression filter to >>>>> show test in progression, regression >>>>> - support icons in OB to show the current state of a test: >>>>> passed, failed, progressed, regressed... >>>>> >>>>> History support: >>>>> - whenever some test cases run from the TestRunner, their >>>>> results are stored in a class side variable TestResult >>>>> class>>History >>>>> - contextual menu for history in TestRunner>>error pane: >>>>> 1) History: access submenu to TestRunner instance history: can >>>>> save and show progress between results ran in the same >>>>> TestRunner; lost when this particular instance of TestRunner is >>>>> closed >>>>> 2) Store results as progress reference: create/update a >>>>> lastStoredRun method on the class side of each TestCase which >>>>> have just been run, containing the results >>>>> 3) Show progress: make a diff between the last run and the >>>>> lastStoredRun, showing progress or regress in tests (new passed, >>>>> new failures, new errors) >>>>> >>>>> The idea is that whenever you are satisfied with the current >>>>> results of some of your tests, you can save this state as a >>>>> reference point with the 'Store results...' action. >>>>> This reference point can be compared with subsequent test >>>>> results to show your progression or regression. >>>>> >>>>> Test results are stored in a class side variable some are kept >>>>> local to your image. Reference results are stored in a special >>>>> method for each TestCase, so that they are saved with their >>>>> package and can be used as a common reference for package >>>>> developers. So a good practice is to store the latest test >>>>> results as reference before committing your changes. >>>>> >>>>> >>>>> Icons support: >>>>> OB Package browser now has icons for test methods in TestCase >>>>> subclasses: >>>>> - green circle: test has passed in the last run >>>>> - red circle: test has failed >>>>> - half green/half red circle: state unknown, test has no history >>>>> or test has changed since last run >>>>> - (no icon): test has raised an error >>>>> - upside green arrow: test has progressed since last reference run >>>>> - downside blue triangle: test has regressed since last >>>>> reference run >>>>> >>>>> A test is in progression if it goes from error or failure to >>>>> passed state. >>>>> A test is in regression if it goes from passed to error or >>>>> failure state. >>>>> >>>>> The last two icons have other meanings with methods not related >>>>> to test, so we should change them whenever someone has better >>>>> icons. >>>>> >>>>> Authors: Alexandre Bergel, Simon Denier, David RÃ¶thlisberger >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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 > -- Simon

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by John M McIntosh

Well I've not had a enough coffee to understand all the implications yet. (a) I wonder how fast getNextEvent is being called because that on some platforms calls aioPoll() to service socket interrupts. Some study will be required to understand the impact. (b) A smoke test of CPU usage shows that a pharo image with only the pharo graphic showing. runs with about 20% LESS CPU usage from an idle VM perspective. 1.8% of the cpu versus 2.2% for example. On 21-Nov-08, at 6:31 PM, Michael Rueger wrote: > Hi all, -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Michael Rueger

Igor Stasenko wrote: > A next stage, would be to refactor MorphicEvent & subclasses > and move them into category Kernel-Events > and then change EventSensor to convert raw events into nice XXXEvent > instances, so the rest of image wouldn't have to deal with raw event > buffers anymore. Yes, although a thought would be to add a separate API on the new sensor for fetching the "real" events and migrate the system over step by step. And for those events we might want to use the new event hierarchy from Miro and ySqueak, they turned out to be almost identical :-) Michael

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

I read it correctly :) Stef On Nov 22, 2008, at 7:46 PM, Michael Rueger wrote: > Michael Rueger wrote: > >> So one of the next things I will try to do is get Miro loaded into >> Morphic and also my ySqueak (formerly iSqueak) framework. But the >> latter > > into Pharo of course > > Need...more...caffeine.... > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

Indeed > >>>> I was wondering what kind of patterns the code to change was >>>> looking like. > > The big question is whether we really want to clean up Morphic as it > is or start putting in a new UI framework. The new input event > architecture allows us to plug in in other UI and event systems > without the need to touch Morphic. > So one of the next things I will try to do is get Miro loaded into > Morphic and also my ySqueak (formerly iSqueak) framework. But the > latter relies on a lot more system changes than Miro IIRC, so it > might take some time. Ok I know that alain was looking for a layout engine. Stef

Nov. 22, 2008