- Pharo-dev - lists.pharo.org

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

> StÃ©phane Ducasse wrote: >> so how do we proceed? >> We try to load it, play with it then? >> integrate it into pharo and you continue hacking and fixing? > > this version is really meant to be smoke tested, it needs some work > on the comments and on the user interrupt handling. Ok I will test it > > > So please load it into your images, make sure you always have > backups and see how it holds up. If it turns out to be reasonably > stable we can push it. > > >> 1- Here I have a question >> =================== >> in this comment EventSensor = InputEventSensor? > > the comment is only a copy from EventSensor, needs to be rewritten. > If somebody has a better suggestion for naming this class I'm open > to suggestions. > >> 2- I saw a method defined on Controller >> But there are no reference to this class in pharo. So we could >> remove Controller I imagine > > It is superclass of other classes, so I'm not sure. I will check. > > >> 3- could you tell me >> what kind of code we would have to change? > > Not sure what you mean? For now no code in the image needs to be > changed. I was already thinking about the next steps. I was wondering what kind of patterns the code to change was looking like. > > > > 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

On Nov 22, 2008, at 7:13 PM, Igor Stasenko wrote: > I just loaded your changeset and have something to report :) > > It looks like it having bigger poll periods than old sensor, or > works slower. > An overall performance feels a bit more sluggish comparing to old > implementation. > Just open a window with long text and hold down the up/down key and > see the difference. > Or try to resize browser window - you can notice its not so smooth as > in old image. I got the same feeling but I have the impression that it was less important than what igor reported. But I had the impression that everything was a bit slower > > > 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >> StÃ©phane Ducasse wrote: >>> >>> so how do we proceed? >>> We try to load it, play with it then? >>> integrate it into pharo and you continue hacking and fixing? >> >> this version is really meant to be smoke tested, it needs some work >> on the >> comments and on the user interrupt handling. >> >> So please load it into your images, make sure you always have >> backups and >> see how it holds up. If it turns out to be reasonably stable we can >> push it. >> >> >>> 1- Here I have a question >>> =================== >>> in this comment EventSensor = InputEventSensor? >> >> the comment is only a copy from EventSensor, needs to be rewritten. >> If somebody has a better suggestion for naming this class I'm open to >> suggestions. >> >>> 2- I saw a method defined on Controller >>> But there are no reference to this class in pharo. So we could >>> remove >>> Controller I imagine >> >> It is superclass of other classes, so I'm not sure. >> >>> 3- could you tell me >>> what kind of code we would have to change? >> >> Not sure what you mean? For now no code in the image needs to be >> changed. >> >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > _______________________________________________ > 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 Igor Stasenko

2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: > I just loaded your changeset and have something to report :) > > It looks like it having bigger poll periods than old sensor, or works slower. > An overall performance feels a bit more sluggish comparing to old > implementation. > Just open a window with long text and hold down the up/down key and > see the difference. > Or try to resize browser window - you can notice its not so smooth as > in old image. > ... which can be fixed easily by reducing poll period from 100ms to 10ms in InputEventPollingFetcher>>eventLoop > 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >> StÃ©phane Ducasse wrote: >>> >>> so how do we proceed? >>> We try to load it, play with it then? >>> integrate it into pharo and you continue hacking and fixing? >> >> this version is really meant to be smoke tested, it needs some work on the >> comments and on the user interrupt handling. >> >> So please load it into your images, make sure you always have backups and >> see how it holds up. If it turns out to be reasonably stable we can push it. >> >> >>> 1- Here I have a question >>> =================== >>> in this comment EventSensor = InputEventSensor? >> >> the comment is only a copy from EventSensor, needs to be rewritten. >> If somebody has a better suggestion for naming this class I'm open to >> suggestions. >> >>> 2- I saw a method defined on Controller >>> But there are no reference to this class in pharo. So we could remove >>> Controller I imagine >> >> It is superclass of other classes, so I'm not sure. >> >>> 3- could you tell me >>> what kind of code we would have to change? >> >> Not sure what you mean? For now no code in the image needs to be changed. >> >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Igor Stasenko

I just loaded your changeset and have something to report :) It looks like it having bigger poll periods than old sensor, or works slower. An overall performance feels a bit more sluggish comparing to old implementation. Just open a window with long text and hold down the up/down key and see the difference. Or try to resize browser window - you can notice its not so smooth as in old image. 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: > StÃ©phane Ducasse wrote: >> >> so how do we proceed? >> We try to load it, play with it then? >> integrate it into pharo and you continue hacking and fixing? > > this version is really meant to be smoke tested, it needs some work on the > comments and on the user interrupt handling. > > So please load it into your images, make sure you always have backups and > see how it holds up. If it turns out to be reasonably stable we can push it. > > >> 1- Here I have a question >> =================== >> in this comment EventSensor = InputEventSensor? > > the comment is only a copy from EventSensor, needs to be rewritten. > If somebody has a better suggestion for naming this class I'm open to > suggestions. > >> 2- I saw a method defined on Controller >> But there are no reference to this class in pharo. So we could remove >> Controller I imagine > > It is superclass of other classes, so I'm not sure. > >> 3- could you tell me >> what kind of code we would have to change? > > Not sure what you mean? For now no code in the image needs to be changed. > > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Michael Rueger

StÃ©phane Ducasse wrote: > so how do we proceed? > We try to load it, play with it then? > integrate it into pharo and you continue hacking and fixing? this version is really meant to be smoke tested, it needs some work on the comments and on the user interrupt handling. So please load it into your images, make sure you always have backups and see how it holds up. If it turns out to be reasonably stable we can push it. > 1- Here I have a question > =================== > in this comment EventSensor = InputEventSensor? the comment is only a copy from EventSensor, needs to be rewritten. If somebody has a better suggestion for naming this class I'm open to suggestions. > 2- I saw a method defined on Controller > But there are no reference to this class in pharo. So we could remove Controller I imagine It is superclass of other classes, so I'm not sure. > 3- could you tell me > what kind of code we would have to change? Not sure what you mean? For now no code in the image needs to be changed. Michael

Nov. 22, 2008

Re: [Pharo-project] OB package browser don't detects newpackages/updates a package list

by Igor Stasenko

2008/11/22 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > >>> You need to have your package defined as a Monticello package. Otherwise >>> it's just a class cat, which is visible it the 'unpackaged' package of >>> the >>> package browser. >>> Could you check if this is the case in your image? >>> >> >> That's the problem, its not visible anywhere, even in 'unpackaged' >> package! > > This is indeed strange. > Could you provide me with this image? > Just download a latest pharo-dev image. Then file-in (not through MC) a .st file which having a package not-yet existing in your image. And then try to find this package in package browser , or one of the classes in it. System browser sees it, package browser don't. > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by Igor Stasenko

2008/11/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > so how do we proceed? > We try to load it, play with it then? > integrate it into pharo and you continue hacking and fixing? > As soon as possible. I want to continue hacking hostwindows based on this new code. :) > Stef > On Nov 22, 2008, at 3:33 AM, Michael Rueger wrote: > >> >>> The event fetcher fetches events from the even and currently still >> >> from the VM that is >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 22, 2008

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

by StÃ©phane Ducasse

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 >

Nov. 22, 2008

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

by Simon Denier

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

Nov. 22, 2008

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

by StÃ©phane Ducasse

alex just told me that he will look into the author problem. Stef On Nov 22, 2008, at 3:39 PM, David RÃ¶thlisberger wrote: > >> I will let david integrate them. > > ok, I integrated OB-Enhancements-simon_denier.254.1.cs into OB- > Enhancements-dr.254. Thanks, Simon! > > Concerning running of a single test method: I think it would be very > useful if you could only update the results of this method without > erasing the other results. I mean technically this should be > possible to implement, it just a little bit complicate. Because the > usability suffers a lot when all other test methods of a test case > lose their results upon the run of new test method. > > Cheers, > David > >>>> >>>> On 21 nov. 08, at 10:17, StÃ©phane Ducasse wrote: >>>> >>>>> I have the not run green/red icons >>>>> but not the green ones when the tests are run. >>>>> Even if once it worked because I saw it. >>>>> Stef >>>> >>>> What Stef is talking about is the ability to run tests in the >>>> browser with the cmd-t shortcut. Indeed, test status is not >>>> updated in this case. Test status are only updated when ran >>>> through the *TestRunner*. But, it makes perfect sense that >>>> running tests through the browser should update the status. >>> >>> I have a very simple small patch to run tests with history from >>> the browser (one method send!). It works when running tests on a >>> package, a class or category. >>> >>> <OB-Enhancements-simon_denier.254.1.cs> >>> >>> >>> The running behavior when a single test method runs is different, >>> so there is a different patch, however I am not sure we want it: >>> running only one method will erase the previous test result for >>> the class, so you will have to run all tests again to see their >>> result (well the same is true if you only run a protocol and there >>> are tests in different protocols anyway, but this is a rarity) >>> >>> <OBCmdTestMethod.simon.denier.1.cs> >>> >>> >>> >>> >>> I will try to check why test classes ask for your name. >>> >>>> >>>> >>>> I can work out something. Any hint about how it works in OB? >>>> >>>> >>>> PS: I have been bothered by the password box being asked twice >>>> too. Worse, when I load both Polymorph and my slice, if I try to >>>> move the cursor to type in my name, it produces a new box, see >>>> screenshot. Be aware. >>>> >>>> <Picture 1.png> >>>> >>>>> >>>>> >>>>> On Nov 20, 2008, at 11:00 PM, David RÃ¶thlisberger wrote: >>>>> >>>>>> >>>>>>> Now I do not understand since when I run the tests the icons >>>>>>> do not change. >>>>>> Strange. So you always get the not run icon (circle with green >>>>>> and red)? >>>>>> For me this is not the case, the icons do change. Can you check >>>>>> whether it saved a history in the class variable of TestCase? >>>>>> >>>>>> david >>>>>>> Stef >>>>>>> >>>>>>> On Nov 20, 2008, at 8:17 PM, David RÃ¶thlisberger wrote: >>>>>>> >>>>>>>> >>>>>>>>> I loaded the fix of John for the menu >>>>>>>>> and the changes for SUnit icons and my image freshes when I >>>>>>>>> open the Package browser and run the tests >>>>>>>>> in 10162 >>>>>>>> >>>>>>>> which tests? All tests? >>>>>>>> >>>>>>>> David > > _______________________________________________ > 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