- Pharo-dev - lists.pharo.org

[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

AioPlugin is back in linux VMs
by Esteban Lorenzano Oct. 29, 2014

Oct. 29, 2014

Hi, I reintroduced AioPlugin into the linux VM. In Mac it is there since always. In windows is irrelevant. So well, if you use linux and download the latest vm, you can play with it and check that everything is ok (or the contrary) :) Esteban

8 10

LivingCode was: Clickable class side example and initialize methods in Pharo 4.0
by kilon alios Oct. 29, 2014

Oct. 29, 2014

Dont know what you feed this monster but it took forever to load on Pharo 4 and now it gives me the error MNU receiver of "do:" is nil Pharo 3 seems to work ok, so from what I gather this is a flow chart representation of Smalltalk language, very interesting , I like it very much. Are you serious about this project or its just a little experiment for you ? Blender users have been wanting a flow based programming language for some time, I have been looking into Phratch but apparently most people prefer flow charts like yours because its what they are used to to as users inside Blender and other 3d apps. So its also an area that interests me too for example procedural creation of 3d objects which is an area that Blender lacks right now while other apps like Houdini and Softimage have again been based on flow chart languages like yours. The nice thing about your approach is that is inside Pharo so it does not lock down into a flow chart-only approach as most implementations do. So the user can use LiveCode to quickly create code and then use normal text code to customise and further refine. Does that make sense to you ? I was thinking creating something similar myself but I was afraid it would be too much work. So I am definitely interested to learn how far you want to go with this . On Thu, Oct 23, 2014 at 9:46 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > I guess so, although I am not really sure what I am looking at - but it > > seems very cool. > > > kilon.alios wrote > > What the hell is that, looks very interesting !!!! > > Ha ha, yeah I guess a bit of context would help ;) > > It's a prototype I've been working on that combines some of (IMHO) the best > IDE ideas of various systems. That particular one shows Self Outliners (the > Morphs on the left of the connector). By pressing $M when an outliner has > the focus, you get a "Message Menu" of Scratch-like interactive tiles for > all the messages it understands. You can click on the unary messages or > type > expressions for the ones taking arguments (actually just realized that the > binary ones don't work so just keyword messages right now). When the > message > is sent, a new Self Outliner open(s)InHand on the result. > > It's a WIP, but if you want to play, start with: > > 1. > Gofer it > smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; > configurationOf: 'LivingCode'; > load. "Strangely I can not #loadDevelopment here because the > ScrollableWorldMorph package doesn't get loaded, even though it does with > the next line" > #ConfigurationOfLivingCode asClass project development load. > #SelfWorld asClass open. > > 2. Then in the search bar, type an evaluatable expression, e.g. "1" and > accept > 3. Drop the Outliner from the hand into the Self World > 4. For fun, click the world background and drag. OMG, you have an infinite > world > 5. Click on the M button in the outliner and the message menu will appear > (erroneously in the World instead of the Self World). > 6. Expand e.g. the "bit manipulation" protocol (assuming you started with > "1" as above) > 7. Click into the text field to the right of bitAnd: and accept the text > A new Outliner of the result will appear in the hand > > Other buttons on the Outliner: > B - open a nautilus on the class of the object > I - traditional inspector > S - open the test class if it exists (I call them Specification(s) in my > personal work) > E - Evaluator (very close to Self) > > Also, if you click on the icons to the right of "class" and "package" > Outliner(s) will appear on those objects. > > That's pretty much it for now. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Clickable-class-side-example-and-initialize-methods-i… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

3 3