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

[Pharo-project] Strange graphics effect (getting Pharo running on the RoarVM)
by Stefan Marr Nov. 10, 2010

Nov. 10, 2010

Hi: When I run Pharo on the RoarVM, I have some strange graphics effects. Maybe anyone has seen something similar in the past and could point me in the direction of the problem. The attached screenshot shows the effect I see while moving a window. All parts of the window, which were containing text are basically cut out, and the other windows in the back are visible instead. This effects seems to occur only while dragging/moving the window. As a reminder, we are using X11. So, if anyone remembers to have experiences something similar in the past, please let me know what the fix was. Thanks Stefan -- 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

3 3

[Pharo-project] Delay class not fit for RoarVM
by Stefan Marr Nov. 9, 2010

Nov. 9, 2010

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

1 0

[Pharo-project] Added Issue 3223 : Replace all sends to compile: in SystemNavigationTest by compileSilently:
by Luc Fabresse Nov. 9, 2010

Nov. 9, 2010

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

1 0

[Pharo-project] [ANN] DesignInfo on SqueakSource
by Bernhard Pieber Nov. 9, 2010

Nov. 9, 2010

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

1 0

[Pharo-project] Installing Glorp in Pharo 1.1
by glpunzi＠lordzealon.com Nov. 9, 2010

Nov. 9, 2010

Hi all, I'm trying to install Glorp in Pharo 1.1. I connected to Glorp Squeaksource repo, and Loaded the GlorpPharoLoader package. Then, I do: GlorpPharoLoader loadGlorpWithNativePostgreSQLDriver If I accept this windown, then a DNU appears. Images attached. Some idea? Thanks a lot..

4 5

[Pharo-project] Process-specific state broken and uncomplete
by Igor Stasenko Nov. 9, 2010

Nov. 9, 2010

Hello, i just found that Squeak images Process class contains unused ivars: island env in Pharo image, env ivar is used for holding a process-specific state, which is convenient, so one could use: Processor activeProcess environmentAt: put:... but in Squeak image there is even no such methods. There are also some caveats with such thing: during process termination, Processor activeProcess could point to different process, and so, accessing to process environment may lead to error(s). To avoid issues like these, the process termination action (stack unwinding) should be always performed only for active process. One of a trick i think, is to replace the suspendedContext with own context, and then activate given process in order to unwind its stack etc. Another way is to remember environment somewhere else during process termination, and use different method to access it i.e. instead of: Processor activeProcess environmentAt: use self processEnvironmentAt: where #processEnvironmentAt: is implemented in Object class, and can handle termination gracefully. But i think replacing suspendedContext is more generic. What you think? -- Best regards, Igor Stasenko AKA sig.

3 6

Re: [Pharo-project] Glorp
by Alan Knight Nov. 9, 2010

Nov. 9, 2010

I'm afraid I've been pretty swamped since getting back from ESUG and haven't had a chance to pursue it any further. Real soon now... At 02:28 PM 2010-11-02, Torsten Bergmann wrote: >Hi Alan, (cc pharo list) > >any news from the Glorp relicensing front? > >Thx >Torsten >-- >Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail -- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight(a)acm.org aknight(a)cincom.com http://www.cincom.com/smalltalk

1 0

Nov. 9, 2010

12231 ----- - Issue 3222: saveSession should return its resuming state Marcus apparently the new step for integrating is working. I may integrate some more this evening. Stef

1 0

Re: [Pharo-project] Issue 3222 in pharo: saveSession should return its resuming state
by pharo＠googlecode.com Nov. 9, 2010

Nov. 9, 2010

Comment #1 on issue 3222 by stephane.ducasse: saveSession should return its resuming state http://code.google.com/p/pharo/issues/detail?id=3222 Else we lose the resuming status of the save (ie whether the image is restarted or not).

1 1

Nov. 9, 2010

Issue 3222: saveSession should return its resuming state saveSession ^ self snapshot: true andQuit: false Else we lose the resuming status.... > On 9 November 2010 09:58, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>> what about using some variable, like: >>> >>> RunTests := true. >>> self saveimage. >>> RunTests := false. >>> self saveImage. >>> >>> and then in startUp: >>> >>> startUp: resuming >>> >>> ( resuming and: [ RunTests] ) ifTrue: [ self runTests ] >>> >> >> but my code is executed when a menu is selected. So the interaction with startUp: is not really good. >> > > snapshot: save andQuit: quit embedded: embeddedFlag > > answers the resuming flag. > > So, you can use it like: > > | resumedInFirstSnapshot | > resumedInFirstSnapshot := false. > > "first save" > (Smalltalk snapshot: save andQuit: false) ifTrue: [ ... "resuming here > " resumedInFirstSnapshot := true ] > "second save" > (Smalltalk snapshot: save andQuit: false) ifTrue: [ ... "resuming here > " resumedInFirstSnapshot ifFalse: [ ... ] ] > > > >> Stef >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

1 0