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