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

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Attila Magyar

> They have strings. And first mock libraries used message names as strings They are not the same. Method rename and find senders works with symbols but not with strings. Some rarely used refactorings might not work, although this is probably a technical limitation of the refactoring engine and not a conceptual one. > not believe that anybody would prefer writing In Ruby this would look like something like this. allow(socket).to receive(:connect).with(address, port, timeout) { do_something } Not so different and many people use this. Probably lot more than the users of Mocketry + BabyMock together. (Anyways probably I wouldn't use a mock library to stub an object like a socket. It is not my own type, too low-level abstraction. It results brittle tests no matter what syntax is used.) > It leads to more code which you will write again and again in your tests If I have too many code for setting up expectations and mocks that is a clear clue that something went wrong in my test, and I rather have a mock library that makes this painful early on. It is really easy to make a mess with mock object based tests. This is why I still prefer jMock over any other mock object library (mockito, easymock) in Java. JMock is a highly opinionated library that deliberately doesn't support features like deep stubbing, partial mocking and other black magic stuffs. BabyMock follows a similar philosophy. -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 1, 2016

Taskit multiple images?

by Yuriy Tymchuk

Hi, is it possible to compute data really really concurrently with Taskit by using multiple images? Because while doing some analysis I need to do boring computations on big collections and processing a collection concurrently can speedup things a lot. Uko

Nov. 1, 2016

Re: [Pharo-dev] [Pharo-users] Using a Unix filedescriptor in a FileStream?

by Mariano Martinez Peck

Hi Holger, Esteban, et all What is the status of https://github.com/pharo-project/pharo-vm/pull/108 ? Will this be finally integrated or not? Because I updated OSSubprocess to take benefit of this PR (OSSubprocess is much better with this PR), but I will have to revert it if the PR is not merged :( Thanks, On Fri, Sep 23, 2016 at 5:40 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > On 23 Sep 2016, at 02:44, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > > > Hi Holger, > > Hi! > > > > Currently the events given by this API are only holding a copy of the > raw inotify event in rawEvent and a copy of the raw path in rawPath. > Further work is required for translating the events into a more platform > independent interface, and for supporting OS X and Windows with this API. > However, this is already something that could be useful to you. > > if I see it correctly you start a poll loop (wait 100ms then call epoll > wait)? Would you be interested to try to use AioEventHandler with the > primitive I proposed? > > regards > holger > -- Mariano http://marianopeck.wordpress.com

Nov. 1, 2016

[pharo-project/pharo-core]

by GitHub

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

Nov. 1, 2016

[pharo-project/pharo-core] 48592d: 60274

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 48592d21b9b3e445f1159e54d93eb1da3235e6fd https://github.com/pharo-project/pharo-core/commit/48592d21b9b3e445f1159e54… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-11-01 (Tue, 01 Nov 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version34_.st M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version12_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version322_.st M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version318_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version220_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version330_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version4191_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version424_.st M GT-Inspector.package/GTObjectPrinter.class/instance/printing/asTruncatedTextFrom_.st A GT-InspectorExtensions-Core.package/extension/Bag/instance/gtInspectorItemsIn_.st M GT-InspectorExtensions-Core.package/extension/Bag/instance/gtInspectorOccurrencesIn_.st A GT-Spotter.package/GTSpotterResultsBrick.class/instance/drawing/clipSubmorphs.st M Glamour-Morphic-Pager.package/GLMPagerBrick.class/instance/pager-actions/scrollerSizeShortcutAction_second_.st M Glamour-Morphic-Renderer.package/GLMMorphicListingRenderer.class/instance/private/treeMorphFor_and_.st R Glamour-Morphic-Widgets.package/GLMSystemWindow.class/instance/event handling/handleKeyStroke_.st A Glamour-Morphic-Widgets.package/GLMSystemWindow.class/instance/event handling/handlesKeyStroke_.st A Glamour-Morphic-Widgets.package/GLMSystemWindow.class/instance/event handling/keyStroke_.st M Glamour-Morphic-Widgets.package/GLMSystemWindow.class/instance/initialization/initialize.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60273.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60274.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60273.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60274.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60274 Moose http://files.pharo.org/image/60/60274.zip

Nov. 1, 2016

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Denis Kudriashov

2016-11-01 11:50 GMT+01:00 Attila Magyar <m.magyar3(a)gmail.com>: > > BabyMock could not be treated as modern mock library just because it uses > > symbols instead of normal message sends. Even C# and Java mocks are based > > on normal messages. > > Because they don't have symbols :). They have strings. And first mock libraries used message names as strings. And any method rename broke tests. > Ruby libraries often use symbols, last > time I checked rspec mocks used it too. I think this is a matter of taste, > it's not about being modern or not. > Probably it looks not so bad with C-like syntax because everything is just function name and arguments inside parenthesise. But with Smalltalk keywords syntax it looks horrible. I not believe that anybody would prefer writing: protocol describe once: socket recv: #connectTo:port:waitForConnectionFor: with: address with: port with: timeout. over simple: socket stub connectTo: address port: port waitForConnectionFor: timeout. And as I said symbol(string) based version is not safe for refactorings. > > I like thinking about mock objects as tools for describing inter-object > protocols (the visualisation tries to emphasize this aspect). I agree with you. > The > communication protocol between the object under test and its peers (mocks) > is expressed in a descriptive language (this language can be changed in > BabyMock quite easily). A narrator object (this is called Protocol in > BabyMock2) speaks in the third person to describe the message exchange > between the object cluster. > I don't like when expectations are set up in mocks directly any more, > It leads to more code which you will write again and again in your tests. And this code is nothing about actual business which tests describe. In Mocketry there is also a guy who manages all specifications and collects all interactions but it's hidden from user. With Mocketry I try to make mocks as simple as possible without losing power. > neither the should/should have notation. The GOOS book was a big influence > on me at that time. >

Nov. 1, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

On 11/01/2016 03:28 PM, test wrote: > Hi Martin, > thanks for this analysis, i really appreciate it. you did proof that, > as you said "1.2000000000000002 *is* the correct answer for 1.19 > roundTo: 0.1.". please excuse me - i seriously think it was very > friendly of you to do this detailed analysis -, but my argument never > was, that if i use Float>roundTo: this produces problematic > floating-point-errors. if it produces floating-point-errors they > wouldnt be unexpected. i thought this would be clear from my previous > posts. what i tried to say is, that i am a simple user and pharo > shouldnt expect from me, that i know, that if i want a result looking > a bit more like 1.2, i should use "(x asFraction > roundTo:(1/10))asFloat" instead of "x roundTo:0.1". the #round: method > circumvents the irritating part of Float calcs imo in an inexpensive > way, and rounding numbers is imo not a very exotic task, but to > presume that i figure out (x asFraction roundTo:(1/10))asFloat by > myself is simply expecting too much from me. otoh now i that i know > how to do it, it's not a problem for me, if the majority wants to > deprecate #roundTo:. oops ... deprecate #round: ... of course > Thank you again for the careful analysis > werner > On 10/31/2016 09:58 PM, Martin McClure wrote: >> tl;dr: >> >> 1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1. >> (1.19 roundTo: (1/10))asFloat gives a different answer because it's >> rounding to a multiple of exactly 0.1, not the Float nearest to 0.1. >> >> >> On 10/31/2016 08:35 AM, test wrote: >>> oops, make that original number 1.19 in the example. >> OK, so the examples are now >> >> 1.19 round: 1. >> >> 1.19 roundTo: 0.1. >> >> (1.19 roundTo: (1/10))asFloat >> >> I should note that the final example *should* result in a Float without >> having to have #asFloat sent to it. Per ANSI and traditional Smalltalk >> practice, any operation where the receiver *or* the argument is a Float >> produces a Float. >> >> Since 0.1 is not quite equal to 1/10, the correct answer may not be the >> same for the latter two examples. Whether you define #round: to be one >> or the other is an interesting question. >> >> I've learned the hard way not to trust the results from Smalltalk math >> libraries too far, so let's manually figure out what the correct answer >> is for each of these, and see if Pharo's doing it right. >> >> To start, every Float (ignoring infinities, NaNs, and subnormals) is (by >> definition) a Fraction constrained to have a numerator in the range >> [2**52..2**53) and a denominator that is a power of two. >> >> Pharo says: >> 0.1 asFraction ==> (3602879701896397/36028797018963968) >> >> Is this correct? The numerator is less than 2**52, so this Fraction has >> been reduced. Let's restore it to what it would be in its Float form by >> multiplying numerator and denominator by, in this case, 2: >> >> 7205759403792794 >> ----------------- >> 72057594037927936 >> >> It's easy to see that this fraction is very nearly equal to 1/10, and to >> see that there could be no Float closer to 1/10. >> >> --- >> >> But I haven't shown the conversion from the string '0.1' to the actual >> Float instance is correct. It's possible that there's some rounding >> error there, which is reversed by a rounding in a different direction by >> the #asFraction. >> >> The Float for '0.1' is two words with values, 1069128089 and 2576980378. >> Convert to hex and combine them, you get 16r3FB999999999999A >> >> The numerator of our fraction is the low-order 52 bits of this, with a 1 >> added on the most-significant end, so 16r1999999999999A, which in >> decimal is 7205759403792794. Which is what we got above, so we're good >> so far. >> >> ======== >> >> Doing the same analysis on 1.19 gives a numerator of 16r130A3D70A3D70A, >> and a denominator 1/16th the previous one, or >> >> 5359283556570890 >> ---------------- >> 4503599627370496 >> >> This one's harder, I can't just look at it and say it's the closest >> possible to 1.19. >> >> But we know that 1.19 = 119/100. >> >> 119/100 * 4503599627370496/4503599627370496 = >> >> 535928355657089024 >> ------------------ >> 450359962737049600 >> >> and is still exactly 1.19. But to make a representable Float we have to >> divide numerator and denominator by 100, rounding the numerator if >> necessary. And we can see that the numerator is correctly rounded, so >> Pharo also converts the string '1.19' into a Float correctly. >> >> How does Pharo do on >> 1.19 asFraction? >> >> (2679641778285445/2251799813685248) >> >> Once again, this has been reduced by dividing numerator and denominator >> by two, but it's numerically correct. >> >> ====== >> >> Now that we know that we have the correct Fractions for the floats, we >> can check the rounding functions. >> >> 1.19 roundTo: 0.1 >> should ideally be equivalent to >> (1.19 asFraction roundTo: 0.1 asFraction) asFloat. >> >> In Pharo 5, >> 1.19 asFraction roundTo: 0.1 asFraction ==> >> (10808639105689191/9007199254740992) >> >> For this to correct, (10808639105689191/9007199254740992) must be a >> multiple of (3602879701896397/36028797018963968), since that's 0.1 >> asFraction. >> >> Is it a multiple? We can align the denominators by multiplying >> (10808639105689191/9007199254740992) by 4/4, and we get >> >> 43234556422756764 >> ----------------- >> 36028797018963968 >> >> which would be a multiple of >> >> 3602879701896397 >> ----------------- >> 36028797018963968 >> >> iff 43234556422756764 is a multiple of 3602879701896397. Looking at the >> original problem (1.19 roundTo: 0.1) we'd expect the multiple to be 12. >> >> Sure enough, 3602879701896397 * 12 ==> 43234556422756764. So we're >> correct so far. >> >> Now we have to convert our answer to the nearest representable Float. >> >> Our denominator is already a power of two, but our numerator is out of >> range -- it's too large. >> >> It's even, so we can cut it in half, getting >> >> 21617278211378382 >> >> Still too large, still even. Cut it in half again: >> >> 10808639105689191 >> >> Just a bit too large. Cut it in half again: >> >> 5404319552844595.5 >> >> Now it's in range [2**52..2**53) but it's not an integer, so we must >> round. Our number is exactly halfway between two representable numbers, >> so by IEEE754 we round to the even one, which is >> >> 5404319552844596 >> >> The Float we get back from >> >> 1.19 roundTo: 0.1 >> >> is 16r3FF3333333333334 >> >> and the numerator part of that is 16r13333333333334, or >> >> 5404319552844596 >> >> Which agrees with what we computed before. So this *is* the correct >> Float result. And it prints as 1.2000000000000002. >> >> This print string implies that there is a Float nearer to 1.2 than this. >> >> 1.2 is represented as 16r3FF3333333333333, so one representable Float >> less than the result of the #roundTo:. But, as we've shown, >> 1.2000000000000002 is *correct*. (Which was not what I expected when >> started this -- I suspected there might be rounding error in the >> computation of #roundTo:. But for this example, there isn't). >> >> I haven't done the full analysis of it, but I expect that >> (1.19 roundTo: (1/10))asFloat gives the Float with representation >> 16r3FF3333333333333 because it's rounding to a multiple of exactly 0.1, >> not the Float nearest to 0.1. >> >> Regards, >> >> -Martin >> >> > > >

Nov. 1, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Martin, thanks for this analysis, i really appreciate it. you did proof that, as you said "1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1.". please excuse me - i seriously think it was very friendly of you to do this detailed analysis -, but my argument never was, that if i use Float>roundTo: this produces problematic floating-point-errors. if it produces floating-point-errors they wouldnt be unexpected. i thought this would be clear from my previous posts. what i tried to say is, that i am a simple user and pharo shouldnt expect from me, that i know, that if i want a result looking a bit more like 1.2, i should use "(x asFraction roundTo:(1/10))asFloat" instead of "x roundTo:0.1". the #round: method circumvents the irritating part of Float calcs imo in an inexpensive way, and rounding numbers is imo not a very exotic task, but to presume that i figure out (x asFraction roundTo:(1/10))asFloat by myself is simply expecting too much from me. otoh now i that i know how to do it, it's not a problem for me, if the majority wants to deprecate #roundTo:. Thank you again for the careful analysis werner On 10/31/2016 09:58 PM, Martin McClure wrote: > tl;dr: > > 1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1. > (1.19 roundTo: (1/10))asFloat gives a different answer because it's > rounding to a multiple of exactly 0.1, not the Float nearest to 0.1. > > > On 10/31/2016 08:35 AM, test wrote: >> oops, make that original number 1.19 in the example. > OK, so the examples are now > > 1.19 round: 1. > > 1.19 roundTo: 0.1. > > (1.19 roundTo: (1/10))asFloat > > I should note that the final example *should* result in a Float without > having to have #asFloat sent to it. Per ANSI and traditional Smalltalk > practice, any operation where the receiver *or* the argument is a Float > produces a Float. > > Since 0.1 is not quite equal to 1/10, the correct answer may not be the > same for the latter two examples. Whether you define #round: to be one > or the other is an interesting question. > > I've learned the hard way not to trust the results from Smalltalk math > libraries too far, so let's manually figure out what the correct answer > is for each of these, and see if Pharo's doing it right. > > To start, every Float (ignoring infinities, NaNs, and subnormals) is (by > definition) a Fraction constrained to have a numerator in the range > [2**52..2**53) and a denominator that is a power of two. > > Pharo says: > 0.1 asFraction ==> (3602879701896397/36028797018963968) > > Is this correct? The numerator is less than 2**52, so this Fraction has > been reduced. Let's restore it to what it would be in its Float form by > multiplying numerator and denominator by, in this case, 2: > > 7205759403792794 > ----------------- > 72057594037927936 > > It's easy to see that this fraction is very nearly equal to 1/10, and to > see that there could be no Float closer to 1/10. > > --- > > But I haven't shown the conversion from the string '0.1' to the actual > Float instance is correct. It's possible that there's some rounding > error there, which is reversed by a rounding in a different direction by > the #asFraction. > > The Float for '0.1' is two words with values, 1069128089 and 2576980378. > Convert to hex and combine them, you get 16r3FB999999999999A > > The numerator of our fraction is the low-order 52 bits of this, with a 1 > added on the most-significant end, so 16r1999999999999A, which in > decimal is 7205759403792794. Which is what we got above, so we're good > so far. > > ======== > > Doing the same analysis on 1.19 gives a numerator of 16r130A3D70A3D70A, > and a denominator 1/16th the previous one, or > > 5359283556570890 > ---------------- > 4503599627370496 > > This one's harder, I can't just look at it and say it's the closest > possible to 1.19. > > But we know that 1.19 = 119/100. > > 119/100 * 4503599627370496/4503599627370496 = > > 535928355657089024 > ------------------ > 450359962737049600 > > and is still exactly 1.19. But to make a representable Float we have to > divide numerator and denominator by 100, rounding the numerator if > necessary. And we can see that the numerator is correctly rounded, so > Pharo also converts the string '1.19' into a Float correctly. > > How does Pharo do on > 1.19 asFraction? > > (2679641778285445/2251799813685248) > > Once again, this has been reduced by dividing numerator and denominator > by two, but it's numerically correct. > > ====== > > Now that we know that we have the correct Fractions for the floats, we > can check the rounding functions. > > 1.19 roundTo: 0.1 > should ideally be equivalent to > (1.19 asFraction roundTo: 0.1 asFraction) asFloat. > > In Pharo 5, > 1.19 asFraction roundTo: 0.1 asFraction ==> > (10808639105689191/9007199254740992) > > For this to correct, (10808639105689191/9007199254740992) must be a > multiple of (3602879701896397/36028797018963968), since that's 0.1 > asFraction. > > Is it a multiple? We can align the denominators by multiplying > (10808639105689191/9007199254740992) by 4/4, and we get > > 43234556422756764 > ----------------- > 36028797018963968 > > which would be a multiple of > > 3602879701896397 > ----------------- > 36028797018963968 > > iff 43234556422756764 is a multiple of 3602879701896397. Looking at the > original problem (1.19 roundTo: 0.1) we'd expect the multiple to be 12. > > Sure enough, 3602879701896397 * 12 ==> 43234556422756764. So we're > correct so far. > > Now we have to convert our answer to the nearest representable Float. > > Our denominator is already a power of two, but our numerator is out of > range -- it's too large. > > It's even, so we can cut it in half, getting > > 21617278211378382 > > Still too large, still even. Cut it in half again: > > 10808639105689191 > > Just a bit too large. Cut it in half again: > > 5404319552844595.5 > > Now it's in range [2**52..2**53) but it's not an integer, so we must > round. Our number is exactly halfway between two representable numbers, > so by IEEE754 we round to the even one, which is > > 5404319552844596 > > The Float we get back from > > 1.19 roundTo: 0.1 > > is 16r3FF3333333333334 > > and the numerator part of that is 16r13333333333334, or > > 5404319552844596 > > Which agrees with what we computed before. So this *is* the correct > Float result. And it prints as 1.2000000000000002. > > This print string implies that there is a Float nearer to 1.2 than this. > > 1.2 is represented as 16r3FF3333333333333, so one representable Float > less than the result of the #roundTo:. But, as we've shown, > 1.2000000000000002 is *correct*. (Which was not what I expected when > started this -- I suspected there might be rounding error in the > computation of #roundTo:. But for this example, there isn't). > > I haven't done the full analysis of it, but I expect that > (1.19 roundTo: (1/10))asFloat gives the Float with representation > 16r3FF3333333333333 because it's rounding to a multiple of exactly 0.1, > not the Float nearest to 0.1. > > Regards, > > -Martin > >

Nov. 1, 2016

Re: [Pharo-dev] Image Distributions [was:Re: Mocks are missing in Pharo (from thread OSProcess is missing)}

by stepharo

Le 29/10/16 Ã 08:39, phil(a)highoctane.be a Ã©crit : > Having them in image can indeed be useful. > > I am testing against REST backends, and well, this is a destructive > test to say the least. Not easy to replay as much as I want. > > I hope that with the Bootstrap we'll be able to have a set of > "Batteries Included" distributions. Kind of like we have Moose today, > which I like very much as I do not have to load parts from all over > the place. Yes we will now people will be able to also define their own image. At the end bootstrap + configura + jenkins = an image > > On http://tcl.tk there are also a number of such distributions: > > * the "Batteries Included" ActiveTcl > (http://www.activestate.com/activetcl) with its various support levels > [which would be good to emulate for the Pharo Pro business proposition] > > * TclKit / StarKits concept (http://wiki.tcl.tk/52) TclKit is a > BaseKit. See http://wiki.tcl.tk/15985 for a table of kits and their > supported features. > > * Build your own from sources. > > TclKit allows one to build special kit, using a command line tool, > similar to what we discuss for loading packages easily. > http://wiki.tcl.tk/10558 > > We do have an image and the TclKit has a VFS (Virtual File System) > bundling everything in a single file. > > So, basically, one runs things with tclkit hello.kit. Quite > reminiscent of pharo Pharo.image I'd say. > > Question 1: > > Which top 5 packages/configurations would you find useful to have > available in a distribution? > > 1- > 2- > 3- > 4- > 5- > > Question 2: > > What do you consider to be the top 3 use cases of a Pharo Distribution > for your own use? > > 1- > 2- > 3- > > Best, > Phil > > > > ` > > > > > > > > On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov > <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > > 2016-10-28 18:58 GMT+02:00 Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > > No, please, kernel test should have the fewer dependencies as > possible! > > I would say this dependency is needed. > > And again i'll hold my position: whoever wants to load it can > do it. There is no need to put it there by default. > > Do you know how much easier it would be to design and test > FileSystem with mocks. Code and tests will be much better and > simpler from the beginning. > And I could said it about any package which provide abstractions. > > Now no project which is part of Pharo can use mocks for tests. So > it is not question of loading it for own project. Pharo > contributors can't use mocks. > > And there is another story. Imaging Ruby guys join Pharo > development (not real story :)). Many years In Ruby people use > mocks and "human should" assertions. Most TDD evolution was from > Ruby. I imaging their impression about Pharo "the best for TDD". > > And generally I would said we have quite bad tests in system. They > are slow, they corrupt image. Mocks will help to improve this > situation. > >

Nov. 1, 2016

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Attila Magyar

Denis Kudriashov wrote > BabyMock could not be treated as modern mock library just because it uses > symbols instead of normal message sends. Even C# and Java mocks are based > on normal messages. Because they don't have symbols :). Ruby libraries often use symbols, last time I checked rspec mocks used it too. I think this is a matter of taste, it's not about being modern or not. I like thinking about mock objects as tools for describing inter-object protocols (the visualisation tries to emphasize this aspect). The communication protocol between the object under test and its peers (mocks) is expressed in a descriptive language (this language can be changed in BabyMock quite easily). A narrator object (this is called Protocol in BabyMock2) speaks in the third person to describe the message exchange between the object cluster. I don't like when expectations are set up in mocks directly any more, neither the should/should have notation. The GOOS book was a big influence on me at that time. -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 1, 2016