- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Nicolai Hess

2015-04-01 18:56 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > Issue 14606 [1] is tagged "Really Important" where evaluating.... > > | t1 t2 t3 t4 t5 t6 | > t1 := 1. > t2 := 2. > t3 := 3. > t4 := 4. > t5 := 5 . > t6 := 6. > [ t5 := 50. > t6 := 60. > t3 + t4. > 1 halt. > ] value > > => can't see the value of t4, t5, t6. > > I've just submitted a possible solution for this, but its a bit late > before release for such a change - so I'm asking for "all hands in" to help > stress test it. You don't need to review code, just please merge latest > slice 14606 into your normal working image and report your experience. > > cheers -ben > > [1] https://pharo.fogbugz.com/default.asp?14606#124466 > > Here is a minimal example that does not work with your fix. (condensed from the failing test case) [ :x :y | (thisContext tempNamed: 'x') inspect. (1 to: 1) do: [ :i | | k l | k := y. l := x. (thisContext tempNamed: 'x') inspect ] ] value: 1 value: 23 Both inspector windows should show the same value for the argument 'x'. But the result is 1. inspector -> 1 2. inspector -> 23

April 1, 2015

GitHub SquareBracketAssociates

by Sean P. DeNigris

Will someone please add me to the team. Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-SquareBracketAssociates-tp4816789.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 1, 2015

Re: [Pharo-dev] Bloc Roadmap

by Sean P. DeNigris

>> > yes, we know, we are preparing a documentation. >> Great! Is the WIP publicly available (e.g. in one of our Pillar/GitHub repos)? Btw. the class comments are reeeally great! I'm only talking about documenting design rationale. > We did them twice :) I'm probably looking in the wrong place. Do you have links? > To doc in on github pharo progress. This? https://github.com/SquareBracketAssociates/PharoInProgress/blob/master/Bloc… > Continue to ask so that we can extract the information from his mind. Okay! :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Roadmap-tp4816171p4816788.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 1, 2015

Re: [Pharo-dev] Enhancing the AST API

by Thierry Goubier

Le 01/04/2015 22:34, stepharo a Ã©crit : > >> Well, I'm allways under the assumption that an instance variable is >> internal only and that, when querying an AST node, I should allways >> use its API (is that usually #startPosition and #stopPosition?). >> > Me too > The implication of my proposal is to also rename all the accessors so > that the get proper names... which of course they do not have. Fair enough. Still, Proper name is proper in a context. I allways try to follow a simple guideline which is: choose a memorable name, adapted to the code it is in use in, and as much as possible understandable. But understandable comes second. And if a long term name is used consistently everywhere, I'll keep it as it is (respecting existing documentation, memory, other developper knowledge and work, etc...) instead of changing it. Thierry

April 1, 2015

Re: [Pharo-dev] Binding semantics of SystemDictionary

by stepharo

Please do not use Smalltalk at: We will ban it for real! Stef Le 31/3/15 20:49, Max Leske a Ã©crit : > Hi > > Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example: > > class := Class new > setName: 4; > yourself. > Smalltalk > at: class name > put: class. > > So we now have a class with name 4 (which is a SmallInteger): > > self assert: (Smalltalk at: 4) == class. > > > There are basically two different issues: > 1. SystemDictionary will store any kind of association, not only symbols / strings arghhhh > 2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object: > > class := Class new > setName: (String streamContents: [ :s | s nextPutAll: 'someName']); > yourself. > Smalltalk > at: class name > put: class. > > Smalltalk > at: (String streamContents: [ :s | s nextPutAll: 'someNameâ]) > ifAbsent: [ false ]. âââ> falseâ > > > In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If thatâs not the case bad things happen. > It would help us a lot if we could clear up the semantics of bindings in SystemDictionary: > 1. Are bindings with keys that are not ByteString or ByteSymbol valid? > 2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)? > 3. If we allow ByteString, do we also allow WideString? > 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? > > > Any suggestions are welcome. > > Cheers, > Max >

April 1, 2015

Re: [Pharo-dev] Bloc Roadmap

by Alain Plantec

> > >> >> > Weâve implemented a lot of examples. please have a look. >> Thanks - I have and they are also great. But AFAICT it's impossible to tell from the examples /why/ e.g. we went from Morphs owning their step actions to block-based steps registered with a scheduler that is universal to all worlds. I have a doubt about that because one use case I've had in Morphic is to speed up time in a world to see what happens e.g. in 10 minutes from now, but #schedule hard-codes the reference to the BlUniverse singleton. Morphic uses two global queues (hold by the world state) one for stepping and the other for the alarms. bloc have only one global queue for stepping and alarms. basically the same kind of implementation as in morph. and again, any class can declare and manage its own AlarmQueues. :) Alain

April 1, 2015

Got a strange font bug

by stepharo

HI we were improving the selection of instance variables of the refactorings via nautilus when suddenly the font got broken. We got a problem with strikefont holding a number of something like that. Impossible to debug - it would be great to have a rescue path (may be via the EmergencyEvalutor) - the only thing that we could do was to kill the image and restart I suspect a problem with the FTPlugin. Stef

April 1, 2015

Re: [Pharo-dev] [ANN] Pharo Consortium New Academic Partner: UMMISCO

by stepharo

Welcome UMMISCO Stef Le 1/4/15 14:47, Marcus Denker a Ã©crit : > The Pharo Consortium is very happy to announce that UMMISCO > has joined the Consortium as an Academic Partner. > > UMMISCO is an international research unit under the supervision of IRD > (Research for Development) and UPMC (UniversitÃ© Pierre Marie Curie) > located in France, Senegal, Morocco, Cameroun and Vietnam. UMMISCO > group carries out research in Computer Science and Mathematics with > the goal of modelling and simulation of complex systems with > applications regarding southern countries concerns like : epidemiology > modelling, disaster management, urban mobility and environmental > monitoring. > > About > > - UMMISCO: http://www.ummisco.ird.fr > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > Individuals can support Pharo via the Pharo Association: > > http://association.pharo.org >

April 1, 2015

Re: [Pharo-dev] Bloc Roadmap

by Alain Plantec

> On 01 Apr 2015, at 22:15, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > yes, we know, we are preparing a documentation. > Great! Is the WIP publicly available (e.g. in one of our Pillar/GitHub repos)? Btw. the class comments are reeeally great! I'm only talking about documenting design rationale. https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc <https://github.com/SquareBracketAssociates/PharoInProgress/tree/master/Bloc> see blocCore.pillar work in progress... > > > Weâve implemented a lot of examples. please have a look. > Thanks - I have and they are also great. But AFAICT it's impossible to tell from the examples /why/ e.g. we went from Morphs owning their step actions to block-based steps registered with a scheduler that is universal to all worlds. I have a doubt about that because one use case I've had in Morphic is to speed up time in a world to see what happens e.g. in 10 minutes from now, but #schedule hard-codes the reference to the BlUniverse singleton. Bloc use Alarms, Stepping will be removed. Each space has its own queue of alarms but nothing prevent a morph to have its own queue. Now, steps and alarms are not limited to use blocks, one can use message send also. Cheers Alain > Cheers, > Sean > > View this message in context: Re: Bloc Roadmap <http://forum.world.st/Bloc-Roadmap-tp4816171p4816769.html> > Sent from the Pharo Smalltalk Developers mailing list archive <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at Nabble.com.

April 1, 2015

Re: [Pharo-dev] Bloc Roadmap

by stepharo

> > yes, we know, we are preparing a documentation. > Great! Is the WIP publicly available (e.g. in one of our Pillar/GitHub > repos)? Btw. the class comments are reeeally great! I'm only talking > about documenting design rationale. We did them twice :) And some of them should be improved. To doc in on github pharo progress. Now I started to document the classes so that after I can generate part of the doc :) > > Weâve implemented a lot of examples. please have a look. > Thanks - I have and they are also great. But AFAICT it's impossible to > tell from the examples /why/ e.g. we went from Morphs owning their > step actions to block-based steps registered with a scheduler that is > universal to all worlds. I have a doubt about that because one use > case I've had in Morphic is to speed up time in a world to see what > happens e.g. in 10 minutes from now, but #schedule hard-codes the > reference to the BlUniverse singleton. Good question alain will answer. Continue to ask so that we can extract the information from his mind. > Cheers, > Sean > > ------------------------------------------------------------------------ > View this message in context: Re: Bloc Roadmap > <http://forum.world.st/Bloc-Roadmap-tp4816171p4816769.html> > Sent from the Pharo Smalltalk Developers mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at > Nabble.com.

April 1, 2015