www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The 3rd .10-versionly look at the pending peeves

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
(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.
Jan 06 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 06 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 06 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 06 2005
prev sibling parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
 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?)
Jan 06 2005
next sibling parent Carotinho <carotinobg yahoo.it> writes:
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
Jan 06 2005
prev sibling parent "Simon Buchan" <not a.valid.address.com> writes:
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
Jan 06 2005