March 2016 - Pharo-dev - lists.pharo.org

[Ann] New version of StateSpecs 2.0

by Denis Kudriashov

Hello. I glad to present new version of StateSpecs: - should expressions based on normal message sends instead of pragma magic Pragma based approach allows to write very natural expressions like 1 should be an instance of: Number But it is completely not practical because it is impossible to work with such code as with any other. No easy way to find senders or implementors of expressions. It is difficult to understand how it works. It's hidden magic. So now this approach is extracted to separate package as nice experiment on what can be done with smalltalk. And legal approach now is to use normal keywords like: 1 should beInstanceOf: SmallInteger 1 should beKindOf: Number With this you can easily find implementors and get full list of defined expressions. (look at class SpecOfShouldExpression) - new functionality: - boolean properties validation. You can send any messages to "should be" which will be executed by subject of "should" and then validated for truth: 1 should be between: 10 and: 50 #(1 2) should be isEmpty - properties chain validation. You can send any series of messages to "object where" to write should expression for internal property: (1@3) where x should be: 1 (0@1 corner: 10@20) where origin x should be: 0 - unordered equality for collections and explicit order sentence: #(1 2) should equal: #(2 1) "not fail" (1 2) should beOrderedEqualTo: #(2 1) "fail" Idea that in tests you usually put as less details as possible. And only if you really need specific behaviour you write it requirement explicitly. - better failures descriptions similar to existed assertions: 1 should be: 2 => Got "1" but it should be "2" 1 should beInstanceOf: String => Got "1" but it should be instance of String #(1 2) should be isEmpty => #(1 2) should be isEmpty (1@3) where x should be: 10 => Got "1" from (1@3) x but it should be 10 - improved existing should expressions: - collection item specification is based on expected item spec #(10 20) should include: 10 at: 1 #(10 20) should include: (Kind of: Number) at: 1 - block failure spec is based on expected failure spec: [1/0] should raise: ZeroDivide "not fail" [1/0] should raise: Error "fail because explicit exception class is specified" [1/0] should raise: (Kind of: Error) "not fail" [self error: 'test'] should raise: errorInstance "fail because raised exception is not the same instance as errorInstance" [1/0] should raiseError "not fail when any kind of errors was signalled" - repackaged to separate specs from DSL code - cleaned classes - comments - no dependency from SMock anymore You can load StateSpecs by Gofer it smalltalkhubUser: 'dionisiy' project: 'StateSpecs'; configurationOf: 'StateSpecs'; loadStable. . Loo at details and examples here http://www.smalltalkhub.com/#!/~dionisiy/StateSpecs I hope StateSpecs can become legal alternative for classic assertions. It models requirements and failures as first class objects which make them good target for object specific tools which will be difficult to achieve with assertion methods. Best regards, Denis

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Ben Coman

On Wed, Mar 23, 2016 at 8:39 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-23 12:38 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> Maybe... >> [ mock someMessage. mock2 somMessage2 ] shouldve beenSent >> >> but maybe you don't want different #shouldXXX messages. > > > Thank you too, Ben. And yes it will not follow other should expressions. But > it would not be bad to use completely different word instead of #should Okay, then perhaps... [mock someMessage. mock2 someMessage2] were sent [mock someMessage. mock2 someMessage2] were sentInOrder [mock someMessage. mock2 someMessage2] were done [mock someMessage. mock2 someMessage2] were doneInOrder but then do you also need singular #was for single items? [mock someMessage. mock2 someMessage2] expect done [mock someMessage. mock2 someMessage2] expect doneInOrder Expect squeezes in usage in both future and past tense... "I expect he'll arrive soon" "I expect he went home" cheers -ben

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Denis Kudriashov

2016-03-23 12:38 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Maybe... > [ mock someMessage. mock2 somMessage2 ] shouldve beenSent > > but maybe you don't want different #shouldXXX messages. > Thank you too, Ben. And yes it will not follow other should expressions. But it would not be bad to use completely different word instead of #should

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Ben Coman

On Wed, Mar 23, 2016 at 6:31 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-03-23 11:02 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >> >> But from English it not sounds like it should be occurred in past. Normally thats my cue ;) but I don't have any great ideas. >> So what correct and not long sentence can be used here? maybe: >> >> mock had received someMessage >> >> >> mock should haveReceived someMessage >> > > Thank's for suggestions. Thats idea from Marcus too. But it feels too long. > But maybe. Now I actually already rename #receive to #haveReceived. But I > hope for better sentence. >> >> >> And same question for verification group of message sends (at the end of >> test): >> >> [mock someMessage. mock2 someMessage2] should occur >> >> [mock someMessage. mock2 someMessage2] should occurInSameOrder >> >> >> [ mock someMessage. mock2 somMessage2 ] should have beenSent > > > It's long too. And I wish reduce number of separated words because it is not > good practically. Maybe... [ mock someMessage. mock2 somMessage2 ] shouldve beenSent but maybe you don't want different #shouldXXX messages. cheers -ben > It raises more questions: how it is implemented, what the > better name for intermediate object (result of have in that case) and > others. > At least your suggestion will be like > [ mock someMessage. mock2 somMessage2 ] should haveBeenSent > > Another idea is to use #happen word: > [ mock someMessage. mock2 somMessage2 ] should happen

March 23, 2016

Re: [Pharo-dev] Discussing FileSystem >> #workingDirectory and VM process getcwd(3)

by Damien Cassou

Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > On Tue, Mar 22, 2016 at 9:37 AM, Damien Pollet <damien.pollet(a)gmail.com> > wrote: > >> Because there is this concept called "consistency" that's interesting to >> have :p >> >> If your code wants $HOME it can ask for it explicitly, same for /. However >> if it just wants to do something in $PWD consistent with most use-cases, >> the image directory is the sensible default. >> >> > I agree with Pollet. I don't care if it is image directory or $HOME. What I > care is that $PWD of the VM process should match with FileSystem >> > workingDirectory. And right now it does not match. I was not clear enough: I agree that consistency is important and VM must answer the same as image. What that "same" should be is still unclear to me though. You propose the image folder, but this is inconsistent with other applications launched by double-click. I propose to be consistent with other applications: HOME on Linux, / on OS X. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Denis Kudriashov

2016-03-23 11:02 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > But from English it not sounds like it should be occurred in past. So what > correct and not long sentence can be used here? maybe: > > mock had received someMessage > > > mock should haveReceived someMessage > > Thank's for suggestions. Thats idea from Marcus too. But it feels too long. But maybe. Now I actually already rename #receive to #haveReceived. But I hope for better sentence. > > And same question for verification group of message sends (at the end of > test): > > [mock someMessage. mock2 someMessage2] should occur > > [mock someMessage. mock2 someMessage2] should occurInSameOrder > > > [ mock someMessage. mock2 somMessage2 ] should have beenSent > It's long too. And I wish reduce number of separated words because it is not good practically. It raises more questions: how it is implemented, what the better name for intermediate object (result of have in that case) and others. At least your suggestion will be like [ mock someMessage. mock2 somMessage2 ] should haveBeenSent Another idea is to use #happen word: [ mock someMessage. mock2 somMessage2 ] should happen

March 23, 2016

Re: [Pharo-dev] Naming question for new version of Mocketry

by Max Leske

> On 23 Mar 2016, at 10:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > I prepare new version of Mocketry with many new functions. And I have little question about some naming. > > It will be possible to verify (at the end of test) that particular message was happened. My first suggestion was: > > mock should receive someMessage > > But from English it not sounds like it should be occurred in past. So what correct and not long sentence can be used here? maybe: > > mock had received someMessage mock should haveReceived someMessage > > And same question for verification group of message sends (at the end of test): > > [mock someMessage. mock2 someMessage2] should occur > [mock someMessage. mock2 someMessage2] should occurInSameOrder [ mock someMessage. mock2 somMessage2 ] should have beenSent > > Does it sounds correct? What suggestions? > > Best regards, > Denis Cheers, Max

March 23, 2016

Naming question for new version of Mocketry

by Denis Kudriashov

Hello. I prepare new version of Mocketry with many new functions. And I have little question about some naming. It will be possible to verify (at the end of test) that particular message was happened. My first suggestion was: mock should receive someMessage But from English it not sounds like it should be occurred in past. So what correct and not long sentence can be used here? maybe: mock had received someMessage And same question for verification group of message sends (at the end of test): [mock someMessage. mock2 someMessage2] should occur [mock someMessage. mock2 someMessage2] should occurInSameOrder Does it sounds correct? What suggestions? Best regards, Denis

March 23, 2016

[pharo-project/pharo-core]

by GitHub

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

March 23, 2016

[pharo-project/pharo-core] 5153ef: 50658

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5153ef622fc2e172d61a9e8163d712ccb0098308 https://github.com/pharo-project/pharo-core/commit/5153ef622fc2e172d61a9e81… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-03-23 (Wed, 23 Mar 2016) Changed paths: M Collections-Tests.package/ArrayTest.class/instance/initialization/setUp.st M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F17_.st M OpalCompiler-Tests.package/OCNewCompilerWithChangesFunctionalTests.class/instance/other-tests/testModulePrimitive.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50657.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50658.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50657.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50658.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R UnifiedFFI-Legacy.package/extension/FFIExternalObject/instance/handle.st R UnifiedFFI-Legacy.package/extension/FFIExternalObject/instance/handle_.st A UnifiedFFI-Legacy.package/extension/FFIExternalReference/instance/handle.st A UnifiedFFI-Legacy.package/extension/FFIExternalReference/instance/handle_.st A UnifiedFFI-Tests.package/FFIConstantHandleTests.class/README.md A UnifiedFFI-Tests.package/FFIConstantHandleTests.class/definition.st A UnifiedFFI-Tests.package/FFIConstantHandleTests.class/instance/primitives/getTimeReturnConstantHandle_.st A UnifiedFFI-Tests.package/FFIConstantHandleTests.class/instance/primitives/getTime_.st A UnifiedFFI-Tests.package/FFIConstantHandleTests.class/instance/tests/testCall.st A UnifiedFFI-Tests.package/FFIConstantHandleTests.class/instance/tests/testReturn.st A UnifiedFFI.package/FFICharacterType.class/instance/testing/needsArityPacking.st R UnifiedFFI.package/FFICharacterType.class/instance/testing/needsArityRolling.st A UnifiedFFI.package/FFICharacterType.class/instance/testing/needsArityUnpacking.st R UnifiedFFI.package/FFICharacterType.class/instance/testing/needsArityUnrolling.st A UnifiedFFI.package/FFIConstantHandle.class/README.md A UnifiedFFI.package/FFIConstantHandle.class/class/converting/asExternalTypeOn_.st A UnifiedFFI.package/FFIConstantHandle.class/class/instance creation/fromInteger_.st A UnifiedFFI.package/FFIConstantHandle.class/definition.st A UnifiedFFI.package/FFIConstantHandle.class/instance/initialization/createDefaultHandle.st A UnifiedFFI.package/FFIConstantHandleType.class/README.md A UnifiedFFI.package/FFIConstantHandleType.class/class/private/naturalPointerArity.st A UnifiedFFI.package/FFIConstantHandleType.class/definition.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/accessing/externalType.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/accessing/externalTypeSize.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/accessing/instanceVariableName.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/emitting code/emitReturnArgument_context_.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/emitting code/readFieldAt_.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/emitting code/readHandleAt_.st A UnifiedFFI.package/FFIConstantHandleType.class/instance/emitting code/writeFieldAt_with_.st M UnifiedFFI.package/FFIDereferencedOpaqueObjectError.class/README.md A UnifiedFFI.package/FFIExternalReference.class/instance/initialization/createDefaultHandle.st M UnifiedFFI.package/FFIExternalReference.class/instance/initialization/initialize.st M UnifiedFFI.package/FFIExternalReferenceType.class/instance/emitting code/emitReturnArgument_context_.st A UnifiedFFI.package/FFIExternalReferenceType.class/instance/testing/needsArityUnpacking.st R UnifiedFFI.package/FFIExternalReferenceType.class/instance/testing/needsArityUnrolling.st M UnifiedFFI.package/FFIExternalType.class/instance/emitting code/emitArgument_context_.st M UnifiedFFI.package/FFIExternalType.class/instance/emitting code/emitPointerArityRoll_context_.st M UnifiedFFI.package/FFIExternalType.class/instance/emitting code/emitReturnArgument_context_.st A UnifiedFFI.package/FFIExternalType.class/instance/testing/needsArityPacking.st R UnifiedFFI.package/FFIExternalType.class/instance/testing/needsArityRolling.st A UnifiedFFI.package/FFIExternalType.class/instance/testing/needsArityUnpacking.st R UnifiedFFI.package/FFIExternalType.class/instance/testing/needsArityUnrolling.st M UnifiedFFI.package/FFIFloat32.class/instance/emitting code/emitPointerArityRoll_context_.st M UnifiedFFI.package/FFIFloat64.class/instance/emitting code/emitPointerArityRoll_context_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitHandleArityUnpack_type_context_objectClass_instVarName_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityPack_context_arity_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityPack_context_arity_selector_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityRoll_context_arity_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityRoll_context_arity_selector_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityUnpack_type_context_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityUnpack_type_context_objectClass_instVarName_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityUnroll_type_context_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/emitting code/emitPointerArityUnroll_type_context_objectClass_instVarName_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/addUnpack_fromArity_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/addUnroll_fromArity_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/emitArgumentVariableAccesingPart_context_objectClass_instVarName_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/emitPointerArityUnpack_context_arity_.st A UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/emitPointerArityUnpack_context_objectClass_instVarName_arity_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/emitPointerArityUnroll_context_arity_.st R UnifiedFFI.package/FFIFunctionArgument.class/instance/private emitting code/emitPointerArityUnroll_context_objectClass_instVarName_arity_.st A UnifiedFFI.package/FFIInstVarArgument.class/instance/private emitting code/emitArgumentVariableAccesingPart_context_objectClass_instVarName_.st A UnifiedFFI.package/FFIMethodArgument.class/instance/private emitting code/emitArgumentVariableAccesingPart_context_objectClass_instVarName_.st A UnifiedFFI.package/FFIOop.class/instance/testing/needsArityUnpacking.st R UnifiedFFI.package/FFIOop.class/instance/testing/needsArityUnrolling.st A UnifiedFFI.package/FFIOpaqueObjectType.class/instance/testing/needsArityPacking.st R UnifiedFFI.package/FFIOpaqueObjectType.class/instance/testing/needsArityRolling.st A UnifiedFFI.package/FFISelfArgument.class/instance/private emitting code/emitArgumentVariableAccesingPart_context_objectClass_instVarName_.st A UnifiedFFI.package/FFIVoid.class/instance/testing/needsArityPacking.st R UnifiedFFI.package/FFIVoid.class/instance/testing/needsArityRolling.st A UnifiedFFI.package/FFIVoid.class/instance/testing/needsArityUnpacking.st R UnifiedFFI.package/FFIVoid.class/instance/testing/needsArityUnrolling.st A UnifiedFFI.package/extension/ByteArray/instance/packAsDoubleToArity_.st A UnifiedFFI.package/extension/ByteArray/instance/packAsFloatToArity_.st A UnifiedFFI.package/extension/ByteArray/instance/packToArity_.st R UnifiedFFI.package/extension/ByteArray/instance/rollAsDoubleToArity_.st R UnifiedFFI.package/extension/ByteArray/instance/rollAsFloatToArity_.st R UnifiedFFI.package/extension/ByteArray/instance/rollToArity_.st A UnifiedFFI.package/extension/ByteArray/instance/unpackHandleFromArity_.st A UnifiedFFI.package/extension/ExternalAddress/instance/packToArity_.st R UnifiedFFI.package/extension/ExternalAddress/instance/rollToArity_.st A UnifiedFFI.package/extension/ExternalAddress/instance/unpackFromArity_.st A UnifiedFFI.package/extension/ExternalAddress/instance/unpackHandleFromArity_.st R UnifiedFFI.package/extension/ExternalAddress/instance/unrollFromArity_.st A UnifiedFFI.package/extension/Float/instance/packAsDoubleToArity_.st A UnifiedFFI.package/extension/Float/instance/packAsFloatToArity_.st A UnifiedFFI.package/extension/Float/instance/packToArity_.st R UnifiedFFI.package/extension/Float/instance/rollAsDoubleToArity_.st R UnifiedFFI.package/extension/Float/instance/rollAsFloatToArity_.st R UnifiedFFI.package/extension/Float/instance/rollToArity_.st A UnifiedFFI.package/extension/Object/instance/packToArity_.st R UnifiedFFI.package/extension/Object/instance/rollToArity_.st A UnifiedFFI.package/extension/SmallInteger/instance/unpackFromArity_.st R UnifiedFFI.package/extension/SmallInteger/instance/unrollFromArity_.st A UnifiedFFI.package/extension/String/instance/packToArity_.st R UnifiedFFI.package/extension/String/instance/rollToArity_.st A UnifiedFFI.package/extension/UndefinedObject/instance/packToArity_.st R UnifiedFFI.package/extension/UndefinedObject/instance/rollToArity_.st Log Message: ----------- 50658 17859 testModulePrimitive should use mock instead of real class https://pharo.fogbugz.com/f/cases/17859 17866 add support for HANDLE types (windows) https://pharo.fogbugz.com/f/cases/17866 17861 ArrayTest should not use Color https://pharo.fogbugz.com/f/cases/17861 http://files.pharo.org/image/50/50658.zip

March 23, 2016