Jump to page: 1 2
Thread overview
DMD 0.110 release
Dec 31, 2004
Walter
Dec 31, 2004
Walter
Dec 31, 2004
Walter
Dec 31, 2004
David L. Davis
Dec 31, 2004
Walter
Jan 01, 2005
David Friedman
Jan 04, 2005
David Friedman
Jan 04, 2005
Walter
December 31, 2004
http://www.digitalmars.com/d/changelog.html


December 31, 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
December 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


December 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!"
December 31, 2004
"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.


December 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.


December 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
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?

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!"


January 01, 2005
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)

http://www.digitalmars.com/drn-bin/wwwnews?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

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2519
http://www.digitalmars.com/drn-bin/wwwnews?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
Just the specfile: http://www.algonet.se/~afb/d/dmd.spec

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." :-)
January 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)
> 
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2500
> 
<rest snipped>

This is a bug in glibc.

David
January 01, 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.


« First   ‹ Prev
1 2