- Pharo-dev - lists.pharo.org

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

by David RÃ¶thlisberger

>> 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? David

Nov. 22, 2008

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

by David RÃ¶thlisberger

> 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

Nov. 22, 2008

[Pharo-project] Two points

by StÃ©phane Ducasse

Hi all I would like to stress two points: - I would like to see the code we are harvesting more tested. - but I would like that in alpha phase we continue to move on. So this is clearly difficult. In french we say that we cannot do an omelet without breaking eggs. Still I would like to stress two points: - I would like to see the code we are harvesting more tested. - but I would like that in not alpha phase we continue to move on. You know what I mean and we are trying to do our best. Now it means that people should also react fast to their submission feedback, which is the case since now. But we should continue but keeping in mind the two points above are important. In the beta phase we will not go at that pace and really stabilize the system. Then also we should favor improvement at the package level: for example the SUnit changes should in the future be really considered from the perspective of a external package improvement process. So a group of people can work on building a better SUnit (integrating/merging... keith improvement for example) and that we can build pharo-dev. Stef

Nov. 22, 2008

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

Hi mike I read the code with emacs (without chekcing the differences) 1- Here I have a question =================== in this comment EventSensor = InputEventSensor? I found it confusing to me especially when you know a little to the previous architecture and the the new one. !InputEventSensor commentStamp: 'mir 8/14/2008 14:16' prior: 0! An InputEventSensor is xxxxxxxxx. EventSensor is a replacement for InputSensor based on a set of (optional) event primitives. An EventSensor updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before, by moving the current VM mechanisms into EventSensor itself. An optional input semaphore is part of the new design. 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 3- could you tell me what kind of code we would have to change? So that I can evaluate the task? On Nov 22, 2008, at 3:31 AM, Michael Rueger wrote: > Hi all, > > finally got it. Turned out to be related to the host window/menu > work, the window index slot needed to be set to 1 if 0. > Sigh... > > Attached is a change set that installs the new logic into a recent > Pharo image. I'm not sure if and how we can get the install into a > package load, but this version is for the adventurous types > anyways :-) > > A few remarks about the new sensor architecture (need to put this > into the class comments). > > First what's not changed, which is the morphic side. HandMorph still > polls for nextEvent and also all old polling methods are still > supported and heavily used in the image. > > Basically the input event handling has been split into two parts: > one event fetcher and event handlers. > > The event fetcher fetches events from the even and currently still > polls. Next step will be to get the input semaphore signaling working. > > The event fetcher then signals the event to all registered event > handlers. In the current version there are two: > the new morphic sensor and the user interrupt handler. > > Events currently are handled multiple times (rather their copies), > we might need to change that later. > > There needs to be some work done on how the user interrupt handler > works, I had some problems with launching the debugger, but that > might have been a problem in my development image. > It would be helpful though, if the VM would provide information > about the interrupted process as it does (or should do?) for the low > space watcher. > > So much for now, questions welcome and happy testing :-) > > Michael > <new-sensor-mir.cs.gz>_______________________________________________ > 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

[Pharo-project] About nile

by StÃ©phane Ducasse

Hi I would like to have Nile in the image because I want to get rid of the old stream implementations slowly migrating the missing parts slowly to nile and I'm afraid that we lose the great work on damienC. I tried to harvest yesterday the item related to the back broken behavior in stream hierarchy but too much changes already happened. I could not find my way and lost time. I asked damien to help me but this is a sign. The plan could be to have Nile in Pharo-Dev for a couple of milestone and at a point switch (remove the old stream hierarchy and replace it by Nile). Also with DamienP we wrote more tests on collections and traits are really working great for that. Really! I imagine that we will have a really good test basis for the collections soon and that with Nile in the image I can improve the test coverage of Streams. I should say that I really fed up with some of the code aspects of Squeak (fileout of classes for example is a huge mess, file/directory....). Stef

Nov. 22, 2008

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

by StÃ©phane Ducasse

I really want to clean the author code and related but I want to focus on etoy cleaning and finish. > yes, popups in the update process should be avoided (else this will > kill an automated process). > > In this case 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... is this really what we want/need? > > Anyway, looking at the code of Author I also noticed that we now > have already _three_ ways of accessing singletons. We had the > following two (which I can never remember): > > SmalltalkImage current > SystemNavigation default > > And now also: > Author uniqueInstance may be for this one we could use the singleton internal and propose some class methods to have a better interface. > > > It would be nice to have some code conventions (also on the > formating) and that we try to keep an eye on the quality of the code > that gets introduced in the image. For example, the following method > I consider a bad smell: > > Author>>#initials: aString > initials := aString. > "Case of being reset due to, eg, copy of image." > aString isEmpty ifTrue: [name := ''] > > It looks like a normal accessor but has a side effect on another > variable under some conditions. There should be another method #reset. This initials and name stuff were wrong in Utilities and they are wrong in authors. Stef > > > Adrian > ___________________ > http://www.adrian-lienhard.ch/

Nov. 22, 2008

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

by StÃ©phane Ducasse

ok so hat what would be the solution? Stef On Nov 22, 2008, at 1:08 PM, 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... > > 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 >

Nov. 22, 2008

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

by Adrian Lienhard

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... 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

Nov. 22, 2008

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

by StÃ©phane Ducasse

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 >

Nov. 22, 2008

Re: [Pharo-project] List of Type entry

by StÃ©phane Ducasse

On Nov 22, 2008, at 11:38 AM, Norbert Hartl wrote: > For me the only obvious types are > > Type-Defect - Bug, soon to be fixed > Type-Enhancement - Nice to have, not decided if and when to include > > I'm not clear about these: > > Type-Patch I thought is was a fix. > Type-Mantis something to harvest from mantis > Type-Squeak > > I created them but I'm not sure if it is a good idea to have > the source of the patch inside the type. I started to add for > every mantis issue (Mxxxx) at the end of the Ticket subject. This > way it is easier to track what changes are included. And maybe this > makes Type-Mantis obsolete. What do you think? > > Type-Task > Type-ToDo > > are the same thing for me. And I don't like todo because it is > used for everything. I would keep Type-Task. Fpr me todo is an invitation for other programmers to help fixing a larger task than just a fix. This is Request for Enhancement. > > Type-Other I removed it. I rephrase the type. Can you check? > > > is evil to me. It does not serve any purpose other to collect cruft. > > Type-NextMilestone > > I would like to see that google code offers something better than > this. The next milestone is ambiguous and you have to touch every > ticket once the next milestone is reached. I fine with it but I'm > not sure those actions are taken seriously. I'll have a look at that. Yes I try to see but I could not find anything. > > > First thoughts, > > Norbert >>> Type-Defect = Report of a software defect >>>> Type-Enhancement = Request for enhancement >>>> Type-Task = Work item that doesn't change the code or docs >>>> Type-Patch = Source code patch for review >>>> Type-Mantis = Ticket on bugs.squeak.org to integrate >>>> Type-Squeak = Squeak version to integrate >>>> Type-Other = Some other kind of issue >>>> Type-ToDo = To list some todo for the coming versions >>>> Type-NextMilestone = To remember some actions for the next >> >> > On Fri, 2008-11-21 at 12:47 +0100, StÃ©phane Ducasse wrote: >> Yes please suggest what we can do >> >> Tasks -Work item that doesn't change the code or docs >> Todo was related to code >> and I would remove other because looks like a trashcan >> >> Stef >> >> On Nov 21, 2008, at 11:14 AM, Norbert Hartl wrote: >> >>> On Thu, 2008-11-20 at 21:34 +0100, StÃ©phane Ducasse wrote: >>>> Hi guys >>>> >>>> I added two type entries >>>> >>>> Type-Defect = Report of a software defect >>>> Type-Enhancement = Request for enhancement >>>> Type-Task = Work item that doesn't change the code or docs >>>> Type-Patch = Source code patch for review >>>> Type-Mantis = Ticket on bugs.squeak.org to integrate >>>> Type-Squeak = Squeak version to integrate >>>> Type-Other = Some other kind of issue >>>> Type-ToDo = To list some todo for the coming versions >>>> Type-NextMilestone = To remember some actions for the next >>>> milestones >>>> >>>> I would like that we used them to sort well the items >>> >>> What's the difference between task and todo? I find todo >>> always too generic. "Others" is the same for me. That places >>> are supposed to collect cruft :) I'm just arguing because >>> I'm confident that less categories is better most of the >>> times. >>> >>> Norbert >>> >>> >>> _______________________________________________ >>> 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 >

Nov. 22, 2008