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