www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.047 and 2.032 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
This will probably be the last OSX 10.5 release, the next should be 10.6.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.047.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.032.zip

Many thanks to the numerous people who contributed to this update.
Sep 03 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
M-M-M-MONSTER KILL!

The serious bug splatting action continues.

Thank you Walter and contributors.
Sep 03 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip
 
 Many thanks to the numerous people who contributed to this update.


Errata:
dmd2 source, arrayop.c, line 427 is missing a 'return'.

-	Expression::buildArrayLoop(fparams);
+	return Expression::buildArrayLoop(fparams);
(this only matters if you are building DMD from source. It's not a bug 
in the released DMD).

A few bugs are fixed but not listed in the changelog:
3077 crash exiting main() without result code
3100 ICE(cast.c) struct with members is shared
3253 DMD crashes on function pointer struct member initialization with 
function literal
3281 ICE(cod1.c) append returned struct to array
Sep 03 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Indeed, using CTFE will probably feel different after this release of D1/D2.
Good work.

I'd like to improve this Wikipedia page some more:
http://en.wikipedia.org/wiki/Compile_time_function_execution

So after all such bugfixes are there better ways to implement the following
code (better = simpler, more natural, etc)?

import std.stdio: writeln;

int[] genFactorials(int n) {
    int factorial(uint n) {
        int result = 1;
        for (int i = 1; i < n+1; i++)
            result *= i;
        return result;
    }

    int[] result;
    for (; n >= 0; --n)
        result = factorial(n) ~ result;
    return result;
}

const int N = 13;
static const auto factorials = cast(int[N])genFactorials(N - 1);

void main() {
    writeln(factorials);
}

For me creating tables at compile-time is an important use case for CTFE. But
that CTFE code is/was fragile, if you change it a bit it stops compiling.

Bye,
bearophile
Sep 03 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 A few bugs are fixed but not listed in the changelog:
 3077 crash exiting main() without result code
 3100 ICE(cast.c) struct with members is shared
 3253 DMD crashes on function pointer struct member initialization with 
 function literal
 3281 ICE(cod1.c) append returned struct to array


Ok, I put 'em in.
Sep 03 2009
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Walter Bright wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip
 
 Many thanks to the numerous people who contributed to this update.



This is great! I can't wait to try out the compiler's new CTFE 
capabilities. :)

Thanks, Walter, Don, Andrei, and other contributors, for putting in all 
the hard work!

-Lars
Sep 03 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip
 
 Many thanks to the numerous people who contributed to this update.


I think Walter forgot to update the changelog from svn before releasing. 
I've sent a bunch more fixes which I paste in source form below. Walter, 
could you please update changelog.dd from svn and then update the html 
changelog? Let's make this bug slugfest a tad even more impressive :o). 
Thanks.

Andrei

	$(LI $(BUGZILLA 3249): sort and setIntersection on array of struct or 
class)
	$(LI $(BUGZILLA 3245): Easy bug fix available for disabled unit test 
code in std.encoding)
	$(LI $(BUGZILLA 3242):  splitter does not handle input range made of a 
unique separator correctly)
	$(LI $(BUGZILLA 3239): std.conv.roundTo does not accept 
const/immutable/shared)
	$(LI $(BUGZILLA 3224): std.random documentation bugs)
	$(LI $(BUGZILLA 3219): Inaccurate std.conv.to!(numeric)(numeric) error 
messages)
	$(LI $(BUGZILLA 3218): Performance of std.xml.encode must be improved)
	$(LI $(BUGZILLA 3217): std.functional.binaryFunImpl doesn't support UDT 
with string functions , therefore neither does many std.algorithm functions)
	$(LI $(BUGZILLA 2979): Xml tags with only attributes return as without 
attributes ElementParser.parse)
	$(LI $(BUGZILLA 3199): sort(chain(...)) doesn't work in some cases)
	$(LI $(BUGZILLA 3197): Minor fixes and additions to std.traits)
	$(LI $(BUGZILLA 3195): `std.conv` pureness (closed with "later" advise))
	$(LI $(BUGZILLA 3189): `std.conv.to` : check for a custom `to` method 
in classes/structs)
	$(LI $(BUGZILLA 3184): std.algorithm.until should work like "find")
	$(LI $(BUGZILLA 3148): syntax error using invariant)
	$(LI $(BUGZILLA 3132): std.string.split should be templated on 
mutable/const/immutable)
	$(LI $(BUGZILLA 3098): std.algorithm.reduce example can not compile)
	$(LI $(BUGZILLA 3087): std.range.retro.opIndex out of range)
	$(LI $(BUGZILLA 3074): std.conv.to!(string)(int.min))
	$(LI $(BUGZILLA 3037): Off-by-one error in Stride.length)
	$(LI $(BUGZILLA 3025): uniform(float,float) pops first, 
uniform(int,int) pops last)
	$(LI $(BUGZILLA 3017): doc errors in std.range (on behalf of Steven 
Schveighoffer))
	$(LI $(BUGZILLA 2996): std.typetuple: add support for any static tuples)
	$(LI $(BUGZILLA 2992): (closed with "later" advise))
	$(LI $(BUGZILLA 2989): std.typetuple: add support for any static tuples)
	$(LI $(BUGZILLA 2988): Chain needs opIndexAssign.)
	$(LI $(BUGZILLA 2976): rename retreatN to retreat)
	$(LI $(BUGZILLA 2980): compiler error when writefln( uint ))
	$(LI $(BUGZILLA 2786): Interfaces should be able to require 
constructors (closed with "invalid" advise))
	$(LI $(BUGZILLA 2785): Interfaces should be able to require non-member 
functions (closed with "invalid" advise))
	$(LI $(BUGZILLA 2784): Interfaces should be able to require type 
definitions (closed with "invalid" advise))
	$(LI $(BUGZILLA 2150): cannot get values from const variant)
	$(LI $(BUGZILLA 1940): Phobos buildscripts do not work on x86_64)
	$(LI $(BUGZILLA 3260): "Error: undefined identifier backend" when 
compiling 'write' with 'wchar')
	$(LI $(BUGZILLA 1604): Non-final method on final struct is too 
restrictive (closed with "invalid" advise))
	$(LI $(BUGZILLA 1616): std/metastrings.d)
Sep 03 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:

 Walter, 
 could you please update changelog.dd from svn and then update the html 
 changelog?


done.
Sep 03 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:

 Andrei Alexandrescu wrote:

 Walter, could you please update changelog.dd from svn and then update 
 the html changelog?


 
 done.


I counted 102 fixed bugs in this release.

Andrei
Sep 03 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  3 de septiembre a las 01:16 me escribiste:

 This will probably be the last OSX 10.5 release, the next should be 10.6.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip
 
 Many thanks to the numerous people who contributed to this update.


These are a very good release, thanks for your work.

Aren't the new CTFE capabilities new features? It's ok to fold them in
DMD1? This is a change to the specs too (unless is considered
a non-standard DMD extension to D1).

I just wonder where the line is drawn to fold changes into D1.

Don't get me wrong, as I stated before, I'm really glad D1 get some new
features/improvements, I just think the changes should be a little more
tested before hit D1 (and new aditions to D1 should be more planned, for
example, leaving them in D2 for a few releases only, so you can get real
feedback from users before puting them in D1, and having some version
scheme to indicate when new features are added).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
If you don't know what direction you should take
You don't know where you are
Sep 03 2009
parent reply Don <nospam nospam.com> writes:
Leandro Lucarella wrote:

 Walter Bright, el  3 de septiembre a las 01:16 me escribiste:

 This will probably be the last OSX 10.5 release, the next should be 10.6.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip

 Many thanks to the numerous people who contributed to this update.


 
 These are a very good release, thanks for your work.
 
 Aren't the new CTFE capabilities new features? 


They're basically bug fixes. All that stuff should have worked. There 
are several other bugs which cannot be fixed without them.
For example, bug 1461 couldn't be fixed without allowing nested functions.
Bug 1950 couldn't be fixed without implementing almost everything 
required for member functions.

Some bugs are so crippling that when they're fixed, it's pretty much a 
new feature.


 Don't get me wrong, as I stated before, I'm really glad D1 get some new
 features/improvements, I just think the changes should be a little more
 tested before hit D1 (and new aditions to D1 should be more planned, for
 example, leaving them in D2 for a few releases only, so you can get real
 feedback from users before puting them in D1, and having some version
 scheme to indicate when new features are added).


I believe you will find the new CTFE very stable. In implementing the 
improvements, many structural problems were fixed. It turns out to be a 
very effective way of diagnosing bugs.
Sep 03 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Don, el  3 de septiembre a las 17:30 me escribiste:

 Leandro Lucarella wrote:

Walter Bright, el  3 de septiembre a las 01:16 me escribiste:

This will probably be the last OSX 10.5 release, the next should be 10.6.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.047.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.032.zip

Many thanks to the numerous people who contributed to this update.


These are a very good release, thanks for your work.
Aren't the new CTFE capabilities new features? 


 
 They're basically bug fixes. All that stuff should have worked.


Not all of them, I've seen the spacs have changed for D2:
http://www.dsource.org/projects/phobos/changeset/1262

I'm just talking about the changes that relaxed the CTFE restrictions
imposed in the specs. Again, that can be called simply a non-standard DMD
extension to D1 and that would be fine with me.


Don't get me wrong, as I stated before, I'm really glad D1 get some new
features/improvements, I just think the changes should be a little more
tested before hit D1 (and new aditions to D1 should be more planned, for
example, leaving them in D2 for a few releases only, so you can get real
feedback from users before puting them in D1, and having some version
scheme to indicate when new features are added).


 I believe you will find the new CTFE very stable. In implementing the
 improvements, many structural problems were fixed. It turns out to be
 a very effective way of diagnosing bugs.


You never know. People use features in extremely different ways, sometimes
in ways you can't possibly foreseen (I think once Walter said that about
the kind of magic you do with CTFE =). Maybe you break some code that
relied on something that doesn't compile (as Bartoz shows in his last post
=). I'm not saying that would happen, I'm just saying that there is a lot
of D out there, and even a simple change should be taken with care. There
are 2 versions of D, one stable and one in development, I think that
should be used and put new features out there in the development version
only for some time, just to be sure, and then move them to the stable
version (some sort of Debian testing/stable =P).

And I want to say again that all your contribution, in this release in the
CTFE front specially, is really impressive, and I hope you keep doing what
you're doing for a long time, even if changes are folded in D1 with blind
trust =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Y serán tiempos de vanos encuentros entre humano y humano; en que las
fieras se comerán entre ellas y después del final; en que se abríran las
tierras y los cielos... y en el medio de la nada Racing saldrá campeón.
	-- Ricardo Vaporeso
Sep 03 2009
parent reply Don <nospam nospam.com> writes:
Leandro Lucarella wrote:

 Don, el  3 de septiembre a las 17:30 me escribiste:

 Leandro Lucarella wrote:

 Walter Bright, el  3 de septiembre a las 01:16 me escribiste:

 This will probably be the last OSX 10.5 release, the next should be 10.6.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip

 Many thanks to the numerous people who contributed to this update.


 These are a very good release, thanks for your work.
 Aren't the new CTFE capabilities new features? 


 They're basically bug fixes. All that stuff should have worked.


 
 Not all of them, I've seen the spacs have changed for D2:
 http://www.dsource.org/projects/phobos/changeset/1262
 
 I'm just talking about the changes that relaxed the CTFE restrictions
 imposed in the specs. Again, that can be called simply a non-standard DMD
 extension to D1 and that would be fine with me.
 

 Don't get me wrong, as I stated before, I'm really glad D1 get some new
 features/improvements, I just think the changes should be a little more
 tested before hit D1 (and new aditions to D1 should be more planned, for
 example, leaving them in D2 for a few releases only, so you can get real
 feedback from users before puting them in D1, and having some version
 scheme to indicate when new features are added).


 I believe you will find the new CTFE very stable. In implementing the
 improvements, many structural problems were fixed. It turns out to be
 a very effective way of diagnosing bugs.


 
 You never know. People use features in extremely different ways, sometimes
 in ways you can't possibly foreseen (I think once Walter said that about
 the kind of magic you do with CTFE =). Maybe you break some code that
 relied on something that doesn't compile (as Bartoz shows in his last post
 =).


Yes, but that's true of ANY bug fix. In fact, the CTFE "features" are 
much smaller changes than many of the bug fixes. The biggest CTFE change 
was actually the fact that references didn't work properly. (They 
compiled but generated wrong code).

I'm not so worried about CTFE stuff, because the compiler behaviour has, 
up to now, departed so radically from the spec that it hasn't been 
possible to depend on it.  Eg, x[x.length - 4]='c'; compiled, but 
x[$-4]='c' did not compile! More importantly, CTFE is almost completely 
isolated from the rest of the compiler: it can't break anything that's 
not CTFE.

AFAIK, the only areas where DMD1 can still get "new features" is CTFE, 
array operations, and contract inheritance. They are the three areas 
where the implementation wasn't finished when D2 began, and where the 
compiler behaviour has never been close to the spec. It is likely, for 
example, that unions will need to be disallowed in CTFE, but there's 
absolutely no reason why 'new' expressions should be disallowed.
Similarly, the specs say nothing about whether array expressions are 
legal in CTFE.


 I'm not saying that would happen, I'm just saying that there is a lot
 of D out there, and even a simple change should be taken with care. 


Indeed. There are still D1 bugs which can only be fixed by some fairly 
large compiler changes. On the CTFE side, fixing bug 1330 is going to be 
far more disruptive than anything in this release.


 There
 are 2 versions of D, one stable and one in development, I think that
 should be used and put new features out there in the development version
 only for some time, just to be sure, and then move them to the stable
 version (some sort of Debian testing/stable =P).


In theory, that already happens to an extent. The version recommended 
for download is not the latest one. I do wonder if anyone actually 
*uses* the recommended one, though!


 And I want to say again that all your contribution, in this release in the
 CTFE front specially, is really impressive, and I hope you keep doing what
 you're doing for a long time, even if changes are folded in D1 with blind
 trust =)


Thanks. I figured that right now, the most useful thing I can do is to 
patch the compiler. So I've put everything else on hold.
Sep 04 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:


CTFE is almost completely isolated from the rest of the compiler: it can't
break anything that's  not CTFE.<


It's like having a compiler plus a D1 interpreter. In theory this duplication
looks silly, in practice it seems handy.



It is likely, for example, that unions will need to be disallowed in CTFE,<


Can you tell me why?



but there's absolutely no reason why 'new' expressions should be disallowed.<


There's a compiler for a small language (designed for embedded CPUs) that
allows to allocate objects at compile time (it also compacts their fields in
smart ways, grouping fields of similar type from more than one object in a
transversal way into arrays of single fields, and compacting pointers reducing
their size, to save memory and speed up programs a little), and then at runtime
the memory can't be allocated dynamically. D can do something similar,
allocating such compile-time objects. It may save running time. I'd like to
know what people think about this.

Bye,
bearophile
Sep 04 2009
parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:
 

 CTFE is almost completely isolated from the rest of the compiler: it can't
break anything that's  not CTFE.<


 
 It's like having a compiler plus a D1 interpreter. In theory this duplication
looks silly, in practice it seems handy.


Interestingly, by *requiring* the compiler to provide an interpreter, 
the language can make optimisation guarantees about constant folding, 
_independent of the backend_.


 It is likely, for example, that unions will need to be disallowed in CTFE,<


 
 Can you tell me why?


Suppose you have:

align(2):
struct S
{
   char d;
   int a;
   char [2] b;
}

union U {
   byte[5] a;
   double x;
   S c;
}

and you write to u.c.d, and u.a[3] what value is x? It's disgusting. 
Depends on the endianness of the target system, for example.


 but there's absolutely no reason why 'new' expressions should be disallowed.<




I mean things like:
int [] a = new int[n];
which is trivial -- about 5 lines of code.

Oh. And the D1 spec doesn't disallow inline asm in CTFE.
But CTFE asm is Not Going To Happen. <g>
Sep 04 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 Oh. And the D1 spec doesn't disallow inline asm in CTFE.
 But CTFE asm is Not Going To Happen. <g>


I think that eventually we can get all of SafeD to work in CTFE, but 
inline asm isn't part of SafeD!
Sep 04 2009
parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:

 Don wrote:

 Oh. And the D1 spec doesn't disallow inline asm in CTFE.
 But CTFE asm is Not Going To Happen. <g>


 
 I think that eventually we can get all of SafeD to work in CTFE, but 
 inline asm isn't part of SafeD!


SafeD doesn't appear to be properly defined in the spec. And certainly 
not mentioned in the CTFE section. Maybe it should be. Of course, very 
little of SafeD is currently implemented. Should Bartosz' article be 
taken as authoritative? (eg, he says 'union' is not permitted in SafeD, 
so CTFE should probably ban it).
Sep 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:

 Walter Bright wrote:

 Don wrote:

 Oh. And the D1 spec doesn't disallow inline asm in CTFE.
 But CTFE asm is Not Going To Happen. <g>


 I think that eventually we can get all of SafeD to work in CTFE, but 
 inline asm isn't part of SafeD!


 
 SafeD doesn't appear to be properly defined in the spec. And certainly 
 not mentioned in the CTFE section. Maybe it should be. Of course, very 
 little of SafeD is currently implemented. Should Bartosz' article be 
 taken as authoritative? (eg, he says 'union' is not permitted in SafeD, 
 so CTFE should probably ban it).


Certainly unions that alias references with non-references should not be 
permitted, but aliasing an int with a float should be permitted.
Sep 07 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:


 but there's absolutely no reason why 'new' expressions should be disallowed.<




 I mean things like:
 int [] a = new int[n];
 which is trivial -- about 5 lines of code.


I hope to see such trivial thing in future DMDs :-)
So it may simplify the code I've shown here:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=16767

(Or I'd like to be able to return fixed-sized arrays (by value?) from
functions).

Bye,
bearophile
Sep 04 2009
prev sibling parent reply Nick B <nick.barbalich gmail.com> writes:
Don wrote:

 Leandro Lucarella wrote:

 Walter Bright, el  3 de septiembre a las 01:16 me escribiste:


 

 Don't get me wrong, as I stated before, I'm really glad D1 get some new
 features/improvements, I just think the changes should be a little more
 tested before hit D1 (and new aditions to D1 should be more planned, for
 example, leaving them in D2 for a few releases only, so you can get real
 feedback from users before puting them in D1, and having some version
 scheme to indicate when new features are added).


 
 I believe you will find the new CTFE very stable. In implementing the 
 improvements, many structural problems were fixed. It turns out to be a 
 very effective way of diagnosing bugs.
 


Don - can you give an example of how CTFE helps in diagnosing a bug ?
Sep 03 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Sep 3, 2009 at 7:01 PM, Nick B<nick.barbalich gmail.com> wrote:

 Don wrote:

 Leandro Lucarella wrote:

 Walter Bright, el =A03 de septiembre a las 01:16 me escribiste:



 Don't get me wrong, as I stated before, I'm really glad D1 get some new
 features/improvements, I just think the changes should be a little more
 tested before hit D1 (and new aditions to D1 should be more planned, fo=






r

 example, leaving them in D2 for a few releases only, so you can get rea=






l

 feedback from users before puting them in D1, and having some version
 scheme to indicate when new features are added).


 I believe you will find the new CTFE very stable. In implementing the
 improvements, many structural problems were fixed. It turns out to be a =




very

 effective way of diagnosing bugs.


 Don - can you give an example of how CTFE helps in diagnosing a bug ?


I think he means that in implementing the improvements to CTFE's
capabilities, it made other CTFE bugs more obvious and diagnosable.
Sep 03 2009
parent Don <nospam nospam.com> writes:
Jarrett Billingsley wrote:

 On Thu, Sep 3, 2009 at 7:01 PM, Nick B<nick.barbalich gmail.com> wrote:

 Don wrote:

 Leandro Lucarella wrote:

 Walter Bright, el  3 de septiembre a las 01:16 me escribiste:
 Don't get me wrong, as I stated before, I'm really glad D1 get some new
 features/improvements, I just think the changes should be a little more
 tested before hit D1 (and new aditions to D1 should be more planned, for
 example, leaving them in D2 for a few releases only, so you can get real
 feedback from users before puting them in D1, and having some version
 scheme to indicate when new features are added).


 I believe you will find the new CTFE very stable. In implementing the
 improvements, many structural problems were fixed. It turns out to be a very
 effective way of diagnosing bugs.


 Don - can you give an example of how CTFE helps in diagnosing a bug ?


 
 I think he means that in implementing the improvements to CTFE's
 capabilities, it made other CTFE bugs more obvious and diagnosable.


Not just that. It shows up problems in the semantic pass elsewhere in 
the compiler. I've just used it to discover what's wrong with D2 struct 
constructors. To a limited extent, CTFE is like an alternative back-end.
I was talking about compiler bugs, not user bugs, although it does now 
detect a couple of run-time bugs (CTFE will now tell you which line a 
null pointer dereference occurs on).
Sep 04 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Thu, Sep 3, 2009 at 4:16 AM, Walter Bright<newshound1 digitalmars.com> wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip

 Many thanks to the numerous people who contributed to this update.


Oh my god. The "compiler now tells you *why* a function is not
CTFE-able" ALONE is like, man, total show-changer.

Thanks for your, Andrei's, Don's, and all others' work on this update :)
Sep 03 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
Thanks for yet another great release, but.. has anyone else gotten DFL to  
compile? (The latest svn of DFL worked fine in 2.031)

I've been trying to get it up and running but I've been seeing really  
weird errors. It appears in several cases that various import statements  
are not being imported. For example:

     import dfl.menu;
     import dfl.form;

Seems to import the menu classes, but not the form classes. And

     import dfl.form;
     import dfl.menu;

does the opposite.

I tried tracing the issue down (from control.d -> menu.d -> application.d  
-> form.d, testing using dfl.internal.winapi) and it looked like I found a  
single line of code in form.d

version(NO_MDI) {} else {
// commented out source
}

in which a public import dfl.internal.winapi worked above and didn't work  
below. But, when I tried to make a simple test case, everything worked.  
And then when I came back to full source, that test worked too, as did  
form (But that was only because I had publicly imported it from  
application.d & application from menu.d)
Sep 03 2009
next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandford jhu.edu>  
wrote:


 Thanks for yet another great release, but.. has anyone else gotten DFL  
 to compile? (The latest svn of DFL worked fine in 2.031)

 I've been trying to get it up and running but I've been seeing really  
 weird errors. It appears in several cases that various import statements  
 are not being imported. For example:

      import dfl.menu;
      import dfl.form;

 Seems to import the menu classes, but not the form classes. And

      import dfl.form;
      import dfl.menu;

 does the opposite.

 I tried tracing the issue down (from control.d -> menu.d ->  
 application.d -> form.d, testing using dfl.internal.winapi) and it  
 looked like I found a single line of code in form.d

 version(NO_MDI) {} else {
 // commented out source
 }

 in which a public import dfl.internal.winapi worked above and didn't  
 work below. But, when I tried to make a simple test case, everything  
 worked. And then when I came back to full source, that test worked too,  
 as did form (But that was only because I had publicly imported it from  
 application.d & application from menu.d)


With some more hacking, I've gotten it to compile. It appears to be  
something to do in how cyclic (+ private duplicates?) imports are handled.  
I made everything public and then commented out some of the redundant  
imports. The strange thing is that I didn't have to remove all cycles or  
all redundant imports to get it compiling. I did get a less hacked up  
version running (package imports + removed redundancies), but I had to  
turn off drag and drop support in order to get it to compile and swapping  
around certain import statements still causes errors.
Sep 04 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 04 Sep 2009 04:40:51 -0400, Robert Jacques <sandford jhu.edu>  
wrote:


 On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandford jhu.edu>  
 wrote:


 Thanks for yet another great release, but.. has anyone else gotten DFL  
 to compile? (The latest svn of DFL worked fine in 2.031)

 I've been trying to get it up and running but I've been seeing really  
 weird errors. It appears in several cases that various import  
 statements are not being imported. For example:

      import dfl.menu;
      import dfl.form;

 Seems to import the menu classes, but not the form classes. And

      import dfl.form;
      import dfl.menu;

 does the opposite.

 I tried tracing the issue down (from control.d -> menu.d ->  
 application.d -> form.d, testing using dfl.internal.winapi) and it  
 looked like I found a single line of code in form.d

 version(NO_MDI) {} else {
 // commented out source
 }

 in which a public import dfl.internal.winapi worked above and didn't  
 work below. But, when I tried to make a simple test case, everything  
 worked. And then when I came back to full source, that test worked too,  
 as did form (But that was only because I had publicly imported it from  
 application.d & application from menu.d)


 With some more hacking, I've gotten it to compile. It appears to be  
 something to do in how cyclic (+ private duplicates?) imports are  
 handled. I made everything public and then commented out some of the  
 redundant imports. The strange thing is that I didn't have to remove all  
 cycles or all redundant imports to get it compiling. I did get a less  
 hacked up version running (package imports + removed redundancies), but  
 I had to turn off drag and drop support in order to get it to compile  
 and swapping around certain import statements still causes errors.


Well, I got drag and drop working. More importantly, I've manage to make a  
small test case to put into bugzilla:  
http://d.puremagic.com/issues/show_bug.cgi?id=3301
Sep 04 2009
parent Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Robert Jacques Wrote:


 On Fri, 04 Sep 2009 04:40:51 -0400, Robert Jacques <sandford jhu.edu>  
 wrote:
 

 On Thu, 03 Sep 2009 19:45:44 -0400, Robert Jacques <sandford jhu.edu>  
 wrote:


 Thanks for yet another great release, but.. has anyone else gotten DFL  
 to compile? (The latest svn of DFL worked fine in 2.031)

 I've been trying to get it up and running but I've been seeing really  
 weird errors. It appears in several cases that various import  
 statements are not being imported. For example:

      import dfl.menu;
      import dfl.form;

 Seems to import the menu classes, but not the form classes. And

      import dfl.form;
      import dfl.menu;

 does the opposite.

 I tried tracing the issue down (from control.d -> menu.d ->  
 application.d -> form.d, testing using dfl.internal.winapi) and it  
 looked like I found a single line of code in form.d

 version(NO_MDI) {} else {
 // commented out source
 }

 in which a public import dfl.internal.winapi worked above and didn't  
 work below. But, when I tried to make a simple test case, everything  
 worked. And then when I came back to full source, that test worked too,  
 as did form (But that was only because I had publicly imported it from  
 application.d & application from menu.d)


 With some more hacking, I've gotten it to compile. It appears to be  
 something to do in how cyclic (+ private duplicates?) imports are  
 handled. I made everything public and then commented out some of the  
 redundant imports. The strange thing is that I didn't have to remove all  
 cycles or all redundant imports to get it compiling. I did get a less  
 hacked up version running (package imports + removed redundancies), but  
 I had to turn off drag and drop support in order to get it to compile  
 and swapping around certain import statements still causes errors.


 
 Well, I got drag and drop working. More importantly, I've manage to make a  
 small test case to put into bugzilla:  
 http://d.puremagic.com/issues/show_bug.cgi?id=3301



That's quite a serious regression, that needs to be fixed as soon as possible
(maybe even with a special fixing release). I tested QtD and gtkD with dmd
1.047, and both doesn't compile.
Sep 11 2009
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 9/4/09 01:45, Robert Jacques wrote:

 Thanks for yet another great release, but.. has anyone else gotten DFL
 to compile? (The latest svn of DFL worked fine in 2.031)

 I've been trying to get it up and running but I've been seeing really
 weird errors. It appears in several cases that various import statements
 are not being imported. For example:

 import dfl.menu;
 import dfl.form;

 Seems to import the menu classes, but not the form classes. And

 import dfl.form;
 import dfl.menu;

 does the opposite.

 I tried tracing the issue down (from control.d -> menu.d ->
 application.d -> form.d, testing using dfl.internal.winapi) and it
 looked like I found a single line of code in form.d

 version(NO_MDI) {} else {
 // commented out source
 }

 in which a public import dfl.internal.winapi worked above and didn't
 work below. But, when I tried to make a simple test case, everything
 worked. And then when I came back to full source, that test worked too,
 as did form (But that was only because I had publicly imported it from
 application.d & application from menu.d)


I have similar problems with one of my projects. Seems like many import 
statements stop working.

/Jacob Carlborg
Sep 04 2009
prev sibling next sibling parent reply Anders Bergh <anders1 gmail.com> writes:
On Thu, Sep 3, 2009 at 10:16, Walter Bright<newshound1 digitalmars.com> wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip

 Many thanks to the numerous people who contributed to this update.


Why the last for OS X 10.5? You can compile software for 10.5 on 10.6
just like you would compile for 10.4 on 10.5. Are you planning on
using some Snow Leopard-only features?

-- 
Anders Bergh
Sep 06 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Anders Bergh wrote:

 Why the last for OS X 10.5? You can compile software for 10.5 on 10.6
 just like you would compile for 10.4 on 10.5. Are you planning on
 using some Snow Leopard-only features?


Apple apparently changed how the linker works. The 10.5 linker does not 
work as documented, and it took some kludging to get it to work. I doubt 
that changing the kludges to work with 10.6 will continue to work with 10.5.
Sep 06 2009
prev sibling next sibling parent Graham St Jack <graham.stjack internode.on.net> writes:
Its great to see so many bugs being sorted out.

However, I am having all kinds of trouble with "shared", which up until 
now I have been able to fairly easily sidestep. Here is a cut-down 
example of what I am trying to do, which is to have one thread acquiring 
data and passing it on to another thread via a queue which uses 
appropriate synchronization mechanisms to make things thread-safe. The 
data passed through is immutable, so theoretically everything should be 
fine.

This kind of thing is very routine in multi-threaded programs, and should 
be easy to pull off. I find I have to do heaps of nasty casting to get 
past the compiler (the immutable assignment thing is a side issue).

Is there a neater syntax for this? How about being able to say "shared 
immutable class Message {...}" (or just shared or just immutable or just 
const), and then all instances (new, local, parameter, return) would 
automatically be shared and immutable?


class Message {
    int data_;
    this(int value) {
        data_ = value;
    }
    int get() immutable {
        return data_;
    }
}

// queue-like synchronized container
class Queue {
    immutable(Message) msg_;

    this() {
        msg_ = null;
    }

    synchronized void add(immutable(Message) msg) {
        Message * tmp = cast(Message *) &msg_;
        *tmp = cast(Message) msg;
    }
    synchronized immutable(Message) remove() {
        return msg_;
    }
}


int main(string args[]) {
    // pretend to be one thread queueing an object
    auto queue = cast(shared) new Queue();
    auto message = cast(immutable) cast(shared) new Message(1);
    queue.add(message);

    // pretend to be another thread taking the data and working with it
    return queue.remove.get;
}
Sep 06 2009
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Walter Bright wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip
 
 Many thanks to the numerous people who contributed to this update.


You can tell it's a good release when you have to do more than a simple 
merge to get it working with ldc ;)

I've pretty much finished merging dmd 2.032 into ldc, there's one issue 
remaining though. In statement.c, a new function, os_critsecsize() is 
used, which the front end now depends upon. With the function being in 
the back end, the license doesn't permit its inclusion in ldc, which 
prevents me finalizing this merge. If you're reading this Walter, could 
you please release the function under a license which will allow 
inclusion in ldc, or alternatively remove the dependency?

Thanks,

Robert
Sep 07 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Robert Clipsham Wrote:


 You can tell it's a good release when you have to do more than a simple 
 merge to get it working with ldc ;)
 
 I've pretty much finished merging dmd 2.032 into ldc,  ...


Does this mean an official D2 LDC will be coming out shortly?
Sep 07 2009
parent reply Robert Clipsham <robert octarineparrot.com> writes:
Jason House wrote:

 Robert Clipsham Wrote:
 

 You can tell it's a good release when you have to do more than a simple 
 merge to get it working with ldc ;)

 I've pretty much finished merging dmd 2.032 into ldc,  ...


 
 Does this mean an official D2 LDC will be coming out shortly?


Unlikely, sorry. LDC 2 is in a very early alpha state. Currently a 
custom version of druntime compiles (a patch has been submitted), how 
much of it functions correctly remains to be seen. Anything using the GC 
doesn't work as some of the GC code segfaults, and about 90% of phobos 
doesn't compile. How soon LDC 2 appears will more than likely depend on 
if anyone else takes an interest in developing it, I don't have enough 
time to really dig into it and make it a fully functioning D2 compiler 
unfortunately.
Sep 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Clipsham wrote:

 Unlikely, sorry. LDC 2 is in a very early alpha state. Currently a 
 custom version of druntime compiles (a patch has been submitted), how 
 much of it functions correctly remains to be seen. Anything using the GC 
 doesn't work as some of the GC code segfaults, and about 90% of phobos 
 doesn't compile. How soon LDC 2 appears will more than likely depend on 
 if anyone else takes an interest in developing it, I don't have enough 
 time to really dig into it and make it a fully functioning D2 compiler 
 unfortunately.


What's the essential problem?
Sep 08 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
Walter Bright wrote:

 Robert Clipsham wrote:

 Unlikely, sorry. LDC 2 is in a very early alpha state. Currently a 
 custom version of druntime compiles (a patch has been submitted), how 
 much of it functions correctly remains to be seen. Anything using the 
 GC doesn't work as some of the GC code segfaults, and about 90% of 
 phobos doesn't compile. How soon LDC 2 appears will more than likely 
 depend on if anyone else takes an interest in developing it, I don't 
 have enough time to really dig into it and make it a fully functioning 
 D2 compiler unfortunately.


 
 What's the essential problem?


LDC 2 is essentially just LDC (a D1 compiler) with the dmd 2 frontend 
instead of the dmd 1 frontend. As you can imagine this leaves quite a 
lot of what's passed to LDC unhandled or handled the way it would be in 
D1 instead of D2 (leading to bad codegen, probably the reason the GC 
segfaults, yet to investigate that though). I'm also pretty sure some of 
the frontend still needs tweaking so it passes what ldc is expecting to 
it rather than what the dm backend expects.

When LDC 2 starts making some progress I'll try and put a patch together 
for you to simplify merges for us, I'll let you know if there's anything 
else you can do to aid development as we progress :)
Sep 08 2009
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
Robert Clipsham wrote:

 Walter Bright wrote:

 This will probably be the last OSX 10.5 release, the next should be 10.6.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.047.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.032.zip

 Many thanks to the numerous people who contributed to this update.


 
 You can tell it's a good release when you have to do more than a simple 
 merge to get it working with ldc ;)
 
 I've pretty much finished merging dmd 2.032 into ldc, there's one issue 
 remaining though. In statement.c, a new function, os_critsecsize() is 
 used, which the front end now depends upon. With the function being in 
 the back end, the license doesn't permit its inclusion in ldc, which 
 prevents me finalizing this merge. If you're reading this Walter, could 
 you please release the function under a license which will allow 
 inclusion in ldc, or alternatively remove the dependency?
 
 Thanks,
 
 Robert


Actually, never mind, Tomas informed me how to do the same thing using 
LDCs code, just #if'd around it.
Sep 08 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Clipsham wrote:

 You can tell it's a good release when you have to do more than a simple 
 merge to get it working with ldc ;)


I try to simplify things in the back end by moving more to the front end.


 I've pretty much finished merging dmd 2.032 into ldc, there's one issue 
 remaining though. In statement.c, a new function, os_critsecsize() is 
 used, which the front end now depends upon. With the function being in 
 the back end, the license doesn't permit its inclusion in ldc, which 
 prevents me finalizing this merge. If you're reading this Walter, could 
 you please release the function under a license which will allow 
 inclusion in ldc, or alternatively remove the dependency?


All it does is return a compile time constant. I don't think anyone 
could make a case out of that.
Sep 08 2009
parent Robert Clipsham <robert octarineparrot.com> writes:
Walter Bright wrote:

 Robert Clipsham wrote:

 You can tell it's a good release when you have to do more than a 
 simple merge to get it working with ldc ;)


 
 I try to simplify things in the back end by moving more to the front end.


Sounds like a good philosophy to me.


 All it does is return a compile time constant. I don't think anyone 
 could make a case out of that.


I thought I better check anyway, you never know :) Doesn't matter too 
much now anyway, turns out the LDC backend had something similar to 
handle it.
Sep 08 2009