www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
electronics

digitalmars.D.announce - DMD 1.007 release

↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
Cleanup of compile time function execution issues.

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

http://ftp.digitalmars.com/dmd.1.007.zip
Feb 20 2007
↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip



Is that change to COMDAT there to fix the linking issues?

--bb
Feb 20 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Is that change to COMDAT there to fix the linking issues?



Yes. We'll see if it works, or creates just other problems.
Feb 20 2007
↑ ↓ ← → kris <foo bar.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:
 

 Is that change to COMDAT there to fix the linking issues?



 
 Yes. We'll see if it works, or creates just other problems.



It does, but increases the exe size of the first example from 180kb to 
617kb! 180kb is when compiled using build/rebuild/jake etc (no library) 
and the 617kb is when using dmd+lib only. Same flags in both cases: none 
at all

- Kris
Feb 20 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 It does, but increases the exe size of the first example from 180kb to 
 617kb! 180kb is when compiled using build/rebuild/jake etc (no library) 
 and the 617kb is when using dmd+lib only. Same flags in both cases: none 
 at all



That makes no sense! There is 0 difference in size on the test program 
(your example).
Feb 21 2007
↑ ↓ ← → kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 It does, but increases the exe size of the first example from 180kb to 
 617kb! 180kb is when compiled using build/rebuild/jake etc (no 
 library) and the 617kb is when using dmd+lib only. Same flags in both 
 cases: none at all



 
 That makes no sense! There is 0 difference in size on the test program 
 (your example).



Oh, I'm not using the little test snippet ... I'm using real examples 
that link to Tango.lib instead. This particular one connects to the DM 
site and downloads the home page. The obj size was 1670 bytes, and the 
rest came from the lib :)

If you prefer, we could switch to the #D thread so as not to pollute 
this one?

As an aside: I also tried the open-watcom linker, but that finds errors 
in snn.lib (multiple symbols marked as entry points for console and dll 
startup code)

- Kris
Feb 21 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 If you prefer, we could switch to the #D thread so as not to pollute 
 this one?



Ok, but I'll need an example. I'd start by comparing .map files.


 As an aside: I also tried the open-watcom linker, but that finds errors 
 in snn.lib (multiple symbols marked as entry points for console and dll 
 startup code)



Either that, or the o.w. linker has bugs in it. snn.lib works fine.
Feb 21 2007
↑ ↓ ← → kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 If you prefer, we could switch to the #D thread so as not to pollute 
 this one?



 
 Ok, but I'll need an example. I'd start by comparing .map files.
 

 As an aside: I also tried the open-watcom linker, but that finds 
 errors in snn.lib (multiple symbols marked as entry points for console 
 and dll startup code)



 
 Either that, or the o.w. linker has bugs in it. snn.lib works fine.



Anything is possible :)

Just for posterity, here's the OW linker output; almost all warnings:

Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
_D11TypeInfo_AC6__initZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
_D11TypeInfo_AC7__ClassZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
_D11TypeInfo_AC6__vtblZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_creal.d): redefinition of 
_D10TypeInfo_C6__initZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_creal.d): redefinition of 
_D10TypeInfo_C7__ClassZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_creal.d): redefinition of 
_D10TypeInfo_C6__vtblZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_double.d): redefinition of 
_D10TypeInfo_d6__initZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_double.d): redefinition of 
_D10TypeInfo_D7__ClassZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_double.d): redefinition of 
_D10TypeInfo_D6__vtblZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_ptr.d): redefinition of 
_D10TypeInfo_p6__initZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_ptr.d): redefinition of 
_D10TypeInfo_p7__ClassZ ignored
Warning! W1027: file phobos.lib(typeinfo\ti_ptr.d): redefinition of 
_D10TypeInfo_p6__vtblZ ignored
Warning! W1027: file snn.lib(..\core32\_exit2.c): redefinition of __Exit 
ignored
Warning! W1027: file snn.lib(..\ios\stream.cpp): redefinition of istream 
&cdecl ws(istream &) ignored
Error! E2166: file snn.lib(..\win32\constart.c): both 
__DllMainCRTStartup 12 and _mainCRTStartup marked as starting symbols
Error! E2166: file snn.lib(..\win32\winstart.c): both 
__DllMainCRTStartup 12 and _WinMainCRTStartup marked as starting symbols
Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
_trace_setlogfilename ignored
Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
_trace_setdeffilename ignored
Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
_trace_term ignored
Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
__trace_pro_n ignored
Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
__trace_epi_n ignored
Error! E2166: file snn.lib(..\win32\wconstar.c): both 
__DllMainCRTStartup 12 and _wmainCRTStartup marked as starting symbols
Error! E2166: file snn.lib(..\win32\wwinstar.c): both 
__DllMainCRTStartup 12 and _wWinMainCRTStartup marked as starting symbols
Warning! W1027: file snn.lib(..\core\_wfopen.c): redefinition of 
__wfopen ignored
Feb 21 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
kris wrote:

 Either that, or the o.w. linker has bugs in it. snn.lib works fine.



 Anything is possible :)
 
 Just for posterity, here's the OW linker output; almost all warnings:
 
 Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
 _D11TypeInfo_AC6__initZ ignored



That's a bug in the OW linker. COMDATs can be multiply defined.


 Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
 _D11TypeInfo_AC7__ClassZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
 _D11TypeInfo_AC6__vtblZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_creal.d): redefinition of 
 _D10TypeInfo_C6__initZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_creal.d): redefinition of 
 _D10TypeInfo_C7__ClassZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_creal.d): redefinition of 
 _D10TypeInfo_C6__vtblZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_double.d): redefinition of 
 _D10TypeInfo_d6__initZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_double.d): redefinition of 
 _D10TypeInfo_D7__ClassZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_double.d): redefinition of 
 _D10TypeInfo_D6__vtblZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_ptr.d): redefinition of 
 _D10TypeInfo_p6__initZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_ptr.d): redefinition of 
 _D10TypeInfo_p7__ClassZ ignored
 Warning! W1027: file phobos.lib(typeinfo\ti_ptr.d): redefinition of 
 _D10TypeInfo_p6__vtblZ ignored
 Warning! W1027: file snn.lib(..\core32\_exit2.c): redefinition of __Exit 
 ignored
 Warning! W1027: file snn.lib(..\ios\stream.cpp): redefinition of istream 
 &cdecl ws(istream &) ignored
 Error! E2166: file snn.lib(..\win32\constart.c): both 
 __DllMainCRTStartup 12 and _mainCRTStartup marked as starting symbols
 Error! E2166: file snn.lib(..\win32\winstart.c): both 
 __DllMainCRTStartup 12 and _WinMainCRTStartup marked as starting symbols



Those aren't errors. Multiple start addresses can be in the library, you 
just can't link both of them into the same exe.


 Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
 _trace_setlogfilename ignored
 Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
 _trace_setdeffilename ignored
 Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
 _trace_term ignored
 Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
 __trace_pro_n ignored
 Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 
 __trace_epi_n ignored
 Error! E2166: file snn.lib(..\win32\wconstar.c): both 
 __DllMainCRTStartup 12 and _wmainCRTStartup marked as starting symbols
 Error! E2166: file snn.lib(..\win32\wwinstar.c): both 
 __DllMainCRTStartup 12 and _wWinMainCRTStartup marked as starting symbols
 Warning! W1027: file snn.lib(..\core\_wfopen.c): redefinition of 
 __wfopen ignored
Feb 21 2007
↑ ↓ ← → kris <foo bar.com> writes:
Walter Bright wrote:

 kris wrote:
 

 Either that, or the o.w. linker has bugs in it. snn.lib works fine.




 Anything is possible :)

 Just for posterity, here's the OW linker output; almost all warnings:

 Warning! W1027: file phobos.lib(typeinfo\ti_Acreal.d): redefinition of 
 _D11TypeInfo_AC6__initZ ignored



 
 That's a bug in the OW linker. COMDATs can be multiply defined.
 

 Error! E2166: file snn.lib(..\win32\constart.c): both 
 __DllMainCRTStartup 12 and _mainCRTStartup marked as starting symbols
 Error! E2166: file snn.lib(..\win32\winstart.c): both 
 __DllMainCRTStartup 12 and _WinMainCRTStartup marked as starting symbols



 
 Those aren't errors. Multiple start addresses can be in the library, you 
 just can't link both of them into the same exe.
 

 Warning! W1027: file snn.lib(..\WIN32\TRACE\TRACE.C): redefinition of 







Thanks; that's useful to know
Feb 21 2007
↑ ↓ ← → nazo <lovesyao gmail.com> writes:
Great. but I found two bugs. I can't split string on compile time :-(

import std.stdio;
template eval(T...){
   const eval=T[0];
}

char[][] bug1(){
   char[][] rv;
   rv~="test";
   return rv;
}

bool bug2(char[] a, char[] b){
   return (a==b);
}

void main(){
//  writefln(eval!(bug1()));
//  writefln(eval!(bug2("test","test")));
}
Feb 20 2007
↑ ↓ ← → Max Samukha <samukha voliacable.com> writes:
On Tue, 20 Feb 2007 20:50:31 -0800, Walter Bright
<newshound digitalmars.com> wrote:


Cleanup of compile time function execution issues.

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

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



Mixins are working with compile-time functions! Thanks!
Feb 21 2007
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip



Is there a reason why this shouldn't work?! It seems to me this is the 
most basic usage for mixin & compile time functions.
--------------------
import std.stdio;

void main()
{
	writefln( getstruct( "test_struct", "int x; int y;" ) );	
}

mixin( getstruct( "test_struct", "int x; int y;" ) );


char[] getstruct( char[] name, char[] sbody )
{
     return "struct " ~ name ~ " { " ~ sbody ~ " }";
}
----------------

Compiling this, I get:
meta.d(8): Error: cannot evaluate getstruct("test_struct","int x; int 
y;") at compile time
attribute argument to mixin must be a string, not 
(getstruct("test_struct","int x; int y;"))

when I comment out the mixin() line, it compiles, and when I run the 
program it outputs:
struct test_struct { int x; int y; }
Feb 21 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
Hasan Aljudy wrote:

 Is there a reason why this shouldn't work?! It seems to me this is the 
 most basic usage for mixin & compile time functions.



Try putting the definition of getstruct() before the mixin.
Feb 21 2007
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:

 Hasan Aljudy wrote:

 Is there a reason why this shouldn't work?! It seems to me this is the 
 most basic usage for mixin & compile time functions.



 Try putting the definition of getstruct() before the mixin.



Ah!! Thanks :D

It's considered a bug though, isn't it? this dependency on the order of 
declaration ...
Feb 21 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
Hasan Aljudy wrote:

 It's considered a bug though, isn't it? this dependency on the order of 
 declaration ...



It'll be a while before that all gets sorted out.
Feb 21 2007
↑ ↓ ← → "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:erh7kb$1i0s$2 digitalmars.com...

 Hasan Aljudy wrote:

 It's considered a bug though, isn't it? this dependency on the order of 
 declaration ...



 It'll be a while before that all gets sorted out.



And therefore a while before 102/282/912 gets sorted out as well?  Sigh.. I 
hate forward declarations.
Feb 21 2007
↑ ↓ ← → BCS <BCS pathlink.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:erh7kb$1i0s$2 digitalmars.com...
 

Hasan Aljudy wrote:


It's considered a bug though, isn't it? this dependency on the order of 
declaration ...



It'll be a while before that all gets sorted out.



 
 And therefore a while before 102/282/912 gets sorted out as well?  Sigh.. I 
 hate forward declarations. 
 
 




void foo(){}
void foo(int i){}

auto fnp = &foo;

//swap foo's and the type of fnp changes
Feb 21 2007
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:

 Hasan Aljudy wrote:

 Is there a reason why this shouldn't work?! It seems to me this is the 
 most basic usage for mixin & compile time functions.



 Try putting the definition of getstruct() before the mixin.



What about this one?

---------------
dchar[] testd( dchar[] input )
{
	if( input[3..5] != "rt" )
	{
		return input[1..3];
	}
	return "my";
}

void main()
{
	static x = testd( "hello" );
}
----------------

it says:
  Error: cannot evaluate testd("hello") at compile time
Feb 22 2007
↑ ↓ ← → Max Samukha <samukha voliacable.com> writes:
On Thu, 22 Feb 2007 14:20:30 -0700, Hasan Aljudy
<hasan.aljudy gmail.com> wrote:


Walter Bright wrote:

 Hasan Aljudy wrote:

 Is there a reason why this shouldn't work?! It seems to me this is the 
 most basic usage for mixin & compile time functions.



 Try putting the definition of getstruct() before the mixin.



What about this one?

---------------
dchar[] testd( dchar[] input )
{
	if( input[3..5] != "rt" )
	{
		return input[1..3];
	}
	return "my";
}

void main()
{
	static x = testd( "hello" );
}
----------------

it says:
  Error: cannot evaluate testd("hello") at compile time



I've been racking my brain over the problem too. It seems like string
comparison expressions are not evaluable at compile time. 

input[3] != 'r' || input[4] != ''t" should work

you can also make your own compare function
Feb 23 2007
↑ ↓ ← → Hasan Aljudy <hasan.aljudy gmail.com> writes:
Max Samukha wrote:

 On Thu, 22 Feb 2007 14:20:30 -0700, Hasan Aljudy
 <hasan.aljudy gmail.com> wrote:
 

 Walter Bright wrote:

 Hasan Aljudy wrote:

 Is there a reason why this shouldn't work?! It seems to me this is the 
 most basic usage for mixin & compile time functions.







 ---------------
 dchar[] testd( dchar[] input )
 {
 	if( input[3..5] != "rt" )
 	{
 		return input[1..3];
 	}
 	return "my";
 }

 void main()
 {
 	static x = testd( "hello" );
 }
 ----------------

 it says:
  Error: cannot evaluate testd("hello") at compile time



 I've been racking my brain over the problem too. It seems like string
 comparison expressions are not evaluable at compile time. 
 
 input[3] != 'r' || input[4] != ''t" should work
 
 you can also make your own compare function
 



What I was pointing out was that slicing doesn't seem to work.
Feb 23 2007
↑ ↓ ← → Max Samukha <samukha voliacable.com> writes:
On Fri, 23 Feb 2007 17:00:55 -0700, Hasan Aljudy
<hasan.aljudy gmail.com> wrote:


Max Samukha wrote:

 On Thu, 22 Feb 2007 14:20:30 -0700, Hasan Aljudy
 <hasan.aljudy gmail.com> wrote:
 

 Walter Bright wrote:

 Hasan Aljudy wrote:

 Is there a reason why this shouldn't work?! It seems to me this is the 
 most basic usage for mixin & compile time functions.







 ---------------
 dchar[] testd( dchar[] input )
 {
 	if( input[3..5] != "rt" )
 	{
 		return input[1..3];
 	}
 	return "my";
 }

 void main()
 {
 	static x = testd( "hello" );
 }
 ----------------

 it says:
  Error: cannot evaluate testd("hello") at compile time



 I've been racking my brain over the problem too. It seems like string
 comparison expressions are not evaluable at compile time. 
 
 input[3] != 'r' || input[4] != ''t" should work
 
 you can also make your own compare function
 



What I was pointing out was that slicing doesn't seem to work.



Slicing works. Comparisons is what makes your function unevaluable at
compiletime. Try to use a function to compare slices. Something like
this:

bool isEqual(dchar[] str1, dchar[] str2)
{
	if (str1.length != str2.length)
		return false;

	for (int i = 0; i < str1.length; i++)
		if (str1[i] != str2[i])
			return false;
	
	return true;
}

dchar[] testd( dchar[] input )
{
	if( !isEqual(input[3..5], "rt"))
 	{
 		return input[1..3];
 	}
 	return "my";
 }

void main()
{
	static x = testd( "hello" );
}

Trickier workarounds might exist
Feb 23 2007
↑ ↓ ← → Jascha Wetzel <"[firstname]" mainia.de> writes:
i award you an oscar for productivity :)
evaluation of classes works properly now - new Ddbg release coming up...

Walter Bright wrote:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip
Feb 21 2007
↑ ↓ ← → kris <foo bar.com> writes:
Jascha Wetzel wrote:

 i award you an oscar for productivity :)
 evaluation of classes works properly now - new Ddbg release coming up...



Sweet! that will be a first :)
Feb 21 2007
↑ ↓ ← → torhu <fake address.dude> writes:
I get errors like this with DWT.  They go away when I add -v1 to the 
command line.  I didn't see this in the changelog, but I guess it's the 
disallowing implicit conversion from objects to void* that was discussed.

dwt\accessibility\accessible.d(507): Error: cannot implicitly convert 
expression (cast(IUnknown)(this.objIAccessible)) of type 
std.c.windows.com.IUnknown to void*

C:\prog\dmd\import\dwt\ole\win32\oleclientsite.d(544): Error: cannot 
implicitly convert expression (cast(IAdviseSink)(this.iAdviseSink)) of 
type dwt.internal.oe.win32.OBJIDL.IAdviseSink to void*
Feb 21 2007
↑ ↓ ← → Walter Bright <newshound digitalmars.com> writes:
torhu wrote:

 I get errors like this with DWT.  They go away when I add -v1 to the 
 command line.  I didn't see this in the changelog, but I guess it's the 
 disallowing implicit conversion from objects to void* that was discussed.
 
 dwt\accessibility\accessible.d(507): Error: cannot implicitly convert 
 expression (cast(IUnknown)(this.objIAccessible)) of type 
 std.c.windows.com.IUnknown to void*
 
 C:\prog\dmd\import\dwt\ole\win32\oleclientsite.d(544): Error: cannot 
 implicitly convert expression (cast(IAdviseSink)(this.iAdviseSink)) of 
 type dwt.internal.oe.win32.OBJIDL.IAdviseSink to void*



Compiling with -v1 or putting in a cast(void*) should resolve the problem.
Feb 21 2007
↑ ↓ ← → =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Walter Bright kirjoitti:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip



Great. It also seems the downloads got a bit faster! :) On average 55
kB/s vs old 7 kB/s.
Feb 21 2007
↑ ↓ ← → Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jari-Matti Mäkelä wrote:

 It also seems the downloads got a bit faster! :) On average 55
 kB/s vs old 7 kB/s.



I noticed the faster downloads too. It was about 160+ kB/s for me, which 
is about 10 times faster than it was previously :).
Feb 21 2007
↑ ↓ ← → Carlos Santander <csantander619 gmail.com> writes:
Walter Bright escribió:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip



The zip file is gone. What happened?

-- 
Carlos Santander Bernal
Feb 21 2007
↑ ↓ ← → jcc7 <technocrat7 gmail.com> writes:
== Quote from Carlos Santander (csantander619 gmail.com)'s article

 Walter Bright escribió:

 Cleanup of compile time function execution issues.

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

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






I've noticed the same problem.

And "http://ftp.digitalmars.com/dmd.zip" seems to contain DMD 1.006.
Feb 21 2007
↑ ↓ ← → Russell Lewis <webmaster villagersonline.com> writes:
Touch.  It's still missing.

jcc7 wrote:

 == Quote from Carlos Santander (csantander619 gmail.com)'s article

 Walter Bright escribió:

 Cleanup of compile time function execution issues.

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

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






 I've noticed the same problem.
 
 And "http://ftp.digitalmars.com/dmd.zip" seems to contain DMD 1.006.
Feb 21 2007
↑ ↓ ← → Tyler Knott <tywebmail mailcity.com> writes:
Bump.  Please fix this, it's still down.

Russell Lewis wrote:

 Touch.  It's still missing.
 
 jcc7 wrote:

 == Quote from Carlos Santander (csantander619 gmail.com)'s article

 Walter Bright escribió:

 Cleanup of compile time function execution issues.

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

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






 I've noticed the same problem.

 And "http://ftp.digitalmars.com/dmd.zip" seems to contain DMD 1.006.
Feb 21 2007
↑ ↓ ← → Paul Findlay <r.lph50+d gmail.com> writes:
 http://ftp.digitalmars.com/dmd.1.007.zip















ftp://ftp.digitalmars.com/dmd.1.007.zip

works

- Paul
Feb 21 2007
↑ ↓ ← → Justin C Calvarese <technocrat7 gmail.com> writes:
Paul Findlay wrote:

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















 ftp://ftp.digitalmars.com/dmd.1.007.zip
 
 works
 
 - Paul



Ah, the file is back now.

-- 
jcc7
Feb 21 2007
↑ ↓ ← → kenny <funisher gmail.com> writes:
Walter Bright wrote:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip



small thing,

http://ftp.digitalmars.com/dmd.1.007.zip is a 404 for me, so I downloaded
dmd.zip

I think the version number in dmd --help still says 1.006 -- did I get the
right file?
Feb 21 2007
↑ ↓ ← → =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
kenny kirjoitti:

 Walter Bright wrote:

 Cleanup of compile time function execution issues.

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

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



 small thing,
 
 http://ftp.digitalmars.com/dmd.1.007.zip is a 404 for me, so I downloaded
dmd.zip
 
 I think the version number in dmd --help still says 1.006 -- did I get the
right file?



It has been deleted, I guess. It was there, but not anymore.
Feb 21 2007
↑ ↓ ← → Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:

 Cleanup of compile time function execution issues.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.007.zip



Thanks for nailing #968.

-- 
- EricAnderton at yahoo
Feb 21 2007