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

[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

Re: [Pharo-dev] Unifying Testing Ideas

by Sean P. DeNigris

On Dec 3, 2013, at 2:43 PM, Attila Magyar [via Smalltalk] <ml-node+s1294792n4727144h52(a)n4.nabble.com> wrote: > It's true, but it would make difficult to return a block. E.g. > > mock can receive: #msg; answers: [ [..] ] I'll trade an extra pair of brackets in a less common case for a simpler API any day ;) > Anyways, I'm working on the next version with a slightly different api. My plan is to fully separate the DSL from the main part. This will make possible to play with different syntax without touching the core. Or even the users will be able to define their own syntax. 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... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4727195.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 4, 2013

Re: [Pharo-dev] [Moose-dev] Roassal 3d now support textures

by Alexandre Bergel

Better is to wait I arrive in Lille. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Dec 3, 2013, at 6:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 3, 2013, at 10:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 3 December 2013 12:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> did you move some functionality (to the place they belong) to NBOpenGL? >> Because this should be done and JB has already spent time on that. >> >> I am not sure it is good choice to expand NBOpenGL. >> There's just API, and most of code is generated (imported from specs), >> so changing something there makes little sense. >> Accompanying package , however , would be much better (in same repo, if you want). > > I was talking about shadder code > > Stef >> >> >> >> Stef >> >>> hi! >>> >>> Just to keep you up to date with the Roassal 3d effort. >>> https://www.facebook.com/photo.php?fbid=547995685287033&set=a.5299979037534… >>> >>> Cheers, >>> Alexandre >>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Dec. 4, 2013

AST-Semantic in Pharo 3.0???

by Bernardo Ezequiel Contreras

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? Thanks. -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Dec. 3, 2013

Re: [Pharo-dev] vm patch for issue-11293

by phil＠highoctane.be

Right tracker. You can fork, do your changes, and issue a pull request if things look right. Phil

Dec. 3, 2013

Re: [Pharo-dev] CompiledMethod>>#= is broken

by ClÃ©ment Bera

Marcus/Esteban I opened the bug and it is ready to integrate. https://pharo.fogbugz.com/f/cases/12331/Fixed-CompiledMethod 2013/12/3 Eliot Miranda <eliot.miranda(a)gmail.com> > > > > On Tue, Dec 3, 2013 at 11:27 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> >> >> >> On Tue, Dec 3, 2013 at 9:49 AM, Oscar Nierstrasz < >> oscar.nierstrasz(a)gmail.com> wrote: >> >>> >>> The following code breaks: >>> >>> (SortedCollectionTest>>#testDo) = (SortedCollectionTest>>#testStoreOn). >>> >>> because it makes use of AdditionalMethodState>>#analogousCodeTo: which >>> tries to send #analogousCodeTo: to a property which is an Association. >>> >>> It seems to me the solution is to implement >>> Association>>#analogousCodeTo: with an equality test: >>> >>> analogousCodeTo: anObject >>> ^self class == anObject class >>> and: [ self = anObject ] >>> >>> Does this make sense? >>> >> >> Yes. I should have written it this way in the first place. Thanks. >> >> >>> >>> See: >>> >>> >>> https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analog… >>> >>> Oscar Nierstrasz >>> >>> >>> >> >> >> -- >> best, >> Eliot >> > > > > -- > best, > Eliot >

Dec. 3, 2013

Re: [Pharo-dev] vm patch for issue-11293

by Nicolai Hess

2013/12/3 phil(a)highoctane.be <phil(a)highoctane.be> > On Github, the pharo-vm has only one place for GetFileAttributesEx and > that's in > > platforms/win32/vm/sqWin32Directory.c l366-368 > > It is GetFileAttributesExW by the way and inside: > > > int dir_EntryLookup(char *pathString, int pathLength, char* nameString, > int nameStringLength, > /* outputs: */ char *name, int *nameLength, int *creationDate, int > *modificationDate, > int *isDirectory, squeakFileOffsetType *sizeIfFile, > sqInt *posixPermissions, sqInt *isSymlink) > ... > > > > if(!GetFileAttributesExW(win32Path, 0, &winAttrs)) { > return NO_MORE_ENTRIES; > } > > Don't know about the other flavors. > > Phil > Yes, that is the version I used and that I want to patch. I think this is the source for all current pharo-vm. Is pharo.fogbugz.com the right issue tracker for this? Who would review / apply this patch? Nicolai

Dec. 3, 2013