- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 4536dc: 60272

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4536dc3e395029e3048320ccb034c2e201acd22d https://github.com/pharo-project/pharo-core/commit/4536dc3e395029e3048320cc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-10-31 (Mon, 31 Oct 2016) Changed paths: M ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/symbolic versions/stable_.st A ConfigurationOfTxText.package/ConfigurationOfTxText.class/instance/versions/version213_.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/running/setUp.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/tests/testCriticsOf.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/tests/testIsFalsePositive.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/tests/testIsToDo.st M Manifest-Tests.package/SmalllintManifestCheckerTest.class/instance/tests/testToDoOf.st M Nautilus.package/MethodIsExampleAction.class/instance/order/isActionHandled.st M Rubric.package/RubScrolledTextExtra.class/instance/accessing/paragraphProvider.st R Rubric.package/RubScrolledTextMorph.class/instance/testing/isParagraphProvider.st R Rubric.package/extension/Object/instance/isParagraphProvider.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60271.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60272.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60271.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60272.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot-Tests.package/ClassVariableTest.class/instance/tests - properties/testIsReadInMethod.st A Slot-Tests.package/ClassVariableTest.class/instance/tests - properties/testIsWrittenInMethod.st A Slot-Tests.package/ClassVariableTest.class/instance/tests - properties/testNotReadInMethod.st A Slot-Tests.package/ClassVariableTest.class/instance/tests - properties/testNotWrittenInMethodWhenItIsOnlyRead.st A Slot-Tests.package/GlobalVariableTest.class/instance/tests - properties/testIsReadInMethod.st A Slot-Tests.package/GlobalVariableTest.class/instance/tests - properties/testNotWrittenInMethod.st A Slot-Tests.package/SlotTest.class/instance/testing - properties/testIsReadInMethod.st A Slot-Tests.package/SlotTest.class/instance/testing - properties/testIsWrittenInMethod.st A Slot-Tests.package/SlotTest.class/instance/testing - properties/testNotReadInMethod.st A Slot-Tests.package/SlotTest.class/instance/testing - properties/testNotWrittenInMethodWhenItIsOnlyRead.st R Slot.package/IndexedSlot.class/instance/meta-object-protocol/isVirtual.st A Slot.package/IndexedSlot.class/instance/testing/isVirtual.st A Slot.package/InstanceVariableSlot.class/instance/testing/isReadIn_.st A Slot.package/InstanceVariableSlot.class/instance/testing/isWrittenIn_.st A Slot.package/LiteralVariable.class/instance/testing/isReadIn_.st A Slot.package/LiteralVariable.class/instance/testing/isWrittenIn_.st A Slot.package/Slot.class/instance/testing/isReadIn_.st A Slot.package/Slot.class/instance/testing/isWrittenIn_.st R TxText-AthensTests.package/TxAthensRenderingTest.class/README.md R TxText-AthensTests.package/TxAthensRenderingTest.class/class/as yet unclassified/newText.st R TxText-AthensTests.package/TxAthensRenderingTest.class/class/as yet unclassified/test.st R TxText-AthensTests.package/TxAthensRenderingTest.class/definition.st R TxText-AthensTests.package/TxTextPositionToViewCoordinatesTest.class/README.md R TxText-AthensTests.package/TxTextPositionToViewCoordinatesTest.class/definition.st Log Message: ----------- 60272 19255 Update TxText https://pharo.fogbugz.com/f/cases/19255 19258 Remove isParagraphProvider https://pharo.fogbugz.com/f/cases/19258 19084 SmalllintManifestCheckerTest: failing tests https://pharo.fogbugz.com/f/cases/19084 19253 Methods to check is variable, global or slot is read or modified in given CompiledCode https://pharo.fogbugz.com/f/cases/19253 19261 Enable <example> methods to be executed https://pharo.fogbugz.com/f/cases/19261 http://files.pharo.org/image/60/60272.zip

Oct. 31, 2016

Re: [Pharo-dev] Epicea user experience report

by Martin Dias

Hello Ben, About discussion points in 2 (a, b and c): I agree with your arguments... somebody that just moved from Pharo 5 to 6 and crashed an image will look for a "Recover lost changes" in the menu and can have a problem to discover it the replacement in a World->Tools->Epicea->... entry. Then, as a first step we could flatten the 2 menu entries and then at least anybody will easily find an entry related to changes in World->Tools. Second, we could try to merge both Epicea GUIs into one (suggestions are welcome). I still have to read more in detail the remaining of your report to answer. Anyway, thanks a lot for it. Cheers, Martin On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman <btc(a)openinworld.com> wrote: > 1. Created fresh Pharo image (build 60269) > > > 2. Opened World > Tools > Epicea > All changes > > Points for discussion... > > a. How many submenu items are expected for Epicea? Can we push the > current ones up so the Tools menu remains a flat menu. > > b. Do we need the two current menu items? "Current session" is > encompassed by "All changes"? What expectations do people have of how > often they'll use the former rather than the latter? > > c. When people move from Pharo 5 to Pharo 6 and in a panic want to > "recover changes" for a crashed image, they'll be looking for that > familiar feature name, not a new app name. Could the app name be left > out or placed in brackets "Changes (Epicea)". > > btw, the interface looks really slick! nice work. > > > 3. Opened World > System Browser. > > 4. Added package AAA > All Changes window - no dynamic change. > On <refresh>, still no change, i.e. no sessions > #New All Changes window - not visible, no sessions. > > 5. Added class AA. > All Changes window - no dynamic change. > On <refresh>, shows new session with AAA & AA. > > 5. Added method... > AA>a > ^'something' > Prompted for author, entered 'BenComan' > All Changes window with session selected - dynamic update showing AA>>a. > > 6. Added package BBB. > All Changes window - no dynamic update. > On <refresh>, BBB still not visible in session. > > 7. Added class A to package AAA. > All Changes window - dynamic update showing A. > On <refresh>, BBB still not visible in session. > > 8. Added class BB to package BBB. > All Changes window - dynamic update showing BBB & BB. > > a. Package creation event seems not handled properly, being only > pushed through when a class is created in it. > > b. Since there is a dynamic update for class and method > modifications, could the session creation also dynamically update it > UI. > > ----------- > 9. Killed the vm from command line > $ ps -ef | grep pharo > $ kill 29349 > Restarted Pharo image > > 10. World > Tools > Epica > All changes. > Authorship is inconsistent: > * AAA and AA have blank author > * AA>>a, A, BBB, B have author 'BenComan'. > > a. I understand this follows on from Author not being requested until > the first method was defined. Did the old changes track the author of > packages and classes at all? > > b. Since Epicea can track package and class authors, can we trigger > the author prompt earlier for them? > > 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB > and did <Apply Changes>. > Prompted for author. Entered 'DrWho' > Existing All Changes window - no change > New All Changes window - shows new session with all six changes. > Authorship is a little inconsistent: > * AAA and AA have author 'Unknown'. > * AA>>a, A, BBB, B have blank author. > > 12. Killed the vm from command line > $ ps -ef | grep pharo > $ kill 30696 > Restarted Pharo image > > 13. World > Tools > Epica > All changes. > Authorship is a little inconsistent: > First session > * AAA and AA have blank author > * AA>>a, A, BBB, B have author 'BenComan'. > Second session > * AAA and AA have blank author > * AA>>a, A, BBB, B have author 'DrWho'. > > a. Epicea changes are reapplied as the current author. This seems a > semantic change from Pharo 5 where changes were reapplied as their > original author. Is this accidental or by design? Can we have some > community discussion on this point (I don't remember seeing any)? > > cheers -ben > > P.S. I'll wait to see what arises out of discussion before creating any > issues. > >

Oct. 31, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

or perhaps it worked now, i think i uploaded SLICE-Issue-15471-Cant-round-Float-fmax-to-2-decimal-places-WernerKassens.1 <http://www.smalltalkhub.com/#%21/%7EPharo/Pharo60Inbox/versions/SLICE-Issue…> werner

Oct. 30, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

On 10/30/2016 09:45 AM, stepharo wrote: > > I'm favor to deprecate round: too. > > Thanks you all for your analysis. I will reread the thread carefully > to learn. > Hi Stephane, just to sum up my arguments: 1. Floats & Fractions represent almost the same thing, hence they should have the same API! iow if Float>>round: is deprecated it should imo also be deprecated in Fractions. and i dont see what is gained by generally deprecating every #round: (eg i like to use it). if it is because you want to have a small image, i'd guess, one could put ScaledDecimal in its own package (as long as there are no dependencies of numbers on it introduced) and have an image without that. the memory gain would be bigger & imo the usability loss smaller. 2. most decimals are not representable as Floats. Ok, so what? pi is not representable too, you dont deprecate Float>>pi because of that, right? werner

Oct. 30, 2016

Re: [Pharo-dev] roundTo: strange behavior

by test

Hi Ben, this explanation helped me most, because i <big grin> realized that i need an account with a password, which i dont have. so things have resolved themselves. thanks werner

Oct. 30, 2016

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

by Norbert Hartl

The context might be right. Still Denis is talking about integrating Mocks in SUnit. And to have kernel tests using Mocks. I don't see a problem because can be loaded later. I see no reason if there is a small kernel why it cannot load additional stuff just for testing. The kernel would still be small. If things packaged the right way tests can be loaded in multiple feature layers. The not yet to discuss thing is indeed what will be the default distribution of pharo. Norbert > Am 30.10.2016 um 11:41 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > I actually think there is no disagreement in this discussion :). I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that: > - Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks. > - Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely. > > From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features. However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside. > > @Guille, Stef: Does this reflect what you think? > @Denis: Is this reasonable for you? > > Cheers, > Doru > > > >> On Oct 30, 2016, at 9:33 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Denis >> >> We are working since 4 years now to get >> >> - have a small kernel + tests >> >> - be able to load nicely configurations >> >> We should not add something else than Sunit for tests of the small kernels tests. >> >> Now people can use whatever they want to test their system but for the core >> >> we are really picky because loading on single package may add far too many dependencies. >> >> and it means >> >> - more time to load >> >> - more time to debug >> >> - more time to just understand what did not work during the bootstrap. >> >> So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them. >> >> I agree with Guillermo. Far too much pain. >> >> Stef >> >>> Le 28/10/16 Ã 18:51, Denis Kudriashov a Ã©crit : >>> We always said that smalltalk is the best for TDD. >>> But we not have mocks by default in Pharo while mocks is fundamental part of TDD. >>> So no kernel tests could benefit from them. >>> And more important TDD is design process and without mocks we can't apply it to kernel with full power. >>> What you think to integrate Mocketry in Pharo 6? >>> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries. >>> >>> Best regards, >>> Denis >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > >

Oct. 30, 2016

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

by Nicolai Hess

2016-10-30 12:00 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Oct 30, 2016, at 11:55 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > 2016-10-30 11:52 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > > > 2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > I actually think there is no disagreement in this discussion :). > > > > I am not sure about that. > > > > > > I see it similarly to how Dale described it, but perhaps I am wrong. It > seems to me that: > > - Guille and Stef are talking about Core, they refer to the smallest > image that can be useful for a developer and that is being built out of the > tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem > does belong in this image, we should not make FileSystem testing depend on > Mocks. > > - Denis is talking about the typical distribution that we now name the > Pharo image. Mocks might actually belong in this one quite nicely. > > > > > > Denis wants to have a Mock-Framework to be used for SUnit, and if we > have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework > has to be in it too, no ? > > > > From a practical point of view, it is not a good option to add new > things for Pharo 6. We have decided that Pharo 6 is closed for new features. > > > > Feature freeze? Really, since when? > > > > Does it means any changes (I am working on) for keymapping and style > settings has to be moved to Pharo 7? > > > > There was an email sent by Esteban recently in the thread: > Notes about Pharo 6 release and new process for Pharo 7 > Oh, I thought it was only about a "VM feature freeze", for having a stable version to work towards 64 bits VM. That is unfortunate, I have some other things I am working on and thought I would have time until february, as in the prior relaese cycles. > > I think that things like your work on keymapping should still make it in > this release. > > Cheers, > Doru > > > > However, once we have the new process in place for Pharo 7, we can > reconsider our options. The new process should precisely make it easier and > safer to play with new things for the official distribution that has > several convenience libraries inside. > > > > @Guille, Stef: Does this reflect what you think? > > @Denis: Is this reasonable for you? > > > > Cheers, > > Doru > > > > > > > > > On Oct 30, 2016, at 9:33 AM, stepharo <stepharo(a)free.fr> wrote: > > > > > > Denis > > > > > > We are working since 4 years now to get > > > > > > - have a small kernel + tests > > > > > > - be able to load nicely configurations > > > > > > We should not add something else than Sunit for tests of the small > kernels tests. > > > > > > Now people can use whatever they want to test their system but for the > core > > > > > > we are really picky because loading on single package may add far too > many dependencies. > > > > > > and it means > > > > > > - more time to load > > > > > > - more time to debug > > > > > > - more time to just understand what did not work during the > bootstrap. > > > > > > So our goal is to shrink the minimal core and not to extend it. So we > will add mock by hand if we need them. > > > > > > I agree with Guillermo. Far too much pain. > > > > > > Stef > > > > > > Le 28/10/16 Ã 18:51, Denis Kudriashov a Ã©crit : > > >> We always said that smalltalk is the best for TDD. > > >> But we not have mocks by default in Pharo while mocks is fundamental > part of TDD. > > >> So no kernel tests could benefit from them. > > >> And more important TDD is design process and without mocks we can't > apply it to kernel with full power. > > >> What you think to integrate Mocketry in Pharo 6? > > >> It has comments and documentation (PharoInProgress, Help), advanced > features and it is very competitive to any modern mock libraries. > > >> > > >> Best regards, > > >> Denis > > > > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Value is always contextual." > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > >

Oct. 30, 2016

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

by Tudor Girba

Hi, > On Oct 30, 2016, at 11:55 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-10-30 11:52 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I actually think there is no disagreement in this discussion :). > > I am not sure about that. > > > I see it similarly to how Dale described it, but perhaps I am wrong. It seems to me that: > - Guille and Stef are talking about Core, they refer to the smallest image that can be useful for a developer and that is being built out of the tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does belong in this image, we should not make FileSystem testing depend on Mocks. > - Denis is talking about the typical distribution that we now name the Pharo image. Mocks might actually belong in this one quite nicely. > > > Denis wants to have a Mock-Framework to be used for SUnit, and if we have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to be in it too, no ? > > From a practical point of view, it is not a good option to add new things for Pharo 6. We have decided that Pharo 6 is closed for new features. > > Feature freeze? Really, since when? > > Does it means any changes (I am working on) for keymapping and style settings has to be moved to Pharo 7? > There was an email sent by Esteban recently in the thread: Notes about Pharo 6 release and new process for Pharo 7 I think that things like your work on keymapping should still make it in this release. Cheers, Doru > However, once we have the new process in place for Pharo 7, we can reconsider our options. The new process should precisely make it easier and safer to play with new things for the official distribution that has several convenience libraries inside. > > @Guille, Stef: Does this reflect what you think? > @Denis: Is this reasonable for you? > > Cheers, > Doru > > > > > On Oct 30, 2016, at 9:33 AM, stepharo <stepharo(a)free.fr> wrote: > > > > Denis > > > > We are working since 4 years now to get > > > > - have a small kernel + tests > > > > - be able to load nicely configurations > > > > We should not add something else than Sunit for tests of the small kernels tests. > > > > Now people can use whatever they want to test their system but for the core > > > > we are really picky because loading on single package may add far too many dependencies. > > > > and it means > > > > - more time to load > > > > - more time to debug > > > > - more time to just understand what did not work during the bootstrap. > > > > So our goal is to shrink the minimal core and not to extend it. So we will add mock by hand if we need them. > > > > I agree with Guillermo. Far too much pain. > > > > Stef > > > > Le 28/10/16 Ã 18:51, Denis Kudriashov a Ã©crit : > >> We always said that smalltalk is the best for TDD. > >> But we not have mocks by default in Pharo while mocks is fundamental part of TDD. > >> So no kernel tests could benefit from them. > >> And more important TDD is design process and without mocks we can't apply it to kernel with full power. > >> What you think to integrate Mocketry in Pharo 6? > >> It has comments and documentation (PharoInProgress, Help), advanced features and it is very competitive to any modern mock libraries. > >> > >> Best regards, > >> Denis > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

Oct. 30, 2016

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

by Nicolai Hess

2016-10-30 11:52 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> I actually think there is no disagreement in this discussion :). > > > I am not sure about that. > > > >> I see it similarly to how Dale described it, but perhaps I am wrong. It >> seems to me that: >> - Guille and Stef are talking about Core, they refer to the smallest >> image that can be useful for a developer and that is being built out of the >> tiny kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem >> does belong in this image, we should not make FileSystem testing depend on >> Mocks. >> - Denis is talking about the typical distribution that we now name the >> Pharo image. Mocks might actually belong in this one quite nicely. >> >> > Denis wants to have a Mock-Framework to be used for SUnit, and if we have > Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to > be in it too, no ? > > >> From a practical point of view, it is not a good option to add new things >> for Pharo 6. We have decided that Pharo 6 is closed for new features. > > > Feature freeze? Really, since when? > Does it means any changes (I am working on) for keymapping and style settings has to be moved to Pharo 7? > > > >> However, once we have the new process in place for Pharo 7, we can >> reconsider our options. The new process should precisely make it easier and >> safer to play with new things for the official distribution that has >> several convenience libraries inside. >> >> @Guille, Stef: Does this reflect what you think? >> @Denis: Is this reasonable for you? >> >> Cheers, >> Doru >> >> >> >> > On Oct 30, 2016, at 9:33 AM, stepharo <stepharo(a)free.fr> wrote: >> > >> > Denis >> > >> > We are working since 4 years now to get >> > >> > - have a small kernel + tests >> > >> > - be able to load nicely configurations >> > >> > We should not add something else than Sunit for tests of the small >> kernels tests. >> > >> > Now people can use whatever they want to test their system but for the >> core >> > >> > we are really picky because loading on single package may add far too >> many dependencies. >> > >> > and it means >> > >> > - more time to load >> > >> > - more time to debug >> > >> > - more time to just understand what did not work during the >> bootstrap. >> > >> > So our goal is to shrink the minimal core and not to extend it. So we >> will add mock by hand if we need them. >> > >> > I agree with Guillermo. Far too much pain. >> > >> > Stef >> > >> > Le 28/10/16 Ã 18:51, Denis Kudriashov a Ã©crit : >> >> We always said that smalltalk is the best for TDD. >> >> But we not have mocks by default in Pharo while mocks is fundamental >> part of TDD. >> >> So no kernel tests could benefit from them. >> >> And more important TDD is design process and without mocks we can't >> apply it to kernel with full power. >> >> What you think to integrate Mocketry in Pharo 6? >> >> It has comments and documentation (PharoInProgress, Help), advanced >> features and it is very competitive to any modern mock libraries. >> >> >> >> Best regards, >> >> Denis >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual." >> >> >> >> >> >> >

Oct. 30, 2016

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

by Nicolai Hess

2016-10-30 11:41 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I actually think there is no disagreement in this discussion :). I am not sure about that. > I see it similarly to how Dale described it, but perhaps I am wrong. It > seems to me that: > - Guille and Stef are talking about Core, they refer to the smallest image > that can be useful for a developer and that is being built out of the tiny > kernel. Indeed, Mocks do not belong there. Specifically, as FileSystem does > belong in this image, we should not make FileSystem testing depend on > Mocks. > - Denis is talking about the typical distribution that we now name the > Pharo image. Mocks might actually belong in this one quite nicely. > > Denis wants to have a Mock-Framework to be used for SUnit, and if we have Kernel and Kernel-Tests in the bootstrap image, the Mocks-Framework has to be in it too, no ? > From a practical point of view, it is not a good option to add new things > for Pharo 6. We have decided that Pharo 6 is closed for new features. Feature freeze? Really, since when? > However, once we have the new process in place for Pharo 7, we can > reconsider our options. The new process should precisely make it easier and > safer to play with new things for the official distribution that has > several convenience libraries inside. > > @Guille, Stef: Does this reflect what you think? > @Denis: Is this reasonable for you? > > Cheers, > Doru > > > > > On Oct 30, 2016, at 9:33 AM, stepharo <stepharo(a)free.fr> wrote: > > > > Denis > > > > We are working since 4 years now to get > > > > - have a small kernel + tests > > > > - be able to load nicely configurations > > > > We should not add something else than Sunit for tests of the small > kernels tests. > > > > Now people can use whatever they want to test their system but for the > core > > > > we are really picky because loading on single package may add far too > many dependencies. > > > > and it means > > > > - more time to load > > > > - more time to debug > > > > - more time to just understand what did not work during the bootstrap. > > > > So our goal is to shrink the minimal core and not to extend it. So we > will add mock by hand if we need them. > > > > I agree with Guillermo. Far too much pain. > > > > Stef > > > > Le 28/10/16 Ã 18:51, Denis Kudriashov a Ã©crit : > >> We always said that smalltalk is the best for TDD. > >> But we not have mocks by default in Pharo while mocks is fundamental > part of TDD. > >> So no kernel tests could benefit from them. > >> And more important TDD is design process and without mocks we can't > apply it to kernel with full power. > >> What you think to integrate Mocketry in Pharo 6? > >> It has comments and documentation (PharoInProgress, Help), advanced > features and it is very competitive to any modern mock libraries. > >> > >> Best regards, > >> Denis > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > > >

Oct. 30, 2016