April 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

April 2, 2015

[pharo-project/pharo-core] d1d881: 40592

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d1d881e547a6da3c8fe57208aa0833ad4a65e336 https://github.com/pharo-project/pharo-core/commit/d1d881e547a6da3c8fe57208… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-02 (Thu, 02 Apr 2015) Changed paths: M Komitter.package/KomitSliceUI.class/instance/initialization/initializeWidgets.st A MonticelloGUI.package/MCFileRepositoryInspector.class/instance/accessing/selectedPackageAncestors.st M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic ui/packageSelection_.st M MonticelloGUI.package/MCFileRepositoryInspector.class/instance/morphic ui/versionHighlightEmphasis_.st M MonticelloGUI.package/MCSliceMaker.class/instance/actions/downloadIssueSummary.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script591.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script592.st R ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40591.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40592.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForIssues_.st Log Message: ----------- 40592 15280 issue grabber should use new tracker app https://pharo.fogbugz.com/f/cases/15280 15234 monticello is not showing right status when working with branches https://pharo.fogbugz.com/f/cases/15234 http://files.pharo.org/image/40/40592.zip

April 2, 2015

Re: [Pharo-dev] GitHub SquareBracketAssociates

by Sean P. DeNigris

Jigyasa Grover wrote > I have sent an invite to join SquareBracketsAssociates. Thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitHub-SquareBracketAssociates-tp4816789p4816868.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 2, 2015

Re: [Pharo-dev] PharoV30.sources in Pharo 4.0 download

by Marcus Denker

> On 01 Apr 2015, at 22:23, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > > Is there a plan to condense changes and build a new sources file for the 4.0 release? > Yes! We will do it next week. And the nature of the whole mechanism is not very nice: it means that the artefact on the build server is not the artefact of releaseâ¦ always very annoying, as the code that you call once a year tend to be brokenâ¦ Marcus > Just curious > -cbc > > On Wed, Apr 1, 2015 at 1:18 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 01 Apr 2015, at 22:12, Dmitri Zagidulin <dmitri(a)zagidulin.net <mailto:dmitri@zagidulin.net>> wrote: >> >> I noticed that the Pharo 4.0 full distribution zip file off of Pharo.org/download <http://pharo.org/download> contains PharoV30.sources (and not, say, PharoV40.sources). >> This is true for all 3 platforms: >> - http://files.pharo.org/platform/Pharo4.0-mac.zip <http://files.pharo.org/platform/Pharo4.0-mac.zip> >> - http://files.pharo.org/platform/Pharo4.0-win.zip <http://files.pharo.org/platform/Pharo4.0-win.zip> >> - http://files.pharo.org/platform/Pharo4.0-linux.zip <http://files.pharo.org/platform/Pharo4.0-linux.zip> >> >> Is there a typo in a CI job somewhere? > > No, those are the latest sources :) The version simply tells you with what image the sources have been created (I presume). Anyway, the version number is not important. >

April 2, 2015

Re: [Pharo-dev] GitHub SquareBracketAssociates

by Jigyasa Grover

Hey Sean ! I have sent an invite to join SquareBracketsAssociates. Thanks and Regards Jigyasa Grover On Thu, Apr 2, 2015 at 3:10 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 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 2, 2015

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