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

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

Re: [Pharo-project] isTransparent

by StÃ©phane Ducasse

On Nov 22, 2008, at 10:03 AM, Marcus Denker wrote: > Hi Stef, > Gwenael once posted this to the inbox: > SLICE-Object-isTransparent-GwenaelCasaccio.2 Yes I asked him to send me the file. Now he told me that he used lasy initialisation which to some extent may solve the problem. Now creating the rioght color is ok but my feeling is that there are too much messages send. So putting a beeper beep is really good to see that something strange is happening. Stef > > > Maybe that fixed the problem? He did not put a note in the > bugtracker, though. > And this means it got lost, I guess. > > Marcus > > > On 21.11.2008, at 22:28, StÃ©phane Ducasse wrote: > >> If you want to have fun >> >> do >> >> Object new setHaltOnce >> >> redefine >> >> Object>>isTransparent >> self haltOnce. >> Beeper beep. >> ^ false >> >> >> I found a kind of fix by initializing correctly SimpleBorder (my >> fix is not totally convincing yet since it crashed the image). >> SimpleBorder is used in BorderedSubpaneDividerMorph >> >> Now what is amazing to me is the number of time isTransparent is >> invoked >> on Object when just typing text, I think that there is bogus there. >> >> If one UI expert can have a look this would be great. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > 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 Norbert Hartl

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

Nov. 22, 2008

[Pharo-project] How to set the color of a gradient button ?

by Hilaire Fernandes

On button created with polymorph, like btn := self newButtonFor: self action: #openFinish label: 'J''ai fini !' help: 'Presse ce bouton lorsque tu as fini l''exercice'. ^ btn onColor: Color green muchLighter offColor: Color gray Changing the color does not work as expected. There are a couple of metod to change the color but none are working. Hilaire -- http://blog.ofset.org/hilaire

Nov. 22, 2008