On 2012-07-16 08:51, Walter Bright wrote:

> It is a good idea, but I'd be nervous myself about allowing the compiler
> to edit my code :-)

Don't you trust your own compiler :)

The compiler could have --dry-run option to show what would be changed. It could also show a diff after all processing.

-- 
/Jacob Carlborg

On Jul 16, 2012 4:15 AM, "Jacob Carlborg" <doob@me.com> wrote:
>
> On 2012-07-16 08:51, Walter Bright wrote:
>
>> It is a good idea, but I'd be nervous myself about allowing the compiler to edit my code :-)
>
>
> Don't you trust your own compiler :)
>
> The compiler could have --dry-run option to show what would be changed.
It could also show a diff after all processing.
>
> --
> /Jacob Carlborg
>

Yeah, and if you're using some kind of version control system there is really no risk.

On Monday, 16 July 2012 at 05:56:47 UTC, Walter Bright wrote:
> SIMD support is critical for D's mission as a systems programming language, and has been important in attracting some significant adoption of D.

Has it?

David

On 16 July 2012 12:26, David Nadlinger <see@klickverbot.at> wrote:
> On Monday, 16 July 2012 at 05:56:47 UTC, Walter Bright wrote:
>>
>> SIMD support is critical for D's mission as a systems programming language, and has been important in attracting some significant adoption of D.
>
>
> Has it?
>
> David
>
>


It certainly raised a few eyebrows from D users from the Game Development market.  Even had someone from Remedy Games contact me over some support queries - which I found to be a bit of a surprise. :-)


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Monday, 16 July 2012 at 11:34:26 UTC, Iain Buclaw wrote:
> It certainly raised a few eyebrows from D users from the Game
> Development market.

I don't doubt that, but has SIMD support in its current form actually led to any »significant adoption«? For example, I got dozens of private requests from different programmers, some from companies with big names, regarding Thrift support in D after last year's GSoC. I know that it led some people to play around with D, but that's hardly what I would call »significant adoption«…

David

On Monday, 16 July 2012 at 06:05:43 UTC, Walter Bright wrote:

> I've had a lot of my own working D code break because of name changes in Phobos. This is extremely annoying. I can fully understand that it drives people away. It's got to stop.

Name changes have been the least annoying breaking change I've come across from using D. Language design being the biggest.

Luckily I've expected that, and recently hit has been very infrequent. There are still changes that will be making big ripples (actually maybe not so much if we are changing how we handle toHash...). Maybe this unstable branch thing will allow us to make a bunch of a breaking changes together when we have one of these required disruptions.

On Monday, 16 July 2012 at 06:00:03 UTC, Walter Bright wrote:
> Supporting Win64 is absolutely critical for the future of D, and the sooner we get it, the better. The COFF route is the shortest route to doing it, and the most practical for attracting devs, which is why it's the way we're going.

Sorry, but I don't think this is a valid argument. Yes, Win64 (and even more so, COFF) support is important to have for DMD, but no, it's not a good idea to delay a pending release because of this (cf. the »Time for a new beta« thread from the end of May). Here is why:

http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2012-04-13&bug_status=RESOLVED&resolution=FIXED

Already 289 issues resolved since 2.059!

And implementing Win64 support isn't going to be done in a weekend. Sure, the changes needed are not world-shattering: Finish COFF writing support, tweak the register spilling/call emitting code to conform to the Win64 ABI, implement vararg support in both the backend and druntime (they are handled differently on Win64 than described in the System V ABI), transition to the MSVC runtime. druntime and Phobos will also require some changes, although there shouldn't be much left to do, given that GDC (and LDC, except for exceptions) already work on x64 Windows.

After this has been done, there are still

http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfieldfrom=2012-04-13&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

to deal with. And after those regressions have been fixed and a first beta is released, chances are that some new regressions will pop up, because many people can't even use Git master for their real-world code right now.

So, all in all, I wouldn't expect a release before, say, around mid-September. This is five months after the last release, a delay twice as long as our usual release cycle. Several of the bugs fixed since 2.059 were hard to work around, so I don't think it's unreasonable to assume that we will have lost users because of this. And what for? Chances are that we will just have _two_ semi-working targets in DMD then (structs are still broken on x86_64 Linux/OS X/BSD w.r.t. parameter ABI and in some cases sizing/alignment).

If you really want to make D more attractive, including for corporate use (from what I gathered from several Thrift-related discussions), the easiest thing to do, in my humble opinion, would be to make the release schedule at least somewhat predictable, to publish more or less dependable short-term roadmaps, and most importantly, to actively communicate your decisions on these topics – it just happens that you are D's lead-developer-release-manager-strategist-dictator, regardless of whether you'd prefer to fill only some of the roles.

David

On 16/07/12 16:51, David Nadlinger wrote:
> On Monday, 16 July 2012 at 06:00:03 UTC, Walter Bright wrote:
>> Supporting Win64 is absolutely critical for the future of D, and the
>> sooner we get it, the better. The COFF route is the shortest route to
>> doing it, and the most practical for attracting devs, which is why
>> it's the way we're going.
>
> Sorry, but I don't think this is a valid argument. Yes, Win64 (and even
> more so, COFF) support is important to have for DMD, but no, it's not a
> good idea to delay a pending release because of this (cf. the »Time for
> a new beta« thread from the end of May). Here is why:
>
> http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2012-04-13&bug_status=RESOLVED&resolution=FIXED
>
>
> Already 289 issues resolved since 2.059!

More than that. Of the official releases, there is no usable 64 bit DMD compiler on ANY platform. Some awful wrong-code bugs were still present in 2.059. They have been fixed for a couple of months in DMD git, but not in an official release.

On Monday, 16 July 2012 at 01:38:38 UTC, Alex Rønne Petersen wrote:
> On 16-07-2012 03:11, Andrei Alexandrescu wrote:
>> On 7/15/12 7:44 PM, Adam Wilson wrote:
>>> I should note that we use this exact model for every project we have
>>> where I work and that it is been highly successful at keeping those five
>>> points of tension moderated. And our users can actually get work done
>>> without waiting for weeks and months because thing X is just plain
>>> broken, which in turn makes us look good. (Improving Loyalty)
>>
>> Allow me to propose something.
>>
>> Right now all dmd changes get merged in the head. Suppose we find a
>> volunteer in the community who is:
>>
>> 1. Highly motivated
>>
>> 2. With a good understanding of D
>>
>> 3. Expert with git
>>
>> 4. Reliable
>>
>> I wonder if it's possible that that person cherry-picks commits from
>> HEAD into two separate branches: bugfixes and unstable. It should be
>> easy to create installers etc. for those.
>>
>> If we see this works well and gathers steady interest, we can improve it
>> and make it the practice of the entire team.
>>
>> Would this be possible?
>>
>>
>> Andrei
>>
>
> I propose a slight variation:
>
> * master: This is the 'incoming' branch. Unstable, in-dev, etc. It's easier this way since pull requests will usually target this branch and build bots will test this.
> * stable: This branch contains only bug fixes to existing language features, and enhancements that do not in any way impact existing features (or break code). Should be manually maintained based on master.
>
> That's it. I don't see a need for any added complexity to this simple model. Feel free to destroy as you see fit, though!

git-flow is the other candidate.

https://github.com/nvie/gitflow/

See more detail:

http://nvie.com/posts/a-successful-git-branching-model/

On Monday, 16 July 2012 at 05:56:47 UTC, Walter Bright wrote:
> On 7/15/2012 5:36 PM, Jonathan M Davis wrote:
>> Arguably, we've been adding too many new features (e.g. new lambda syntax and
>> SIMD support), given that we're supposed to be making everything that we
>> already  have work properly, but those features haven't been breaking changes,
>> and presumably forcing Walter to just fix bugs wouldn't be all that pleasant
>> for him.
>
> SIMD support is critical for D's mission as a systems programming language, and has been important in attracting some significant adoption of D.

OTOH, if the people who were attracted end up quitting because the language is continuously unstable, the net effect is negative, because those who leave the boat won't come back.

I tend to agree that there should be a stable and a dev branch, with regular merges from dev --> stable when new non breaking features have been shown to work for a while. For instance, nothing prevents you to develop COFF and SIMD on the dev branch, and decide in 6 months to merge those features in the stable branch, because they've been shown to have stabilized.

In fact, it's much easier to make a roadmap this way than it is right now, where releases are delayed because new features don't work.

The 2.060 is late, very late.