dmd 1.048 and 2.033 releases
Another OSX 10.5 release :-) Anyhow, this should work with gdb now, and has contract inheritance (finally). http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.048.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.033.zip Many thanks to the numerous people who contributed to this update.
Re: dmd 1.048 and 2.033 releases
Walter Bright newshou...@digitalmars.com wrote in message news:hac8nb$26j...@digitalmars.com... Another OSX 10.5 release :-) Anyhow, this should work with gdb now, and has contract inheritance (finally). http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.048.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.033.zip Many thanks to the numerous people who contributed to this update. Compiler now detects some cases of illegal null dereferencing when compiled with -O A bug-detection feature that's turned on with -O? I assume that's just a temporary situation and is related to either it currently being detected by the optimizer and the feature maybe being in a trial phase? Or maybe just a typo? ;)
Re: dmd 1.048 and 2.033 releases
On Mon, 05 Oct 2009 14:23:26 +0400, Nick Sabalausky a...@a.a wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:hac8nb$26j...@digitalmars.com...
Another OSX 10.5 release :-)
Anyhow, this should work with gdb now, and has contract inheritance
(finally).
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.048.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.033.zip
Many thanks to the numerous people who contributed to this update.
Compiler now detects some cases of illegal null dereferencing when
compiled
with -O
A bug-detection feature that's turned on with -O? I assume that's just a
temporary situation and is related to either it currently being detected
by
the optimizer and the feature maybe being in a trial phase? Or maybe
just
a typo? ;)
No, it's not:
void main() {
Object o;
o.toString();
}
# dmd test.d // fine
# dmd test.d -O // test.d(4): Error: null dereference in function _Dmain
(mangled name, is it done on purpose?)
Nice start, anyway, I'm looking forward to having a complete code flow
analysis soon :)
Re: dmd 1.048 and 2.033 releases
Can someone show an usage example of contract inheritance? (where inheritance
is useful).
Regarding the fixed bugs 2702 and 2469, I'm having problems still, at the
bottom y is 0:
import std.stdio: writeln;
import std.conv: to;
struct Ranged(int RANGED_MIN, int RANGED_MAX) {
int x_ = RANGED_MIN;
int x() { return this.x_; }
int x(int xx) { this.x_ = xx; return xx; }
alias x this;
invariant() {
//assert(this.x_ = RANGED_MIN, Ranged value too much small);
assert(this.x_ RANGED_MAX, Ranged value too much big);
}
//Ranged opCast(int xx) { return Ranged(xx); }
string toString() { return to!string(this.x_); }
}
void main() {
typedef Ranged!(10, 20) ranged;
ranged x;
writeln(x);
//ranged y = 1000; // temp.d(23): Error: cannot implicitly convert
expression (1000) of type int to ranged
ranged y = cast(ranged)100;
writeln(y); // 0?
}
Bye,
bearophile
Re: dmd 1.048 and 2.033 releases
On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright newshou...@digitalmars.com wrote: Another OSX 10.5 release :-) Anyhow, this should work with gdb now, and has contract inheritance (finally). http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.048.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.033.zip Many thanks to the numerous people who contributed to this update. Excellent work! It looks like a lot of mundane bugs are getting fixed, which is a good sign :) A couple questions: 1. The result type of the typeid(type) is now the most derived TypeInfo class, rather than the TypeInfo base class Why can't this be propogated to D1? I can't imagine code that depends on the return value being typed as TypeInfo that would not simply just work with the most derived return type... 2. A while ago, (I can't find the post, it may have been on reddit) you mentioned that you were going to add property notation. Is that still going to happen? I'm really looking forward to that, and if not, is there a reason? -Steve
Re: dmd 1.048 and 2.033 releases
On Mon, 05 Oct 2009 16:55:49 +0400, Jacob Carlborg d...@me.com wrote:
On 10/5/09 13:49, Steven Schveighoffer wrote:
On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Another OSX 10.5 release :-)
Anyhow, this should work with gdb now, and has contract inheritance
(finally).
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.048.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.033.zip
Many thanks to the numerous people who contributed to this update.
Excellent work! It looks like a lot of mundane bugs are getting fixed,
which is a good sign :)
A couple questions:
1. The result type of the typeid(type) is now the most derived TypeInfo
class, rather than the TypeInfo base class Why can't this be propogated
to D1? I can't imagine code that depends on the return value being typed
as TypeInfo that would not simply just work with the most derived return
type...
2. A while ago, (I can't find the post, it may have been on reddit) you
mentioned that you were going to add property notation. Is that still
going to happen? I'm really looking forward to that, and if not, is
there a reason?
There are some traces of it in the code:
http://www.dsource.org/projects/dmd/changeset/195 search for property.
-Steve
int bar() @property
{
return 42;
}
writeln(bar);
Yay! :)
Re: dmd 1.048 and 2.033 releases
On Mon, 05 Oct 2009 09:12:32 -0400, Denis Koroskin 2kor...@gmail.com
wrote:
On Mon, 05 Oct 2009 16:55:49 +0400, Jacob Carlborg d...@me.com wrote:
On 10/5/09 13:49, Steven Schveighoffer wrote:
On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Another OSX 10.5 release :-)
Anyhow, this should work with gdb now, and has contract inheritance
(finally).
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.048.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.033.zip
Many thanks to the numerous people who contributed to this update.
Excellent work! It looks like a lot of mundane bugs are getting fixed,
which is a good sign :)
A couple questions:
1. The result type of the typeid(type) is now the most derived
TypeInfo
class, rather than the TypeInfo base class Why can't this be
propogated
to D1? I can't imagine code that depends on the return value being
typed
as TypeInfo that would not simply just work with the most derived
return
type...
2. A while ago, (I can't find the post, it may have been on reddit) you
mentioned that you were going to add property notation. Is that still
going to happen? I'm really looking forward to that, and if not, is
there a reason?
There are some traces of it in the code:
http://www.dsource.org/projects/dmd/changeset/195 search for property.
-Steve
int bar() @property
{
return 42;
}
writeln(bar);
Yay! :)
Cool :)
Unfortunately, this still compiles :(
int bar()
{
return 42;
}
writeln(%d, bar);
And this too:
int bar() @property
{
return 42;
}
writeln(%d, bar());
So it appears that @property is a noop for now, but is valid syntax.
Also interesting from this revelation is that attributes are coming :D
int bar() @blah
{
return 42;
}
#../dmd-2.033/linux/bin/dmd -w testme.d
testme.d(8): valid attribute identifiers are property, not blah
-Steve
Re: DMD svn and contract inheritance
Walter Bright Wrote: It's outlined in the code comments, but it's implemented by making the contract code a nested function. The overriding function calls those nested functions of the overridden function(s). In order for this to work successfully, the 'this' pointer and the stack parameters must wind up in the same relative position on the stack. 'this' pointer could be passed as a regular argument just like stack pointer.
Re: dmd 1.048 and 2.033 releases
On 10/5/09 15:46, Steven Schveighoffer wrote:
On Mon, 05 Oct 2009 09:12:32 -0400, Denis Koroskin 2kor...@gmail.com
wrote:
On Mon, 05 Oct 2009 16:55:49 +0400, Jacob Carlborg d...@me.com wrote:
On 10/5/09 13:49, Steven Schveighoffer wrote:
On Mon, 05 Oct 2009 03:54:22 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Another OSX 10.5 release :-)
Anyhow, this should work with gdb now, and has contract inheritance
(finally).
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.048.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.033.zip
Many thanks to the numerous people who contributed to this update.
Excellent work! It looks like a lot of mundane bugs are getting fixed,
which is a good sign :)
A couple questions:
1. The result type of the typeid(type) is now the most derived
TypeInfo
class, rather than the TypeInfo base class Why can't this be
propogated
to D1? I can't imagine code that depends on the return value being
typed
as TypeInfo that would not simply just work with the most derived
return
type...
2. A while ago, (I can't find the post, it may have been on reddit) you
mentioned that you were going to add property notation. Is that still
going to happen? I'm really looking forward to that, and if not, is
there a reason?
There are some traces of it in the code:
http://www.dsource.org/projects/dmd/changeset/195 search for property.
-Steve
int bar() @property
{
return 42;
}
writeln(bar);
Yay! :)
Cool :)
Unfortunately, this still compiles :(
int bar()
{
return 42;
}
writeln(%d, bar);
And this too:
int bar() @property
{
return 42;
}
writeln(%d, bar());
So it appears that @property is a noop for now, but is valid syntax.
Also interesting from this revelation is that attributes are coming :D
I just hope that they also will be user defined.
int bar() @blah
{
return 42;
}
#../dmd-2.033/linux/bin/dmd -w testme.d
testme.d(8): valid attribute identifiers are property, not blah
-Steve
Re: dmd 1.048 and 2.033 releases
Jacob Carlborg, el 5 de octubre a las 16:08 me escribiste:
2. A while ago, (I can't find the post, it may have been on reddit) you
mentioned that you were going to add property notation. Is that still
going to happen? I'm really looking forward to that, and if not, is
there a reason?
There are some traces of it in the code:
http://www.dsource.org/projects/dmd/changeset/195 search for property.
-Steve
int bar() @property
{
return 42;
}
writeln(bar);
Yay! :)
Cool :)
Unfortunately, this still compiles :(
int bar()
{
return 42;
}
writeln(%d, bar);
And this too:
int bar() @property
{
return 42;
}
writeln(%d, bar());
So it appears that @property is a noop for now, but is valid syntax.
Also interesting from this revelation is that attributes are coming :D
I just hope that they also will be user defined.
Ok, this is getting interesting... 8-)
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Dentro de 30 años Argentina va a ser un gran supermercado con 15
changuitos, porque esa va a ser la cantidad de gente que va a poder
comprar algo.
-- Sidharta Wiki
Re: dmd 1.048 and 2.033 releases
Steven Schveighoffer:
Also interesting from this revelation is that attributes are coming :D
Despite all, it seems sometimes Walter listens :-)
Maybe this syntax will be allowed (attribute before instead of after function
name):
@property int bar() {...
Bye,
bearophile
Re: dmd 1.048 and 2.033 releases
Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hac8nb$26j...@digitalmars.com... Another OSX 10.5 release :-) Anyhow, this should work with gdb now, and has contract inheritance (finally). http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.048.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.033.zip Many thanks to the numerous people who contributed to this update. Compiler now detects some cases of illegal null dereferencing when compiled with -O A bug-detection feature that's turned on with -O? I assume that's just a temporary situation and is related to either it currently being detected by the optimizer and the feature maybe being in a trial phase? Or maybe just a typo? ;) Somewhere in the huge thread(s) on the topic Walter mentioned the optimizer does (some of) the required flow analysis, so presumably it needs to run in order for this to work.
Re: dmd 1.048 and 2.033 releases
Nick Sabalausky wrote: Compiler now detects some cases of illegal null dereferencing when compiled with -O A bug-detection feature that's turned on with -O? I assume that's just a temporary situation and is related to either it currently being detected by the optimizer and the feature maybe being in a trial phase? Or maybe just a typo? ;) No, it's deliberate. Turns out, in order for it to work reliably and not give false positives, it needs the full attention of the optimizer. Otherwise, you get false positives like: int* p = null; ... if (p) *p = 7;
Re: dmd 1.048 and 2.033 releases
Steven Schveighoffer wrote: 1. The result type of the typeid(type) is now the most derived TypeInfo class, rather than the TypeInfo base class Why can't this be propogated to D1? I can't imagine code that depends on the return value being typed as TypeInfo that would not simply just work with the most derived return type... Changing the spec constantly for D1 makes it not stable. 2. A while ago, (I can't find the post, it may have been on reddit) you mentioned that you were going to add property notation. Is that still going to happen? I'm really looking forward to that, and if not, is there a reason? It's high on the list, it's just that there were some important improvements that I felt should be released now rather than holding them back.
Re: dmd 1.048 and 2.033 releases
#ponce wrote: I think it's disabled in debug mode to keep the compilation time low. That, and the optimizer tends to scramble the relationship between source and assembler, making source debugging next to impossible. I guess it's more expensive CPU-wise than escape analysis which is done in both modes. So it seems the right thing to do for me.
Re: DMD svn and contract inheritance
Leandro Lucarella wrote: Thanks for finally taking this way, Walter =) http://www.dsource.org/projects/dmd/timeline Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for Nightly builds and maybe even post the results to the D newsgroups/IRC channels. If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you.
Re: dmd 1.048 and 2.033 releases
Walter Bright newshou...@digitalmars.com wrote in message news:hadbml$1mb...@digitalmars.com... Nick Sabalausky wrote: Compiler now detects some cases of illegal null dereferencing when compiled with -O A bug-detection feature that's turned on with -O? I assume that's just a temporary situation and is related to either it currently being detected by the optimizer and the feature maybe being in a trial phase? Or maybe just a typo? ;) No, it's deliberate. Turns out, in order for it to work reliably and not give false positives, it needs the full attention of the optimizer. Otherwise, you get false positives like: int* p = null; ... if (p) *p = 7; I see, but is that just a temporary situation? I'm fine with it for now, but optimizers are known for conflicting with debugging, so in the long run I'd hate to have to split my debug builds into separate maximum static analysis vs debuggable builds (I already had been forced to split my debug builds into separate debug with warnings and debug without warnings builds, which was a real pain in the ass until I started hacking in that optionally treat warnings as warnings patch...but I've had to temporarily abandon use of even that since I'm working on a multi-build-version tool, used by some projects I've released, and none of those should have to be reliant on a feature that only exists in a custom build of DMD).
Re: dmd 1.048 and 2.033 releases
Hello Walter, #ponce wrote: I think it's disabled in debug mode to keep the compilation time low. That, and the optimizer tends to scramble the relationship between source and assembler, making source debugging next to impossible. How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file?
Re: dmd 1.048 and 2.033 releases
Nick Sabalausky wrote: I see, but is that just a temporary situation? I'm fine with it for now, but optimizers are known for conflicting with debugging, so in the long run I'd hate to have to split my debug builds into separate maximum static analysis vs debuggable builds (I already had been forced to split my debug builds into separate debug with warnings and debug without warnings builds, which was a real pain in the ass until I started hacking in that optionally treat warnings as warnings patch...but I've had to temporarily abandon use of even that since I'm working on a multi-build-version tool, used by some projects I've released, and none of those should have to be reliant on a feature that only exists in a custom build of DMD). Just build your releases with -O.
Re: dmd 1.048 and 2.033 releases
BCS wrote: Hello Walter, #ponce wrote: I think it's disabled in debug mode to keep the compilation time low. That, and the optimizer tends to scramble the relationship between source and assembler, making source debugging next to impossible. How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file? It seems even easier to just compile with -0.
Re: DMD svn and contract inheritance
Robert Clipsham wrote: Leandro Lucarella wrote: Thanks for finally taking this way, Walter =) http://www.dsource.org/projects/dmd/timeline Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for Nightly builds and maybe even post the results to the D newsgroups/IRC channels. If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you. The problem is if some package fails, then I have a large debugging problem trying to figure out unfamiliar code.
Re: dmd 1.048 and 2.033 releases
bearophile wrote: Steven Schveighoffer: Also interesting from this revelation is that attributes are coming :D Despite all, it seems sometimes Walter listens :-) Wow, indeed he does. :-D
Re: dmd 1.048 and 2.033 releases
Nick Sabalausky a...@a.a wrote in message news:hadst9$58...@digitalmars.com... Walter Bright newshou...@digitalmars.com wrote in message news:hadqcs$30n...@digitalmars.com... BCS wrote: Hello Walter, #ponce wrote: I think it's disabled in debug mode to keep the compilation time low. That, and the optimizer tends to scramble the relationship between source and assembler, making source debugging next to impossible. How hard would it be to have the code generate run on the unoptimized code and then do the optimizer backed test and only if no bugs jump out, move the results into the object file? It seems even easier to just compile with -0. It isn't. *Very* typical workflow: [stuff] None of those are particularly good options, and I don't see any other possibilities. ...Plus it's just plain unintuitive.
Re: DMD svn and contract inheritance
Walter Bright Wrote: Robert Clipsham wrote: Leandro Lucarella wrote: Thanks for finally taking this way, Walter =) http://www.dsource.org/projects/dmd/timeline Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for Nightly builds and maybe even post the results to the D newsgroups/IRC channels. If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you. The problem is if some package fails, then I have a large debugging problem trying to figure out unfamiliar code. With small commits to dmd, it should be trivial to know what small change in dmd caused a user observable change in behavior. If things look good on the dmd side, I'd really hope the code authors would help with debugging their code. Knowing of a failure within an hour is way better than finding out a month later. BTW, such regression tests work much better when all failing tests can be identified. It can help with figuring out patterns. Stopping on the first failure can be somewhat limiting, especially if the failure will stick around for a week.
Re: DMD svn and contract inheritance
Jason House wrote: Walter Bright Wrote: Robert Clipsham wrote: Leandro Lucarella wrote: Thanks for finally taking this way, Walter =) http://www.dsource.org/projects/dmd/timeline Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for Nightly builds and maybe even post the results to the D newsgroups/IRC channels. If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you. The problem is if some package fails, then I have a large debugging problem trying to figure out unfamiliar code. With small commits to dmd, it should be trivial to know what small change in dmd caused a user observable change in behavior. If things look good on the dmd side, I'd really hope the code authors would help with debugging their code. Knowing of a failure within an hour is way better than finding out a month later. BTW, such regression tests work much better when all failing tests can be identified. It can help with figuring out patterns. Stopping on the first failure can be somewhat limiting, especially if the failure will stick around for a week. We clearly can't define the language around a best-effort kind of flow analysis. I consider Walter's extra checks during optimization a nice perk, but definitely not something we can consider a part of the language. The language definition must work without those. Andrei
Re: dmd 1.048 and 2.033 releases
On Mon, 05 Oct 2009 10:54:22 +0300, Walter Bright newshou...@digitalmars.com wrote: gdb stack trace should work now Could someone please elaborate on this a bit (what exactly was changed), or at least point to the respective SVN revision or something? -- Best regards, Vladimir mailto:thecybersha...@gmail.com
Re: DMD svn and contract inheritance
Andrei Alexandrescu, el 5 de octubre a las 19:17 me escribiste: Jason House wrote: Walter Bright Wrote: Robert Clipsham wrote: Leandro Lucarella wrote: Thanks for finally taking this way, Walter =) http://www.dsource.org/projects/dmd/timeline Now that DMD is under version control it should be fairly easy for me to adapt the automated build system used for ldc for dmd. I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries, even package up dmd for Nightly builds and maybe even post the results to the D newsgroups/IRC channels. If you'd be interested to see this Walter, let me know what exactly you want automating/how and where you want results and I'll see about setting it up for you. The problem is if some package fails, then I have a large debugging problem trying to figure out unfamiliar code. With small commits to dmd, it should be trivial to know what small change in dmd caused a user observable change in behavior. If things look good on the dmd side, I'd really hope the code authors would help with debugging their code. Knowing of a failure within an hour is way better than finding out a month later. BTW, such regression tests work much better when all failing tests can be identified. It can help with figuring out patterns. Stopping on the first failure can be somewhat limiting, especially if the failure will stick around for a week. We clearly can't define the language around a best-effort kind of flow analysis. I consider Walter's extra checks during optimization a nice perk, but definitely not something we can consider a part of the language. The language definition must work without those. I guess you answered to the wrong mail, Jason is talking about Robert's offering to set up a build/test bot for DMD, to build and test each commit, using dstress and maybe other popular libraries/programs. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- When I was a child I had a fever My hands felt just like two balloons. Now I've got that feeling once again I can't explain you would not understand This is not how I am. I have become comfortably numb.
Re: DMD svn and contract inheritance
Jason House wrote: With small commits to dmd, it should be trivial to know what small change in dmd caused a user observable change in behavior. The problem is, one doesn't know if it is a problem with the change or if it is a problem with the user code. To determine that requires working with and understanding the user code. It's just impractical for me to do that with a large base of code like that. If things look good on the dmd side, I'd really hope the code authors would help with debugging their code. Knowing of a failure within an hour is way better than finding out a month later. BTW, such regression tests work much better when all failing tests can be identified. It can help with figuring out patterns. Stopping on the first failure can be somewhat limiting, especially if the failure will stick around for a week.
Re: dmd 1.048 and 2.033 releases
Vladimir Panteleev wrote: On Mon, 05 Oct 2009 10:54:22 +0300, Walter Bright newshou...@digitalmars.com wrote: gdb stack trace should work now Could someone please elaborate on this a bit (what exactly was changed), or at least point to the respective SVN revision or something? All the changes are in dwarf.c.
Re: dmd 1.048 and 2.033 releases
Denis Koroskin wrote:
snip
int bar() @property
{
return 42;
}
What is @ going to be used for generally? (What is the essential
difference between an attribute that's an @word and one that's a simple
keyword before or after the type?)
Stewart.
Re: DMD svn and contract inheritance
Hello Walter, I can set it up to automatically build dmd after a commit, and run dstress/build popular projects and libraries The problem is if some package fails, then I have a large debugging problem trying to figure out unfamiliar code. Or it could just inform the owner of the lib and they can cut out a test cases or even do most of the detective work for you.
Re: dmd 1.048 and 2.033 releases
Which gdb should this release work with? I seem to have misplaced my patched gdb. The standard gdb 6.8 can show backtraces but can't list code, even if the code is linked in libraries from C++. Walter Bright wrote: Another OSX 10.5 release :-) Anyhow, this should work with gdb now, and has contract inheritance (finally). http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.048.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.033.zip Many thanks to the numerous people who contributed to this update.
