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!
Changelog isn't showing up for me.
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
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.
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
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
Walter:
> http://ftp.digitalmars.com/dmd.2.057.zip
Thank you for the work. 2.057beta has allowed me to remove several work-arounds
in my D2 code.
Some thinks I'd like to see some attention on, in 2.058:
1) Fixing import semantics (http://d.puremagic.com/issues/show_bug.cgi?id=313
https://git
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
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
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
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
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
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
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 (Objec
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
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
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 wrote:
> On 2011-12-14 11:10, Walter Bright wrote:
>> On 12/14/201
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
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.
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
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 arou
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
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 a
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 not
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
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 Carlbor
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
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 alrea
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
wrote:
> Am 14.12.2011 18:57, schrieb Walter Bright:
>> On 12/14/2011 6:59 AM, Adrian wrote:
>>> I have a strange
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).
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 enc
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
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 inadve
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
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
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/
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 O
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 un
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
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 o
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
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
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?
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 ou
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
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?
Perh
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, s
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 .
But anyone can pull the latest from github and use it, many do.
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 .
But anyone can pull the latest from gith
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
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 communi
"Alex Rønne Petersen" 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 comm
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 communi
On Tue, Jan 3, 2012 at 5:02 PM, 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 expe
On 2012-01-03 20:46, Nick Sabalausky wrote:
"Alex Rønne Petersen" 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
gettin
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
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 f
57 matches
Mail list logo
