www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.110 release

reply "Walter" <newshound digitalmars.com> writes:
http://www.digitalmars.com/d/changelog.html
Dec 30 2004
next sibling parent reply "Carlos Santander B." <csantander619 gmail.com> writes:
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
parent "Walter" <newshound digitalmars.com> writes:
"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
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
" .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
parent "Walter" <newshound digitalmars.com> writes:
"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
prev sibling next sibling parent reply David L. Davis <SpottedTiger yahoo.com> writes:
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
parent "Walter" <newshound digitalmars.com> writes:
"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
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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.rpm
 rpmbuild --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
next sibling parent reply David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> writes:
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
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
parent reply David Friedman <d3rdclsmail_a_ _t_earthlink_d_._t_net> writes:
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
parent "Walter" <newshound digitalmars.com> writes:
"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
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 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
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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