February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] missing cairo library in CI

by Peter UhnÃ¡k

I've personally solved it by forcing the job to run on "pharo-contribution-linux64-3" slave. There should be also at least one more slave that has cairo, but I don't remember the name. Peter On Sat, Feb 13, 2016 at 11:54 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > CI still can not find cairo library sometimes... > >> Error: Cannot locate cairo library. Please check if it installed on your >> system > > For example: > https://ci.inria.fr/pharo-contribution/job/Bloc/63/console > <https://ci.inria.fr/pharo-contribution/job/Bloc/63/console> > > > Cheers, > Alex >

Feb. 14, 2016

Re: [Pharo-dev] missing cairo library in CI

by Aliaksei Syrel

CI still can not find cairo library sometimes... > Error: Cannot locate cairo library. Please check if it installed on your > system For example: https://ci.inria.fr/pharo-contribution/job/Bloc/63/console <https://ci.inria.fr/pharo-contribution/job/Bloc/63/console> Cheers, Alex

Feb. 13, 2016

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

by stepharo

Yes I would even buy 20% coverage right now. Stef Le 13/2/16 20:22, Max Leske a Ã©crit : > 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

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