[UPDATES] 34 for Squeak3.7alpha AND TESTS!!!!

ducasse ducasse at iam.unibe.ch
Sun Jan 18 10:20:02 UTC 2004


Hi all

this is my last email on the topic. Because I have to work. I start to 
be a bit worried by the questions...

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.
If in the future, this situation would escape us then we also can in 10 
min removed them from the image.
Have you realised that if marcus would have spend time separating tests 
from the code they would be there.
The intention of marcus was good. As soon as we can manage the tests 
easily we can redo that.

Still the tests of the core image (OrderedCollection, ClassBuilder....) 
should be in the image and we have unload package scripts
when we will have them.

>> Why a decision should force people working losing more time.

By the way, we ARE losing our time, harvesters, reviewers and end 
programmers because we can submit bug that are not bugs....
See the insert:before: dsicussion and we can review a bug that is not 
one!!! And we have to close it and soon on....

testAddBeforeAndRemove
	"self run: #testAddBefore"

	| l initialCollection |
	l := #(1 2 3 4) asOrderedCollection.
	initialCollection := l shallowCopy.
	l add: 88 before: 1.
	self assert: (l =  #(88 1 2 3 4) asOrderedCollection).
	l add: 99 before: 2.
	self assert: (l =  #(88 1 99 2 3 4) asOrderedCollection).
	l remove: 99.
	l remove: 88.
	self assert: l = initialCollection.

testCreationFromString
	| uuid string |
	string _ UUID nilUUID asString.
	uuid _ UUID fromString: string.
	self should: [uuid size = 16].
	self should: [uuid = UUID nilUUID].
	self should: [uuid isNilUUID].
	self should: [uuid asString size = 36].
	self should: [uuid asArray asSet size = 1].
	self should: [(uuid asArray asSet asArray at: 1) = 0].

testNormalize

	"Check normalization and conversion to/from SmallInts"

	self should: [(SmallInteger maxVal + 1 - 1) == SmallInteger maxVal].
	self should: [(SmallInteger maxVal + 3 - 6) == (SmallInteger 
maxVal-3)].
	self should: [(SmallInteger minVal - 1 + 1) == SmallInteger minVal].
	self should: [(SmallInteger minVal - 3 + 6) == (SmallInteger 
minVal+3)].

Do we need a book or a documentation after that!



> 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?
Really what have you done for the community? I like diego point of view 
and also the SCRUM
methodology only people that commit to do stuff should talk.

>  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***.
We are some of the few that:
	- help on henryk packages: alex did a ftp server on my demand
	read the last email I sent on the topic when henryk insulted us to 
know what we really did.
	- alex, roel, nathanael, me and nadrew spedn a lot of time on that!!!!

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 
(and are right) 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.

Please note that I will not continue to reply to emails related to this 
topic in the future.
Not because I'm ^^&^*(^&*( (fill what you want) but because I have no 
time.

Stef

I like the email of diego about goal and resources....
My goal is to have something that fits today problems and we will 
change when you guys will
propose new tools. I really thanks Brent for BFAV because I do not have 
the time to do it and this is great.




More information about the Squeak-dev mailing list