View mode: basic / threaded / horizontal-split · Log in · Help
December 10, 2011
If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
> 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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Re: If I had my way
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
Top | Discussion index | About this forum | D home