February 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20555

by Esteban Lorenzano

20555 ----- Issue 7521: Add PostMaterializationAction to Fueled out stack traces http://code.google.com/p/pharo/issues/detail?id=7521 Issue 7532: Integrate a preview of Fuel 1.9 http://code.google.com/p/pharo/issues/detail?id=7532 2nd attempt :) Diff information: http://ss3.gemstone.com/ss/Pharo20/FuelSystem-FileRegistry-EstebanLorenzano… http://ss3.gemstone.com/ss/Pharo20/Fuel-EstebanLorenzano.746.diff

Feb. 19, 2013

Re: [Pharo-project] Smalllint for Traits

by Damien Cassou

On Tue, Feb 19, 2013 at 2:46 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > The license page needs an update, "Copyright (c) Pharo Project, and > Contributors Copyright (c) 1996-2008 " must be "Copyright (c) Pharo Project, > and Contributors Copyright (c) 1996-2013" ? done > Maybe "The Distribution Agreement" can be updated with the Pharo consortium > as the distributor? I have no idea. Steph ? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 19, 2013

[Pharo-project] [update 2.0] #20554

by Esteban Lorenzano

20554 ----- Issue 7521: Add PostMaterializationAction to Fueled out stack traces http://code.google.com/p/pharo/issues/detail?id=7521 Issue 7403: CMD-click no longer works to activate source-links http://code.google.com/p/pharo/issues/detail?id=7403 Issue 7532: Integrate a preview of Fuel 1.9 http://code.google.com/p/pharo/issues/detail?id=7532 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-EstebanLorenzano.1044.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-EstebanLorenzano.1353.diff http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-EstebanLorenzano.25.d… http://ss3.gemstone.com/ss/Pharo20/FuelTests-EstebanLorenzano.306.diff http://ss3.gemstone.com/ss/Pharo20/Fuel-EstebanLorenzano.744.diff

Feb. 19, 2013

Re: [Pharo-project] New Issue Tracker

by Christophe Demarey

Hi all, I quickly developed a basic importer (Google code => Jira) so that everyone can play a bit with real data. There is still a lot of missing stuff that we can import (ex: labels, author) but I will only do that once we agree on the new bugtracker to choose. So, we have a free Jira instance available at https://pharo-project.atlassian.net/browse/DEMO (there is already a Pharo project but I prefer to not pollute it with tests). Direct acces to issues: https://pharo-project.atlassian.net/issues/?jql=project%20%3D%20DEMO I configured the minimum. We can tune this portal if needed. If you want to play, first register and ask me to become a project member. Cheers, Christophe. Le 12 fÃ©vr. 2013 Ã 14:16, Camillo Bruni a Ã©crit : > After a discussion with Christophe which is in favor of JIRA ;) we decided to put a > wiki page online where we should list all the requirements (not just the ones I think > are important :P) > > https://code.google.com/p/pharo/wiki/NewIssueTracker

Feb. 19, 2013

Re: [Pharo-project] Magritte and Spec

by Esteban Lorenzano

cool :) On Feb 19, 2013, at 12:53 AM, DeNigris Sean <sean(a)clipperadams.com> wrote: > Since I'm using Spec for all my Pharo UIs, I'm interested in having Spec as the backend to Magritte. If anyone is interested, I started an experiment at http://ss3.gemstone.com/ss/SpdPlayground/ . Look for the Magritte-Spec package. > > Cheers, > Sean

Feb. 19, 2013

Re: [Pharo-project] Phexample should methods

by Frank Shearar

On 19 February 2013 07:59, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > > On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote: > >> That gives rise to example-driven testing ala: >> >> Foo >> #barShouldBeSomething >> >> So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name. >> >> Any opinions on that? > > Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods (imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class. > > I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ... > > Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR > > Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome! That would greatly lessen the difference between exploratory programming and "classic" TDD, which I think is a great idea. You play around with some code in a Workspace, get something working, and then want to formalise that/record it as a test... and have to open up a Browser and move bits here and there, and it's a bit of a pain. Having this kind of thing - whether a menu item or button or whatever - would remove that source of friction. frank

Feb. 19, 2013

[Pharo-project] Pharo By Example 2 Book - Assembled Files in PDF form.

by phil＠highoctane.be

Hi all, I struggled with the fact that the PBE2 book was in tex format and not all chapters were together in a single PDF. So, I ran the scripts in order to get a version with all the parts put together. This should be made into a Jenkins job I think so that we can have the PBE2 and other books in PDF form for easier dissemination. Here is the current assembly: https://www.dropbox.com/s/t8pesgxsovy61k5/PBE2-Assembled-20130213.pdf 412 pages of Pharo explanations. How lovely! Enjoy, Phil

Feb. 19, 2013

Re: [Pharo-project] Phexample should methods

by Frank Shearar

On 19 Feb 2013, at 7:59, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > > On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote: > >> That gives rise to example-driven testing ala: >> >> Foo >> #barShouldBeSomething >> >> So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name. >> >> Any opinions on that? > > Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods I'm not sure I understand you correctly: in Ruby you also only have classes and methods. Those apparently independent methods (top level defs, describe blocks, ...) are all methods on Object. It's just that Ruby lets you (in the case of def) leave out the "on Object" part or (in the case of describe has special eval forms (and implicit receivers) which make Ruby look like it supports anything other than methods. frank > (imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class. > > I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ... > > Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR > > Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome! > > >> PS: It is also inconsistent with Phexample's own #isTest: implementation, which uses #beginsWith: > > Oops, that's a bug, #theMoreGeneralCaseShouldApply :) > > Even though personally I prefer to not use should inside the name in order to limit the pollution for the selection name space with regard to Smalltalk's simple autocomplete ... > > --AA

Feb. 19, 2013

Re: [Pharo-project] Issue 7534 LazyListMorph>>selectionFrameForRow: fails with a 'should not happen' IS BACK

by Goubier Thierry

Le 18/02/2013 22:28, Sean P. DeNigris a Ã©crit : > http://code.google.com/p/pharo/issues/detail?id=7534 http://code.google.com/p/pharo/issues/detail?id=7509 With Igor suggestions on how to correct that :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 19, 2013

Re: [Pharo-project] Phexample should methods

by Adrian Kuhn

On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote: > That gives rise to example-driven testing ala: > > Foo >> #barShouldBeSomething > > So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name. > > Any opinions on that? Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods (imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class. I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ... Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome! > PS: It is also inconsistent with Phexample's own #isTest: implementation, which uses #beginsWith: Oops, that's a bug, #theMoreGeneralCaseShouldApply :) Even though personally I prefer to not use should inside the name in order to limit the pollution for the selection name space with regard to Smalltalk's simple autocomplete ... --AA

Feb. 19, 2013