Jump to page: 1 213  
Page
Thread overview
If I had my way
Dec 10, 2011
Mehrdad
Dec 10, 2011
bearophile
Dec 10, 2011
Gour
Dec 10, 2011
Mehrdad
Dec 10, 2011
bearophile
Dec 10, 2011
Trass3r
Dec 11, 2011
Adam Wilson
Dec 13, 2011
Hans Uhlig
Dec 10, 2011
David Nadlinger
Dec 10, 2011
Andrew Wiley
Dec 11, 2011
Nick Sabalausky
Dec 11, 2011
Manu
Dec 10, 2011
maarten van damme
Dec 10, 2011
Walter Bright
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
maarten van damme
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
Chad J
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
Bane
Dec 11, 2011
so
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
so
Dec 11, 2011
Bane
Dec 11, 2011
Timon Gehr
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
Timon Gehr
Dec 11, 2011
Timon Gehr
Dec 12, 2011
Timon Gehr
Dec 13, 2011
Somedude
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
Bane
Dec 11, 2011
Timon Gehr
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
Chad J
Dec 13, 2011
Hans Uhlig
Dec 11, 2011
Alvaro
Dec 11, 2011
Somedude
Dec 11, 2011
Manu
Dec 11, 2011
Paulo Pinto
Dec 11, 2011
Manu
Dec 12, 2011
Walter Bright
Dec 12, 2011
Paulo Pinto
Dec 12, 2011
Manu
Dec 12, 2011
Robert Clipsham
Dec 12, 2011
Manu
Dec 12, 2011
Paulo Pinto
Dec 12, 2011
Manu
Dec 12, 2011
F i L
Dec 12, 2011
Paulo Pinto
Dec 13, 2011
Walter Bright
Dec 12, 2011
Danni Coy
Dec 13, 2011
Hans Uhlig
Dec 10, 2011
Walter Bright
Dec 10, 2011
David Nadlinger
Dec 10, 2011
Jonathan M Davis
Dec 11, 2011
Somedude
Dec 11, 2011
Dejan Lekic
Dec 11, 2011
Nick Sabalausky
Dec 11, 2011
Jonathan M Davis
Dec 10, 2011
maarten van damme
Dec 10, 2011
Walter Bright
Dec 12, 2011
Jacob Carlborg
Dec 13, 2011
Martin Nowak
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Martin Nowak
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Martin Nowak
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Michel Fortin
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Walter Bright
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Walter Bright
Dec 14, 2011
Martin Nowak
Dec 14, 2011
Jacob Carlborg
Dec 14, 2011
Walter Bright
Dec 14, 2011
Martin Nowak
Dec 13, 2011
Martin Nowak
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Martin Nowak
Dec 13, 2011
Jacob Carlborg
Dec 14, 2011
Walter Bright
Dec 14, 2011
Martin Nowak
Dec 14, 2011
Walter Bright
Dec 11, 2011
Jesse Phillips
Dec 11, 2011
Jesse Phillips
Dec 11, 2011
Jonathan M Davis
Dec 12, 2011
Jakob Ovrum
Dec 12, 2011
F i L
Dec 12, 2011
bearophile
Dec 12, 2011
Jonathan M Davis
Dec 13, 2011
F i L
Dec 13, 2011
Jonathan M Davis
Dec 13, 2011
Mehrdad
Dec 13, 2011
Jonathan M Davis
Dec 13, 2011
Mehrdad
Dec 13, 2011
Jacob Carlborg
Dec 13, 2011
Michel Fortin
Dec 13, 2011
Jonathan M Davis
Dec 13, 2011
Michel Fortin
Dec 13, 2011
Jonathan M Davis
Dec 13, 2011
Michel Fortin
Dec 14, 2011
F i L
Dec 14, 2011
Jonathan M Davis
Dec 14, 2011
F i L
Dec 14, 2011
Jonathan M Davis
Dec 14, 2011
Timon Gehr
December 10, 2011
I think we have a great release in the making: 64-bit code generation on OSX, improved floating point arithmetic, and a bunch of bugfixes.

Yet, if I had my way, I'd stop the release until every single complaint of Mehrdad's recent rampage has been looked at and addressed. Sure, we can label Mehrdad as a whiny baby, but I suspect his experience is representative for the out-of-the-box experience of many others: they see D's cool features, they download the compiler to try it out on their own terms, and as soon as they deviate from what is tried and works, or they combine features in an unusual yet meaningful manner, it all comes unglued.

It's about time to make a statement of reconnecting with our community, and in particular to the whiny babies out there. Sure, the kind of stuff we have in this beta is useful. Floating point arithmetic benchmarks have long hurt us, and 64-bit generation on OSX is a gating issue. But simple, long-standing issues that make babies whine are very important, too, and require our immediate attention.

I vote for making a strong point of fixing these out-of-the-box experience issues raised before we move forward with this release.


Andrei
December 10, 2011
On 12/10/2011 11:23 AM, Andrei Alexandrescu wrote:
> I think we have a great release in the making: 64-bit code generation on OSX, improved floating point arithmetic, and a bunch of bugfixes.
>
> Yet, if I had my way, I'd stop the release until every single complaint of Mehrdad's recent rampage has been looked at and addressed. Sure, we can label Mehrdad as a whiny baby, but I suspect his experience is representative for the out-of-the-box experience of many others: they see D's cool features, they download the compiler to try it out on their own terms, and as soon as they deviate from what is tried and works, or they combine features in an unusual yet meaningful manner, it all comes unglued.
>
> It's about time to make a statement of reconnecting with our community, and in particular to the whiny babies out there. Sure, the kind of stuff we have in this beta is useful. Floating point arithmetic benchmarks have long hurt us, and 64-bit generation on OSX is a gating issue. But simple, long-standing issues that make babies whine are very important, too, and require our immediate attention.
>
> I vote for making a strong point of fixing these out-of-the-box experience issues raised before we move forward with this release.
>
>
> Andrei

+1 (obviously) :)
December 10, 2011
Andrei Alexandrescu:

> I vote for making a strong point of fixing these out-of-the-box experience issues raised before we move forward with this release.

I suggest to release the nearly done 2.057 and leave those issues to 2.058 and successive versions.

Bye,
bearophile
December 10, 2011
> Floating point arithmetic benchmarks have long hurt us,
> and 64-bit generation on OSX is a gating issue.

The disastrous Windoze toolchain as well.
F*** OMF.
December 10, 2011
I certainly appreciate the general statement, as keeping ones users happy is one of the most important, if not the single most important thing, to a positive image.

However, please don't forget that there has already been put quite a lot of effort into making the current version ready for release (I don't think there are any blockers left, are there?). Addressing all the points raised would require several potentially high impact changes, which could easily set us back for two or three weeks.

Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are notoriously troublesome since tracing them down takes a lot of effort.

And personally, I'd like to see a new version being released soon because I'd otherwise have to tell Thrift people to use a Git version of DMD when I post my GSoC project for upstream inclusion, which I can't postpone infinitely. ;)

As 2.057 will contain a few additions which could potentially require some fixes before they can be considered stable, my proposal would be to release 2.057 now, and aim for a quick 2.058 to address both the issues you mentioned, and any problems turned up by FReD/OS X x86_64 being used in the real world.

David



On 12/10/11 8:23 PM, Andrei Alexandrescu wrote:
> I think we have a great release in the making: 64-bit code generation on
> OSX, improved floating point arithmetic, and a bunch of bugfixes.
>
> Yet, if I had my way, I'd stop the release until every single complaint
> of Mehrdad's recent rampage has been looked at and addressed. Sure, we
> can label Mehrdad as a whiny baby, but I suspect his experience is
> representative for the out-of-the-box experience of many others: they
> see D's cool features, they download the compiler to try it out on their
> own terms, and as soon as they deviate from what is tried and works, or
> they combine features in an unusual yet meaningful manner, it all comes
> unglued.
>
> It's about time to make a statement of reconnecting with our community,
> and in particular to the whiny babies out there. Sure, the kind of stuff
> we have in this beta is useful. Floating point arithmetic benchmarks
> have long hurt us, and 64-bit generation on OSX is a gating issue. But
> simple, long-standing issues that make babies whine are very important,
> too, and require our immediate attention.
>
> I vote for making a strong point of fixing these out-of-the-box
> experience issues raised before we move forward with this release.
>
>
> Andrei

December 10, 2011
On Sat, Dec 10, 2011 at 2:00 PM, David Nadlinger <see@klickverbot.at> wrote:
> I certainly appreciate the general statement, as keeping ones users happy is one of the most important, if not the single most important thing, to a positive image.
>
> However, please don't forget that there has already been put quite a lot of effort into making the current version ready for release (I don't think there are any blockers left, are there?). Addressing all the points raised would require several potentially high impact changes, which could easily set us back for two or three weeks.
>
> Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are notoriously troublesome since tracing them down takes a lot of effort.
>
> And personally, I'd like to see a new version being released soon because I'd otherwise have to tell Thrift people to use a Git version of DMD when I post my GSoC project for upstream inclusion, which I can't postpone infinitely. ;)
>
> As 2.057 will contain a few additions which could potentially require some fixes before they can be considered stable, my proposal would be to release 2.057 now, and aim for a quick 2.058 to address both the issues you mentioned, and any problems turned up by FReD/OS X x86_64 being used in the real world.

^^
I agree. Postponing the current release doesn't really do anything but
frustrate the people that depend on recent changes. Setting a goal for
the next release accomplishes the same goals without the added
frustration.
We might try making a list of current bugs that *must* be resolved in
the next release. The size of the list would have to be carefully
controlled, but it would bridge the gap between the compiler
developers and the community.
December 10, 2011
yes please.
I've read the book "the d programming language" and got all excited until I
actually tried using std.algorithm. (d made up for it pretty soon).
It are the huge problems that prevent people for trying a language but it
are those little things that scare them back away.

And I've also been a bit disappointed in the d way of doing things (it's easy to write good code but hard is always possible). Just for fun I wanted to create a program as little as possible, compiled without garbage collector/phobos/... and it turned out that compiling without garbage collector is pretty much impossible (memory leaks all around the place in druntime). dynamic linking for the d standard library would be a great new option for a dmd release in the future :).


December 10, 2011
On Sat, 10 Dec 2011 14:35:13 -0500
bearophile <bearophileHUGS@lycos.com> wrote:

> I suggest to release the nearly done 2.057 and leave those issues to 2.058 and successive versions.

I suggest releasing 2.057 soon, but then, for subsequent releases, if there are major improvements to change current numbering scheme.

2.056 --> 2.057 --> 2.058 somehow does not seem right. Of course, maybe we  should be at 1.99.x instead.


Sincerely,
Gour


-- 
As fire is covered by smoke, as a mirror is covered by dust, or as the embryo is covered by the womb, the living entity is similarly covered by different degrees of this lust.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


December 10, 2011
On 12/10/11 2:14 PM, Andrew Wiley wrote:
> On Sat, Dec 10, 2011 at 2:00 PM, David Nadlinger<see@klickverbot.at>  wrote:
>> I certainly appreciate the general statement, as keeping ones users happy is
>> one of the most important, if not the single most important thing, to a
>> positive image.
>>
>> However, please don't forget that there has already been put quite a lot of
>> effort into making the current version ready for release (I don't think
>> there are any blockers left, are there?). Addressing all the points raised
>> would require several potentially high impact changes, which could easily
>> set us back for two or three weeks.
>>
>> Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are
>> notoriously troublesome since tracing them down takes a lot of effort.
>>
>> And personally, I'd like to see a new version being released soon because
>> I'd otherwise have to tell Thrift people to use a Git version of DMD when I
>> post my GSoC project for upstream inclusion, which I can't postpone
>> infinitely. ;)
>>
>> As 2.057 will contain a few additions which could potentially require some
>> fixes before they can be considered stable, my proposal would be to release
>> 2.057 now, and aim for a quick 2.058 to address both the issues you
>> mentioned, and any problems turned up by FReD/OS X x86_64 being used in the
>> real world.
>
> ^^
> I agree. Postponing the current release doesn't really do anything but
> frustrate the people that depend on recent changes. Setting a goal for
> the next release accomplishes the same goals without the added
> frustration.

There are good ways of addressing that. We can delay the release by only a few days and fix long-standing and extremely important issues. This is not only about doing the expected/reasonable thing here, but breaking a pattern and making a statement.

> We might try making a list of current bugs that *must* be resolved in
> the next release. The size of the list would have to be carefully
> controlled, but it would bridge the gap between the compiler
> developers and the community.

That's a great idea going forward.


Andrei
December 10, 2011
On 12/10/2011 12:00 PM, David Nadlinger wrote:
> I certainly appreciate the general statement, as keeping ones users happy is one
> of the most important, if not the single most important thing, to a positive image.
>
> However, please don't forget that there has already been put quite a lot of
> effort into making the current version ready for release (I don't think there
> are any blockers left, are there?). Addressing all the points raised would
> require several potentially high impact changes, which could easily set us back
> for two or three weeks.
>
> Also, the soon-to-be 2.057 fixes quite a few codegen bugs, which are notoriously
> troublesome since tracing them down takes a lot of effort.
>
> And personally, I'd like to see a new version being released soon because I'd
> otherwise have to tell Thrift people to use a Git version of DMD when I post my
> GSoC project for upstream inclusion, which I can't postpone infinitely. ;)
>
> As 2.057 will contain a few additions which could potentially require some fixes
> before they can be considered stable, my proposal would be to release 2.057 now,
> and aim for a quick 2.058 to address both the issues you mentioned, and any
> problems turned up by FReD/OS X x86_64 being used in the real world.

Andrei makes a compelling case, but I am also concerned about messing things up for you. What is your schedule like?
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11