www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - State of Play

reply Mike James <foo bar.com> writes:
What is the state of play with D1.0 vs. D2.0?

Is D1.0 a dead-end and D2.0 should be used for future projects?

Is D2.0 stable enough for use at the present?

Is Tango for D2.0 at a level of D1.0 and can be used now?

Is DWT ready for D2.0 now?


Regards, mike.
Mar 26 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Mike James escribió:

 What is the state of play with D1.0 vs. D2.0?
 
 Is D1.0 a dead-end and D2.0 should be used for future projects?
 
 Is D2.0 stable enough for use at the present?
 
 Is Tango for D2.0 at a level of D1.0 and can be used now?
 
 Is DWT ready for D2.0 now?
 
 
 Regards, mike.


I don't know why a lot of people see D1.0 as a dead-end. It's a stable 
language. It won't get new features. It won't change. It'll probably 
receive bug fixes. It works. It gets the job done. You can use it and be 
sure than in a time all of what you did will still be compatible with 
"newer" versions of D1.

D2 is not stable enough yet, in my opinion. It's an experiment. So you 
use it just for experimentation. You woudln't write a library for it if 
you know that in two weeks some of what you did will not compile anymore.

I see D1 as something finished and working and for which it's worth 
writing libraries and tools, because who knows when a stable, final D2 
version will be out there. And when it'll finally be here, what? You'd 
say it's a dead end because D3 is out for experiment? :-P
Mar 26 2009
parent reply ValeriM <Valeri.Mytinski gmail.com> writes:
Ary Borenszweig Wrote:


 Mike James escribió:

 What is the state of play with D1.0 vs. D2.0?
 
 Is D1.0 a dead-end and D2.0 should be used for future projects?
 
 Is D2.0 stable enough for use at the present?
 
 Is Tango for D2.0 at a level of D1.0 and can be used now?
 
 Is DWT ready for D2.0 now?
 
 
 Regards, mike.


 
 I don't know why a lot of people see D1.0 as a dead-end. It's a stable 
 language. It won't get new features. It won't change. It'll probably 
 receive bug fixes. It works. It gets the job done. You can use it and be 
 sure than in a time all of what you did will still be compatible with 
 "newer" versions of D1.


No. It's not stable.
Try to build last Tango and DWT releases with D1.041 and you will get the
problems.

That is the causes a lot of people ask such questions. And I too. Not because
D1.0 dead-end. But because I can't understand what is "stable" toolset and how
long it would be "stable". D+Tango+DWT is a good example.

Regards, valeri.
Mar 26 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
ValeriM wrote:

 Ary Borenszweig Wrote:
 

 Mike James escribi�:

 What is the state of play with D1.0 vs. D2.0?

 Is D1.0 a dead-end and D2.0 should be used for future projects?

 Is D2.0 stable enough for use at the present?

 Is Tango for D2.0 at a level of D1.0 and can be used now?

 Is DWT ready for D2.0 now?


 Regards, mike.


 I don't know why a lot of people see D1.0 as a dead-end. It's a stable 
 language. It won't get new features. It won't change. It'll probably 
 receive bug fixes. It works. It gets the job done. You can use it and be 
 sure than in a time all of what you did will still be compatible with 
 "newer" versions of D1.


 
 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.


"It's a stable language."

Note the use of the word "language."

What you're referring to are bugs in the compiler.  It happens.

  -- Daniel
Mar 26 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Daniel Keep wrote:

 
 ValeriM wrote:

 Ary Borenszweig Wrote:


 Mike James escribi�:

 What is the state of play with D1.0 vs. D2.0?

 Is D1.0 a dead-end and D2.0 should be used for future projects?

 Is D2.0 stable enough for use at the present?

 Is Tango for D2.0 at a level of D1.0 and can be used now?

 Is DWT ready for D2.0 now?


 Regards, mike.


 I don't know why a lot of people see D1.0 as a dead-end. It's a stable 
 language. It won't get new features. It won't change. It'll probably 
 receive bug fixes. It works. It gets the job done. You can use it and be 
 sure than in a time all of what you did will still be compatible with 
 "newer" versions of D1.


 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.


 
 "It's a stable language."
 
 Note the use of the word "language."
 
 What you're referring to are bugs in the compiler.  It happens.
 
   -- Daniel


But ValieriM has a point. If I code, say, a library in D 1.041 only to 
find out that in a couple of months it won't compile anymore in D 1.045, 
that's not good at all. That's when someone sends a message to the 
newsgroups saying "I just downloaded library Foo, but it won't compile 
with D 1.045... is it abandoned? Why isn't it maintained? D1 is broken". 
The point is, you shouldn't need to maintain libraries for D1 anymore. 
Maybe the test suite for D1 should be bigger to cover more cases...
Mar 26 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Ary Borenszweig (ary esperanto.org.ar)'s article

 Daniel Keep wrote:

 ValeriM wrote:

 Ary Borenszweig Wrote:


 Mike James escribi�:

 What is the state of play with D1.0 vs. D2.0?

 Is D1.0 a dead-end and D2.0 should be used for future projects?

 Is D2.0 stable enough for use at the present?

 Is Tango for D2.0 at a level of D1.0 and can be used now?

 Is DWT ready for D2.0 now?


 Regards, mike.


 I don't know why a lot of people see D1.0 as a dead-end. It's a stable
 language. It won't get new features. It won't change. It'll probably
 receive bug fixes. It works. It gets the job done. You can use it and be
 sure than in a time all of what you did will still be compatible with
 "newer" versions of D1.


 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the






problems.

 "It's a stable language."

 Note the use of the word "language."

 What you're referring to are bugs in the compiler.  It happens.

   -- Daniel


 But ValieriM has a point. If I code, say, a library in D 1.041 only to
 find out that in a couple of months it won't compile anymore in D 1.045,
 that's not good at all. That's when someone sends a message to the
 newsgroups saying "I just downloaded library Foo, but it won't compile
 with D 1.045... is it abandoned? Why isn't it maintained? D1 is broken".
 The point is, you shouldn't need to maintain libraries for D1 anymore.
 Maybe the test suite for D1 should be bigger to cover more cases...


Yes, but there's a difference between being broken in some trivial way that
requires a few greps and a recompile and being broken in a way that requires
people to actually review and possibly redesign parts of the code to fix it.  I
really don't see how the former is a big deal.
Mar 26 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
dsimcha wrote:

 == Quote from Ary Borenszweig (ary esperanto.org.ar)'s article

 Daniel Keep wrote:

 ValeriM wrote:

 Ary Borenszweig Wrote:


 Mike James escribi�:

 What is the state of play with D1.0 vs. D2.0?

 Is D1.0 a dead-end and D2.0 should be used for future projects?

 Is D2.0 stable enough for use at the present?

 Is Tango for D2.0 at a level of D1.0 and can be used now?

 Is DWT ready for D2.0 now?


 Regards, mike.


 I don't know why a lot of people see D1.0 as a dead-end. It's a stable
 language. It won't get new features. It won't change. It'll probably
 receive bug fixes. It works. It gets the job done. You can use it and be
 sure than in a time all of what you did will still be compatible with
 "newer" versions of D1.


 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the






 problems.

 "It's a stable language."

 Note the use of the word "language."

 What you're referring to are bugs in the compiler.  It happens.

   -- Daniel


 But ValieriM has a point. If I code, say, a library in D 1.041 only to
 find out that in a couple of months it won't compile anymore in D 1.045,
 that's not good at all. That's when someone sends a message to the
 newsgroups saying "I just downloaded library Foo, but it won't compile
 with D 1.045... is it abandoned? Why isn't it maintained? D1 is broken".
 The point is, you shouldn't need to maintain libraries for D1 anymore.
 Maybe the test suite for D1 should be bigger to cover more cases...


 
 Yes, but there's a difference between being broken in some trivial way that
 requires a few greps and a recompile and being broken in a way that requires
 people to actually review and possibly redesign parts of the code to fix it.  I
 really don't see how the former is a big deal.



reference it and it works. If I had to fix something for it to work, I 
woudldn't use it. Mainly because to fix it I'd had to understand the 
code, and I just want to understand the interface.

If you have to modify a library when you download it just to make it 
work (not to tweak it), that's a huge problem for me.
Mar 26 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Ary Borenszweig (ary esperanto.org.ar)'s article


 reference it and it works. If I had to fix something for it to work, I
 woudldn't use it. Mainly because to fix it I'd had to understand the
 code, and I just want to understand the interface.
 If you have to modify a library when you download it just to make it
 work (not to tweak it), that's a huge problem for me.


Agreed, but if the library is being actively maintained, the library developer
will do this.  If it's not being maintained, well, we do have a lot of abandoned
stuff out on dource, but I wouldn't want to use a library if noone understands
it
and cares enough to fix a few trivial bugs.
Mar 26 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
dsimcha wrote:

 == Quote from Ary Borenszweig (ary esperanto.org.ar)'s article


 reference it and it works. If I had to fix something for it to work, I
 woudldn't use it. Mainly because to fix it I'd had to understand the
 code, and I just want to understand the interface.
 If you have to modify a library when you download it just to make it
 work (not to tweak it), that's a huge problem for me.


 
 Agreed, but if the library is being actively maintained, the library developer
 will do this.  If it's not being maintained, well, we do have a lot of
abandoned
 stuff out on dource, but I wouldn't want to use a library if noone understands
it
 and cares enough to fix a few trivial bugs.


Yes, but fixing bugs should be understood as bugs in the code, some flaw 
in the library logic. Not some bug because the compiler suddenly changed.

And as someone mentioned some days ago, D is mostly used by hobby-ists, 
so the chances of maintaining a library in that sense are very few. 
Specially because it's very boring to fix bugs you didn't caused.
Mar 26 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el 26 de marzo a las 10:20 me escribiste:

Note the use of the word "language."
What you're referring to are bugs in the compiler.  It happens.
  -- Daniel


 
 But ValieriM has a point. If I code, say, a library in D 1.041 only to
 find out that in a couple of months it won't compile anymore in D 1.045,
 that's not good at all. That's when someone sends a message to the
 newsgroups saying "I just downloaded library Foo, but it won't compile
 with D 1.045... is it abandoned?  Why isn't it maintained? D1 is
 broken". The point is, you shouldn't need to maintain libraries for D1
 anymore. Maybe the test suite for D1 should be bigger to cover more
 cases...


Another problem with D1 vs. D2 is nobody wants to start new software using
D1 when D2 is about to come and have breaking changes. Not trivial
breaking changes, but really base ones, a change in paradigm (D2 will be
a lot more oriented to concurrency, and a lot of idioms will change). You
probably have to start thinking in a different way to code with D2, at
least to take advantage of new features/paradigm.

I think this is something people see and why a lot of people see D1 as
a dead end. This doesn't happen with other language AFAIK (at least no
with Python wich is another moderately fast-evolving language that I use
often). You can move from Python 2 to Python 3 almost as smoothly as
moving from 2.5 to 2.6 (and that is *very* smooth). The difference with
D is Python 3 didn't introduce any paradigm change, it doesn't want to be
a revolutionary new language as D2 want.

I think this phrase should not be in the D homepage anymore:
"It seems to me that most of the "new" programming languages fall into one
of two categories: Those from academia with radical new paradigms and
those from large corporations with a focus on RAD and the web. Maybe it's
time for a new language born out of practical experience implementing
compilers." -- Michael

I think D now almost fit into the "Those from academia with radical new
paradigms" category =P

I think this wouldn't happen if D2 were focused on just adding small
features like the ones already added (like full closures, struct
improvements, common runtime with Tango, etc.) and AST macros for
example... =)

If you take small steps, you can evolve more smoothly (like Python) and
avoid this kind of huge gaps between language versions.

That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to
make an "unofficial" D 1.1 language), with a few minor non-breaking new
features over D 1.0, then D 1.2 could introduce some more, and so on. This
way people can catch-up easly, with small simple iterations, and D1 wont
feel as a dead frozen language.

Just my 2¢

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Mar 26 2009
next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella <llucax gmail.com> wrote=
:

 ...snip...

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to
 make an "unofficial" D 1.1 language), with a few minor non-breaking new
 features over D 1.0, then D 1.2 could introduce some more, and so on. Thi=


s

 way people can catch-up easly, with small simple iterations, and D1 wont
 feel as a dead frozen language.


I think this is bound to happen sooner or later.


 Just my 2=C2=A2

 --
 Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/bl=


og/
Mar 26 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Tomas Lindquist Olsen, el 26 de marzo a las 18:18 me escribiste:

 On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella <llucax gmail.com> wrote:

 ...snip...

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to
 make an "unofficial" D 1.1 language), with a few minor non-breaking new
 features over D 1.0, then D 1.2 could introduce some more, and so on. This
 way people can catch-up easly, with small simple iterations, and D1 wont
 feel as a dead frozen language.


 
 I think this is bound to happen sooner or later.


Well, then I'd love it happen sooner ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Mar 26 2009
parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Thu, Mar 26, 2009 at 6:41 PM, Leandro Lucarella <llucax gmail.com> wrote=
:

 Tomas Lindquist Olsen, el 26 de marzo a las 18:18 me escribiste:

 On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella <llucax gmail.com> wr=




ote:

 ...snip...

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used=






 to

 make an "unofficial" D 1.1 language), with a few minor non-breaking ne=






w

 features over D 1.0, then D 1.2 could introduce some more, and so on. =






This

 way people can catch-up easly, with small simple iterations, and D1 wo=






nt

 feel as a dead frozen language.


 I think this is bound to happen sooner or later.


 Well, then I'd love it happen sooner ;)


We could start by figuring out what D 1.1 is ...


 --
 Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/bl=


og/

 -------------------------------------------------------------------------=


---

 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 =C2=A0104C 949E BFB6 5F5A 8D0=


5)

 -------------------------------------------------------------------------=


---





 Mar 26 2009



  parent reply Ary Borenszweig <ary esperanto.org.ar>  writes:


Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 6:41 PM, Leandro Lucarella <llucax gmail.com> wrote:

 Tomas Lindquist Olsen, el 26 de marzo a las 18:18 me escribiste:

 On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella <llucax gmail.com> wrote:

 ...snip...

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to
 make an "unofficial" D 1.1 language), with a few minor non-breaking new
 features over D 1.0, then D 1.2 could introduce some more, and so on. This
 way people can catch-up easly, with small simple iterations, and D1 wont
 feel as a dead frozen language.


 I think this is bound to happen sooner or later.


 Well, then I'd love it happen sooner ;)


 
 We could start by figuring out what D 1.1 is ...


It's D2 - const/invariant, yeaaah! :-P



 Mar 26 2009



  parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 6:58 PM, Ary Borenszweig <ary esperanto.org.ar> wrote:

 Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 6:41 PM, Leandro Lucarella <llucax gmail.com>
 wrote:

 Tomas Lindquist Olsen, el 26 de marzo a las 18:18 me escribiste:

 On Thu, Mar 26, 2009 at 5:50 PM, Leandro Lucarella <llucax gmail.com>
 wrote:

 ...snip...

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used
 to
 make an "unofficial" D 1.1 language), with a few minor non-breaking new
 features over D 1.0, then D 1.2 could introduce some more, and so on.
 This
 way people can catch-up easly, with small simple iterations, and D1
 wont
 feel as a dead frozen language.


 I think this is bound to happen sooner or later.


 Well, then I'd love it happen sooner ;)


 We could start by figuring out what D 1.1 is ...


 It's D2 - const/invariant, yeaaah! :-P


Sounds a little drastic to me.



 Mar 26 2009



  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Tomas Lindquist Olsen, el 26 de marzo a las 19:13 me escribiste:

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used
 to
 make an "unofficial" D 1.1 language), with a few minor non-breaking new
 features over D 1.0, then D 1.2 could introduce some more, and so on.
 This
 way people can catch-up easly, with small simple iterations, and D1
 wont
 feel as a dead frozen language.


 I think this is bound to happen sooner or later.


 Well, then I'd love it happen sooner ;)


 We could start by figuring out what D 1.1 is ...


 It's D2 - const/invariant, yeaaah! :-P


 
 Sounds a little drastic to me.


Yes, I think small iterations are better. It's easier to catch-up and
start using new features for developers, it's less likely for something
to break, etc.

I think Python got the development model really right. From Wikipedia:
"Python 2.0 was released on 16 October 2000, with many major new features
including a full garbage collector and support for unicode. However, the
most important change was to the development process itself, with a shift
to a more transparent and community-backed process."

I don't think is a coincidence that since Python 2.0 the language has such
a fast growth. I think D can learn a lot from Python =)

Again from Wikipedia:
"Python 3.0, a major, backwards-incompatible release, was released on
3 December 2008 after a long period of testing. Many of its major
features have been backported to the backwards-compatible Python 2.6."

I've searched throgh the new D2 features page[1] and D2 changelog[2] and
started a wiki page to make a plan for (unofficial) D1.x language
series:
http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal

Here is a transcription for the lazy ones that don't want to switch to the
browser and to ease the discussion in the NG:


D1.x series proposal
====================

This proposal is intended to address the actual feel about D1 being
obsolete and D2 being not ready for real life use. There a lot of new
features in D2 that are simple, useful and easily backported to D1, but D1
is marked as frozen (or stable), so no new features are added. Worst,
there is a very thin line between what is a new feature and a bugfix or
a harmless addition, so sometimes D1 gets new features (like several new
predefined version identifiers, .__vptr and .__monitor properties,
extern(system), etc.). And it's much more easy for D1 to break when adding
this kind of stuff, and suddenly the frozen D1 version is not stable
anymore, and it doesn't provide anything new that is really interesting.

What would be nice is to have a language that evolves fast, with small
iterations, but each iteration being really stable. This way developers
can be more confident in the stability of the language concerning one
particular version. If some code works with D1.034, then it should work
with D1.045 without changes, or with any other D1.0xx.

Python has a very good development model, and D can learn a lot from it.
Python versions are composed of 3 numbers, major version, minor version,
and bugfix versions. Bugfix version should not introduce backward
incompatible changes at all, only bugfixes. If your code works with Python
2.5.0, it will work with Python 2.5.3 too. Minor version releases happen
every year, year and a half, and can include backward compatible changes
or even backward incompatible changes as long as they are easy to stop and
upgrade. Generally every backward incompatible change is added in 2 steps.
The change is introduced in minor version X, but only enable if the
developer asks for it (using from __future__ import feature, in the it can
be a compiler flag, or a pragma). Any incompatibility with the new feature
issue a warning (even when the new feature is not requested by the user).
For example, if a new keyword is introduced, and you have a symbol with
the same name as the new keyword, a warning is issued. In version X+1, the
new feature is enabled by default, and if there any backward compatibility
with the old version can be maintained, it kept but issues a deprecation
warning. Finally, in X+2 all (deprecated) backward compatibility is
removed. When a new major version is on the way, like with 3.0, all new
features that can be ported to the previous major version, are ported and
a new flag can be set to enable forward-compatibility warnings, to ease
writing forward compatible programs.

D situation is a little different because D2 is already here, and it's too
much ahead of D1. So a plan to backport features from D2 to D1
progressively should be done.

Here are the features proposed for D1.x series:

D1.1
----
This should be a transitional version, with as little changes as possible,
just to try out how the new version is taken by the community. Only
trivial changes are backported, specially the ones that improves
forward-compatibility of code. Porting D1.0 programs to D should be
trivial.

The proposed new features are:

    * Add predefined versions:
          o unittest (when -unittest is set)
          o D_PIC (when -fPIC switch is used)
    * Change result type of IsExpression? from int to bool.
    * Change return type of opEquals from int to bool.
    * Add warning when override is omitted.
    * Make hidden methods get a compile time warning rather than a runtime one.
    * Make special member functions _ctor, _dtor, etc., have two leading
      _ in order to not conflict with the user identifier space (maybe
      include an alias, if that's possible, to the old names and issue
      a warning if they are used).
    * Deprecate html source files.
    * Deprecate VolatileStatement?.
    * Deprecate invariant, pure, nothrow, shared and other "stable" new D2
      keywords as "free identifiers" (issue a deprecation warning if they
      are used).
    * Make opAssign no longer overloadable for class objects (issue
      a deprecation warning if it's overloaded).
    * Class and struct invariant declarations may have a () (issue
      a warning if () are omitted).
    * Extend enums to allow declaration of manifest constants.
    * Add new syntax for string literals (delimited, heredoc, D tokens).
    * Make the 'this' parameter to struct member functions a reference
      type, rather than a pointer.
    * Change __FILE__ and __LINE__ so they work as parameter default
      initializers.

D1.2
----
This version can introduce some bigger changes, for example:

    * Remove old _ctor, _dtor, etc. aliases (from D1.1).
    * Remove html source files support.
    * Remove VolatileStatement?.
    * Make invariant, pure, nothrow, shared and other "stable" new D2
      keywords reserved identifiers.
    * Make opAssign no longer overloadable for class objects.
    * Class and struct invariant declarations must have a ().
    * Use druntime to finally allow Tango-Phobos? compatibility (maybe
      this one should go to D1.1 even when I think it's not that trivial)
    * Add C++ interface for plugins.
    * Add isSame and compiles to __traits.
    * Add typeof(return) type specifier.
    * Allow static arrays to be lvalues.
    * Allows implicit casting of StructLiterals? if each of its arguments
      can be implicitly cast.
    * Add pragma startaddress.
    * Allow .tupleof access private fields of a struct/class.
    * Add partial ordering rules to disambiguate function overloading.
    * Allow template alias be literals.
    * Allow function templates deduce the return type if they are declared
      with auto.
    * Don't match non-lvalues to ref and out parameters when overloading.
    * Evaluate std.math.sin, cos, tan at compile time if the argument is
      a constant.

D1.3
----
This version can be focused on even bigger changes, and struct improvements:

    * Implement Overload Sets for functions and templates.
    * Add Constraints to templates.
    * Add struct constructors.
    * Add struct destructors and postblits.
    * Add nested structs.
    * Add overloadable unary * operation as opStar().


General notes
-------------
Full closure should be backported to D1.x too, but I don't remember if the
problem about heap allocation is fully fixed yet (scope can be used to
avoid heap allocation in function parameters I think but I don't remember
if that solved all problems). If it's all working good, maybe it should be
part of D1.2 o r D1.3.

OpDot? and __thread storage class are other features that can be ported to
D1.x, but they are marked as experimental even in D2 (at least they were
marked as experimental when first added to D2), so I guess they have to
wait until they are at least somehow stable in D2.

Ranges (and foreach range support) could be backported to D1.x too in the
future, but, again, they are not that stable yet, so they should wait
a little to think about that.

On each new D1.x version, new keywords that are stable enough in D2 should
be added as reserved words, so people can write code more
forward-compatible with D2. New version identifier like {D Version1 1}?
(maybe something else if it's unofficial) should be added to indicate the
current version of the compiler.

Standard library (Phobos) changes should be ported too, but there are so
many that it's harder to make a plan for it, and some code will depend on
which new features are introduced so extra care should be taken when
deciding what to put where. But most changes should be ported sooner than
later for, again, forward-compatibility.

Finally, the "safe" stuff (module(system) and -safe switch) could be added
in the future too, but there is not much about that for now there is no
point in making plans for them =)


[1] http://www.digitalmars.com/d/2.0/features2.html
[2] http://www.digitalmars.com/d/2.0/changelog.html

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------



 Mar 26 2009



  parent reply Sean Kelly <sean invisibleduck.org>  writes:


== Quote from Leandro Lucarella (llucax gmail.com)'s article

 D situation is a little different because D2 is already here, and it's too
 much ahead of D1. So a plan to backport features from D2 to D1
 progressively should be done.


Who is going to do these backports?  Personally, I'd rather think about
moving my code to D2 in one jump than in a bunch of incremental
steps, each requiring a custom compiler.



 Mar 26 2009



  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Sean Kelly, el 26 de marzo a las 22:08 me escribiste:

 == Quote from Leandro Lucarella (llucax gmail.com)'s article

 D situation is a little different because D2 is already here, and it's too
 much ahead of D1. So a plan to backport features from D2 to D1
 progressively should be done.


 
 Who is going to do these backports?


That's a fair question without an answer =)
(I wish I had the time to do it. If I had the time I probably first do it
and then propose it)


 Personally, I'd rather think about moving my code to D2 in one jump than
 in a bunch of incremental steps, each requiring a custom compiler.


Are you? If not, why? I think D2 being a moving target make people don't
want to port code because it would be too hard to maintain. They idea
behind 1.x series is that each minor version is *stable*. Code you port
to, let's say, 1.1.000, will work with 1.1.100. No new predefined
versions, no new nothing. You get a really stable language and one that
evolves fast. You just have to do some minor porting about once a year,
when a new minor version is release, and that porting should be trivial.
Porting code to D2 now is a complicated excercise, at least to do it right
(using constness features).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Algún día los libros desterrarán a la radio y el hombre descubrirá el
oculto poder del Amargo Serrano.
	-- Ricardo Vaporeso. El Bolsón, 1909.



 Mar 26 2009



 next sibling parent  Don <nospam nospam.com>  writes:


Leandro Lucarella wrote:

 Sean Kelly, el 26 de marzo a las 22:08 me escribiste:

 == Quote from Leandro Lucarella (llucax gmail.com)'s article

 D situation is a little different because D2 is already here, and it's too
 much ahead of D1. So a plan to backport features from D2 to D1
 progressively should be done.


 Who is going to do these backports?


 
 That's a fair question without an answer =)
 (I wish I had the time to do it. If I had the time I probably first do it
 and then propose it)
 

 Personally, I'd rather think about moving my code to D2 in one jump than
 in a bunch of incremental steps, each requiring a custom compiler.


 
 Are you? If not, why? I think D2 being a moving target make people don't
 want to port code because it would be too hard to maintain. They idea
 behind 1.x series is that each minor version is *stable*. Code you port
 to, let's say, 1.1.000, will work with 1.1.100. No new predefined
 versions, no new nothing. You get a really stable language and one that
 evolves fast. You just have to do some minor porting about once a year,
 when a new minor version is release, and that porting should be trivial.
 Porting code to D2 now is a complicated excercise, at least to do it right
 (using constness features).
 


You'd get the same effect if we had a stable D2. Which we don't yet 
have, but it feels to me that it's converging.



 Mar 27 2009



prev sibling  parent reply Jason House <jason.james.house gmail.com>  writes:


Leandro Lucarella Wrote:


 Sean Kelly, el 26 de marzo a las 22:08 me escribiste:

 == Quote from Leandro Lucarella (llucax gmail.com)'s article

 D situation is a little different because D2 is already here, and it's too
 much ahead of D1. So a plan to backport features from D2 to D1
 progressively should be done.


 
 Who is going to do these backports?


 
 That's a fair question without an answer =)
 (I wish I had the time to do it. If I had the time I probably first do it
 and then propose it)
 

 Personally, I'd rather think about moving my code to D2 in one jump than
 in a bunch of incremental steps, each requiring a custom compiler.


 
 Are you? If not, why? I think D2 being a moving target make people don't
 want to port code because it would be too hard to maintain. They idea
 behind 1.x series is that each minor version is *stable*. Code you port
 to, let's say, 1.1.000, will work with 1.1.100. No new predefined
 versions, no new nothing. You get a really stable language and one that
 evolves fast. You just have to do some minor porting about once a year,
 when a new minor version is release, and that porting should be trivial.
 Porting code to D2 now is a complicated excercise, at least to do it right
 (using constness features).


I think many people avoid D2 because it has const and that const is too much
work for too little gain. Many seem to want all features of D2 without the
const. I don't really get any of the anti D2 arguments except that D2 lacks
Tango. I pushed hard trying to see something official in that area, including
offering my time totest/fix Tango after breaking D2 changes. I've given up on
the whole mess.



 Mar 27 2009



  parent reply Christopher Wright <dhasenan gmail.com>  writes:


Jason House wrote:

 I think many people avoid D2 because it has const and that const is too much
work for too little gain. Many seem to want all features of D2 without the
const. I don't really get any of the anti D2 arguments except that D2 lacks
Tango. I pushed hard trying to see something official in that area, including
offering my time totest/fix Tango after breaking D2 changes. I've given up on
the whole mess.


I *want* to use const. But it's too much work. I want const by default, 
since that would let me be lazy and let the compiler tell me where 
things can't be const.



 Mar 27 2009



  parent  Jason House <jason.james.house gmail.com>  writes:


Christopher Wright Wrote:
 

 I *want* to use const. But it's too much work. I want const by default, 
 since that would let me be lazy and let the compiler tell me where 
 things can't be const.


I wish for the same thing. "in" parameters by default would be great. One of
these days, I'll add const-awareness to my D2 code...



 Mar 27 2009



prev sibling  parent  "Nick Sabalausky" <a a.a>  writes:


"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090326165012.GC17722 burns.springfield.home...

 Ary Borenszweig, el 26 de marzo a las 10:20 me escribiste:

Note the use of the word "language."
What you're referring to are bugs in the compiler.  It happens.
  -- Daniel


 But ValieriM has a point. If I code, say, a library in D 1.041 only to
 find out that in a couple of months it won't compile anymore in D 1.045,
 that's not good at all. That's when someone sends a message to the
 newsgroups saying "I just downloaded library Foo, but it won't compile
 with D 1.045... is it abandoned?  Why isn't it maintained? D1 is
 broken". The point is, you shouldn't need to maintain libraries for D1
 anymore. Maybe the test suite for D1 should be bigger to cover more
 cases...


 Another problem with D1 vs. D2 is nobody wants to start new software using
 D1 when D2 is about to come and have breaking changes. Not trivial
 breaking changes, but really base ones, a change in paradigm (D2 will be
 a lot more oriented to concurrency, and a lot of idioms will change). You
 probably have to start thinking in a different way to code with D2, at
 least to take advantage of new features/paradigm.

 I think this is something people see and why a lot of people see D1 as
 a dead end. This doesn't happen with other language AFAIK (at least no
 with Python wich is another moderately fast-evolving language that I use
 often). You can move from Python 2 to Python 3 almost as smoothly as
 moving from 2.5 to 2.6 (and that is *very* smooth). The difference with
 D is Python 3 didn't introduce any paradigm change, it doesn't want to be
 a revolutionary new language as D2 want.

 I think this phrase should not be in the D homepage anymore:
 "It seems to me that most of the "new" programming languages fall into one
 of two categories: Those from academia with radical new paradigms and
 those from large corporations with a focus on RAD and the web. Maybe it's
 time for a new language born out of practical experience implementing
 compilers." -- Michael

 I think D now almost fit into the "Those from academia with radical new
 paradigms" category =P

 I think this wouldn't happen if D2 were focused on just adding small
 features like the ones already added (like full closures, struct
 improvements, common runtime with Tango, etc.) and AST macros for
 example... =)

 If you take small steps, you can evolve more smoothly (like Python) and
 avoid this kind of huge gaps between language versions.

 That's why I'd love to see some kind of D 1.1 (maybe LDC could be used to
 make an "unofficial" D 1.1 language), with a few minor non-breaking new
 features over D 1.0, then D 1.2 could introduce some more, and so on. This
 way people can catch-up easly, with small simple iterations, and D1 wont
 feel as a dead frozen language.


I've never really minded D's willingness to change, especially this early in 
it's lifetime (in fact, I quite respect it), primarily because I've seen 
what too much emphasis on backwards compatibility can eventually do to a 
language (ie, C/C++).

But that said, you do have an interesting point about providing a migration 
path that breaks the changes into smaller, easier-to-digest chunks.



 Mar 26 2009



prev sibling  parent  Clay Smith <clayasaurus gmail.com>  writes:


Ary Borenszweig wrote:

 Daniel Keep wrote:

 ValeriM wrote:

 Ary Borenszweig Wrote:


 Mike James escribi�:

 What is the state of play with D1.0 vs. D2.0?

 Is D1.0 a dead-end and D2.0 should be used for future projects?

 Is D2.0 stable enough for use at the present?

 Is Tango for D2.0 at a level of D1.0 and can be used now?

 Is DWT ready for D2.0 now?


 Regards, mike.


 I don't know why a lot of people see D1.0 as a dead-end. It's a 
 stable language. It won't get new features. It won't change. It'll 
 probably receive bug fixes. It works. It gets the job done. You can 
 use it and be sure than in a time all of what you did will still be 
 compatible with "newer" versions of D1.


 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get 
 the problems.


 "It's a stable language."

 Note the use of the word "language."

 What you're referring to are bugs in the compiler.  It happens.

   -- Daniel


 
 But ValieriM has a point. If I code, say, a library in D 1.041 only to 
 find out that in a couple of months it won't compile anymore in D 1.045, 
 that's not good at all. That's when someone sends a message to the 
 newsgroups saying "I just downloaded library Foo, but it won't compile 
 with D 1.045... is it abandoned? Why isn't it maintained? D1 is broken". 
 The point is, you shouldn't need to maintain libraries for D1 anymore. 
 Maybe the test suite for D1 should be bigger to cover more cases...


You should be using the compiler that comes bundled with Tango, perhaps.



 Mar 26 2009



prev sibling  parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 2:10 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

 ValeriM wrote:

 Ary Borenszweig Wrote:


 Mike James escribi=EF=BF=BD:

 What is the state of play with D1.0 vs. D2.0?

 Is D1.0 a dead-end and D2.0 should be used for future projects?

 Is D2.0 stable enough for use at the present?

 Is Tango for D2.0 at a level of D1.0 and can be used now?

 Is DWT ready for D2.0 now?


 Regards, mike.


 I don't know why a lot of people see D1.0 as a dead-end. It's a stable
 language. It won't get new features. It won't change. It'll probably
 receive bug fixes. It works. It gets the job done. You can use it and b=






e

 sure than in a time all of what you did will still be compatible with
 "newer" versions of D1.


 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get th=




e problems.

 "It's a stable language."

 Note the use of the word "language."

 What you're referring to are bugs in the compiler. =C2=A0It happens.

 =C2=A0-- Daniel


D1 does have some missing features that are in D2, and could be
backported to D1 without breaking any code.
This isn't going to happen for the sake of stability. But if I want to
use some of the new features, I have to get all the cruft that made me
look into D in the first place as well. A major reason I started with
D was because of simple syntax, GC and lack of the const hell.

D2 is no longer a simple language, you have to know all kinds of shit
to be able to use it correctly.

All my projects at the moment are in C++. And TBH I don't see that
changing any time soon. The stuff I did in D no longer works, and I
don't have time to debug the entire thing to figure out how/where the
compiler changed.

And yes, the Phobos vs. Tango (which in turn keeps breaking) situation
of course isn't making things better.



 Mar 26 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Tomas Lindquist Olsen wrote:

 D1 does have some missing features that are in D2, and could be
 backported to D1 without breaking any code.
 This isn't going to happen for the sake of stability. But if I want to
 use some of the new features, I have to get all the cruft that made me
 look into D in the first place as well. A major reason I started with
 D was because of simple syntax, GC and lack of the const hell.
 
 D2 is no longer a simple language, you have to know all kinds of shit
 to be able to use it correctly.
 
 All my projects at the moment are in C++. And TBH I don't see that
 changing any time soon. The stuff I did in D no longer works, and I
 don't have time to debug the entire thing to figure out how/where the
 compiler changed.


I've worked with C/C++ for decades, and it's a miracle if code that 
compiled 10 years ago compiles today without changes. Code never works 
without changes when porting to a different compiler. Code targeted at 
VC tends to target specific versions of VC. "Portable" libraries like 
Boost, STL, and Hans Boehm GC are full of #ifdef's.

The only real difference from D is that:
1. The evolution of C++ is about 10 times slower than D.
2. We're all so used to working around these problems in C++, we don't 
notice it.

I understand your frustrations with the changes, just not why that means 
using C++ <g>.


 And yes, the Phobos vs. Tango (which in turn keeps breaking) situation
 of course isn't making things better.





 Mar 26 2009



prev sibling next sibling parent reply TomD <t_demmer nospam.web.de>  writes:


ValeriM Wrote:

[...]

 
 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.
 


But not because of D1.0. It is because of the Tango team
introducing a couple of breaking changes. Frank is working on
updating DWT (or has even fixed that already, not sure)


 That is the causes a lot of people ask such questions. And I too. Not because
D1.0 dead-end. But because I can't understand what is "stable" toolset and how
long it would be "stable". D+Tango+DWT is a good example.
 


Yeah, but that is life. At some point you need
to  change APIs, and then you need to revise the "downstream"
libraries. That takes some time. This no question of dead-end.

Ciao
TomD



 Mar 26 2009



  parent  "Denis Koroskin" <2korden gmail.com>  writes:


On Thu, 26 Mar 2009 16:23:29 +0300, TomD <t_demmer nospam.web.de> wrote:


 ValeriM Wrote:

 [...]

 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.


 But not because of D1.0. It is because of the Tango team
 introducing a couple of breaking changes. Frank is working on
 updating DWT (or has even fixed that already, not sure)


 That is the causes a lot of people ask such questions. And I too. Not because
D1.0 dead-end. But because I can't understand what is "stable" toolset and how
long it would be "stable". D+Tango+DWT is a good example.


 Yeah, but that is life. At some point you need
 to  change APIs, and then you need to revise the "downstream"
 libraries. That takes some time. This no question of dead-end.

 Ciao
 TomD
 


True. That's why Tango provides bundles which include compiler and the library
in both source and binary form. Bundles exist for stable and trunk revisions
and I have never got any problems using them.



 Mar 26 2009



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


ValeriM wrote:

 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.


I am not aware that D1.041 broke Tango and DWT. Please, which bugzilla 
numbers are those?



 Mar 26 2009



 next sibling parent reply "Denis Koroskin" <2korden gmail.com>  writes:


On Thu, 26 Mar 2009 21:27:52 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:


 ValeriM wrote:

 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.


 I am not aware that D1.041 broke Tango and DWT. Please, which bugzilla
 numbers are those?
 


One of the breaking changes that I recall was that you made Posix identifier
built-in and thus any custom Posix versioning became an error. Not sure if it
was introduced in 1.041, though, but it is still a breaking change.



 Mar 26 2009



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


Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


It was more of a build system change, but I get your point. It shows 
that even trivial changes are a bad idea for D1.



 Mar 26 2009



 next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows that
 even trivial changes are a bad idea for D1.


Everyone certainly does not think it was a bad idea. If trivial things
like this sets people off, they should at least look at the problem
(and comment those few lines) before complaining.

All my humble opinion of course.



 Mar 26 2009



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


Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows that
 even trivial changes are a bad idea for D1.


 
 Everyone certainly does not think it was a bad idea. If trivial things
 like this sets people off, they should at least look at the problem
 (and comment those few lines) before complaining.
 
 All my humble opinion of course.


To me, it illustrates a fundamental disconnect. One cannot have both a 
100% stable language and yet introduce improvements to it.

As for the does one develop stable code targeting D1 and D2, I would 
suggest targeting D1 but be careful to use the string alias for all the 
char[]'s, and treat strings as if they were immutable. This will cover 
90% of any source code changes between D1 and D2, perhaps even more than 
90%. It's also very possible to write D1 code using the immutability 
style, in fact, I advocated it long before D2 (see all the old threads 
discussing Copy On Write). If code follows the COW principle, it should 
port from D1 to D2 with little more than a few cosmetic changes.



 Mar 26 2009



 next sibling parent  Sean Kelly <sean invisibleduck.org>  writes:


== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows that
 even trivial changes are a bad idea for D1.


 Everyone certainly does not think it was a bad idea. If trivial things
 like this sets people off, they should at least look at the problem
 (and comment those few lines) before complaining.

 All my humble opinion of course.


 To me, it illustrates a fundamental disconnect. One cannot have both a
 100% stable language and yet introduce improvements to it.
 As for the does one develop stable code targeting D1 and D2, I would
 suggest targeting D1 but be careful to use the string alias for all the
 char[]'s, and treat strings as if they were immutable. This will cover
 90% of any source code changes between D1 and D2, perhaps even more than
 90%. It's also very possible to write D1 code using the immutability
 style, in fact, I advocated it long before D2 (see all the old threads
 discussing Copy On Write). If code follows the COW principle, it should
 port from D1 to D2 with little more than a few cosmetic changes.


One minor thing in druntime that may help is that opEquals() returns
an equals_t, which evaluates to bool in D2.  It would probably be worth
changing the declaration in D1 to have a similar alias that evaluates to
int.  That should help address another minor inconsistency between D1
and D2.



 Mar 26 2009



prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows that
 even trivial changes are a bad idea for D1.


 Everyone certainly does not think it was a bad idea. If trivial things
 like this sets people off, they should at least look at the problem
 (and comment those few lines) before complaining.

 All my humble opinion of course.


 To me, it illustrates a fundamental disconnect. One cannot have both a 100%
 stable language and yet introduce improvements to it.


I don't necessarily want a 100% stable language. In fact I don't. But
obviously asking for both is just silly.
The only thing I'm not happy about is if code that used to work, still
compiles, but no longer works. This is where the real problem is and
I've seen it several times. MinWin, APaGeD and probably others.



 Mar 26 2009



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


Tomas Lindquist Olsen wrote:

 I don't necessarily want a 100% stable language. In fact I don't. But
 obviously asking for both is just silly.
 The only thing I'm not happy about is if code that used to work, still
 compiles, but no longer works. This is where the real problem is and
 I've seen it several times. MinWin, APaGeD and probably others.


What do you suggest?

It's why there's a "last stable version" of D1 on the website. With any 
software package, if you always download the latest version but another 
package was only tested with a different version, it's likely to have 
problems.



 Mar 26 2009



 next sibling parent  Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 10:05 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Tomas Lindquist Olsen wrote:

 I don't necessarily want a 100% stable language. In fact I don't. But
 obviously asking for both is just silly.
 The only thing I'm not happy about is if code that used to work, still
 compiles, but no longer works. This is where the real problem is and
 I've seen it several times. MinWin, APaGeD and probably others.


 What do you suggest?

 It's why there's a "last stable version" of D1 on the website. With any
 software package, if you always download the latest version but another
 package was only tested with a different version, it's likely to have
 problems.


I'm not sure about what to do with the damage done already. I think it
came across worse than I meant it to.
In the future I think this can largely be solved by my public source
repository proposal.






 Mar 26 2009



prev sibling  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Walter Bright, el 26 de marzo a las 14:05 me escribiste:

 Tomas Lindquist Olsen wrote:

I don't necessarily want a 100% stable language. In fact I don't. But
obviously asking for both is just silly.
The only thing I'm not happy about is if code that used to work, still
compiles, but no longer works. This is where the real problem is and
I've seen it several times. MinWin, APaGeD and probably others.


 
 What do you suggest?
 
 It's why there's a "last stable version" of D1 on the website. With any
 software package, if you always download the latest version but another
 package was only tested with a different version, it's likely to have
 problems.


This is another problem with D, the lack of a public SCM repository for,
at least, the fronend. Now each DMD release is really a "nightly snapshot"
without any real-world testing (I guess). That's another reason why
"stable" DMD release keep breaking.

If one could download a snapshot every once in a while and give it a try,
most breaking changes should be detected *before* the actual release. Or
maybe alpha or beta versions should be released.

When I see a compiler version 1.041, I see a stable release number, not
a beta, or release candidate or nightly snapshoot, but sadly that is what
it is. Maybe that is a big source of confusion.

Maybe an improvement on version numbering scheme can be very useful in
this regard, even for people looking at D2.0, D2.032 really looks like
a stable release. D2.0alpha032, for example, is really ugly but at lease
looks more like an alpha release =)
D1.041rc2, looks like a release candidate, not a final version, and if it
breaks something, I wouldn't be as surprised as if D1.041 breaks.

Anyway, I will be glad if you take a look at the D1.x series proposal =)
http://www.prowiki.org/wiki4d/wiki.cgi?D1XProposal

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------



 Mar 26 2009



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


Leandro Lucarella wrote:

 This is another problem with D, the lack of a public SCM repository for,
 at least, the fronend. Now each DMD release is really a "nightly snapshot"
 without any real-world testing (I guess). That's another reason why
 "stable" DMD release keep breaking.
 
 If one could download a snapshot every once in a while and give it a try,
 most breaking changes should be detected *before* the actual release. Or
 maybe alpha or beta versions should be released.
 
 When I see a compiler version 1.041, I see a stable release number, not
 a beta, or release candidate or nightly snapshoot, but sadly that is what
 it is. Maybe that is a big source of confusion.


But that's why the download page divides the downloads into "latest" and 
"stable." If you want "stable", why download "latest"?

http://www.digitalmars.com/d/download.html

Furthermore, before release, it is made available to the DWT and Tango 
teams to see if it breaks them. If I made it generally available, how is 
that different from the "latest" on the download page? There's even a 
"bundle" version that comes with various libraries tested and verified 
with it.



 Mar 26 2009



  parent reply Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Thu, Mar 26, 2009 at 6:07 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 But that's why the download page divides the downloads into "latest" and
 "stable." If you want "stable", why download "latest"?


Stable doesn't just mean "not changing."  It also means "providing a
strong foundation upon which something can be built."  The older
compilers are usually anything but that, as the newer ones usually fix
more things than what they break.  The library developers are forced
to use newer compilers because there are showstopping bugs in the
older ones, and the library users are then forced to use newer
compilers as a result.  At least, that's what I've experienced.


 Furthermore, before release, it is made available to the DWT and Tango teams
 to see if it breaks them. If I made it generally available, how is that
 different from the "latest" on the download page? There's even a "bundle"
 version that comes with various libraries tested and verified with it.


Well usually problems only arise when things change - directory
structure, new features, language spec changes (.init).  Bugfixes
rarely create problems.  For example I'd welcome fixes to things like
bugs 313 and 314 (which are ancient, by the way) even if it means I
have to change my code, because I know that my code is more correct as
a result.  I feel like the idea behind the nightly releases is so that
when _changes_ occur, or when regressions are introduced, they can be
stamped out before a major release.  DWT and Tango are major projects
but are by no means an exhaustive testbed.

So what about the following counterargument: "even if nightly builds
were made available, how can we be sure that enough people are using
them to sufficiently test them?"  OK, sure, if not many people are
using the nightly builds, then there wouldn't be much benefit.  But it
does seem to work out fine for a lot of projects.  And with a proper
SCM set up which you commit to daily, there's virtually no work on
your part.  You just commit, and everyone else can download and
compile.



 Mar 26 2009



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


Jarrett Billingsley wrote:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?"  OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit.  But it
 does seem to work out fine for a lot of projects.  And with a proper
 SCM set up which you commit to daily, there's virtually no work on
 your part.  You just commit, and everyone else can download and
 compile.


I believe that people downloading half-baked works in progress and then 
finding problems I already know about and am fixing is probably not more 
productive.



 Mar 26 2009



 next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Thu, Mar 26, 2009 at 7:01 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?" =A0OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit. =A0But it
 does seem to work out fine for a lot of projects. =A0And with a proper
 SCM set up which you commit to daily, there's virtually no work on
 your part. =A0You just commit, and everyone else can download and
 compile.


 I believe that people downloading half-baked works in progress and then
 finding problems I already know about and am fixing is probably not more
 productive.


It's not the bugs that you know about that cause problems for other people!



 Mar 26 2009



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


Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other people!


Half-baked implementations won't help them, either. I just don't think 
the answer is, what is in essence, a lot more releases.



 Mar 26 2009



  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

It's not the bugs that you know about that cause problems for other people!


 
 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


Millions of open source projects that work that way can prove you wrong.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
 ease, eating well (no more microwave dinners and saturated fats),
a patient better driver, a safer car (baby smiling in back seat),
sleeping well (no bad dreams), no paranoia,



 Mar 26 2009



 next sibling parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Leandro Lucarella wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 
 Millions of open source projects that work that way can prove you wrong.


Phobos works that way, and intermediate "releases" are pretty much 
ignored (as I think they should be).



 Mar 26 2009



 next sibling parent  Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Fri, Mar 27, 2009 at 12:29 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Leandro Lucarella wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other
 people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 Millions of open source projects that work that way can prove you wrong.


 Phobos works that way, and intermediate "releases" are pretty much ignored
 (as I think they should be).


Maybe it's because no one uses it.

I mean, I'm just saying.



 Mar 26 2009



prev sibling next sibling parent  Jarrett Billingsley <jarrett.billingsley gmail.com>  writes:


On Fri, Mar 27, 2009 at 1:19 AM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Fri, Mar 27, 2009 at 12:29 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Leandro Lucarella wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other
 people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 Millions of open source projects that work that way can prove you wrong.


 Phobos works that way, and intermediate "releases" are pretty much ignored
 (as I think they should be).


 Maybe it's because no one uses it.

 I mean, I'm just saying.


This is also partly the beer talking.



 Mar 26 2009



prev sibling next sibling parent  Leandro Lucarella <llucax gmail.com>  writes:


Walter Bright, el 26 de marzo a las 21:29 me escribiste:

 Leandro Lucarella wrote:

Walter Bright, el 26 de marzo a las 16:58 me escribiste:

Jarrett Billingsley wrote:

It's not the bugs that you know about that cause problems for other people!


Half-baked implementations won't help them, either. I just don't think
the answer is, what is in essence, a lot more releases.


Millions of open source projects that work that way can prove you wrong.


 
 Phobos works that way, and intermediate "releases" are pretty much
 ignored (as I think they should be).


I do follow the development of phobos (and reported some minor issues when
I saw them).

And making beta or at least rc releases would help a lot too, because
a lot of people will be willing to download the rc and test it with its
software to see if all works good and report problems so they are fixed in
the release.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
heart that's full up like a landfill,
a job that slowly kills you,
bruises that won't heal.



 Mar 27 2009



prev sibling  parent  Christopher Wright <dhasenan gmail.com>  writes:


Walter Bright wrote:

 Leandro Lucarella wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other 
 people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 Millions of open source projects that work that way can prove you wrong.


 
 Phobos works that way, and intermediate "releases" are pretty much 
 ignored (as I think they should be).


I ignore them because:
1. I don't use phobos
2. They sometimes rely on compiler features that won't be available for 
another few weeks

On the other hand, I get tango from svn rather than the last release as 
a matter of course. And when using LDC, I update roughly once a week -- 
more often if I experience bugs.



 Mar 27 2009



prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com>  writes:


On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax gmail.com> wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

It's not the bugs that you know about that cause problems for other people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 Millions of open source projects that work that way can prove you wrong.



I think part of the problem with the current approach is that the
"stable" D releases seem to have no connection with reality.  It's
always been way older than it should be every time I've looked.  I
wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
should be the most recent "stable" version at the moment.   It seems
there isn't a good process in place for figuring out what's stable and
what's not.

It seems to me the only people who would know which compilers deserve
the "stable" label are the folks using dmd on a daily basis to build
their software.  Yet I've never seen the question come up here or
anywhere else of what version of D the users find to be the most
stable.   My impression is frankly that Walter just arbitrarily slaps
the label on a rev that's about 10 steps back from current.  Probably
there's more to it than that, but that's what it seems like.

--bb



 Mar 26 2009



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


Bill Baxter wrote:

 It seems to me the only people who would know which compilers deserve
 the "stable" label are the folks using dmd on a daily basis to build
 their software.  Yet I've never seen the question come up here or
 anywhere else of what version of D the users find to be the most
 stable.   My impression is frankly that Walter just arbitrarily slaps
 the label on a rev that's about 10 steps back from current.  Probably
 there's more to it than that, but that's what it seems like.


The current "stable" D1 is that way because it's the one that people 
supplied me with a bundled version that has the major libraries 
specifically tested and working with it.

I think that is a fairly reasonable definition of it.



 Mar 26 2009



  parent  Sergey Gromov <snake.scaly gmail.com>  writes:


Thu, 26 Mar 2009 22:30:50 -0700, Walter Bright wrote:


 Bill Baxter wrote:

 It seems to me the only people who would know which compilers deserve
 the "stable" label are the folks using dmd on a daily basis to build
 their software.  Yet I've never seen the question come up here or
 anywhere else of what version of D the users find to be the most
 stable.   My impression is frankly that Walter just arbitrarily slaps
 the label on a rev that's about 10 steps back from current.  Probably
 there's more to it than that, but that's what it seems like.


 
 The current "stable" D1 is that way because it's the one that people 
 supplied me with a bundled version that has the major libraries 
 specifically tested and working with it.
 
 I think that is a fairly reasonable definition of it.


Official stable Tango is bundled with 1.033 for a very long time
already.



 Mar 27 2009



prev sibling  parent reply Brad Roberts <braddr puremagic.com>  writes:


Bill Baxter wrote:

 On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax gmail.com> wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 Millions of open source projects that work that way can prove you wrong.


 
 
 I think part of the problem with the current approach is that the
 "stable" D releases seem to have no connection with reality.  It's
 always been way older than it should be every time I've looked.  I
 wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
 should be the most recent "stable" version at the moment.   It seems
 there isn't a good process in place for figuring out what's stable and
 what's not.
 
 It seems to me the only people who would know which compilers deserve
 the "stable" label are the folks using dmd on a daily basis to build
 their software.  Yet I've never seen the question come up here or
 anywhere else of what version of D the users find to be the most
 stable.   My impression is frankly that Walter just arbitrarily slaps
 the label on a rev that's about 10 steps back from current.  Probably
 there's more to it than that, but that's what it seems like.
 
 --bb


Actually it's more like he moves it forward when conversations like this
come up and point out how far behind it is.  I'm not sure I've seen it
ever pro-actively moved forward, only re-actively. :)

Later,
Brad



 Mar 26 2009



  parent reply Don <nospam nospam.com>  writes:


Brad Roberts wrote:

 Bill Baxter wrote:

 On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax gmail.com> wrote:

 Walter Bright, el 26 de marzo a las 16:58 me escribiste:

 Jarrett Billingsley wrote:

 It's not the bugs that you know about that cause problems for other people!


 Half-baked implementations won't help them, either. I just don't think
 the answer is, what is in essence, a lot more releases.


 Millions of open source projects that work that way can prove you wrong.


 I think part of the problem with the current approach is that the
 "stable" D releases seem to have no connection with reality.  It's
 always been way older than it should be every time I've looked.  I
 wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
 should be the most recent "stable" version at the moment.   It seems
 there isn't a good process in place for figuring out what's stable and
 what's not.

 It seems to me the only people who would know which compilers deserve
 the "stable" label are the folks using dmd on a daily basis to build
 their software.  Yet I've never seen the question come up here or
 anywhere else of what version of D the users find to be the most
 stable.   My impression is frankly that Walter just arbitrarily slaps
 the label on a rev that's about 10 steps back from current.  Probably
 there's more to it than that, but that's what it seems like.

 --bb


 
 Actually it's more like he moves it forward when conversations like this
 come up and point out how far behind it is.  I'm not sure I've seen it
 ever pro-actively moved forward, only re-actively. :)
 
 Later,
 Brad


Yes. I think I was responsible for the provoking two of the three 
changes that have occured. I don't like that at all. I think what's 
really lacking is a process for declaring a revision as stable. Then, 
library developers would need to agree to make sure to verify that 
everything works with the last version which is declared as stable.

It'd also be nice to mark in the changelog as soon as a version is known 
to be broken, so that more people don't download it.



 Mar 27 2009



  parent  Leandro Lucarella <llucax gmail.com>  writes:


Don, el 27 de marzo a las 10:58 me escribiste:

 Brad Roberts wrote:

Bill Baxter wrote:

On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax gmail.com> wrote:

Walter Bright, el 26 de marzo a las 16:58 me escribiste:

Jarrett Billingsley wrote:

It's not the bugs that you know about that cause problems for other people!


Half-baked implementations won't help them, either. I just don't think
the answer is, what is in essence, a lot more releases.


Millions of open source projects that work that way can prove you wrong.


I think part of the problem with the current approach is that the
"stable" D releases seem to have no connection with reality.  It's
always been way older than it should be every time I've looked.  I
wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
should be the most recent "stable" version at the moment.   It seems
there isn't a good process in place for figuring out what's stable and
what's not.

It seems to me the only people who would know which compilers deserve
the "stable" label are the folks using dmd on a daily basis to build
their software.  Yet I've never seen the question come up here or
anywhere else of what version of D the users find to be the most
stable.   My impression is frankly that Walter just arbitrarily slaps
the label on a rev that's about 10 steps back from current.  Probably
there's more to it than that, but that's what it seems like.

--bb


Actually it's more like he moves it forward when conversations like this
come up and point out how far behind it is.  I'm not sure I've seen it
ever pro-actively moved forward, only re-actively. :)
Later,
Brad


 
 Yes. I think I was responsible for the provoking two of the three
 changes that have occured. I don't like that at all. I think what's
 really lacking is a process for declaring a revision as stable. Then,
 library developers would need to agree to make sure to verify that
 everything works with the last version which is declared as stable.
 
 It'd also be nice to mark in the changelog as soon as a version is known
 to be broken, so that more people don't download it.


Make beta/release candidate release!

If code is in a SCM is much more simpler, you can simply say: "hey,
people, a new release is comming next week, can you download current <SCM>
version and see if all works good?". You don't even have to go throgh
a complete release process.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA.
	-- Crónica TV



 Mar 27 2009



prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?" =C2=A0OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit. =C2=A0But=




 it

 does seem to work out fine for a lot of projects. =C2=A0And with a prope=




r

 SCM set up which you commit to daily, there's virtually no work on
 your part. =C2=A0You just commit, and everyone else can download and
 compile.


 I believe that people downloading half-baked works in progress and then
 finding problems I already know about and am fixing is probably not more
 productive.


Some of us might actually look at your changes.

1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.

2) We can comment on changes. Ideally there would be a mailing list
with each commit. This makes discussion of specific changes much
easier.

3) You get feedback on the code.

I'm not sure how many people have access to your code, or if you even
use a SCM repository locally.

As an extra bonus you could release your internal test suite as well.
This would be useful for projects like LDC, as a compliment to
DStress. Do you use Dstress?

The testing process of DMD could be much less opaque in general.

-Tomas



 Mar 27 2009



 next sibling parent reply "Denis Koroskin" <2korden gmail.com>  writes:


On Fri, 27 Mar 2009 23:33:43 +0300, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:


 On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?"  OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit.  But it
 does seem to work out fine for a lot of projects.  And with a proper
 SCM set up which you commit to daily, there's virtually no work on
 your part.  You just commit, and everyone else can download and
 compile.


 I believe that people downloading half-baked works in progress and then
 finding problems I already know about and am fixing is probably not more
 productive.


 Some of us might actually look at your changes.

 1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.

 2) We can comment on changes. Ideally there would be a mailing list
 with each commit. This makes discussion of specific changes much
 easier.

 3) You get feedback on the code.

 I'm not sure how many people have access to your code, or if you even
 use a SCM repository locally.

 As an extra bonus you could release your internal test suite as well.
 This would be useful for projects like LDC, as a compliment to
 DStress. Do you use Dstress?

 The testing process of DMD could be much less opaque in general.

 -Tomas
 


*Highly* agree!



 Mar 27 2009



  parent  =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?=  writes:


Denis Koroskin wrote:

 On Fri, 27 Mar 2009 23:33:43 +0300, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:
 

 On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?"  OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit.  But it
 does seem to work out fine for a lot of projects.  And with a proper
 SCM set up which you commit to daily, there's virtually no work on
 your part.  You just commit, and everyone else can download and
 compile.


 I believe that people downloading half-baked works in progress and then
 finding problems I already know about and am fixing is probably not more
 productive.


 Some of us might actually look at your changes.

 1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.

 2) We can comment on changes. Ideally there would be a mailing list
 with each commit. This makes discussion of specific changes much
 easier.

 3) You get feedback on the code.

 I'm not sure how many people have access to your code, or if you even
 use a SCM repository locally.

 As an extra bonus you could release your internal test suite as well.
 This would be useful for projects like LDC, as a compliment to
 DStress. Do you use Dstress?

 The testing process of DMD could be much less opaque in general.

 -Tomas


 
 *Highly* agree!
 


2nded



 Mar 27 2009



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


Tomas Lindquist Olsen wrote:

 As an extra bonus you could release your internal test suite as well.
 This would be useful for projects like LDC, as a compliment to
 DStress. Do you use Dstress?


The problem with releasing the test suite I use is that its heritage is 
not very clear. It's quite a grab-bag collection of everything that went 
wrong in the past. Parts of it come from Dstress, too.


 The testing process of DMD could be much less opaque in general.
 
 -Tomas





 Mar 27 2009



prev sibling  parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Fri, Mar 27, 2009 at 9:33 PM, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:

 On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Jarrett Billingsley wrote:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?" =C2=A0OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit. =C2=A0Bu=






t it

 does seem to work out fine for a lot of projects. =C2=A0And with a prop=






er

 SCM set up which you commit to daily, there's virtually no work on
 your part. =C2=A0You just commit, and everyone else can download and
 compile.


 I believe that people downloading half-baked works in progress and then
 finding problems I already know about and am fixing is probably not more
 productive.


 Some of us might actually look at your changes.

 1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.

 2) We can comment on changes. Ideally there would be a mailing list
 with each commit. This makes discussion of specific changes much
 easier.

 3) You get feedback on the code.

 I'm not sure how many people have access to your code, or if you even
 use a SCM repository locally.

 As an extra bonus you could release your internal test suite as well.
 This would be useful for projects like LDC, as a compliment to
 DStress. Do you use Dstress?

 The testing process of DMD could be much less opaque in general.

 -Tomas


I should have picked another thread to reply to. I have no interest of
nightly builds of DMD.



 Mar 27 2009



  parent  Leandro Lucarella <llucax gmail.com>  writes:


Tomas Lindquist Olsen, el 27 de marzo a las 21:35 me escribiste:

 So what about the following counterargument: "even if nightly builds
 were made available, how can we be sure that enough people are using
 them to sufficiently test them?"  OK, sure, if not many people are
 using the nightly builds, then there wouldn't be much benefit.  But it
 does seem to work out fine for a lot of projects.  And with a proper
 SCM set up which you commit to daily, there's virtually no work on
 your part.  You just commit, and everyone else can download and
 compile.








[snip]

 I should have picked another thread to reply to. I have no interest of
 nightly builds of DMD.


BTW, when I originally said "nightly builds" I ment "nightly snapshots",
which is a poor man aproximation to an SCM. An SCM would be ideal, of
course.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
RENUNCIO PARA IR A REZARLE A SAN CAYETANO
	-- Crónica TV



 Mar 27 2009



prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen
<tomas.l.olsen gmail.com> wrote:

 On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows that
 even trivial changes are a bad idea for D1.


 Everyone certainly does not think it was a bad idea. If trivial things
 like this sets people off, they should at least look at the problem
 (and comment those few lines) before complaining.

 All my humble opinion of course.


 To me, it illustrates a fundamental disconnect. One cannot have both a 100%
 stable language and yet introduce improvements to it.


 I don't necessarily want a 100% stable language. In fact I don't. But
 obviously asking for both is just silly.
 The only thing I'm not happy about is if code that used to work, still
 compiles, but no longer works. This is where the real problem is and
 I've seen it several times. MinWin, APaGeD and probably others.


Which leads me to: If I was to help with a D 1.1 implementation, only
features that would not change any semantics of valid D1 code would go
in.



 Mar 26 2009



 next sibling parent reply grauzone <none example.net>  writes:


Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen
 <tomas.l.olsen gmail.com> wrote:

 On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Tomas Lindquist Olsen wrote:

 On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows that
 even trivial changes are a bad idea for D1.


 Everyone certainly does not think it was a bad idea. If trivial things
 like this sets people off, they should at least look at the problem
 (and comment those few lines) before complaining.

 All my humble opinion of course.


 To me, it illustrates a fundamental disconnect. One cannot have both a 100%
 stable language and yet introduce improvements to it.


 I don't necessarily want a 100% stable language. In fact I don't. But
 obviously asking for both is just silly.
 The only thing I'm not happy about is if code that used to work, still
 compiles, but no longer works. This is where the real problem is and
 I've seen it several times. MinWin, APaGeD and probably others.


 
 Which leads me to: If I was to help with a D 1.1 implementation, only
 features that would not change any semantics of valid D1 code would go
 in.


Isn't this the point of the whole "D 1.1" idea?



 Mar 26 2009



  parent  Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 9:45 PM, grauzone <none example.net> wrote:

 Tomas Lindquist Olsen wrote:

 Which leads me to: If I was to help with a D 1.1 implementation, only
 features that would not change any semantics of valid D1 code would go
 in.


 Isn't this the point of the whole "D 1.1" idea?


People seem to have different ideas of what D 1.1 should be.



 Mar 26 2009



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


Tomas Lindquist Olsen wrote:

 Which leads me to: If I was to help with a D 1.1 implementation, only
 features that would not change any semantics of valid D1 code would go
 in.


But they always do. Many of the complaints about D1 breaking things is 
the result of bug fixes to D1 inadvertently breaking something unexpected.



 Mar 26 2009



  parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com>  writes:


On Thu, Mar 26, 2009 at 10:02 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Tomas Lindquist Olsen wrote:

 Which leads me to: If I was to help with a D 1.1 implementation, only
 features that would not change any semantics of valid D1 code would go
 in.


 But they always do. Many of the complaints about D1 breaking things is the
 result of bug fixes to D1 inadvertently breaking something unexpected.


True.

However, now that the DMD source is available, that can change. All we
need is for it be put in a public repository (svn, hg etc). Then
people would be able to see what you're doing and test the fixes.
Catching bugs early in the process, as well as providing pretty much
guaranteed code review. I know I'd be subscribing my RSS reader to the
changelog at least.



 Mar 26 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Tomas Lindquist Olsen wrote:

 However, now that the DMD source is available, that can change. All we
 need is for it be put in a public repository (svn, hg etc). Then
 people would be able to see what you're doing and test the fixes.
 Catching bugs early in the process, as well as providing pretty much
 guaranteed code review. I know I'd be subscribing my RSS reader to the
 changelog at least.


I think that's a good idea.



 Mar 26 2009



prev sibling  parent  Trass3r <mrmocool gmx.de>  writes:


Walter Bright schrieb:

 As for the does one develop stable code targeting D1 and D2, I would 
 suggest targeting D1 but be careful to use the string alias for all the 
 char[]'s, and treat strings as if they were immutable. This will cover 
 90% of any source code changes between D1 and D2, perhaps even more than 
 90%. It's also very possible to write D1 code using the immutability 
 style, in fact, I advocated it long before D2 (see all the old threads 
 discussing Copy On Write).


Well, using the string alias leads to problems, esp. when used as a 
function parameter:
int func(string str)

This makes it impossible to pass a mutable string to the function in D2.

I personally use an  alias const(char)[] cstring;  for most of my 
parameters and  alias invariant(char)[] istring;  for normal immutable 
strings.



 Mar 26 2009



prev sibling  parent  cemiller <chris dprogramming.com>  writes:


On Thu, 26 Mar 2009 12:17:04 -0700, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Denis Koroskin wrote:

 One of the breaking changes that I recall was that you made Posix
 identifier built-in and thus any custom Posix versioning became an
 error. Not sure if it was introduced in 1.041, though, but it is
 still a breaking change.


 It was more of a build system change, but I get your point. It shows  
 that even trivial changes are a bad idea for D1.


Isn't there a very simple way to get the best of both... allow these  
versions to be re-set if they are valid for the platform. e.g. still allow  
me to -version=Posix on linux, but fail on Windows (ignoring that Windows  
can have some posix compliance).

The same could be done for the rest of the pre-set ones. It could also be  
an easy way for programmers to enforce compiling only with supported  
configurations.



 Mar 26 2009



prev sibling  parent reply "Denis Koroskin" <2korden gmail.com>  writes:


On Thu, 26 Mar 2009 21:27:52 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:


 ValeriM wrote:

 No. It's not stable.
 Try to build last Tango and DWT releases with D1.041 and you will get the
problems.


 I am not aware that D1.041 broke Tango and DWT. Please, which bugzilla
 numbers are those?
 


BTW, looks like you released 1.042 about two weeks ago, but the file is not
found on the server.



 Mar 26 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Denis Koroskin wrote:

 BTW, looks like you released 1.042 about two weeks ago, but the file
 is not found on the server.
 


It wasn't released. 1.041 is the current version.



 Mar 26 2009



prev sibling next sibling parent  Clay Smith <clayasaurus gmail.com>  writes:


Mike James wrote:

 What is the state of play with D1.0 vs. D2.0?
 
 Is D1.0 a dead-end and D2.0 should be used for future projects?
 
 Is D2.0 stable enough for use at the present?
 
 Is Tango for D2.0 at a level of D1.0 and can be used now?
 
 Is DWT ready for D2.0 now?
 
 
 Regards, mike.


Use DMD 1.0 if you want a stable language that works.

Use DMD 2.0 if you don't potentially changing your code with every 
compiler release, and don't need to use that many libraries.



 Mar 26 2009



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 26 Mar 2009 07:42:01 -0400, Mike James <foo bar.com> wrote:


 Is Tango for D2.0 at a level of D1.0 and can be used now?


No.  It is being worked on.  I don't forsee Tango for D2 being ready until  
at least September, perhaps later.

-Steve



 Mar 26 2009



  parent reply Brad Roberts <braddr puremagic.com>  writes:


Steven Schveighoffer wrote:

 On Thu, 26 Mar 2009 07:42:01 -0400, Mike James <foo bar.com> wrote:
 

 Is Tango for D2.0 at a level of D1.0 and can be used now?


 
 No.  It is being worked on.  I don't forsee Tango for D2 being ready
 until at least September, perhaps later.
 
 -Steve


Would you mind outlining / documenting what needs to be done?  I'd
expect that there are a number of people who would be interested in
volunteering to help.



 Mar 26 2009



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 26 Mar 2009 15:50:22 -0400, Brad Roberts <braddr puremagic.com>  
wrote:


 Steven Schveighoffer wrote:

 On Thu, 26 Mar 2009 07:42:01 -0400, Mike James <foo bar.com> wrote:


 Is Tango for D2.0 at a level of D1.0 and can be used now?


 No.  It is being worked on.  I don't forsee Tango for D2 being ready
 until at least September, perhaps later.

 -Steve


 Would you mind outlining / documenting what needs to be done?  I'd
 expect that there are a number of people who would be interested in
 volunteering to help.


what needs to be done:

1. Make Tango build on top of druntime.  I just merged from trunk  
yesterday, which was about 300 files, so most likely there will be compile  
issues ;)
2. Const-ify everything.  Some parts are already done.
3. Make all opApply's scoped properly.

Not sure what happens after that, but step 2 alone is a ton of work.  In  
addition, there are some blocker bugs in DMD (1645 and 2524 right now)  
that prevent a complete port.

When the shared/unshared paradigm is released, there's probably another  
ton of work to do :)

And of course, there's the possibility of redesigns.  A lot of code can  
probably make use of __traits and there are the new range constructs to  
consider.  Of course, these are all probably things that would be severely  
different from the D1 version, so they probably won't happen for a while.

Note that the September or later date is based on the amount of time I  
spend on it (which isn't a lot).  Someone who wanted to do nothing but  
porting Tango to D2 could probably get it done in a month or two.  Note  
also that I don't consider the port done until all the "cast to get it to  
compile" hacks are removed.  In some cases, this requires design changes,  
and in some of those, tough decisions.

-Steve



 Mar 26 2009



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


Steven Schveighoffer wrote:

 what needs to be done:
 
 1. Make Tango build on top of druntime.  I just merged from trunk 
 yesterday, which was about 300 files, so most likely there will be 
 compile issues ;)
 2. Const-ify everything.  Some parts are already done.
 3. Make all opApply's scoped properly.
 
 Not sure what happens after that, but step 2 alone is a ton of work.  In 
 addition, there are some blocker bugs in DMD (1645 and 2524 right now) 
 that prevent a complete port.
 
 When the shared/unshared paradigm is released, there's probably another 
 ton of work to do :)


You can already used shared/unshared. The semantics aren't implemented, 
but the type system support for it is.


 
 And of course, there's the possibility of redesigns.  A lot of code can 
 probably make use of __traits and there are the new range constructs to 
 consider.  Of course, these are all probably things that would be 
 severely different from the D1 version, so they probably won't happen 
 for a while.
 
 Note that the September or later date is based on the amount of time I 
 spend on it (which isn't a lot).  Someone who wanted to do nothing but 
 porting Tango to D2 could probably get it done in a month or two.  Note 
 also that I don't consider the port done until all the "cast to get it 
 to compile" hacks are removed.  In some cases, this requires design 
 changes, and in some of those, tough decisions.
 
 -Steve





 Mar 26 2009



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Thu, 26 Mar 2009 17:27:25 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Steven Schveighoffer wrote:

 what needs to be done:
  1. Make Tango build on top of druntime.  I just merged from trunk  
 yesterday, which was about 300 files, so most likely there will be  
 compile issues ;)
 2. Const-ify everything.  Some parts are already done.
 3. Make all opApply's scoped properly.
  Not sure what happens after that, but step 2 alone is a ton of work.   
 In addition, there are some blocker bugs in DMD (1645 and 2524 right  
 now) that prevent a complete port.
  When the shared/unshared paradigm is released, there's probably  
 another ton of work to do :)


 You can already used shared/unshared. The semantics aren't implemented,  
 but the type system support for it is.


But is it enforced?  Basically, I want to focus on one new language aspect  
at a time.  As far as I know, with the current D compiler, I can access a  
global not marked shared from multiple threads, no?  When shared/unshared  
is actually implemented, each thread gets its own copy, right?  It's still  
a fuzzy concept to me, and it seems like a waste of time to try and write  
code to use features that don't yet exist.  The longer I can put it off,  
the better.

The only impact I've seen so far is that singletons in Tango were  
sometimes named 'shared', so I had to change the names because of the  
reserved keyword.

-Steve



 Mar 26 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Steven Schveighoffer wrote:

 On Thu, 26 Mar 2009 17:27:25 -0400, Walter Bright 

 You can already used shared/unshared. The semantics aren't 
 implemented, but the type system support for it is.


 
 But is it enforced?


No, it is just type-checked.


 Basically, I want to focus on one new language 
 aspect at a time.  As far as I know, with the current D compiler, I can 
 access a global not marked shared from multiple threads, no?


That's correct.


 When 
 shared/unshared is actually implemented, each thread gets its own copy, 
 right?


Of unshared data, right, each thread gets its own copy. The default will 
be __thread for globals.



 Mar 26 2009