www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.006 release

reply Walter Bright <newshound digitalmars.com> writes:
Compile time function execution! (Please discuss in the corresponding 
thread in digitalmars.D)

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

http://ftp.digitalmars.com/dmd.1.006.zip
Feb 15 2007
next sibling parent reply Reiner Pope <xxxx xxx.xxx> writes:
Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

The interpretation section is missing from function.html in the docs.
Feb 15 2007
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Reiner Pope wrote:
 The interpretation section is missing from function.html in the docs.

Should be there now.
Feb 15 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Reiner Pope wrote:
 Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)

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

 http://ftp.digitalmars.com/dmd.1.006.zip

The interpretation section is missing from function.html in the docs.

Yes, it seems the site hasn't been updated yet. And not just that page, the URL referenced in http://d.puremagic.com/issues/show_bug.cgi?id=960 (listed as fixed) doesn't seem to be updated either. They're provided in the zip though (dmd/html/d/function.html and dmd/html/d/future.html).
Feb 15 2007
parent reply jcc7 <technocrat7 gmail.com> writes:
== Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 Reiner Pope wrote:
 Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding
 thread in digitalmars.D)

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

 http://ftp.digitalmars.com/dmd.1.006.zip

The interpretation section is missing from function.html in the docs.

the URL referenced in http://d.puremagic.com/issues/show_bug.cgi?id=960 (listed as fixed) doesn't seem to be updated either.

The website version of future.html looks fixed to me. That's why I marked it as "fixed". Is your browser using a cached version of that page?
 They're provided in the zip though (dmd/html/d/function.html and
 dmd/html/d/future.html).

Feb 16 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
jcc7 wrote:
 == Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 Reiner Pope wrote:
 Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding
 thread in digitalmars.D)

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

 http://ftp.digitalmars.com/dmd.1.006.zip


the URL referenced in http://d.puremagic.com/issues/show_bug.cgi?id=960 (listed as fixed) doesn't seem to be updated either.

The website version of future.html looks fixed to me. That's why I marked it as "fixed". Is your browser using a cached version of that page?

Judging by the post Walter made just before mine, it seems he fixed it between the time I checked and the time I I clicked 'send'...
Feb 16 2007
parent jcc7 <technocrat7 gmail.com> writes:
== Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 jcc7 wrote:
 == Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article
 Yes, it seems the site hasn't been updated yet. And not just that
 the URL referenced in http://d.puremagic.com/issues/show_bug.cgi?id=960
 (listed as fixed) doesn't seem to be updated either.

The website version of future.html looks fixed to me. That's why I > > marked


 that page?

it between the time I checked and the time I I clicked 'send'...

Oh. Sorry, I guess I was caught in a timewarp.
Feb 16 2007
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

SWEEET!!!! Um, Why? the following statement types are not allowed: * labelled break and continue statements
Feb 15 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:
 Um, Why?
 
 the following statement types are not allowed:
     * labelled break and continue statements

Because it's hard to do, and I'm lazy :-(
Feb 15 2007
parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 BCS wrote:
 
 Um, Why?

 the following statement types are not allowed:
     * labelled break and continue statements

Because it's hard to do, and I'm lazy :-(

Oh. Fine by me. Is that the same as: "later... maybe"?
Feb 15 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:
 Walter Bright wrote:
 BCS wrote:

 Um, Why?

 the following statement types are not allowed:
     * labelled break and continue statements

Because it's hard to do, and I'm lazy :-(

Oh. Fine by me. Is that the same as: "later... maybe"?

Yes <g> I did get goto's to work, though. Can't live without that!
Feb 15 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 BCS wrote:
 Walter Bright wrote:
 BCS wrote:

 Um, Why?

 the following statement types are not allowed:
     * labelled break and continue statements

Because it's hard to do, and I'm lazy :-(

Oh. Fine by me. Is that the same as: "later... maybe"?

Yes <g> I did get goto's to work, though. Can't live without that!

Aren't labeled breaks and continues basically glorified gotos? Or is the hard part figuring out which instruction to jump to? :)
Feb 15 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

This release increases the resultant executable size of a trivial HelloWorld program, by around 12KB. What happened? I thought there was some notion afoot to /reduce/ the size instead? - Kris
Feb 15 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
kris wrote:
 This release increases the resultant executable size of a trivial 
 HelloWorld program, by around 12KB. What happened?

I don't know. Which platform?
Feb 15 2007
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 kris wrote:
 This release increases the resultant executable size of a trivial 
 HelloWorld program, by around 12KB. What happened?

I don't know. Which platform?

Win32. We're still investigating, but building the same code with DMD 1.0 gives us a HelloWorld EXE of 90,652 bytes. With 1.005 the same code gives us a HelloWorld EXE of 113,180 bytes. I have yet to try 1.006 but reports indicate that the size is roughly the same as 1.005. I think no one simply noticed this until 1.006 experimentation began today. If I had to hazard a guess, I'd say most of the size change is probably a result of the TypeInfo changes post-1.0, but it will take a while to dig through object files to sort all this out. Sean
Feb 15 2007
parent reply kris <foo bar.com> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 
 kris wrote:

 This release increases the resultant executable size of a trivial 
 HelloWorld program, by around 12KB. What happened?

I don't know. Which platform?

Win32. We're still investigating, but building the same code with DMD 1.0 gives us a HelloWorld EXE of 90,652 bytes. With 1.005 the same code gives us a HelloWorld EXE of 113,180 bytes. I have yet to try 1.006 but reports indicate that the size is roughly the same as 1.005. I think no one simply noticed this until 1.006 experimentation began today. If I had to hazard a guess, I'd say most of the size change is probably a result of the TypeInfo changes post-1.0, but it will take a while to dig through object files to sort all this out. Sean

with 1006, the result is 114,716. That's 26% larger than 1.0 ?
Feb 15 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:
 Sean Kelly wrote:
 Walter Bright wrote:

 kris wrote:

 This release increases the resultant executable size of a trivial 
 HelloWorld program, by around 12KB. What happened?

I don't know. Which platform?

Win32. We're still investigating, but building the same code with DMD 1.0 gives us a HelloWorld EXE of 90,652 bytes. With 1.005 the same code gives us a HelloWorld EXE of 113,180 bytes. I have yet to try 1.006 but reports indicate that the size is roughly the same as 1.005. I think no one simply noticed this until 1.006 experimentation began today. If I had to hazard a guess, I'd say most of the size change is probably a result of the TypeInfo changes post-1.0, but it will take a while to dig through object files to sort all this out. Sean

with 1006, the result is 114,716. That's 26% larger than 1.0 ?

Turns out we have been using different flags. My numbers above are with "-release -O -inline" set. Without these flags the 1.0 EXE is 92,188 bytes. This will be a more useful comparison vs. Kris' number above. Sean
Feb 15 2007
prev sibling next sibling parent Walter Bright <newshound digitalmars.com> writes:
kris wrote:
 with 1006, the result is 114,716. That's 26% larger than 1.0 ?

That's likely due to the typeinfo's necessary to implement the type aware gc.
Feb 15 2007
prev sibling parent kris <foo bar.com> writes:
kris wrote:
 Sean Kelly wrote:
 
 Walter Bright wrote:

 kris wrote:

 This release increases the resultant executable size of a trivial 
 HelloWorld program, by around 12KB. What happened?

I don't know. Which platform?

Win32. We're still investigating, but building the same code with DMD 1.0 gives us a HelloWorld EXE of 90,652 bytes. With 1.005 the same code gives us a HelloWorld EXE of 113,180 bytes. I have yet to try 1.006 but reports indicate that the size is roughly the same as 1.005. I think no one simply noticed this until 1.006 experimentation began today. If I had to hazard a guess, I'd say most of the size change is probably a result of the TypeInfo changes post-1.0, but it will take a while to dig through object files to sort all this out. Sean

with 1006, the result is 114,716. That's 26% larger than 1.0 ?

With 1007, this dropped by a half-kb to 114,204. Possibly due to a little code motion. Now that typeinfo et al are isolated in separate segments, how do we get the linker to drop all the unused ones? I ask, since the example used for tracking down the lib issues has the following characteristics: code ~120kb data ~60kb Looking at what's represented by data, a rough guess is that an elimination of unused data would reduce it by perhaps as much as 75%
Feb 21 2007
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:er28ht$1cch$2 digitalmars.com...
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)

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

 http://ftp.digitalmars.com/dmd.1.006.zip

Great stuff, Walter! By the way, is it just a freaky coincidence that this made it in *exactly one year* after the first (afaik) discussion about it? http://www.digitalmars.com/d/archives/digitalmars/D/announce/2676.html L.
Feb 15 2007
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Small typo in function.html:

syncrhonized
Feb 16 2007
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Thanks
Feb 16 2007
prev sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Fri, 16 Feb 2007 04:04:37 -0500, Lionello Lunesu  
<lio lunesu.remove.com> wrote:

 Small typo in function.html:

 syncrhonized

ugh, I mess it up every time; I hate this word. lock() much nicer.
Feb 16 2007
prev sibling next sibling parent reply Miles <_______ _______.____> writes:
Walter Bright wrote:
 Compile time function execution!

Best D release ever! But the way you are numbering DMD versions is really annoying :-( "1.006" does not express how much changed. The last software I saw that used decimal versions was Netscape Navigator, and before that I can't even remember. Most software companies I know deprecated this scheme of version numbering for a good reason. 3 or 4-piece version numbers are largely used today, and they express a lot better the life history of a software. 1.000 should have been called 1.0.0; From 1.001 to 1.004, they should have been numbered 1.0.1 until 1.0.4; Now, 1.005 and 1.006, both introduced sensible changes to the language spec, so 1.1.0 and 1.2.0 for them. This also allows one to refer to things like "version 1.1 of D spec". Today, we have to say "the D spec as it was between 1.005 and 1.006"... Also, version numbers are not decimal numbers. 1.10 is greater than 1.9. No need for leading zeros.
Feb 15 2007
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Miles wrote:
 Walter Bright wrote:
 Compile time function execution!

Best D release ever! But the way you are numbering DMD versions is really annoying :-( "1.006" does not express how much changed. The last software I saw that used decimal versions was Netscape Navigator, and before that I can't even remember. Most software companies I know deprecated this scheme of version numbering for a good reason. 3 or 4-piece version numbers are largely used today, and they express a lot better the life history of a software. 1.000 should have been called 1.0.0; From 1.001 to 1.004, they should have been numbered 1.0.1 until 1.0.4; Now, 1.005 and 1.006, both introduced sensible changes to the language spec, so 1.1.0 and 1.2.0 for them. This also allows one to refer to things like "version 1.1 of D spec". Today, we have to say "the D spec as it was between 1.005 and 1.006"... Also, version numbers are not decimal numbers. 1.10 is greater than 1.9. No need for leading zeros.

This seems a sensible change. Version.Major.Minor is very common and very intuitive. Version for code incompatible changes, Major for new additions to the spec, minor for bug fixes. You can keep your current numbering scheme for minor ticks. Thus 1.0.001, 1.0.002, etc. As Miles suggests, you could even retroactively bump the new "major" version to reflect the new features (mixins and compile time functions).
Feb 15 2007
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Henning Hasemann wrote:
 This seems a sensible change. Version.Major.Minor is very common and 
 very intuitive. Version for code incompatible changes, Major for new 
 additions to the spec, minor for bug fixes. You can keep your current 
 numbering scheme for minor ticks. Thus 1.0.001, 1.0.002, etc. As Miles 
 suggests, you could even retroactively bump the new "major" version to 
 reflect the new features (mixins and compile time functions).

votes++

same here
Feb 17 2007
parent reply "Saaa" <empty needmail.com> writes:
 votes++

same here

bump
Feb 19 2007
parent just jeff <jeffrparsons optusnet.com.au> writes:
Saaa wrote:
 votes++


bump

Feb 20 2007
prev sibling next sibling parent kenny <funisher gmail.com> writes:
WALTER!!! YOU ROCK!!!

Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

Feb 15 2007
prev sibling next sibling parent Witold Baryluk <baryluk mpi.int.pl> writes:
On Thu, 15 Feb 2007 10:25:01 -0800
Walter Bright <newshound digitalmars.com> wrote:

 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

I'm impressed. Last releases are the best I've ever seen. As i understand function at compile time are interpreted (by some kind of VM)? Now, when i think about it, and about modular design of D (and compiler), I think it wasn't so hard to implement. Any way, great job! -- Witold Baryluk
Feb 16 2007
prev sibling next sibling parent Henning Hasemann <hhasemann web.de> writes:
 This seems a sensible change. Version.Major.Minor is very common and 
 very intuitive. Version for code incompatible changes, Major for new 
 additions to the spec, minor for bug fixes. You can keep your current 
 numbering scheme for minor ticks. Thus 1.0.001, 1.0.002, etc. As Miles 
 suggests, you could even retroactively bump the new "major" version to 
 reflect the new features (mixins and compile time functions).

votes++
Feb 16 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

Now that's truly spectacular. Metaprogramming is dead. Long live metaprogramming! How on Mars did you do it that fast?
Feb 16 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 Now that's truly spectacular.
 Metaprogramming is dead. Long live metaprogramming!
 How on Mars did you do it that fast?

I realized I could leverage the existing constant folding code. Sometimes the obvious isn't so obvious <g>. I predict that it won't be long before other compiled languages will seem antiquated if they don't have such capability.
Feb 16 2007
parent reply Brad Anderson <brad dsource.org> writes:
Walter Bright wrote:
 I predict that it won't be long before other compiled languages will
 seem antiquated if they don't have such capability.

Mmmm, the smell of world domination in the morning.
Feb 16 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Brad Anderson wrote:
 Walter Bright wrote:
 I predict that it won't be long before other compiled languages will
 seem antiquated if they don't have such capability.

Mmmm, the smell of world domination in the morning.

Good thing I brought my surfboard.
Feb 16 2007
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Brad Anderson wrote:
 Walter Bright wrote:
 I predict that it won't be long before other compiled languages will
 seem antiquated if they don't have such capability.

Mmmm, the smell of world domination in the morning.

How times have changed. When I started paying attention to D (Aug 2005), the website and spec had a defensive feel ("not as powerful as C++, but much simpler"). And there was a link to the very first D announcement, which had a list of "Features to drop from C++", which included "templates".
Feb 17 2007
parent Justin C Calvarese <technocrat7 gmail.com> writes:
Don Clugston wrote:
 Brad Anderson wrote:
 Walter Bright wrote:
 I predict that it won't be long before other compiled languages will
 seem antiquated if they don't have such capability.

Mmmm, the smell of world domination in the morning.

How times have changed. When I started paying attention to D (Aug 2005), the website and spec had a defensive feel ("not as powerful as C++, but much simpler"). And there was a link to the very first D announcement, which had a list of "Features to drop from C++", which included "templates".

Yes, it is pretty amazing how powerful D was at 1.0 compared to Walter's earlier ideas. From 2001/08/14: "I know that templates likely will be a big issue. I intend to address it in version 2 of the language. The way C++ does it is simply too complicated for me, I am trying to find a simpler way, so much more thought needs to be expended there." (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=15) -- jcc7
Feb 17 2007
prev sibling next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding 
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

Wow. This is strange territory to be traveling in. But the more I look at it, the more sense it makes. I've been tinkering around in template space a lot lately - this should help a bunch. Thanks Walter! -- - EricAnderton at yahoo
Feb 16 2007
parent Nicolai Waniek <no.spam thank.you> writes:
Pragma wrote:
 Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding
 thread in digitalmars.D)

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

 http://ftp.digitalmars.com/dmd.1.006.zip

Wow. This is strange territory to be traveling in. But the more I look at it, the more sense it makes. I've been tinkering around in template space a lot lately - this should help a bunch. Thanks Walter!

You know, one year on mars has 687 days, so one day on earth is two days on mars. Walter had twice the time ;)
Feb 16 2007
prev sibling parent Jascha Wetzel <"[firstname]" mainia.de> writes:
* Codeview for classes now gives correct LF_CLASS

i'd say that this issue is only partially solved in 1.006.
type strings for classes now get the correct LF_CLASS, but symbols of
those types are still marked as pointers to structs. hence they cannot
have the LF_CLASS leafs associated with them, but use the (obsolete?)
struct leafs (marked as forward refs) that exist for each class leaf.

example:

module mymodule;
class class1 { ... }
// ...
class1 myclass = new class1;
// ...

will generate two CV type strings:

class 0x1004 'mymodule.class1' field list: 0x1001 properties: 0x0
struct 0x100b 'class1' field list: 0x0 properties: 0x80

the symbol "myclass" will be marked as a pointer to struct 0x100b.
besides the (probably obsolete) indirection, i think there is no clean
way to tell that 0x100b and pointer-to-0x1004 describe the same type.

Walter Bright wrote:
 Compile time function execution! (Please discuss in the corresponding
 thread in digitalmars.D)
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.006.zip

Feb 18 2007