www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.041 and 2.026 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.041.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.026.zip
Mar 05 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 05 Mar 2009 13:40:07 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
W00t! An awesome release! Especially the buildable dmd source part! This is fantastic! Now we can start playing with compiler for real. Very much appreciated!
Mar 05 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 05 Mar 2009 13:40:07 +0300, Walter Bright <newshound1 digitalmars.com>
wrote:

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
You used to put some words with a release announcement, like Faster long divides! Now includes Mac OSX version! etc. Please, keep saying something in future!
Mar 05 2009
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Wow! This release is too good to be true :D Not only are my favorite bugs fixed, the .zip contains the *full source code of DMD* :O And on top of that, the backend changes didn't break my DDL-powered dynamic linking! Walter, you're my hero! -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Mar 05 2009
prev sibling next sibling parent "ideage" <ideage gmail.com> writes:
Walter, you're my hero!

Thanks!!!!!

"Walter Bright" <newshound1 digitalmars.com> 
??????:gooa63$j6g$1 digitalmars.com...
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip 
Mar 05 2009
prev sibling next sibling parent hurd <hurd 163.com> writes:
Walter Bright Wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
I love you so much.
Mar 05 2009
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Finally some fixes but just one issue that was in the Top10 of Bugzilla Voting list ? using D2, thanks to its main feature (const..), unusable. Regards
Mar 05 2009
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <ludwig informatik.uni-luebeck.de> writes:
Extrawurst schrieb:
 Walter Bright wrote:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Finally some fixes but just one issue that was in the Top10 of Bugzilla Voting list ? using D2, thanks to its main feature (const..), unusable. Regards
But other than that its really great step forward (this and the mac support in the prev. release of course). Maybe I can even find some time to look into some open bugs by myself, now that the sources are all available.
Mar 05 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Awesome. You and Andrei and Bartoz and the rest of the D people are doing a truly outstanding job with D. I find it amazing that a language that's being worked on by a few C++ gurus in their spare time kicks $$ compared to languages with massive corporate backing. Purely out of curiosity, with regard to the DMD source, what changed that all of the sudden caused you to release the full source?
Mar 05 2009
next sibling parent fei <flyingxu gmail.com> writes:
dsimcha Wrote:
 Awesome.  You and Andrei and Bartoz and the rest of the D people are doing a
truly
 outstanding job with D.  I find it amazing that a language that's being worked
on
 by a few C++ gurus in their spare time kicks  $$ compared to languages with
 massive corporate backing.
 
 Purely out of curiosity, with regard to the DMD source, what changed that all
of
 the sudden caused you to release the full source?
I'm curious too, :-) anyway, good job & thanks!
Mar 05 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
dsimcha, el  5 de marzo a las 14:03 me escribiste:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Awesome. You and Andrei and Bartoz and the rest of the D people are doing a truly outstanding job with D. I find it amazing that a language that's being worked on by a few C++ gurus in their spare time kicks $$ compared to languages with massive corporate backing. Purely out of curiosity, with regard to the DMD source, what changed that all of the sudden caused you to release the full source?
A non-imposible to contribute opensource compiler called LDC maybe? =) Anyway, it's great that the source is out there. Thanks! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Todos en el mundo somos grasas, no hago distinción de sexo y raza, sólo que algunos lo disfrutan y otros no pueden evitarlo.
Mar 05 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 Purely out of curiosity, with regard to the DMD source, what changed that all
of
 the sudden caused you to release the full source?
I've been intending to for a while, it took a while for me to clean it up, check all the licenses, and get it into a presentable form. Essentially, it's pretty obvious that the world has changed, and closed source is no longer acceptable for a mainstream product that people will be relying on. Open source is the future, and it's past time for dmd to join the party!
Mar 05 2009
next sibling parent 0ffh <frank youknow.what.todo.interNETz> writes:
Walter Bright wrote:
 [...]
 Essentially, it's pretty obvious that the world has changed, and closed 
 source is no longer acceptable for a mainstream product that people will 
 be relying on. Open source is the future, and it's past time for dmd to 
 join the party!
Hell, I'm at a loss for words! Go, D!
Mar 05 2009
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 dsimcha wrote:
 Purely out of curiosity, with regard to the DMD source, what changed 
 that all of
 the sudden caused you to release the full source?
I've been intending to for a while, it took a while for me to clean it up, check all the licenses, and get it into a presentable form. Essentially, it's pretty obvious that the world has changed, and closed source is no longer acceptable for a mainstream product that people will be relying on. Open source is the future, and it's past time for dmd to join the party!
Thanks Walter, I think that is a big step forward. -- Bruno Medeiros
Mar 28 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
2009/3/5 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
From the backend license: "The Software was not designed to operate after December 31, 1999." Well that explains EVERYTHING! ;)
Mar 05 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 From the backend license:
 
 "The Software was not designed to operate after December 31, 1999."
 
 Well that explains EVERYTHING!  ;)
Yeah, well, I'm not at liberty to change that license.
Mar 05 2009
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 2009/3/5 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
From the backend license: "The Software was not designed to operate after December 31, 1999." Well that explains EVERYTHING! ;)
Y2K compliance is such a tricky thing...
Mar 05 2009
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Jarrett Billingsley wrote:
<snip>
 From the backend license:
 
 "The Software was not designed to operate after December 31, 1999."
 
 Well that explains EVERYTHING!  ;)
As does the preceding statement "It has not undergone testing". Hang on ... does that mean that 200% of things are now explained? Now if only the remaining -100% can be explained, human knowledge'll be complete. Stewart.
Mar 06 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Cool thing about the sources!!! Should the following file be removed? samples/d/dhry.res I see no point with it, and it is over 200k.
Mar 05 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:
 Should the following file be removed?
 
 samples/d/dhry.res
 
 I see no point with it, and it is over 200k.
I don't know why that's there, I'll get rid of it.
Mar 05 2009
prev sibling next sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Walter Bright wrote:
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
O.O Hell yeah!
Mar 05 2009
prev sibling next sibling parent Manuel =?ISO-8859-1?B?S/ZuaWc=?= <manuelk89 gmx.net> writes:
Am Thu, 05 Mar 2009 02:40:07 -0800
schrieb Walter Bright <newshound1 digitalmars.com>:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Awesome release, even with the source code! But compiling with dsss on linux using the dmd-posix layout gives: $ Error: version identifier 'Posix' is reserved and cannot be set Apparently this release reserved the Posix identifier on linux. Removing the -version=Posix in your dmd-posix layout fixes this.
Mar 05 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
2009/3/5 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Compiling on linux from source is broken! Looks like you forgot to include the total.h file! -Tomas
Mar 05 2009
next sibling parent reply Don <nospam nospam.com> writes:
Tomas Lindquist Olsen wrote:
 2009/3/5 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Compiling on linux from source is broken! Looks like you forgot to include the total.h file! -Tomas
On Windows, it compiles, but I can't get it to link. The errors are all related to malloc-family functions. ------------ rmem.obj(rmem) Offset 00111H Record Type 0091 Error 1: Previous Definition Different : ?strdup Mem QAEPADPBD Z (char *syscall Mem::strdup(char const *)) --- and so on for the other Mem functions, all from rmem.obj. tk.obj(tk) Error 42: Symbol Undefined ?mem_free YAXPAX Z (void cdecl mem_free(void *)) -- and so on, all the malloc functions from tk.obj. e2ir.obj(e2ir) Error 42: Symbol Undefined ?mem_fcalloc YAPAXI Z (void *cdecl mem_fcalloc(unsi gned )) cgobj.obj(cgobj) Error 42: Symbol Undefined ?mem_realloc YAPAXPAXI Z (void *cdecl mem_realloc(v oid *,unsigned )) -----------
Mar 05 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 05 Mar 2009 18:54:53 +0300, Don <nospam nospam.com> wrote:

 Tomas Lindquist Olsen wrote:
 2009/3/5 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Compiling on linux from source is broken! Looks like you forgot to include the total.h file! -Tomas
On Windows, it compiles, but I can't get it to link. The errors are all related to malloc-family functions. ------------ rmem.obj(rmem) Offset 00111H Record Type 0091 Error 1: Previous Definition Different : ?strdup Mem QAEPADPBD Z (char *syscall Mem::strdup(char const *)) --- and so on for the other Mem functions, all from rmem.obj. tk.obj(tk) Error 42: Symbol Undefined ?mem_free YAXPAX Z (void cdecl mem_free(void *)) -- and so on, all the malloc functions from tk.obj. e2ir.obj(e2ir) Error 42: Symbol Undefined ?mem_fcalloc YAPAXI Z (void *cdecl mem_fcalloc(unsi gned )) cgobj.obj(cgobj) Error 42: Symbol Undefined ?mem_realloc YAPAXPAXI Z (void *cdecl mem_realloc(v oid *,unsigned )) -----------
I'm on Windows, too, and it compiles fine for me. I'm using Microsoft nmake and compile it as follows:
 name win32.mak
Full build log is attached.
Mar 05 2009
prev sibling next sibling parent reply Haruki Shigemori <rayerd.wiz gmail.com> writes:
Don さんは書きました:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
 
 ------------
 rmem.obj(rmem)  Offset 00111H Record Type 0091
  Error 1: Previous Definition Different : ?strdup Mem  QAEPADPBD Z (char 
 *syscall Mem::strdup(char const *))
 
 --- and so on for the other Mem functions, all from rmem.obj.
 
 tk.obj(tk)
  Error 42: Symbol Undefined ?mem_free  YAXPAX Z (void cdecl 
 mem_free(void *))
 
 -- and so on, all the malloc functions from tk.obj.
 
 e2ir.obj(e2ir)
  Error 42: Symbol Undefined ?mem_fcalloc  YAPAXI Z (void *cdecl 
 mem_fcalloc(unsi
 gned ))
 cgobj.obj(cgobj)
  Error 42: Symbol Undefined ?mem_realloc  YAPAXPAXI Z (void *cdecl 
 mem_realloc(v
 oid *,unsigned ))
 -----------
1. Edit win32.mak like this: --- win32.mak.default Thu Mar 05 01:53:36 2009 +++ win32.mak Thu Mar 05 23:06:02 2009 -6,6 +6,6 -D= +D=c:\d SCROOT=$D\dm INCLUDE=$(SCROOT)\include -CC=\dm\bin\dmc +CC=c:\d\dm\bin\dmc LIBNT=$(SCROOT)\lib -14,2 +14,3 CP=cp +SC=c:\d\dm\bin\sc.exe -153,3 +154,3 $(TARGET).exe : $(OBJS) win32.mak - sc -o$(TARGET).exe $(OBJS) -cpp -mn -Ar $(LFLAGS) + $(SC) -o$(TARGET).exe $(OBJS) -cpp -mn -Ar $(LFLAGS) -169,3 +170,3 msgsx.exe : msgsx.c - sc msgsx -mn -D$(TARGET) $(DEFINES) $(WINLIBS) + $(SC) msgsx -mn -D$(TARGET) $(DEFINES) $(WINLIBS) -173,3 +174,3 $C\cdef.h $C\cc.h $C\oper.h $C\ty.h $C\optabgen.c + $(SC) -cpp -ooptabgen.exe $C\optabgen -DMARS -I$(TK) $(WINLIBS) optabgen -181,3 +182,3 id.h id.c : idgen.c - sc -cpp idgen + $(SC) -cpp idgen idgen 2. Remove old dmd and dmc folders. 3. Extract dmd.zip and dmc.zip. You got link errors because you over-wrote to old folders. 4. Enjoy your dmd!
Mar 05 2009
parent reply Don <nospam nospam.com> writes:
Haruki Shigemori wrote:
 Don さんは書きました:
 On Windows, it compiles, but I can't get it to link. The errors are 
 all related to malloc-family functions.
As far as I know, that's the first time I've ever さんは書きました something.
    You got link errors because you over-wrote to old folders.
Thanks! This one line was all I needed.
Mar 05 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:gop88f$2b97$1 digitalmars.com...
 Haruki Shigemori wrote:
 Don ????????:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
As far as I know, that's the first time I've ever ???????? something.
From the tiny bit I've managed to remember, I think it's more like the first time Don-?? had ????? something ;) (What's the root form of that verb in ramaji again? "kikiru" or something like that? I think it starts with a "k", IIRC (My apologies if "kikiru" is something bad))
    You got link errors because you over-wrote to old folders.
Thanks! This one line was all I needed.
Mar 05 2009
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gop8op$2cfj$1 digitalmars.com...
 "Don" <nospam nospam.com> wrote in message 
 news:gop88f$2b97$1 digitalmars.com...
 Haruki Shigemori wrote:
 Don ????????:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
As far as I know, that's the first time I've ever ???????? something.
From the tiny bit I've managed to remember, I think it's more like the first time Don-?? had ????? something ;) (What's the root form of that verb in ramaji again? "kikiru" or something like that? I think it starts with a "k", IIRC (My apologies if "kikiru" is something bad))
    You got link errors because you over-wrote to old folders.
Thanks! This one line was all I needed.
Oops, I guess my newsgroup client can't send UTF. ;)
Mar 05 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Mar 5, 2009 at 11:12 AM, Don <nospam nospam.com> wrote:
 Haruki Shigemori wrote:
 Don $B$5$s$O=q$-$^$7$?(B:
 On Windows, it compiles, but I can't get it to link. The errors are all
 related to malloc-family functions.
As far as I know, that's the first time I've ever $B$5$s$O=q$-$^$7$?(B something.
It says "Don-san wa kakimashita:" or "Mr. Don wrote:" :-)
Mar 05 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Bill Baxter wrote:
 On Thu, Mar 5, 2009 at 11:12 AM, Don <nospam nospam.com> wrote:
 Haruki Shigemori wrote:
 Don さんは書きました:
 On Windows, it compiles, but I can't get it to link. The errors are all
 related to malloc-family functions.
As far as I know, that's the first time I've ever さんは書きました something.
It says "Don-san wa kakimashita:" or "Mr. Don wrote:" :-)
It's the first time I see something in Japanese is longer than the English version.
Mar 05 2009
next sibling parent hasen <hasan.aljudy gmail.com> writes:
Georg Wrede wrote:
 Bill Baxter wrote:
 On Thu, Mar 5, 2009 at 11:12 AM, Don <nospam nospam.com> wrote:
 Haruki Shigemori wrote:
 Don さんは書きました:
 On Windows, it compiles, but I can't get it to link. The errors are 
 all
 related to malloc-family functions.
As far as I know, that's the first time I've ever さんは書きました something.
It says "Don-san wa kakimashita:" or "Mr. Don wrote:" :-)
It's the first time I see something in Japanese is longer than the English version.
Formalities .. otherwise wrote is also 書いた [kaita]
Mar 05 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:gophg0$2uu3$1 digitalmars.com...
 Bill Baxter wrote:
 On Thu, Mar 5, 2009 at 11:12 AM, Don <nospam nospam.com> wrote:
 Haruki Shigemori wrote:
 Don ????????:
 On Windows, it compiles, but I can't get it to link. The errors are 
 all
 related to malloc-family functions.
As far as I know, that's the first time I've ever ???????? something.
It says "Don-san wa kakimashita:" or "Mr. Don wrote:" :-)
It's the first time I see something in Japanese is longer than the English version.
I've noticed it seems to happen both ways. It's interesting how english words get translated into their katakana alphabet. I've seen that occasionally end up longer than the original spelling because of approximating certain sounds and sound combinations that they don't have. And then when that katakana gets written in our english/roman letters, it's roughly twice as long as the katakana. Its been far too long since I've studied it though, so I can't really think of a good example (probably something with a lot of consecutive consonants). I do love the language though (even though I understand very little of it).
Mar 05 2009
prev sibling next sibling parent reply hasen <hasan.aljudy gmail.com> writes:
Don wrote:
 Haruki Shigemori wrote:
 Don さんは書きました:
 On Windows, it compiles, but I can't get it to link. The errors are 
 all related to malloc-family functions.
As far as I know, that's the first time I've ever さんは書きました something.
書きました [kakimashita] -> "wrote" *don't try to pronounce it in English because it's *not* ka-kee-mashii-ta :P
Mar 05 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"hasen" <hasan.aljudy gmail.com> wrote in message 
news:gophel$2vj7$1 digitalmars.com...
 Don wrote:
 Haruki Shigemori wrote:
 Don ????????:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
As far as I know, that's the first time I've ever ???????? something.
????? [kakimashita] -> "wrote" *don't try to pronounce it in English because it's *not* ka-kee-mashii-ta :P
In other words, the "i" from the "shi" generally gets dropped in cases like this. (There isn't anything else about the pronunciation I'm unaware of, is there?)
Mar 05 2009
next sibling parent hasen <hasan.aljudy gmail.com> writes:
Nick Sabalausky wrote:
 "hasen" <hasan.aljudy gmail.com> wrote in message 
 news:gophel$2vj7$1 digitalmars.com...
 Don wrote:
 Haruki Shigemori wrote:
 Don ????????:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
As far as I know, that's the first time I've ever ???????? something.
????? [kakimashita] -> "wrote" *don't try to pronounce it in English because it's *not* ka-kee-mashii-ta :P
In other words, the "i" from the "shi" generally gets dropped in cases like this. (There isn't anything else about the pronunciation I'm unaware of, is there?)
Well, sure there is. You know how non-native-English speakers often pronounce English words using the rules of their own native language? And they sound kinda funny, no? (This includes me too! lol) Same thing kinda applies here. There are several differences (some of them are somewhat subtle) that make American pronunciation of Japanese sound quite .. funny :P Just one example, in English (more specifically, north american english), most often, non-stressed vowels are converted to schwa (think about the 'u' sound in the verb subject vs the noun subject). Japanese doesn't do that kinda thing. wow, this is very off-topic.
Mar 05 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:
 "hasen" <hasan.aljudy gmail.com> wrote in message 
 news:gophel$2vj7$1 digitalmars.com...
 Don wrote:
 Haruki Shigemori wrote:
 Don ????????:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
As far as I know, that's the first time I've ever ???????? something.
????? [kakimashita] -> "wrote" *don't try to pronounce it in English because it's *not* ka-kee-mashii-ta :P
In other words, the "i" from the "shi" generally gets dropped in cases like this. (There isn't anything else about the pronunciation I'm unaware of, is there?)
It's elided completely these days? I was aware that high vowels became voiceless between voiceless consonants, but this is new. It does sound about right, but I'm not used to hearing voiceless vowels, so it's a bit hard for me to distinguish.
Mar 06 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
I uploaded new makefiles, should fix the problem.
Mar 05 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 On Windows, it compiles, but I can't get it to link. The errors are all 
 related to malloc-family functions.
It could be you're picking up the wrong mem.h. Try installing the source tree into a clean directory.
Mar 05 2009
prev sibling next sibling parent Christian Kamm <kamm-incasoftware shiftleftandremove.de> writes:
Tomas Lindquist Olsen Wrote:
 Compiling on linux from source is broken! Looks like you forgot to
 include the total.h file!
It compiles with some changes (dchar path, mars.h path, remove copyright.c from makefile) and the total.h from dmd 1.039. Thanks for making this available!
Mar 05 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 Compiling on linux from source is broken! Looks like you forgot to
 include the total.h file!
You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
Mar 05 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  5 de marzo a las 11:37 me escribiste:
 Tomas Lindquist Olsen wrote:
Compiling on linux from source is broken! Looks like you forgot to
include the total.h file!
You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
I don't know exactly what you mean, but: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Pitzulino! Pitzulino! Todos a cantar por el tubo! Pitzulino! Pitzulino! Todos a cantar por el codo!
Mar 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el  5 de marzo a las 11:37 me escribiste:
 Tomas Lindquist Olsen wrote:
 Compiling on linux from source is broken! Looks like you forgot to
 include the total.h file!
You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
I don't know exactly what you mean, but: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
I suppose it's been added since the last time I looked. gcc has thousands of switches.
Mar 06 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Leandro Lucarella wrote:
 Walter Bright, el  5 de marzo a las 11:37 me escribiste:
 Tomas Lindquist Olsen wrote:
 Compiling on linux from source is broken! Looks like you forgot to
 include the total.h file!
You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
I don't know exactly what you mean, but: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
I suppose it's been added since the last time I looked. gcc has thousands of switches.
There are days when I can get upset at you for not implementing feature X. I really need X, damnit. Do you have any idea how badly I want X?! ... And then I do something that requires me to look at the man page for gcc. And then I die a little inside. It's strange at times, but I do appreciate that you take a considerable amount of convincing. It's a bit like the situation with Archchancellor Mustrum Ridcully from Discworld; he holds the view that if someone is still trying to explain something to him after about 2 minutes, it must be worth listening to, and if they give up earlier, it was not worth bothering him with in the first place. Obviously, s/minutes/years/ :P -- Daniel
Mar 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 
 Walter Bright wrote:
 Leandro Lucarella wrote:
 Walter Bright, el  5 de marzo a las 11:37 me escribiste:
 Tomas Lindquist Olsen wrote:
 Compiling on linux from source is broken! Looks like you forgot to
 include the total.h file!
You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
I don't know exactly what you mean, but: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
I suppose it's been added since the last time I looked. gcc has thousands of switches.
There are days when I can get upset at you for not implementing feature X. I really need X, damnit. Do you have any idea how badly I want X?! ... And then I do something that requires me to look at the man page for gcc. And then I die a little inside.
Every command line switch that a compiler has is a failure of design. It reminds me of early jet engine controls for aircraft. There were all kinds of tweaks for it, and the pilot often got it wrong. The thing was eventually boiled down to a fantastically complicated mechanical box, that had one lever on it - "gimme more power".
 It's strange at times, but I do appreciate that you take a considerable
 amount of convincing.  It's a bit like the situation with Archchancellor
 Mustrum Ridcully from Discworld; he holds the view that if someone is
 still trying to explain something to him after about 2 minutes, it must
 be worth listening to, and if they give up earlier, it was not worth
 bothering him with in the first place.
The C++ standards committee has a good system for that. They won't consider any ideas unless they are submitted as papers. The idea is that if someone doesn't care enough about a feature to write a paper about it, it isn't worth the committee's time. I'm not willing to go that far, but working on D is a full time job for me. New ideas and proposals come in *every single day*. I cannot even *read* them all, let alone prepare an intelligent reply even in saying it's not a good idea.
Mar 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 Walter Bright wrote:
 Leandro Lucarella wrote:
 Walter Bright, el  5 de marzo a las 11:37 me escribiste:
 Tomas Lindquist Olsen wrote:
 Compiling on linux from source is broken! Looks like you forgot to
 include the total.h file!
You don't need it, I'll fix the makefile. total.h is for precompiled headers, which don't even exist on gcc.
I don't know exactly what you mean, but: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
I suppose it's been added since the last time I looked. gcc has thousands of switches.
There are days when I can get upset at you for not implementing feature X. I really need X, damnit. Do you have any idea how badly I want X?! ... And then I do something that requires me to look at the man page for gcc. And then I die a little inside.
Every command line switch that a compiler has is a failure of design. It reminds me of early jet engine controls for aircraft. There were all kinds of tweaks for it, and the pilot often got it wrong. The thing was eventually boiled down to a fantastically complicated mechanical box, that had one lever on it - "gimme more power".
I wish somehow all this nice philosophy about aircraft would somehow found its way in the compiler implementation. Or perhaps it *is* the main cause of the problems with the compielr implementation. I finally found out why dmd was crashing on my program with nothing but "Segmentation fault": assert(puu.is_empty()); was used in my old code instead of: assert(puu.empty()); This was inside a template class and was enough to have the compiler segfault leaving me with no line and not even file information. Combine that with templates and multiple files and -lib compiling, and you'll see just how pernicious that is. (If you answer and the answer contains "binary search", I'll drop to the ground and start kicking it with my arms and legs. Binary search for where compilation fails DOES NOT WORK! It is search but NOWHERE NEAR binary.) If you allow me a little criticism, I did notice different pattern which may also be derived from a systematic mechanical engineering approach: there generality could be improved. From the hail of bugs that hit my face on a daily basis, I notice that stuff that works works only for the situations it was tested, and subsequently bug fixes only fix one particular situation, not an entire class of problems. That's why reenactments of bugs are not infrequent. Without having looked at the dmd source, I'd conjecture that it contains in many places a hodge-podge of particular cases instead of consistently looking to nail the general problem. I guess this would be the way to go in mechanical engineering, where restrictions of the natural world make the by-case analysis easier to carry exhaustively. Andrei
Mar 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 I wish somehow all this nice philosophy about aircraft would somehow 
 found its way in the compiler implementation.
I was referring to the language design, but yes, I think some of it is in the compiler implementation. In your criticism, you should also realize the Boeing is extremely conservative about adopting new designs. D is not conservative in that way at all, we're constantly trying out new things, and that means crashes and the occasional blowup on the launch pad <g>. It took about 20 years of flying jet engines in aircraft, and iterative improvements, to really work the usability problems out. I once had an illuminating conversation with the lead engineer of the 757 cockpit design. I (stupidly) said it was obvious how to design the controls. He mildly replied that everything that looked obvious was paid for by someone who splattered his brains over the instrument panel, and the obviousness of the right way to do it was discovered only later after careful analysis.
 Or perhaps it *is* the 
 main cause of the problems with the compielr implementation.  I finally 
 found out why dmd was crashing on my program with nothing but 
 "Segmentation fault":
 
 assert(puu.is_empty());
 
 was used in my old code instead of:
 
 assert(puu.empty());
 
 This was inside a template class and was enough to have the compiler 
 segfault leaving me with no line and not even file information. Combine 
 that with templates and multiple files and -lib compiling, and you'll 
 see just how pernicious that is. (If you answer and the answer contains 
 "binary search", I'll drop to the ground and start kicking it with my 
 arms and legs. Binary search for where compilation fails DOES NOT WORK! 
 It is search but NOWHERE NEAR binary.)
I agree that the line number thing is a constant problem. It really is a load of special cases.
 If you allow me a little criticism, I did notice different pattern which 
 may also be derived from a systematic mechanical engineering approach: 
 there generality could be improved. From the hail of bugs that hit my 
 face on a daily basis, I notice that stuff that works works only for the 
 situations it was tested, and subsequently bug fixes only fix one 
 particular situation, not an entire class of problems. That's why 
 reenactments of bugs are not infrequent. Without having looked at the 
 dmd source, I'd conjecture that it contains in many places a hodge-podge 
 of particular cases instead of consistently looking to nail the general 
 problem. I guess this would be the way to go in mechanical engineering, 
 where restrictions of the natural world make the by-case analysis easier 
 to carry exhaustively.
In my defense, I'll point out that you said that when you did "Modern C++ Design" you had similar issues with C++ compilers not working. You are writing code right out on the edge, and often over the edge, of what has been implemented in the compiler. I'm not making excuses, but it's often hard to see what the general case is until after the special cases are accounted for. Then it's time for refactoring can cleanup. When I implement a new feature, there isn't (by definition) any existing body of code that uses it. So I have no test cases, nothing, other than what I cobble together. You're often the first person to use the feature in a substantive way. Special cases are an odd thing with computers. What a computer sees as a special case a user sees as a generalization, and vice versa. Programming languages struggle with this dissonance all the time. For a recent example on the n.g., 'void' is a special case to the compiler, but a general case to the programmer. Back in college, a science historian did a nice lecture on how research was done. He said that in reading the scientists' notebooks, he found that they went all over the place in trying to find a solution. When they finally found it, they wrote a paper where they presented their activities as a straight line progression from hypothesis to proof, whereas the reality of how it actually happened was nothing like that. I also wish to point out that despite dmd being written in C++, it has had very few memory corruption bugs in the last 10 years. (Lars found one I introduced with the Mac port.) I attribute that to changing my coding style to a way which heads them off, but that wasn't possible without long experience with them. The problems you're seeing are with the new stuff, not the old stuff.
Mar 07 2009
next sibling parent 0ffh <frank youknow.what.todo.interNETz> writes:
Walter Bright wrote:
 [...] Back in college, a science historian did a nice lecture on how
 research was done. He said that in reading the scientists' notebooks, he
 found that they went all over the place in trying to find a solution. When
 they finally found it, they wrote a paper where they presented their 
 activities as a straight line progression from hypothesis to proof, whereas
 the reality of how it actually happened was nothing like that. [...]
Reminds me of Parnas' "A rational design process: How and why to fake it"... =)
Mar 07 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 I wish somehow all this nice philosophy about aircraft would somehow 
 found its way in the compiler implementation.
I was referring to the language design, but yes, I think some of it is in the compiler implementation. In your criticism, you should also realize the Boeing is extremely conservative about adopting new designs. D is not conservative in that way at all, we're constantly trying out new things, and that means crashes and the occasional blowup on the launch pad <g>. It took about 20 years of flying jet engines in aircraft, and iterative improvements, to really work the usability problems out. I once had an illuminating conversation with the lead engineer of the 757 cockpit design. I (stupidly) said it was obvious how to design the controls. He mildly replied that everything that looked obvious was paid for by someone who splattered his brains over the instrument panel, and the obviousness of the right way to do it was discovered only later after careful analysis.
 Or perhaps it *is* the main cause of the problems with the compielr 
 implementation.  I finally found out why dmd was crashing on my 
 program with nothing but "Segmentation fault":

 assert(puu.is_empty());

 was used in my old code instead of:

 assert(puu.empty());

 This was inside a template class and was enough to have the compiler 
 segfault leaving me with no line and not even file information. 
 Combine that with templates and multiple files and -lib compiling, and 
 you'll see just how pernicious that is. (If you answer and the answer 
 contains "binary search", I'll drop to the ground and start kicking it 
 with my arms and legs. Binary search for where compilation fails DOES 
 NOT WORK! It is search but NOWHERE NEAR binary.)
I agree that the line number thing is a constant problem. It really is a load of special cases.
 If you allow me a little criticism, I did notice different pattern 
 which may also be derived from a systematic mechanical engineering 
 approach: there generality could be improved. From the hail of bugs 
 that hit my face on a daily basis, I notice that stuff that works 
 works only for the situations it was tested, and subsequently bug 
 fixes only fix one particular situation, not an entire class of 
 problems. That's why reenactments of bugs are not infrequent. Without 
 having looked at the dmd source, I'd conjecture that it contains in 
 many places a hodge-podge of particular cases instead of consistently 
 looking to nail the general problem. I guess this would be the way to 
 go in mechanical engineering, where restrictions of the natural world 
 make the by-case analysis easier to carry exhaustively.
In my defense, I'll point out that you said that when you did "Modern C++ Design" you had similar issues with C++ compilers not working. You are writing code right out on the edge, and often over the edge, of what has been implemented in the compiler. I'm not making excuses, but it's often hard to see what the general case is until after the special cases are accounted for. Then it's time for refactoring can cleanup. When I implement a new feature, there isn't (by definition) any existing body of code that uses it. So I have no test cases, nothing, other than what I cobble together. You're often the first person to use the feature in a substantive way. Special cases are an odd thing with computers. What a computer sees as a special case a user sees as a generalization, and vice versa. Programming languages struggle with this dissonance all the time. For a recent example on the n.g., 'void' is a special case to the compiler, but a general case to the programmer. Back in college, a science historian did a nice lecture on how research was done. He said that in reading the scientists' notebooks, he found that they went all over the place in trying to find a solution. When they finally found it, they wrote a paper where they presented their activities as a straight line progression from hypothesis to proof, whereas the reality of how it actually happened was nothing like that. I also wish to point out that despite dmd being written in C++, it has had very few memory corruption bugs in the last 10 years. (Lars found one I introduced with the Mac port.) I attribute that to changing my coding style to a way which heads them off, but that wasn't possible without long experience with them. The problems you're seeing are with the new stuff, not the old stuff.
Well this is all nice and dandy, but lately dmd does next to nothing to improve my mood. I gotta tell about this bug because it's very illustrative. The newly-added local instantiation continued to not work in one rather obvious case when it should have, with the error: std/algorithm.d(4228): function std.algorithm.topNIndex!("a > b",cast(SwapStrategy)0,int[],ubyte[]).topNIndex.BinaryHeap!(ubyte[],indirectLess .BinaryHeap.heapify cannot get frame pointer to indirectLess The pointed-to line was: public void heapify(Range r, size_t i) I spent a couple of of hours on figuring out what was going on. I tried simpler cases - they all compiled. I tried to comment out code in std.algorithm until there was only a shell of empty function - it didn't compile. At some point, in a bout of exasperation, I removed the redundant "public". (I've put it there to remind myself and you about a bug that disallows private functions.) In the context it was redundant - it did absolutely nothing. As soon as I removed it, the unittest compiled, linked, and ran. I have no idea how the redundant "public" is so important to something completely unrelated. But I can tell that a design that needs to handle that as a special case, and in which the very interaction is allowed to occur on separate code paths,... well, I better stop here. Andrei
Mar 07 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 New ideas and proposals come in *every single day*.
Consider yourself a very lucky person for this. Bye, bearophile
Mar 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 New ideas and proposals come in *every single day*.
Consider yourself a very lucky person for this.
Sure. It's an embarrassment of riches.
Mar 07 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
I can confirm that this indeed fixes the issues with the infinite loop
in compilation for me.   And it does so without creating any
blahblah__initZ errors too.  This is the first compiler since 1.037
that can actually compile my source.

Not sure about the speed though.  I haven't measured the compile time,
but it did feel like it took significantly longer to compile than
1.037 did.  I'll measure it when I get the chance to see if there's
really a difference or not.

--bb

2009/3/5 Walter Bright <newshound1 digitalmars.com>:
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Mar 05 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
Great release! :)

Although I'm curious, where is the 3x speed improvement from? Just general 
misc optimizations, or something specific? 
Mar 05 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gopboj$2j0b$1 digitalmars.com...
 Great release! :)

 Although I'm curious, where is the 3x speed improvement from? Just general 
 misc optimizations, or something specific?
Compile Times For DWT)?
Mar 05 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 Although I'm curious, where is the 3x speed improvement from? Just general 
 misc optimizations, or something specific? 
Have to ask Don, he did that!
Mar 05 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:
 Great release! :)
 
 Although I'm curious, where is the 3x speed improvement from? Just general 
 misc optimizations, or something specific? 
That's a 3x speed improvement for those particular library functions, not dmd or the resulting code :P
Mar 05 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:
 Great release! :)
 
 Although I'm curious, where is the 3x speed improvement from? Just general 
 misc optimizations, or something specific? 
 
 
It's just the exp(), expm1(), and exp2() functions. Previously they used some extremely slow asm instructions. I wrote completely new implementations that are fast. It was done primarily because the C std math library was inaccurate on Mac OSX. Most people won't care. But in the past, someone (Robert Frazer, I think) had complained that DMD's exp() was the bottleneck in his code, and was less than half as fast as MSVC/Intel, so the speed of these functions is actually critical sometimes.
Mar 06 2009
parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 06 Mar 2009 03:35:10 -0500, Don <nospam nospam.com> wrote:
 But in the past, someone (Robert Frazer, I think) had complained that  
 DMD's exp() was the bottleneck in his code, and was less than half as  
 fast as MSVC/Intel, so the speed of these functions is actually critical  
 sometimes.
Actually, it was me and thank you very much!
Mar 06 2009
prev sibling next sibling parent hurd <changlon gmail.com> writes:
Georg Wrede Wrote:

 Bill Baxter wrote:
 On Thu, Mar 5, 2009 at 11:12 AM, Don <nospam nospam.com> wrote:
 Haruki Shigemori wrote:
 Don さんは書きました:
 On Windows, it compiles, but I can't get it to link. The errors are all
 related to malloc-family functions.
As far as I know, that's the first time I've ever さんは書きました something.
It says "Don-san wa kakimashita:" or "Mr. Don wrote:" :-)
It's the first time I see something in Japanese is longer than the English version.
"書" is mean "wrote" in old Japanese or Chinese language.
Mar 05 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Walter Bright Wrote:

 total.h is for precompiled headers, which don't even exist on gcc.
??? Did I get it right that gcc doesn't support precompiled headers?
Mar 06 2009
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kagamin wrote:

 total.h is for precompiled headers, which don't even exist on gcc.
??? Did I get it right that gcc doesn't support precompiled headers?
Sounds strange... http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Precompiled-Headers.html --anders
Mar 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Bjrklund wrote:
 Kagamin wrote:
 
 total.h is for precompiled headers, which don't even exist on gcc.
??? Did I get it right that gcc doesn't support precompiled headers?
Sounds strange... http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Precompiled-Headers.html
Well, it didn't when I initially worked on linux.
Mar 06 2009
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Precompiled-Headers.html
Well, it didn't when I initially worked on linux.
True, forgot that it's been in Apple GCC much longer than in main. Think they didn't appear there until GCC 3.4, so only since 2004 ? --anders
Mar 07 2009
prev sibling next sibling parent reply wade <swadenator gmail.com> writes:
I don't see this in the change logs but does this version fix the MacOS seek
problem (issue 2689)?

Just curious,
wade

Walter Bright Wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
Mar 06 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
wade wrote:
 I don't see this in the change logs but does this version fix the MacOS seek
problem (issue 2689)?
It should be fixed in the next release as an artifact of some other changes that are being made.
Mar 06 2009
parent wade <swadenator gmail.com> writes:
great!

wade

Sean Kelly Wrote:

 wade wrote:
 I don't see this in the change logs but does this version fix the MacOS seek
problem (issue 2689)?
It should be fixed in the next release as an artifact of some other changes that are being made.
Mar 06 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
wade wrote:
 I don't see this in the change logs but does this version fix the
 MacOS seek problem (issue 2689)?
No. Would you like to take a look at figuring out what's wrong?
Mar 06 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:

 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.041.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.026.zip
How awesome, thank you so much!
Mar 07 2009
prev sibling next sibling parent wade <swadenator gmail.com> writes:
I believe the problem relates to calls to lseek in stream.d (multiple places,
e.g. class File: line 1981):

Unlike standard posix, darwin uses a 64bit offset by default so this line
causes issues:

  ulong result = lseek(hFile, cast(int)offset, rel);

Here's a link to this problem:

http://www.opendarwin.info/opendarwin.org/en/faq/ch04.html#lseek

There's some discussion about this on the bugs list.

wade

Walter Bright Wrote:

 wade wrote:
 I don't see this in the change logs but does this version fix the
 MacOS seek problem (issue 2689)?
No. Would you like to take a look at figuring out what's wrong?
Mar 07 2009
prev sibling next sibling parent reply davesun <davesun 126.com> writes:
when can I use dmd on 64bit linux ?
Mar 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
davesun wrote:
 when can I use dmd on 64bit linux ?
You can now - 32 bit executables work fine on 64 bit linux!
Mar 11 2009
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:
 davesun wrote:
 when can I use dmd on 64bit linux ?
You can now - 32 bit executables work fine on 64 bit linux!
Maybe I should try it again sometime, but I ran into linker issues when I tried using DMD on 64bit linux. Other than that, DMD worked fine.
Mar 12 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Ellery Newcomer (ellery-newcomer utulsa.edu)'s article
 Walter Bright wrote:
 davesun wrote:
 when can I use dmd on 64bit linux ?
You can now - 32 bit executables work fine on 64 bit linux!
Maybe I should try it again sometime, but I ran into linker issues when I tried using DMD on 64bit linux. Other than that, DMD worked fine.
Same here, but only on some installations of 64-bit Linux. Others work fine. I think the key is that you need the 32-bit version of GCC and all the libraries like libpthread, libgcc, libc, etc. available. I've been nagging my sysadmin to install these, though it matters less for me now that I have the DMD source and was able to make DMD work on some other Linux boxes that it previously didn't work on for unrelated reasons. If you have a bunch of Linux boxes around, you can also compile on one that has the 32-bit libs and copy the resulting binary over to one that doesn't, and it will usually work.
Mar 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:
 == Quote from Ellery Newcomer (ellery-newcomer utulsa.edu)'s article
 Walter Bright wrote:
 davesun wrote:
 when can I use dmd on 64bit linux ?
You can now - 32 bit executables work fine on 64 bit linux!
Maybe I should try it again sometime, but I ran into linker issues when I tried using DMD on 64bit linux. Other than that, DMD worked fine.
Same here, but only on some installations of 64-bit Linux. Others work fine. I think the key is that you need the 32-bit version of GCC and all the libraries like libpthread, libgcc, libc, etc. available. I've been nagging my sysadmin to install these, though it matters less for me now that I have the DMD source and was able to make DMD work on some other Linux boxes that it previously didn't work on for unrelated reasons. If you have a bunch of Linux boxes around, you can also compile on one that has the 32-bit libs and copy the resulting binary over to one that doesn't, and it will usually work.
On Ubuntu64, which is my main linux dev machine, the following is necessary: To compile 32 bit programs under ub64: sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386 To run 32 bit programs: sudo apt-get install gcc-multilib sudo apt-get install g++-multilib (After long bitter experience, I now keep notes on how to configure the machine after a fresh install <g>.)
Mar 12 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:
 dsimcha wrote:
 == Quote from Ellery Newcomer (ellery-newcomer utulsa.edu)'s article
 Walter Bright wrote:
 davesun wrote:
 when can I use dmd on 64bit linux ?
You can now - 32 bit executables work fine on 64 bit linux!
Maybe I should try it again sometime, but I ran into linker issues when I tried using DMD on 64bit linux. Other than that, DMD worked fine.
Same here, but only on some installations of 64-bit Linux. Others work fine. I think the key is that you need the 32-bit version of GCC and all the libraries like libpthread, libgcc, libc, etc. available. I've been nagging my sysadmin to install these, though it matters less for me now that I have the DMD source and was able to make DMD work on some other Linux boxes that it previously didn't work on for unrelated reasons. If you have a bunch of Linux boxes around, you can also compile on one that has the 32-bit libs and copy the resulting binary over to one that doesn't, and it will usually work.
On Ubuntu64, which is my main linux dev machine, the following is necessary: To compile 32 bit programs under ub64: sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386 To run 32 bit programs: sudo apt-get install gcc-multilib sudo apt-get install g++-multilib (After long bitter experience, I now keep notes on how to configure the machine after a fresh install <g>.)
When I have free time again I'll give that a try. I found it easier just to put something inside a VM.
Mar 12 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 dsimcha wrote:
 == Quote from Ellery Newcomer (ellery-newcomer utulsa.edu)'s article
 Walter Bright wrote:
 davesun wrote:
 when can I use dmd on 64bit linux ?
You can now - 32 bit executables work fine on 64 bit linux!
Maybe I should try it again sometime, but I ran into linker issues when I tried using DMD on 64bit linux. Other than that, DMD worked fine.
Same here, but only on some installations of 64-bit Linux. Others work fine. I think the key is that you need the 32-bit version of GCC and all the libraries like libpthread, libgcc, libc, etc. available. I've been nagging my sysadmin to install these, though it matters less for me now that I have the DMD source and was able to make DMD work on some other Linux boxes that it previously didn't work on for unrelated reasons. If you have a bunch of Linux boxes around, you can also compile on one that has the 32-bit libs and copy the resulting binary over to one that doesn't, and it will usually work.
On Ubuntu64, which is my main linux dev machine, the following is necessary: To compile 32 bit programs under ub64: sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386 To run 32 bit programs: sudo apt-get install gcc-multilib sudo apt-get install g++-multilib (After long bitter experience, I now keep notes on how to configure the machine after a fresh install <g>.)
Seems I might have to as well. Before installing these, I was getting a "file not found" error running dmd. Now everything works perfectly. Talk about a confusing error message!
May 04 2009
prev sibling next sibling parent reply The Anh Tran <trtheanh gmail.com> writes:
Download page says so:
http://www.digitalmars.com/d/download.html

I've never noticed this until i make proposal for my friends.
Thanks.
Mar 13 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 13 Mar 2009 13:12:47 -0400, The Anh Tran wrote:

 Download page says so:
 http://www.digitalmars.com/d/download.html

 I've never noticed this until i make proposal for my friends.
 Thanks.
The whole 1.0 branch is supposed to be stable (meaning, no new features only bug fixes). There have been releases that were unusable due to obscure introduced bugs, but there are definitely more recent versions than 1.030 that were usable. I use 1.038 at the moment. I have no idea why 1.030 is annointed the stable version. -Steve
Mar 13 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Mar 13, 2009 at 1:20 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 On Fri, 13 Mar 2009 13:12:47 -0400, The Anh Tran wrote:

 The whole 1.0 branch is supposed to be stable (meaning, no new features o=
nly
 bug fixes). =A0There have been releases that were unusable due to obscure
 introduced bugs, but there are definitely more recent versions than 1.030
 that were usable. =A0I use 1.038 at the moment.
I don't know why there's a 'stable' version either. The newer versions are usually more stable (fewer bugs).
 I have no idea why 1.030 is annointed the stable version.
Worse, which version is "stable" is inconsistent. On the D1 changelog, it has a link to download the latest stable compiler, marked as 1.020.
Mar 13 2009
prev sibling next sibling parent reply John Stoneham <captnjameskirk yahoo.com> writes:
There is a problem with debug symbols, namely source file paths, generated by
DMD on OS X. It seems that gdb cannot find any source files when debugging a
program compiled with DMD's -g (or -gc) switch, with a "no source file named
[whatever]" error, so setting breakpoints is impossible. GDC on OS X does not
have this problem. Some googling around has led me to discover that GNU gcc on
linux (not Apple gcc) also had this problem a few releases ago until it was
patched, caused by something to do with the pathnames used in the debug symbols
it generated, though I'm not sure of the technical details.
Mar 17 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2741
Mar 17 2009
prev sibling parent reply John Stoneham <captnjameskirk yahoo.com> writes:
Walter Bright Wrote:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=2741
A few more details if it'll help. Using the gdb command "info sources" on a simple Tango "hello" program lists the following (comiled with "dmd -g"), which lists no D source files at all: /System/Library/Frameworks/System.framework/PrivateHeaders/i386 cpu_capabilities.h, /System/Library/Frameworks/System.framework/PrivateHeaders/machine cpu_capabilities.h, <command line>, <built-in>, /SourceCache/Libsystem/Libsystem-88.3.10//, CommPageSymbols.st, {standard input} Now, the same file compiled with GDC shows the following sources: /System/Library/Frameworks/System.framework/PrivateHeaders/i386 cpu_capabilities.h, /System/Library/Frameworks/System.framework/PrivateHeaders/machine cpu_capabilities.h, <command line>, <built-in>, /SourceCache/Libsystem/Libsystem-88.3.10//, CommPageSymbols.st, {standard input}, ../shared/rt/typeinfo/ti_C.d, critical.c, arraycast.d, ../shared/rt/util/string.d, ../shared/rt/util/hash.d, ../shared/rt/util/console.d, ../shared/rt/typeinfo/ti_wchar.d, ../shared/rt/typeinfo/ti_void.d, ../shared/rt/typeinfo/ti_ushort.d, ../shared/rt/typeinfo/ti_uint.d, ../shared/rt/typeinfo/ti_ubyte.d, ../shared/rt/typeinfo/ti_short.d, ../shared/rt/typeinfo/ti_int.d, ../shared/rt/typeinfo/ti_dchar.d, ../shared/rt/typeinfo/ti_char.d, ../shared/rt/typeinfo/ti_byte.d, ../shared/rt/typeinfo/ti_Ashort.d, ../shared/rt/typeinfo/ti_Aint.d, ../shared/rt/typeinfo/ti_Ag.d, ../shared/rt/typeinfo/ti_AC.d, monitor.c, memory_dyld.c, memory.d, /Users/obijohn/projects/d/tango/std/c/stdarg.di, lifetime.d, genobj.d, gcc/unwind.d, gcc/deh.d, dgccmain2.d, cmain.d, cast.d, aaA.d, /Users/obijohn/projects/d/hello.d Also, I took a look at the executable in a hex editor, and in the DMD-compiled version the main source filename actually comes directly before the path (it comes after the path in the GDC-compiled version). I don't know if this means anything, though.
Mar 17 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
John Stoneham wrote:
 Also, I took a look at the executable in a hex editor, and in the
 DMD-compiled version the main source filename actually comes directly
 before the path (it comes after the path in the GDC-compiled
 version). I don't know if this means anything, though.
Use the dumpobj program that comes with dmd, it'll make it a lot easier to examine object files. Also, anyone can post bug reports and more info to bugzilla!
Mar 17 2009