October 2014 - Pharo-dev - lists.pharo.org

GTDebugger popping up instead of the usual popup box.
by phil＠highoctane.be Oct. 30, 2014

Oct. 30, 2014

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

3 3

[pharo-project/pharo-core]
by GitHub Oct. 30, 2014

Oct. 30, 2014

Branch: refs/tags/40339 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] b7014a: 40339
by GitHub Oct. 30, 2014

Oct. 30, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: b7014a82ccef973a33d750746c93096ba68846a4 https://github.com/pharo-project/pharo-core/commit/b7014a82ccef973a33d75074… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-30 (Thu, 30 Oct 2014) Changed paths: A Nautilus.package/AbstractNautilusUI.class/instance/as yet unclassified/shiftedTextPaneMenuRequest.st M Refactoring-Changes.package/RBRefactoryChangeManager.class/instance/initialize-release/connectToChanges.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script339.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40339.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40339 14345 Replace Announcer>>#on:send:to:s senders in Refactoring-Changes https://pharo.fogbugz.com/f/cases/14345 10520 Right clicking on the source pane in Nautilus and clicking extended search itself produces a walkback https://pharo.fogbugz.com/f/cases/10520 http://files.pharo.org/image/40/40339.zip

1 0

[ANN] Pharo Days 2015
by Sven Van Caekenberghe Oct. 30, 2014

Oct. 30, 2014

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

3 2

[pharo-project/pharo-core]
by GitHub Oct. 30, 2014

Oct. 30, 2014

Branch: refs/tags/40338 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 3461c9: 40338
by GitHub Oct. 30, 2014

Oct. 30, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3461c9e17150b97bc90b9bd86127b046e4dfe7e3 https://github.com/pharo-project/pharo-core/commit/3461c9e17150b97bc90b9bd8… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-30 (Thu, 30 Oct 2014) Changed paths: R MorphicTests.package/HandBugsTest.class/README.md R MorphicTests.package/HandBugsTest.class/definition.st R MorphicTests.package/HandBugsTest.class/instance/accessing/testTargetPoint.st R MorphicTests.package/MorphBugsTest.class/README.md R MorphicTests.package/MorphBugsTest.class/definition.st R MorphicTests.package/MorphBugsTest.class/instance/accessing/adhereToEdgeTest.st R MorphicTests.package/MorphicUIBugTest.class/instance/private/findWindowInWorldLabeled_.st M MorphicTests.package/MorphicUIBugTest.class/instance/running/setUp.st M MorphicTests.package/MorphicUIBugTest.class/instance/running/tearDown.st R MorphicTests.package/MorphicUIBugTest.class/instance/tests/testOpenWorkspace.st M MorphicTests.package/RenderBugsTest.class/instance/private/long.st M MorphicTests.package/RenderBugsTest.class/instance/private/shouldntTakeLong_.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testForward.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testHeading.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testSetForward.st M MorphicTests.package/RenderBugsTest.class/instance/tests/testTestTime.st M MorphicTests.package/StickynessBugsTest.class/instance/tests/testForTiltedStickyness.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script338.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40338.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40338 14343 MorphicUIBugTest failing with GTPlayground active https://pharo.fogbugz.com/f/cases/14343 http://files.pharo.org/image/40/40338.zip

1 0

Re: [Pharo-dev] Question
by jdelgado＠lsi.upc.edu Oct. 29, 2014

Oct. 29, 2014

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 >

1 0

Question
by jdelgado＠lsi.upc.edu Oct. 29, 2014

Oct. 29, 2014

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? why? 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? 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 ].

2 1

**Important** PharoDays Preparation
by stepharo Oct. 29, 2014

Oct. 29, 2014

Hi guys We will organize at Lille the 29 and 30 of January PharoDays. Now to help us building a budget I would like to know if you already know that you plan to attend the conference. Could you fill up the doodle http://doodle.com/icxtazwfq76caxf8 Stef

3 3

Roassal2 in Pharo GTInspector
by Yuriy Tymchuk Oct. 29, 2014

Oct. 29, 2014

Hi, What should I do to be able to use roassal2 representation on Pharo? Because Iâve tried to load Roassal2 group form ConfigurationOfGlamour, but then it loads newer version of glamour which breaks in some way the inspector. Uko

3 4