May 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] Test coverage on branch level?
by Stefan Marr May 13, 2012

May 13, 2012

Hi: I was looking for something that could visualize code coverage on the branch/statement level. My understanding is that the test coverage tool provide by the test runner only tells me which methods haven't been called. I also had a look at Hapao. First I found that the linked image was rather old [1], but even after loading the latest version into a fresh image, I still had the feeling that it provides me with a lot information that is not immediately helpful to answer my questions. >From the C world, I am used to things like gcov and lcov [2], where I can see immediately which branches haven't been covered. Is there something similar available in the Pharo universe? Reading a recent thread on the mailing list [3] gives me the impression: 'not yet'? Thanks Stefan [1] http://objectprofile.com/pier/Products/Hapao/Download [2] http://ltp.sourceforge.net/coverage/lcov.php [3] http://forum.world.st/Proposal-coverage-tests-td4407271.html -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

1 0

[Pharo-project] Fun with spock (NativeBoost FFI)
by Lawson English May 13, 2012

May 13, 2012

So, thanks to Igor Stasenko, I've managed to learn how to (sorta) use the new NativeBoost FFI (spock). We (he) implemented a binding to a few of the gmplib functions. gmp is the GNU Multi-Precision Library. Here is a simple benchmark of the Pharo factorial method vs the gmplib mpz_fac_ui() function. As might be expected, gmplib is faster for any test larger than 13 factorial, as LargePositiveInteger starts to become involved, and the speed differential becomes rather huge as larger integers are tested: 1000 factorial time to run with: squeak: 2 ms gmplib: 0.004 ms ratio: 50.0 11000 factorial time to run with: squeak: 354 ms gmplib: 0.191 ms ratio: 185.34031413612567 [...] 91000 factorial time to run with: squeak: 34598 ms gmplib: 4.759 ms ratio: 727.0014708972473 Running on a Mac OS X Snow Leopard 2.8Ghz, with NBCog and 1.4 Pharo image. benchmark: a := GMPzWrapper new. 1000 to: 100000 by: 10000 do: [:i| squeakTime := [ i factorial] timeToRun. Transcript show: i asString, ' factorial time to run with:';cr. Transcript show: 'squeak: ', (squeakTime) asString, ' ms '. gmpTime := [100 timesRepeat: [a prim_mpz_fac_ui: i]] timeToRun. Transcript show: ' gmplib: ' , (gmpTime/1000.0) asString, ' ms '. Transcript show: ' ratio: ', (squeakTime/(gmpTime/100.0)) asString;cr;cr. ] -- Squeak from the very start (introduction to Squeak and Pharo Smalltalk for the (almost) complete and compleate beginner). https://www.youtube.com/playlist?list=PL6601A198DF14788D&feature=view_all

1 1

[Pharo-project] Pharo and the ST-80 classes
by blake May 13, 2012

May 13, 2012

I went to use a "Line" today and found it wasn't in Pharo. Apparently this is part of the ST80-* (ST80-Paths) classes which aren't carried over to Pharo. So...how do I draw a line on a morph (without creating another morph)? ===Blake===

3 5

[Pharo-project] FileList efficiency could hardly be worse
by Nicolas Cellier May 13, 2012

May 13, 2012

The efficiency of FileList>>listForPattern: is something which should deserve a bit more care. It tries to sort the files, for example by name, but wants to display directory first ^ [ :x :y | |xIsDir| ((xIsDir := x isDirectory) = y isDirectory) ifTrue: [ x basename <= y basename ] ifFalse: [ "directories always precede files" xIsDir ]] Alas, this isDirectory test cost you an arm: FileReference>>isDirectory ^ filesystem isDirectory: path FileSystem>>isDirectory: aResolvable "Resolve the argument, and answer true if the result refers to a directory, false if it refers to a file or doesn't exist." ^ store isDirectory: (self resolve: aResolvable) FileSystemStore>>isDirectory: aPath aPath isRoot ifTrue: [ ^ true ]. self nodeAt: aPath ifPresent: [ :entry | ^ self basicIsDirectory: entry ] ifAbsent: [ ^ false ]. DiskStore>>nodeAt: aPath ifPresent: presentBlock ifAbsent: absentBlock | name| aPath isRoot ifTrue: [ ^ presentBlock value: self rootNode ]. "| encodedPath encodedBasename entry | encodedPath := Primitives encode: (self stringFromPath: aPath parent). encodedBasename := Primitives encode: aPath basename. entry := Primitives lookupDirectory: encodedPath filename: encodedBasename. ^ entry == #badDirectoryPath ifTrue: absentBlock ifFalse: [ entry at: 1 put: aPath basename. presentBlock value: entry ]." name := aPath basename. self directoryAt: aPath parent ifAbsent: absentBlock nodesDo: [ :entry | (self filename: (entry at: 1) matches: name) ifTrue: [ ^ presentBlock value: entry ] ]. ^ absentBlock value Arghh, it scans the whole parent directory again! If sort is O(n log n), then we transform it into O(2 n^2 log n). Try to browse your package-cache if you're not a chicken. Seriously, it's unusable... Nicolas

6 8

[Pharo-project] smallUML news: towards autogenerated diagrams
by Carla F. Griggio May 13, 2012

May 13, 2012

Hi everyone! I've been doing some experiments to get Class Diagrams generated from the evaluation of a block. There's still a lot of work to be done, but I've just got this working and I wanted to show it to you :) Gofer new squeaksource: 'smallUML'; package: 'ConfigurationOfSmallUML'; load. ((Smalltalk at: #ConfigurationOfSmallUML) project version:'1.1.6') load. After downloading the project, try this example: [|jack william blackPearl questMission| jack := Pirate new alcoholLevel: 0.7; items:#(#compass #islandMap #rum #moreRum #goldMedallion). questMission := TreasureQuest new. blackPearl := Ship new. blackPearl mission: questMission. blackPearl acceptIntoTripulation: jack. ] asClassDiagram openQuickView A messy and 'overlapped' diagram will come up, because there's still no autimatic positioning of the diagram nodes :( but you can drag the class boxes around to place them anywhere you want. You will notice that what I've got so far is: - Drawing the classes involved in the evaluation of that block, with the messages that were sent during that block - Drawing the superclasses involved along with the inheritance arrow. Superclasses are included only if there are inherited methods excecuted. - Drawing the association relationships between instances! That's my favorite part, and the one that was not trivial to achieve. The code still sucks, but it's working. You can see that the association relationships between the Ship, the Pirate and the Mission are drawn, and Collections are 'skipped' as in a regular class diagram using the cardinality annotation * over the arrow. What's interesting about this last point, is resolving these (still pending) issues: - If an object form class A has a collection where the elements are of different classes, or if it has an attribute that could point to different polimorfic objects, there should be just one association arrow from class A to: - the superclass of those different classes, or - the inferred *type* those different classes share: this comes along with some questions, like 'what will the type name be?' - What will be the scope of the diagram? Objects can have attributes ponting to numbers, strings, blocks, booleans, etc. Are we interested in showing those classes in a class diagram? I guess, it depends. The diagram scope should not be hard coded (as it is now :P), because if we want to document a core package, some core classes will have to appear instead of being ignored like we would prefere in a 'domain specific' diagram. - Collections are 'skipped' in the diagrams. That means that if an object A points to a collection, that points to several objects of class B, in the diagram only the classes A and B are shown with the classical 'one to many' arrow. This will mess up diagrams of the collection packages themselves :P So, I invite you to think about how could these issues be resolved, and also play a little bit with what I've got so far, executing [your block code] asClassDiagram openQuickView. I hope that the GSoC project of Santiago will help with the type inferences part :) Cheers! Carla.

4 5

[Pharo-project] Nautilus oddities (Naudities?)
by blake May 12, 2012

May 12, 2012

Observation: The Nautilus browser seems to have a tendency to offer options that have no effect. Or maybe it's just the refactoring elements, I'm not sure how the integration works. When right clicking on the method pane one seems to get the full suite of options even if no method is selected. One of the refactoring options is "move to class side" which one gets even when one is already ON the class side. ===Blake===

2 3

[Pharo-project] I cannot see the code in the latest Moose build
by Fabrizio Perin May 12, 2012

May 12, 2012

Hi, I download the latest yellow build from the moose web site (8 may). When I open Nautilus I cannot see the code. I don't have any clue if it is about Nautilus or about how Nautilus is loaded in Moose or about something else. Any idea? Cheers, Fabrizio

3 10

May 12, 2012

Hi everybody We really want to build a "vitrine" showroom of Pharo and we would you to participate. We want to build a web page with all these successes and show it to the world. :) We would like to get from you a three slides document: slide one: a sexy picture and a teaser / who you are. slide two: what is it how cool is it. slide three: what cool pharo techno you used or developed. I did a bad one using DrGeo to give you an idea. So can you please send us these three slides. We would like to present them during the Pharo conf and after put them on the web. Stef and marcus.

3 3

Re: [Pharo-project] [review needed] Do we remove SmartRefStream?
by Marcus Denker May 12, 2012

May 12, 2012

On May 12, 2012, at 10:27 AM, StÃ©phane Ducasse wrote: > > On May 11, 2012, at 10:27 AM, Marcus Denker wrote: > >> >> With Fuel, we should take the opportunity to clean up the systm. There are things we need to keep >> for a while (DataStream, for example, a it is used by Monticello). >> >> But what about SmartRefStream? With ImageSegment already gone, does it make sense to keep >> it? The code looks horrible. >> >> One can just remove it and all remaining users like this: >> >> http://code.google.com/p/pharo/issues/detail?id=5859 >> >> Can we do that? do we need to formally deprecate it? > > would be good even if so boringâ¦ :) I have an idea: I will integrate the removal change. But as soon as somone who is not me adds a tracker entry with a Slice that has a nicely deprecated version of SmartRefStream, I will directly add it. This is kind "removal inversion": normally keeping something is the cheap and easy option. Removing is hard. In this case, we invert: remvove, but *if* for somebody the "keep" option is important enough to spend *a trivial amoung of work on*, we do it. ;-) Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] [update 2.0] #20071
by Esteban Lorenzano May 12, 2012

May 12, 2012

20071 ----- Issue 5866: error in new CodeImporter http://code.google.com/p/pharo/issues/detail?id=5866 Issue 5835: Improved version of StartupPreferences http://code.google.com/p/pharo/issues/detail?id=5835

1 0