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