www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.030 and 2.014 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
These contain a new way of building that I've wanted to do for a long 
time. dmd can now build libraries directly, without writing out object 
files or invoking the librarian. This accelerates library builds by a 
whopping factor of 3! Besides, it doesn't litter your directories with 
pointless object files.

The library build option has another major coolness feature - before, 
one module compiles to one object file. With library build, one source 
file can compile to multiple object files. This cuts down on executable 
bloat from pulling in object files with irrelevant stuff in them.

Another build improvement is when multiple modules are compiled at the 
same time to build an executable, only one object file is created with 
the generated code for all modules combined into it. This speeds 
linking, and also eliminates pointless file detritus.

No, having dmd incorporate the linking is probably not going to happen 
:-(. Librarians are so simple, though, that this is a big win.

Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).

Another cool new feature is the dmd -man switch. Try it out! Lots of new 
library stuff, bugfixes, and Andrei has completely redone rdmd.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.030.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.014.zip
May 16 2008
next sibling parent janderson <askme me.com> writes:
Walter Bright wrote:

 These contain a new way of building that I've wanted to do for a long 
 time. dmd can now build libraries directly, without writing out object 
 files or invoking the librarian. This accelerates library builds by a 
 whopping factor of 3! Besides, it doesn't litter your directories with 
 pointless object files.
 
 The library build option has another major coolness feature - before, 
 one module compiles to one object file. With library build, one source 
 file can compile to multiple object files. This cuts down on executable 
 bloat from pulling in object files with irrelevant stuff in them.
 
 Another build improvement is when multiple modules are compiled at the 
 same time to build an executable, only one object file is created with 
 the generated code for all modules combined into it. This speeds 
 linking, and also eliminates pointless file detritus.
 
 No, having dmd incorporate the linking is probably not going to happen 
 :-(. Librarians are so simple, though, that this is a big win.
 
 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).
 
 Another cool new feature is the dmd -man switch. Try it out! Lots of new 
 library stuff, bugfixes, and Andrei has completely redone rdmd.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


Sweet!
May 17 2008
prev sibling next sibling parent janderson <askme me.com> writes:
<snip>


 Changed std.to to throw exception when object-to-object cast fails.



That's why they added the TryParse which would fail silently and return 
a best guess number (ie 0 if there was no number, MAX if overflow).  Is 
there an alternative in the std?  One that is silent or allows you to 
specify a default?

Of course that would not be hard to write, but it would be useful.

-Joel
May 17 2008
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 These contain a new way of building that I've wanted to do for a long
 time. dmd can now build libraries directly, without writing out
 object files or invoking the librarian. This accelerates library
 builds by a whopping factor of 3! Besides, it doesn't litter your
 directories with pointless object files.


How does incremental compilation work then, if there are no files ?
I'm assuming the factor applies when doing full rebuilds each time.


 [...] Librarians are so simple, though, that this is a big win. 

 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).


Neat, wonder if GDC should get this addition or if it will just add
complexity with portability, and the various odd platform linkers...

It's of course doable to emulate the -lib option in the gdmd script
wrapper otherwise, and use a temporary directory for object storage.


 Another cool new feature is the dmd -man switch. Try it out! Lots of new 
 library stuff, bugfixes, and Andrei has completely redone rdmd.


Will this new rdmd be released under an open source license as well ?
(the old version, which is also in gdc now, was in the public domain)

--anders
May 17 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Bjrklund wrote:

 Walter Bright wrote:
 

 These contain a new way of building that I've wanted to do for a long
 time. dmd can now build libraries directly, without writing out
 object files or invoking the librarian. This accelerates library
 builds by a whopping factor of 3! Besides, it doesn't litter your
 directories with pointless object files.


 
 How does incremental compilation work then, if there are no files ?
 I'm assuming the factor applies when doing full rebuilds each time.


It does a full build each time, and the times apply to a full build. 
Perhaps in the future a -make switch could be added to do an incremental 
build.


 [...] Librarians are so simple, though, that this is a big win.
 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).


 
 Neat, wonder if GDC should get this addition or if it will just add
 complexity with portability, and the various odd platform linkers...


It has no affect on the linker or linking phase. Also, since this isn't 
a language issue, whether gdc gets it or not is a tool decision.


 It's of course doable to emulate the -lib option in the gdmd script
 wrapper otherwise, and use a temporary directory for object storage.


Yes.



 Another cool new feature is the dmd -man switch. Try it out! Lots of 
 new library stuff, bugfixes, and Andrei has completely redone rdmd.


 
 Will this new rdmd be released under an open source license as well ?
 (the old version, which is also in gdc now, was in the public domain)


It should be, but I'll ask Andrei.
May 17 2008
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 Neat, wonder if GDC should get this addition or if it will just add
 complexity with portability, and the various odd platform linkers...


 
 It has no affect on the linker or linking phase. Also, since this isn't 
 a language issue, whether gdc gets it or not is a tool decision.


Guess I meant object formats (such as the ELF variants or Mach-O),
but you are right that it is ultimately decision entirely in gdc...

Q: Will there be a -shlib option too, to generate shared libraries ?
Rebuild currently has one, that matches its -lib (for static libs).

--anders
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Anders F Bjrklund wrote:

 Q: Will there be a -shlib option too, to generate shared libraries ?


Shared libraries aren't built by the librarian, but by the linker. They 
are special executables. dmd supports the -fPIC option, which builds the 
object files for shared libraries.
May 17 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Thanks for the release!

Walter Bright wrote:

 The library build option has another major coolness feature - before, 
 one module compiles to one object file. With library build, one source 
 file can compile to multiple object files. This cuts down on executable 
 bloat from pulling in object files with irrelevant stuff in them.
 
 Another build improvement is when multiple modules are compiled at the 
 same time to build an executable, only one object file is created with 
 the generated code for all modules combined into it. This speeds 
 linking, and also eliminates pointless file detritus.


How does this affect incremental build tools a la DSSS/rebuild or bud?
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:

 Thanks for the release!
 
 Walter Bright wrote:

 The library build option has another major coolness feature - before, 
 one module compiles to one object file. With library build, one source 
 file can compile to multiple object files. This cuts down on 
 executable bloat from pulling in object files with irrelevant stuff in 
 them.

 Another build improvement is when multiple modules are compiled at the 
 same time to build an executable, only one object file is created with 
 the generated code for all modules combined into it. This speeds 
 linking, and also eliminates pointless file detritus.


 
 How does this affect incremental build tools a la DSSS/rebuild or bud?


It shouldn't affect them. But they can now offer the option of building 
multiple objects per source file.
May 17 2008
prev sibling next sibling parent Max Samukha <nospam nospam.com> writes:
On Fri, 16 May 2008 23:29:49 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:


These contain a new way of building that I've wanted to do for a long 
time. dmd can now build libraries directly, without writing out object 
files or invoking the librarian. This accelerates library builds by a 
whopping factor of 3! Besides, it doesn't litter your directories with 
pointless object files.


Thanks a lot! bug 2100 is not listed in 1.030 change log. I guess 2109
is also fixed in 1.030?
May 17 2008
prev sibling next sibling parent davidl <davidl 126.com> writes:
在 Sat, 17 May 2008 14:29:49 +0800，Walter Bright  
<newshound1 digitalmars.com> 写道:


 These contain a new way of building that I've wanted to do for a long  
 time. dmd can now build libraries directly, without writing out object  
 files or invoking the librarian. This accelerates library builds by a  
 whopping factor of 3! Besides, it doesn't litter your directories with  
 pointless object files.

 The library build option has another major coolness feature - before,  
 one module compiles to one object file. With library build, one source  
 file can compile to multiple object files. This cuts down on executable  
 bloat from pulling in object files with irrelevant stuff in them.

 Another build improvement is when multiple modules are compiled at the  
 same time to build an executable, only one object file is created with  
 the generated code for all modules combined into it. This speeds  
 linking, and also eliminates pointless file detritus.

 No, having dmd incorporate the linking is probably not going to happen  
 :-(. Librarians are so simple, though, that this is a big win.

 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).

 Another cool new feature is the dmd -man switch. Try it out! Lots of new  
 library stuff, bugfixes, and Andrei has completely redone rdmd.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


Thanks for the hard working. Downloading now!
I wish we can preview some stuff/ new features visually on the website on  
the update release.

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
May 17 2008
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Thanks, Walter!

To everyone worried about the .obj generation change: ReBuild still 
provides incremental compilation, as it passes -c to the compiler, which 
makes it output multiple .obj-s.

-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Tom S wrote:

 To everyone worried about the .obj generation change: ReBuild still 
 provides incremental compilation, as it passes -c to the compiler, which 
 makes it output multiple .obj-s.



The new dmd also does not trace imports for dependencies, nor does it do 
incremental builds.
May 17 2008
prev sibling next sibling parent reply davidl <davidl 126.com> writes:
在 Sat, 17 May 2008 14:29:49 +0800，Walter Bright  
<newshound1 digitalmars.com> 写道:


 These contain a new way of building that I've wanted to do for a long  
 time. dmd can now build libraries directly, without writing out object  
 files or invoking the librarian. This accelerates library builds by a  
 whopping factor of 3! Besides, it doesn't litter your directories with  
 pointless object files.

 The library build option has another major coolness feature - before,  
 one module compiles to one object file. With library build, one source  
 file can compile to multiple object files. This cuts down on executable  
 bloat from pulling in object files with irrelevant stuff in them.

 Another build improvement is when multiple modules are compiled at the  
 same time to build an executable, only one object file is created with  
 the generated code for all modules combined into it. This speeds  
 linking, and also eliminates pointless file detritus.

 No, having dmd incorporate the linking is probably not going to happen  
 :-(. Librarians are so simple, though, that this is a big win.

 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).

 Another cool new feature is the dmd -man switch. Try it out! Lots of new  
 library stuff, bugfixes, and Andrei has completely redone rdmd.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


Added -lib switch to generate library files. Also causes multiple object  
files to be generated from one source module. <-- what does this exactly  
mean

We need more docs on this.

-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
May 17 2008
next sibling parent pragma <eric.t.anderton gmail.com> writes:
davidl wrote:

 在 Sat, 17 May 2008 14:29:49 +0800，Walter Bright 
 <newshound1 digitalmars.com> 写道:
 

 These contain a new way of building that I've wanted to do for a long 
 time. dmd can now build libraries directly, without writing out object 
 files or invoking the librarian. This accelerates library builds by a 
 whopping factor of 3! Besides, it doesn't litter your directories with 
 pointless object files.

 The library build option has another major coolness feature - before, 
 one module compiles to one object file. With library build, one source 
 file can compile to multiple object files. This cuts down on 
 executable bloat from pulling in object files with irrelevant stuff in 
 them.

 Another build improvement is when multiple modules are compiled at the 
 same time to build an executable, only one object file is created with 
 the generated code for all modules combined into it. This speeds 
 linking, and also eliminates pointless file detritus.

 No, having dmd incorporate the linking is probably not going to happen 
 :-(. Librarians are so simple, though, that this is a big win.

 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).

 Another cool new feature is the dmd -man switch. Try it out! Lots of 
 new library stuff, bugfixes, and Andrei has completely redone rdmd.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


 
 Added -lib switch to generate library files. Also causes multiple object 
 files to be generated from one source module. <-- what does this exactly 
 mean
 
 We need more docs on this.
 
 --使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/


Agreed.  While I can download and futz around with this myself, I'd like 
to know ahead of time what I'm getting into.  Does anyone have a 
practical example?

- Pragma
May 17 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
davidl wrote:

 Added -lib switch to generate library files. Also causes multiple object 
 files to be generated from one source module. <-- what does this exactly 
 mean
 
 We need more docs on this.


http://www.digitalmars.com/d/2.0/dmd-windows.html#library
May 17 2008
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:

 davidl wrote:

 Added -lib switch to generate library files. Also causes multiple
 object files to be generated from one source module. <-- what does
 this exactly mean

 We need more docs on this.


 
 http://www.digitalmars.com/d/2.0/dmd-windows.html#library


	This isn't very clear for people who don't already know how the
linker works and what static libraries are. Here's a go at something
more complete:

	When you create an executable (or a shared library), the linker
takes all the object files that you specified and glues them
together. It also translates all the external references, so that if
you use function "foo" in file a.o and this function is defined in
file b.o it will modify the code of a.o to point the implementation
of "foo".

	Static libraries are just collections of *optional* additional
object files. This means that if you have an object file c.o in a
static library and nobody refers to it, then it won't be included in
the executable, but if you use one function in c.o, then the *whole*
object file is included.

	The usual way to make object files is that one source file gives
one object file. This means that if you want to avoid executable
bloat, you need to split your source files so that people can call
one function without bringing in a lot of unnecessary functions that
just happened to be defined in the same file.

	What the "-lib" option does is to automagically split the files so
that a single source file will generate several small object files
instead of a single big one. This way you don't need to split your
source code into lots of small files if you don't want to, and your
executables won't become unnecessarily big from all those extra
functions.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger jabber.fr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFILzeqd0kWM4JG3k8RAtzmAJ9M4wIEe+KU7M5akehypBOfg5feKgCgsqTw
xLLOuj4Cvj/PkjjgSjumQ2E=
=6Nba
-----END PGP SIGNATURE-----
May 17 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 davidl wrote:

 Added -lib switch to generate library files. Also causes multiple 
 object files to be generated from one source module. <-- what does 
 this exactly mean

 We need more docs on this.


 
 http://www.digitalmars.com/d/2.0/dmd-windows.html#library


There, where you say "and existing object file bar.obj", don't you mean 
"abc.obj" instead?

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 28 2008
prev sibling next sibling parent reply John C <johnch_atms hotmail.com> writes:
Walter Bright Wrote:


 These contain a new way of building that I've wanted to do for a long 
 time. dmd can now build libraries directly, without writing out object 
 files or invoking the librarian. This accelerates library builds by a 
 whopping factor of 3! Besides, it doesn't litter your directories with 
 pointless object files.


When an executable is built using two libs built using this method, the
compiler (or optlink) errors out:
Previous Definition Different : _D10object.16212__ModuleInfoZ
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
John C wrote:

 When an executable is built using two libs built using this method,
 the compiler (or optlink) errors out: Previous Definition Different :
 _D10object.16212__ModuleInfoZ


You're right, that's a bug.
May 17 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Great!

I see a lot of "Got rid of some gotos" in the D2 changelog for phobos. 
Any plans for getting rid of them in DMD front-end? ;-)

How does rdmd compares to other build tools like bud or dsss?

(I guess my "dream" is to release a Descent version that matches the 
latest versions of DMD... it's always about catching up...)
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:

 I see a lot of "Got rid of some gotos" in the D2 changelog for phobos. 
 Any plans for getting rid of them in DMD front-end? ;-)


No :-)
May 17 2008
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter, I think I've found a potential bug in DMD 1.030 while porting it 
to Descent.

Take a look at cast.c, Expression *BinExp::typeCombine(Scope *sc), lines 
1371 and 1374:

/* Pick 'tightest' type
  */
ClassDeclaration *cd1 = tc1->sym->baseClass;
ClassDeclaration *cd2 = tc1->sym->baseClass;

shouldn't the second line use tc2 instead of tc1?

(Eclipse pointed me out that tc2 wasn't used... ;-)
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:

 Walter, I think I've found a potential bug in DMD 1.030 while porting it 
 to Descent.
 
 Take a look at cast.c, Expression *BinExp::typeCombine(Scope *sc), lines 
 1371 and 1374:
 
 /* Pick 'tightest' type
  */
 ClassDeclaration *cd1 = tc1->sym->baseClass;
 ClassDeclaration *cd2 = tc1->sym->baseClass;
 
 shouldn't the second line use tc2 instead of tc1?


Yes. Thanks for letting me know about this. I wonder how it passed the 
test case!
May 17 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:

 These contain a new way of building that I've wanted to do for a long 
 time. dmd can now build libraries directly, without writing out object 
 files or invoking the librarian. This accelerates library builds by a 
 whopping factor of 3! Besides, it doesn't litter your directories with 
 pointless object files.


Sweet!  And I guess this works on both Win32 and Linux?


Sean
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 Sweet!  And I guess this works on both Win32 and Linux?


Yes.
May 17 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:

 These contain a new way of building that I've wanted to do for a long 
 time. dmd can now build libraries directly, without writing out object 
 files or invoking the librarian. This accelerates library builds by a 
 whopping factor of 3! Besides, it doesn't litter your directories with 
 pointless object files.


Oh, I'm not sure if it does this already, but it would be great if DMD 
used the fully qualified module name instead of the file name for 
library additions.  Or something along those lines anyway.  Having to 
deal with filename collisions while building libraries is an annoying 
anachronism.  I believe with Tango we tell the librarian to use the path 
name instead of just the file name, but not all librarians support this.


Sean
May 17 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 Oh, I'm not sure if it does this already, but it would be great if DMD 
 used the fully qualified module name instead of the file name for 
 library additions.  Or something along those lines anyway.  Having to 
 deal with filename collisions while building libraries is an annoying 
 anachronism.  I believe with Tango we tell the librarian to use the path 
 name instead of just the file name, but not all librarians support this.


Andrei suggested the same, I just haven't gotten around to it.
May 17 2008
prev sibling next sibling parent pragma <eric.t.anderton gmail.com> writes:
Walter Bright wrote:

 These contain a new way of building that I've wanted to do for a long 
 time. dmd can now build libraries directly, without writing out object 
 files or invoking the librarian. This accelerates library builds by a 
 whopping factor of 3! Besides, it doesn't litter your directories with 
 pointless object files.
 
 The library build option has another major coolness feature - before, 
 one module compiles to one object file. With library build, one source 
 file can compile to multiple object files. This cuts down on executable 
 bloat from pulling in object files with irrelevant stuff in them.
 
 Another build improvement is when multiple modules are compiled at the 
 same time to build an executable, only one object file is created with 
 the generated code for all modules combined into it. This speeds 
 linking, and also eliminates pointless file detritus.
 
 No, having dmd incorporate the linking is probably not going to happen 
 :-(. Librarians are so simple, though, that this is a big win.
 
 Yes, both 1.0 and 2.0 dmd's get this (it doesn't affect the language).
 
 Another cool new feature is the dmd -man switch. Try it out! Lots of new 
 library stuff, bugfixes, and Andrei has completely redone rdmd.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


Looks like seriously cool stuff Walter.  Thanks for the hard work and 
the bug patches, as always.

- Pragma
May 17 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


Any chance we'll be getting a backport of the fix to bug 493 in DMD 
1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]

--bb
May 18 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


I understand your point, and I have mixed feelings about it. The trouble 
is, it isn't a stable target if it gets language changes, and everyone 
has a different idea on what should be moved from 2.0 to 1.0.
May 19 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 
 I understand your point, and I have mixed feelings about it. The trouble 
 is, it isn't a stable target if it gets language changes, and everyone 
 has a different idea on what should be moved from 2.0 to 1.0.


You're worried about existing D1 code that relies on IFTI failing?

--bb
May 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The 
 trouble is, it isn't a stable target if it gets language changes, and 
 everyone has a different idea on what should be moved from 2.0 to 1.0.


 
 You're worried about existing D1 code that relies on IFTI failing?


No, I'm concerned about different D1 compilers that support different 
languages.
May 21 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,


 Bill Baxter wrote:
 

 You're worried about existing D1 code that relies on IFTI failing?
 


 No, I'm concerned about different D1 compilers that support different
 languages.
 


For the time being there /are/ no other compilers (that I know of) to worry 
about unless you count older versions of DMD.

So I'm not so shure that is a big issue.
May 21 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The
 trouble is, it isn't a stable target if it gets language changes, and
 everyone has a different idea on what should be moved from 2.0 to 1.0.


 You're worried about existing D1 code that relies on IFTI failing?


 No, I'm concerned about different D1 compilers that support different
 languages.


But again, how does this represent a language change?


Sean
May 21 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

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

 Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The
 trouble is, it isn't a stable target if it gets language changes, and
 everyone has a different idea on what should be moved from 2.0 to 1.0.


 You're worried about existing D1 code that relies on IFTI failing?


 No, I'm concerned about different D1 compilers that support different
 languages.


 
 But again, how does this represent a language change?


I think the issue is that the spec gives one or maybe two specific 
examples of when IFTI works[1].  It says "if blah blah blah, then the 
template parameters will be deduced automatically".  It does not say 
what happens if *not* blah blah blah.

Plus it does say "implicitly, where the /TemplateArgumentList/ is 
deduced from the arguments", and not something like "*some or all* of 
the /TemplateArgumentList/ is deduced".  So I think Walter is right that 
a literal reading of the spec suggests that this a language change.

But my position is that

A) it just makes sense that if you can deduce them all then you should 
also be able to deduce just some.  Why wouldn't you be able to?  I never 
read the spec as saying "this is all that IFTI is intended to do", more 
like "here's one thing IFTI can do".  Actually the D2 spec doesn't 
mention this supposedly new feature[2], so that would argue that even 
Walter didn't see it as a spec change when he added it.

B) this is an important capability for porting D2 algorithms to D1.  The 
std2 project is halted mostly because of lack of this ability.

C) adding it should introduce little or no errors in existing D1 code 
since it used to be an error.  -- ok it is /conceivable/ that some code 
somewhere is using "is(typeof(...))" and counting on it failing when not 
all template parameters are specified, but I think this is pretty 
unlikely to affect much code at all.


[1] http://www.digitalmars.com/d/1.0/template.html under "Function 
Templates"

[2] If it does, I can't find it.  At least D2.0's [1] has the exact same 
text as D1's.

--bb
May 21 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:

 Sean Kelly wrote:

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

 Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The
 trouble is, it isn't a stable target if it gets language changes, and
 everyone has a different idea on what should be moved from 2.0 to 1.0.


 You're worried about existing D1 code that relies on IFTI failing?


 No, I'm concerned about different D1 compilers that support different
 languages.


 But again, how does this represent a language change?


 
 I think the issue is that the spec gives one or maybe two specific 
 examples of when IFTI works[1].  It says "if blah blah blah, then the 
 template parameters will be deduced automatically".  It does not say 
 what happens if *not* blah blah blah.
 
 Plus it does say "implicitly, where the /TemplateArgumentList/ is 
 deduced from the arguments", and not something like "*some or all* of 
 the /TemplateArgumentList/ is deduced".  So I think Walter is right that 
 a literal reading of the spec suggests that this a language change.


My understanding of IFTI was that it was intended to eventually work a 
lot like IFTI in C++.  Walter has certainly said as much in the past, at 
any rate.  So I don't accept that we should have read between the lines 
in the spec regarding this.  Besides, if a strict interpretation of the 
spec were required then I'd expect D 1.0 to have things like inheritable 
contracts--a feature which may never actually make it into the language 
at all, despite requests.


Sean
May 22 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g11ove$181r$1 digitalmars.com...

 Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The trouble 
 is, it isn't a stable target if it gets language changes, and everyone 
 has a different idea on what should be moved from 2.0 to 1.0.


 You're worried about existing D1 code that relies on IFTI failing?


 No, I'm concerned about different D1 compilers that support different 
 languages.


Uh, DMD 1.000 vs. DMD 1.030?
May 21 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:g12s4e$j26$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g11ove$181r$1 digitalmars.com...

 Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The 
 trouble is, it isn't a stable target if it gets language changes, and 
 everyone has a different idea on what should be moved from 2.0 to 1.0.


 You're worried about existing D1 code that relies on IFTI failing?


 No, I'm concerned about different D1 compilers that support different 
 languages.


 Uh, DMD 1.000 vs. DMD 1.030?


The point being that _this has already happened_ with, apparently, no real 
problems.
May 21 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Jarrett Billingsley wrote:

 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:g12s4e$j26$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:g11ove$181r$1 digitalmars.com...

 Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The 
 trouble is, it isn't a stable target if it gets language changes, and 
 everyone has a different idea on what should be moved from 2.0 to 1.0.


 You're worried about existing D1 code that relies on IFTI failing?


 No, I'm concerned about different D1 compilers that support different 
 languages.


 Uh, DMD 1.000 vs. DMD 1.030?


 
 The point being that _this has already happened_ with, apparently, no real 
 problems. 


Walter's argument could apply to really any bug fix anyway, because they 
all affect compiler behavior.  I think what's important is to determine 
what the intended feature set was for D 1.0 and decide based on that. 
Clearly, we all thought that IFTI would eventually work as advertised in 
D 1.0, and perhaps Walter does not agree.  What worries me is that long 
asked-for bug fixes like this may be left out of DMD 1.0 as a way to 
"encourage" people to move to D 2.0.  If that happens, I'm out.


Sean
May 22 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way to 
 "encourage" people to move to D 2.0.  If that happens, I'm out.


Indeed that's a fear I have as well. D 1.0 has never been fully stable 
(look at the ".init" change that happened after 2.0 was out... that 
broke a lot of code). So it seems rather arbitrary that a bug fix like 
this (reported as bug, not an enhancement, before 2.0 was on the 
horizon) would only make it to the 2.0 branch.
May 22 2008
parent reply Chris Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:

 Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way to 
 "encourage" people to move to D 2.0.  If that happens, I'm out.


 
 Indeed that's a fear I have as well. D 1.0 has never been fully stable 
 (look at the ".init" change that happened after 2.0 was out... that 
 broke a lot of code). So it seems rather arbitrary that a bug fix like 
 this (reported as bug, not an enhancement, before 2.0 was on the 
 horizon) would only make it to the 2.0 branch.


A lot of people have been annoyed by a lot of these changes. 
Unfortunately, nobody (and that includes the lack of me) has gotten off 
their butts to release a DMD 1.1.x branch.
May 22 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Wright wrote:

 Robert Fraser wrote:

 Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way to 
 "encourage" people to move to D 2.0.  If that happens, I'm out.


 Indeed that's a fear I have as well. D 1.0 has never been fully stable 
 (look at the ".init" change that happened after 2.0 was out... that 
 broke a lot of code). So it seems rather arbitrary that a bug fix like 
 this (reported as bug, not an enhancement, before 2.0 was on the 
 horizon) would only make it to the 2.0 branch.


 
 A lot of people have been annoyed by a lot of these changes. 
 Unfortunately, nobody (and that includes the lack of me) has gotten off 
 their butts to release a DMD 1.1.x branch.


When you say "nobody" are you suggesting that the D community should 
create a 1.1 branch and release it whether Walter wants it or not?

--bb
May 22 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Bill Baxter wrote:

 Chris Wright wrote:

 Robert Fraser wrote:

 Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way to 
 "encourage" people to move to D 2.0.  If that happens, I'm out.


 Indeed that's a fear I have as well. D 1.0 has never been fully 
 stable (look at the ".init" change that happened after 2.0 was out... 
 that broke a lot of code). So it seems rather arbitrary that a bug 
 fix like this (reported as bug, not an enhancement, before 2.0 was on 
 the horizon) would only make it to the 2.0 branch.


 A lot of people have been annoyed by a lot of these changes. 
 Unfortunately, nobody (and that includes the lack of me) has gotten 
 off their butts to release a DMD 1.1.x branch.


 
 When you say "nobody" are you suggesting that the D community should 
 create a 1.1 branch and release it whether Walter wants it or not?
 
 --bb


That's a good idea (I don't think Walter would be against it; but he 
certainly doesn't have the time to maintain 3 branches). I suspect it 
would be of GDC, though; since DMD's backend is closed-source.
May 22 2008
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:

 Chris Wright wrote:

 Robert Fraser wrote:

 Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way to 
 "encourage" people to move to D 2.0.  If that happens, I'm out.


 Indeed that's a fear I have as well. D 1.0 has never been fully 
 stable (look at the ".init" change that happened after 2.0 was out... 
 that broke a lot of code). So it seems rather arbitrary that a bug 
 fix like this (reported as bug, not an enhancement, before 2.0 was on 
 the horizon) would only make it to the 2.0 branch.


 A lot of people have been annoyed by a lot of these changes. 
 Unfortunately, nobody (and that includes the lack of me) has gotten 
 off their butts to release a DMD 1.1.x branch.


 
 When you say "nobody" are you suggesting that the D community should 
 create a 1.1 branch and release it whether Walter wants it or not?


I am. There seems to be demand for it. And if there were such a branch, 
Walter could even stop maintaining the 1.x branch because bugfixes from 
the 2.x branch would get ported to the 1.1 branch.

This isn't ideal for the community, perhaps. If enough people were 
involved, however, Walter would just be working on an experimental 
branch, and the community would handle bugfixes.


 --bb
May 23 2008
next sibling parent reply Lutger <lutger.blijdestin gmail.com> writes:
Chris Wright wrote:

 
 I am. There seems to be demand for it. And if there were such a branch,
 Walter could even stop maintaining the 1.x branch because bugfixes from
 the 2.x branch would get ported to the 1.1 branch.
 
 This isn't ideal for the community, perhaps. If enough people were
 involved, however, Walter would just be working on an experimental
 branch, and the community would handle bugfixes.
 

 --bb




imho, this would only be a good idea if 1.1 would not be another branch, but
replace the current D1 language. D1 was and is about D not being a moving
target and that has been pretty successful as far as I can see. Creating a
language incompatible with both 1.0x and 2.x will only complicate matters. 

Implementing 'changes' like the currently discussed one that don't have much
impact or are actually clarifications from the spec is one thing. But
adding new features, even if backward compatible, may introduce again the
situation that libraries grow out-of-sync. How much of a problem that will
be in practice, I don't know. But development in D is much more practical
now than before D1 was stabilized, and it would be very unfortunate to lose
that.

Besides, the plan is stabilize D2 somewhere this year already (iirc). Thus
such a branch might not even be worthwhile before the migration starts.
May 23 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Lutger wrote:

 Implementing 'changes' like the currently discussed one that don't have much
 impact or are actually clarifications from the spec is one thing. But
 adding new features, even if backward compatible, may introduce again the
 situation that libraries grow out-of-sync.


I'd hope the features selected would be such that most D libraries would 
still be able to compile. For example, Java is _mostly_ backwards 
compatible to 1.0 (if you take out the "enum" and "assert" keywords, 
it;s likely that 1.0 code would compile fine under 1.6). I'd hope the 
same is true of D if it gets a 1.1 branch (that is, if any new features 
are added, they are done in a way that DOES not keep libraries out-of-sync).

If it was designed in a way to keep a large, mostly-spanning subset of 
(multiple versions of) D1 libraries/apps (i.e. Tango, Phobos, DFL, DWT, 
Derelict, MiniD, a few other big ones) compiling at every release, it 
would be reasonable to assume that most D1 code would compile rather 
easily with it. I'd also hope that any DStress tests that pass with D 
1.030 (or whenever the branch is made) would remain a strict subset of 
the DStress tests that pass as the branch evolves.

If these conditions were met, it would be possible to add in *some* 
backwards-compatible changes that would benefit the community and still 
allow libraries designed for the 1.0 branch to keep compiling. But 
that's just my personal pipe dream: I'm sure some people wouldn't mind 
having 3 completely distinct branches, while others would prefer that 
only bugfixies make it into 1.1.
May 23 2008
parent reply Chris Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:

 Lutger wrote:

 Implementing 'changes' like the currently discussed one that don't 
 have much
 impact or are actually clarifications from the spec is one thing. But
 adding new features, even if backward compatible, may introduce again the
 situation that libraries grow out-of-sync.


 
 I'd hope the features selected would be such that most D libraries would 
 still be able to compile. For example, Java is _mostly_ backwards 
 compatible to 1.0 (if you take out the "enum" and "assert" keywords, 
 it;s likely that 1.0 code would compile fine under 1.6). I'd hope the 
 same is true of D if it gets a 1.1 branch (that is, if any new features 
 are added, they are done in a way that DOES not keep libraries 
 out-of-sync).


So you'd accept added keywords such as __traits, I take it? Though 
invariant would be a pretty controversial one to add.


 If it was designed in a way to keep a large, mostly-spanning subset of 
 (multiple versions of) D1 libraries/apps (i.e. Tango, Phobos, DFL, DWT, 
 Derelict, MiniD, a few other big ones) compiling at every release, it 
 would be reasonable to assume that most D1 code would compile rather 
 easily with it. I'd also hope that any DStress tests that pass with D 
 1.030 (or whenever the branch is made) would remain a strict subset of 
 the DStress tests that pass as the branch evolves.
 
 If these conditions were met, it would be possible to add in *some* 
 backwards-compatible changes that would benefit the community and still 
 allow libraries designed for the 1.0 branch to keep compiling. But 
 that's just my personal pipe dream: I'm sure some people wouldn't mind 
 having 3 completely distinct branches, while others would prefer that 
 only bugfixies make it into 1.1.


I think a fair number of people would be perfectly happy with a D2 
branch minus const. I mean, what else was added that's not to love? 
Besides instability, that is. But the only thing preventing people from 
using most of these libraries with dmd2.014 is probably const.
May 23 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Chris Wright wrote:

 So you'd accept added keywords such as __traits, I take it? Though 
 invariant would be a pretty controversial one to add.


Well, __traits is okay because it isn't commonly used as an identifier. 
But I'd prefer "macro" be changed to something like "__macro" in a 
backport (people might be using that as a variable name). Again, just 
personal opinion, that stuff doesn't matter too much.


 I think a fair number of people would be perfectly happy with a D2 
 branch minus const. I mean, what else was added that's not to love? 
 Besides instability, that is. But the only thing preventing people from 
 using most of these libraries with dmd2.014 is probably const.


IMO, pure and nothrow, too. I think it's a good idea but it requires too 
much library support (i.e. there's no way to write a standard lib that 
would work well under D1.0 and D1.1 if the latter had pure and nothrow). 
Also, overload sets (great idea, but very much breaking).

I think there's at least one naysayer for every D2 feature, so you can't 
please everybody. I think whoever creates the branch needs to go 
mini-Walter and decide for him/her self which features to back port -- 
the D community will be richer with it than without it.
May 24 2008
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Robert Fraser wrote:

 Also, overload sets (great idea, but very much breaking).


I haven't used D2 much, but from what I've read on overload sets I can't 
see how they'd breaking (very much) stuff.
 From what I understand, the "single overload set" case is identical to 
what happens in D1, and the cases with multiple ones are always an error 
in D1 (assuming a call to one of the overloads is attempted). The only 
case where the behavior would differ in the case of valid D1 code 
compiled as "D1 + overload sets" would be the result of something like 
is(typeof(foo(ARGS))) where "foo" consists of multiple overload sets, 
AFAICT. And I can't imagine that corner case to be "very much breaking" 
all by itself...
May 24 2008
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:

 Chris Wright wrote:

 So you'd accept added keywords such as __traits, I take it? Though 
 invariant would be a pretty controversial one to add.


 
 Well, __traits is okay because it isn't commonly used as an identifier. 
 But I'd prefer "macro" be changed to something like "__macro" in a 
 backport (people might be using that as a variable name). Again, just 
 personal opinion, that stuff doesn't matter too much.


It's another point of friction; ideally, anything that compiles in D1 
will compile in D1.1. (Dunno yet how serious I am about forking, unless 
someone offers to help. In that case, I am quite serious.)


 I think a fair number of people would be perfectly happy with a D2 
 branch minus const. I mean, what else was added that's not to love? 
 Besides instability, that is. But the only thing preventing people 
 from using most of these libraries with dmd2.014 is probably const.


 
 IMO, pure and nothrow, too. I think it's a good idea but it requires too 
 much library support (i.e. there's no way to write a standard lib that 
 would work well under D1.0 and D1.1 if the latter had pure and nothrow). 
 Also, overload sets (great idea, but very much breaking).


Pure and nothrow aren't implemented yet, I think, so it'd be easy to 
exclude them.

I agree with Fritz's assessment on overload sets, unless you can come up 
with a sample of code that overload sets breaks.
May 25 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Wright wrote:

 I agree with Fritz's assessment on overload sets, [...]


Thanks, but my name is Frits...
May 25 2008
parent Chris Wright <dhasenan gmail.com> writes:
Frits van Bommel wrote:

 Chris Wright wrote:

 I agree with Fritz's assessment on overload sets, [...]


 
 Thanks, but my name is Frits...


Sorry, I've been reading a book where the main character's name is Fitz 
(the Farseer trilogy by Robin Hobb), so I'm lucky that I remembered the 
R. I meant to check the spelling, but I got lazy.
May 25 2008
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
Chris Wright wrote:

 Bill Baxter wrote:

 Chris Wright wrote:

 Robert Fraser wrote:

 Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way 
 to "encourage" people to move to D 2.0.  If that happens, I'm out.


 Indeed that's a fear I have as well. D 1.0 has never been fully 
 stable (look at the ".init" change that happened after 2.0 was 
 out... that broke a lot of code). So it seems rather arbitrary that 
 a bug fix like this (reported as bug, not an enhancement, before 2.0 
 was on the horizon) would only make it to the 2.0 branch.


 A lot of people have been annoyed by a lot of these changes. 
 Unfortunately, nobody (and that includes the lack of me) has gotten 
 off their butts to release a DMD 1.1.x branch.


 When you say "nobody" are you suggesting that the D community should 
 create a 1.1 branch and release it whether Walter wants it or not?


 
 I am. There seems to be demand for it. And if there were such a branch, 
 Walter could even stop maintaining the 1.x branch because bugfixes from 
 the 2.x branch would get ported to the 1.1 branch.


Though this is made harder since the DMD frontend isn't developed using 
any version control system that I can access. So I can only see a whole 
lump of changes between two dmd2 revisions, many of which are bugfixes, 
many of which are changed features that will impact user code, and some 
of which are actually nonbreaking features. Given the overhauls done to 
const, it may be a better idea just to diff dmd1.030 and dmd2.014 and 
start from there.
May 23 2008
prev sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Chris Wright wrote:

 Bill Baxter wrote:

 Chris Wright wrote:

 Robert Fraser wrote:

 Sean Kelly wrote:

 What worries me is that long
 asked-for bug fixes like this may be left out of DMD 1.0 as a way 
 to "encourage" people to move to D 2.0.  If that happens, I'm out.


 Indeed that's a fear I have as well. D 1.0 has never been fully 
 stable (look at the ".init" change that happened after 2.0 was 
 out... that broke a lot of code). So it seems rather arbitrary that 
 a bug fix like this (reported as bug, not an enhancement, before 2.0 
 was on the horizon) would only make it to the 2.0 branch.


 A lot of people have been annoyed by a lot of these changes. 
 Unfortunately, nobody (and that includes the lack of me) has gotten 
 off their butts to release a DMD 1.1.x branch.


 When you say "nobody" are you suggesting that the D community should 
 create a 1.1 branch and release it whether Walter wants it or not?


 
 I am. There seems to be demand for it. And if there were such a branch, 
 Walter could even stop maintaining the 1.x branch because bugfixes from 
 the 2.x branch would get ported to the 1.1 branch.
 
 This isn't ideal for the community, perhaps. If enough people were 
 involved, however, Walter would just be working on an experimental 
 branch, and the community would handle bugfixes.
 

 --bb




I've wanted a D 1.1 for a long time. When LLVMDC gets more stable (by that I
mean to a point 
where it can compete with DMD), I could be interested in starting such a fork.
May 26 2008
prev sibling next sibling parent Lutger <lutger.blijdestin gmail.com> writes:
Walter Bright wrote:


 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 
 I understand your point, and I have mixed feelings about it. The trouble
 is, it isn't a stable target if it gets language changes, and everyone
 has a different idea on what should be moved from 2.0 to 1.0.


In this case though the change can be interpreted as a bug right? So it is
not a question of opinion on what should be moved but rather whether it is
seen as a bug or a change. That's a pretty clear line.
May 20 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The trouble
 is, it isn't a stable target if it gets language changes, and everyone
 has a different idea on what should be moved from 2.0 to 1.0.


I'm not sure I understand.  Could you please explain why this issue is
a language change and not a bug?  The ticket was certainly submitted
well prior to D 2.0's release.


Sean
May 20 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

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

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The trouble
 is, it isn't a stable target if it gets language changes, and everyone
 has a different idea on what should be moved from 2.0 to 1.0.


 
 I'm not sure I understand.  Could you please explain why this issue is
 a language change and not a bug?  The ticket was certainly submitted
 well prior to D 2.0's release.


I think we just need to have a D1.1 release.  That would make everyone 
happy.  Like Miles just said, basically.

The majority of available code right now is D1 only.  So if you don't 
want to reinvent lots of wheels, your best bet is D1.  As most everyone 
knows, Tango is D1 only.  Probably the majority of long-timers here are 
still D1 only simply because if you have lots of code that works, moving 
all of it to an unstable D2 is not a very compelling proposition.

Let me put it this way.  I don't have the time or really the interest at 
this point to get my libs (OpenMeshD, Multiarray, Luigi) or the libs I 
depend on (DWT and Tango via that) updated to D2.  And beyond my dsource 
libs I have probably about an equal amount of application code written 
in D1.  I think probably a number of folks in the Tango team are in the 
same boat, and probably various others who got started with D1 and have 
been enjoying using it.

So does it make sense to leave this demographic of heavy D users behind 
with an aging feature set?

Ugh, I don't think I'm saying this well at all, but I can't spend any 
more time on this email, because I have to get back to my actual 
full-time job (writing D1 code, ATM).  Basically to sum it up, it seems 
to me like current development priorities neglect some of the most loyal 
D users, those who have been using it and writing large-ish libraries 
since D0 days.  A backward-compatible features-only D1.1 release would 
serve that, IMHO, important demographic.

--bb
May 20 2008
next sibling parent reply "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Bill Baxter wrote:

 Sean Kelly wrote:

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





 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=3D493 ]


 I understand your point, and I have mixed feelings about it. The trou=






ble

 is, it isn't a stable target if it gets language changes, and everyon=






e

 has a different idea on what should be moved from 2.0 to 1.0.


 I'm not sure I understand.  Could you please explain why this issue is=





 a language change and not a bug?  The ticket was certainly submitted
 well prior to D 2.0's release.


=20
 I think we just need to have a D1.1 release.  That would make everyone =



 happy.  Like Miles just said, basically.


Perhaps just using D2 as a testing version where new features are=20
debugged before they're merged onto D1?  That might even be better, so=20
that library makers have an opportunity to see a new feature coming in=20
the future.


 The majority of available code right now is D1 only.  So if you don't=20
 want to reinvent lots of wheels, your best bet is D1.  As most everyone=


=20

 knows, Tango is D1 only.  Probably the majority of long-timers here are=


=20

 still D1 only simply because if you have lots of code that works, movin=


g=20

 all of it to an unstable D2 is not a very compelling proposition.
=20
 Let me put it this way.  I don't have the time or really the interest a=


t=20

 this point to get my libs (OpenMeshD, Multiarray, Luigi) or the libs I =



 depend on (DWT and Tango via that) updated to D2.  And beyond my dsourc=


e=20

 libs I have probably about an equal amount of application code written =



 in D1.  I think probably a number of folks in the Tango team are in the=


=20

 same boat, and probably various others who got started with D1 and have=


=20

 been enjoying using it.


I know there was an experimental branch a while back that was supposed=20
to have worked with D2.  I don't know if it's still maintained.


 So does it make sense to leave this demographic of heavy D users behind=


=20

 with an aging feature set?
=20
 Ugh, I don't think I'm saying this well at all, but I can't spend any=20
 more time on this email, because I have to get back to my actual=20
 full-time job (writing D1 code, ATM).  Basically to sum it up, it seems=


=20

 to me like current development priorities neglect some of the most loya=


l=20

 D users, those who have been using it and writing large-ish libraries=20
 since D0 days.  A backward-compatible features-only D1.1 release would =



 serve that, IMHO, important demographic.


Perhaps a Debian-like system, with an experimental, unstable, testing,=20
and stable branch?  New stuff can be introduced in experimental,=20
debugged to unstable, and then people can debate whether they like it or =

not as it phases from there into testing and finally stable.  Hopefully=20
it'd slow down the rate of new compiler releases on the stable line, and =

make the changes between releases smaller, which would benefit library=20
makers.

I'm not saying its the only system, or even the best, but if "the=20
system" is going to change (which seems a mighty big assumption to me),=20
it's something to at least consider.
May 20 2008
parent BCS <ao pathlink.com> writes:
Reply to Chris,


 New stuff can be introduced in experimental, debugged to unstable, and
 then people can debate whether they like it or not as it phases from
 there into testing and finally stable.
 


One problem, 2.0 has things that can't not be breaking changes. I don't ever 
want to see them in 1.0. I feel that is a distinction that must be maintained, 
and if it is, we need the 2.0 branch to play them in. With that IMHO, there 
won't be much reason to have the other levels.
May 20 2008
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Bill,


 A backward-compatible features-only D1.1 release would serve that,
 IMHO, important demographic.
 


I'll second that.

I'd kinda like to see a version that is backwards compatible with 1.0 but 
allows in most anything that can be argued well as fixing an "issue" even 
if it is more than just a bug fix.
May 20 2008
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Bill Baxter wrote:

 A backward-compatible features-only D1.1 release would 
 serve that, IMHO, important demographic.


I don't think Walter would ever go for it. That doesn't mean someone in 
the D community couldn't make a compiler for a version of D with only 
backwards-compatible additions from D2.
May 20 2008
prev sibling parent Don <nospam nospam.com.au> writes:
Bill Baxter wrote:

 Sean Kelly wrote:

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

 Bill Baxter wrote:

 Any chance we'll be getting a backport of the fix to bug 493 in DMD
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]


 I understand your point, and I have mixed feelings about it. The trouble
 is, it isn't a stable target if it gets language changes, and everyone
 has a different idea on what should be moved from 2.0 to 1.0.




 
 The majority of available code right now is D1 only.  So if you don't
 want to reinvent lots of wheels, your best bet is D1.  As most everyone
 knows, Tango is D1 only.  Probably the majority of long-timers here are
 still D1 only simply because if you have lots of code that works, moving
 all of it to an unstable D2 is not a very compelling proposition.



 So does it make sense to leave this demographic of heavy D users behind 
 with an aging feature set?


It's not just that. By making _no_ changes to D1.0, it makes later 
migration to D2.0 more painful. I think migration is an issue that needs 
more thought. Especially considering that the majority of new code will 
be developed under D1.0, not D2, probably for a year or so longer.
May 21 2008
prev sibling parent Miles <_______ _______.____> writes:
Walter Bright wrote:

 I understand your point, and I have mixed feelings about it. The trouble 
 is, it isn't a stable target if it gets language changes, and everyone 
 has a different idea on what should be moved from 2.0 to 1.0.


Again, I reinforce that D versioning scheme is one of its most painful 
deficiencies. A three-component version numbering scheme 
(major.minor.patch) would best support this kind of development.

Such a change would land on the 1.x branch, without affecting the 
current 1.0.x branch, and eventually released as 1.1.0. No problem at all.

Soon, when the 2.x branch is stable enough for release as "stable", you 
will find that you won't be able to call it 2.anything, because there 
won't be any "reference point" inside the 2.x branch to call it stable, 
and the first "stable" release of 2.x will probably be called 3.0.

This should have been done long ago, since the first 1.x versions.

Good articles to read:
http://en.wikipedia.org/wiki/Software_versioning
http://www.advogato.org/article/40.html
May 20 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.030.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.014.zip


 
 Any chance we'll be getting a backport of the fix to bug 493 in DMD 
 1.031?   [ http://d.puremagic.com/issues/show_bug.cgi?id=493 ]
 
 --bb


Hum, nice, I didn't know that was possible. I guess I didn't see it 
since no spec change occurred because of that fix (although it should?).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 28 2008
prev sibling parent reply =?iso-8859-1?Q?Julio=20C=e9sar=20Carrascal=20Urquijo?= <jcarrascal gmail.com> writes:
Great stuff Walter. Thanks


Walter Bright wrote:


 The library build option has another major coolness feature - before,
 one module compiles to one object file. With library build, one source
 file can compile to multiple object files. This cuts down on
 executable bloat from pulling in object files with irrelevant stuff in
 them.


On question, though. How does DMD decide to split a module in servera .obj 
files? By class or once a threshold is reached?
May 19 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Julio Csar Carrascal Urquijo wrote:

 On question, though. How does DMD decide to split a module in servera 
 .obj files? By class or once a threshold is reached?


It's done for things that would be generated in multiple files, like 
template instantiations and typeinfo data.
May 19 2008