This is the first release in a while that hasn't broken any of my code.
Yay!

It broke one thing in mine...but that's just because I was accidentally
doing something that violated immutable and DMD didn't catch it until now.
So "Yay!" from here, too :)

Actually I had one little problem, that outdated Gdi32 import lib. I
quickly replaced it with a new one though. I hope we can start putting
newer import libs into future DMD releases, there are several projects
out there that depend on it (DGUI and maybe even DWT, I think they
both distribute import libs).

Great release :)
Although it's not in the changelog (I didn't even think to check for it
there until now), there's a bunch of RDMD issues fixed too:
------------------------------------------------
https://github.com/D-Programming-Language/tools/pull/14 (Don't pass .di
files to DMD.)
This fixes a problem that frequently made RDMD fail to work on projects that
import a static lib and .di files. Real-world examples of the problem are
here:
http://www.dsource.org/forums/viewtopic.php?t=5856http://www.linuxquestions.org/questions/programming-9/d-is-d-programming-language-just-too-much-898862/#post4452127
------------------------------------------------
https://github.com/D-Programming-Language/tools/pull/14 (rdmd fixes)
This is killer pull request from CyberShadow, improving a number of things:
- Fixes usage of rdmd by multiple users on the same Posix system.
- Using --build-only, by default, places the exe in the current directory
rather than the usual tmp directory. The --build-only option is frequently
(always, AFAIK) used like an alternate to bud/rebuild/xfbuild/etc, so this
default makes much more sense.
- RDMD should now work within VisualD
- Don't append a second extension to -of path on Windows
- A couple of things that had been fixed in an old pre-github patch, but
failed to get applied correctly (thank god we're on github now!!):
1. Don't mistake .map filenames as the .d file to build.
2. Don't use std.getopt.config.stopOnFirstNonOption. As CyberShadow says:
"rdmd already scans the command line to find the point where option parsing
should stop. Including this getopt option breaks using rdmd with e.g.
DMD's -map option."

- Using --build-only, by default, places the exe in the current directory
rather than the usual tmp directory. The --build-only option is
frequently (always, AFAIK) used like an alternate to
bud/rebuild/xfbuild/etc

Yep, build-only should be the default! And running the exe afterwards an
option.

It's Andrei that manages the site, whereas Walter does the dmd release, and
it's been less than 3 hours since the release, so I expect that Andrei hasn't
had the chance to update the site yet.
- Jonathan M Davis

It's Andrei that manages the site, whereas Walter does the dmd release, and
it's been less than 3 hours since the release, so I expect that Andrei hasn't
had the chance to update the site yet.
- Jonathan M Davis

Yeh, a simple app I've written has gone from 514k to 1098k in release.
Where has
all the extra 'goodness' come from :-O

Take a look at the .map file (run dmc with -map). It'll tell you where the
size
comes from.

This is the only section that seem to have a big difference in length:
2.055:
Length Name Class
00071CAEH _TEXT CODE 32-bit
2.056:
Length Name Class
00101A1AH _TEXT CODE 32-bit
Other than that, 2.056 actually creates fewer symbols than 2.055.

Yeh, a simple app I've written has gone from 514k to 1098k in release.
Where has
all the extra 'goodness' come from :-O

Take a look at the .map file (run dmc with -map). It'll tell you where the
size
comes from.

This is the only section that seem to have a big difference in length:
2.055:
Length Name Class
00071CAEH _TEXT CODE 32-bit
2.056:
Length Name Class
00101A1AH _TEXT CODE 32-bit
Other than that, 2.056 actually creates fewer symbols than 2.055.

Interesting..
If I compile my app via dmd myapp.d <dependencies.lib> I get a 2.149 KB exe.
If instead I do "dmd -c myapp.d" and then do "dmd myapp.obj
<dependencies.lib> I get a 1.117KB exe. That's kind of odd.
If I use Unilink to link the app object file to the dependencies I get
a 340Kb working exe. Now that's something!

Impressive as always. I noticed there seem to be a couple of D2 related
fixes in the D1 changelog:
Bugzilla 6073: Cannot pass __traits(parent, ...) as a template parameter
if it is a module
Then there are a couple of fixes related to regressions for D2, don't
know if they apply to D1 as well, just look for Regression(2.0xy).
--
/Jacob Carlborg

Impressive as always. I noticed there seem to be a couple of D2 related
fixes in the D1 changelog:
Bugzilla 6073: Cannot pass __traits(parent, ...) as a template parameter
if it is a module
Then there are a couple of fixes related to regressions for D2, don't
know if they apply to D1 as well, just look for Regression(2.0xy).

They do apply. In every case, some code was modified on the D1 compiler.
Not all of the test cases apply to D1 though (sometimes there are bugs
in the compiler internals, where we don't have a D1 test case that
triggers them).

They do apply. In every case, some code was modified on the D1 compiler. Not
all
of the test cases apply to D1 though (sometimes there are bugs in the compiler
internals, where we don't have a D1 test case that triggers them).

Just to chime in, whenever I fix a bug in D2 I check to see if it is applicable
to D1, and merge the patch into D1 if it is.

Impressive as always. I noticed there seem to be a couple of D2 related
fixes in the D1 changelog:
Bugzilla 6073: Cannot pass __traits(parent, ...) as a template parameter
if it is a module
Then there are a couple of fixes related to regressions for D2, don't
know if they apply to D1 as well, just look for Regression(2.0xy).

They do apply. In every case, some code was modified on the D1 compiler.
Not all of the test cases apply to D1 though (sometimes there are bugs
in the compiler internals, where we don't have a D1 test case that
triggers them).

I'm only saddened that my std.socket cleanup pull request[1] wasn't
merged, despite being ready for merging for over a month of inactivity.
That's a few more months for my open-source network code not building with
a stock DMD. Oh well, I guess I'll move the new std.socket to my network
library if it comes to that.
[1]: https://github.com/D-Programming-Language/phobos/pull/260
--
Best regards,
Vladimir mailto:vladimir thecybershadow.net

I'm only saddened that my std.socket cleanup pull request[1] wasn't merged,
despite being ready for merging for over a month of inactivity. That's a few
more months for my open-source network code not building with a stock DMD. Oh
well, I guess I'll move the new std.socket to my network library if it comes to
that.
[1]: https://github.com/D-Programming-Language/phobos/pull/260

Sorry about that. There are still a lot of great outstanding pull requests.
There's nothing dramatic that marked this release, it's simply that enough was
pulled to justify putting out a release.

I'm only saddened that my std.socket cleanup pull request[1] wasn't
merged,
despite being ready for merging for over a month of inactivity. That's
a few
more months for my open-source network code not building with a stock
DMD. Oh
well, I guess I'll move the new std.socket to my network library if it
comes to
that.
[1]: https://github.com/D-Programming-Language/phobos/pull/260

Sorry about that. There are still a lot of great outstanding pull
requests. There's nothing dramatic that marked this release, it's simply
that enough was pulled to justify putting out a release.

I'm only saddened that my std.socket cleanup pull request[1] wasn't
merged, despite being ready for merging for over a month of inactivity.
That's a few more months for my open-source network code not building
with a stock DMD. Oh well, I guess I'll move the new std.socket to my
network library if it comes to that.
[1]: https://github.com/D-Programming-Language/phobos/pull/260