- Pharo-dev - lists.pharo.org

Issue tracker: do not forget to change state to "fix review needed"

by Marcus Denker

Hi, When submitting a fix, please do not forget to change the state of the issue. And issue with âwork neededâ yet a fix in the inbox will only be looked at by chance, and that chance is *very* low with 570 open issuesâ¦ Marcus

Dec. 4, 2013

Re: [Pharo-dev] Slice 12324

by Stephan Eggermont

Thanks Marcus.

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Frank Shearar

On 4 December 2013 10:01, Attila Magyar <m.magyar3(a)gmail.com> wrote: > Sean P. DeNigris wrote >> Are you interested in integrating my changes into the current API? If so, >> I'll refactor them and clean them up. I personally would find it difficult >> to use the library without them. Coming from Ruby, a proper test double >> framework is the thing I miss most. Rspec was amazing. BabyMock is close, >> and with these changes has the test double features I commonly relied on >> Rspec for... > > Yes, anyArgs can be useful, and I was thinking about the /does/ extension > too, and I convinced myself that it is ok and useful. I gave you access to > the repo. > > The reason for my initial hesitation was that my goal is to not have too > powerful features like rspec has. E.g. in rspec, it is easy to stub out > global class objects and I see lots of ruby programmer doing it. I don't > think this is the right solution for the problem. Can you give an example of what you mean? Being about to stub out the file system, or the clock, seem like extremely useful things to do. (See https://github.com/defunkt/fakefs for instance.) frank

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Attila Magyar

Sean P. DeNigris wrote > Are you interested in integrating my changes into the current API? If so, > I'll refactor them and clean them up. I personally would find it difficult > to use the library without them. Coming from Ruby, a proper test double > framework is the thing I miss most. Rspec was amazing. BabyMock is close, > and with these changes has the test double features I commonly relied on > Rspec for... Yes, anyArgs can be useful, and I was thinking about the /does/ extension too, and I convinced myself that it is ok and useful. I gave you access to the repo. The reason for my initial hesitation was that my goal is to not have too powerful features like rspec has. E.g. in rspec, it is easy to stub out global class objects and I see lots of ruby programmer doing it. I don't think this is the right solution for the problem. -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4727265.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 4, 2013

Re: [Pharo-dev] Slice 12324

by Marcus Denker

On 03 Dec 2013, at 18:36, Stephan Eggermont <stephan(a)stack.nl> wrote: > Can anyone put it in place? Canât seem to commit it I get an error when I try to copy it to the inbox, but saving it again worked. Marcus

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by StÃ©phane Ducasse

On Dec 4, 2013, at 5:18 AM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > This is the task I would really like to participate in. Although, just as you, I have no time at all, I still will find at least few hours a week :) welcome to our nice club of busy people

Dec. 4, 2013

[pharo-project/pharo-core]

by GitHub

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

Dec. 4, 2013

[pharo-project/pharo-core] 28388b: 30618

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 28388b0732fe53dc90ace03d1d7fb813f2b5234e https://github.com/pharo-project/pharo-core/commit/28388b0732fe53dc90ace03d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-04 (Wed, 04 Dec 2013) Changed paths: M KernelTests.package/ClassDescriptionTest.class/instance/tests/testClassDescriptionRespectsPolymorphismWithTraitDescription.st M Morphic-Base.package/MorphTreeNodeMorph.class/instance/drawing/drawCheckOn_in_.st A Morphic-Base.package/MorphTreeNodeMorph.class/instance/drawing/drawCheckedIconOn_at_.st A Morphic-Base.package/MorphTreeNodeMorph.class/instance/drawing/drawPartialCheckedIconOn_rectangle_at_offset_.st A Morphic-Base.package/MorphTreeNodeMorph.class/instance/drawing/drawUncheckedIconOn_at_.st M Network-Mail.package/MailMessage.class/class/utilities/dateTimeSuffix.st A Polymorph-Widgets.package/EclipseUIThemeIcons.class/instance/accessing - icons/checkedBoxIcon.st A Polymorph-Widgets.package/EclipseUIThemeIcons.class/instance/accessing - icons/partialCheckedBoxIcon.st A Polymorph-Widgets.package/EclipseUIThemeIcons.class/instance/accessing - icons/uncheckedBoxIcon.st A Polymorph-Widgets.package/EclipseUIThemeIcons.class/instance/private - contents/checkedBoxIconContents.st A Polymorph-Widgets.package/EclipseUIThemeIcons.class/instance/private - contents/partialCheckedBoxIconContents.st A Polymorph-Widgets.package/EclipseUIThemeIcons.class/instance/private - contents/uncheckedBoxIconContents.st A Polymorph-Widgets.package/ThemeIcons.class/instance/accessing - icons/checkedBoxIcon.st A Polymorph-Widgets.package/ThemeIcons.class/instance/accessing - icons/partialCheckedBoxIcon.st A Polymorph-Widgets.package/ThemeIcons.class/instance/accessing - icons/uncheckedBoxIcon.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script273.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30618.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/OldClassBuilderAdapter.class/definition.st R Slot.package/SlotVirus.class/README.md R Slot.package/SlotVirus.class/class/fixing/fixSuperclassSubclasses_.st R Slot.package/SlotVirus.class/class/fixing/refresh.st R Slot.package/SlotVirus.class/class/fixing/removeBrokenDoIts.st R Slot.package/SlotVirus.class/class/installing/basicLayoutFor_.st R Slot.package/SlotVirus.class/class/installing/basicLayoutScopeFor_.st R Slot.package/SlotVirus.class/class/installing/basicVariableLayoutFor_.st R Slot.package/SlotVirus.class/class/installing/basicWeakLayoutFor_.st R Slot.package/SlotVirus.class/class/installing/installLayoutVariable.st R Slot.package/SlotVirus.class/class/installing/installNewLayouts.st R Slot.package/SlotVirus.class/class/installing/layoutScopeFor_.st R Slot.package/SlotVirus.class/class/installing/newLayoutFor_.st R Slot.package/SlotVirus.class/class/installing/spread.st R Slot.package/SlotVirus.class/class/testing/checkAllLayouts.st R Slot.package/SlotVirus.class/class/testing/checkDuplicateClass_.st R Slot.package/SlotVirus.class/class/testing/checkInheritedSlots_.st R Slot.package/SlotVirus.class/class/testing/checkLayoutOfClass_.st R Slot.package/SlotVirus.class/class/testing/checkLayout_.st R Slot.package/SlotVirus.class/class/testing/checkSlotsIndices_.st R Slot.package/SlotVirus.class/class/testing/invalidClasses.st R Slot.package/SlotVirus.class/definition.st R Slot.package/extension/ClassDescription/instance/initializeLayout.st Log Message: ----------- 30618 12327 Use eclipse icon for checklist tick https://pharo.fogbugz.com/f/cases/12327 11832 Remove SlotVirus https://pharo.fogbugz.com/f/cases/11832 12326 MailMessage class >> #dateTimeSuffix calls deprecated primSecondsClock https://pharo.fogbugz.com/f/cases/12326 http://files.pharo.org/image/30/30618.zip

Dec. 4, 2013

Re: [Pharo-dev] AST-Semantic in Pharo 3.0???

by Marcus Denker

On 04 Dec 2013, at 00:53, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > Hi all, > I see that ast-semantic is present in Pharo 2.0 but is not present in Pharo 3.0, > so the question is > How did you replace it? > what do you use in Pharo 3.0? > We use the Semantic analysis phase of Opal. Itâs exactly the same thing, slightly different implementation. It does a bit more as it needs to analyse correctly for optimised blocks and needs to do the tempVector/copying temp analysis for the closure model of Cog). The class that does the analysis is OCASTSemanticAnalyzer (together with OCASTClosureAnalyzer, we visit a second time for tempVector vs. copying for escaping variables). Analysis is triggered with #doSemanticAnalysis on the RBProgramNode. -> every method+block get a scope (see OCAbstractScope) (this knows the defined vars and the hierarchy models ivar/class/global lookup) -> variables are represented as subclasses of OCAbstractVariable -> the Variables AST node has a property binding for such a semantic variable -> the semantic variable knows what kind of var it is, so it is easy to implement #isTemp as isTemp ^self binding isTemp There is some preliminary work to model temp vs. ivar as AST node subclasses, but Opal is not using that and the implementation has some problems. This will see some work soon, I think. Marcus

Dec. 4, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Dennis Schetinin

This is the task I would really like to participate in. Although, just as you, I have no time at all, I still *will* find at least few hours a week :) -- Best regards, Dennis Schetinin 2013/12/3 Denis Kudriashov <dionisiydk(a)gmail.com> > Problem with TestCase approach is mixing two separate concerns. First is > how we want to define system specifications. Another is how we can persist > such specifications. When we stay at test case level we lost freedom for > specification definition. We restricted with smalltalk language artifacts. > For example, how we can group our tests? With classic test case approach > we have four levels: packages, classes, protocols and methods. Now remember > how many times you put long names for test like > #shouldDoingSomethingWhenSomeSitiationHappensDuringAnotherSituationHappenButWhenSituation3NotHappen. > And most times you have tests for each separate situation with same long > test names. > In smalltalk only way to refactor test names duplication is extraction > same "when condition" to separate test case classes. But it means that you > build classes with very long names and most times your test names stay big > (but with reduced length). And do you know way how to group such classes? > Only way is put such classes to own class category. Nobody doing this. > > Now imagine we don't care how to persist tests (specifications). We can > model specifications with explicit objects which present #when, #should and > other test artifacts, which can group specifications with arbitrary way. > With true objects we don't name our specifications with method name > convention. We can name tests with natural language, we can put names for > "when" and "should" expressions with natural language. > With objects we can build "smalltalk vision" of BDD framework. Really with > smalltalk live system testing environment can be very different from other > languages. BDD frameworks of other languages just changed names of "TDD > dictionary". They all stay restricted with language syntax. > > So it is my vision. I really want to build such system but I have no time > for this yet. > Maybe Sean doing something similar? > > > > 2013/12/3 Esteban A. Maringolo <emaringolo(a)gmail.com> > >> 2013/12/3 Dennis Schetinin <chaetal(a)gmail.com> >> >> > >> > I see the only correct way to build a good testing environment: tests >> should be basically objects, not methods. >> >> They are objects. Instances of TestCase. >> >> But for simplicity they're implemented in a single "factory" class, >> the TestCase subclass... >> >> >> >> Esteban A. Maringolo >> >> >

Dec. 4, 2013