From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10303182134.AA24129@clio.rice.edu>
Subject:	Re: DJGPP 2.04 release? [Was: Re: nmalloc revisited]
To:	djgpp-workers AT delorie DOT com
Date:	Tue, 18 Mar 2003 15:34:21 -0600 (CST)
In-Reply-To:	<200303182021.h2IKLlW16834@speedy.ludd.luth.se> from "ams@ludd.luth.se" at Mar 18, 2003 09:21:47 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> I don't see why that's so important. Sure, NLS binaries are bloated
> until then (or no NLS support).

It's not just NLS.  Its Mesa, and PythonD, and other projects which are
being delayed or cancelled due to the lack of support.  But if we don't
get a standard tool kit available, new builds for Simtel will never start
using it.

> The choices are:
> 1. making a 2.04 soon without that (date X) and a 2.05 with that when
> it's ready (date Y)
> 
> 2. making a 2.04 with that when it's ready (date Z)
> 
> Why wouldn't Y == Z?
> Anyway, Y will be rather close to Z.

Or choice 3, slap out 2.04 with some DXE code and if it works great, if
it doesn't then 2.05.

> What did we loose? Not much because we're using CVS anyway. But we
> deprived the users the new features for Y-Z days. (Which will be
> rather many days if past track record is anything to go by.)

I worry about no 2.05 for many years after that, and without it being
in the standard package, no one using it, and continued chaos.

> Also consider this: you manage to get the new DXE ready. Just in time
> for your departure, of course (that's the way it goes). You go
> away. Problems arise with the new DXE? What will we do without you?

You'll have the source, and I'll give you Daniel Borca's email :-)

> Is there a regular contributor here that does have a solid grip on the
> new DXE besides you? We'll probably wait for your return. See the
> problem?

It's actually pretty straightforward code - supports exception frames,
constructors, destructors.  Works with old GCCs and new ones.  Can build
dynamic libc with it.

> (This is naturally not a personal attack or any complaints about any
> DXE code. I'm just predicting a little.)

I don't mind, I think it should be discussed.  You guys know me - if I
feel really strongly I just check it in ...

But given the sparse use of DXEs now, I doubt anyone would notice a 
bug :-)

> By the way, where in Europe will you visit?

I'll be in southwest Sweden, implementing an on-line optimization.

- Raw text -