[UPDATES] 34 for Squeak3.7alpha AND TESTS!!!!
ducasse
ducasse at iam.unibe.ch
Sun Jan 18 09:16:50 UTC 2004
Hi all
this is my last email on the topic. Because I have to work ;) yes even
the sunday.
I see that basically we had three or four persons against tests in the
image. This is a good news.
Note that this is clear that we were talking about tests of the basic
image, the situation should be clearer.
If in the future, this situation would escape us then we also can in 10
min removed them from the image.
>> Why a decision should force people working losing more time.
>
> I hope that is not saying that SqueakMap and package info-style
> modularization have been the wrong way to go and that, instead,
> everything should be kept in a monolithic image with every change going
> through the update stream. I have felt that the renaissance we are
> enjoying in Squeak was sparked by Goran's diplomacy in moving us off
> the
> dead-end 3.3 and into our current SqueakMap era (and fueled by Avi's
> package info and the hard work of many, including you).
Me too. to not oppose things that are not opposed.
> And, that a key
> aspect of this is to transfer everything possible out of the most basic
> image and onto SqueakMap.
Read my previous emails. Why do I spent/lose time on KCP for masochists
feelings?
> Perhaps you have been in agreement with that
I suggest you to read the archive and discussion on modules to see that
I
was a big fan of packages ***but with the right architecture***. So I'm
waiting
for SM2. But SM2 pakage are at another level. And I would like to see
monticello been
used for project where there are more than two persons. Here we develop
code with people in
Roumania, belgium, and we have in the group at least 6 people coding
different stuff over the same core.
I really could not see how to handle that with Monticello not because
monticello is bad but because
we need more. But Avi knows that we already discussed about that.
> but had felt either or both that (a) the core tests were an exception
> or
> (b) that the core tests were not or could not be put on SqueakMap.
TESTS are ACTIVE and ALWAYS SYNCHRONISED DCOUMENTATION.
So all the people complaining that there is no documentation in Squeak
will be happy to be able
to read tests. Tests are simple to write and contrary to a Wiki page
that is already obsolete when you save it
tests stay valid. But for that they should be visible.
But from now on I will stop losing my time saying obvious thing. You
know this is the same
as trying to convince the strongly type language programmer that never
tried dynamically
language that dynamically typed languages are cool and we do not have
too much bug.
As such they should not be not present with the code they cover
***before***
we get an easy to use package mechanism. Right now we are developing
using
monticello a new version of traits and we end up merging all the code
in one file to be able
not to lose too much time identifying which version of with parts work
with which
other. We are three developers and there were three files and this was
the mess.
So for now if you want to help, help extending monticello to have
Bundles/package
as in Envy/Store so that I can identify a build and I can load it in
one click.
This is not that difficult, just copy Ginsu module model.
Once we have that then we will be able to do all kind of stuff. Right
now we cannot.
I would be so happy to be able to use that!
> I think, though, if I have followed your and Avi's comments, that we
> now
> have an even better resolution: that you will send the necessary
> changesets to Avi and that he will put the tests on SqueakMap.
As responsible of KCP I would prefer to manage our tests ourselves.
But we will see. Also WE HAVE TO HAVE THE TEST RELATED TO THE CODE
BESIDE THE CODE: imagine if the tests on orderedCollection would have
been there
then this guy would not have sned a bug report for insert: because he
would have read the tests,
see the green light and say "of Course"
TESTS ARE ACTIVE AND SYNCHRONISED DOCUMENTATION DOCUMENTATION.
End of my thread.
More information about the Squeak-dev
mailing list
|