Community

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

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) :)

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

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

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.

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 :).

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

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

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?