Re: dmd 2.057 release
On 2012-01-03 20:46, Nick Sabalausky wrote: Alex Rønne Petersenxtzgzo...@gmail.com wrote in message news:jdviuj$16e$1...@digitalmars.com... On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betasg. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. I don't remember if this feature has made it into a formal DVM release yet or not, but it's been in the main DVM master branch for awhile: git clone https://github.com/D-Programming-Language/dmd.git git clone https://github.com/D-Programming-Language/druntime.git git clone https://github.com/D-Programming-Language/phobos.git git clone https://github.com/D-Programming-Language/tools.git # for RDMD dvm compile ./dmd/bin32/dmd # or ./dmd/bin64/dmd No, it's not in a release yet, sorry. But I can make one. I was hoping to make DVM download the source from github automatically but I haven't had time to implement that yet. I've been focused on other projects lately. -- /Jacob Carlborg
Re: dmd 2.057 release
On 2012-01-04 00:02, Sean Cavanaugh wrote: On 1/3/2012 1:25 PM, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. Well there is always the google (and mozilla) route of force-feeding the latest binaries to everyone :) They don't install nightly builds, do they? -- /Jacob Carlborg
Re: dmd 2.057 release
Chrome and Firefox both have several different auto updating versions. For Chrome there's stable, beta, dev channel, and canary (which is basically a nightly build). So there are lots of opportunities for bugs to be found by developers before they go live in the stable release channel. --bb Sent from my Android. On Jan 4, 2012 1:43 AM, Jacob Carlborg d...@me.com wrote: On 2012-01-04 00:02, Sean Cavanaugh wrote: On 1/3/2012 1:25 PM, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. Well there is always the google (and mozilla) route of force-feeding the latest binaries to everyone :) They don't install nightly builds, do they? -- /Jacob Carlborg
Re: dmd 2.057 release
On 03-01-2012 08:49, Caligo wrote: Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months? Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. - Alex
Re: dmd 2.057 release
On 03/01/2012 14:49, Alex Rønne Petersen wrote: On 03-01-2012 08:49, Caligo wrote: Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months? Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. - Alex Beta releases are made weeks before an actual release for testing on this mailing list: http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta Web interface: http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta -- Robert http://octarineparrot.com/
Re: dmd 2.057 release
On 03-01-2012 15:56, Robert Clipsham wrote: On 03/01/2012 14:49, Alex Rønne Petersen wrote: On 03-01-2012 08:49, Caligo wrote: Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months? Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. - Alex Beta releases are made weeks before an actual release for testing on this mailing list: http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta Web interface: http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta I mean something weekly or bi-weekly. Beta releases are only made very close to the actual release. - Alex
Re: dmd 2.057 release
On 03.01.2012 16:07, Alex Rønne Petersen wrote: On 03-01-2012 15:56, Robert Clipsham wrote: On 03/01/2012 14:49, Alex Rønne Petersen wrote: On 03-01-2012 08:49, Caligo wrote: Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months? Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. - Alex Beta releases are made weeks before an actual release for testing on this mailing list: http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta Web interface: http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta I mean something weekly or bi-weekly. Beta releases are only made very close to the actual release. - Alex I just asked about this in D, but as there is a discussion here already: The auto-tester builds dmd++, why not let the latest binary that successfully passed the tests be available for download?
Re: dmd 2.057 release
On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do.
Re: dmd 2.057 release
On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. - Alex
Re: dmd 2.057 release
On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group.
Re: dmd 2.057 release
On 03-01-2012 20:25, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. I don't know. There are many things in DMD that are far from bug-free, and some people would like to actually use those features. So when fixes are committed, it'd be nice to just be able to switch to a nightly build. We have to bear in mind that while D itself is fairly mature, it is still very much an evolving language, and thus, as is the compiler. For this reason, sticking to a stable release is not always practical. - Alex
Re: dmd 2.057 release
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message news:jdviuj$16e$1...@digitalmars.com... On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. I don't remember if this feature has made it into a formal DVM release yet or not, but it's been in the main DVM master branch for awhile: git clone https://github.com/D-Programming-Language/dmd.git git clone https://github.com/D-Programming-Language/druntime.git git clone https://github.com/D-Programming-Language/phobos.git git clone https://github.com/D-Programming-Language/tools.git # for RDMD dvm compile ./dmd/bin32/dmd # or ./dmd/bin64/dmd DMD32 D Compiler v2.0... ...etc... Of course, that completely ignores the results of the auto-tester. As others suggested, the auto-tester publishing builds for download would be ideal. - Alex
Re: dmd 2.057 release
On 1/3/2012 1:25 PM, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. Well there is always the google (and mozilla) route of force-feeding the latest binaries to everyone :)
Re: dmd 2.057 release
On Tue, Jan 3, 2012 at 5:02 PM, Sean Cavanaugh worksonmymach...@gmail.com wrote: On 1/3/2012 1:25 PM, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. Well there is always the google (and mozilla) route of force-feeding the latest binaries to everyone :) They can get away with that because their users don't really care about versions. As long as Chrome starts and browses when I want it to, I don't care whether Google pushes updates out behind my back. Development tools are a different game because versions introduce breaking changes and silently changing versions will just create a horde of angry developers.
Re: dmd 2.057 release
Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months?
Re: dmd 2.057 release
Jonathan M Davis:
On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
...
Regardless, the compiler shouldn't be ICEing though.
Is it in Bugzilla?
Bye,
bearophile
Re: dmd 2.057 release
On Saturday, 17 December 2011 at 11:02:41 UTC, bearophile wrote:
Jonathan M Davis:
On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
...
Regardless, the compiler shouldn't be ICEing though.
Is it in Bugzilla?
Bye,
bearophile
Looks to be the same issue as
http://d.puremagic.com/issues/show_bug.cgi?id=4414
Re: dmd 2.057 release
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
wrote:
Highlights are use of XMM floating point registers in 64 bit
targets, and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best
release ever. Thanks!
I found a bug when slicing static arrays. It's not new to 2.057
but I totally forgot about it (my bad) and didn't simplify a test
case.
auto x() {
ubyte[4] a;
return a;
}
auto y() {
return x()[1..$];
}
void main() {
y();
}
Gives:
Internal error: ..\ztc\cgcs.c 354
Is this known or should I file a bug?
Re: dmd 2.057 release
On Friday, December 16, 2011 16:26:11 Christian Manning wrote:
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
wrote:
Highlights are use of XMM floating point registers in 64 bit
targets, and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best
release ever. Thanks!
I found a bug when slicing static arrays. It's not new to 2.057
but I totally forgot about it (my bad) and didn't simplify a test
case.
auto x() {
ubyte[4] a;
return a;
}
auto y() {
return x()[1..$];
}
void main() {
y();
}
Gives:
Internal error: ..\ztc\cgcs.c 354
Is this known or should I file a bug?
It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414
I'd point out though that that is really bad code, which should probably give
an error when you try and compile it (though it obviously shouldn't cause the
compiler to ICE regardless).
http://d.puremagic.com/issues/show_bug.cgi?id=7087
- Jonathan M Davis
Re: dmd 2.057 release
On Friday, 16 December 2011 at 16:43:29 UTC, Jonathan M Davis
wrote:
On Friday, December 16, 2011 16:26:11 Christian Manning wrote:
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
wrote:
Highlights are use of XMM floating point registers in 64 bit
targets, and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best
release ever. Thanks!
I found a bug when slicing static arrays. It's not new to 2.057
but I totally forgot about it (my bad) and didn't simplify a
test
case.
auto x() {
ubyte[4] a;
return a;
}
auto y() {
return x()[1..$];
}
void main() {
y();
}
Gives:
Internal error: ..\ztc\cgcs.c 354
Is this known or should I file a bug?
It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414
I'd point out though that that is really bad code, which should
probably give an error when you try and compile it (though it
obviously shouldn't cause the compiler to ICE regardless).
http://d.puremagic.com/issues/show_bug.cgi?id=7087
- Jonathan M Davis
It was just some mess around code, but I'll avoid it in the
future, so thanks for pointing it out :)
It does indeed look to be the same problem as
http://d.puremagic.com/issues/show_bug.cgi?id=4414
I should also point out that the appearance of the error is
dependant on the slice size.
How about this as a better test case?
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
Re: dmd 2.057 release
On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
How about this as a better test case?
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
That actually has exactly the same problem. You're slicing a temporary. You
can't slice a static array unless it's an actual variable, or you're going to
have problems. b points to a slice of a static array which doesn't exist
anymore. It _might_ work depending on how the registers used and how the stack
is laid out, but it's still a bad idea.
Regardless, the compiler shouldn't be ICEing though.
- Jonathan M Davis
Re: dmd 2.057 release
On Friday, 16 December 2011 at 22:48:21 UTC, Jonathan M Davis wrote: That actually has exactly the same problem. You're slicing a temporary. You can't slice a static array unless it's an actual variable, or you're going to have problems. b points to a slice of a static array which doesn't exist anymore. It _might_ work depending on how the registers used and how the stack is laid out, but it's still a bad idea. Ah I get it now, thanks.
Re: dmd 2.057 release
On 12/15/2011 2:25 PM, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). I've never seen code depend on an ICE :)
Re: dmd 2.057 release
Am 15.12.2011 07:50, schrieb Adrian: Am 14.12.2011 18:57, schrieb Walter Bright: On 12/14/2011 6:59 AM, Adrian wrote: I have a strange crash of the new dmd 2.057 compiler. I can't do anything without a reproducible test case. If you want, I can sent you the whole source. Its nothing real important, because I am playing around with D and porting some code to test. Adrian. I am little step forward. It has to do with the option for array bounds checking. When disabled dmd crashes, when enabled not. Therefor the debug version worked and the release not.
Re: dmd 2.057 release
On 15.12.2011 12:02, Adrian wrote: - for the crash to happen the project has to be compiled with the switches -noboundscheck and -deps=bug.dep. if you omit one of them the crash wont show. sounds like this one i encountered last release already: http://d.puremagic.com/issues/show_bug.cgi?id=6951
Re: dmd 2.057 release
On 2011-12-15 08:43, Jonathan M Davis wrote:
On Thursday, December 15, 2011 08:19:39 Jacob Carlborg wrote:
On 2011-12-14 18:00, Jonathan M Davis wrote:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of
type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an
array of Foo's. If foo() replaces one of the array elements with an
Object, then b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
I see, thanks. I was search for array on the changelog page.
The names of bug reports are frequently not particularly informative, and even
if they are, they frequently don't contain the necessary information to
understand the effects of fixing the bug. If you want to actually know what's
really being fixed, you frequently have to actually read all of the bug reports
rather than looking at their titles.
- Jonathan M Davis
Yeah, I guess.
--
/Jacob Carlborg
Re: dmd 2.057 release
On 2011-12-15 08:43, Jonathan M Davis wrote: The names of bug reports are frequently not particularly informative, and even if they are, they frequently don't contain the necessary information to understand the effects of fixing the bug. If you want to actually know what's really being fixed, you frequently have to actually read all of the bug reports rather than looking at their titles. - Jonathan M Davis I wonder if we can list breaking changes in a separate sections in the changelog. -- /Jacob Carlborg
Re: dmd 2.057 release
Am 15.12.2011 12:31, schrieb Stephan: On 15.12.2011 12:02, Adrian wrote: - for the crash to happen the project has to be compiled with the switches -noboundscheck and -deps=bug.dep. if you omit one of them the crash wont show. sounds like this one i encountered last release already: http://d.puremagic.com/issues/show_bug.cgi?id=6951 yes looks pretty much the same. Its total weired, because it seems to depend on code which is elsewhere.
Re: dmd 2.057 release
Sounds offset-dependent. I bet if you added and removed instructions in the right place you could reduce it a lot further. Sent from my iPhone On Dec 15, 2011, at 3:02 AM, Adrian adrian.remove-nos...@veith-system.de wrote: Am 14.12.2011 18:57, schrieb Walter Bright: On 12/14/2011 6:59 AM, Adrian wrote: I have a strange crash of the new dmd 2.057 compiler. I can't do anything without a reproducible test case. I tried to reduce the problem as much as possible and found out the following: - I have include a bug.bat which shows the commandline I used. - for the crash to happen the project has to be compiled with the switches -noboundscheck and -deps=bug.dep. if you omit one of them the crash wont show. - the module btree.d has to be compiled with the project, even if it is not referenced from main.d. if it is not in the command line - no crash - if you comment out the first writeln(Hello D-World!) in main() - no crash - if you comment out the other two writeln(..) in main() - no crash hope you can reproduce it on another system - it sounds too odd to me and if it is not reproducible on another system I feel a bit crazy. Adrian. bug.zip
Re: dmd 2.057 release
On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently).
Re: dmd 2.057 release
On 12/15/2011 6:31 AM, Adrian wrote: Am 15.12.2011 12:31, schrieb Stephan: On 15.12.2011 12:02, Adrian wrote: - for the crash to happen the project has to be compiled with the switches -noboundscheck and -deps=bug.dep. if you omit one of them the crash wont show. sounds like this one i encountered last release already: http://d.puremagic.com/issues/show_bug.cgi?id=6951 yes looks pretty much the same. Its total weired, because it seems to depend on code which is elsewhere. How about adding your bug.zip to that report?
Re: dmd 2.057 release
On 2011-12-15 20:25, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes. -- /Jacob Carlborg
Re: dmd 2.057 release
On 15.12.2011 21:34, Jacob Carlborg wrote: On 2011-12-15 20:25, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes. Deprecating typedef is in the list of changed features, not in the list of fixed bugs. Choosing which list things go in is sometimes a bit arbitrary, though. Occasionally in the changelog, major breaking changes were shown in red. That hasn't happened for ages.
Re: dmd 2.057 release
On 2011-12-15 22:28, Don wrote: On 15.12.2011 21:34, Jacob Carlborg wrote: On 2011-12-15 20:25, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes. Deprecating typedef is in the list of changed features, not in the list of fixed bugs. Choosing which list things go in is sometimes a bit arbitrary, though. Occasionally in the changelog, major breaking changes were shown in red. That hasn't happened for ages. Yes, I noticed typedef in the list, but in this case it would have been nice if it had its own section in the list. I know that typedef has been deprecated for a while but I had no idea it would be official in this release. -- /Jacob Carlborg
Re: dmd 2.057 release
On Wednesday, December 14, 2011 08:09:53 Bernard Helyer wrote: Changelog isn't showing up for me. Walter does the release, but Andrei updates the site. So, there's always a delay after a release before the site is updated. - Jonathan M Davis
Re: dmd 2.057 release
On 14.12.2011 11:05, Walter Bright wrote:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
Indeed.
Yet I have to issue yet another warning about new std.regex compared
with old one:
import std.stdio;
import std.regex;
void main() {
string src = 4.5.1;
foreach (c; match(src, regex(r(\d+
writeln(c.hit);
}
previously this will find all matches, now it finds only first one. To
get all of matches use g option.
Seems like 100% compatibility was next to impossible.
--
Dmitry Olshansky
Re: dmd 2.057 release
On 2011-12-14 08:05, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip A lot of people put a ton of effort into making this D's best release ever. Thanks! That's an impressive number of bug fixes and new features, nice. -- /Jacob Carlborg
Re: dmd 2.057 release
On 2011-12-14 08:05, Walter Bright wrote:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable using
argument types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to Object[]
Have I missed something, I can't find this in the changelog?
--
/Jacob Carlborg
Re: dmd 2.057 release
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the object
slicing problem. The thing is, main() expects b to be an array of Foo's. If
foo() replaces one of the array elements with an Object, then b is no longer an
array of Foo's, and can crash.
Note that if you write foo as:
void foo(const(Object)[] a)
it will work.
Re: dmd 2.057 release
On 12/14/11 1:44 AM, Walter Bright wrote: On 12/13/2011 11:18 PM, Jacob Carlborg wrote: On 2011-12-14 08:09, Bernard Helyer wrote: Changelog isn't showing up for me. Same here, latest change log is 2.056, which is empty. Andrei's working on uploading it. Sorry about the delay. Yah, sorry. Andrei
Re: dmd 2.057 release
On 12/14/11 1:05 AM, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip A lot of people put a ton of effort into making this D's best release ever. Thanks! Many thanks to all participants for this awesome release and in particular for the intense pace of the past few days! Andrei
Re: dmd 2.057 release
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
Note that if you write foo as:
void foo(const(Object)[] a)
it will work.
Ok, thanks.
--
/Jacob Carlborg
Re: dmd 2.057 release
Jacob Carlborg:
What happened to arrays in this release:
They have closed a significant D2 hole.
As Walter has explained, this code used to compile fine and then crash at
runtime:
class Foo {
void spam() {}
}
class Bar {}
void foo(Object[] a) {
a[0] = new Bar;
}
void main() {
Foo[] b = [new Foo];
foo(b);
b[0].spam(); // crash
}
Now instead it gives this at compile-time:
test.d(10): Error: function test.foo (Object[] a) is not callable using
argument types (Foo[])
test.d(10): Error: cannot implicitly convert expression (b) of type Foo[] to
Object[]
Now a modified foo is accepted if its 'a' argoment is constant, because you
can't modify the array contents (unless you cast away const):
class Foo {
void spam() {}
}
void foo(const(Object[]) a) {
}
void main() {
Foo[] b = [new Foo];
foo(b);
}
This Java code compiles with no errors:
class Foo {
Foo() {}
void spam() {}
}
class Bar {
Bar() {}
}
class Test {
static void foo(Object[] a) {
a[0] = new Bar(); // line 10, runtime error here
}
public static void main(String[] args) {
Foo[] b = {new Foo()};
Test.foo(b);
b[0].spam(); // line 15
}
}
Instead of crashing at run-time at line 15, it raises a
java.lang.ArrayStoreException at runtime at line 10, where at runtime it tests
that in a[0] you put a Foo() instead of something else like a Bar() or
Object(). So (in theory) the JavaVM has to perform a runtime test every time
you perform an assignment of a class reference to an array cell.
Bye,
bearophile
Re: dmd 2.057 release
Am 14.12.2011 08:05, schrieb Walter Bright:
Highlights are use of XMM floating point registers in 64 bit targets,
and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best release
ever. Thanks!
I have a strange crash of the new dmd 2.057 compiler.
I am running the compiler from inside VisualD. In debug mode the code
compiles fine. In release mode the compiler crashes and Windows starts
the Just-In-Time-Debugger saying that there is an unhandled exception
inside dmd.exe.
as a side note: the same code did compile with 2.056 !
When I try to find the source of the error it gets really funky strange:
int main(string[] argv)
{
writeln(Hello D-World!);
auto i = uniform(0, 15); // line A
auto c = 0;
if (c++ c) // line B
writeln(Why did they call it c++); // line C
//writeln(bench!(doStringTest)); // line D
//writeln(bench!(doBench1)); // line E
//writeln(bench!(doBench2)); // line F
//writeln(bench!(doBench3)); // line G
// main1(argv); // line I
// return 0; // line J
//} // line K
//int main1(string[] argv)// line L
//{ // line M
... much more code
}
- the code above crashes
- when I comment out line A it compiles
- when I leave A comment out B and C - dmd gets into an endless loop (
I waited several minutes for the process to terminate)
- when I leave A and uncomment I to M it compiles
- when I uncomment A to G it compiles
- when I uncomment A to F it crashes
now I tried the following:
int main(string[] argv)
{
writeln(Hello D-World!);
auto i = uniform(0, 15); // line A
auto c = 0;
if (c++ c) // line B
writeln(Why did they call it c++); // line C
//writeln(bench!(doStringTest)); // line D
//writeln(bench!(doBench1)); // line E
//writeln(bench!(doBench2)); // line F
//writeln(bench!(doBench3)); // line G
main1(argv); // line I
return 0; // line J
} // line K
int main1(string[] argv)// line L
{ // line M
... much more code
}
- as soon as I uncomment line G it compiles with any combination of line
D to F uncommented
- when line G is commented out any combination of line D to F
uncommented crashes.
- when I comment out line I any other combination compiles
I really would like to find a minimal stripped down version of the code,
but as soon as I try to find it, the behavior changes.
Re: dmd 2.057 release
Ideally, every nontrivial change should have a bugzilla entry, even if that
means its created by whoever made the change. It's too easy to miss things
otherwise.
Sent from my iPhone
On Dec 14, 2011, at 3:11 AM, Jacob Carlborg d...@me.com wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
Note that if you write foo as:
void foo(const(Object)[] a)
it will work.
Ok, thanks.
--
/Jacob Carlborg
Re: dmd 2.057 release
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
Re: dmd 2.057 release
On 12/14/2011 6:59 AM, Adrian wrote: I have a strange crash of the new dmd 2.057 compiler. I can't do anything without a reproducible test case.
Re: dmd 2.057 release
On 14/12/11 7:05 AM, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip A lot of people put a ton of effort into making this D's best release ever. Thanks! Great release. 64-bit OSX is working for my project without any problems. Had to change some uint's to size_t's and fix some inline asm but everything was fine after that :-)
Re: dmd 2.057 release
Am 14.12.2011 18:57, schrieb Walter Bright: On 12/14/2011 6:59 AM, Adrian wrote: I have a strange crash of the new dmd 2.057 compiler. I can't do anything without a reproducible test case. If you want, I can sent you the whole source. Its nothing real important, because I am playing around with D and porting some code to test. Adrian.
Re: dmd 2.057 release
On 2011-12-14 18:00, Jonathan M Davis wrote:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an array of
Foo's. If foo() replaces one of the array elements with an Object, then
b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
I see, thanks. I was search for array on the changelog page.
--
/Jacob Carlborg
Re: dmd 2.057 release
On Thursday, December 15, 2011 08:19:39 Jacob Carlborg wrote:
On 2011-12-14 18:00, Jonathan M Davis wrote:
On Wednesday, December 14, 2011 12:11:03 Jacob Carlborg wrote:
On 2011-12-14 11:10, Walter Bright wrote:
On 12/14/2011 1:59 AM, Jacob Carlborg wrote:
What happened to arrays in this release:
void foo (Object[] a) {}
class Foo {}
void main ()
{
Foo[] b;
foo(b);
}
The above code fails with the following message:
main.d(54): Error: function main.foo (Object[] a) is not callable
using argument
types (Foo[])
main.d(54): Error: cannot implicitly convert expression (b) of
type
Foo[] to
Object[]
Have I missed something, I can't find this in the changelog?
I don't remember if there was a bugzilla entry for it, but it's the
object slicing problem. The thing is, main() expects b to be an
array of Foo's. If foo() replaces one of the array elements with an
Object, then b is no longer an array of Foo's, and can crash.
I think it would be good if it's in the changelog, even if there is no
bugzilla entry for it.
It's the first dmd bug on the list:
http://d.puremagic.com/issues/show_bug.cgi?id=2095
- Jonathan M Davis
I see, thanks. I was search for array on the changelog page.
The names of bug reports are frequently not particularly informative, and even
if they are, they frequently don't contain the necessary information to
understand the effects of fixing the bug. If you want to actually know what's
really being fixed, you frequently have to actually read all of the bug reports
rather than looking at their titles.
- Jonathan M Davis
Re: dmd 2.057 release
Changelog isn't showing up for me.
Re: dmd 2.057 release
On 2011-12-14 08:09, Bernard Helyer wrote: Changelog isn't showing up for me. Same here, latest change log is 2.056, which is empty. -- /Jacob Carlborg
Re: dmd 2.057 release
On 12/13/2011 11:18 PM, Jacob Carlborg wrote: On 2011-12-14 08:09, Bernard Helyer wrote: Changelog isn't showing up for me. Same here, latest change log is 2.056, which is empty. Andrei's working on uploading it. Sorry about the delay.
Re: dmd 2.057 release
Why is the result of this different between 2.056 and 2.057?
import std.stdio;
import std.regex;
void main() {
string src = 4.5.1;
foreach (c; match(src, regex(r(\d+
writeln(c.hit);
}
2.056:
4
5
1
2.057:
4
