- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] More tests for new frameworks

by Peter UhnÃ¡k

On Sat, Feb 13, 2016 at 8:22 PM, Max Leske <maxleske(a)gmail.com> wrote: > How about enforcing coverage? I know that coverage tests donât say > anything about the quality of the test cases but itâs (almost) always > better to have some tests than none. I wouldnât set the bar too high either > for coverage, maybe 60 or 70%. 100% is unrealistic, but 60 to 70 should be > achievable with a couple of well written tests. > > Of course we would need a way to run coverage tests on the test suite. Do > we have a tool for coverage tests? > Yes, there's Hapao http://objectprofile.com/Hapao.html you can install it from Catalog Browser under the name "Spy2". (There's more to Spy2, but Hapao is included.) So maybe CI could run the coverage and issue a warning if it is under a certain threshold, however the doesn't really cover adding new features (e.g. project has 80% coverageâ¦ new untested features are added, coverage drops to 75% and nobody notices). Peter

Feb. 13, 2016

Re: [Pharo-dev] More tests for new frameworks

by Max Leske

How about enforcing coverage? I know that coverage tests donât say anything about the quality of the test cases but itâs (almost) always better to have some tests than none. I wouldnât set the bar too high either for coverage, maybe 60 or 70%. 100% is unrealistic, but 60 to 70 should be achievable with a couple of well written tests. Of course we would need a way to run coverage tests on the test suite. Do we have a tool for coverage tests? > On 13 Feb 2016, at 19:35, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > with damien cassou we had an interesting discussion. Basically we are teaching tests and we see that many Pharo subsystems are not really well tested. I wonder how we can change this. For example, we will have a new graphical core without any tests > and this is sad because tests could be really good to make sure that we will be able to move forward in the future. > I would like to get tests for Ring. > > Stef > > >

Feb. 13, 2016

More tests for new frameworks

by stepharo

Hi guys with damien cassou we had an interesting discussion. Basically we are teaching tests and we see that many Pharo subsystems are not really well tested. I wonder how we can change this. For example, we will have a new graphical core without any tests and this is sad because tests could be really good to make sure that we will be able to move forward in the future. I would like to get tests for Ring. Stef

Feb. 13, 2016

Re: [Pharo-dev] [Vm-dev] Termination semaphore for Process

by Max Leske

Thanks Eliot. Nice idea to return the result. What didnât work for me was to only suspend the process in #forBlock:priority:. I had to send #terminate instead. There are two main reasons: 1. #isTerminating (not #isTerminated) will not be correctly set if #terminate hasnât been sent 2. when signalling the semaphore I want *all* processes that are waiting to be signalled so that the terminating process canât be preempted while signalling the semaphore. Otherwise it may resume a higher priority process that will not allow the other processes still waiting on the semaphore to run. To do this I have to use different approaches for active and inactive processes, such that #isTerminated is always true when the termination semaphore has been signalled. Iâd appreciate it if you could take a look. Maybe youâll spot something I could have done better. Cheers, Max Fogbugz issue: https://pharo.fogbugz.com/f/cases/17588/Termination-semaphore-for-Process > On 12 Feb 2016, at 19:35, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Fri, Feb 12, 2016 at 6:59 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > Hi all, > > I have a proposal and Iâd like to hear your opinion. > > Right now, when I want to wait for a process to finish I use something like #forkAndWait or I write a block with semaphores myself. This works fine for processes that I spawn and then immediately want to wait for. But what if I spawn a process somewhere else and only later know that I want to wait for its termination? Currently I would construct a polling loop to do that. > > Hereâs a different idea (which Iâve tested): > > 1. add instance variable âterminationSemaphoreâ to Process > 2. at the end of Process>>terminate #ensure: that all waiting processes are signaled > 3. add #waitForTermination message to Process: > > waitForTermination > terminationSemaphore ifNil: [ terminationSemaphore := Semaphore new ]. > self resume. > terminationSemaphore wait > > > > This enables code like the following: > > result := 0. > p := [ result := 2. 2 seconds asDelay wait ] newProcess > priority: 20; > yourself. > > âdonât run the new process yet" > [ p waitForTermination. result2 := 3. ] forkAt: 30. > âp is now running, the second process is waiting" > > p waitForTermination. > âp is still running, two processes are waitingâ > > âbecause processes waiting on a semaphore are signaled in the order > they sent #wait we even achieve ordering (at least with equal process > priorities) and so âresult2â is not nil but 3â > > {result. result2} â#(2 3) > > > I wrote this in 10 minutes, so thereâs room for polishing. I just want to know if this is something other people might want and if there are potential problems with process termination and semaphores which I am not aware of. > > Seems very nice. But why not add both terminationSemaphore and result? So we have > > Process class methods for instance creation > forBlock: aBlockClosure priority: anInteger > "Answer an instance of me that has suspended aContext at priority anInteger." > > <primitive: 19> "Simulation guard" > | newProcess | > (newProcess := self new) > suspendedContext: > [newProcess result: aBlockClosure value. > newProcess terminationSemaphore ifNotNil: [:ts| ts signal]. > "Since control is now at the bottom there is no need to terminate (which > runs unwinds) since all unwinds have been run. Simply suspend. > Note that we must use this form rather than e.g. Processor suspendActive > so that isTerminated answers true. isTerminated requires that if there is a > suspended context it is the bottom-most, but using a send would result in > the process's suspendedContext /not/ being the bottom-most." > newProcess suspend] asContext; > priority: anInteger. > ^newProcess > > BlockClosure methods for scheduling > newProcess > "Answer a Process running the code in the receiver. The process is not scheduled." > ^Process forBlock: self priority: Processor activePriority > > Process methods for termination > waitForTermination > terminationSemaphore ifNil: [ terminationSemaphore := Semaphore new ]. > self resume. > terminationSemaphore wait. > ^result > > and hence > > ((1 to: 3) collect: [:i| [(Delay forSeconds: i) wait. i] forkAt: Processor activePriority - 1]) collect: [:p| p waitForTermination] #(1 2 3) > > > [find attached, leaving BlockClosure>>newProcessWith: as an exercise for the reader ;-) ] > > _,,,^..^,,,_ > best, Eliot > <waitForTermination.st>

Feb. 13, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by stepharo

Alain is lost somewhere on vacation without internet or something like that :) Le 12/2/16 22:38, Nicolai Hess a Ã©crit : > > In short, whatever way you look at it, this initialization > difficulty is a hard problem. > > Morphic makes it a bit harder than expected because a Morph can be > considered as active as soon as it is created, not just when it > has been opened in the world. > > > Here is an example: > > |t| > t:=TextModel new. > t text:'hello'. > t openWithSpec. > t hasUnacceptedEdits > > it shows that our text has unaccepted edits, although the text did not > change. ( and there is actually no text decoration indicating this state). > > I tried to follow the trace from #openWithSpec to the call that sets > #hasUnacceptedEdits:true. > I don't think this is a problem of "initialization is difficult" but a > problem of pluging rubric text components as widgets for spec. > The way spec-models are working and the way rubric works, just don't > fit well. > > (see issue > 16873Adding a new Method marks current entry in SendersOf > MessageBrowser as dirty > for another example. The cause is that rubric somehow changes this > "hasUnacceptedEdits state" when the text actually *did not change*. > And this > again is difficult to trace down. And I don't know how to fix this. > > Help appreciate

Feb. 13, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by stepharo

> > > 2016-02-09 13:46 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi nicolai > > I agree. I will have a look at the Calipso experience of Alain. > Because may be Calipso + Spec layout format would be much nicer. > Did you look at it? > > > I could not find anything about Calipso, what is it? http://smalltalkhub.com/#!/~AlainPlantec/Calypso Stef > > Alain just brainstormed but this is interesting for thinking. > > Stef > > What I hate also is that the > > AbstractApdate>>update: aSymbol > > self changed: aSymbol > > This is a bit terrible because the adpater should not exist at > runtime > and adapter should just encapsulate how to create and set the > communication > between the model and the view. Now it is in the middle and this > is not good. > > stef > > > Le 8/2/16 11:31, Nicolai Hess a Ã©crit : >> >> >> 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>>: >> >> Hi guys >> >> I should say that I'm sick (gift from my little boy) so may >> be this is obvious. >> >> I'm looking at the code of Spec and I hate this code :) >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> >> I do not see why widgetDo: has to test for nil >> So I transformed >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> into >> >> >> widgetDo: aBlock >> >> ^ aBlock cull: self widget >> >> BTW I hate all the cull: call. They are connected with >> sloppiness). It is far too easy to use cull: >> I do not know how many arguments, I do not care I use cull: >> cull: is slow slow and help producing messing API. >> >> And it broke. The methodBrowser example did not work anymore >> and many others. >> Debugger felt down.... >> I feel sad. Now my brain is dead so I cannot concentrate more. >> >> >> Stef >> >> >> This is a big problem with morphic/spec ui elements. You never >> know for sure >> what code this >> self update ---> search through all (dynamicly added) dependents >> and notify >> will finally call. >> In this example we are about to *built* the widgets and in this >> run , we change a component that >> will update all dependents goes back and forth between model, >> adapter and widget. And all >> before the widget is actually accessible for the widgetDo: call. >> >> (and, REALLY we need to clean this up. This is really bad code if >> we announce a textChanged announcement for >> a text component, if we *initialize* an *empty textcomponent* >> with an *empty text*!). >> >> > >

Feb. 13, 2016

[UpdatedPharoByExample] Collection chapter

by stepharo

Hi guys here is a new chapter for UpdatedPharoByExample. Stef

Feb. 13, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Nicolai Hess

2016-02-08 15:02 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>> Hi guys >>> >>> I should say that I'm sick (gift from my little boy) so may be this is >>> obvious. >>> >>> I'm looking at the code of Spec and I hate this code :) >>> >>> widgetDo: aBlock >>> >>> ^ self widget ifNotNil: aBlock >>> >>> >>> I do not see why widgetDo: has to test for nil >>> So I transformed >>> >>> widgetDo: aBlock >>> >>> ^ self widget ifNotNil: aBlock >>> >>> into >>> >>> >>> widgetDo: aBlock >>> >>> ^ aBlock cull: self widget >>> >>> BTW I hate all the cull: call. They are connected with sloppiness). It >>> is far too easy to use cull: >>> I do not know how many arguments, I do not care I use cull: >>> cull: is slow slow and help producing messing API. >>> >> > aBlock value: value: value: > > does not much better than cull:, imho. Usually, the api documentation of > the block are just what you'll find in existing code, nothing else. > > >> >>> And it broke. The methodBrowser example did not work anymore and many >>> others. >>> Debugger felt down.... >>> I feel sad. Now my brain is dead so I cannot concentrate more. >>> >>> >>> Stef >>> >>> >> This is a big problem with morphic/spec ui elements. You never know for >> sure >> what code this >> self update ---> search through all (dynamicly added) dependents and >> notify >> will finally call. >> > > I don't think there is any way around it. You have to decouple view(s) > from model(s), and, hence have those propagation constraints by way of > notifications. > > Of course, a true alternative would be to use a proper propagation > constraint system... > > >> In this example we are about to *built* the widgets and in this run , we >> change a component that >> will update all dependents goes back and forth between model, adapter and >> widget. And all >> before the widget is actually accessible for the widgetDo: call. >> >> (and, REALLY we need to clean this up. This is really bad code if we >> announce a textChanged announcement for >> a text component, if we *initialize* an *empty textcomponent* with an >> *empty text*!). >> > > In short, whatever way you look at it, this initialization difficulty is a > hard problem. > > Morphic makes it a bit harder than expected because a Morph can be > considered as active as soon as it is created, not just when it has been > opened in the world. > Here is an example: |t| t:=TextModel new. t text:'hello'. t openWithSpec. t hasUnacceptedEdits it shows that our text has unaccepted edits, although the text did not change. ( and there is actually no text decoration indicating this state). I tried to follow the trace from #openWithSpec to the call that sets #hasUnacceptedEdits:true. I don't think this is a problem of "initialization is difficult" but a problem of pluging rubric text components as widgets for spec. The way spec-models are working and the way rubric works, just don't fit well. (see issue 16873Adding a new Method marks current entry in SendersOf MessageBrowser as dirty for another example. The cause is that rubric somehow changes this "hasUnacceptedEdits state" when the text actually *did not change*. And this again is difficult to trace down. And I don't know how to fix this. Help appreciate > > Thierry > >

Feb. 12, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Tudor Girba

Thanks. I went over the commits. As I said in the issue, it seems that using a shortcut like arrow + meta + shift does not work on Mac. Any idea why? In the meantime, I reverted the problematic shortcuts from Spotter (for example, dive in category). Cheers, Doru > On Feb 10, 2016, at 3:17 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Cool, thanks! (I thought nobody had read that part of the email because of the flood of answers :)) > > Doru, I made the following commits to the Glamour and GToolkit repositories. I let you manage the integration/merge/configurations. If you have any comments, go on ^^ > > Name: Glamour-Core-GuillermoPolito.312 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:00.429222 pm > UUID: 7b5e7388-3e60-4500-ad80-8fa51e3e55c3 > Ancestors: Glamour-Core-AndreiChis.311 > > Coherent Shortcuts - big pass > > > > Name: GT-Spotter-GuillermoPolito.356 > Author: GuillermoPolito > Time: 10 February 2016, 3:08:08.471892 pm > UUID: 92142dbd-9a1e-461f-a1f8-5716d85be62a > Ancestors: GT-Spotter-AliakseiSyrel.355 > > Coherent Shortcuts - big pass > > > > Name: Glamour-Morphic-Widgets-GuillermoPolito.190 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:06.355081 pm > UUID: 1dd0f9e4-9776-4eb5-b449-ea21e9c1cd24 > Ancestors: Glamour-Morphic-Widgets-AndreiChis.189 > > Coherent Shortcuts - big pass > > > > Name: Glamour-Tests-Morphic-GuillermoPolito.136 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:00.874947 pm > UUID: ba1deabc-2e70-4a7d-bd91-55be918ee0bb > Ancestors: Glamour-Tests-Morphic-EstebanLorenzano.135 > > Coherent Shortcuts - big pass > > > > Name: Glamour-Tests-Rubric-GuillermoPolito.20 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:05.73715 pm > UUID: 6d6e6bcf-8ead-4492-9aef-fa582417b1f9 > Ancestors: Glamour-Tests-Rubric-AndreiChis.19 > > Coherent Shortcuts - big pass > > > > On 02/09/2016 11:32 PM, Tudor Girba wrote: >> Thanks Stephan :). >> >> @Guille: Stephan just added you to the SmalltalkHub repository. >> >> Could you ping me when you commit so that I can review? >> >> Cheers, >> Doru >> >> >>> On Feb 9, 2016, at 11:25 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> On 09/02/16 15:50, Guille Polito wrote: >>>> Also, I did some changes in Glamour and GTSpotter, but I have no >>>> permissions to commit there. How do we do to commit in those packages? >>>> Should I ask for permissions or is there any other process in place? >>> There's a magical process by which you complain in the mailing list and then suddenly are able to commit. >>> >>> Stephan >>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Feb. 12, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Nicolai Hess

2016-02-09 13:46 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi nicolai > > I agree. I will have a look at the Calipso experience of Alain. > Because may be Calipso + Spec layout format would be much nicer. > Did you look at it? > I could not find anything about Calipso, what is it? > Alain just brainstormed but this is interesting for thinking. > > Stef > > What I hate also is that the > > AbstractApdate>>update: aSymbol > > self changed: aSymbol > > This is a bit terrible because the adpater should not exist at runtime > and adapter should just encapsulate how to create and set the > communication > between the model and the view. Now it is in the middle and this is not > good. > > stef > > > Le 8/2/16 11:31, Nicolai Hess a Ã©crit : > > > > 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> I should say that I'm sick (gift from my little boy) so may be this is >> obvious. >> >> I'm looking at the code of Spec and I hate this code :) >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> >> I do not see why widgetDo: has to test for nil >> So I transformed >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> into >> >> >> widgetDo: aBlock >> >> ^ aBlock cull: self widget >> >> BTW I hate all the cull: call. They are connected with sloppiness). It is >> far too easy to use cull: >> I do not know how many arguments, I do not care I use cull: >> cull: is slow slow and help producing messing API. >> >> And it broke. The methodBrowser example did not work anymore and many >> others. >> Debugger felt down.... >> I feel sad. Now my brain is dead so I cannot concentrate more. >> >> >> Stef >> >> > This is a big problem with morphic/spec ui elements. You never know for > sure > what code this > self update ---> search through all (dynamicly added) dependents and notify > will finally call. > In this example we are about to *built* the widgets and in this run , we > change a component that > will update all dependents goes back and forth between model, adapter and > widget. And all > before the widget is actually accessible for the widgetDo: call. > > (and, REALLY we need to clean this up. This is really bad code if we > announce a textChanged announcement for > a text component, if we *initialize* an *empty textcomponent* with an > *empty text*!). > > > >

Feb. 12, 2016