May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] froze image just

by Igor Stasenko

On 1 May 2013 19:45, Ben Coman <btc(a)openinworld.com> wrote: > Maybe something like this will help... > http://architects.dzone.com/articles/simulate-network-latency > yeah.. good-old ipfw (know it by heart from times when i was working with FreeBSD) > cheers -ben > > > stephane ducasse wrote: >> >> I created a slice then pressed save when clicking on the package cache and >> I was on the train my connection was flaky. >> So I should retry to see if I cut internet I get the same behavior >> >> Stef >> On May 1, 2013, at 2:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> >>> On 01 May 2013, at 14:06, stephane ducasse <stephane.ducasse(a)free.fr> >>> wrote: >>> >>> >>>> >>>> Yes :) >>>> Same behavior here >>>> On May 1, 2013, at 11:51 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> >>>>> >>>>> Btw. Waiting for network timeout doesn't work. That is to say, waiting >>>>> a night is not long enough >>>>> >>>>> Stephan >>>>> >>>>> Verstuurd vanaf mijn iPhone >>>>> >>> >>> Well, Stephan or StÃ©phane, give us/me a repeatable use case on Mac OS X >>> (preferably using latest VM and 2.0) where you are sure a network timeout >>> should occur and it doesn't. It has to include a description of what is >>> precisely 'no network'. >>> >>> I know it is not perfect, but to make any progress we need something >>> concrete. >>> >>> Sven >>> >>> >>> >>> >> >> >> >> >> > > > > -- Best regards, Igor Stasenko.

May 1, 2013

Re: [Pharo-project] Jenkins: Seaside-3.1-in-Pharo-2.0 is broken

by Camillo Bruni

Grml :P What is the status of the Seaside 3.1 Configuration? On 2013-05-01, at 19:19, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > if you open the image resulting from this job, you get a "FileWriteError: > File stdout is broken". > > https://ci.inria.fr/pharo-contribution/job/Seaside-3.1-in-Pharo-2.0/ > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing > enthusiasm." > Winston Churchill

May 1, 2013

Re: [Pharo-project] Moment of fun

by Camillo Bruni

On 2013-05-01, at 19:01, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, great superpowers! > A bit more lightweight and efficient than abort(); gdb myApp core > > A small reminder for myself: > > [ > (Delay forSeconds: 2 hours asSeconds) wait. > WorldState addDeferredUIMessage: [ UIManager default inform: 'You''re > Smalltalking too much > There are other nice things worth in life' ]. > ] fork in Pharo 3.0 you can write that a tad more elegant: [ WorldState addDeferredUIMessage: [ UIManager default inform: 'You''re Smalltalking too much There are other nice things worth in life' ]. ] valueAfterWaiting: 2 hours and in general for waiting on delays you now can do: 2 hours wait that hides away quite some details :)

May 1, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by Marcus Denker

On May 1, 2013, at 7:03 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> When? Friday May 3 > > What time are you all starting? I will be on IRC and Skype from NYC as usual > :) > I think that people will arrive aroung 9-9:30 local time, with real action starting 10h. Marcus

May 1, 2013

Re: [Pharo-project] froze image just

by Ben Coman

Maybe something like this will help... http://architects.dzone.com/articles/simulate-network-latency cheers -ben stephane ducasse wrote: > I created a slice then pressed save when clicking on the package cache and I was on the train my connection was flaky. > So I should retry to see if I cut internet I get the same behavior > > Stef > On May 1, 2013, at 2:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 01 May 2013, at 14:06, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >> >>> Yes :) >>> Same behavior here >>> On May 1, 2013, at 11:51 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> >>>> Btw. Waiting for network timeout doesn't work. That is to say, waiting a night is not long enough >>>> >>>> Stephan >>>> >>>> Verstuurd vanaf mijn iPhone >>>> >> Well, Stephan or StÃ©phane, give us/me a repeatable use case on Mac OS X (preferably using latest VM and 2.0) where you are sure a network timeout should occur and it doesn't. It has to include a description of what is precisely 'no network'. >> >> I know it is not perfect, but to make any progress we need something concrete. >> >> Sven >> >> >> >> > > > >

May 1, 2013

Re: [Pharo-project] [regression reporter]regression occurred

by Nicolas Cellier

False alarm, I retract my assertion about Opal which was due to my wrong interpretation of some byteCode. After closer inspection, I don't suspect Opal anymore. 2013/5/1 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Hmm, just a coincidence then. > Is there an easy way to reproduce the behavior? > > > 2013/5/1 Marcus Denker <marcus.denker(a)inria.fr> > >> but Opal is not used here! >> >> And we had cases before, Esteban was looking at this. >> >> >> On Wed, May 1, 2013 at 3:03 PM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> I'd rather suspect an OpalCompiler bug... >>> This happened to me after I switch to opal as default and recompiled >>> all... >>> Following in another post... >>> >>> >>> 2013/4/30 Sven Van Caekenberghe <sven(a)stfx.eu> >>> >>>> >>>> On 30 Apr 2013, at 10:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> > >>>> > On Apr 30, 2013, at 10:30 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> > >>>> >> >>>> >> On 30 Apr 2013, at 08:53, no-reply(a)ci.inria.fr wrote: >>>> >> >>>> >>> >>>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… >>>> >>> >>>> >>> 1 regressions found. >>>> >>> Zinc.Tests.ZnClientTests.testPostMultipart >>>> >> >>>> >> This seems like a compiler problem to me: how else could (client := >>>> ZnClient new) return a SmallInteger ? >>>> >> >>>> > >>>> > This is a vm bug, I think. >>>> >>>> Nice ;-) >>>> >>>> >> Error Message >>>> >> >>>> >> SmallInteger>>url: >>>> >> >>>> >> Stacktrace >>>> >> >>>> >> SmallInteger(Object)>>doesNotUnderstand: #url: >>>> >> [:server | >>>> >> (client := ZnClient new) url: server localUrl; >>>> >> addPath: 'echo'; >>>> >> >>>> >> addPart: (ZnMimePart fieldName: 'username' value: >>>> 'john'); >>>> >> >>>> >> addPart: (ZnMimePart >>>> >> fieldName: 'foo' >>>> >> entity: (ZnEntity text: '123')); >>>> >> >>>> >> addPart: (ZnMimePart fieldName: 'file' fileNamed: >>>> filename); >>>> >> post. >>>> >> self assert: client isSuccess. >>>> >> self >>>> >> assert: (client contents includesSubstring: >>>> 'multipart')] in ZnClientTests>>testPostMultipart >>>> >> BlockClosure>>cull: >>>> >> [server start. >>>> >> self assert: server isRunning & server isListening. >>>> >> block cull: server] in ZnClientTests>>withServerDo: >>>> >> BlockClosure>>ensure: >>>> >> ZnClientTests>>withServerDo: >>>> >> ZnClientTests>>testPostMultipart >>>> >> ZnClientTests(TestCase)>>performTest >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> >>> >> >> >> -- >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de >> > >

May 1, 2013

[Pharo-project] Playing with Opal AST->BC Translator

by Nicolas Cellier

Opal is fun. I have a few simplifications to propose for the AST->BC OCASTTranslator 1) instead of testing isEffectTranslator or refining in subclass, most often we could just let self visit the node. Indeed, self will already be either a Translator ForEffect or ForValue. For example, this could apply to emitIfFalseIfTrue: emitIfNilIfNotNil: visitCascadeNode: This might also remove a few useless pushNil; pop BC sequences. 2) I think we can simplify the #visitBlockNode: / #visitSequenceNode: pair. Indeed, visitSequenceNode: tests if its parent isBlock, and if so will emitValue, else emitEffect. Inversely visitBlockNode: always ask to emitEffect, but since it contains a SequenceNode, this is a big lie. I suggest to always let the valueTranslator emitValue visitBlockNode: and simplify #visitSequenceNode: to just let (self visitNode: statements last). 3) I suggest changing the BC generated for or: and and: instead of: valueTranslator visitNode: aMessageNode receiver. methodBuilder jumpAheadTo: #else if: false; pushLiteral: true; jumpAheadTo: #end; jumpAheadTarget: #else. valueTranslator visitInlinedBlockNode: aMessageNode arguments first. methodBuilder jumpAheadTarget: #end. We could just use dup and thus remove a jump: valueTranslator visitNode: aMessageNode receiver. methodBuilder pushDup; jumpAheadTo: #end if: true; popTop. self visitInlinedBlockNode: aMessageNode arguments first. methodBuilder jumpAheadTarget: #end. ForEffect, this would just be self emitIfFalse: aMessageNode Of course, that last change might disturb the Decompiler a bit, but since we care far less now... I can open 1 or more issues if there is an interest. Nicolas

May 1, 2013

[Pharo-project] Jenkins: Seaside-3.1-in-Pharo-2.0 is broken

by Damien Cassou

Hi, if you open the image resulting from this job, you get a "FileWriteError: File stdout is broken". https://ci.inria.fr/pharo-contribution/job/Seaside-3.1-in-Pharo-2.0/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 1, 2013

Re: [Pharo-project] [Sprint] Sprint Lille May 3rd

by Sean P. DeNigris

Marcus Denker-4 wrote > When? Friday May 3 What time are you all starting? I will be on IRC and Skype from NYC as usual :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Sprint-Sprint-Lille-May-3rd-tp4682097p4684819.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 1, 2013

Re: [Pharo-project] Moment of fun

by Nicolas Cellier

Yes, great superpowers! A bit more lightweight and efficient than abort(); gdb myApp core A small reminder for myself: [ (Delay forSeconds: 2 hours asSeconds) wait. WorldState addDeferredUIMessage: [ UIManager default inform: 'You''re Smalltalking too much There are other nice things worth in life' ]. ] fork 2013/5/1 Camillo Bruni <camillobruni(a)gmail.com> > I really love the use of fuel to serialize errors on the build server: > ------------------------------------------------------------------------- > > [ > "some code causing an error" > Error signal > ] on: Error do: [ :error | > FLSerializer serialize: error toFileNamed: 'error.fuel' ] > > ------------------------------------------------------------------------- > Then in a new image open a debugger on the serialized error: > ------------------------------------------------------------------------- > > error := FLMaterializer materializeFromFileNamed: 'error.fuel'. > error debug. > >

May 1, 2013