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

[ANN] Nireas - a theme manager for Pharo 4
by kilon alios Nov. 23, 2014

Nov. 23, 2014

Hello pharoers , I would like to present to you my latest project and a good excuse to learn Spec. First I would like to thank Nicolai for his help and all other people who helped me out understand Spec. Of course I am still learning :) So , Nireas is a theme manager for Pharo 4. What this means is that Nireas takes the dark theme and by presenting you with an easy to use gui allows you to change the colors on the fly to adjust the theme to your own preferences and habits. This is an example https://www.dropbox.com/s/w3c72lz0r81v4iv/Screenshot%202014-11-23%2013.53.0… you can see the Nireas GUI on the bottom, the Nautilus on the left has the default dark theme colors, the one on the right has the color selected by Nireas. You can find instructions on how to install Nireas and how to use here https://github.com/kilon/Nireas Unfortunately the last one the scroll bar color seems to have no effect, I will have to look into it, but the other options work fine. Please note also that you will have refresh issues so its advisable to close existing windows and reopen them so they update properly to the new colors. Please try this tool inside a new fresh pharo 4 image, this code is very experimental and has been known to crash Morphic. So use with caution. Nireas implements its own theme subclassing the dark theme, the big diffirence here is that it defines color to be independent and dynamic so the theme can be , well, .... themable :D Nireas does not change anything inside Pharo so it can be installed safely. I would like to take this tool further to allow of course deeper customisations that goes beyond just customising colors, meaning change the look and feel of Pharo. But this means unfortunately/fortunately that some things will have to change inside Pharo and Pharo will have to become much more dynamic GUI wise to make dynamic themes much easier to implement. Nireas is part of my Ephestos project, so this is why it appears inside an Ephestos menu and hopefully I will keep working it as customising Pharo GUI is something that I find really interesting and fun, As always comments, insults, worship and rage is more than welcomed.

2 2

cull: equivalent for valueWithArguments:
by stepharo Nov. 23, 2014

Nov. 23, 2014

Hi guys What would be cull: equivalent for valueWithArguments:? I need to be able to specify an extra argument to valueWithArguments valueWithArgument:cull:? Stef

2 2

Pharo 4 buggy with gui
by kilon alios Nov. 22, 2014

Nov. 22, 2014

Is it just me or has Morphic become really buggy with Pharo 4 ? I get severe freezes of Pharo and I have to force quit both in MacOS 10.10 and Ubuntu 14.04 here is a screenshot https://www.dropbox.com/s/9ev53j31i0k5svt/Screenshot%202014-11-22%2023.42.4… I am using latest build as of today and yesterday + friday

2 3

[ANN] SciSmalltalk v0.16
by Serge Stinckwich Nov. 22, 2014

Nov. 22, 2014

Dear all, we are to happy to announce SciSmalltalk v0.16 SciSmalltalk is a Smalltalk project, similar to existing scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby. SciSmalltalk already provide the following basic functionalities: - complex and quaternions extensions, - random number generators, - fuzzy algorithms, - Didier Besset's numerical methods, - Ordinary Differential Equation (ODE) Solver. Version 0.16 includes updates from Werner Kassens to several packages, the work Nicolas Cellier about arbitrary precision floats. SciSmalltalk project web page is here: https://github.com/SergeStinckwich/SciSmalltalk All the code is available under the MIT licence. We have more than 563 green unit tests and we run a CI job here: https://ci.inria.fr/pharo-contribution/job/SciSmalltalk/ This version should work on Pharo 3.0/4.0 and also Squeak 4.5 (to be confirmed). We are looking for more code contributions and also tests, documentation ! Join the mailing-list : https://groups.google.com/forum/#!forum/scismalltalk -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Help fight Ebola by joining the Computing for Ebola Challenge http://bit.ly/1oEdBag

5 4

[pharo-project/pharo-core] 20a69e: 40382
by GitHub Nov. 22, 2014

Nov. 22, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 20a69ec3f950e4f88ed083008aa723692100bd38 https://github.com/pharo-project/pharo-core/commit/20a69ec3f950e4f88ed08300… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-22 (Sat, 22 Nov 2014) Changed paths: A Morphic-Base.package/extension/BorderedMorph/instance/changeBorderColor_.st M Morphic-Core.package/BorderedMorph.class/instance/menu/addBorderStyleMenuItems_hand_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitClassTraitDefinition_.st M Refactoring-Core.package/RBAbstractClass.class/instance/accessing/allSubclasses.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script382.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40382.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40382 14516 use an explicit copy of subclass collection in RBAbstractClass>>#allSubclasses https://pharo.fogbugz.com/f/cases/14516 12007 BorderMorph halo menu border colour broken https://pharo.fogbugz.com/f/cases/12007 14494 PSMCChangesGrouper is missing #visitClassTraitDefinition: https://pharo.fogbugz.com/f/cases/14494 http://files.pharo.org/image/40/40382.zip

1 0

[pharo-project/pharo-core]
by GitHub Nov. 22, 2014

Nov. 22, 2014

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

1 0

Float hierarchy for 64-bit Spur
by Eliot Miranda Nov. 21, 2014

Nov. 21, 2014

Hi All, 64-bit Spur can usefully provide an immediate float, a 61-bit subset of the ieee double precision float. The scheme steals bits from the mantissa to use for the immediate's 3-bit tag pattern. So values have the same precision as ieee doubles, but can only represent the subset with exponents between 10^-38 and 10^38, the single-precision range. The issue here is how to organize the class hierarchy. The approach that looks best to me is to modify class Float to be an abstract class, and add two subclasses, BoxedFloat and SmallFloat, such that existing boxed instances of Float outside the SmallFloat range will become instances of BoxedFloat and instances within that range will be replaced by references to the relevant SmallFloat. With this approach ... - Float pi etc can still be used, even though they will answer instances of SmallFloat. But tests such as "self assert: result class == Float." will need to be rewritten to e.g. "self assert: result isFloat". - BoxedFloat and SmallFloat will not be mentioned much at all since floats print themselves literally, and so the fact that the classes have changed won't be obvious. - the boxed Float primitives (receiver is a boxed float) live in BoxedFloat and the immediate ones live in SmallFloat. Making SmallFloat a subclass of Float poses problems for all the primitives that do a super send to retry, since the boxed Float prims will be above the unboxed ones and so the boxed ones would have to test for an immediate receiver. An alternative, that VW took (because it has both Float and Double) is to add a superclass, e.g. LimitedPrecisionReal, move most of the methods into it, and keep Float as Float, and add SmallFloat as a subclass of LimitedPrecisionReal. Then while class-side methods such as pi would likely be implemented in LimitedPrecisionReal class, sends to Float to access them find them via inheritance. An automatic reorganization which moves only primitives out of LimitedPrecisionReal is easy to write. Thoughts? -- best, Eliot

5 4

Re: [Pharo-dev] [squeak-dev] Float hierarchy for 64-bit Spur
by Eliot Miranda Nov. 21, 2014

Nov. 21, 2014

Hi Tobias, On Fri, Nov 21, 2014 at 4:51 AM, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Hi, > > On 21.11.2014, at 13:44, Bert Freudenberg <bert(a)freudenbergs.de> wrote: > > > On 21.11.2014, at 13:29, J. Vuletich (mail lists) < > juanlists(a)jvuletich.org> wrote: > > > >> Quoting Bert Freudenberg <bert(a)freudenbergs.de>: > >>> > >>> I'd suggest BoxedDouble and ImmediateDouble as names for the concrete > subclasses (*). Names do mean something. (**) > >>> > >>> You're right about the FloatArray confusion. However, note that the > IEEE standard calls it single and double. It's only C using "float" to mean > "single precision". > >>> > >>> I'd name the abstract superclass Float, for readability, and the > isFloat test etc. Also: "Float pi" reads a lot nicer than anything else. I > don't see the need for having a deep LimitedPrecisionReal - Float - > BoxedDouble/ImmediateDouble deep hierarchy now. > >>> > >>> If we ever add single-precision floats, we should name them > BoxedSingle and ImmediateSingle. At that point we might want a Single > superclass and a LimitedPrecisionReal supersuperclass, but we can cross > that bridge when we get there. > >>> > >>> - Bert - > >>> > >>> (*) Since we're not going to see the class names often, we could even > spell it out as BoxedDoublePrecisionFloat and > ImmediateDoublePrecisionFloat. Only half joking. It would make the relation > to the abstract Float very clear. > >>> > >>> (**) We could also try to make the names googleable. I was surprised > to not get a good hit for "boxed immediate". Only "boxed unboxed" finds it. > Maybe there are two better words? > >> > >> I very much agree with Bert. But I'd suggest SmallDouble instead of > ImmediateDouble for consistency with SmallInteger. > > > > Then it would have to be LargeDouble for consistency with LargeInteger, > too. Which I don't find compelling. > > > > Also, with the 64 bit format we get many more immediate objects. There > already are immediate integers and characters, floats will be the third, > there could be more, like immediate points. For those, the small/large > distinction does not make sense. > > > > Maybe Eliot's idea of keeping "Float" in the name was best, but instead > of "small" use "immediate": > > > > Float - BoxedFloat - ImmediateFloat > > > > A Float is either a BoxedFloat or an ImmediateFloat, depending on > the magnitude of its exponent. > > I don't like the idea of putting a VM/Storage detail into the Class name. > The running system itself does not care about whether Floats or Integers > are > boxed or immediate. > I disagree. I think at least Smalltalk-80 has a philosophy of lifting as much out of the VM into the system, and hiding it from clients via encapsulation. So unlike many other VMs the compiler is in the system, the system explicitly separates SmallInteger, LargePositiveInteger and LargeNegativeInteger and implements large integer arithmetic with Smalltalk code that uses SmallIntegers. Note that the primitives are an optional extra optimization that the VM does not need to implement. So for me it is in keeping with the current system to use BoxedFloat and SmallFloat or BoxedDouble and SmallDouble. This lifting things up provides us with an extremely malleable system. Pushing things down into the VM does the opposite. For example in RSqueakVM (aka SPy) there is no immediate > Integer whatsoever. Yes, tagged ints are read during image startup but they > aren't subsequently represented as immediates or tagged ints after that. > Well because it's implemented above RPython I guess it is using Python's bignum code directly. That's fine but its a bit of a cheat. > > Just as input, in the Racket language and other Schemes, > the equivalent to our SmallInterger/LargeInteger is fixnum/bignum > and for floats they have flonums and "extflonums" (80bit). > > Best > -Tobias thanks -- best, Eliot

2 3

[pharo-project/pharo-core]
by GitHub Nov. 21, 2014

Nov. 21, 2014

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

1 0

[pharo-project/pharo-core] 898184: 40381
by GitHub Nov. 21, 2014

Nov. 21, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 89818487a755292e8f477a5e855cdca5b578b619 https://github.com/pharo-project/pharo-core/commit/89818487a755292e8f477a5e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-11-21 (Fri, 21 Nov 2014) Changed paths: R Collections-Abstract.package/Collection.class/instance/enumerating/do_displayingProgress_.st R Collections-Abstract.package/Collection.class/instance/enumerating/do_displayingProgress_every_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script381.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40381.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Caching.package/extension/BlockClosure/instance/memoized.st A System-Caching.package/extension/BlockClosure/instance/memoizedUsing_.st A System-CachingTests.package/extension/BlockClosureTest/instance/testMemoizedDictionary.st A System-CachingTests.package/extension/BlockClosureTest/instance/testMemoizedLRUCache.st A System-CachingTests.package/extension/LRUCache/instance/testSupportGetCachedAssociations.st A UIManager.package/extension/Collection/instance/do_displayingProgress_.st A UIManager.package/extension/Collection/instance/do_displayingProgress_every_.st Log Message: ----------- 40381 14487 do:displayingProgress: in Collection should be part of the UIManager package https://pharo.fogbugz.com/f/cases/14487 14458 Add BlockClosure>>memoized https://pharo.fogbugz.com/f/cases/14458 http://files.pharo.org/image/40/40381.zip

1 0