- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GTDebugger popping up instead of the usual popup box.

by Tudor Girba

What would you expect in this case? Doru On Thu, Oct 30, 2014 at 9:37 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > While loading a package with missing classes, I get > > > [image: Inline image 1] > > Instead of the normal popup with a choice. > > Pharo3+GT > > How to handle this case? > > Phil > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 30, 2014

GTDebugger popping up instead of the usual popup box.

by phil＠highoctane.be

While loading a package with missing classes, I get [image: Inline image 1] Instead of the normal popup with a choice. Pharo3+GT How to handle this case? Phil

Oct. 30, 2014

Re: [Pharo-dev] unexpected merge conflict

by Marcus Denker

> On 29 Oct 2014, at 23:35, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > In a fresh Pharo 4 image I want to merge a package (Glamour-Presentations) but I get a merge conflict. > > Nevertheless, the package from the image has no changes and the package cache is empty. Shouldn't there be no merge conflict in this case? > I think we do not have the repositories defined correctly for these packages. (or alternatively, the current packages need to be in the pharo repo which is not the case). Marcus

Oct. 30, 2014

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Days 2015

by FranÃ§ois Stephany

I can host one or two people at my place in Mons, Belgium (~1h drive from INRIA Lille) for free. I can drive to the conference both days. In the best case, I might have some friends to host me (us?) in Lille. So we can have some beers without having to drive. Francois On Wed, Oct 29, 2014 at 4:18 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > We are excited to announce the details so far for the Pharo Days 2015, to > be held on Thursday January 29 and Friday January 30 at INRIA, Lille, > France. > > > https://medium.com/@svenvc/pharo-days-2015-6336d6ee2a23 > > > Weâll update this page moving forward. You can ask questions on the any of > the Pharo mailing lists or you can email the Pharo Board. > > > Official registration is not yet open, but there is a Doodle that should > give an indication of who is coming and that can help us plan resources. > > > http://doodle.com/icxtazwfq76caxf8 > > > The Pharo Board >

Oct. 29, 2014

[ANN] Pharo Days 2015

by Sven Van Caekenberghe

We are excited to announce the details so far for the Pharo Days 2015, to be held on Thursday January 29 and Friday January 30 at INRIA, Lille, France. https://medium.com/@svenvc/pharo-days-2015-6336d6ee2a23 Weâll update this page moving forward. You can ask questions on the any of the Pharo mailing lists or you can email the Pharo Board. Official registration is not yet open, but there is a Doodle that should give an indication of who is coming and that can help us plan resources. http://doodle.com/icxtazwfq76caxf8 The Pharo Board

Oct. 29, 2014

unexpected merge conflict

by Andrei Chis

Hi, In a fresh Pharo 4 image I want to merge a package (Glamour-Presentations) but I get a merge conflict. Nevertheless, the package from the image has no changes and the package cache is empty. Shouldn't there be no merge conflict in this case? The package is here (its the latest version): MCSmalltalkhubRepository owner: 'Moose' project: 'Glamour' user: '' password: '' Cheers, Andrei

Oct. 29, 2014

Trouble while defining a customized tab in GT inspector

by Luc Fabresse

Hi all, I try to play with the GT inspector (thx Andrei and Doru for the great hands on session @ ESUG'14!). In short, I try to add a customized tab for Persons objects using a PersonUI facade and a subclass of GTObjectVariablesBrowser (ok I can explain why if needed ;-)). Like that: Person>>gtInspectorCustomUIIn: composite <gtInspectorPresentationOrder: 5> ^ (composite custom: (MyGTCustomObjectVariablesBrowser new startOn: (PersonUI on: self) )) " <----- HERE" title: 'Customized view'; yourself But, the #variableValuePairsFor: message is not sent to the PersonUI object but to the Person object even if I passed a PersonUI one to the #startOn: method (cf. HERE). startOn: seems to not store properly the object to use afterwards or I missed a something. Did I? please find a code sample attached if needed. Try: Person new inspect Thx for any hint, Cheers, #Luc

Oct. 29, 2014

Re: [Pharo-dev] Question

by jdelgado＠lsi.upc.edu

Thanks a lot, Eliot! Bests, Jordi > On Wed, Oct 29, 2014 at 9:48 AM, <jdelgado(a)lsi.upc.edu> wrote: > >> Hi all, >> >> ------------------------------------------------ >> My question is: >> One thing I've observed is that local/temporal variables in the blocks >> passed to #ifTrue:iFfalse are not stored in the separate remote (heap >> allocated) array, but in the method context (see page 328 of Deep Into >> Pharo to see what I mean). Is this true? > > > yes. > > >> why? >> > > because the blocks don't really exist. they have been optimized away and > the control flow implemented using conditional branches and jumps instead > of closures and polymorphism. Hence there is no other scope to hold > temps > in other than the method context (or the block context of a block > containing optimized blocks). > > But realise that the remote temp vector is *only* used for variables that > are referred to from more than one full scope (method or unoptimized > block) > that can change value after they have been closed-over. If a variable is > closed over but doesn't change then its value is copied into the block, > and > ends up in a temporary slot in the block's activation, not in the > indirection vector. > > > >> Thanks in advance, >> >> Bests, >> >> Jordi >> ------------------------------------------------ >> >> PS: >> Now, to put that question in context, here comes a really long "rest of >> the message" part. >> >> We assume we have Continuation class >> #callcc: implemented as: >> callcc: aBlock >> ^ Continuation currentDo: aBlock >> (#callcc: can be found in ContinuationTests, but I prefer to change >> its location. It does not matter at all where it is). >> >> A version of whileTrue: can be implemented with callcc: and no >> iterative constructs, let's call it BlockClosure >> #whileTrueCC: >> whileTrueCC: aBlock >> | cont | >> cont := Continuation callcc: [ :cc | cc ]. >> self value ifTrue: [ aBlock value. >> cont value: cont] >> ifFalse: [^ nil]. >> >> and you can use it in the same way as #whileTrue:, for example: >> | n | >> n := 10. >> [ n > 0 ] whileTrueCC: [ >> Transcript show: n asString; cr. >> n := n-1 ] >> >> I observed some strange behavior dealing with local variables and >> continuations. Assume we have: >> >> Version 1) >> whileTrueCC: aBlock >> | cont tmp | >> tmp := 0. >> cont := Continuation callcc: [ :cc | cc ]. >> self value ifTrue: [ aBlock value. >> Transcript show: 'inside whileTrueCC: -> ', >> tmp >> asString; cr. >> tmp := tmp + 1. >> cont value: cont] >> ifFalse: [^ nil]. >> >> Version 2) >> whileTrueCC: aBlock >> | cont tmp | >> tmp := 0. >> [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does >> nothing, apparently" >> cont := Continuation callcc: [ :cc | cc ]. >> self value ifTrue: [ aBlock value. >> Transcript show: 'inside whileTrueCC: -> ', >> tmp >> asString; cr. >> tmp := tmp + 1. >> cont value: cont] >> ifFalse: [^ nil]. >> >> I try both versions with: >> | n | >> n := 4. >> [ n > 0 ] whileTrueCC: [ n := n-1 ] >> >> Version 1: >> It writes in the Transcript: >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 0 >> >> Version 2: >> It writes in the Transcript: >> inside whileTrueCC: -> 0 >> inside whileTrueCC: -> 1 >> inside whileTrueCC: -> 2 >> inside whileTrueCC: -> 3 >> >> Which is ok, according to what I understood from Deep Into Pharo. The >> thing is, why the ifTrue: block does not make tmp behave as when we >> close >> it with '[ tmp ]' in version 2? >> > > See above. The compiler is not smart enough to realise that the value of > [tmp] is discarded, so it thinks there is a block created that closed over > tmp which may be evaluated at any time (because it could get assigned to a > variable and used later). So tmp is modified *after* it has been closed > over (in the while block) and hence the compiler puts it in a temp vector. > > > PS 2: The behavior is *exactly* the same in Version 2 if I close tmp >> *after* grabbing the continuation, that is, if I go >> cont := Continuation callcc: [ :cc | cc ]. >> [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does >> nothing, apparently" >> instead of >> [ tmp ]. "<-------- Only difference wrt Version 1 !!!! It does >> nothing, apparently" >> cont := Continuation callcc: [ :cc | cc ]. >> > > > -- > best, > Eliot >

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Eliot Miranda

On Wed, Oct 29, 2014 at 12:14 PM, Ben Coman <btc(a)openinworld.com> wrote: > Holger Hans Peter Freyther wrote: > >> On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter Freyther >> wrote: >> >>> On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: >>> >>> Good Evening, >>> >> >> Hi again, >> >> I don't know how you debug startUp issues. I just added an >> OrderedCollection >> into the systemdictionary and use it as a log.. >> >> time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay forSeconds: >> 3) wait. (Smalltalk at: #Foo) do: [:each | FileStream stderr nextPutAll: >> each printString; cr].1" >> ... old events from saving the image... >> {#handleTimerEvent->7147} >> {#handleTimerEvent->7167} >> {#resumptionTime->7187} >> {#handleTimerEvent->7167} >> {#handleTimerEvent->7187} >> {#start->true} >> {#start->393102159} >> {#start->393102159} >> {#resumptionTime->3279} >> {#handleTimerEvent->279} >> {#adjustResum->-393098880} >> {#restoreWithActiveDelay->266} >> {#adjustResum->-393098601} >> 1 >> >> real 0m0.294s >> user 0m0.244s >> sys 0m0.048s >> >> >> So what happens is Delay class>>#startU is called. and >> ActiveDelayStartTime is being set to 393102159. Then the >> delay is being created and resumptionTime is set to 3279. >> At the first time handleTimerEvent runs the milliSecondClock >> jumped backwards from 393102159 to 3279 which leads to >> an adjustment of the time. >> >> >> a.) Why does the time jump backwards like this during the >> resumption of the image? "3279" is not the old time nor >> the new starting time. >> >> b.) So even if that is a "wrap" around. Why does it go >> wrong? Are there unit tests for the clock wraps around? >> > > There are no unit tests, I guess since its all done using class variables > its too hard test without disturbing the system. > > Now I have spent the last week refactoring this out to the instance-side > of a new class "DelayScheduler" which should help with getting unit tests. > Its ready for review [1], maybe you could take a look. > > [1] https://pharo.fogbugz.com/default.asp?14261 > > Maybe it is the same reason delays just don't work after >> image resumption? >> >> The "first" issue appears that when start is being executed >> that the clock is still wrong. At the same the clock is >> being considered wrapped the resumption time was actually >> already "correct' (3279 instead of 393102159+3279). >> >> Does this ring a bell? >> >> holger >> >> >> > btw, its too late in the night for me to try something, but I have been > wondering, should the check for clock roll-over occur immediately after > TimingSemaphore wait > wakes up. That is, before the Schedule and Finish requests are handled ??? > The check for rollover should be thrown away and the system implemented over the VM's support for 64-bit microseconds since 1901. It's in the VM, it isn't susceptible to rollover for ~ 50,000 years, and doesn't require the millisecond clock to be synced to the second clock, because all times can be derived from the one 64-bit microsecond clock. -- best, Eliot

Oct. 29, 2014

Re: [Pharo-dev] Super fast delay

by Ben Coman

Holger Hans Peter Freyther wrote: > On Wed, Oct 29, 2014 at 06:54:57PM +0100, Holger Hans Peter Freyther wrote: >> On Wed, Oct 29, 2014 at 10:03:03AM +0100, Norbert Hartl wrote: >> >> Good Evening, > > Hi again, > > I don't know how you debug startUp issues. I just added an OrderedCollection > into the systemdictionary and use it as a log.. > > time ./bin/pharo --nodisplay ./TimerTest3.image eval "(Delay forSeconds: 3) wait. (Smalltalk at: #Foo) do: [:each | FileStream stderr nextPutAll: each printString; cr].1" > ... old events from saving the image... > {#handleTimerEvent->7147} > {#handleTimerEvent->7167} > {#resumptionTime->7187} > {#handleTimerEvent->7167} > {#handleTimerEvent->7187} > {#start->true} > {#start->393102159} > {#start->393102159} > {#resumptionTime->3279} > {#handleTimerEvent->279} > {#adjustResum->-393098880} > {#restoreWithActiveDelay->266} > {#adjustResum->-393098601} > 1 > > real 0m0.294s > user 0m0.244s > sys 0m0.048s > > > So what happens is Delay class>>#startU is called. and > ActiveDelayStartTime is being set to 393102159. Then the > delay is being created and resumptionTime is set to 3279. > At the first time handleTimerEvent runs the milliSecondClock > jumped backwards from 393102159 to 3279 which leads to > an adjustment of the time. > > > a.) Why does the time jump backwards like this during the > resumption of the image? "3279" is not the old time nor > the new starting time. > > b.) So even if that is a "wrap" around. Why does it go > wrong? Are there unit tests for the clock wraps around? There are no unit tests, I guess since its all done using class variables its too hard test without disturbing the system. Now I have spent the last week refactoring this out to the instance-side of a new class "DelayScheduler" which should help with getting unit tests. Its ready for review [1], maybe you could take a look. [1] https://pharo.fogbugz.com/default.asp?14261 > Maybe it is the same reason delays just don't work after > image resumption? > > The "first" issue appears that when start is being executed > that the clock is still wrong. At the same the clock is > being considered wrapped the resumption time was actually > already "correct' (3279 instead of 393102159+3279). > > Does this ring a bell? > > holger > > btw, its too late in the night for me to try something, but I have been wondering, should the check for clock roll-over occur immediately after TimingSemaphore wait wakes up. That is, before the Schedule and Finish requests are handled ??? cheers -ben

Oct. 29, 2014