www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.153 release

reply Walter Bright <newshound digitalmars.com> writes:
Bug fixes.

http://www.digitalmars.com/d/changelog.html
Apr 10 2006
next sibling parent John Demme <me teqdruid.com> writes:
Walter, you're  machine!

Walter Bright wrote:

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

Apr 10 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:e1egd4$flk$1 digitaldaemon.com...
 Bug fixes.

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

And what's this _smart linking_ that's so important as to be required to be in italics? ;) Something big coming soon for D?
Apr 10 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e1egd4$flk$1 digitaldaemon.com...
 Bug fixes.

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

And what's this _smart linking_ that's so important as to be required to be in italics? ;) Something big coming soon for D?

Naw. "smart linking" is a marketing term that appeared in the 1980's that refers to the linker discarding unreferenced code sections. Since it's a bit of jargon, I italicized it. Optlink has been doing it for 15+ years, ld only recently.
Apr 10 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 10 Apr 2006 18:25:49 -0700, Walter Bright wrote:

 Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e1egd4$flk$1 digitaldaemon.com...
 Bug fixes.

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

And what's this _smart linking_ that's so important as to be required to be in italics? ;) Something big coming soon for D?

Naw. "smart linking" is a marketing term that appeared in the 1980's that refers to the linker discarding unreferenced code sections. Since it's a bit of jargon, I italicized it. Optlink has been doing it for 15+ years, ld only recently.

Is a 'code section' equivalent to a D module? In other words, if I have three D modules, each one is in its own unique code section. And thus if I'm not referencing anything in one of those modules and I include the module.obj in the command line, the linker will discard that module from the resulting executable file? Or is 'code section' more finely grained than that, say down to the function level? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 11/04/2006 11:40:18 AM
Apr 10 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 11 Apr 2006 11:43:28 +1000, Derek Parnell wrote:

 On Mon, 10 Apr 2006 18:25:49 -0700, Walter Bright wrote:
 
 Jarrett Billingsley wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:e1egd4$flk$1 digitaldaemon.com...
 Bug fixes.

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

And what's this _smart linking_ that's so important as to be required to be in italics? ;) Something big coming soon for D?

Naw. "smart linking" is a marketing term that appeared in the 1980's that refers to the linker discarding unreferenced code sections. Since it's a bit of jargon, I italicized it. Optlink has been doing it for 15+ years, ld only recently.

Is a 'code section' equivalent to a D module? In other words, if I have three D modules, each one is in its own unique code section. And thus if I'm not referencing anything in one of those modules and I include the module.obj in the command line, the linker will discard that module from the resulting executable file? Or is 'code section' more finely grained than that, say down to the function level?

Never mind, I just did a test and it seems to be at the function level. That is, optlink discards functions that are not referenced even if other functions in the same module are referenced. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 11/04/2006 11:48:48 AM
Apr 10 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 On Tue, 11 Apr 2006 11:43:28 +1000, Derek Parnell wrote:
 On Mon, 10 Apr 2006 18:25:49 -0700, Walter Bright wrote:
 Naw. "smart linking" is a marketing term that appeared in the 1980's 
 that refers to the linker discarding unreferenced code sections. Since 
 it's a bit of jargon, I italicized it. Optlink has been doing it for 15+ 
 years, ld only recently.

three D modules, each one is in its own unique code section. And thus if I'm not referencing anything in one of those modules and I include the module.obj in the command line, the linker will discard that module from the resulting executable file? Or is 'code section' more finely grained than that, say down to the function level?

Never mind, I just did a test and it seems to be at the function level. That is, optlink discards functions that are not referenced even if other functions in the same module are referenced.

Each module is made up of multiple sections. Smart linking relies on the compiler emitting a separate section for each function. You can see this by running obj2asm on it.
Apr 10 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 On Tue, 11 Apr 2006 11:43:28 +1000, Derek Parnell wrote:
 On Mon, 10 Apr 2006 18:25:49 -0700, Walter Bright wrote:
 Naw. "smart linking" is a marketing term that appeared in the 1980's
 that refers to the linker discarding unreferenced code sections.
 Since it's a bit of jargon, I italicized it. Optlink has been doing
 it for 15+ years, ld only recently.

three D modules, each one is in its own unique code section. And thus if I'm not referencing anything in one of those modules and I include the module.obj in the command line, the linker will discard that module from the resulting executable file? Or is 'code section' more finely grained than that, say down to the function level?

Never mind, I just did a test and it seems to be at the function level. That is, optlink discards functions that are not referenced even if other functions in the same module are referenced.

Each module is made up of multiple sections. Smart linking relies on the compiler emitting a separate section for each function. You can see this by running obj2asm on it.

This is really impressive - the resulting Linux binaries now seem to be several hundreds of kilobytes smaller! A big thanks. -- Jari-Matti
Apr 12 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 Bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

nice work : )
Apr 10 2006
prev sibling next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <e1egd4$flk$1 digitaldaemon.com>, Walter Bright says...
Bug fixes.

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

Walter, I just wanted to thank you for all you hard work you're been putting into the D! :) David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!" ------------------------------------------------------------------- MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Apr 10 2006
prev sibling next sibling parent akcom <CppCoder gmail.com> writes:
Walter Bright wrote:
 Bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

Superb as always :)
Apr 10 2006
prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 Bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

Steadily marching towards 1.0! Have you set criterion for when that will be Walter?
Apr 11 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Kyle Furlong wrote:
 Walter Bright wrote:
 Bug fixes.

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

Steadily marching towards 1.0! Have you set criterion for when that will be Walter?

Aside from bugs there's still some minor work to do with imports and interfaces - maybe dynamic libraries on linux too ;) Otherwise we're almost there :) -- Jari-Matti
Apr 11 2006
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <e1egd4$flk$1 digitaldaemon.com>, Walter Bright says...
Bug fixes.

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

Thank you Walter. :) #95 was really starting to cause some problems in my code. Thanks for taking the time to fix it so quickly. - EricAnderton at yahoo
Apr 11 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Thanks for removing the std.regexp dependency on std.outbuffer :-)


Sean
Apr 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 Thanks for removing the std.regexp dependency on std.outbuffer :-)

It still depends on it, I just removed a couple of the cases. The rest needs to go, too. The reason outbuffer is in there is because when I originally wrote regexp, the D arrays were not as powerful as they are now.
Apr 11 2006
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 Thanks for removing the std.regexp dependency on std.outbuffer :-)

It still depends on it, I just removed a couple of the cases. The rest needs to go, too. The reason outbuffer is in there is because when I originally wrote regexp, the D arrays were not as powerful as they are now.

Oops, you're right--I must have missed the build message after removing OutBuffer. No worries. I'll just keep OutBuffer around a bit longer then. It's still nice see all this getting sorted out. Sean
Apr 11 2006
prev sibling next sibling parent r <r_member pathlink.com> writes:
In article <e1egd4$flk$1 digitaldaemon.com>, Walter Bright says...
Bug fixes.

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

as learning lurker thanx for your super work! r
Apr 11 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Thanks to all who said 'thanks.' Your appreciation makes it all 
worthwhile for me.
Apr 11 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 Thanks to all who said 'thanks.' Your appreciation makes it all 
 worthwhile for me.

And not only us, but (as really I believe it,) Mankind! Honestly. georg
Apr 11 2006
prev sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Tue, 11 Apr 2006 17:10:45 -0400, Walter Bright  
<newshound digitalmars.com> wrote:

 Thanks to all who said 'thanks.' Your appreciation makes it all  
 worthwhile for me.

I don't say it enough (or at all), so thanks! Even if D does not become a success, a lot of us have learned a lot along the way, and that's all what really matters to me. - Chris
Apr 12 2006
parent reply John Reimer <terminal.node gmail.com> writes:
Chris Miller wrote:
 On Tue, 11 Apr 2006 17:10:45 -0400, Walter Bright 
 <newshound digitalmars.com> wrote:
 
 Thanks to all who said 'thanks.' Your appreciation makes it all 
 worthwhile for me.

I don't say it enough (or at all), so thanks! Even if D does not become a success, a lot of us have learned a lot along the way, and that's all what really matters to me. - Chris

Totally agree! -JJR
Apr 13 2006
parent Charles <noone nowhere.com> writes:
Yep, its been a fun ride :D.  Thanks from me too.

Charlie



John Reimer wrote:
 Chris Miller wrote:
 
 On Tue, 11 Apr 2006 17:10:45 -0400, Walter Bright 
 <newshound digitalmars.com> wrote:

 Thanks to all who said 'thanks.' Your appreciation makes it all 
 worthwhile for me.

I don't say it enough (or at all), so thanks! Even if D does not become a success, a lot of us have learned a lot along the way, and that's all what really matters to me. - Chris

Totally agree! -JJR

Apr 13 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Bug fixes.
 
 http://www.digitalmars.com/d/changelog.html

"Changed parameter types for std.date.MakeDate and std.date.MakeTime so they won't overflow." What you've done here makes no sense to me. Why is abusing the d_time type necessary to prevent an overflow? I.e. how does any of the following: - making the parameters long, considering that d_time is an alias of long anyway - casting the ints to longs within the function - making TicksPerHour et al long still lead to an overflow? I refer you back to digitalmars.D.bugs/2365 Also, why are none of the Make* and *FromTime functions documented? Stewart.
Apr 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Bug fixes.

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

"Changed parameter types for std.date.MakeDate and std.date.MakeTime so they won't overflow." What you've done here makes no sense to me. Why is abusing the d_time type necessary to prevent an overflow? I.e. how does any of the following: - making the parameters long, considering that d_time is an alias of long anyway - casting the ints to longs within the function - making TicksPerHour et al long still lead to an overflow?

Because sometimes very large values are passed to these functions. I have a test app that does that.
 Also, why are none of the Make* and *FromTime functions documented?

Sloth on my part.
Apr 14 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:

 What you've done here makes no sense to me.  Why is abusing the d_time 
 type necessary to prevent an overflow?  I.e. how does any of the 
 following:

 - making the parameters long, considering that d_time is an alias of 
 long anyway
 - casting the ints to longs within the function
 - making TicksPerHour et al long

 still lead to an overflow?

Because sometimes very large values are passed to these functions. I have a test app that does that.

But what is the practical use of being able to pass such huge arguments as the day or month? Still, people are no doubt already confused by the idea that you're supposed to pass a number of milliseconds since 1970 as the year, month, day, hour, minute, second or millisecond component when constructing a date/time. At least, these parameters should be long rather than d_time. Unless I'm missing something then there's nothing to lose, and some sanity in the code (and eventual documentation) to gain. Stewart.
Apr 16 2006
parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Because sometimes very large values are passed to these functions. I 
 have a test app that does that.

as the day or month?

Test programs often aren't practical; they test the limits. And the limits should work without silent overflow.
 Still, people are no doubt already confused by the idea that you're 
 supposed to pass a number of milliseconds since 1970 as the year, month, 
 day, hour, minute, second or millisecond component when constructing a 
 date/time.

The only thing confusing is it isn't documented.
 At least, these parameters should be long rather than 
 d_time.  Unless I'm missing something then there's nothing to lose, and 
 some sanity in the code (and eventual documentation) to gain.
 
 Stewart.

Apr 16 2006