Le 29/10/16 à 08:39, [email protected] a écrit :
Having them in image can indeed be useful.
I am testing against REST backends, and well, this is a destructive
test to say the least. Not easy to replay as much as I want.
I hope that with the Bootstrap we'll be able to have a set of
"Batteries Included" distributions. Kind of like we have Moose today,
which I like very much as I do not have to load parts from all over
the place.
Yes we will now people will be able to also define their own image.
At the end
bootstrap
+ configura
+ jenkins
= an image
On http://tcl.tk there are also a number of such distributions:
* the "Batteries Included" ActiveTcl
(http://www.activestate.com/activetcl) with its various support levels
[which would be good to emulate for the Pharo Pro business proposition]
* TclKit / StarKits concept (http://wiki.tcl.tk/52). TclKit is a
BaseKit. See http://wiki.tcl.tk/15985 for a table of kits and their
supported features.
* Build your own from sources.
TclKit allows one to build special kit, using a command line tool,
similar to what we discuss for loading packages easily.
http://wiki.tcl.tk/10558
We do have an image and the TclKit has a VFS (Virtual File System)
bundling everything in a single file.
So, basically, one runs things with tclkit hello.kit. Quite
reminiscent of pharo Pharo.image I'd say.
Question 1:
Which top 5 packages/configurations would you find useful to have
available in a distribution?
1-
2-
3-
4-
5-
Question 2:
What do you consider to be the top 3 use cases of a Pharo Distribution
for your own use?
1-
2-
3-
Best,
Phil
`
On Fri, Oct 28, 2016 at 8:36 PM, Denis Kudriashov
<[email protected] <mailto:[email protected]>> wrote:
2016-10-28 18:58 GMT+02:00 Guillermo Polito
<[email protected] <mailto:[email protected]>>:
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.
