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

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

by Dale Henrichs

It seems to me that there perhaps needs to be more clarity here ... I think there is perhaps a difference in between "kernel tests should have fewer depencies" and "mocks missing from Pharo". Is "Pharo" and "kernel" synonymous? I imagine that there is a minimal/minimum kernel image that has the kernel and nothing else ... but this kernel image has very little in it and may not even have bare bones development tools ... I also imagine that there is at least one "Pharo minimal" image (perhaps this is the "kernel" that Guille is referring to?) that is the minimum kernel plus the bare minimum of development tools installed ... no bells and whistles, or anything shiny ... this is the base image that developers would use when they want to build an image aimed at their specific needs ... and of course the image is the starting point for the "developer image" ... I also imagine that there is at least one "developer image" that is targeted at developers and this image will be billed as the "recommended developers image" and this image should come with the full suite of development tools and supporting projects to make life easy for most developers so that they don't have to customize their development environment from the get-go. I would think that maintaining the "developer image" would be not that much more complicated than maintaining the 100 or so Contributor builds --- it is built on top of the "Pharo minimal/kernel" image --- all the tests are run, which is the most important thing... Dale On 10/28/2016 11:36 AM, Denis Kudriashov 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.

Oct. 28, 2016

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

by Esteban A. Maringolo

2016-10-28 16:07 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: >> 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. > Ruby guys can load the library they prefer. And use it in their projects. > I'm no-one to forbid that, and actually I'd encourage it if that is what > they want. > > And actually this is what they do in Ruby: if they want a library they load > it. Why in Pharo it cannot be the same for god's sake?? +1 to this. We should be able to deliver a minimal core, with the basic features to load external packages. The problem, I suspect, is that project discoverability/installation might not be as straightforward as with a ruby gem, but the integrated catalog eases that in a big extent. Regards! -- Esteban.

Oct. 28, 2016

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

by Guillermo Polito

On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-10-28 18:58 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> No, please, kernel test should have the fewer dependencies as possible! >> > I would say this dependency is needed. > You're somehow neglecting how difficult it is to build and maintain the system as it is. Because if Kernel packages are tested using mocks it means that to be able to test the system we need to: - build bootstrap - load SUnit - load mocks - which will load probably a proxy framework - then, just then, we are able to load the tests Then to know if the system is in a good state, we have to make the assumption that (and I say make the assumption because we cannot test it yet at this stage) - sunit is ok - the mock library is ok - and all the mock library dependencies are ok It is too much for the kernel. > 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. > That is not true. People can create mocks by hand. They do not require a library for easing it. Maybe it is a bit more bureaucratic but it still works. Second, mocks are no silver bullet. they are alright to decouple and try to test some parts of the system in isolation, but then you still need integration tests to test how the different components add-up together. > > 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. > Ruby guys can load the library they prefer. And use it in their projects. I'm no-one to forbid that, and actually I'd encourage it if that is what they want. And actually this is what they do in Ruby: if they want a library they load it. Why in Pharo it cannot be the same for god's sake?? Most TDD evolution was from Ruby. I imaging their impression about Pharo > "the best for TDD". > TDD is not about mocks. TDD is not about tests. TDD is about a way to approach the design of an application. And what makes Pharo IMHO "the best for TDD" are not mocks but the debugger and how we can develop applications with it. > 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. > Yes, but that's not because we do not have mocks. That's because some part of the system are not designed to be tested (depend on global state), or because nobody cared of writing good tests. **I am 100% sure that people can write bad tests with any mock library that you want**

Oct. 28, 2016

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

by Denis Kudriashov

2016-10-28 18:58 GMT+02:00 Guillermo Polito <guillermopolito(a)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.

Oct. 28, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Richard Sargent

Dale Henrichs-3 wrote > Guillermo, > > Apparently you don't like the github browser-based code review tool? > > What are your objections? > > Do you know of a better tool that is out in the wild or do you just have > visions that code review could be better? Let me add some thoughts on review tools, not as an argument against anything in this thread, but more like nostalgia for what I have used in the past and would like to see again. What I describe was specifically oriented toward 1:1 peer reviews and self reviews. VA Smalltalk has a difference browser which has the usual browser top panes (in the case of VA, showing Application, Class, and Method lists) and side-by-side bottom panes showing the two versions of the code for the selection in the top panes. It also has a button that allows you to step through the changes, highlighting each successive difference. (It also has substantial room for improvements!) The things I like about it are: - it's live in my image, so all the usual things one can do with Smalltalk are possible - I can easily review other versions of the artefacts - I can jump around to follow related artefacts (e.g., look at a changed method called from the current one or vice versa) - I can *remove artefacts from the lists* as I finish with them so that my browser works as a structured check list and as I eliminate things I can can see what remains and eventually empty the lists, signifying completion - I can modify the changes to correct problems with them and then publish an updated change (or in Git terms a new commit) So, these are some of the characteristics I would like to find in a review tool. > Better tools are always possible, but it is sometimes nice to use a tool > that you didn't have to build from scratch while creating the better > tool:) > > Dale > > On 10/27/2016 05:06 AM, Guillermo Polito wrote: >> I would like to have a good code review tool, before having to do one >> ad-hoc... >> >> On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov >> < > dionisiydk@ > <mailto: > dionisiydk@ > >> wrote: >> >> Hi. >> >> With future transition to github I ask myself what tools we will >> have out of the box. >> I google a bit and found these nice service http://ghv.artzub.com. >> Try to search guillep and then pharo-core. It looks really nice. >> >> What other online services you know to analyse github projects? >> >> -- View this message in context: http://forum.world.st/GitHub-code-analytics-tools-tp4920385p4920581.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 28, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Thierry Goubier

Hi Esteban, Le 28/10/2016 Ã 11:56, Esteban Lorenzano a Ã©crit : > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ What is the difference between the various x86_64 versions? I chose the itimer one for my tests. The threaded one is the "run external calls in their own thread" vm? Thanks, Thierry

Oct. 28, 2016

Re: [Pharo-dev] GitHub code analytics tools

by Dale Henrichs

On 10/28/16 2:07 AM, Guille Polito wrote: > Hi! > > -------- Original Message -------- >> >> Guillermo, >> >> Apparently you don't like the github browser-based code review tool? >> >> What are your objections? >> >> Do you know of a better tool that is out in the wild or do you just >> have visions that code review could be better? >> >> Better tools are always possible, but it is sometimes nice to use a >> tool that you didn't have to build from scratch while creating the >> better tool:) >> > Well, that is in fact my point. I'd like to know options and > alternatives. If the easiest to setup and use is github's one, ok, > that's no problem to me. Following the github workflow model is probably best for getting started ... just because it is well documented and directly supported by the guthub tools ... as a community, we need to make a shift to this new model (for some) and keeping it simple is good ... over time the github workflow has evolved and tools like the ones Phil was talking about have come into play (for good reasons) but shifting a community process is hard enough ... individual developers have the freedom to set up their projects on gitlab or bitbucket ... but for Pharo kernel adopting the github tools and workflow (in the beginning) makes a lot of sense .. > > What bothers me the most from the github+filetree combination when > reviewing a pull request, is that it is a file-based review. And > finally you're reviewing the low-level export format, and I get a bit > lost... Just dreaming, maybe there is some tool out there where we can > just provide a kind of plugin to enhance the review? I mentioned in another thread that I would like to see an amber (or PharoJS) based github filetree browser that allowed one to browse the project code in a familiar Smalltalk browser ... I assume that a project diff browser could be done as well --- I think the web api for github is pretty sophisticated so these kinds of tools would be possible ... I'd think > > But for sure I do not want to do one from scratch :) Haha, yeah ... I've got an amber-based repository viewer that I use on my github.io page .. and it comes complete with a MNU and a debugger ... I would fix the bug, but I think that the having the debugger come is kind of nice ... in a twisted sort of way:) Dale [1] http://dalehenrich.github.io/ > >> Dale >> >> On 10/27/2016 05:06 AM, Guillermo Polito wrote: >>> I would like to have a good code review tool, before having to do >>> one ad-hoc... >>> >>> On Thu, Oct 27, 2016 at 1:50 PM, Denis Kudriashov >>> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> Hi. >>> >>> With future transition to github I ask myself what tools we will >>> have out of the box. >>> I google a bit and found these nice service http://ghv.artzub.com. >>> Try to search guillep and then pharo-core. It looks really nice. >>> >>> What other online services you know to analyse github projects? >>> >>> >> >

Oct. 28, 2016

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

by Guillermo Polito

No, please, kernel test should have the fewer dependencies as possible! 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. Le 28 oct. 2016 18:52, "Denis Kudriashov" <dionisiydk(a)gmail.com> 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. 28, 2016

Mocks are missing in Pharo (from thread OSProcess is missing)

by Denis Kudriashov

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. 28, 2016

Re: [Pharo-dev] Instructions for Pharo 6 64bits

by Dimitris Chloupis

awesome thank you guys On Fri, Oct 28, 2016 at 7:05 PM stepharo <stepharo(a)free.fr> wrote: > > > Le 28/10/16 Ã 16:59, Dimitris Chloupis a Ã©crit : > > does 64 bit means that we can now take full advantage of the memory of our > system > > > yes > > > and not have to adhere to a specific limit ? > > well probably the one of your OS :) > > > Is that something the current build does or is it planned for future > releases ? > > This one. > > > > On Fri, Oct 28, 2016 at 4:19 PM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > On 28 Oct 2016, at 14:22, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > apart from the missing SSL support which makes loading complex stuff from > github a bit painfull, it seems to be usable enough. > > > I should work on this :) > > Esteban > > >

Oct. 28, 2016