RE: re: TrueType font support and 3.6

I'll take that as a reminder that we haven't yet created the official
submission/review policy we talked about last week. Here's a draft -

Code submitted should be the simplest thing that could possibly work
(*), where "work" is defined as providing the functionality promised
(ENH) or correcting the bug (FIX) without creating others.

(*) note that this precludes, among other forms of complexity -
1. Dead code that does nothing.
2. Extensions to existing classes that are not strictly required for the
code to work.
3. Breaking or undoing other peoples changes.

Andreas, does this help?

Daniel

Andreas Raab <[email protected]> wrote:
> Hi Daniel,
> 
> > > 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? 
> 
> 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 
> > 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
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sun Jun 22 00:53:27 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 22085 invoked from network); 22 Jun 2003 00:53:27 -0000
Received: from mxout1.netvision.net.il (194.90.9.20)
  by mail.theinternetone.net with SMTP; 22 Jun 2003 00:53:27 -0000
Received: from aSqueakSystem ([80.178.105.14]) by mxout1.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTPA id <[email protected]> for
 [email protected]; Sun,
 22 Jun 2003 03:53:26 +0300 (IDT)
Date: Sun, 22 Jun 2003 03:44:07 +0200
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]re: TrueType font support and 3.6
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5174
Content-transfer-encoding: 7BIT
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: Sun, 22 Jun 2003 00:53:28 -0000

I don't know about the rest of Agile Development, but XP claims that
code is easy to _change_ (not fix) things *iff* up to that point, you
refactored mercilessly, did the simplest things that could possibly
work, and have tests to back you up. If the code in question was
refactored mercilessly, we would not be having this discussion... 

We're not talking about potential bugs here (which additional testers
might flush out, as you say), we're talking about code that hasn't been
improved or pronounced ready by it's author, after recieving a first
review. I don't understand what there is to discuss.

Daniel

Marcus Denker <[email protected]> wrote:
> On Sat, Jun 21, 2003 at 06:04:03PM +0200, Daniel Vainsencher wrote:
> > Hi Andreas - 
> > 
> > I'm confused too. Let's try to isolate the problem.
> > 
> > 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. 
> > 
> > Claim II - I percieve as a very obvious, general rule that at every
> > stage of mixing code in with more of the real world, the price of fixing
> > errors goes up, because problems are easier to solve in isolation.
> > Therefore, make it work, make it right, then deploy wider.
> > 
> 
> Problem is: Claim II is wrong. And obvioulsy so: Adding a big
> changeset to Squeak takes a long time: It needs to be reviewed,
> and discussed (image or package?). Most of the time those things
> are pretty complicated, just because they tuch a lot of stuff 
> where not many reviewsers are real experts. So adding big things
> takes time.
> 
> On the other hand: small, isolated refactorings, that fix a little
> thingy at one place can be harvested *very* fast: lots of people
> can review a simple refactoring (e.g. removing a direct reference
> to a class) without understanding the whole thing that was once that
> big changeset. 
> 
> Another thing: Adding even not-perfectly working stuff can be good, because
> it gets tested by lots of people, and most squeakers who
> follow the update stream actively fix bugs they encounter. They
> do this for the stuff in the update stream, not for those big changesets
> that are in the review process.
> 
> So my claim (which is not new btw, it's the basis of the whole "Agile
> Development" Hype) is that it's less expensive to fix things later
> than most people would intuitivly guess.
> 
>   Marcus
> 
> -- 
> Marcus Denker [email protected]  -- Squeak! http://squeak.de
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sun Jun 22 00:53:28 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 22090 invoked from network); 22 Jun 2003 00:53:28 -0000
Received: from mxout1.netvision.net.il (194.90.9.20)
  by mail.theinternetone.net with SMTP; 22 Jun 2003 00:53:28 -0000
Received: from aSqueakSystem ([80.178.105.14]) by mxout1.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003))
 with SMTPA id <[email protected]> for
 [email protected]; Sun,
 22 Jun 2003 03:53:26 +0300 (IDT)
Date: Sun, 22 Jun 2003 03:55:44 +0200
From: Daniel Vainsencher <[email protected]>
Subject: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
To: [email protected],<[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5174
Content-transfer-encoding: 7BIT
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: Sun, 22 Jun 2003 00:53:28 -0000

[Additions to various classes...]
Note that my problem with these is not that I argue with the usefulness
of specific items - I simply don't think that it's appropriate to
include them as part of a fix. Why don't you post them one by one to the
mailing list for discussion, where people may argue whether they are
appropriate. You're saying that something should be part of the class
library, defend your opinions on squeak-dev, just like Richard does,
method by method, idea by idea.

[... are mostly required by closures, not runtime fixes]
Great. Then can you please isolate only those needed for the runtime
fixes? it'll mean we have a lot less to talk about before including the
runtime fixes in the image. Then we'll only need a review by someone
with exceptions savvy...

Daniel

Anthony Hannan <[email protected]> wrote:
> > >4 Anthony runtime enhancements (split in two - fixes and closures)
> 
> There are two packages: ContextCleanupPlus-ajh.zip and ClosureCs-ajh.zip. 
> ContextCleanupPlus cleans up contexts, exceptions, and related classes.  You
> can think of it as part of KCP.  I have used it for about a year in my image,
> and after a few minor updates here and there, things are running very smoothly.
>  I would encourage people to test it just by loading it and going about their
> normal business.  Normal operation will test its low-level changes.
> 
> > What about the SmaCC license issue?
> 
> ContextCleanupPlus does not depend on SmaCC, only ClosureCs does which we can
> be considered after ContextCleanupPlus.  ClosureCs depends on
> ContextCleanupPlus but not vice versa.
> 
> > Anthony, for some reason includes in this package myriad changes to
> > existing classes.
> 
> Of course, cleanup involves changes to existing classes.  If you're talking
> about the additional protocol I've added to general classes, below are the
> detailed explanations.  I think you will agree they a reasonable, and truly
> belong as class extensions rather than in user classes where they would be
> tedious and less reusable.  I would not be afraid to add these new protocols
> especially since they can't affect any existing code.  Note, many of the users
> are in ClosureCs and not in ContextCleanupPlus itself.
> 
> Object>>literalEqual: - Do the receiver and argument represent the same
> literal.  Note, two objects can be = but not literalEqual: as in 'anthony' =
> #anthony, but ('anthony' literalEqual: #anthony) not.
> 
> Boolean>>asBit - Return 1 for true, 0 for false.
> 
> Class>>becomeClass: otherClass - Become forward the other class and fix up the
> global dictionary and system organization as well.
> 
> Collection>>collectArray: - Same as collect: except always return an array.
> 
> CompiledMethod>>headerDescription - Prints out all the components of the header
> (numArgs, numLiterals, etc) in a readable format.
> 
> LargePositiveInteger>>as31BitSmallInt - Keep my 31 bits the same but put them
> in a SmallInt.
> 
> Number>>extend: - Like #to: except designate the length instead of the last.
> 
> OrderedCollection>>bottom,top,pop,push,etc. - stack protocol.
> 
> SequenceableCollection>>allButFirstDo:,allButLastDo:,atLast:,atLast:put:
> ,copyGrowBy:copyWithFirst:,detectIndex:,reverseDetect:,slide:by:,with:wi
> thIndexDo: - Additional methods that are similar to other methods that already
> exist and should be part of the protocol because they are useful.  I bet many
> of these have been needed in the past but were coded out the long way in the
> user.
> 
> PositionableStream>>back,current,previous,do:,at:,includes: - Added helpful
> methods for stepping back and looking into the collection itself.
> 
> WriteStream>>insert:,removeNext: - Additional manipulation beside appending.
> 
> (The last two additions may not seam appropriate for streams if you look at a
> stream like a pipe.  So I could be persuaded to move these to a new class.  But
> the rest I believe are very appropriate for their specified classes.)
> 
> Cheers,
> Anthony
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sun Jun 22 01:00:54 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 26540 invoked from network); 22 Jun 2003 01:00:54 -0000
Received: from iramx1.ira.uni-karlsruhe.de (141.3.10.80)
  by mail.theinternetone.net with SMTP; 22 Jun 2003 01:00:54 -0000
Received: from acb290c8.ipt.aol.com ([172.178.144.200]
	helo=i09nbmarcus.ira.uka.de)
	by iramx1.ira.uni-karlsruhe.de with asmtp (Exim 3.30 #10 (Debian))
	id 19TtDx-0004tD-00; Sun, 22 Jun 2003 03:00:54 +0200
Received: from marcus by i09nbmarcus.ira.uka.de with local (Exim 3.33 #2
	(Debian))	id 19TtEo-0000PX-00; Sun, 22 Jun 2003 03:01:46 +0200
Date: Sun, 22 Jun 2003 03:01:46 +0200
From: Marcus Denker <[email protected]>
To: Discussing the Squeak Foundation
	<[email protected]>
Subject: Re: [Squeakfoundation]ContextCleanupPlus-ajh (was: Re: KCP & 3.6)
Message-ID: <[email protected]>
References: <[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: Mutt/1.4.1i
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: Sun, 22 Jun 2003 01:00:55 -0000

On Sun, Jun 22, 2003 at 03:55:44AM +0200, Daniel Vainsencher wrote:
> [Additions to various classes...]
> Note that my problem with these is not that I argue with the usefulness
> of specific items - I simply don't think that it's appropriate to
> include them as part of a fix. Why don't you post them one by one to the
> mailing list for discussion, where people may argue whether they are
> appropriate. You're saying that something should be part of the class
> library, defend your opinions on squeak-dev, just like Richard does,
> method by method, idea by idea.
> 
I just self-approved a two-liner I posted six weeks ago. So I would
estimate that this procedure will take maybe 3 years.

   Marcus

-- 
Marcus Denker [email protected]  -- Squeak! http://squeak.de