(Using the numbering convention of the Olympics, i.e. numbered as though they've been happening regularly without exception.)

Hello, happy new year everyone!  How well-timed DMD 0.110 was!  Now time to look at the progress at some long-outstanding issues....

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves

Bit array slicing is now working on slices beginning on a byte boundary.  I've noticed that this restriction has now been written into the spec.  Since code for the general case has been written, it seems silly to ignore it.  But if that's the way it's going to be, oh well, I guess I could add my implementation (or something based on it) to my utility lib.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/495

And although slicing is working to this extent, concatenation of bit arrays is still just as broken as it was.

http://www.digitalmars.com/drn-bin/wwwnews?D/23535

I've just put my deprecation tester through again.  It's now picking up more than it was, but there is still work to do.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1202

There were two separate bugs by which out parameters weren't working properly.  I know that the one I reported (out parameters not initialised) was soon fixed, and believe that the bug with out parameters in nested functions is now fixed.  Can someone confirm if this really is working properly now?

http://www.digitalmars.com/drn-bin/wwwnews?D/27548

Shortfalls, loopholes and suspected errors in the spec are still transpiring to an extent, and I still haven't seen much evidence of these being resolved.

Of course, it isn't really doubted that the D grammar really was meant to be context-free.  Taking out C-style casts is one step towards dealing with it.  Another apparent ambiguity (Expression.Identifier vs. (Type).Identifier) was answered.  So I thought we had the issue pretty much wrapped up (short of actually removing the old cast syntax), but then another trouble cropped up - in synchronized nested functions.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1955

The Object.opCmp debate seems to have gone quiet, but it is still far from being resolved.

http://www.digitalmars.com/drn-bin/wwwnews?D/26144
http://www.digitalmars.com/drn-bin/wwwnews?D/26193
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/10558

Even if it is a bit late to change things in time for 1.0, the documentation needs adjusting in more ways than one to reflect this. But at least it's good that AAs and sorting can now be made to work on structs; however, there is still some work to do (see my last two posts on d.D.bugs).

Now as for a decent I/O system, it seems we now have the O.  There have been one or two ideas for implementing the I - but are there any actual plans as yet?

One of various:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/13945

Benjamin Herr - you added "Portability (to amd64, for example)" to the list of things missing from Phobos.  I'm afraid this is too vague - what bits of Phobos are you claiming are unportable?

For that matter, is there any consensus on what platforms DMD 1.0 should support?  For example, is it time to write DMD for any 64-bit platforms?


This shows that, although many bugs have been fixed since I started programming in D, there is still enough to be getting on with.  Maybe it'll soon be time to put in the corners of the spec that have been left on the fence all this time.  But who knows?

Wishing D a happy, bug-free and prosperous future....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> For that matter, is there any consensus on what platforms DMD 1.0 should support?  For example, is it time to write DMD for any 64-bit platforms?

Unless Walter something changes soon, it looks like Win32 and Linux X86.
But GDC works on the following platforms: Cygwin, Linux, Darwin, FreeBSD

Not sure about the current 64-bit status of DMD/GDC and Phobos, though ?
But I think I will try it later, by making a PPC64 test build of it...

> This shows that, although many bugs have been fixed since I started programming in D, there is still enough to be getting on with.  Maybe it'll soon be time to put in the corners of the spec that have been left on the fence all this time.  But who knows?

I'd chalk up both "bit" and "real"* to the growing list in D of
neat-things-that-are-hard-to-implement-and-even-tougher-to-port ?

(* as there is no "long double" 80-bit type on the PowerPC/SPARC,
eventually it will be emulated using a *pair* of 64-bit doubles)

--anders

Anders F Björklund wrote:
<snip>
> I'd chalk up both "bit" and "real"* to the growing list in D of
> neat-things-that-are-hard-to-implement-and-even-tougher-to-port ?
> 
> (* as there is no "long double" 80-bit type on the PowerPC/SPARC,
> eventually it will be emulated using a *pair* of 64-bit doubles)

According to the spec, real is "largest hardware implemented floating point size".  So if 64-bit is the biggest floating-point type a given platform has, real and double will be effectively the same (though presumably still distinct types as far as D is concerned).

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> According to the spec, real is "largest hardware implemented floating point size".  So if 64-bit is the biggest floating-point type a given platform has, real and double will be effectively the same (though presumably still distinct types as far as D is concerned).

There is a -mlong-double-128 option to GCC, just that it's buggy...
This means that the "hardware"* supported type is either 64 or 128 ?

(* hardware is kinda relative, it's pretty common for a 64-bit int
to be emulated using two 32-bit int registers on 32-bit machines)


And the end result is that a D "real" is either 64, 80 or 128 bits.
Just like a bool is 0.125, 1 or 4 bytes and a utf is 1,2 or 4 bytes ?

It all depends on the circumstances, how it's being implemented...
Some unit tests assume that a real is bigger than a double, and fail.

--anders

> For that matter, is there any consensus on what platforms DMD 1.0
should
> support?  For example, is it time to write DMD for any 64-bit
platforms?

A vote for pda's (Pocket-PC and/or Palm).

I think D would be a huge improvement over what is currently available. Compared to the alternatives, it has the potential of being a terrific F-sF-F-nF combination (Fast, small Footprint, Free, and not Flaky)

(Is there a 'tool chain' that allows pda development on windows
computers?)

Lynn Allan wrote:

> (Is there a 'tool chain' that allows pda development on windows
> computers?)

Yes, there is, freely downloadable from Microsoft site. I too would like to develop D for my PDA, it sounds so "cool & technological" :)

Byez!

Carotinho

On Thu, 6 Jan 2005 07:25:27 -0700, Lynn Allan <l_d_allan@adelphia.net> wrote:

> I think D would be a huge improvement over what is currently
> available. Compared to the alternatives, it has the potential of being
> a terrific F-sF-F-nF combination (Fast, small Footprint, Free, and not
> Flaky)

Heh, not sure about the "not Flaky" part ];)
About the only thing I see D beating (gc)C in is occasionaly Fast,
and less buggy code (or is that the Flaky bit?)

PS: are small memory requirements an issue for GC'ed langs? Seeing
as how much java there is on mobile phones, etc..., wouldn't think so

--
"Yes, the american troops have advanced further. This will only
make it easier for us to defeat them" - Iraqi Information Minister
Muhammed Saeed al-Sahaf