www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.173 release

reply Walter Bright <newshound digitalmars.com> writes:
Major new stuff! But please, let's discuss that over in the 
digitalmars.D group.

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

http://ftp.digitalmars.com/dmd.173.zip
Nov 02 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Major new stuff! But please, let's discuss that over in the
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

The links in the changelog seems to be dead. (S&S, cpuid) -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Nov 02 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Lars Ivar Igesund wrote:
 Walter Bright wrote:
 
 Major new stuff! But please, let's discuss that over in the
 digitalmars.D group.

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

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

The links in the changelog seems to be dead. (S&S, cpuid)

download.
Nov 02 2006
parent Walter Bright <newshound digitalmars.com> writes:
Mike Parker wrote:
 Lars Ivar Igesund wrote:
 The links in the changelog seems to be dead. (S&S, cpuid)

download.

Fixed.
Nov 02 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

<stunned> Have I slipped through a wormhole? This appears to be an advanced beta of DMD 2.0. </stunned>
Nov 02 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Thu, 02 Nov 2006 01:52:42 -0800, Don Clugston <dac nospam.com.au> wrote:

 Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the  
 digitalmars.D group.
  http://www.digitalmars.com/d/changelog.html
  http://ftp.digitalmars.com/dmd.173.zip

<stunned> Have I slipped through a wormhole? This appears to be an advanced beta of DMD 2.0. </stunned>

Yes, it does seem that Walter is heading straight for 2.0. I guess there's no stopping the momentum now. I'm not sure whether this is a good idea or not... but whatever... it sure /looks/ impressive. -JJR
Nov 07 2006
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

OMG, template variadics! And standard signal-slots, I'm pretty excited.
Nov 02 2006
prev sibling next sibling parent Tom <tom nospam.com> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

You seem to be drinking too much caffeine, you're at full speed! :) Tom;
Nov 02 2006
prev sibling next sibling parent Serg Kovrov <kovrov no.spam> writes:
Hello Walter, you wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.

Yet gain, great work, Walter! I just want to express my profound respect for you. -- serg.
Nov 02 2006
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Thu, 02 Nov 2006 03:53:56 -0500, Walter Bright  
<newshound digitalmars.com> wrote:

 Major new stuff! But please, let's discuss that over in the  
 digitalmars.D group.

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

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

Some of my programs get random access violations with this version. Windbg says it's somewhere in std.utf's unittest. I rebuilt phobos.lib and the problem went away (make -f win32.mak).
Nov 02 2006
prev sibling next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

Holy crap. So many nice new features. So little time. Thank you Walter. -- - EricAnderton at yahoo
Nov 02 2006
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
Walter Bright wrote:

 Major new stuff! But please, let's discuss that over in the
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

The reference links to "A Deeper Look at Signals and Slots" and "Boost Signals" appear to be broken. -- ~John Demme me teqdruid.com http://www.teqdruid.com/
Nov 02 2006
parent Walter Bright <newshound digitalmars.com> writes:
John Demme wrote:
 The reference links to "A Deeper Look at Signals and Slots" and "Boost
 Signals" appear to be broken.

Fixed.
Nov 02 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:eicbn3$2qba$1 digitaldaemon.com...
 Major new stuff! But please, let's discuss that over in the digitalmars.D 
 group.

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

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

Un. Be. Liev. A. Ble. Not only are variadic templates _amazing_ things, they're also _exactly_ what I'll need to do the MiniD binding library (and Kirk is understandably happy as well!).
Nov 02 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:eidi8o$11o4$2 digitaldaemon.com...
 Un.  Be.  Liev.  A.  Ble.

 Not only are variadic templates _amazing_ things, they're also _exactly_ 
 what I'll need to do the MiniD binding library (and Kirk is understandably 
 happy as well!).

Waaahaha! This is so cool. A variadic "call" function for MiniD which used to look like: public void easyCall(MDClosure func, uint numReturns, ...) { uint funcReg = push(func); for(int i = 0; i < _arguments.length; i++) { TypeInfo ti = _arguments[i]; if(ti == typeid(bool)) push(cast(bool)va_arg!(bool)(_argptr)); else if(ti == typeid(byte)) push(cast(int)va_arg!(byte)(_argptr)); else if(ti == typeid(ubyte)) push(cast(int)va_arg!(ubyte)(_argptr)); else if(ti == typeid(short)) push(cast(int)va_arg!(ushort)(_argptr)); else if(ti == typeid(ushort)) push(cast(int)va_arg!(ushort)(_argptr)); else if(ti == typeid(int)) push(cast(int)va_arg!(int)(_argptr)); else if(ti == typeid(uint)) push(cast(int)va_arg!(uint)(_argptr)); else if(ti == typeid(long)) push(cast(int)va_arg!(long)(_argptr)); else if(ti == typeid(ulong)) push(cast(int)va_arg!(ulong)(_argptr)); else if(ti == typeid(float)) push(cast(float)va_arg!(float)(_argptr)); else if(ti == typeid(double)) push(cast(float)va_arg!(double)(_argptr)); else if(ti == typeid(real)) push(cast(float)va_arg!(real)(_argptr)); else if(ti == typeid(char[])) push(new MDString(va_arg!(char[])(_argptr))); else if(ti == typeid(wchar[])) push(new MDString(va_arg!(wchar[])(_argptr))); else if(ti == typeid(dchar[])) push(new MDString(va_arg!(dchar[])(_argptr))); else if(ti == typeid(MDObject)) push(cast(MDObject)va_arg!(MDObject)(_argptr)); else if(ti == typeid(MDUserdata)) push(cast(MDUserdata)va_arg!(MDUserdata)(_argptr)); else if(ti == typeid(MDClosure)) push(cast(MDClosure)va_arg!(MDClosure)(_argptr)); else if(ti == typeid(MDTable)) push(cast(MDTable)va_arg!(MDTable)(_argptr)); else if(ti == typeid(MDArray)) push(cast(MDArray)va_arg!(MDArray)(_argptr)); else throw new MDRuntimeException(this, "MDState.easyCall(): invalid parameter ", i); } call(funcReg, _arguments.length, numReturns); } Has now become: public void easyCall(T...)(MDClosure func, uint numReturns, T params) { uint funcReg = push(func); foreach(param; params) push(param); call(funcReg, params.length, numReturns); } Not only is it magnitudes easier to read, it's also far more efficient. Amazing, amazing, amazing. Thank you so much, again and again.
Nov 02 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:eidi8o$11o4$2 digitaldaemon.com...
 
Un.  Be.  Liev.  A.  Ble.

Not only are variadic templates _amazing_ things, they're also _exactly_ 
what I'll need to do the MiniD binding library (and Kirk is understandably 
happy as well!).

Waaahaha! This is so cool. A variadic "call" function for MiniD which used to look like: public void easyCall(MDClosure func, uint numReturns, ...) { uint funcReg = push(func); for(int i = 0; i < _arguments.length; i++) { TypeInfo ti = _arguments[i]; if(ti == typeid(bool)) push(cast(bool)va_arg!(bool)(_argptr)); else if(ti == typeid(byte)) push(cast(int)va_arg!(byte)(_argptr)); else if(ti == typeid(ubyte)) push(cast(int)va_arg!(ubyte)(_argptr)); else if(ti == typeid(short)) push(cast(int)va_arg!(ushort)(_argptr)); else if(ti == typeid(ushort)) push(cast(int)va_arg!(ushort)(_argptr)); else if(ti == typeid(int)) push(cast(int)va_arg!(int)(_argptr)); else if(ti == typeid(uint)) push(cast(int)va_arg!(uint)(_argptr)); else if(ti == typeid(long)) push(cast(int)va_arg!(long)(_argptr)); else if(ti == typeid(ulong)) push(cast(int)va_arg!(ulong)(_argptr)); else if(ti == typeid(float)) push(cast(float)va_arg!(float)(_argptr)); else if(ti == typeid(double)) push(cast(float)va_arg!(double)(_argptr)); else if(ti == typeid(real)) push(cast(float)va_arg!(real)(_argptr)); else if(ti == typeid(char[])) push(new MDString(va_arg!(char[])(_argptr))); else if(ti == typeid(wchar[])) push(new MDString(va_arg!(wchar[])(_argptr))); else if(ti == typeid(dchar[])) push(new MDString(va_arg!(dchar[])(_argptr))); else if(ti == typeid(MDObject)) push(cast(MDObject)va_arg!(MDObject)(_argptr)); else if(ti == typeid(MDUserdata)) push(cast(MDUserdata)va_arg!(MDUserdata)(_argptr)); else if(ti == typeid(MDClosure)) push(cast(MDClosure)va_arg!(MDClosure)(_argptr)); else if(ti == typeid(MDTable)) push(cast(MDTable)va_arg!(MDTable)(_argptr)); else if(ti == typeid(MDArray)) push(cast(MDArray)va_arg!(MDArray)(_argptr)); else throw new MDRuntimeException(this, "MDState.easyCall(): invalid parameter ", i); } call(funcReg, _arguments.length, numReturns); } Has now become: public void easyCall(T...)(MDClosure func, uint numReturns, T params) { uint funcReg = push(func); foreach(param; params) push(param); call(funcReg, params.length, numReturns); } Not only is it magnitudes easier to read, it's also far more efficient. Amazing, amazing, amazing. Thank you so much, again and again.

That has to be about as significant an example as one could ask for. Also, the new code makes it much more future-compatable, as it can be made ready for new datatypes without ever editing easyCall itself! (So long as push() supports the type, you're good to go.) -- Chris Nicholson-Sauls
Nov 02 2006
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

Excellent! I would love to check out the Signal and Slot implementation. Too bad I am tied up in other projects using other languages. Bastiaan.
Nov 02 2006
parent Brad Anderson <brad dsource.org> writes:
Bastiaan Veelo wrote:
 Too bad I am tied up in other projects using other languages.

Resistance is futile.
Nov 02 2006
prev sibling next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

Variadic templates, and tuples... badass.
Nov 02 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html

One of the 'minor things' is also "Template instantiations can now accept alias parameters for local variables and nested functions." which is of great interest to me, since now meta.prettynameof!() can work with local variables; this will be significant for DDL and probably things like PyD as well. But, the name mangling is really weird. It's totally different to the name mangling for static variables, for example. Maybe this is intentional, and needs to be that way; but it's a bit tricky to parse, so I'd like confirmation that it's not a mistake. Below is an example, taken from my meta.nameof file. ----------- template inner(alias F) { class inner { } } template outer(alias B) { void function( inner!(B) ) outer; } template rawmanglednameof(alias A) { const char [] rawmanglednameof = typeof(&outer!(A)).mangleof; } void wolf() { static int proto; int quark; static assert(rawmanglednameof!(proto)== "PPFC" ~ "4meta6nameof42__T5inner" ~ "S29_D4meta6nameof4wolfFZv" ~ "5protoi" ~ "Z5innerZv"); static assert(rawmanglednameof!(quark)== "PPFC" ~ "_D4meta6nameof4wolfFZv54__T16rawmanglednameof" ~ "S29_D4meta6nameof4wolfFZv5quarkiZ42__T5outer" ~ "S29_D4meta6nameof4wolfFZv5quarkiZ42__T5inner" ~ "S29_D4meta6nameof4wolfFZv" ~ "5quarki" ~ "Z5innerZv"); /* Why isn't it just: "PPFC" ~ "4meta6nameof42__T5inner" ~ "S29_D4meta6nameof4wolfFZv" ~ "5quarki" ~ "Z5innerZv" ? */ }
Nov 03 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 "Template instantiations can now accept alias parameters for local 
 variables and nested functions."
 
 which is of great interest to me, since now meta.prettynameof!() can 
 work with local variables; this will be significant for DDL and probably 
 things like PyD as well.
 But, the name mangling is really weird. It's totally different to the 
 name mangling for static variables, for example.

What happens is when one of the parameters is an alias to a local, the template becomes a *nested* class/function, and is mangled like one.
Nov 03 2006
next sibling parent Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Don Clugston wrote:
 "Template instantiations can now accept alias parameters for local 
 variables and nested functions."

 which is of great interest to me, since now meta.prettynameof!() can 
 work with local variables; this will be significant for DDL and 
 probably things like PyD as well.
 But, the name mangling is really weird. It's totally different to the 
 name mangling for static variables, for example.

What happens is when one of the parameters is an alias to a local, the template becomes a *nested* class/function, and is mangled like one.

OK, that makes sense -- that should prevent the alias from 'leaking out' from the function. Might take me a while to get my head around all the consequences, though <g>. Opens up lots of possibilities.
Nov 03 2006
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Don Clugston wrote:
 "Template instantiations can now accept alias parameters for local 
 variables and nested functions."

 which is of great interest to me, since now meta.prettynameof!() can 
 work with local variables; this will be significant for DDL and 
 probably things like PyD as well.
 But, the name mangling is really weird. It's totally different to the 
 name mangling for static variables, for example.

What happens is when one of the parameters is an alias to a local, the template becomes a *nested* class/function, and is mangled like one.

I think I've found a bug in a corner case: template t (alias A) {...} void g() { void f() { // t!(f); // CASE 1 ---> template t is nested in both g and f. } t!(f); // CASE 2 ---> template t is nested in g but not f. } If case 1 appears anywhere (even in a pragma(msg)), it changes the name mangling of case 2. I think case 1 is wrong: an inner function is not inside itself.
Nov 04 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

The file phobos/std_outofmemory.html is still missing from the dmd package. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 05 2006
parent Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:
 The file phobos/std_outofmemory.html is still missing from the dmd package.

I'll fix.
Nov 06 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 Major new stuff!

Belated congrats!! At this rate we're well past 2.0 at end of year! :-) And for anybody contemplating a book on D, don't include the last chapter! Reason is, the back cover of the book runs away from you at precisely the speed you're writing the next-to-last chapter! :-)
Nov 05 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Ok, so this one is about a feature of some releases ago, but you're 
releasing new features faster than what we can keep up and look at :P

Regarding array literals, it concerns me that each new literal 
"evaluation" will create a new instance. For example a literal inside a 
function will allocate a new instance every time the function is called. 
Likewise a literal inside a loop will allocate a new instance for every 
cycle of the loop!
This strikes me as both inefficient (as there is no simple way to use 
the opposite behavior: static/global instances) and inconsistent: other 
kinds of literals, like string literals, are not instanced per 
"evaluation" but instead are single/global/static instances.
Is there any particular reason for this behavior? Because if not I'm 
inclined to think it would be better that array literals work as string 
literals (global/static instances). If the new'ed-instance behavior is 
needed it could be easily emulated with dup'ing:
   ar = [1, 4, 9].dup;

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 05 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Bruno Medeiros wrote:
 Ok, so this one is about a feature of some releases ago, but you're 
 releasing new features faster than what we can keep up and look at :P

Aint that the truth. :)
 
 Regarding array literals, it concerns me that each new literal 
 "evaluation" will create a new instance. For example a literal inside a 
 function will allocate a new instance every time the function is called. 
 Likewise a literal inside a loop will allocate a new instance for every 
 cycle of the loop!
 This strikes me as both inefficient (as there is no simple way to use 
 the opposite behavior: static/global instances) and inconsistent: other 
 kinds of literals, like string literals, are not instanced per 
 "evaluation" but instead are single/global/static instances.
 Is there any particular reason for this behavior? Because if not I'm 
 inclined to think it would be better that array literals work as string 
 literals (global/static instances). If the new'ed-instance behavior is 
 needed it could be easily emulated with dup'ing:
   ar = [1, 4, 9].dup;
 

I'm afraid that things have to be that way. It would make sense for array literals to be allocated only once if they were made of only constant values, but in cases like: for(int i=0; i<100; i++) { f( [i, i*i] ); } I would expect a new instance to be created at each step in the loop.
Nov 05 2006
parent Bill Baxter <wbaxter gmail.com> writes:
Ivan Senji wrote:
 Bruno Medeiros wrote:
 
 Ok, so this one is about a feature of some releases ago, but you're 
 releasing new features faster than what we can keep up and look at :P

Aint that the truth. :)
 Regarding array literals, it concerns me that each new literal 
 "evaluation" will create a new instance. For example a literal inside 
 a function will allocate a new instance every time the function is 
 called. Likewise a literal inside a loop will allocate a new instance 
 for every cycle of the loop!
 This strikes me as both inefficient (as there is no simple way to use 
 the opposite behavior: static/global instances) and inconsistent: 
 other kinds of literals, like string literals, are not instanced per 
 "evaluation" but instead are single/global/static instances.
 Is there any particular reason for this behavior? Because if not I'm 
 inclined to think it would be better that array literals work as 
 string literals (global/static instances). If the new'ed-instance 
 behavior is needed it could be easily emulated with dup'ing:
   ar = [1, 4, 9].dup;

I'm afraid that things have to be that way. It would make sense for array literals to be allocated only once if they were made of only constant values, but in cases like: for(int i=0; i<100; i++) { f( [i, i*i] ); } I would expect a new instance to be created at each step in the loop.

It doesn't even need to be dynamic values. Given for(int i=0; i<100; i++) { f( [1, 42] ); } You might have f modifying the array since D doesn't have good support for const: void f(int[2] v) { v[0]++; } And then f([1,42]) after the first call becomes equivalent to f([2,42]) which would be bad. --bb
Nov 05 2006
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
Bruno Medeiros wrote:
 Ok, so this one is about a feature of some releases ago, but you're 
 releasing new features faster than what we can keep up and look at :P
 
 Regarding array literals, it concerns me that each new literal 
 "evaluation" will create a new instance. For example a literal inside a 
 function will allocate a new instance every time the function is called. 
 Likewise a literal inside a loop will allocate a new instance for every 
 cycle of the loop!
 This strikes me as both inefficient (as there is no simple way to use 
 the opposite behavior: static/global instances) and inconsistent: other 
 kinds of literals, like string literals, are not instanced per 
 "evaluation" but instead are single/global/static instances.
 Is there any particular reason for this behavior? Because if not I'm 
 inclined to think it would be better that array literals work as string 
 literals (global/static instances). If the new'ed-instance behavior is 
 needed it could be easily emulated with dup'ing:
   ar = [1, 4, 9].dup;
 

Agreed. It also makes life interesting in that things that depend of an array having compile-time constant value fail: const bool[3] a = [true,false,true]; static if(a[0]) {} (and fail with the misleading error message "expression (a)[0] does not evaluate to a boolean"). This is ok though: static if([true,false,true][0]) {} Another thing that should work is: static const int[3] a = [4,5,6]; static const int[a[0]] b = [1,2,3,4]; test.d(17): a is used as a type test.d(17): can't have associative array key of void[0] Ok, that's maybe a different issue... but I bet if it weren't trying to interpret the above as an associative array it would be complaining that the value a[0] isn't constant. :-) Ah, here's a better example: static const int[2] sizes = [2,4]; static const int[2] use_sizes = [sizes[0], sizes[1]];
 staticdata.d(19): non-constant expression (sizes)[0]
 staticdata.d(19): non-constant expression (sizes)[1]


--bb
Nov 05 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Major new stuff! But please, let's discuss that over in the 
 digitalmars.D group.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.173.zip

The relaxed rules for template alias parameters aren't documented in the spec. The example under 'global names' compiles now <g>.
Nov 06 2006
parent Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 The relaxed rules for template alias parameters aren't documented in the 
 spec. The example under 'global names' compiles now <g>.

I'll fix.
Nov 06 2006