2016-10-30 12:00 GMT+01:00 Tudor Girba <[email protected]>:

> Hi,
>
> > On Oct 30, 2016, at 11:55 AM, Nicolai Hess <[email protected]>
> wrote:
> >
> >
> >
> > 2016-10-30 11:52 GMT+01:00 Nicolai Hess <[email protected]>:
> >
> >
> > 2016-10-30 11:41 GMT+01:00 Tudor Girba <[email protected]>:
> > 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 <[email protected]> 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."
>
>
>

Reply via email to