digitalmars.D.announce - DMD 1.007 release
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
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.
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
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).
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
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.
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
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
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
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")));
}
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!
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; }
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.
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 ...
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.
"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.
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
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
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
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.
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
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
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 :)
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*
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.
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.
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 :).
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
== 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.
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.
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.
http://ftp.digitalmars.com/dmd.1.007.zip
ftp://ftp.digitalmars.com/dmd.1.007.zip
works
- Paul
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
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?
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.
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
|
C & C++
DMDScript
kris <foo bar.com> 