- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Help with bugfix process

by Julien Delplanque

I just tried using Lubuntu 32 bits on Virtualbox and I still have the same problem... Is it possible that the problem is something else? Julien On 07/02/16 13:41, Julien Delplanque wrote: > Ok I will try this :-). > > Julien > > On 07/02/16 13:36, Nicolai Hess wrote: >> Yes, that should work. >> Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" >> <julien(a)tamere.eu>: >> >>> I do not have a real 32bit machine available, would it be ok to use a >>> virtual 32bit machine? >>> >>> Julien >>> >>> On 07/02/16 13:26, Nicolai Hess wrote: >>> >>>> No, you did it right, and it should work that way. >>>> At the Moment, we have a problem with uuid genetation on Linux >>>> 64bit. Can >>>> you try to recreate and resubmit the change on a 32bit Machine? >>>> Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" >>>> <julien(a)tamere.eu>: >>>> >>>> Hello, >>>>> I am trying to submit a simple enhancement to WindowModel (spec) by >>>>> adding >>>>> #activate message [1]. >>>>> >>>>> I follow the process described here [2]. The problem is that when I >>>>> commit >>>>> my Slice in Pharo50Inbox, it uploads my changes but when I try to >>>>> load my >>>>> slice (in a fresh image) I have some strange things happening: >>>>> >>>>> I try to load my slice by: >>>>> 1. Opening Monticello browser. >>>>> 2. Selecting Pharo50Inbox in the right lists. >>>>> 3. I click on 'Open' button. >>>>> 4. I search for my slice in the right list of the window opened. >>>>> >>>>> Then, there are two strange things: >>>>> 1. I can see my slice (with the right name) but when I try to load it >>>>> using the button 'Load', it does nothing and if I click on changes it >>>>> shows >>>>> nothing. >>>>> 2. The data displayed in the text field on the bottom of the >>>>> window is >>>>> wrong, the author is not my username, the package name is not the >>>>> same as >>>>> displayed in the right list and the commit message is not my commit >>>>> message >>>>> (see attached image). >>>>> >>>>> Am I doing something wrong? I think I follow the process correctly >>>>> so I >>>>> do >>>>> not understand what is going on... >>>>> >>>>> I already submitted the fix twice and I am sorry if it creates >>>>> unwanted >>>>> work for someone. :-( >>>>> >>>>> Thanks in advance for the help, >>>>> >>>>> Julien >>>>> >>>>> [1]: https://pharo.fogbugz.com/f/cases/17528 >>>>> [2]: http://pharo.org/contribute-propose-fix >>>>> >>>>> >>> >

Feb. 7, 2016

Re: [Pharo-dev] Help with bugfix process

by Julien Delplanque

Ok I will try this :-). Julien On 07/02/16 13:36, Nicolai Hess wrote: > Yes, that should work. > Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" <julien(a)tamere.eu>: > >> I do not have a real 32bit machine available, would it be ok to use a >> virtual 32bit machine? >> >> Julien >> >> On 07/02/16 13:26, Nicolai Hess wrote: >> >>> No, you did it right, and it should work that way. >>> At the Moment, we have a problem with uuid genetation on Linux 64bit. Can >>> you try to recreate and resubmit the change on a 32bit Machine? >>> Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" <julien(a)tamere.eu>: >>> >>> Hello, >>>> I am trying to submit a simple enhancement to WindowModel (spec) by >>>> adding >>>> #activate message [1]. >>>> >>>> I follow the process described here [2]. The problem is that when I >>>> commit >>>> my Slice in Pharo50Inbox, it uploads my changes but when I try to load my >>>> slice (in a fresh image) I have some strange things happening: >>>> >>>> I try to load my slice by: >>>> 1. Opening Monticello browser. >>>> 2. Selecting Pharo50Inbox in the right lists. >>>> 3. I click on 'Open' button. >>>> 4. I search for my slice in the right list of the window opened. >>>> >>>> Then, there are two strange things: >>>> 1. I can see my slice (with the right name) but when I try to load it >>>> using the button 'Load', it does nothing and if I click on changes it >>>> shows >>>> nothing. >>>> 2. The data displayed in the text field on the bottom of the window is >>>> wrong, the author is not my username, the package name is not the same as >>>> displayed in the right list and the commit message is not my commit >>>> message >>>> (see attached image). >>>> >>>> Am I doing something wrong? I think I follow the process correctly so I >>>> do >>>> not understand what is going on... >>>> >>>> I already submitted the fix twice and I am sorry if it creates unwanted >>>> work for someone. :-( >>>> >>>> Thanks in advance for the help, >>>> >>>> Julien >>>> >>>> [1]: https://pharo.fogbugz.com/f/cases/17528 >>>> [2]: http://pharo.org/contribute-propose-fix >>>> >>>> >>

Feb. 7, 2016

Re: [Pharo-dev] Help with bugfix process

by Nicolai Hess

Yes, that should work. Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" <julien(a)tamere.eu>: > I do not have a real 32bit machine available, would it be ok to use a > virtual 32bit machine? > > Julien > > On 07/02/16 13:26, Nicolai Hess wrote: > >> No, you did it right, and it should work that way. >> At the Moment, we have a problem with uuid genetation on Linux 64bit. Can >> you try to recreate and resubmit the change on a 32bit Machine? >> Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" <julien(a)tamere.eu>: >> >> Hello, >>> >>> I am trying to submit a simple enhancement to WindowModel (spec) by >>> adding >>> #activate message [1]. >>> >>> I follow the process described here [2]. The problem is that when I >>> commit >>> my Slice in Pharo50Inbox, it uploads my changes but when I try to load my >>> slice (in a fresh image) I have some strange things happening: >>> >>> I try to load my slice by: >>> 1. Opening Monticello browser. >>> 2. Selecting Pharo50Inbox in the right lists. >>> 3. I click on 'Open' button. >>> 4. I search for my slice in the right list of the window opened. >>> >>> Then, there are two strange things: >>> 1. I can see my slice (with the right name) but when I try to load it >>> using the button 'Load', it does nothing and if I click on changes it >>> shows >>> nothing. >>> 2. The data displayed in the text field on the bottom of the window is >>> wrong, the author is not my username, the package name is not the same as >>> displayed in the right list and the commit message is not my commit >>> message >>> (see attached image). >>> >>> Am I doing something wrong? I think I follow the process correctly so I >>> do >>> not understand what is going on... >>> >>> I already submitted the fix twice and I am sorry if it creates unwanted >>> work for someone. :-( >>> >>> Thanks in advance for the help, >>> >>> Julien >>> >>> [1]: https://pharo.fogbugz.com/f/cases/17528 >>> [2]: http://pharo.org/contribute-propose-fix >>> >>> > >

Feb. 7, 2016

Re: [Pharo-dev] Help with bugfix process

by Julien Delplanque

I do not have a real 32bit machine available, would it be ok to use a virtual 32bit machine? Julien On 07/02/16 13:26, Nicolai Hess wrote: > No, you did it right, and it should work that way. > At the Moment, we have a problem with uuid genetation on Linux 64bit. Can > you try to recreate and resubmit the change on a 32bit Machine? > Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" <julien(a)tamere.eu>: > >> Hello, >> >> I am trying to submit a simple enhancement to WindowModel (spec) by adding >> #activate message [1]. >> >> I follow the process described here [2]. The problem is that when I commit >> my Slice in Pharo50Inbox, it uploads my changes but when I try to load my >> slice (in a fresh image) I have some strange things happening: >> >> I try to load my slice by: >> 1. Opening Monticello browser. >> 2. Selecting Pharo50Inbox in the right lists. >> 3. I click on 'Open' button. >> 4. I search for my slice in the right list of the window opened. >> >> Then, there are two strange things: >> 1. I can see my slice (with the right name) but when I try to load it >> using the button 'Load', it does nothing and if I click on changes it shows >> nothing. >> 2. The data displayed in the text field on the bottom of the window is >> wrong, the author is not my username, the package name is not the same as >> displayed in the right list and the commit message is not my commit message >> (see attached image). >> >> Am I doing something wrong? I think I follow the process correctly so I do >> not understand what is going on... >> >> I already submitted the fix twice and I am sorry if it creates unwanted >> work for someone. :-( >> >> Thanks in advance for the help, >> >> Julien >> >> [1]: https://pharo.fogbugz.com/f/cases/17528 >> [2]: http://pharo.org/contribute-propose-fix >>

Feb. 7, 2016

Re: [Pharo-dev] Help with bugfix process

by Nicolai Hess

No, you did it right, and it should work that way. At the Moment, we have a problem with uuid genetation on Linux 64bit. Can you try to recreate and resubmit the change on a 32bit Machine? Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" <julien(a)tamere.eu>: > Hello, > > I am trying to submit a simple enhancement to WindowModel (spec) by adding > #activate message [1]. > > I follow the process described here [2]. The problem is that when I commit > my Slice in Pharo50Inbox, it uploads my changes but when I try to load my > slice (in a fresh image) I have some strange things happening: > > I try to load my slice by: > 1. Opening Monticello browser. > 2. Selecting Pharo50Inbox in the right lists. > 3. I click on 'Open' button. > 4. I search for my slice in the right list of the window opened. > > Then, there are two strange things: > 1. I can see my slice (with the right name) but when I try to load it > using the button 'Load', it does nothing and if I click on changes it shows > nothing. > 2. The data displayed in the text field on the bottom of the window is > wrong, the author is not my username, the package name is not the same as > displayed in the right list and the commit message is not my commit message > (see attached image). > > Am I doing something wrong? I think I follow the process correctly so I do > not understand what is going on... > > I already submitted the fix twice and I am sorry if it creates unwanted > work for someone. :-( > > Thanks in advance for the help, > > Julien > > [1]: https://pharo.fogbugz.com/f/cases/17528 > [2]: http://pharo.org/contribute-propose-fix >

Feb. 7, 2016

Help with bugfix process

by Julien Delplanque

Hello, I am trying to submit a simple enhancement to WindowModel (spec) by adding #activate message [1]. I follow the process described here [2]. The problem is that when I commit my Slice in Pharo50Inbox, it uploads my changes but when I try to load my slice (in a fresh image) I have some strange things happening: I try to load my slice by: 1. Opening Monticello browser. 2. Selecting Pharo50Inbox in the right lists. 3. I click on 'Open' button. 4. I search for my slice in the right list of the window opened. Then, there are two strange things: 1. I can see my slice (with the right name) but when I try to load it using the button 'Load', it does nothing and if I click on changes it shows nothing. 2. The data displayed in the text field on the bottom of the window is wrong, the author is not my username, the package name is not the same as displayed in the right list and the commit message is not my commit message (see attached image). Am I doing something wrong? I think I follow the process correctly so I do not understand what is going on... I already submitted the fix twice and I am sorry if it creates unwanted work for someone. :-( Thanks in advance for the help, Julien [1]: https://pharo.fogbugz.com/f/cases/17528 [2]: http://pharo.org/contribute-propose-fix

Feb. 7, 2016

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

by Tudor Girba

Hi, Indeed, we had an intense exchange and finally the decision was to change the basic design. In short, the main reason for this was to move towards a design that relies on only one single tree of elements for easing rendering and interaction. Previously, BlMorph had a BlShape that knew how to draw the morph. This was Ok for single shapes, but the design got too complicated when we tried to have composites because the delegation had to essentially go through two hierarchies. We had a similar experience with Mondrian and Roassal before. In the current design, we have only one tree of elements, and each element has a basic shape that holds the path but it does not draw. Essentially, the shape provides the background space on which the morph can draw. One of the ideas that drove the design si that Bloc should provide a simple yet flexible low level design, and allow higher level abstractions on top. For example, we would like to have an engine like Roassal be directly implemented using bloc elements, without relying on its own world built in a canvas. Cheers, Doru > On Feb 6, 2016, at 10:00 AM, stepharo <stepharo(a)free.fr> wrote: > > > > 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. >> >> > > -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

Feb. 6, 2016

Re: [Pharo-dev] [bloc] a little demo

by Aliaksei Syrel

Bloc has a jenkins build, which is finally green (to some extent) https://ci.inria.fr/pharo-contribution/job/Bloc/ alex On Sat, Feb 6, 2016 at 9:49 AM, stepharo <stepharo(a)free.fr> wrote: > 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] [Vm-dev] Simple versus Recursive Mutexes

by Ben Coman

On Sat, Feb 6, 2016 at 8:28 AM, Ben Coman <btc(a)openinworld.com> wrote: > 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]] Dennis, I no longer think we need a new primitive for #acquire. We should just use 186. Regarding the inverted logic, we either live with it, or perhaps name it something like #acquiredAgain. For example we might have... Mutex>>criticalNew: aBlock lock acquiredAgain ifTrue: [aBlock value] "recursive" ifFalse: [ aBlock ensure: [ lock release] ]. "first time" OwnedLockTest>>testAcquireLockTwiceFromSameProcess | acquiredAgain | self fork: [ lock acquiredAgain. acquiredAgain := lock acquiredAgain ]. self waitLastProcessFinished. self assert: acquiredAgain description: 'acquiring lock twice should return true' but I'm not sure about my #acquiredAgain suggestion and hope to hear what others think. cheers -ben

Feb. 6, 2016

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

by Max Leske

Changing the scheduler didnât have any effect. However, it seems to me that the size of the input matters. I can make it work in two ways: 1. delete a line. If the lineâs too short it wonât work though 2. delete a couple of characters from some symbols That would suggest that not the number of symbols / items in the array is significant but the number of bytes. So maybe thereâs a problem with memory allocation in the VM. I havenât been able to come up with an exact number, but the VM starts crashing at around 7096 characters. Sometimes I can go over 7100, other times not. Smaller numbers always work. HTH, Max > On 06 Feb 2016, at 07:25, Ben Coman <btc(a)openInWorld.com> wrote: > > On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> 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>) 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?17066> > https://pharo.fogbugz.com/default.asp?13756 <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