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

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

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

by Tudor Girba

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] GTInspector table hides columns

by Tudor Girba

Hi, Sorry for the late reply on this. I added horizontal scroll bar to the morphtreemorph-based presentations. Cheers, Doru > On Jul 5, 2016, at 1:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > apparently inspector is happy to hide columns if they don't fit. Why is there no vertical scrollbar? > > <inspector-table-1.png> > <inspector-table-2.png> > â > Also (I know I brought up this in the past, but the problem still remains), why does "Description" takes up so much space even though there's no data at all? Why not cap it at the width of the heading? > > Thanks, > Peter -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Oct. 30, 2016

Re: [Pharo-dev] roundTo: strange behavior

by stepharo

I'm favor to deprecate round: too. Thanks you all for your analysis. I will reread the thread carefully to learn. Stef Le 27/10/16 Ã 18:12, Martin McClure a Ã©crit : > On 10/27/2016 04:12 AM, test wrote: >> i would prefer if #round: will not be deprecated in Floats. in some >> cases Float>>#round: can be useful, eg optimization problems where >> one searched value describes the size of a screw, that exists only in >> certain sizes. > > #roundTo: can be used for this (and is specified by ANSI Smalltalk, > for those who care). If the screws only come in 16th inch increments, > for instance, then "roundTo: 0.0625" will give you an exact result, > since 16ths *are* exactly representable as floats. > > OTOH, #round: (not in ANSI) appears to promise something that cannot > be delivered for Floats, so is misleading, and it spreads the kind of > confusion that resulted in this thread. > > That's why I favor deprecating #round: for Floats. > > Regards, > > -Martin >

Oct. 30, 2016