- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] roundTo: strange behavior

by stepharo

Le 29/10/16 Ã 17:01, test a Ã©crit : > On 10/27/2016 11:13 AM, Nicolas Cellier wrote: >> >> feel free to improve the slice. >> > Hi, > i never made a slice and thought <stupid grin>, i could eventually try > to do that in this case, but of course i did not succeed: > 1. Nicolas, i do not understand, why you put asScaledDecimal: > numberOfWishedDecimal at the end of Fraction>>round:. what would not > work, if one simply omitted that? > 2. when i make a slice i find no possibility to save it to my pc, to > check whether i made things correctly and there is no changes-button > in the monticello-browser to look at the diff that slice would make. > of course the seasoned programmer has no problems with that, but a > simple user like me? > 3. this line: "< expr: '(1/3 round: 2)' result: (33/100) >" is not > accepted by the browser. i have no idea how to call this example to > debug it, perhaps (33/100) is not accepted as a result because > Fractions are no literals? and then what? > This is an experience that we should remove "< expr: '(1/3 round: 2)' result: (33/100) >" -> "(1/3 round: 2)' -> (33/100)" > werner > > p.s. regarding your slice, Nicolas, FractionTest>>testRounding needs > also to be changed. >

Oct. 30, 2016

Re: [Pharo-dev] roundTo: strange behavior

by stepharo

Hi werner to load a slice: - select it and press load. to create a slice - + slice - then select the package that will compose the slice - save the slice in the inbox Can you retry and let me know what did not work? Stef Le 29/10/16 Ã 17:01, test a Ã©crit : > On 10/27/2016 11:13 AM, Nicolas Cellier wrote: >> >> feel free to improve the slice. >> > Hi, > i never made a slice and thought <stupid grin>, i could eventually try > to do that in this case, but of course i did not succeed: > 1. Nicolas, i do not understand, why you put asScaledDecimal: > numberOfWishedDecimal at the end of Fraction>>round:. what would not > work, if one simply omitted that? > 2. when i make a slice i find no possibility to save it to my pc, to > check whether i made things correctly and there is no changes-button > in the monticello-browser to look at the diff that slice would make. > of course the seasoned programmer has no problems with that, but a > simple user like me? > 3. this line: "< expr: '(1/3 round: 2)' result: (33/100) >" is not > accepted by the browser. i have no idea how to call this example to > debug it, perhaps (33/100) is not accepted as a result because > Fractions are no literals? and then what? > werner > > p.s. regarding your slice, Nicolas, FractionTest>>testRounding needs > also to be changed. >

Oct. 30, 2016

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

by stepharo

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

Oct. 30, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Ben Coman

On Sat, Oct 29, 2016 at 11:01 PM, test <wkassens(a)libello.com> wrote: > 2. when i make a slice i find no possibility to save it to my pc, Save it to package-cache (Henrik's snapshot), then later <Copy> it from package-cache to Pharo6Inbox. Note that <Copy> doesn't automatically request your password for Pharo6Inbox like when you <Save> direct to it. You will need to edit its repository definition to add manually add your account & password. > to check > whether i made things correctly and there is no changes-button in the > monticello-browser to look at the diff that slice would make. I find the preview provided by the <Merge> button more often gives me what I want to review my Slices in a fresh Image. cheers -ben

Oct. 30, 2016

Re: [Pharo-dev] Odd literal in metaclasses methods

by Nicolas Cellier

Because CompiledMethod>>methodClass expects a classical literal binding className->class methodClass "answer the class that I am installed in" ^(self literalAt: self numLiterals) value. But there ain't no binding for the metaclass which is accessible only indirectly thru the class (you write Object class, not ObjectClass). So it is a kind of hack to unify class and metaclass behavior... Note that the hack is necessary and used by the VM for resolving super send, so think twice if you want to come with a better hack, it's possible but also and advanced topic. 2016-10-29 18:23 GMT+02:00 Henrik Nergaard <henrik.nergaard(a)uia.no>: > Every method implemented in the class side includes a literal: > ânil->theMetaClassâ. > Object class methods collect: [ :cm | cm literals last ]. > > What is it used for? > > Best regards, > Henrik > >

Oct. 29, 2016