↑ ↓ ← → 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.htmlhttp://ftp.digitalmars.com/dmd.1.030.ziphttp://www.digitalmars.com/d/2.0/changelog.htmlhttp://ftp.digitalmars.com/dmd.2.014.zip
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.htmlhttp://ftp.digitalmars.com/dmd.1.030.ziphttp://www.digitalmars.com/d/2.0/changelog.htmlhttp://ftp.digitalmars.com/dmd.2.014.zip
Changed std.to to throw exception when object-to-object cast fails.
What always annoyed me in C# was the conversions causing exceptions.
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
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
↑ ↓ ←→ 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)
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
↑ ↓ ← → 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
↑↓←→ 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
↑ ↓ ← → 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.
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?
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.htmlhttp://ftp.digitalmars.com/dmd.1.030.ziphttp://www.digitalmars.com/d/2.0/changelog.htmlhttp://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
↑↓←→ 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
↑ ↓ ← → 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.
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.htmlhttp://ftp.digitalmars.com/dmd.1.030.ziphttp://www.digitalmars.com/d/2.0/changelog.htmlhttp://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/
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.htmlhttp://ftp.digitalmars.com/dmd.1.030.ziphttp://www.digitalmars.com/d/2.0/changelog.htmlhttp://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
↑ ↓ ←→ 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.
-----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.
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
↑ ↓ ← → 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.
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
↑ ↓ ← → 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
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
↑ ↓ ← → 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? ;-)
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
↑ ↓ ← → 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!
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
↑ ↓ ← → Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
Sweet! And I guess this works on both Win32 and Linux?
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
↑ ↓ ← → 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.
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.htmlhttp://ftp.digitalmars.com/dmd.1.030.ziphttp://www.digitalmars.com/d/2.0/changelog.htmlhttp://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
↑↓←→ Bill Baxter <dnewsgroup billbaxter.com> writes:
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
↑ ↓←→ Bill Baxter <dnewsgroup billbaxter.com> writes:
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
↑ ↓ ←→ Walter Bright <newshound1 digitalmars.com> writes:
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.
You're worried about existing D1 code that relies on IFTI failing?
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.
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?
languages.
But again, how does this represent a language change?
Sean
May 21 2008
↑ ↓ ←→ Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
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.
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
↑ ↓ ← → Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter wrote:
Sean Kelly wrote:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
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.
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
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.
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.
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.
languages.
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
↑ ↓ ←→ 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.
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
↑ ↓ ←→ 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
↑ ↓← → 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.
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.
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
↑ ↓ ←→ 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.
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
↑ ↓ ←→ 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
↑ ↓← → 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...
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
↑ ↓ ←→ Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Chris Wright wrote:
I agree with Fritz's assessment on overload sets, [...]
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.
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
↑ ↓ ← → 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.
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.
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
↑ ↓ ←→ Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
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
↑ ↓←→ "Chris R. Miller" <lordSaurontheGreat gmail.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Bill Baxter wrote:
Sean Kelly wrote:
=3D=3D Quote from Walter Bright (newshound1 digitalmars.com)'s article=
is, it isn't a stable target if it gets language changes, and everyon=
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.
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=
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, movin=
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=
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=
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.
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=
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=
to me like current development priorities neglect some of the most loya=
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.
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.
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
↑↓← → 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.
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.
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_versioninghttp://www.advogato.org/article/40.html
May 20 2008
↑ ↓ ← → Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
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
↑ ↓ ← → 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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next