RE: re: TrueType font support and 3.6

> No, we don't "all agree". That's my point. If you consider the above to be
> serious flaws that need to be fixed then please explain to me what the
> "desired code quality" is that you are trying to achieve. To me, this is
> nit-picking.
You don't, but Yoshiki agrees. I have no ideas what issues he is working
on, and what their intersection is with the ones I raised but he's
stated that we shouldn't integrate the current version. 

I don't consider the above to be "serious flaws". I consider the above
to be the kind of small cruft that naturally accumulates when building
something, and gets easily cleaned out *before* it gets integrated and
forgotten, so that we don't one day need a TTFCP. You think this is nit
picking, I think code should be clean as it can reasonably be. The price
to clean it today is tiny compared to the price paid by everyone that
will try to maintain the code in the future.

> If alpha is closed without the TTF stuff
> it means you've delayed the most important improvement to Squeak's user
> interface in the last three years.
Have you ever failed a test because you didn't put in the effort and had
to do it over? did you blame the teacher for writing the test? 

You may see things so that you think that I'm delaying this code, but
this code could easily be cleaner, and you know it, and you can do
something about it just as easily as me. As for my role in this, I don't
agree that welcoming cruft into Squeak arbitrarily is the way to advance
it.

I think this is clearly about values, and maybe about that "Vision" you
were looking for so hard - I think Squeak's code should be something
that people enjoy reading. I think much of the power Smalltalk has had
over Smalltalkers' ideas comes from teaching them by example "this is
how it should be". Cruft in the Basic Squeak image sabotages that
effect, and makes Squeak weaker in something that really matters. I'm
going over to a friend whom I'm teaching Smalltalk, we'll be looking at
squeak code, and he'll be asking "why did they do that?" with all
intention to learn something new. And I'll say to him, "Oh, no, ignore
that, some people think it's ok to let cruft into the image (but look at
the beautiful fonts it gives us!). Here, look at this bit, this one is
good... well mostly".

[Conflicts are hard to find]
Well, yes. Do you think that the fact that conflict detection is hard
means that we should ignore it? We can do the work at integration, or we
can be surprised later by problems in releases newbies use. This extra
work is the price of distributed development. The problems of unchecked
conflicts will get worse with more contributors. BTW, feel free to try
out and improve Dougs conflict checker.

[DecPools and KCP]
The fact that conflicts with packages are hard to solve is a sad
consequence of not having package releases. It is made more difficult by
having more packages, but the solution is not in going back to a
monolithic image, but in improving our infrastructure (SM1.1). Wish I
could give you a release date for that, but I can't. When we're talking
about a package, like RB, what I did was fork it into two packages. When
we're talking about a patch like DecPools, I would track the current
alpha, because the version for an old 3.6 won't be particularly useful
to anyone.

Daniel

Andreas Raab <[email protected]> wrote:
> Hi Daniel,
> 
> > Do we disagree on the code, on the software engineering rule of thumb,
> > on its application to this code, or on its application to 
> > Squeak code in general?
> 
> We disagree on the terms "flaw" and "error". The issues you originally
> mention may (depending on ones interpretation, certainly not mine - see
> below) be seen as "flaws" but there are definitely no "errors" in what you
> describe. None of them (not a single one) will prevent Squeak to function
> correctly.
> 
> > I don't see what this has to do with beta
> 
> It has a whole lot to do with beta. If alpha is closed without the TTF stuff
> it means you've delayed the most important improvement to Squeak's user
> interface in the last three years. For reasons which I find impossible to
> follow.
> 
> > I also never required that conflicts be checked with "all 
> > ongoing work" - MCP is part of Squeak 3.6 as of 5240, IIRC.
> > Conflicts with previously included work should be detected
> > and resolved, of course - when we don't
> > do this, we get the annoying "didnt I fix this already" effect.
> 
> Are you aware that right now this is almost impossible? For example, I've
> posted the declarative pools at SqueakMap and there are a few conflicts with
> KCP changes. Fixing these conflicts means that suddenly noone in pre-3.6
> systems can load this any longer. So how do you propose to proceed in this
> situation?
> 
> I'd argue that what we want to do is to load the existing code base and fix
> the conflicts as things get integrated. This leaves the package at SqueakMap
> alone and will allow others to use it, too.
> 
> [snip]
> > On the other hand, the work hasn't been done yet to bring it up
> > to the desired quality level.
> 
> Desired by whom? Looking at your critique in detail:
> 
> >  - at least one method clashes with MCP.
> 
> It's not "at least" one method but "exactly" one method and the conflict is
> that some "verb first" has been reverted to "verb at: 1".
> 
> >  - The single GrafPort method sends to super but
> > implicitly returns self.
> 
> I don't get the point here. Why can't a method send to super and implicitly
> return self? In any case, it seems that this method is just a left-over from
> later improvements.
> 
> >  - Paragraph>>asForm does an "isKindOf: TTCFont"
> 
> Again, what's your point here? Paragraphs have to know fonts or else they
> can't function correctly. One can argue that using isKindOf: is generally
> not good style (and I agree on this) but in this particular case the action
> taken is so specific for TTCFonts that it makes perfect sense to use
> #isKindOf:.
> 
> > Claim I - We have a piece of code that's candidate for inclusion. We all
> > agree it has flaws as detected by even cursory inspections.
> 
> No, we don't "all agree". That's my point. If you consider the above to be
> serious flaws that need to be fixed then please explain to me what the
> "desired code quality" is that you are trying to achieve. To me, this is
> nit-picking.
> 
> Cheers,
>   - Andreas
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sat Jun 21 19:39:54 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 23199 invoked from network); 21 Jun 2003 19:39:54 -0000
Received: from mail.gmx.de (HELO mail.gmx.net) (213.165.64.20)
  by mail.theinternetone.net with SMTP; 21 Jun 2003 19:39:54 -0000
Received: (qmail 25532 invoked by uid 65534); 21 Jun 2003 19:39:53 -0000
Received: from p508833C7.dip.t-dialin.net (EHLO atlantis) (80.136.51.199)
  by mail.gmx.net (mp007) with SMTP; 21 Jun 2003 21:39:53 +0200
From: "Andreas Raab" <[email protected]>
To: "'Discussing the Squeak Foundation'"
	<[email protected]>
Subject: RE: [Squeakfoundation]re: TrueType font support and 3.6
Date: Sat, 21 Jun 2003 21:39:42 +0200
Message-ID: <000101c3382c$dcc8ced0$8ef7fea9@atlantis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[email protected]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.squeakfoundation.org/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sat, 21 Jun 2003 19:39:55 -0000

Hi Daniel,

> > If alpha is closed without the TTF stuff
> > it means you've delayed the most important improvement to=20
> > Squeak's user interface in the last three years.
> Have you ever failed a test because you didn't put in the=20
> effort and had to do it over? did you blame the teacher for
> writing the test?=20

Yes, but in these situations the rules were clear to me and I knew what
exactly I should have done differently.

Again: Please explain to me what your desired code quality is. What =
measures
do you use? What are the rules?

> You may see things so that you think that I'm delaying this code, but
> this code could easily be cleaner, and you know it, and you can do
> something about it just as easily as me.

Only if I know the rules. Otherwise I can only wait until  there is some
critique here or there and depending on your workload this may take =
days,
weeks, or months.

> [Conflicts are hard to find]
> Well, yes. Do you think that the fact that conflict detection is hard
> means that we should ignore it?

You lost me here. Finding potential conflicts with other packages is =
quite
simple once you've got the stuff loaded. Just go into a dual change =
sorter
and choose "conflicts with other change sets" and it'll list you all of
them. Then you turn on the diffs and voila! all your conflicts get =
nicely
highlighted. Fixing them can be a different matter though ;-)

> [DecPools and KCP]
> The fact that conflicts with packages are hard to solve is a sad
> consequence of not having package releases. It is made more=20
> difficult by having more packages, but the solution is not
> in going back to a monolithic image, but in improving our
> infrastructure (SM1.1).

You lost me again. I don't see how the above is related to my question =
about
how to handle a concrete case in a concrete situation. Please explain.

> Wish I could give you a release date for that, but I can't.

I sure hope it's soon. I already started to manually mirror important
packages in order to be able to rely on the right versions. It sucks =
like
hell but there's nothing else I can do.

> When we're talking about a package, like RB, what I did was fork it =
into
> two packages. When we're talking about a patch like DecPools, I would
track
> the current alpha, because the version for an old 3.6 won't be
particularly
> useful to anyone.

I think it's quite valuable to have it available for older Squeak =
versions.
The point is that someone may want to load a package which contains a
declarative pool in something like 3.4/3.5. Having the package at =
SqueakMap
means that they have at least a chance to try it.

Cheers,
  - Andreas