November 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Delay class not fit for RoarVM

by Stefan Marr

Hi: I ran into a little trouble with the Delay class. David thought he had fixed it already, but there was another problem to get Pharo running multicore. The fundamental problem is, that Delay relies on scheduler implementation details. More precisely, it uses a single class variable to communicate the delay it wants to schedule (self) to the handleTimerEvent loop. This cannot work on RoarVM, at every point in time, there can be multiple processes which all want to schedule a Delay, and the guarantees for impossible interleavings the current implementation is requiring are not given anymore. Below are two, well, dirty hacks, to fix the problem. Better solutions are very welcome. I do not really like the busy wait, however, other solutions add more overhead. I could imaging a semaphore based synchronization, but with the current semaphore implementation it is kind of tricky to get the initialization right. The biggest problem is the actual writing of that code, since changing Delay is not the most safe operation... Another solution could involve a synchronized/atomic queue to communicate the Delays to the handler loop. Beyond the implementation, it would be also interesting to discuss how such fixes, that are specific to RoarVM should be handled. Do you want to support it? Thanks Stefan PS: those fixes should also work for Squeak, but I haven't tested it yet. !Delay methodsFor: 'private' stamp: 'StefanMarr 11/9/2010 23:38' prior: 47886371! schedule "Schedule this delay" | delayDelivered | delayDelivered := false. beingWaitedOn ifTrue: [^self error: 'This Delay has already been scheduled.']. resumptionTime := Time millisecondClockValue + delayDuration. [AccessProtect critical: [ ScheduledDelay ifNil: [ ScheduledDelay := self. TimingSemaphore signal. delayDelivered := true. ] ]. delayDelivered ] whileFalse.! ! !Delay methodsFor: 'private' stamp: 'StefanMarr 11/9/2010 23:39' prior: 47885691! unschedule | delayDelivered | delayDelivered := false. [AccessProtect critical: [ ScheduledDelay ifNil: [ FinishedDelay := self. TimingSemaphore signal. delayDelivered := true. ] ]. delayDelivered ] whileFalse.! ! !Delay class methodsFor: 'timer process' stamp: 'StefanMarr 11/9/2010 17:44' prior: 19672467! handleTimerEvent "Handle a timer event; which can be either: - a schedule request (ScheduledDelay notNil) - an unschedule request (FinishedDelay notNil) - a timer signal (not explicitly specified) We check for timer expiry every time we get a signal." | nowTick nextTick | "Wait until there is work to do." TimingSemaphore wait. "Process any schedule requests" ScheduledDelay ifNotNil:[ "Schedule the given delay" self scheduleDelay: ScheduledDelay. ScheduledDelay := nil. ]. "Process any unschedule requests" FinishedDelay ifNotNil:[ self unscheduleDelay: FinishedDelay. FinishedDelay := nil. ]. "Check for clock wrap-around." nowTick := Time millisecondClockValue. nowTick < ActiveDelayStartTime ifTrue: [ "clock wrapped" self saveResumptionTimes. self restoreResumptionTimes. ]. ActiveDelayStartTime := nowTick. "Signal any expired delays" [ActiveDelay notNil and:[nowTick >= ActiveDelay resumptionTime]] whileTrue:[ ActiveDelay signalWaitingProcess. SuspendedDelays isEmpty ifTrue: [ActiveDelay := nil] ifFalse:[ActiveDelay := SuspendedDelays removeFirst]. ]. "And signal when the next request is due. We sleep at most 1sec here as a soft busy-loop so that we don't accidentally miss signals." nextTick := nowTick + 1000. ActiveDelay ifNotNil:[nextTick := nextTick min: ActiveDelay resumptionTime]. nextTick := nextTick min: SmallInteger maxVal. "Since we have processed all outstanding requests, reset the timing semaphore so that only new work will wake us up again. Do this RIGHT BEFORE setting the next wakeup call from the VM because it is only signaled once so we mustn't miss it." "No!!!! If running multicore, TimingSemaphore may have already been signalled!!!! Do not reset signals, because then we will miss it -- dmu 9/26/10" RVMPrimitives coreCount > 1 ifFalse: [TimingSemaphore initSignals]. "Do not wait till the next Delay if Semaphore already signaled. -- dmu 9/26/10" TimingSemaphore isSignaled ifFalse: [ Delay primSignal: TimingSemaphore atMilliseconds: nextTick. ]. "This last test is necessary for the obscure case that the msecs clock rolls over after nowTick has been computed (unlikely but not impossible). In this case we'd wait for MillisecondClockMask msecs (roughly six days) or until another delay gets scheduled (which may not be any time soon). In any case, since handling the condition is easy, let's just deal with it" Time millisecondClockValue < nowTick ifTrue:[TimingSemaphore signal]. "retry" ! ! -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 9, 2010

Re: [Pharo-project] Strange graphics effect (getting Pharo running on the RoarVM)

by Stefan Marr

Hi: On 09 Nov 2010, at 17:00, Juan Vuletich wrote: > Looks like you're using an outdated, buggy BitBlt plugin. I fixed several issues there some time ago. Thank you all, that seems to be the problem. Have ported the changes from [1], and it works beautiful :) Bye the way, there are a number of 'unsigned int's in function declarations which probably are supposed to by usqInt for consistency. Thanks Stefan [1] http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/unix/src/vm/intplug… -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 9, 2010

Re: [Pharo-project] About SourcedMethodReference

by Igor Stasenko

I think identity is better. It forcing more strict rules: no more than one method reference in system necessary for representing same method. On 9 November 2010 23:48, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi all, > WhenÂ SourcedMethodReference have been introduced, some tests in > SystemNavigationTest turned yellow. > The tests are currently expecting a MethodReference. > If I modify the tests to exepect a SourcedMethodReference, the problem is > now on: > SourcedMethodReference>>= > Â Â Â Â ^self == aMethodReference. > Why this has been redefined inÂ SourcedMethodReference? > I think that the super class (MethodReference)Â implementation is > semantically better. No? > > MethodReference>>= anotherMethodReference > "Answer whether the receiver and the argument represent the > same object." > ^ self species == anotherMethodReference species > and: [(self classSymbol = anotherMethodReference classSymbol) > and: [(self classIsMeta = anotherMethodReference classIsMeta) > and: [self methodSymbol = anotherMethodReference methodSymbol]]] > #Luc > -- Best regards, Igor Stasenko AKA sig.

Nov. 9, 2010

[Pharo-project] About SourcedMethodReference

by Luc Fabresse

Hi all, When SourcedMethodReference have been introduced, some tests in SystemNavigationTest turned yellow. The tests are currently expecting a MethodReference. If I modify the tests to exepect a SourcedMethodReference, the problem is now on: SourcedMethodReference>>= ^self == aMethodReference. Why this has been redefined in SourcedMethodReference? I think that the super class (MethodReference) implementation is semantically better. No? MethodReference>>= anotherMethodReference "Answer whether the receiver and the argument represent the same object." ^ self species == anotherMethodReference species and: [(self classSymbol = anotherMethodReference classSymbol) and: [(self classIsMeta = anotherMethodReference classIsMeta) and: [self methodSymbol = anotherMethodReference methodSymbol]]] #Luc

Nov. 9, 2010

Re: [Pharo-project] #& in Socket >> #waitForSendDoneFor:

by Schwab,Wilhelm K

Phillipe, The *possible* connection is that pushing limits has a way of making otherwise benign problems show themselves. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Philippe Marschall [kustos(a)gmx.net] Sent: Tuesday, November 09, 2010 2:21 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #& in Socket >> #waitForSendDoneFor: > IMHO, the socket should do what it is asked to do, blocking only the calling thread, and let other threads and/or the user decide when that is taking too long. What does this have to do with replacing a #& with a #and:? > Could you be getting timeouts that are causing unexpected behavior? I don't think so, see above. Since I can't reproduce it anymore it was probably a measuring inaccuracy (~3 %). However I think it's still worthwhile replacing that #&. Cheers Philippe

Nov. 9, 2010

Re: [Pharo-project] Howto measure memory footprints of functions/objects/libraries in Pharo?

by Alexandre Bergel

Hi Max, > Um... I should be able to get a visualisation by running somthing like this right (I only installed it, didn't subclass anything)? > > MemoryProfiler > viewProfiling: [ FSDiskFilesystem current working / foo ]. > > I get a window but there's nothing in it... The piece of code you want to profile needs is executed twice, and it needs "to be time consuming" (~ 1 second). For example, try: MemoryProfiler viewProfiling: [ | view | view := MOViewRenderer new. view nodes: (1 to: 5000). view root applyLayout ] or MemoryProfiler viewProfiling: [ (1 to: 2) collect: [ :i | ConfigurationOfMetacello project currentVersion ] ] to get a nice picture > Also, is selecting the expression in the block above, right clicking and selecting "memory profile it" equivalent to sending #viewProfiling: ? yes > Reading your paper I get the idea that this should work, when looking at the instructions on the moose site it rather seems that I need to subclass MemoryProfiler to actually profile anything. No need to subclass. Cheers, Alexandre > > > > On 09.11.2010, at 15:02, Alexandre Bergel wrote: > >> Ok, but please, provide feedback. >> >> Alexandre >> >> >> On 9 Nov 2010, at 10:40, Max Leske wrote: >> >>> Sounds like what I just needed! I'll try it out. >>> >>> Cheers, >>> Max >>> >>> >>> On 09.11.2010, at 12:42, Alexandre Bergel wrote: >>> >>>> Hi Guido, >>>> >>>> We wrote a profiler to keep track of memory consumption. >>>> >>>> http://bergel.eu/download/papers/Berg10g-MemoryProfiling.pdf >>>> >>>> It will be presented at Smalltalks next week. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> On 8 Nov 2010, at 23:47, Guido Stepken wrote: >>>> >>>>> E.g.: Three different solutions for a Euler problem: >>>>> >>>>> (1 to: 999) inject: 0 into: [:sum :i | (i \\ 3 = 0) | (i \\ 5 = 0) >>>>> ifTrue: [sum + i] >>>>> ifFalse: [sum]] >>>>> >>>>> >>>>> (1 to: 999) detectSum: [:i | (i \\ 3 = 0) | (i \\ 5 = 0) ifTrue: [i] ifFalse: [0]] >>>>> >>>>> (1 to: 999) detectSum: [:i | i * (#(0 0 1 0 1 1 0 0 1 1 0 1 0 0 1) atWrap: i)] >>>>> >>>>> How do i measure the exact memory footprint of each solution? >>>>> >>>>> Pharo claims having reduced memory footprint at many places. Can that be proofed, e.g. with one comparable demo app, once run in old squeak, once in Pharo 1.1/1.2? >>>>> >>>>> And no, MessageTally spyOn: does not do right! >>>>> >>>>> Tnx in advance, Guido Stepken >>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 9, 2010

Re: [Pharo-project] Issue 3223 in pharo: Replace all sends to compile: in SystemNavigationTest by compileSilently:

by pharo＠googlecode.com

Updates: Status: Fixed Labels: Milestone-1.2 Comment #1 on issue 3223 by stephane.ducasse: Replace all sends to compile: in SystemNavigationTest by compileSilently: http://code.google.com/p/pharo/issues/detail?id=3223 Thanks

Nov. 9, 2010

[Pharo-project] Added Issue 3223 : Replace all sends to compile: in SystemNavigationTest by compileSilently:

by Luc Fabresse

Fix in pharo task forces Tests-LucFabresse.242 #Luc

Nov. 9, 2010

[Pharo-project] Issue 3223 in pharo: Replace all sends to compile: in SystemNavigationTest by compileSilently:

by pharo＠googlecode.com

Status: Accepted Owner: luc.fabresse New issue 3223 by luc.fabresse: Replace all sends to compile: in SystemNavigationTest by compileSilently: http://code.google.com/p/pharo/issues/detail?id=3223 This make the tests faster and cleaner. In pharo task forces. Tests-LucFabresse.242

Nov. 9, 2010

[Pharo-project] [ANN] DesignInfo on SqueakSource

by Bernhard Pieber

Dear Squeakers and Pharoers, I did it! I registered my first mini project on SqueakSource: http://www.squeaksource.com/DesignInfo.html A DesignInfo collects the following information and metrics about the design of a package: lines of code lines of production code lines of test code percentage of production code percentage of test code It can create morphs that show a bar chart of the lines of code of all Monticello packages, sorted either by package name or by lines of code. The bar chart also shows the percentage of production versus test code. Balloon help is used to show detailed information about a package. I used it to create the lines of code bar chart for Squeak and Pharo: http://bpieber.wordpress.com/2010/11/07/lines-of-code-of-squeak-and-pharo/ Cheers, Bernhard

Nov. 9, 2010