digitalmars.D - DMD 0.110 release
- "Walter" <newshound digitalmars.com> Dec 30 2004
- "Carlos Santander B." <csantander619 gmail.com> Dec 31 2004
- "Walter" <newshound digitalmars.com> Dec 31 2004
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Dec 31 2004
- "Walter" <newshound digitalmars.com> Dec 31 2004
- David L. Davis <SpottedTiger yahoo.com> Dec 31 2004
- "Walter" <newshound digitalmars.com> Dec 31 2004
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Jan 01 2005
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Jan 01 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Jan 01 2005
- David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> Jan 03 2005
- "Walter" <newshound digitalmars.com> Jan 03 2005
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Jan 01 2005
http://www.digitalmars.com/d/changelog.html
Dec 30 2004
Walter wrote:http://www.digitalmars.com/d/changelog.html
structs now have typeinfo! Great! My question: the typeinfo for a struct is in the form module_name.struct_name, while the other typeinfos and classinfos are withouth the module name. Will it remain that way? I mean, because it seems inconsistent. _______________________ Carlos Santander Bernal
Dec 31 2004
"Walter" <newshound digitalmars.com> "Carlos Santander B." <csantander619 gmail.com> wrote in message news:cr3vhu$jno$1 digitaldaemon.com...Walter wrote:http://www.digitalmars.com/d/changelog.html
structs now have typeinfo! Great! My question: the typeinfo for a struct is in the form module_name.struct_name, while the other typeinfos and classinfos are withouth the module name. Will it remain that way? I mean, because it seems inconsistent.
The typeinfo for classes should have the module name too.
Dec 31 2004
" .sizeof property can no longer be overridden." Hehe, did my thread have something to do with that? ;) Sweet Jesus, structs can be sorted! :D
Dec 31 2004
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message news:cr41gk$lrn$1 digitaldaemon.com..." .sizeof property can no longer be overridden." Hehe, did my thread have something to do with that? ;)
I've known it should be fixed for a while. The original idea was that those properties were part of some pseudo "base" class that could be overridden. I just never found any reasonable justification for overriding the .sizeof.
Dec 31 2004
In article <cr26v2$1rbl$1 digitaldaemon.com>, Walter says...http://www.digitalmars.com/d/changelog.html
Walter: With this build I decided to recheck on some of my MIID (Most important issues for D) which was a thread you started back on 11.Sep.04 before dmd v0.102 was released, I was glad to see that "functions with char[], wchar[], dchar[] parameters are now calling the right matching function" (example test2() below). I guess that must have happen in the dmd v0.105 release where the changelog states: "Changed integral literal type determination to match C99 6.4.4.1." But thus far, the "String Concatenation with String Literals" using wchar[]s and dchar[]s (example test1() below) are still a problem...will this be corrected any time soon? Hope you don't mind me asking? Thanks for your reply in advance! :) # private import std.stdio; # # int main() # { # test1(); # test2(); # # return 0; # # } // end int main() # # // String Concatenation with String Literals # void test1() # { # char[] sDynStr = ""; # wchar[] wsDynStr = ""; # dchar[] dsDynStr = ""; # # // This works # sDynStr = "Initializing to 8-Bit"; # wsDynStr = "Initializing to 16-Bit"; # dsDynStr = "Initializing to 32-bit"; # # // This always works # sDynStr = "This is" ~ " a test!"; # # /+ # ' But when I use the ~ operator it forces # ' the 2nd literal string to a char[] # ' thus causing the "cannot implicitly convert # ' expression "This is a test!" # ' of type char[15] to wchar[]" error. # ' # +/ # wsDynStr = "This is" ~ " a test!"; # dsDynStr = "This is" ~ " a test!"; # # // This works - forced to cast() each literal string # wsDynStr = cast(wchar[])"This is" ~ cast(wchar[])" a test!"; # dsDynStr = cast(dchar[])"This is" ~ cast(dchar[])" a test!"; # # // This works - - forced to cast() a literal string with (x)s # wsDynStr = cast(wchar[])( "This is" ~ " a test!" ); # dsDynStr = cast(dchar[])( "This is" ~ " a test!" ); # # } // end void test1() # # // Functions with char[], wchar[], dchar[] parameters # // now call the right matching function. # void test2() # { # char[] sDynStr = "Testing"; # wchar[] wsDynStr = "Testing"; # dchar[] dsDynStr = "Testing"; # # test( wsDynStr ); # test( sDynStr ); # test( dsDynStr ); # # } // void test2() # # void test( in char[] sText ) # { # writefln( "test( in char[] ) called, sText=%s", sText ); # } # # void test( in wchar[] wsText ) # { # writefln( "test( in wchar[] ) called, wsText=%s", wsText ); # } # # void test( in dchar[] dsText ) # { # writefln( "test( in dchar[] ) called, dsText=%s", dsText ); # } Keep up the good work, David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Dec 31 2004
"David L. Davis" <SpottedTiger yahoo.com> wrote in message news:cr42nb$mro$1 digitaldaemon.com...Walter: With this build I decided to recheck on some of my MIID (Most
issues for D) which was a thread you started back on 11.Sep.04 before dmd
was released, I was glad to see that "functions with char[], wchar[],
parameters are now calling the right matching function" (example test2()
I guess that must have happen in the dmd v0.105 release where the
states: "Changed integral literal type determination to match C99
thus far, the "String Concatenation with String Literals" using wchar[]s
dchar[]s (example test1() below) are still a problem...will this be
any time soon? Hope you don't mind me asking?
No, I don't mind. I don't have a schedule for fixing it, there's a lot of issues that still need addressing.Thanks for your reply in advance! :) # private import std.stdio; # # int main() # { # test1(); # test2(); # # return 0; # # } // end int main() # # // String Concatenation with String Literals # void test1() # { # char[] sDynStr = ""; # wchar[] wsDynStr = ""; # dchar[] dsDynStr = ""; # # // This works # sDynStr = "Initializing to 8-Bit"; # wsDynStr = "Initializing to 16-Bit"; # dsDynStr = "Initializing to 32-bit"; # # // This always works # sDynStr = "This is" ~ " a test!"; # # /+ # ' But when I use the ~ operator it forces # ' the 2nd literal string to a char[] # ' thus causing the "cannot implicitly convert # ' expression "This is a test!" # ' of type char[15] to wchar[]" error. # ' # +/ # wsDynStr = "This is" ~ " a test!"; # dsDynStr = "This is" ~ " a test!"; # # // This works - forced to cast() each literal string # wsDynStr = cast(wchar[])"This is" ~ cast(wchar[])" a test!"; # dsDynStr = cast(dchar[])"This is" ~ cast(dchar[])" a test!"; # # // This works - - forced to cast() a literal string with (x)s # wsDynStr = cast(wchar[])( "This is" ~ " a test!" ); # dsDynStr = cast(dchar[])( "This is" ~ " a test!" ); # # } // end void test1() # # // Functions with char[], wchar[], dchar[] parameters # // now call the right matching function. # void test2() # { # char[] sDynStr = "Testing"; # wchar[] wsDynStr = "Testing"; # dchar[] dsDynStr = "Testing"; # # test( wsDynStr ); # test( sDynStr ); # test( dsDynStr ); # # } // void test2() # # void test( in char[] sText ) # { # writefln( "test( in char[] ) called, sText=%s", sText ); # } # # void test( in wchar[] wsText ) # { # writefln( "test( in wchar[] ) called, wsText=%s", wsText ); # } # # void test( in dchar[] dsText ) # { # writefln( "test( in dchar[] ) called, dsText=%s", dsText ); # } Keep up the good work, David L. ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Dec 31 2004
Walter wrote:http://www.digitalmars.com/d/changelog.html
That's great, but... * the Phobos unittest still breaks (on Linux):Error: AssertError Failure format(734)
digitalmars.D.bugs/2500 * man pages are missing (in the RPM below, and also at http://www.algonet.se/~afb/d/d-manpages/d-manpages.zip Expanded at: http://www.algonet.se/~afb/d/d-manpages/ (DMD + GDC) * the makefiles needs patching for "make -j2" etc, the same problem as with DMD 0.109 and earlier digitalmars.D.bugs/2519 digitalmars.D.bugs/2520 Updated source RPM can be found at the same location: http://www.algonet.se/~afb/d/dmd-0.110-3.nosrc.rpmrpmbuild --with unittest --rebuild dmd-*-*.nosrc.rpm
Packaging Wishlist: 1) include the 3 man pages in distribution (e.g. from the zipfile above) 2) fix the Makefile problems above, and include a "make install" target 3) make a "dmd-0.###.tar.gz" Linux tarball, without Windows binaries Future Hopes for DMD: 1) make the Phobos unittests run... 2) include an updated dmd.spec file 3) offer .i686 RPMS from D homepage --anders PS. Seems to be working in 2005 too, despite the friendly warning: "The Software was not designed to operate after Dec 31, 1999." :-)
Jan 01 2005
Anders F Björklund wrote:Walter wrote:http://www.digitalmars.com/d/changelog.html
about ftp://ftp.digitalmars.com/dmd.110.zip That's great, but... * the Phobos unittest still breaks (on Linux):Error: AssertError Failure format(734)
digitalmars.D.bugs/2500
This is a bug in glibc. David
Jan 01 2005
David Friedman wrote:* the Phobos unittest still breaks (on Linux):Error: AssertError Failure format(734)
digitalmars.D.bugs/2500
This is a bug in glibc.
That's reassuring to hear! (do you know of a fixed glibc version ?) But shouldn't the unit test run in the final version of the library ? (maybe it's not such a great unittest, if it doesn't work everywhere) --anders
Jan 01 2005
Anders F Björklund wrote:David Friedman wrote:* the Phobos unittest still breaks (on Linux):Error: AssertError Failure format(734)
digitalmars.D.bugs/2500
<rest snipped> This is a bug in glibc.
That's reassuring to hear! (do you know of a fixed glibc version ?)
I'm trying to figure out if the latest CVS version has a fix. That doesn't seem to be the case, though, so I'll probably file a bug report.But shouldn't the unit test run in the final version of the library ? (maybe it's not such a great unittest, if it doesn't work everywhere) --anders
Maybe, "version(GlibcHexFloatBug) { /*nothing*/ } else { <test> }" David
Jan 03 2005
"David Friedman" <d3rdclsmail_a_ _t_earthlink_d_._t_net> wrote in message news:crctos$lhd$1 digitaldaemon.com...Anders F Björklund wrote:David Friedman wrote:* the Phobos unittest still breaks (on Linux):Error: AssertError Failure format(734)
digitalmars.D.bugs/2500
<rest snipped> This is a bug in glibc.
That's reassuring to hear! (do you know of a fixed glibc version ?)
I'm trying to figure out if the latest CVS version has a fix. That doesn't seem to be the case, though, so I'll probably file a bug report.
%A doesn't seem to be widely used, so I think it's probably best to wait for a fix in glibc rather than reimplementing it within std.format.But shouldn't the unit test run in the final version of the library ? (maybe it's not such a great unittest, if it doesn't work everywhere) --anders
Maybe, "version(GlibcHexFloatBug) { /*nothing*/ } else { <test> }" David
Jan 03 2005
3) make a "dmd-0.###.tar.gz" Linux tarball, without Windows binaries
No offense, but the download is all of 2.8MB ;) And the zip has linux binaries in it as well, but I'm not complaining.
Jan 01 2005
Jarrett Billingsley wrote:3) make a "dmd-0.###.tar.gz" Linux tarball, without Windows binaries
No offense, but the download is all of 2.8MB ;)
It's possible to use it from SRPM anyway, so it's no big deal... Just have to create a proper directory for it, before unpacking. The zipfile is not redistributable anyway, so size doesn't matter:The Software is copyrighted and comes with a single user license, and may not be redistributed. If you wish to obtain a redistribution license, please contact Digital Mars.
And the line endings can be fixed before doing any patches or such. (the previously posted RPM for DMD has all of the workarounds used) Just some friendy suggestions, --anders
Jan 01 2005