- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] pharo-minimal-vm

by stepharo

We are interested about that with guillermo ;) Le 5/2/16 05:08, Ben Coman a Ã©crit : > Is there a minimal-VM that can be used to run the minimal-IMAGE [1] ? > It would be nice for [1] to include an a step.... > PharoVMBuilder buildUnix32minimal. > since the VM is also part of "how small can we go". > > My reason for asking is that also less generated VM code might shorten > the edit-compile-run loop when I try porting the VM to a Xen Rump > kernel > > Also nice would be an example of how to invoke the tests in a minimal > image from the commandline. > > cheers -ben > > [1] https://github.com/pharo-project/pharo-minimal-scripts > >

Feb. 6, 2016

Re: [Pharo-dev] Recent changes in Bloc, no more BlMorph

by stepharo

Stefan I do not know if you have commit right, if so do it. Stef Le 5/2/16 12:17, Stephan Eggermont a Ã©crit : > On 05-02-16 11:03, Aliaksei Syrel wrote: >> Shortly saying, everything :) > > That would have been a good moment to update the version/baseline in > the configuration to make it easy to notice such things. People have > started building applications on top of bloc... > chicoary / SmallFBP > > Stephan > > >

Feb. 6, 2016

Re: [Pharo-dev] Recent changes in Bloc, no more BlMorph

by stepharo

Le 5/2/16 13:51, Sean P. DeNigris a Ã©crit : > Aliaksei Syrel wrote >> Root element is BlElement. No more BlView. Added BlShape and BlPath. > Would you summarize that design decision? oh boy: 50 emails, chat over skype, visit of aleksei to Brest during 3 days, breaking Bloc core.... So alex can try :) Stef > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Recent-changes-in-Bloc-no-more-BlMorph-tp4875999p4876… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Feb. 6, 2016

[bloc] a little demo

by stepharo

Hi guys aleksei, glenn, alain shaked deeply bloc and slowly bloc is getting backing shape. We are moving now the discussions to the pharo-dev mailing-list https://drive.google.com/file/d/0B-bMBVDOi3oTTDBxNmdfS0o3S3c/view?pref=2&pl…

Feb. 6, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Ben Coman

On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > In fact, this integration step > (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z) was > already passed by Epicea in December. That was before spur, it might be > related to spur. > > That time, the integration of Epicea revealed a bug in delay's scheduling... Was that these issues integrated in build 50466... https://pharo.fogbugz.com/default.asp?17066 https://pharo.fogbugz.com/default.asp?13756 which should have left the current scheduler as DelayExperimentalSpinScheduler but in current build 50564 "Delay delaySchedulerClass" --> DelayMicrosecondScheduler Maybe Delay class >> initialize has been executed since Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. Scheduler := DelayMicrosecondScheduler new. Scheduler startTimerEventLoop. Smalltalk addToStartUpList: self. but I don't see any updates that might have invoked it. Anyway, maybe changing that will help. cheers -ben > maybe now it's revealing some bug in Windows+spur...? > > Martin > > > On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: >> >> If you remove any line, it stops crashingâ¦ >> >> I really donât know what is going onâ¦ >> >> >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Henrik Nergaard >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 14:03 >> >> >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> Removing >> >> #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: >> visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: >> visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: >> visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: >> visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: >> visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: >> visitSend: )) >> >> And it stops crashing. >> >> >> >> - BTW, there is not crash.dmp, does it works with spur? >> >> >> https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… >> >> >> >> Best regards, >> >> Henrik >> >> >> >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Blondeau Vincent >> Sent: Friday, February 5, 2016 1:54 PM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >> [ANN] We are in "code freeze" for Pharo 5) >> >> >> >> Very strange bug indeed that happens on windows machines that crashes the >> VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ >> >> Can someone have the same issue under Windows or Mac? >> >> >> >> To reproduce : Copy paste the contents of the attached file in the >> playground and print it or do it >> >> It works on pre-spur vm. >> >> >> >> BTW, there is not crash.dmp, does it works with spur? >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Marcus Denker >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> >> >> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >> I will try do integrate it nowâ¦ >> >> >> >> >> >> >> >> No, it still fails. >> >> >> >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… >> >> >> >> The last test it executed seems to be this: >> >> running suite: Refactoring-Tests-Environment >> >> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... >> >> Very strange... >> >> Marcus >> >> >> >> >> >> ________________________________ >> >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As its >> integrity cannot be secured on the Internet, the Worldline liability cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> ________________________________ >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As its >> integrity cannot be secured on the Internet, the Worldline liability cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. > >

Feb. 6, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Martin Dias

In fact, this integration step ( https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z <https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe…>) was already passed by Epicea in December. That was before spur, it might be related to spur. That time, the integration of Epicea revealed a bug in delay's scheduling... maybe now it's revealing some bug in Windows+spur...? Martin On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: > If you remove any line, it stops crashingâ¦ > > I really donât know what is going onâ¦ > > > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *De la part > de* Henrik Nergaard > *EnvoyÃ© :* vendredi 5 fÃ©vrier 2016 14:03 > > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > Removing > > #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: > visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: > visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: > visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: > visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: > visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: > visitSend: )) > > And it stops crashing. > > > > - BTW, there is not crash.dmp, does it works with spur? > > > https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… > > > > Best regards, > > Henrik > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *On Behalf Of *Blondeau Vincent > *Sent:* Friday, February 5, 2016 1:54 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > Very strange bug indeed that happens on windows machines that crashes the > VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ > > Can someone have the same issue under Windows or Mac? > > > > To reproduce : Copy paste the contents of the attached file in the > playground and print it or do it > > It works on pre-spur vm. > > > > BTW, there is not crash.dmp, does it works with spur? > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *De la part de* Marcus Denker > *EnvoyÃ© :* vendredi 5 fÃ©vrier 2016 13:01 > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > > > On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > I will try do integrate it nowâ¦ > > > > > > > > No, it still fails. > > > > > https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… > > > > The last test it executed seems to be this: > > running suite: Refactoring-Tests-Environment > > starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... > > Very strange... > > Marcus > > > > > ------------------------------ > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Feb. 6, 2016

Re: [Pharo-dev] [Vm-dev] Where to get Monitor implementation based on primitives?

by Ben Coman

On Fri, Jan 8, 2016 at 9:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > > btw, Looking at the following... > CriticalSection>>critical: aBlock > ^self primitiveEnterCriticalSection > ifTrue: [aBlock value] > ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] > > without intimate VM knowledge but seeing Eliot recently say > "invocations of methods with primitives [...] are not suspension > points, unless their primitives fail" -- I'm paranoid that since > #ensure: primitive 198 always fail, there might be some some small > window for a race where a process might be terminated before > #primitiveExitCriticalSection can be executed. I'll take a refutation > of this to improve the method comment. > > The following instils more confidence... > > CriticalSection2>>critical: aBlock > | reEntered | > reEntered := false. > [ reEntered := self primitiveEnterCriticalSection. > aBlock value ] ensure: > [ reEntered ifFalse: [ self primitiveExitCriticalSection] ] Having spent more time considering this, I found I was off track here. If a process waiting at #primitiveEnterCriticalSection is terminated, then #primitiveExitCriticalSection is erroneously executed. And it will be the same problem with the proposal for Case17373 based on OwnedLock>>acquire Mutex>>critical: aBlock | lockAcquiredNotHere | <lockAt: #lock tracksStateAt: 1> lockAcquiredNotHere := true. ^[ lockAcquiredNotHere := false. lockAcquiredNotHere := lock acquire. aBlock value ] ensure: [lockAcquiredNotHere ifFalse: [lock release]]. So now I believe the original #critical: proposed by Eliot is optimal. * If #primitiveEnterCriticalSection is terminated while waiting, then the #ifFalse: is never executed. * When #primitiveEnterCriticalSection returns, the inlined #ifTrue:ifFalse cant be interrupted. * #ensure is a primitive which can't be interrupted. By the time it has done its usual "fail", which I raised concern over, actually it has already done its job to make sure #primitiveExitCriticalSection is executed.

Feb. 6, 2016

Re: [Pharo-dev] [Vm-dev] Simple versus Recursive Mutexes

by Ben Coman

On Fri, Feb 5, 2016 at 1:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Feb 3, 2016 at 2:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Ben, >> >> On Tue, Feb 2, 2016 at 9:54 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> While we are in the process of revising the Mutex infrastructure [1] >>> to use dedicated primitives rather than rely on counting via a >>> semaphore, I want to raise the question of simple versus recursive >>> mutexes. >>> >>> This isn't something I know much about, except that some people >>> strongly believe recursive mutexes are evil, including David Butenhof >>> who apparently was the guy who added recursive mutexes to POSIX "on a >>> dare [...] but nobody was supposed to use recursive mutexes." [1]. >>> >>> There are two interesting discussion on stockoverflow [2][3]. But btw >>> I disagree with Tall Jeff [3] says "The difference between a recursive >>> and non-recursive mutex has to do with ownership. " I think he >>> confuses a simple-mutex and binary-semaphore, as do a some commenters. >>> >>> "Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some >>> performance considerations and advises "a recursive mutex is dangerous >>> because you lose sense of locking scope. It costs more than a simple >>> mutex." >>> >>> "Recursive Locks Will Kill You!" [5] provides some thread safety >>> guidelines. >>> >>> Finally, there is a paper "Ad Hoc Synchronization Considered harmful" >>> [6], which I haven't read yet since I wanted to get this post out >>> before heading to bed, but I hope to tomorrow. >>> >>> >>> [1] http://www.zaval.org/resources/library/butenhof1.html >>> [2] http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex >>> [3] >>> http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recur… >>> [4] >>> http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ >>> [5] >>> http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ >>> [6] https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf >>> >>> >>> So our existing Mutex implementation happens to be recursive, and I'm >>> not suggesting we change that. However if we should consider *not* >>> baking the *assumption* of recursion into the primitives, so the same >>> primitives could *also* be used for a SimpleMutex class. The logic to >>> provide recursion for Mutex is only [ owner = activeProcess ] which is >>> easily done in-image. >>> >>> So I propose introducing aquire/release primitives based off the >>> existing critical section primitives with the recursion removed. >> >> >> We have two sets of primitives, the queueing semaphore ones, signal and >> wait, #85 & #86, which are not recursive, and new ones, #185, #186 & #187 >> that support ownership, and hence support recursion. It makes no sense to >> remove the recursion support. That's what the primitives are for, to >> provide ownership support as efficiently as possible. Please don't be led >> by the problems others may have in other systems, and instead be led by how >> we're doing. Squeak and Pharo (and Smalltalk) have had recursive owned >> critical sections for decades and no one (e.g. from demanding industrial >> control applications) has complained that these recursive critical sections >> are problematic. > > I respect your deep experience, but there is an engineering principle > that "just because it works, doesn't mean its correct. It may just > be reinforcing some misconceptions" ;) > > Several reasons why people may not complain... > 1. the expectation its been there so long that its correct > 2. the expectation expert people worked on it so its correct > 3. subtle bugs remain latent or trigger infrequently, thus hard to isolate > 4. when bugs arise, they are fixed pragmatically without deeper > philosophical consideration > 5. coincidently other good programming practices avoided problematic situations > 6. Threads run concurrently and co-operatively, so maybe in practice > there are less issues than a parallel and pre-emptive systems. Okay class... your new word for the day is "hubris". It was hubris for me to lay it out like that. It was easy to think I could do better from a distant hand waving perspective, but having spent a few hours in the trenches playing concretely with the primitive code, I've realised the current primitiveEnterCriticalSection is optimum. > I would think a thread doing an in-image (owner = activeProcess) test > would be unaffected by suspension points since it doesn't change any > state and only the same thread would have set owner via the primitive. >> The new primitives give us a streamlined and hack-free >> implementation which doesn't depend on the niceties of what are suspension >> points as do the pre-primitive implementations. So I see no rationale for >> gelding these primitives. You are right. Actually, as Dennis indicated, the existing primitive already provides everything needed... RecursiveMutex>>critical: aBlock ^self primitiveEnterCriticalSection ifTrue: [aBlock value] ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] SimpleMutex>>critical: aBlock ^self primitiveEnterCriticalSection ifTrue: [self error: 'recursive primitives will kill you'] ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] duh, me! Well, it was a useful learning process for me to play with the primitive. I'm may have some further thoughts on the exit primitive, but they are still forming, so I'll leave for a separate post. cheers -ben

Feb. 6, 2016

Re: [Pharo-dev] Ubuntu with Spur

by Damien Cassou

On February 5, 2016 8:07:38 PM GMT+01:00, Torsten Bergmann <astares(a)gmx.de> wrote: >Is Spur already in the PPA for last stable Ubuntu or how >do I install latest spur quickly using commandline? > >Should I use zeroconf from get.pharo.org. Does it >run on latest dev version of Ubuntu? > >Thanks >T. I updated the source repository. Now, Markus must upload a new deb release. In the meantime, you can use get.pharo.org or http://nixos.org/nixpkgs/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 5, 2016

Ubuntu with Spur

by Torsten Bergmann

Is Spur already in the PPA for last stable Ubuntu or how do I install latest spur quickly using commandline? Should I use zeroconf from get.pharo.org. Does it run on latest dev version of Ubuntu? Thanks T.

Feb. 5, 2016