- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Levente Uzonyi

On Fri, 9 Dec 2011, Schwab,Wilhelm K wrote: > Ok, but I have never failed to be impressed by how much trouble even green threads can cause. Meaning no disrespect, if I had a repeatable failure scenario, I would make the switch to a mutex just in case. If for no other reason, Semaphore>>critical: makes assumptions about what is and is not interruptible. I don't have to so much as play dumb here (it comes naturally at the vm level), but I can't help wondering about the validity of the assumptions, the correctness of the code, and all the more so given our move to Cog. Is there a reason *not* to use Mutex in such situations? We have multiple users telling us there is a problem. Mutex is broken, so you better not use it. :) Levente ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, December 09, 2011 1:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? On 09.12.2011 16:59, Schwab,Wilhelm K wrote: > I would be very curious about what happens if you replace the socket-related mutual exclusion semaphores with mutexes. For the semaphore in question here, there is no recursion going on in any of the critical sections. So the answer to that would be absolutely nothing. Cheers, Henry >

Dec. 9, 2011

Re: [Pharo-project] [squeak-dev] Re: Prune stack serialization

by Mariano Martinez Peck

Hi guys. When we implemented this possibility of pruning the closures when they were clean, one of our crazy tests started to fail. It is not that the test is very important, but I am interested in trying to understand why it fails. The test (simplied) is: | aSortedCollection materialized | instanceVariableForTesting := false. aSortedCollection := SortedCollection sortBlock: [:a :b | instanceVariableForTesting ifTrue: [ a <= b ] ifFalse: [ a >= b ] ]. materialized := self resultOfSerializeAndMaterialize: aSortedCollection. materialized addAll: #(2 3 1). aSortedCollection addAll: #(2 3 1). Well, the thing is that the materialized SortedCollection, it is sortBLock, the closure is quite crazy and the 'instanceVariableForTesting' doesn't have the boolean but instead a #Processor WTF?? So then the #addAll: fails with a MustBeBoolean. Do you think there is something I should check for this closure? I think it may have to be related with the instanceVariable... Just for the record, what we are doing is something like: serializeReferencesOf: aBlockClosure with: aSerialization 1 to: aBlockClosure basicSize do: [ :index | aSerialization encodeReferenceTo: (aBlockClosure basicAt: index) ]. aBlockClosure isClean ifTrue: [ aSerialization stream nextPut: 1. aSerialization encodeReferenceTo: aBlockClosure method. aSerialization encodeReferenceTo: aBlockClosure receiver. ] ifFalse: [ aSerialization stream nextPut: 0. aSerialization encodeReferenceTo: aBlockClosure outerContext. ]. aSerialization encodeReferenceTo: aBlockClosure startpc. aSerialization encodeReferenceTo: aBlockClosure numArgs. ----- materializeReferencesOf: aBlockClosure with: aMaterialization | methodOrContext method context | 1 to: aBlockClosure basicSize do: [ :index | aBlockClosure basicAt: index put: (aMaterialization nextEncodedReference). ]. (aMaterialization stream next = 1) ifTrue: [ " it was a clean BlockClosure, otherwise it should have been 0" method := aMaterialization nextEncodedReference. aBlockClosure outerContext: (MethodContext sender: nil receiver: aMaterialization nextEncodedReference method: method arguments: #() ) startpc: aMaterialization nextEncodedReference numArgs: aMaterialization nextEncodedReference. ] ifFalse: [ context := aMaterialization nextEncodedReference. aBlockClosure outerContext: context startpc: aMaterialization nextEncodedReference numArgs: aMaterialization nextEncodedReference]. ----- Thanks in advance! On Sun, Dec 4, 2011 at 8:33 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Thanks Juan. With the latest version of Eliot, the following are failing: > > > self deny: [ | outerBlockTemp | [ outerBlockTemp printString ] isClean ] > value. > self deny: [ | outerBlockTemp | [ outerBlockTemp :=7 ] isClean ] value. > self deny: [ tempVar + 1 ] isClean. > self deny: [ tempVar := 1 ] isClean. > self deny: [ ClassVar + 1 ] isClean. > self deny: [ ClassVar := 1 ] isClean. > > Thanks > > > On Sat, Dec 3, 2011 at 3:01 AM, Juan Vuletich <juan(a)jvuletich.org> wrote: > >> Eliot Miranda wrote: >> >> >>> >>> On Fri, Dec 2, 20Tha11 at 4:01 PM, Juan Vuletich <juan(a)jvuletich.org<mailto: >>> juan(a)jvuletich.org>> wrote: >>> >>> Eliot Miranda wrote: >>> >>> Hi Juan, >>> >>> ... >>> >>> >>> >>> I can say that it does indeed work. But I'd be really >>> grateful if >>> Eliot took a good look at that code! >>> >>> >>> There is a much better way, using >>> InstructionStream>>**interpreetNextInstructionFor: which >>> abstracts away from the bytecode encoding and allows one to >>> simply use messages. e.g. look at >>> >>> and (SortedCollection sortBlock: [:a :b| a compare: b >>> caseSensitive: false]) sortBlock abstractBytecodes evaluates to >>> >>> an OrderedCollection(#**pushTemporaryVariable: >>> #pushTemporaryVariable: #pushConstant: #send:super:numArgs:) >>> >>> So a check for clean blocks would check for a block's >>> abstractBytecodes not including some particular set of banned >>> messages (which I *think* is pushReceiver >>> pushReceiverVariable: popIntoReceiverVariable: >>> storeIntoReceiverVariable: methodReturnConstant: >>> methodReturnReceiver methodReturnTop). >>> >>> e.g. >>> >>> isClean >>> ^(self abstractBytecodes intersection: #(pushReceiver >>> pushReceiverVariable: popIntoReceiverVariable: >>> storeIntoReceiverVariable: methodReturnConstant: >>> methodReturnReceiver methodReturnTop)) isEmpty >>> >>> >>> Cheers, >>> Juan Vuletich >>> >>> >>> >>> >>> -- best, >>> Eliot >>> >>> >>> Thanks Eliot. However, it looks to me that this needs more tweaking. >>> >>> <blush>Damn right :) I've done zero testing. It was just an >>> example</blush> >>> >>> For instance, your method answers true for >>> [ xx size ] isClean >>> and >>> [ ^ nil ] isClean >>> while mine answers false for both. Maybe we could serialize non >>> local returns using the Compiler (although we won't be able to >>> return anywhere), but external variable acess is a problem. >>> >>> Will keep playing with this for a while... >>> >>> >>> Can you (can I??) write some tests? What's xx in the above? Ah! [^nil] >>> isn't clean in my code since it should be pc <= end, not pc < end!! Try >>> the attached... >>> >> >> This is a start: >> >> testIsClean >> " >> ClosureTests new testIsClean >> " >> | tempVar | >> tempVar := 1. >> self assert: [ 3 + 4 ] isClean. >> self assert: [ :a | a * 2 ] isClean. >> self assert: [ Smalltalk size ] isClean. >> self assert: [ :blockArg | blockArg printString ] isClean. >> self assert: [ | blockTemp | blockTemp printString ] isClean. >> self assert: [ | blockTemp | blockTemp :=7 ] isClean. >> self deny: [ | outerBlockTemp | [ outerBlockTemp printString ] isClean >> ] value. >> self deny: [ | outerBlockTemp | [ outerBlockTemp :=7 ] isClean ] value. >> self deny: [ tempVar + 1 ] isClean. >> self deny: [ tempVar := 1 ] isClean. >> self deny: [ ivar + 1 ] isClean. >> self deny: [ ivar := 1 ] isClean. >> self deny: [ ^ true ] isClean. >> self deny: [ self printString ] isClean. >> self deny: [ ^ self ] isClean. >> self deny: [ ClassVar + 1 ] isClean. >> self deny: [ ClassVar := 1 ] isClean. >> >> This test passes with my implementation. >> >> >> >>> >>> Cheers, >>> Juan Vuletich >>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >> Cheers, >> Juan Vuletich >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Dec. 9, 2011

Re: [Pharo-project] SMTPClient uses local address

by Sean P. DeNigris

Issue 5078: SMTPClient (wrongly) uses local address http://code.google.com/p/pharo/issues/detail?id=5078 I have no idea how to fix it. I cheated in my image with "(PipeableOSProcess waitForCommand: 'curl whatismyip.org') output" to get it to work temporarily. -- View this message in context: http://forum.world.st/SMTPClient-uses-local-address-tp4178445p4178467.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011

[Pharo-project] SMTPClient uses local address

by Sean P. DeNigris

SMTPClient>>initiateSession ... self sendCommand: ... NetNameResolver localHostName. ... This results in the local address (e.g. 10.0.0.5) being used, which sometimes gets kicked back by the mail server with: 550-"JunkMail rejected - ool-182daabe.dyn.optonline.net (10.0.0.5) -- View this message in context: http://forum.world.st/SMTPClient-uses-local-address-tp4178445p4178445.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 94 - AnnouncementSet

by StÃ©phane Ducasse

I'm a group of announcements. I can be used to register action to a group of announcement instead of enumerating them one by one. On Dec 9, 2011, at 10:46 PM, sean(a)clipperadams.com wrote: > 93 classes done > 802 classes remaining > Continuing in Announcements... > > Today: AnnouncementSet > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! >

Dec. 9, 2011

Re: [Pharo-project] MenuMorph instances

by StÃ©phane Ducasse

> "MenuMorph allInstances" returns an array of 27 in my personal 1.3 image, and > 5 in a fresh 1.3 rc. Are they cached? orphaned? Not that I know. Stef

Dec. 9, 2011

[Pharo-project] [COTDC] 94 - AnnouncementSet

by sean＠clipperadams.com

93 classes done 802 classes remaining Continuing in Announcements... Today: AnnouncementSet Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 9, 2011

Re: [Pharo-project] Exception Handling in the Moose Distribution Image

by StÃ©phane Ducasse

Yes it was the problem with the Stream basicNew. In 1.4 latest version it works. On Dec 9, 2011, at 4:24 PM, Mircea Filip Lungu wrote: > Hi guys, > > This is a bug report I got from one of my students and replicated by myself: > > In the Moose 4.6 image downloaded from moosetechnology.org, if I > execute the following code > > | c | > c := Collection new. > c add: 1. > > the image seems to freeze, although what I would expect is that > SubclassResponsibility > exception to be raised. This has been observed on Windows and Mac. > > Do you know about this? > > Thanks, > M. > > -- > Dr. Mircea Lungu > Researcher > Software Composition Group > University of Bern > > > -- > Dr. Mircea Lungu > Researcher > Software Composition Group > University of Bern >

Dec. 9, 2011

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by Schwab,Wilhelm K

Ok, but I have never failed to be impressed by how much trouble even green threads can cause. Meaning no disrespect, if I had a repeatable failure scenario, I would make the switch to a mutex just in case. If for no other reason, Semaphore>>critical: makes assumptions about what is and is not interruptible. I don't have to so much as play dumb here (it comes naturally at the vm level), but I can't help wondering about the validity of the assumptions, the correctness of the code, and all the more so given our move to Cog. Is there a reason *not* to use Mutex in such situations? We have multiple users telling us there is a problem. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, December 09, 2011 1:33 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image? On 09.12.2011 16:59, Schwab,Wilhelm K wrote: > I would be very curious about what happens if you replace the socket-related mutual exclusion semaphores with mutexes. For the semaphore in question here, there is no recursion going on in any of the critical sections. So the answer to that would be absolutely nothing. Cheers, Henry

Dec. 9, 2011

[Pharo-project] MenuMorph instances

by Sean P. DeNigris

"MenuMorph allInstances" returns an array of 27 in my personal 1.3 image, and 5 in a fresh 1.3 rc. Are they cached? orphaned? -- View this message in context: http://forum.world.st/MenuMorph-instances-tp4178039p4178039.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 9, 2011