- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Strange logic in PolygonMorph>>fromHand: hand
by Fernando Olivero May 13, 2012

May 13, 2012

Indeed is weird. I think it has to explicitly call runStepMethods, because it's not forking , thus taking control of the ui process, does it make sense? I would remove the method (and all the similar ones found in the image, that explicitly reference Sensor and while doing "true whileTrue:[ ...]", if needed it would be have to re-done using the new event model with announcements. Fernando On Sun, May 13, 2012 at 10:20 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I'm cleaning Sensor use so that we end up with a better layered system. > Now I see this method and I wonder (replacing Sensor by hand does not work. > But I do not understand why this methods has to explicitly invoke runStepMethodsâ¦ to me it looks like a broken behavior > due probably to the lack of a functionality or ticking behavior. > > What do you think? > > fromHand: hand > Â Â Â Â "Let the user draw a polygon, clicking at each vertex, and ending > Â Â Â Â Â Â Â Â by clicking within 5 of the first point..." > Â Â Â Â "self fromHand: ActiveHand" > > Â Â Â Â | p1 poly oldVerts pN opposite | > Â Â Â Â Cursor crossHair showWhile: > Â Â Â Â Â Â Â Â [[Sensor anyButtonPressed] whileFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [self currentWorld displayWorldSafely; runStepMethods]. > Â Â Â Â Â Â Â Â p1 := Sensor cursorPoint]. > Â Â Â Â opposite := (Display colorAt: p1) negated. > Â Â Â Â opposite = Color transparent ifTrue: [opposite := Color red]. > Â Â Â Â (poly := LineMorph from: p1 to: p1 color: opposite width: 2) openInWorld. > Â Â Â Â oldVerts := {p1}. > Â Â Â Â self currentWorld displayWorldSafely; runStepMethods. > Â Â Â Â [true] whileTrue: > Â Â Â Â Â Â Â Â [[Sensor anyButtonPressed] whileTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [pN := Sensor cursorPoint. > Â Â Â Â Â Â Â Â Â Â Â Â poly setVertices: (oldVerts copyWith: pN). > Â Â Â Â Â Â Â Â Â Â Â Â self currentWorld displayWorldSafely; runStepMethods]. > Â Â Â Â Â Â Â Â (oldVerts size > 1 and: [(pN dist: p1) < 5]) ifTrue: > Â Â Â Â Â Â Â Â Â Â Â Â [hand position: Sensor cursorPoint. Â "Done -- update hand pos" > Â Â Â Â Â Â Â Â Â Â Â Â ^ (poly setVertices: (poly vertices copyWith: p1)) delete]. > Â Â Â Â Â Â Â Â oldVerts := poly vertices. > Â Â Â Â Â Â Â Â [Sensor anyButtonPressed] whileFalse: > Â Â Â Â Â Â Â Â Â Â Â Â [pN := Sensor cursorPoint. > Â Â Â Â Â Â Â Â Â Â Â Â poly setVertices: (oldVerts copyWith: pN). > Â Â Â Â Â Â Â Â Â Â Â Â self currentWorld displayWorldSafely; runStepMethods]]. > >

2 1

[Pharo-project] implementors of...
by blake May 13, 2012

May 13, 2012

If I have a method showing in the method pane, I can right-click on renderContentOn: and get a list of all the implementors of that method. What if I don't know of a class that has the renderContentOn: method? How can I find the classes then? ===Blake===

3 6

[Pharo-project] [update 2.0] #20072
by Marcus Denker May 13, 2012

May 13, 2012

20072 ----- Issue 5886: Minor fix in Nautilus http://code.google.com/p/pharo/issues/detail?id=5886 Issue 5875: Too Many Options http://code.google.com/p/pharo/issues/detail?id=5875 Issue 5833: More robust allSuperclassesIncluding: http://code.google.com/p/pharo/issues/detail?id=5833 Issue 5872: [BUG]: Nautilus doesnt know a method is selected http://code.google.com/p/pharo/issues/detail?id=5872 Issue 5869: New versions of Spec (fixing a bit MessageBrowser) http://code.google.com/p/pharo/issues/detail?id=5869 Issue 5630: Cannot browse traits with Nautius http://code.google.com/p/pharo/issues/detail?id=5630 -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [Pharo-consortium] We need your successes
by Fernando Olivero May 13, 2012

May 13, 2012

I'll prepare one, detailing myself and Gaucho. Fernando On Sat, May 12, 2012 at 9:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks Hilaire for this cool one :) > > > Â Â Â Â https://gforge.inria.fr/frs/download.php/30761/drgeo-teaser.pdf > > I should do one for http://www.synectique.eu > > Stef >

1 0

[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