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

[pharo-project/pharo-core] 8415a3: 30802
by GitHub March 26, 2014

March 26, 2014

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 8415a33051a1b45ef02a5df2dc37ee30650a57a2 https://github.com/pharo-project/pharo-core/commit/8415a33051a1b45ef02a5df2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-26 (Wed, 26 Mar 2014) Changed paths: M Kernel.package/Number.class/instance/mathematical functions/floorLog_.st A KernelTests.package/FractionTest.class/instance/tests - mathematical functions/testFloorLog.st A KernelTests.package/IntegerTest.class/instance/tests - mathematical functions/testFloorLog.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script455.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30802.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHParserST80.class/instance/scan/scanBinary.st M Shout.package/SHParserST80.class/instance/scan/scanNumber.st M ShoutTests.package/SHParserST80Test.class/instance/tests/testNumbers.st Log Message: ----------- 30802 13080 Shout does not recognize doubled vertical bar || as a binary selector https://pharo.fogbugz.com/f/cases/13080 13083 Shout does not recognize Scaled decimal terminated by s https://pharo.fogbugz.com/f/cases/13083 13085 Large Integer and Fraction should avoid Float overflow when asked for their floogLog: https://pharo.fogbugz.com/f/cases/13085 http://files.pharo.org/image/30/30802.zip

1 0

[pharo-project/pharo-core]
by GitHub March 26, 2014

March 26, 2014

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

1 0

[pharo-project/pharo-core]
by GitHub March 26, 2014

March 26, 2014

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

1 0

[pharo-project/pharo-core] 557274: 30801
by GitHub March 26, 2014

March 26, 2014

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 557274427ddcc51da0bbf382fa8b981a803b425b https://github.com/pharo-project/pharo-core/commit/557274427ddcc51da0bbf382… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-26 (Wed, 26 Mar 2014) Changed paths: A Kernel.package/Integer.class/instance/mathematical functions/nthRootRounded_.st M Kernel.package/Integer.class/instance/mathematical functions/nthRoot_.st R Kernel.package/LargeInteger.class/instance/mathematical functions/sqrtFloor.st M Kernel.package/NumberParser.class/instance/parsing-private/makeIntegerOrScaledInteger.st M Kernel.package/NumberParser.class/instance/parsing-private/readNumberWithFractionPartNumberOfTrailingZeroInIntegerPart_.st R Kernel.package/NumberParser.class/instance/parsing-private/readScale.st A Kernel.package/NumberParser.class/instance/parsing-private/readScaleWithDefaultNumberOfDigits_.st M Kernel.package/NumberParser.class/instance/parsing-public/nextScaledDecimal.st A KernelTests.package/FloatTest.class/instance/tests - characterization/testMaxExactInteger.st A KernelTests.package/IntegerTest.class/instance/tests - mathematical functions/testNthRootExactness.st A KernelTests.package/LargePositiveIntegerTest.class/instance/tests/testLargeSqrtFloor.st A KernelTests.package/NumberParserTest.class/instance/tests - ScaledDecimal/testScaledDecimalWithoutScaleSpecification.st A KernelTests.package/NumberParsingTest.class/instance/tests - ScaledDecimal/testScaledDecimalWithoutScaleSpecification.st M Metacello-ToolBox.package/MetacelloToolBox.class/class/scripts/createDevelopment_for_importFromBaseline_description_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script454.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30801.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30801 13096 Do not update projects when releasing from the toolbox https://pharo.fogbugz.com/f/cases/13096 13081 Integer nthRoot: is not allways exact though it claims to https://pharo.fogbugz.com/f/cases/13081 13109 Incorrect sqrtFloor for large Integers https://pharo.fogbugz.com/f/cases/13109 13082 ScaledDecimal 0.050s should be interpreted with scale 3, not 0. https://pharo.fogbugz.com/f/cases/13082 http://files.pharo.org/image/30/30801.zip

1 0

Flat button look in Pharo3
by Philippe Back March 26, 2014

March 26, 2014

I grew really fed up of the blue -> gray gradients in the Pharo3Theme. Watching it all day long was too much, so I embarked on looking inside. Check https://pharo.fogbugz.com/default.asp?13132 and the SLICE-Issue-13132-Ugly-gradients-in-Pharo3Theme-Not-in-line-with-the-times-P hilippeBack.1 Phil --- Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com

2 1

Fixing inconsistent buttons look in PharoUI
by Philippe Back March 26, 2014

March 26, 2014

I've made a pass at fixing the buttons look (border in some places, no border in others). Spec-generated buttons are using the ButtonModel and MorphicButtonAdapter but the defaultSpec fo the the ButtonModel is asking the borderWidth and borderColor from the model, which is all nice but should be looking like the standard PluggableButtonMorphs, which do have a border. So, aligned now. https://pharo.fogbugz.com/default.asp?13135 Slice in inbox: SLICE-Issue-13135-Inconsistent-look-of-buttons-across-tools-Border-no-border -PhilippeBack.1 Phil --- Ce courrier Ã©lectronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com

1 0

Use Spotlight to quickly evaluate and inspect short expressions
by Sven Van Caekenberghe March 26, 2014

March 26, 2014

I had this idea: https://pharo.fogbugz.com/f/cases/13128/Use-Spotlight-to-quickly-evaluate-a… now you can do <shift-Enter>:42<Enter> to inspect the magic number 42 <shift-Enter>:1500*1.25<Enter> to quickly compute your 25% raise <shift-Enter>:Float pi<Enter> to see how many decimals you still remember <shift-Enter>:ZnClient new get: 'http://zn.stfx.eu/zn/small.html'<Enter> and so on. The interaction with the completion menu is not 100% perfect, but pressing <Space> at the end before <Enter> solves that. Feedback ? Sven PS: I know that many Smalltalk greybeards type everywhere to the same effect, and that is cool to, but it leaves around dirty windows. Opening a workspace for a single expression often is overkill. This feature is totally keyboard driven and very clean. PS2: Yes it resembles Emacs' M-: (evaluate-expression), but Pharo is much cooler, right ;-)

8 10

Location of Metacello package dependency
by Nicolas Cellier March 25, 2014

March 25, 2014

I have some packages A that depend on another package B. In Metacello, I can easily declare the dependency spec className: 'ConfigurationOfB'; versionString: #'stable'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. But the repository is hardcoded here. My problem is that I'd like to edit a ConfigurationOfA valid for pharo 1.x, 2.0.x and 3.0.x (so far so good) and put a copy in MetaRepoForPharo20 and another copy in MetaRepoForPharo30. Since the repository is hardcoded, this is going to be a problem because the MetaRepo will then cross-ref other repositories and weaken robustness or miss uptodate ConfigurationOfB... I'd like to avoid maintaining many branches of ConfigurationOfA. How do others resolve this?

3 10

FileSystemGit and Fuel final report
by Max Leske March 25, 2014

March 25, 2014

For those whoâve been interested in what went on during the last two weeks, where I visited Lille, Iâve compiled a short report. Regarding my work on Git Iâll continue to report on the status from time to time. I want to thank everyone at RMoD once again for the warm welcome and the support I received. Special thanks to Ben and Camillo for providing a place to crash at. Thanks also go to all of you guys and girls on the list for pushing Pharo constantly and for showing interest in my work. Itâs very encouraging. Cheers, Max Git: - Esteban Lorenzano and me worked together on preparing the libgit2 and libssh2 libraries for integration into the VM - Igor Stasenko worked with me to solve a couple of problems I had with NativeBoost. Especially callbacks can be tricky - Learnt how to build the VM in debugging mode so that I could debug FFI calls in XCode - Stefan Marr worked with me on moving the tests from Phexample to SUnit - The implementation now enables writing of blobs, trees and commits, cloning of remote repositories (https), fetching from remote repositories (https), pushing to remote repositories (https) - Authentication with remote repositories via SSH is working but clone, fetch, push don't work yet (problems with the libssh2 interaction that I wasn't able to resolve yet) - I set up an initial build infrastructure on the INRIA CI server (https://ci.inria.fr/pharo-contribution/job/LibGit2/) - We defined a rough roadmap for what needs to be done in the near future: 1. finish the low level libgit2 abstraction (offer a minimal API that hides the bindings; we don't want users to use the bindings directly) 2. we already have a prototype of a FileSystem wrapper for Git. We want to use that on top of the libgit2 abstraction layer 3. we already have a Monticello FileSystem wrapper prototype. We want to use that to abstract from the actual storage method. Together with the Git-FileSystem wrapper this should make it very easy to continue (for now) using Monticello and the existing GUI tools while using Git as a backend for storage. - On Friday 21 I gave a short demo at RMoD on the work accomplished and what the plans are for the future Fuel: - MartÃn Dias and I worked together on: - debugging a problem with large object graphs - preparing a new baseline for Fuel 2 - moving the benchmark suite to SMark - setting up a benchmark build on the INRIA CI server which will help us track performance changes when introducing changes - defining a rough roadmap for Fuel - Had a discussion with Usman Bhatti about the uses and the future of Fuel in Moose

3 3

Instance mutation [Was threading in Pharo]
by Eliot Miranda March 25, 2014

March 25, 2014

Hi Phil, Hi ClassBuilder people, On Mar 25, 2014, at 5:16 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: On Tue, Mar 25, 2014 at 1:05 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 24 March 2014 22:54, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > >> On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> >> I am working on a memory model for expandable collection in Pharo. >>> Currently, OrderedCollection, Dictionary and other expandable collections >>> use a internal array to store their data. My new collection library recycle >>> these array instead of letting the garbage collector dispose them. I simply >>> insert the arrays in an ordered collection when an array is not necessary >>> anymore. And I remove one when I need one. >>> > >>> > Hm, is that really going to be worth the trouble? >>> >>> This technique reduces the consumption of about 15% of memory. >>> >>> >> At the end, #add: and #remove: are performed on these polls of >>> arrays. I haven't been able to spot any problem regarding concurrency and I >>> made no effort in preventing them. I have a simple global collection and >>> each call site of "OrderedCollection new" can pick an element of my global >>> collection. >>> >> >>> >> I have the impression that I simply need to guard the access to the >>> global poll, which is basically guarding #add: #remove: and #includes: >>> > >>> > One of the AtomicCollections might be the right things for you? >>> >>> I will have a look at it. >>> >>> >> What is funny, is that I did not care at all about multi-threading >>> and concurrency, and I have not spotted any problem so far. >>> > >>> > There isn't any 'multi-threading' like in Java, you got a much more >>> control version: cooperative on the same priority, preemptive between >>> priorities. >>> > So, I am not surprised. And well, these operations are likely not to >>> be problematic when they are racy, except when the underling data structure >>> could get into an inconsistent state itself. The overall operations >>> (adding/removing/searing) are racy on the application level anyway. >>> > >>> > However, much more interesting would be to know what kind of benefit >>> do you see for such reuse? >>> > And especially, with Spur around the corner, will it still pay off >>> then? Or is it an application-specific optimization? >>> >>> I am exploring a new design of the collection library of Pharo. Not all >>> the (academic) ideas will be worth porting into the mainstream of Pharo. >>> But some of them yes. >>> >>> Thanks for all your help guys! You're great! >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> An interesting method I stumbled upon which may help in understanding how >> these things do work. >> >> BlockClosure>>valueUnpreemptively >> "Evaluate the receiver (block), without the possibility of preemption >> by higher priority processes. Use this facility VERY sparingly!" >> "Think about using Block>>valueUninterruptably first, and think about >> using Semaphore>>critical: before that, and think about redesigning your >> application even before that! >> After you've done all that thinking, go right ahead and use it..." >> | activeProcess oldPriority result semaphore | >> activeProcess := Processor activeProcess. >> oldPriority := activeProcess priority. >> activeProcess priority: Processor highestPriority. >> result := self ensure: [activeProcess priority: oldPriority]. >> >> > I would not recommend you to use this method for anything. > This method heavily relies on how process scheduler works, and in case of > any changes, it may break everything. > For the sake of programming, one shall never assume there is a way to > "stop the world while i busy doing something". > If you reshape the world, it makes sense. I was looking at how classes were migrated, that's why I found it. And all of the new Pharo way of doing these things. Hey, it is becoming really cool down there. Martin and Camille have been hard at work. Kudos! migrateClasses: old to: new using: anInstanceModification instanceModification := anInstanceModification. old ifEmpty: [ ^ self ]. [ 1 to: old size do: [ :index | self updateClass: (old at: index) to: (new at: index)]. old elementsForwardIdentityTo: new. " Garbage collect away the zombie instances left behind in garbage memory in #updateInstancesFrom: " " If we don't clean up this garbage, a second update would revive them with a wrong layout! " " (newClass rather than oldClass, since they are now both newClass) " Smalltalk garbageCollect. ] valueUnpreemptively The global GC here is pretty unfortunate. It is there because the VM used to leave old instances lying around. It works like this: we want to reshape instances of class C, e.g. by adding an inst var, and so 1. create C', which is C plus an inst var 2. create a parallel set of instances of class C', one for each instance of class C 3. for each corresponding pair of instances copy state from the instance of C to the instance of C' 4. forward-become the instances of C to the instances of C' (now no references to the instances of C remain) 5. become C to C' (now C' is the new C) The bug is that the old instances of C are still in the heap. Because of the become in 5. they look like instances of the new C, but are the wrong size; they lack space for the new inst var. They're not reachable (4. replaced all references to them with references to the instances of C') but they can be resurrected through allInstances (someInstance,nextInstance) which works not by following references from the roots (Smalltalk and the activeProcess) but by scanning objects in the heap. However, this was "fixed" in Name: VMMaker.oscog-eem.254 Author: eem Time: 11 January 2013, 7:05:37.389 pm UUID: 74e6a299-691e-4f7d-986c-1a7d3d0ec02c Ancestors: VMMaker.oscog-eem.253 Fix becomeForward: so that objects whose references are deleted are freed and can no longer be resurrected via allObjects or allInstances. The change is to free the objects replaced in a forwardBecome so they are no longer objects (effectively their class is null (not nil, but 0)). So they can't be resurrected and hence the global GC is un necessary. The Newspeak folks, in particular Ryan Macnak, spotted this and encouraged me to make the change. It of course speeds up instance mutation considerably. I say fixed because there was a bug tail: Name: VMMaker.oscog-eem.258 Author: eem Time: 18 January 2013, 11:01:23.072 am UUID: da1433f1-de50-475f-be33-f462b300a2ea Ancestors: VMMaker.oscog-eem.257 Fix becomeForward: when the rootTable overflows. There were two bugs here. One is that initializeMemoryFirstFree: used to clear the needGCFlag so if the rootTable overflowed noteAsRoot:headerLoc:'s setting of the needGCFlag would be undone after the sweep. The other is that rootTable overflow was indicated by rootTableCount >= RootTableSize which could be undone by becomeForward: freeing roots which need to be removed from the rootTable. At some point in becomeForward the rootTable would fill but at a later point a root would be freed, causing the table to become not full. The fix is two fold. 1. Add an explicit rootTableOverflowed flag instead of relying on rootTableCount >= RootTableSize. 2. move the clearing of the needGCFlag to the GC routines. Remove unnecessary senders of needGCFlag: false, and remove the accessor. Name: VMMaker.oscog-eem.255 Author: eem Time: 12 January 2013, 6:28:41.398 pm UUID: 51e53ec1-8caf-41f6-9293-1088ef4b82d8 Ancestors: VMMaker.oscog-eem.254 [New[Co]]ObjectMemory: Fix freeing of objects for becomeForward:. Remove freed young roots from the rootsTable. Filter freed objects pointet to from the extraRootsTable (because these locations can change it is wrong to remove entries from the extraRootsTable). But the bottom line is that, at least on the current Cog VM, that global GC is unnecessary. David, Tim, this still needs to be folded into ObjectMemory in the standard interpreter. But doing so is very worth-while. Monticello loads are noticeably faster. KR Phil > > > -- > Best regards, > Igor Stasenko. > Eliot (phone)

2 2