www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd 2.068, 2.069, 2.0xx Evil Plan going forward

reply Walter Bright <newshound2 digitalmars.com> writes:
2.068 - resolve remaining regressions and release

2.069 - translate to D. No new features, no refactoring. Only regression fixes 
and what's already in HEAD. This should give us a solid baseline. It also means 
that open PRs that address other issues will not be pulled for 2.069.

Perhaps we should name this 2.100, to signify such a milestone.

2.101+ -
1. Take advantage of D features to improve quality.
2. Go to full lazy semantic analysis of imports, rather than the current 
"analyze them all"
3. Rethink what "speculative instantiation" of templates means so we can have a 
coherent process of compiling them.
4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was 
already done for constant folding, but now it's time for the rest of the 
interpreter.
5. Get rid of reliance on the global error count. This has been mostly done, it 
just hast to be finished.
6. Convert the back end to D as well.
Jul 19 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Jul 19, 2015 at 09:02:03PM -0700, Walter Bright via Digitalmars-d wrote:

 2.068 - resolve remaining regressions and release


Are there any remaining naming issues (introduced in this release, that
is, not stuff that's already out there -- let's not touch those anymore)
that people are dying to fix? If there are, we should get them in now
before the names become set in stone.



 2.069 - translate to D. No new features, no refactoring. Only
 regression fixes and what's already in HEAD. This should give us a
 solid baseline. It also means that open PRs that address other issues
 will not be pulled for 2.069.


Sounds like a good idea, give ourselves a whole release to stabilise
self-hosting D, without anything else to distract our efforts.



 Perhaps we should name this 2.100, to signify such a milestone.
 
 2.101+ -
 1. Take advantage of D features to improve quality.
 2. Go to full lazy semantic analysis of imports, rather than the
 current "analyze them all"
 3. Rethink what "speculative instantiation" of templates means so we
 can have a coherent process of compiling them.


For the sake of those of us who aren't so familiar with dmd internals:
what is speculative instantiation and why does matter so much?



 4. Redo CTFE interpreter so it only rarely needs to allocate memory.
 This was already done for constant folding, but now it's time for the
 rest of the interpreter.


Yes, please! This would significantly widen the practical usage of D
compile-time features in real-world projects.



 5. Get rid of reliance on the global error count. This has been mostly
 done, it just hast to be finished.


Does this involve cleaning up the handling of error-gagging too?



 6. Convert the back end to D as well.


Will a D backend still be under the same license encumbrances as the
current one?


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson
Jul 19 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/19/2015 9:15 PM, H. S. Teoh via Digitalmars-d wrote:

 On Sun, Jul 19, 2015 at 09:02:03PM -0700, Walter Bright via Digitalmars-d
wrote:

 3. Rethink what "speculative instantiation" of templates means so we
 can have a coherent process of compiling them.


 For the sake of those of us who aren't so familiar with dmd internals:
 what is speculative instantiation and why does matter so much?


It's the basis of static if - does this piece of code compile. It's been a rich 
source of bugs because if the compilation fails, it can leave the state of the 
compiler in an indeterminate state.



 5. Get rid of reliance on the global error count. This has been mostly
 done, it just hast to be finished.


 Does this involve cleaning up the handling of error-gagging too?


Yes.



 6. Convert the back end to D as well.


 Will a D backend still be under the same license encumbrances as the
 current one?


Yes. Mere translation would not change the license.

But I view the backend license encumbrance as more of a theoretical issue than
a 
practical one - the license is extremely permissive. There isn't that much more 
to it than agreeing to not sue Symantec.
Jul 19 2015
parent reply "Kagamin" <spam here.lot> writes:
On Monday, 20 July 2015 at 04:35:30 UTC, Walter Bright wrote:

 But I view the backend license encumbrance as more of a 
 theoretical issue than a practical one - the license is 
 extremely permissive. There isn't that much more to it than 
 agreeing to not sue Symantec.


Redistribution is explicitly disallowed though (i.e. one can't 
fork it on github without individual permission).
Jul 20 2015
next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Monday, 20 July 2015 at 08:40:24 UTC, Kagamin wrote:

 Redistribution is explicitly disallowed though (i.e. one can't 
 fork it on github without individual permission).


Technically, I believe that by uploading any project to GitHub, 
one has granted permission for it to be forked _on GitHub_.  
(This is explicitly stated in the GitHub Terms of Service.)

That doesn't automatically grant any other permissions of re-use 
or redistribution, though.
Jul 20 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2015 1:40 AM, Kagamin wrote:

 On Monday, 20 July 2015 at 04:35:30 UTC, Walter Bright wrote:

 But I view the backend license encumbrance as more of a theoretical issue than
 a practical one - the license is extremely permissive. There isn't that much
 more to it than agreeing to not sue Symantec.


 Redistribution is explicitly disallowed though (i.e. one can't fork it on
github
 without individual permission).


Yeah, well, I've never denied anyone permission, and the only point of that is 
they have to agree not to sue Symantec.
Jul 20 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 20 Jul 2015 02:11:49 -0700, Walter Bright wrote:


 On 7/20/2015 1:40 AM, Kagamin wrote:

 On Monday, 20 July 2015 at 04:35:30 UTC, Walter Bright wrote:

 But I view the backend license encumbrance as more of a theoretical
 issue than a practical one - the license is extremely permissive.
 There isn't that much more to it than agreeing to not sue Symantec.


 Redistribution is explicitly disallowed though (i.e. one can't fork it
 on github without individual permission).


=20
 Yeah, well, I've never denied anyone permission, and the only point of
 that is they have to agree not to sue Symantec.


but still, the backend license is what blocks including DMD in some GNU/
Linux distros repositories, 'cause "The Software is copyrighted and comes=20
with a single user license, and may not be redistributed."

this effectively blocks all non-source-based distros from redistributing=20
DMD as distro package (both in compiled and in source forms).=
Jul 23 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
i.e. blocks any distros that doesn't "git clone" as the part of package=20
installing process.=
Jul 23 2015
prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 20/07/2015 4:02 p.m., Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only regression
 fixes and what's already in HEAD. This should give us a solid baseline.
 It also means that open PRs that address other issues will not be pulled
 for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.


Or instead, move to SEMVER? Same effect.
Although, now might be a good time to think about D3. After all, we are 
having a massive change in the ecosystem. It wouldn't be that strange to 
think of it as more of a push for polishing.


 2.101+ -
 1. Take advantage of D features to improve quality.


As a library perhaps?


 2. Go to full lazy semantic analysis of imports, rather than the current
 "analyze them all"


Ooo


 3. Rethink what "speculative instantiation" of templates means so we can
 have a coherent process of compiling them.


Can the plan include stripping out unneeded ones? And even inlining some?


 4. Redo CTFE interpreter so it only rarely needs to allocate memory.
 This was already done for constant folding, but now it's time for the
 rest of the interpreter.


Less memory = win! E.g. can we compile + run phobos test suite in < 1gb 
memory?
Because it's a real pain finding single board computers that support 
more then 1gb.


 5. Get rid of reliance on the global error count. This has been mostly
 done, it just hast to be finished.
 6. Convert the back end to D as well.


Ooo, yes please.
Perhaps even as a library?

I would love to see dmd literally along with it's backends as dub 
packages. That would be *high pitched* awesome.
Jul 19 2015
parent reply "Andrea Fontana" <nospam example.com> writes:
On Monday, 20 July 2015 at 04:45:21 UTC, Rikki Cattermole wrote:

 Perhaps we should name this 2.100, to signify such a milestone.


 Or instead, move to SEMVER? Same effect.
 Although, now might be a good time to think about D3. After 
 all, we are having a massive change in the ecosystem. It 
 wouldn't be that strange to think of it as more of a push for 
 polishing.


Semver ftw! About D3: if we have to do a switch, it's the right 
time to remove old things left for retro-compatibility and 
rename/move things (and fix  property, for example).


 2.101+ -
 1. Take advantage of D features to improve quality.


 As a library perhaps?


+100 for library


 6. Convert the back end to D as well.


 Ooo, yes please.
 Perhaps even as a library?


+100
Jul 20 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 20/07/2015 7:12 p.m., Andrea Fontana wrote:

 On Monday, 20 July 2015 at 04:45:21 UTC, Rikki Cattermole wrote:

 Perhaps we should name this 2.100, to signify such a milestone.


 Or instead, move to SEMVER? Same effect.
 Although, now might be a good time to think about D3. After all, we
 are having a massive change in the ecosystem. It wouldn't be that
 strange to think of it as more of a push for polishing.


 Semver ftw! About D3: if we have to do a switch, it's the right time to
 remove old things left for retro-compatibility and rename/move things
 (and fix  property, for example).


In a way we are in a transition period. Not a big language change, but a 
ecosystem/organization one.


 2.101+ -
 1. Take advantage of D features to improve quality.


 As a library perhaps?


 +100 for library


 6. Convert the back end to D as well.


 Ooo, yes please.
 Perhaps even as a library?


 +100
Jul 20 2015
prev sibling next sibling parent reply "ZombineDev" <valid_email he.re> writes:
On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.

 2.101+ -
 1. Take advantage of D features to improve quality.
 2. Go to full lazy semantic analysis of imports, rather than 
 the current "analyze them all"
 3. Rethink what "speculative instantiation" of templates means 
 so we can have a coherent process of compiling them.
 4. Redo CTFE interpreter so it only rarely needs to allocate 
 memory. This was already done for constant folding, but now 
 it's time for the rest of the interpreter.
 5. Get rid of reliance on the global error count. This has been 
 mostly done, it just hast to be finished.
 6. Convert the back end to D as well.


+ 1000000000
Jul 19 2015
parent "ZombineDev" <valid_email he.re> writes:
On Monday, 20 July 2015 at 05:05:52 UTC, ZombineDev wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.

 2.101+ -
 1. Take advantage of D features to improve quality.
 2. Go to full lazy semantic analysis of imports, rather than 
 the current "analyze them all"
 3. Rethink what "speculative instantiation" of templates means 
 so we can have a coherent process of compiling them.
 4. Redo CTFE interpreter so it only rarely needs to allocate 
 memory. This was already done for constant folding, but now 
 it's time for the rest of the interpreter.
 5. Get rid of reliance on the global error count. This has 
 been mostly done, it just hast to be finished.
 6. Convert the back end to D as well.


 + 1000000000


I believe that migrating the the development of the compiler from 
C++ to D will have extremely positive effect to to the whole 
language and ecosystem. We should make this our number one 
priority!

 WalterBright and the other core developers:
Can you make a TODO list of what needs to be done to make this 
happen?

Is this list in bugzilla complete?
https://issues.dlang.org/buglist.cgi?bug_status=__open__&content=ddmd&list_id=202211&order=relevance%20desc&query_format=specific
(I just searched for DDMD)
Jul 19 2015
prev sibling next sibling parent "Ilya Yaroshenko" <ilyayaroshenko gmail.com> writes:
On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 4. Redo CTFE interpreter so it only rarely needs to allocate 
 memory. This was already done for constant folding, but now 
 it's time for the rest of the interpreter.


Great!

... and CTFE-able unions, thought. They are required for 
CTFE-able math.
Jul 19 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-07-20 06:02, Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only regression
 fixes and what's already in HEAD. This should give us a solid baseline.
 It also means that open PRs that address other issues will not be pulled
 for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.

 2.101+ -
 1. Take advantage of D features to improve quality.
 2. Go to full lazy semantic analysis of imports, rather than the current
 "analyze them all"
 3. Rethink what "speculative instantiation" of templates means so we can
 have a coherent process of compiling them.
 4. Redo CTFE interpreter so it only rarely needs to allocate memory.
 This was already done for constant folding, but now it's time for the
 rest of the interpreter.
 5. Get rid of reliance on the global error count. This has been mostly
 done, it just hast to be finished.
 6. Convert the back end to D as well.


I like it. Please continue with these kinds of posts.

-- 
/Jacob Carlborg
Jul 19 2015
prev sibling next sibling parent reply "Adrian Matoga" <epi atari8.info> writes:
On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.


This may also be the best moment to start keeping frontend 
versions among DMD/GDC/LDC synchronized, forever.
Jul 20 2015
parent "wobbles" <grogan.colin gmail.com> writes:
On Monday, 20 July 2015 at 07:15:16 UTC, Adrian Matoga wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.


 This may also be the best moment to start keeping frontend 
 versions among DMD/GDC/LDC synchronized, forever.


So much this.

Theres always so many nice new features in the newest dmd (and 
phobos) that you want to use it, but cant as a result of GDC/LDC 
being slightly outdated.
Jul 20 2015
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 20 July 2015 at 06:02, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only regression
 fixes and what's already in HEAD. This should give us a solid baseline. It
 also means that open PRs that address other issues will not be pulled for
 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.

 2.101+ -
 1. Take advantage of D features to improve quality.
 2. Go to full lazy semantic analysis of imports, rather than the current
 "analyze them all"
 3. Rethink what "speculative instantiation" of templates means so we can
 have a coherent process of compiling them.
 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This
 was already done for constant folding, but now it's time for the rest of the
 interpreter.
 5. Get rid of reliance on the global error count. This has been mostly done,
 it just hast to be finished.
 6. Convert the back end to D as well.


I just have one request.  We need to designate a supported version of
the compiler (2.069?) as the base to which we convert and maintain
compatibility for, and do not introduce any new features after that
point.  Something as vague as "the last three versions" does *not* cut
it.

This is to give maximum time for all ecosystems to adjust, and
encourage that we have a "stable" snapshot of D2 before the conversion
that will receive maintenance fixes long after mainline development
has switched.

Iain
Jul 20 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2015 2:09 AM, Iain Buclaw via Digitalmars-d wrote:

 I just have one request.  We need to designate a supported version of
 the compiler (2.069?) as the base to which we convert and maintain
 compatibility for, and do not introduce any new features after that
 point.  Something as vague as "the last three versions" does *not* cut
 it.

 This is to give maximum time for all ecosystems to adjust, and
 encourage that we have a "stable" snapshot of D2 before the conversion
 that will receive maintenance fixes long after mainline development
 has switched.


We can do that for 2.068.
Jul 20 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 20 July 2015 at 09:10:13 UTC, Iain Buclaw wrote:

 I just have one request.  We need to designate a supported 
 version of the compiler (2.069?) as the base to which we 
 convert and maintain compatibility for, and do not introduce 
 any new features after that point.


I don't fully understand what you're asking for.
Can you tell us what problem you're trying to address instead of 
which solution to apply.
Jul 20 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 Jul 2015 00:00, "Martin Nowak via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Monday, 20 July 2015 at 09:10:13 UTC, Iain Buclaw wrote:

 I just have one request.  We need to designate a supported version of




the compiler (2.069?) as the base to which we convert and maintain
compatibility for, and do not introduce any new features after that point.

 I don't fully understand what you're asking for.
 Can you tell us what problem you're trying to address instead of which


solution to apply.

1. If you want ddmd to be compilable by both gdc and ldc then you can't
introduce any new features to the ddmd codebase post conversion.

The work you've left me is an added burden that was ultimately welcome, but
unasked for. So expect things to halt on my side for some time as I'm going
through a partial rewrite.

2. Simplifies bootstrap for porting to self-hosted D.

Though the gdc compiler is available in Debian on all supported platforms -
some 16 in total - the library is still only being built on x86 and ARM,
because of lack of testing or build failures.

Having the last C++ frontend being able to build the latest D frontend
allows the transition for these targets that need their runtime library
ported and tested easier.  The reality still is that C++ has the upper hand
for being more portable, but there should be no reason why we can't run
everywhere C++ runs granted there is an OS.

3. Force stability language through codebase.  Maybe ddmd will be a bad
example as it's pretty much written in the style of a Poor-mans-C++-in-D.
But not breaking language compatibility between 2.068 and LATEST should
help reduce regressions between versions.  Most people I've talked to agree.

Iain.
Jul 20 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2015 8:47 PM, Iain Buclaw via Digitalmars-d wrote:

 3. Force stability language through codebase.  Maybe ddmd will be a bad example
 as it's pretty much written in the style of a Poor-mans-C++-in-D.  But not
 breaking language compatibility between 2.068 and LATEST should help reduce
 regressions between versions.  Most people I've talked to agree.


I agree it makes sense to stick with 2.068 to compile ddmd until gdc and ldc
can 
switch to ddmd.
Jul 20 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Tuesday, 21 July 2015 at 03:47:11 UTC, Iain Buclaw wrote:

 1. If you want ddmd to be compilable by both gdc and ldc then 
 you can't introduce any new features to the ddmd codebase post 
 conversion.


Sticking to 2.068 will help for some time but is not a long-term 
solution. Particularly when considering some of the bigger D 
issues left to resolve, we'll likely have to deal with some 
incompatibilities/deprecations.
Also consider that we might use the stable phobos parts.

I made a Trello card, let's discuss the details when we're 
actually working on this. 
https://trello.com/c/4NtxWDtK/30-compatibility-implications-for-self-hosting-d-compiler
Jul 20 2015
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 July 2015 at 08:19, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 21 July 2015 at 03:47:11 UTC, Iain Buclaw wrote:

 1. If you want ddmd to be compilable by both gdc and ldc then you can't
 introduce any new features to the ddmd codebase post conversion.



 Sticking to 2.068 will help for some time but is not a long-term solution.
 Particularly when considering some of the bigger D issues left to resolve,
 we'll likely have to deal with some incompatibilities/deprecations.
 Also consider that we might use the stable phobos parts.

 I made a Trello card, let's discuss the details when we're actually working
 on this.
 https://trello.com/c/4NtxWDtK/30-compatibility-implications-for-self-hosting-d-compiler


Phobos may not be a problem depending on what ends up being decided -
there have been both arguments for and against Phobos being used in
ddmd.

I certainly don't want to have bugs get in the way, so it is in my
interest to have some sort of backport window open for 2.068 as ddmd
transforms out of it's current design.

Iain
Jul 21 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2015 11:19 PM, Martin Nowak wrote:

 On Tuesday, 21 July 2015 at 03:47:11 UTC, Iain Buclaw wrote:

 1. If you want ddmd to be compilable by both gdc and ldc then you can't
 introduce any new features to the ddmd codebase post conversion.


 Sticking to 2.068 will help for some time but is not a long-term solution.
 Particularly when considering some of the bigger D issues left to resolve,
we'll
 likely have to deal with some incompatibilities/deprecations.
 Also consider that we might use the stable phobos parts.

 I made a Trello card, let's discuss the details when we're actually working on
 this.
 https://trello.com/c/4NtxWDtK/30-compatibility-implications-for-self-hosting-d-compiler


I don't see a reason to maintain 2.068 beyond the time that LDC and GDC migrate 
to ddmd.
Jul 21 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
Good intentions. Totally insane versioning scheme.
Jul 20 2015
prev sibling next sibling parent "sigod" <sigod.mail gmail.com> writes:
On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.


I like this idea.


 Perhaps we should name this 2.100, to signify such a milestone.


But hate version jumps.
Jul 20 2015
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 Perhaps we should name this 2.100, to signify such a milestone.


2.1 Sounds good!

But going forward can we stick to a sane versioning system like 
what dub uses:

http://semver.org/
Jul 20 2015
next sibling parent reply "sigod" <sigod.mail gmail.com> writes:
On Monday, 20 July 2015 at 11:45:31 UTC, Gary Willoughby wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 Perhaps we should name this 2.100, to signify such a milestone.


 2.1 Sounds good!


2.1.0 sounds even better. 2.100 - not.


 But going forward can we stick to a sane versioning system like 
 what dub uses:

 http://semver.org/


+1
Jul 20 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Monday, 20 July 2015 at 13:16:46 UTC, sigod wrote:

 On Monday, 20 July 2015 at 11:45:31 UTC, Gary Willoughby wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 Perhaps we should name this 2.100, to signify such a 
 milestone.


 2.1 Sounds good!


 2.1.0 sounds even better. 2.100 - not.


That'd probably cause confusion, people wondering if there'd been 
a mistake and an old version was put in the release. 2.7.0 would 
probably be better. Otherwise, +1 for semver.
Jul 20 2015
parent reply "sigod" <sigod.mail gmail.com> writes:
On Monday, 20 July 2015 at 13:52:16 UTC, Meta wrote:

 On Monday, 20 July 2015 at 13:16:46 UTC, sigod wrote:

 On Monday, 20 July 2015 at 11:45:31 UTC, Gary Willoughby wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 Perhaps we should name this 2.100, to signify such a 
 milestone.


 2.1 Sounds good!


 2.1.0 sounds even better. 2.100 - not.


 That'd probably cause confusion, people wondering if there'd 
 been a mistake and an old version was put in the release. 2.7.0 
 would probably be better. Otherwise, +1 for semver.


2.69.0 for DDMD release, then? Or does 3rd digit means PATCH 
version in current versioning system?
Jul 20 2015
parent reply "Meta" <jared771 gmail.com> writes:
On Monday, 20 July 2015 at 13:58:02 UTC, sigod wrote:

 2.69.0 for DDMD release, then? Or does 3rd digit means PATCH 
 version in current versioning system?


I don't really know how the current versioning system works. I 
think it just increments by 1 every release, and patches get .1, 
etc. added on.
Jul 20 2015
parent reply "sigod" <sigod.mail gmail.com> writes:
On Monday, 20 July 2015 at 14:07:12 UTC, Meta wrote:

 On Monday, 20 July 2015 at 13:58:02 UTC, sigod wrote:

 2.69.0 for DDMD release, then? Or does 3rd digit means PATCH 
 version in current versioning system?


 I don't really know how the current versioning system works. I 
 think it just increments by 1 every release, and patches get 
 .1, etc. added on.


Yes, you're right. I forgot about current version - 2.067.1
It seems not so different from semver.
Jul 20 2015
parent reply "Jack Stouffer" <jack jackstouffer.com> writes:
On Monday, 20 July 2015 at 14:31:38 UTC, sigod wrote:

 On Monday, 20 July 2015 at 14:07:12 UTC, Meta wrote:

 On Monday, 20 July 2015 at 13:58:02 UTC, sigod wrote:

 2.69.0 for DDMD release, then? Or does 3rd digit means PATCH 
 version in current versioning system?


 I don't really know how the current versioning system works. I 
 think it just increments by 1 every release, and patches get 
 .1, etc. added on.


 Yes, you're right. I forgot about current version - 2.067.1
 It seems not so different from semver.


It's missing the most important piece of semver, the fact that 
the major version number denotes backwards incompatible changes. 
If D were using semver, we would be somewhere between D10 and D15.
Jul 20 2015
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Monday, 20 July 2015 at 16:32:08 UTC, Jack Stouffer wrote:

 It's missing the most important piece of semver, the fact that 
 the major version number denotes backwards incompatible 
 changes. If D were using semver, we would be somewhere between 
 D10 and D15.


D2 is the product name. We're on major version 67 of D2. :P
Jul 20 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-07-20 18:32, Jack Stouffer wrote:


 It's missing the most important piece of semver, the fact that the major
 version number denotes backwards incompatible changes. If D were using
 semver, we would be somewhere between D10 and D15.


Since we're about to release 2.068.0, I would say D68 ;). I'm actually 
quite serious. Every single release since at least 2.050 has broken at 
least one of my projects.

-- 
/Jacob Carlborg
Jul 20 2015
prev sibling parent reply "Whatever" <wh ev.er> writes:
On Monday, 20 July 2015 at 11:45:31 UTC, Gary Willoughby wrote:

 2.1 Sounds good!


That version was already released in 2007 [1]. Version numbers 
are not floats, they are period separated lists of integers. So 
`assert(2.1 == 2.01 && 2.01 == 2.001);`. The leading zero is 
actually forbidden in several important places (such as Linux 
package version numbers), and is one of the more head-scratching 
stylistic choices in D. Bumping to 2.100 will appease those who 
insist on a three-digit second component for reasons I will never 
understand, and make it so that D versions can actually be 
uniformly represented everywhere they show up.

[1]: http://dlang.org/changelog.html#new2_001
Jul 20 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 20 July 2015 at 19:10, Whatever via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Monday, 20 July 2015 at 11:45:31 UTC, Gary Willoughby wrote:

 2.1 Sounds good!



 That version was already released in 2007 [1]. Version numbers are not
 floats, they are period separated lists of integers. So `assert(2.1 == 2.01
 && 2.01 == 2.001);`.


You might be able to get away with 2.001 == 2.0.01 and 2.1 == 2.1.00. :o)

On a serious note though, the versioning could be better, and I think
the current suggested version bump from Walter is a missed opportunity
to set things right.  To quote anther project leader though: "Let’s
face it - what’s the point of being in charge if you can’t pick the
bike shed color without holding a referendum on it?"

Iain
Jul 20 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2015 11:06 AM, Iain Buclaw via Digitalmars-d wrote:

 On a serious note though, the versioning could be better, and I think
 the current suggested version bump from Walter is a missed opportunity
 to set things right.  To quote anther project leader though: "Let’s
 face it - what’s the point of being in charge if you can’t pick the
 bike shed color without holding a referendum on it?"


I'm sad that this discussion on Evil Plans has so quickly turned into a deluge 
of posts bikeshedding a version number.
Jul 20 2015
next sibling parent reply "Brian Rogoff" <brogoff gmail.com> writes:
On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:


 I'm sad that this discussion on Evil Plans has so quickly 
 turned into a deluge of posts bikeshedding a version number.


Is there a timeline for this Evil Plan? What about bug fixes 
during the 2.068-2.069 period; are these deprioritized in favor 
of the translation?

It's pretty exciting! I hope that after the compiler is all 
D-ified, there'll be some work on building DMD from source so 
that it becomes a much simpler process.
Jul 20 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/20/2015 12:52 PM, Brian Rogoff wrote:

 Is there a timeline for this Evil Plan?


Not really, other than ASAP.



 What about bug fixes during the
 2.068-2.069 period; are these deprioritized in favor of the translation?


That's right. Trying to fix bugs while translating doesn't work very well. The 
idea is to get a 2.068 workalike to use as a baseline. Regressions can, of 
course, still be pushed to the 2.068 line.

That said, one can still post PR's for fixes. No reason to stop doing that.



 It's pretty exciting!


Me too!
Jul 20 2015
parent "Martin Nowak" <code dawg.eu> writes:
On Monday, 20 July 2015 at 23:01:26 UTC, Walter Bright wrote:

 That's right. Trying to fix bugs while translating doesn't work 
 very well. The idea is to get a 2.068 workalike to use as a 
 baseline. Regressions can, of course, still be pushed to the 
 2.068 line.

 That said, one can still post PR's for fixes. No reason to stop 
 doing that.


Please target the stable branch with regression fixes.
We might create a long term 2.068 branch before using stable for 
2.069.
Jul 20 2015
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:

 I'm sad that this discussion on Evil Plans has so quickly 
 turned into a deluge of posts bikeshedding a version number.


Hardly bikeshedding. The comments are merely pointing out that as 
it stands D doesn't follow any particular versioning style, 
making each release hard to understand in the big picture. No 
other language has these problems and usually use well 
documented, easily understandable versioning. a la 
http://semver.org
Jul 20 2015
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-07-20 22:28 GMT+02:00 Gary Willoughby via Digitalmars-d <
digitalmars-d puremagic.com>:


 On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:


 I'm sad that this discussion on Evil Plans has so quickly turned into a
 deluge of posts bikeshedding a version number.


 Hardly bikeshedding. The comments are merely pointing out that as it
 stands D doesn't follow any particular versioning style, making each
 release hard to understand in the big picture. No other language has these
 problems and usually use well documented, easily understandable versioning.
 a la http://semver.org


We do follow a versioning style: '2.MAJOR.PATCH'  (with major being 3
digits). It's not as good as SemVer, but better than it was few years ago,
and I have faith we'll end up following SemVer at some point.

Following SemVer strictly wouldn't solve the real problem: We'll go from
2.068, 2.069. 2.070.. to 3.0.0, 4.0.0, 5.0.0 and will soon end up playing
catch up with Chrome.
To follow SemVer we'll have to separate breaking changes from bugfixes
(including regressions) from new feature, and most likely work with
separate branches.. Martin already started to work on this and we're in a
nicer spot now, but it requires manpower.
Since we don't have 2 consecutive releases that don't break code, I see no
point in changing the version scheme at this point other than satisfying
the purists.

Having a focus for releases will hopefully mitigate that problem. But so
far most posts have been about "BTW we need that fixed" and "our versioning
scheme is broken".
Jul 20 2015
parent "HaraldZealot" <harald_zealot tut.by> writes:
On Monday, 20 July 2015 at 21:27:17 UTC, Mathias Lang wrote:

 We do follow a versioning style: '2.MAJOR.PATCH'  (with major 
 being 3 digits). It's not as good as SemVer, but better than it 
 was few years ago, and I have faith we'll end up following 
 SemVer at some point.

 Following SemVer strictly wouldn't solve the real problem: 
 We'll go from
 2.068, 2.069. 2.070.. to 3.0.0, 4.0.0, 5.0.0 and will soon end 
 up playing
 catch up with Chrome.
 To follow SemVer we'll have to separate breaking changes from 
 bugfixes
 (including regressions) from new feature, and most likely work 
 with
 separate branches.. Martin already started to work on this and 
 we're in a
 nicer spot now, but it requires manpower.
 Since we don't have 2 consecutive releases that don't break 
 code, I see no
 point in changing the version scheme at this point other than 
 satisfying
 the purists.

 Having a focus for releases will hopefully mitigate that 
 problem. But so far most posts have been about "BTW we need 
 that fixed" and "our versioning scheme is broken".


+100
Jul 21 2015
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:

 On 7/20/2015 11:06 AM, Iain Buclaw via Digitalmars-d wrote:

 On a serious note though, the versioning could be better, and 
 I think
 the current suggested version bump from Walter is a missed 
 opportunity
 to set things right.  To quote anther project leader though: 
 "Let’s
 face it - what’s the point of being in charge if you can’t 
 pick the
 bike shed color without holding a referendum on it?"


 I'm sad that this discussion on Evil Plans has so quickly 
 turned into a deluge of posts bikeshedding a version number.


The fact that you consider this bikeshedding is quite a highlight 
of the problem alone.
Jul 20 2015
next sibling parent reply "Temtaime" <temtaime gmail.com> writes:
DMD is a problem for all the D ecosystem.
It supports only x86, has a proprietary backend license, 
generates very, very slow and ugly code.

Only one feature : it's faster than ldc for example and it's only 
because 1.5 humans want to optimize ldc.

DMD should be dropped in favor of ldc.
Jul 20 2015
parent reply "ZombineDev" <valid_email he.re> writes:
On Monday, 20 July 2015 at 20:53:09 UTC, Temtaime wrote:

 DMD is a problem for all the D ecosystem.
 It supports only x86, has a proprietary backend license, 
 generates very, very slow and ugly code.

 Only one feature : it's faster than ldc for example and it's 
 only because 1.5 humans want to optimize ldc.

 DMD should be dropped in favor of ldc.


By your logic we should also drop support for Windows, since 
currently only DMD supports Windows well. It would be really 
stupid to focus on only one backend. Being backend agnostic is a 
far better objective. Why should anyone be tied to using _only_ 
LLVM? For example, AFAIK, GDC has far superior support for 
embedded platforms. Also having a reference implementation 
_different_ from GDC and LDC has advantages on its own.
DMD's backend isn't holding back GDC or LDC in any way. Nowadays 
there are quite few changes in that area so DMD's backend isn't 
stealing manpower that would otherwise go to LDC or GDC. 
Surprisingly, in the last few months I have the impression that 
DMD has far less codegen bugs than LDC and GDC, though I maybe 
wrong.
Jul 20 2015
parent reply "rsw0x" <anonymous anonymous.com> writes:
On Monday, 20 July 2015 at 21:25:22 UTC, ZombineDev wrote:

 On Monday, 20 July 2015 at 20:53:09 UTC, Temtaime wrote:

 DMD is a problem for all the D ecosystem.
 It supports only x86, has a proprietary backend license, 
 generates very, very slow and ugly code.

 Only one feature : it's faster than ldc for example and it's 
 only because 1.5 humans want to optimize ldc.

 DMD should be dropped in favor of ldc.


 By your logic we should also drop support for Windows, since 
 currently only DMD supports Windows well. It would be really 
 stupid to focus on only one backend. Being backend agnostic is 
 a far better objective. Why should anyone be tied to using 
 _only_ LLVM? For example, AFAIK, GDC has far superior support 
 for embedded platforms. Also having a reference implementation 
 _different_ from GDC and LDC has advantages on its own.
 DMD's backend isn't holding back GDC or LDC in any way. 
 Nowadays there are quite few changes in that area so DMD's 
 backend isn't stealing manpower that would otherwise go to LDC 
 or GDC. Surprisingly, in the last few months I have the 
 impression that DMD has far less codegen bugs than LDC and GDC, 
 though I maybe wrong.


because versions are released with GDC and LDC lagging 2-3 
versions behind, when DMD is unusable for production quality 
codegen.

2.068 is almost out and GDC and LDC both only support 2.066. 
Until D decides to adopt either GDC or LDC as a real backend, 
this will never be fixed.
Jul 20 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:

 because versions are released with GDC and LDC lagging 2-3 
 versions behind, when DMD is unusable for production quality 
 codegen.

 2.068 is almost out and GDC and LDC both only support 2.066. 
 Until D decides to adopt either GDC or LDC as a real backend, 
 this will never be fixed.


Unifying the frontend will go a long way towards fixing this 
problem, and Daniel is working on that right now. He's aiming to 
make it so that the frontend is identical across all three 
compilers so that the ldc and gdc developers don't have to fork 
it like they do now.

- Jonathan M Davis
Jul 20 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 Jul 2015 00:45, "Jonathan M Davis via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:

 because versions are released with GDC and LDC lagging 2-3 versions




behind, when DMD is unusable for production quality codegen.

 2.068 is almost out and GDC and LDC both only support 2.066. Until D




decides to adopt either GDC or LDC as a real backend, this will never be
fixed.

 Unifying the frontend will go a long way towards fixing this problem, and


Daniel is working on that right now. He's aiming to make it so that the
frontend is identical across all three compilers so that the ldc and gdc
developers don't have to fork it like they do now.


Hardly. All he can take credit for is removing the virtual method interface
and replacing them with visitors (which can be described as no small job,
but benefitted more towards ddmd).

Everything else has been a slow, tedious three year job from yours truly to
remove all x86-isms and platform-specific handling out of the frontend.

There are a more than a few last leg things to be done, some are in PRs
raised by me, but or not being looked at, or understood properly.

Example, I moved underscore prefixing hacks for OSX out of the frontend
(every single one broke GDC ABI in one way or another) and into Target.
Then Walter slams it for being pointless refactoring.

Target is a concept raised at DConf 2013 where I bounced the idea that all
uses of global.params.isXXX should be removed from the frontend as all are
there to only address a perk of DMD when targeting that platform.  The end
goal then becomes to make it so that instead of asking 'Is my target OSX?',
what the frontend should be asking is 'Does the target add prefixes to
symbols?'

I shouldn't have to explain why the latter benefits all.

Iain



 Jul 20 2015



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Tuesday, 21 July 2015 at 03:19:16 UTC, Iain Buclaw wrote:

 On 21 Jul 2015 00:45, "Jonathan M Davis via Digitalmars-d" < 
 digitalmars-d puremagic.com> wrote:

 On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:

 because versions are released with GDC and LDC lagging 2-3 
 versions




 behind, when DMD is unusable for production quality codegen.

 2.068 is almost out and GDC and LDC both only support 2.066. 
 Until D




 decides to adopt either GDC or LDC as a real backend, this will 
 never be fixed.

 Unifying the frontend will go a long way towards fixing this 
 problem, and


 Daniel is working on that right now. He's aiming to make it so 
 that the frontend is identical across all three compilers so 
 that the ldc and gdc developers don't have to fork it like they 
 do now.


 Hardly. All he can take credit for is removing the virtual 
 method interface and replacing them with visitors (which can be 
 described as no small job, but benefitted more towards ddmd).

 Everything else has been a slow, tedious three year job from 
 yours truly to remove all x86-isms and platform-specific 
 handling out of the frontend.


Sorry. I was not trying to take credit away from you or anyone 
else. I just know that Daniel considers getting the frontend to 
the point that it's identical across all three compilers to be 
the top priority, and as of dconf at least, that's what he was 
focusing on. I mentioned him, because I knew he was working on it.

I'm certainly grateful for the stuff that you've done, though 
admittedly, I don't keep up with what's happening with any of the 
compilers very well, so you're bound to have done a lot more than 
I'm aware of.


 There are a more than a few last leg things to be done, some 
 are in PRs raised by me, but or not being looked at, or 
 understood properly.

 Example, I moved underscore prefixing hacks for OSX out of the 
 frontend (every single one broke GDC ABI in one way or another) 
 and into Target. Then Walter slams it for being pointless 
 refactoring.

 Target is a concept raised at DConf 2013 where I bounced the 
 idea that all uses of global.params.isXXX should be removed 
 from the frontend as all are there to only address a perk of 
 DMD when targeting that platform.  The end goal then becomes to 
 make it so that instead of asking 'Is my target OSX?', what the 
 frontend should be asking is 'Does the target add prefixes to 
 symbols?'

 I shouldn't have to explain why the latter benefits all.


Yeah. Walter seems surprisingly resistant to making changes that 
make the frontend identical across the three compilers. David and 
Daniel were arguing with him over something related to that at 
dconf and were having a hard time getting him to even consider it 
(though in that case, it was because he was afraid it would slow 
the compiler down rather being an issue with refactoring). In 
your case, you might have had bad timing (depending on when your 
work was rejected), since just prior to dconf Walter was getting 
annoyed with the higher than normal number of regressions and 
decided that excessive refactoring was to blame (which it may or 
may not have been), which would tend to make him a lot more 
resistant to accepting refactoring even with a good reason. 
Hopefully, he can be convinced of it at some point.

- Jonathan M Davis



 Jul 20 2015



  parent  "Suliman" <evermind live.ru>  writes:


Maybe it's really better to jump ddmd to 2.1 version and stay 
2.06+ for compatibility purpose? The something similar was with 
D1 time, when for a long times it's get new updates.



 Jul 20 2015



prev sibling  parent reply Johannes Pfau <nospam example.com>  writes:


Am Tue, 21 Jul 2015 05:10:45 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 21 Jul 2015 00:45, "Jonathan M Davis via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:

 On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:

 because versions are released with GDC and LDC lagging 2-3 versions




 behind, when DMD is unusable for production quality codegen.

 2.068 is almost out and GDC and LDC both only support 2.066. Until
 D




 decides to adopt either GDC or LDC as a real backend, this will never
 be fixed.

 Unifying the frontend will go a long way towards fixing this
 problem, and


 Daniel is working on that right now. He's aiming to make it so that
 the frontend is identical across all three compilers so that the ldc
 and gdc developers don't have to fork it like they do now.


 
 Hardly. All he can take credit for is removing the virtual method
 interface and replacing them with visitors (which can be described as
 no small job, but benefitted more towards ddmd).
 
 Everything else has been a slow, tedious three year job from yours
 truly to remove all x86-isms and platform-specific handling out of
 the frontend.
 
 There are a more than a few last leg things to be done, some are in
 PRs raised by me, but or not being looked at, or understood properly.
 
 Example, I moved underscore prefixing hacks for OSX out of the
 frontend (every single one broke GDC ABI in one way or another) and
 into Target. Then Walter slams it for being pointless refactoring.
 
 Target is a concept raised at DConf 2013 where I bounced the idea
 that all uses of global.params.isXXX should be removed from the
 frontend as all are there to only address a perk of DMD when
 targeting that platform.  The end goal then becomes to make it so
 that instead of asking 'Is my target OSX?', what the frontend should
 be asking is 'Does the target add prefixes to symbols?'
 
 I shouldn't have to explain why the latter benefits all.
 
 Iain
 


That also summarizes my biggest doubts regarding frontend unification:
We have quite some DMD-backend-specific stuff in the shared frontend
(profiler, ...) and nobody complained about that. OTOH adding GDC

always met with scepticism.

Such gdc-specific frontend changes are fortunately rare. But with our
own frontend fork we can simply commit them. With a unified frontend
we'll have to spent hours convincing dmd devs that we need these
changes for GDC.



 Jul 21 2015



  parent  Martin Nowak <code+news.digitalmars dawg.eu>  writes:


On 07/21/2015 09:47 AM, Johannes Pfau wrote:

 Such gdc-specific frontend changes are fortunately rare. But with our
 own frontend fork we can simply commit them. With a unified frontend
 we'll have to spent hours convincing dmd devs that we need these
 changes for GDC.


I understand that it's sometimes frustrating to spend hours convincing
somebody of a seemingly obvious change. But please bear in mind that
communication is the foundation for collaboration.
The only sustainable way to raise awareness for gdc/ldc implications of
dmd changes is to explain why something needs to be done differently.
I think the Target pattern is a good example for a design decision
making gdc/ldc related differences visible in the dmd frontend.

Of course it's possible to just fork the frontend and pave your own way,
but in the interest of alternative compilers I'd rather see more
involvement of you in dmd development to help identify issues upfront.
A good improvement would be to continously merge the dmd frontend during
gdc development. Right now we only get feedback (if any) for issues long
after the changes have been released.

TL;DR The reason you have to convince dmd devs is b/c we have no idea
what you're doing and you don't tell us.



 Jul 23 2015



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/20/15 4:42 PM, Dicebot wrote:

 On Monday, 20 July 2015 at 19:30:36 UTC, Walter Bright wrote:

 On 7/20/2015 11:06 AM, Iain Buclaw via Digitalmars-d wrote:

 On a serious note though, the versioning could be better, and I think
 the current suggested version bump from Walter is a missed opportunity
 to set things right.  To quote anther project leader though: "Let’s
 face it - what’s the point of being in charge if you can’t pick the
 bike shed color without holding a referendum on it?"


 I'm sad that this discussion on Evil Plans has so quickly turned into
 a deluge of posts bikeshedding a version number.


 The fact that you consider this bikeshedding is quite a highlight of the
 problem alone.


I, too, think we devote too much attention to the picayune. There's a 
lot of interesting stuff in Walter's post, yet most discussion focused 
on a side remark. -- Andrei



 Jul 20 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Monday, 20 July 2015 at 21:02:38 UTC, Andrei Alexandrescu 
wrote:

 I, too, think we devote too much attention to the picayune. 
 There's a lot of interesting stuff in Walter's post, yet most 
 discussion focused on a side remark. -- Andrei


Agreed. Maybe we should change how we do versioning, maybe not. 
But it is disappointing that almost the entirety of the 
discussion has been on changing the versioning scheme rather than 
the cool stuff that the original post was about.

- Jonathan M Davis



 Jul 20 2015



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 20 July 2015 at 21:02:38 UTC, Andrei Alexandrescu 
wrote:

 I, too, think we devote too much attention to the picayune. 
 There's a lot of interesting stuff in Walter's post, yet most 
 discussion focused on a side remark. -- Andrei


And I see this as typical "two steps forward, one step back" case 
which tends to be the trend in later D development. Meaningless 
versioning scheme makes hard to both implement breaking changes 
in industry-friendly manner (every single release becomes 
breaking) and reason about support cycle of specific feature set 
(major headache with gdc inclusion into gcc which means version 
freeze).



 Jul 20 2015



prev sibling next sibling parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 7/20/2015 2:02 PM, Andrei Alexandrescu wrote:

 I, too, think we devote too much attention to the picayune. There's a lot of
 interesting stuff in Walter's post, yet most discussion focused on a side
 remark. -- Andrei


Yah, it was a throwaway comment I thought of while I was typing in the post. I 
should have known better :-)



 Jul 20 2015



prev sibling  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 07/20/2015 05:02 PM, Andrei Alexandrescu wrote:

 I, too, think we devote too much attention to the picayune. There's a
 lot of interesting stuff in Walter's post, yet most discussion focused
 on a side remark. -- Andrei


We worry too much about that. I don't mind bikeshedding so much as 
bikeshedding *about* bikeshedding.

I don't think anyone *has* anything to say about the real meat of the 
original post beyond just "Yes, sounds good, +1, etc." There's nothing 
anyone disagrees with, there's nothing anyone is uncertain or unclear 
about, and therefore there is nothing to say on those matters. 
Discussion only occurs when there *isn't* universal understanding and 
agreement.



 Jul 21 2015



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2015-07-20 06:02, Walter Bright wrote:


 2.069 - translate to D.


This should absolutely be our main focus, to finish the D port.

-- 
/Jacob Carlborg



 Jul 20 2015



prev sibling next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.

 Perhaps we should name this 2.100, to signify such a milestone.

 2.101+ -
 1. Take advantage of D features to improve quality.
 2. Go to full lazy semantic analysis of imports, rather than 
 the current "analyze them all"
 3. Rethink what "speculative instantiation" of templates means 
 so we can have a coherent process of compiling them.
 4. Redo CTFE interpreter so it only rarely needs to allocate 
 memory. This was already done for constant folding, but now 
 it's time for the rest of the interpreter.
 5. Get rid of reliance on the global error count. This has been 
 mostly done, it just hast to be finished.
 6. Convert the back end to D as well.


It'll be fantastic to get a lot of that done. The CTFE 
improvements in particular are likely to be huge. It'll be 
interesting to see how much faster some of the compiler 
improvements will get done once we don't have to worry about 
maintaining it in C++ anymore.

One big item that we've never quite managed to get far with is 
removing opEquals, opCmp, toString, and toHash from Object:

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

Without that, attributes on classes are kind of borked - 
particularly with regards to const. As it is, druntime is 
violating the type system by casting away const to compare const 
Objects.

Making that work without breaking code is going to require some 
changes in both dmd and druntime (probably including the work on 
AAs that Martin's been working on), and it'll likely be fairly 
interesting to pull off, but I think that it's pretty clear that 
we need to find a way to do it if we don't want classes to be too 
restrictive with regards to attributes - both with regards to 
which ones are permitted and which ones are required.

- Jonathan M Davis



 Jul 20 2015



prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

How is this evil? This seems very good :)


 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.


YAY, I have been wanting to learn how the compiler works for a 
while but have been to lazy and don't want to look at so much 
c++, having to be in D will make diggin into it so much more 
attractive.

Also seems like the compiler as a library is not too far away, is 
that going to be apart of the plan eventually?


 Perhaps we should name this 2.100, to signify such a milestone.


Your the boss, I dont gaf what the version numbers are.


 2.101+ -
 1. Take advantage of D features to improve quality.


Again, yay...


 2. Go to full lazy semantic analysis of imports, rather than 
 the current "analyze them all"


What effects will this have? Faster compile times? Smaller 
binaires?


 3. Rethink what "speculative instantiation" of templates means 
 so we can have a coherent process of compiling them.


Sounds complicated... what effects will this have? Simpler 
internals? What effects for end user?


 4. Redo CTFE interpreter so it only rarely needs to allocate 
 memory. This was already done for constant folding, but now 
 it's time for the rest of the interpreter.


Oh god yes


 5. Get rid of reliance on the global error count. This has been 
 mostly done, it just hast to be finished.


No idea what this is referring to..


 6. Convert the back end to D as well.


<3

This all seems very not evil.

One question I have, are there any plans for a language clean up 
of sorts, there are a bunch of little features and some big that 
don't really make sense anymore. D is starting to feel like it's 
going down the road of c++ with lots of baggage and unwillingness 
to get rid of old features even if they are discouraged from use, 
all for the sake of backwards compatibility. I know D has been 
getting progressively more reserved about breaking changes, do 
you see that changing any time in the future? 1 year? 3 years? 
Would automatic conversion tools make you more willing to break 
things?



 Jul 20 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 7/20/2015 1:52 PM, Tofu Ninja wrote:

 Also seems like the compiler as a library is not too far away, is that going to
 be apart of the plan eventually?


Yes.



 2. Go to full lazy semantic analysis of imports, rather than the current
 "analyze them all"


 What effects will this have? Faster compile times? Smaller binaires?


Yes.



 3. Rethink what "speculative instantiation" of templates means so we can have
 a coherent process of compiling them.


 Sounds complicated... what effects will this have? Simpler internals? What
 effects for end user?


Mainly fewer compiler bugs.



 This all seems very not evil.


Not evil enough? I have failed!



 One question I have, are there any plans for a language clean up of sorts,
there
 are a bunch of little features and some big that don't really make sense
 anymore. D is starting to feel like it's going down the road of c++ with lots
of
 baggage and unwillingness to get rid of old features even if they are
 discouraged from use, all for the sake of backwards compatibility. I know D has
 been getting progressively more reserved about breaking changes, do you see
that
 changing any time in the future? 1 year? 3 years? Would automatic conversion
 tools make you more willing to break things?


I think we're kinda stuck there.



 Jul 20 2015



prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.068 - resolve remaining regressions and release

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.


Releasing ddmd with dmd's current backend results in a ~20-30% 
slowdown s we'd have to compile ddmd with gdc or ldc to make this 
feasible.



 Jul 20 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/20/2015 1:58 PM, Martin Nowak wrote:

 Releasing ddmd with dmd's current backend results in a ~20-30% slowdown s we'd
 have to compile ddmd with gdc or ldc to make this feasible.


First we have to make sure we know why it is slower.



 Jul 20 2015



  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 23:20:58 UTC, Walter Bright wrote:

 First we have to make sure we know why it is slower.


I got this number from Daniel, he didn't found a reason.
Chances are it's uniformly slower because of dmd's backend, but 
of course profiling might help.



 Jul 20 2015



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/20/2015 11:34 PM, Martin Nowak wrote:

 I got this number from Daniel, he didn't found a reason.
 Chances are it's uniformly slower because of dmd's backend, but of course
 profiling might help.


Consider that the Win32 version of dmd is built with with the same backend as 
dmd. If there's a slowdown with that version, it isn't due to the backend.



 Jul 21 2015



 next sibling parent reply Johannes Pfau <nospam example.com>  writes:


Am Tue, 21 Jul 2015 01:54:44 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:


 On 7/20/2015 11:34 PM, Martin Nowak wrote:

 I got this number from Daniel, he didn't found a reason.
 Chances are it's uniformly slower because of dmd's backend, but of
 course profiling might help.


 
 Consider that the Win32 version of dmd is built with with the same
 backend as dmd. If there's a slowdown with that version, it isn't due
 to the backend.


"On Win32 the performance difference is much smaller, because it's
going from compiling with dmc to compiling with dmd"

https://youtu.be/5daHGXSetXk?t=2438



 Jul 21 2015



  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 21 July 2015 at 11:04, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Tue, 21 Jul 2015 01:54:44 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:


 On 7/20/2015 11:34 PM, Martin Nowak wrote:

 I got this number from Daniel, he didn't found a reason.
 Chances are it's uniformly slower because of dmd's backend, but of
 course profiling might help.


 Consider that the Win32 version of dmd is built with with the same
 backend as dmd. If there's a slowdown with that version, it isn't due
 to the backend.


 "On Win32 the performance difference is much smaller, because it's
 going from compiling with dmc to compiling with dmd"


You beat me to it....



 Jul 21 2015



prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Tuesday, 21 July 2015 at 08:54:43 UTC, Walter Bright wrote:

 Consider that the Win32 version of dmd is built with with the 
 same backend as dmd. If there's a slowdown with that version, 
 it isn't due to the backend.


Talking about compiler speed, we can get an easy 10% speedup 
using PGO+LTO.
https://github.com/D-Programming-Language/dmd/pull/4651



 Jul 21 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 7/21/2015 4:31 AM, Martin Nowak wrote:

 Talking about compiler speed, we can get an easy 10% speedup using PGO+LTO.
 https://github.com/D-Programming-Language/dmd/pull/4651


The PR needs to be updated.



 Jul 21 2015



prev sibling  parent  ketmar <ketmar ketmar.no-ip.org>  writes:


On Tue, 21 Jul 2015 01:54:44 -0700, Walter Bright wrote:


 On 7/20/2015 11:34 PM, Martin Nowak wrote:

 I got this number from Daniel, he didn't found a reason.
 Chances are it's uniformly slower because of dmd's backend, but of
 course profiling might help.


=20
 Consider that the Win32 version of dmd is built with with the same
 backend as dmd. If there's a slowdown with that version, it isn't due to
 the backend.


DMC version of DMD is noticably slower on building phobos than MinGW=20
version. i'm using HEAD built with MinGW with wine, and the difference=20
can be noticed with my eyes. i didn't measure that with "time", though.

so backend is surely plays a role here.=



 Jul 23 2015



prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.101+ -
 1. Take advantage of D features to improve quality.


Great for thing with good test coverage. Will hopefully attract 
more contributors.


 2. Go to full lazy semantic analysis of imports, rather than 
 the current "analyze them all"


Good for compilation speed, but sound very work intensive.
Maybe do an 80/20 solution instead?

We have a few more important compiler issue, such as 313+314.


 3. Rethink what "speculative instantiation" of templates means 
 so we can have a coherent process of compiling them.


Longstanding issue, particularly for separate compilation and 
when compiling to multiple object files.


 4. Redo CTFE interpreter so it only rarely needs to allocate 
 memory. This was already done for constant folding, but now 
 it's time for the rest of the interpreter.


High priority task.


 5. Get rid of reliance on the global error count. This has been 
 mostly done, it just hast to be finished.


Sure


 6. Convert the back end to D as well.


Waste of time IMO, there is nothing to gain here.



 Jul 20 2015



  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 21:10:57 UTC, Martin Nowak wrote:

 6. Convert the back end to D as well.


 Waste of time IMO, there is nothing to gain here.


- We already have a working C++ backend and can interface that 
from ddmd, the other compilers will have to work with a C++ 
interface anyhow.
   Just translating doesn't improve anything for D users.

- The backend generates pretty bad code, we'll never be able to 
catch up with good optimizers. Why should we invest in an 
outdated backend?

- Bugs in the backend are among the worst for users and time 
consuming to fix. Translating the backend risks to introduce new 
bugs.



 Jul 22 2015



  parent  ketmar <ketmar ketmar.no-ip.org>  writes:


On Wed, 22 Jul 2015 12:17:21 +0000, Martin Nowak wrote:


 - The backend generates pretty bad code, we'll never be able to catch up
 with good optimizers. Why should we invest in an outdated backend?


the one reason is that it's small and doesn't require 3rd-party libraries=20
to build. while it's not the best backend out here, change-compile-full-
rebuild cycle is very fast for DMD, and doesn't require to install gcc=20
sources or llvm.

yet i'm not sure that this reason will outweigh the translation and=20
maintenance burden.=



 Jul 23 2015



prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.101+ -


This sounds like workload for the rest of the year.
Are you sure that the CTFE interpreter and compilation speed are 
the 2 most important issues?
They are definitely very high priority, but I'd also like us to 
address all the import (313+314) and protection issues (DIP22) 
this year.



 Jul 20 2015



 next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Monday, 20 July 2015 at 21:24:59 UTC, Martin Nowak wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.101+ -


 This sounds like workload for the rest of the year.
 Are you sure that the CTFE interpreter and compilation speed 
 are the 2 most important issues?
 They are definitely very high priority, but I'd also like us to 
 address all the import (313+314) and protection issues (DIP22) 
 this year.


What's the hold up on those anyway? I thought that Kenji had a PR 
that sorted them out. In fact, I thought that someone at dconf 
said something about those changes being merged in already 
(though maybe I'm misremembering). I take it that there were 
outstanding issues with the PR that have made it so that it 
hasn't gotten in yet? Or maybe it only fixed some of the issues?

Regardless, it's a serious issue, particularly in light of how 
easy it is to break existing code with unrelated changes thanks 
to how private is dealt with currently.

- Jonathan M Davis



 Jul 20 2015



  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 21:38:35 UTC, Jonathan M Davis wrote:

 What's the hold up on those anyway? I thought that Kenji had a 
 PR that sorted them out. In fact, I thought that someone at 
 dconf said something about those changes being merged in 
 already (though maybe I'm misremembering). I take it that there 
 were outstanding issues with the PR that have made it so that 
 it hasn't gotten in yet? Or maybe it only fixed some of the 
 issues?


We have a PR from Kenji, that fixes 313+314.
https://github.com/D-Programming-Language/dmd/pull/3407

It's a major change of the import system, so it needs a thorough 
review and we also need to mitigate the code breakage impact of 
this change.


 Regardless, it's a serious issue, particularly in light of how 
 easy it is to break existing code with unrelated changes thanks 
 to how private is dealt with currently.


Those 2 issues have nothing to do with visibility of imported 
private symbols. There is DIP22 and a few outstanding protection 
checks.



 Jul 20 2015



 next sibling parent  "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Monday, 20 July 2015 at 21:49:01 UTC, Martin Nowak wrote:

 Those 2 issues have nothing to do with visibility of imported 
 private symbols. There is DIP22 and a few outstanding 
 protection checks.


I thought that one of them did. Clearly, I misremembered. 
Regardless, both of those issues and DIP22 definitely need to be 
sorted out, and it is kind of embarrassing that it's taken this 
long, but we're not exactly the quickest with getting stuff 
done... :(

- Jonathan M Davis



 Jul 20 2015



prev sibling  parent  ketmar <ketmar ketmar.no-ip.org>  writes:


On Mon, 20 Jul 2015 21:49:00 +0000, Martin Nowak wrote:


 We have a PR from Kenji, that fixes 313+314.
 https://github.com/D-Programming-Language/dmd/pull/3407
=20
 It's a major change of the import system, so it needs a thorough review
 and we also need to mitigate the code breakage impact of this change.


at least for phobos, it breaks almost nothing. and where it does some=20
breckage, it identifies invalid code that relies on import bugs anyway.

the same with some projects i tried to build, like deadcode, for example=20
(which is fairly big): this PR breaks only invalid code, i.e. code that=20
relies on current buggy import and should be fixed anyway.

yet, there is surprisingly small amount of such code, literally along 10=20
or so patches for phobos (and that number constantly decreases), and not=20
much more for deadcode (but for deadcode the fixes was a little more=20
complicated, as i have to add some qualifiers in some modules).

i'm using DMD with that patch incorporated for more a year now, and got=20
no problems with code that doesn't rely on import bugs.=



 Jul 23 2015



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 7/20/2015 2:24 PM, Martin Nowak wrote:

 On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.101+ -


 This sounds like workload for the rest of the year.
 Are you sure that the CTFE interpreter and compilation speed are the 2 most
 important issues?
 They are definitely very high priority, but I'd also like us to address all the
 import (313+314) and protection issues (DIP22) this year.


What is high priority is certainly debatable, but what is most clear to me is 
that transitioning to D source code has finally bubbled to the top of the
stack. 
I strongly believe that D source code will enable us to simplify the front end 
and improve its quality substantially, which will help with everything else we 
want to improve.

And if it doesn't, we should be reevaluating what we're doing with D :-)



 Jul 20 2015



  parent  "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 23:11:57 UTC, Walter Bright wrote:

 They are definitely very high priority, but I'd also like us 
 to address all the
 import (313+314) and protection issues (DIP22) this year.


 What is high priority is certainly debatable, but what is most 
 clear to me is that transitioning to D source code has finally 
 bubbled to the top of the stack.


It makes sense to spent quite some time on the D transition b/c 
it's feasible, thanks to Daniel's work, and might have a good 
impact on compiler contributions.
Still we should have that debate and prioritize the bigger 
remaining D issues, e.g. for the 2015H2 vision.



 Jul 20 2015



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:

 2.069 - translate to D. No new features, no refactoring. Only 
 regression fixes and what's already in HEAD. This should give 
 us a solid baseline. It also means that open PRs that address 
 other issues will not be pulled for 2.069.


I still have a lot WIP for the GC, RefCounted, and Unique.
So I hope you only mean dmd with this restriction.



 Jul 20 2015



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 7/20/2015 2:51 PM, Martin Nowak wrote:

 I still have a lot WIP for the GC, RefCounted, and Unique.
 So I hope you only mean dmd with this restriction.


Right, the library should not be affected.



 Jul 20 2015