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 ? And thanks to issue #2560 this is the 4th release in a row that makes 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 ? And thanks to issue #2560 this is the 4th release in a row that makes using D2, thanks to its main feature (const..), unusable. Regards

I'll have to second that. Bug #2560 is still a blocker for me, too. 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

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 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) #-L$(LINKS) + $(SC) -cpp -ooptabgen.exe $C\optabgen -DMARS -I$(TK) $(WINLIBS) #-L$(LINKS) 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.

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.


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.



Oops, I guess my newsgroup client can't send UTF. ;)
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.



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



*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 next sibling 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.



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.


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.



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

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!

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!

headers, which don't even exist on gcc.

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

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!

headers, which don't even exist on gcc.

http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

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 "Denis Koroskin" <2korden gmail.com> writes:
------------zWYzISqI0TB6UaUJtxZveh
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: 7bit

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

include the total.h file! -Tomas

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. ------------zWYzISqI0TB6UaUJtxZveh Content-Disposition: attachment; filename=build.log Content-Type: application/octet-stream; name=build.log Content-Transfer-Encoding: Base64 CW5tYWtlIC1md2luMzIubWFrIEM9YmFja2VuZCBUSz10ayBST09UPXJvb3QgY2xl YW4NCglkZWwgKi5vYmoNCglkZWwgdG90YWwuc3ltDQoJZGVsIG1zZ3MuaCBtc2dz LmMNCglkZWwgZWx4eHguYyBjZHh4eC5jIG9wdGFiLmMgZGVidGFiLmMgZmx0YWJs ZXMuYyB0eXRhYi5jDQoJZGVsIGltcGNudnRhYi5jDQoJbm1ha2UgLWZ3aW4zMi5t YWsgQz1iYWNrZW5kIFRLPXRrIFJPT1Q9cm9vdCBkbWQNCglubWFrZSAtZndpbjMy Lm1hayBDPWJhY2tlbmQgVEs9dGsgUk9PVD1yb290IE9QVD0tbyAiREVCVUc9IiBk bWQuZXhlDQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAg LWNwcCAtRF9ESCAgbWFycyAtQWUNCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRt XGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIICBlbnVtDQoJXGRtXGJpblxkbWMgLWMg LUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgc3RydWN0DQoJXGRt XGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAg ZHN5bWJvbA0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8g IC1jcHAgLURfREggIGltcG9ydA0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1c aW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGlkDQoJXGRtXGJpblxkbWMgLWMgLUly b290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgc3RhdGljYXNzZXJ0DQoJ XGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9E SCAgaWRlbnRpZmllcg0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVk ZSAgLW8gIC1jcHAgLURfREggIG10eXBlDQoJXGRtXGJpblxkbWMgLWMgLUlyb290 O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgZXhwcmVzc2lvbg0KCVxkbVxi aW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIG9w dGltaXplDQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAg LWNwcCAtRF9ESCAgdGVtcGxhdGUNCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRt XGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIICBsZXhlcg0KCVxkbVxiaW5cZG1jIC1j IC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGRlY2xhcmF0aW9u DQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAt RF9ESCAgY2FzdA0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAg LW8gIC1jcHAgLURfREggIGluaXQNCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRt XGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIICBmdW5jDQoJXGRtXGJpblxkbWMgLWMg LUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgdXRmDQoJXGRtXGJp blxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgdW5p YWxwaGENCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRtXGluY2x1ZGUgIC1vICAt Y3BwIC1EX0RIICBwYXJzZQ0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5j bHVkZSAgLW8gIC1jcHAgLURfREggIHN0YXRlbWVudA0KCVxkbVxiaW5cZG1jIC1j IC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGNvbnN0Zm9sZA0K CVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURf REggIHZlcnNpb24NCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRtXGluY2x1ZGUg IC1vICAtY3BwIC1EX0RIICBpbmlmaWxlDQoJXGRtXGJpblxkbWMgLWMgLUliYWNr ZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggLUlyb290IHR5cGluZg0K CVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURf REggLUliYWNrZW5kICBtb2R1bGUuYw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtc ZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIHNjb3BlDQoJXGRtXGJpblxkbWMg LWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgZHVtcA0KCVxk bVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREgg IGNvbmQNCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRtXGluY2x1ZGUgIC1vICAt Y3BwIC1EX0RIICBpbmxpbmUNCglcZG1cYmluXGRtYyAtYyAtSXJvb3Q7XGRtXGlu Y2x1ZGUgIC1vICAtY3BwIC1EX0RIICBvcG92ZXINCglcZG1cYmluXGRtYyAtYyAt SXJvb3Q7XGRtXGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIICBlbnRpdHkNCglcZG1c YmluXGRtYyAtYyAtSXJvb3Q7XGRtXGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIICBj bGFzcw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1j cHAgLURfREggIG1hbmdsZQ0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5j bHVkZSAgLW8gIC1jcHAgLURfREggIGF0dHJpYg0KCVxkbVxiaW5cZG1jIC1Jcm9v dCAtY3BwIGltcGNudmdlbg0KbGluayBpbXBjbnZnZW4sLCx1c2VyMzIra2VybmVs MzIvbm9pOw0KDQoJaW1wY252Z2VuDQoJXGRtXGJpblxkbWMgLWMgLUlyb290IC1j cHAgaW1wY252dGFiDQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRl ICAtbyAgLWNwcCAtRF9ESCAgbGluaw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtc ZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGFjY2Vzcw0KCVxkbVxiaW5cZG1j IC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGRvYw0KCVxk bVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREgg IG1hY3JvDQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAg LWNwcCAtRF9ESCAgaGRyZ2VuDQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxp bmNsdWRlICAtbyAgLWNwcCAtRF9ESCAgZGVsZWdhdGl6ZQ0KCVxkbVxiaW5cZG1j IC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGludGVycHJl dA0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAg LURfREggIHRyYWl0cw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVk ZSAgLW8gIC1jcHAgLURfREggIGJ1aWx0aW4NCglcZG1cYmluXGRtYyAtYyAtSXJv b3Q7XGRtXGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIICBjbG9uZQ0KCVxkbVxiaW5c ZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggIGxpYm9t Zg0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8gIC1jcHAg LURfREggIGFycmF5b3ANCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURN QVJTIC1jcHAgIC1lIC13eCAtRF9ESCBpcnN0YXRlDQoJXGRtXGJpblxkbWMgLWMg LUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggLUlyb290IGds dWUNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1l IC13eCAtRF9ESCBtc2MNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURN QVJTIC1jcHAgIC1lIC13eCAtRF9ESCBwaA0KCVxkbVxiaW5cZG1jIC1jIC1JYmFj a2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIHRrLmMNCglcZG1cYmlu XGRtYyAtYyAtSXJvb3QgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3gg LURfREggczJpcg0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdCAtSWJhY2tlbmQ7dGsg LURNQVJTIC1jcHAgIC1lIC13eCAtRF9ESCB0b2R0DQoJXGRtXGJpblxkbWMgLWMg LUlyb290IC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGUy aXINCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1l IC13eCAtRF9ESCAtSXJvb3QgdG9jc3ltDQoJXGRtXGJpblxkbWMgLWMgLUliYWNr ZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggdXRpbA0KCVxkbVxiaW5c ZG1jIC1jIC1Jcm9vdCAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1lIC13eCAt RF9ESCBiaXQNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1j cHAgIC1lIC13eCAtRF9ESCBlaA0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0 ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIC1Jcm9vdCB0b29iag0KCVxkbVxi aW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RI IC1Jcm9vdCB0b2N0eXBlDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1E TUFSUyAtY3BwICAtZSAtd3ggLURfREggLUlyb290IHRvY3ZkZWJ1Zw0KCVxkbVxi aW5cZG1jIC1jIC1Jcm9vdCAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1lIC13 eCAtRF9ESCB0b2lyDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFS UyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxnbw0KCVxkbVxiaW5cZG1jIC1j IC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRc Z2RhZw0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAg LWUgLXd4IC1EX0RIIGJhY2tlbmRcZ290aGVyDQoJXGRtXGJpblxkbWMgLWMgLUli YWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxnZmxv dw0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUg LXd4IC1EX0RIIGJhY2tlbmRcZ2xvb3ANCglzYyAtY3BwIC1vb3B0YWJnZW4uZXhl IGJhY2tlbmRcb3B0YWJnZW4gLURNQVJTIC1JdGsgDQpsaW5rIG9wdGFiZ2VuLG9w dGFiZ2VuLmV4ZSwsdXNlcjMyK2tlcm5lbDMyL25vaTsNCg0KCW9wdGFiZ2VuDQpP UFRBQkdFTi4uLiBnZW5lcmF0aW5nIGZpbGVzDQoJXGRtXGJpblxkbWMgLWMgLUli YWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggLUkuIGJhY2tlbmRc dmFyDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAt ZSAtd3ggLURfREggYmFja2VuZFxlbA0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2Vu ZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRcbmV3bWFuDQoJ XGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3gg LURfREggYmFja2VuZFxnbG9jYWwNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7 dGsgLURNQVJTIC1jcHAgIC1lIC13eCAtRF9ESCBiYWNrZW5kXG9zDQoJXGRtXGJp blxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREgg YmFja2VuZFxudGVoDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFS UyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxldmFsdTgNCglcZG1cYmluXGRt YyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1lIC13eCAtRF9ESCBiYWNr ZW5kXGNnY3MNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1j cHAgIC1lIC13eCAtRF9ESCBiYWNrZW5kXHJ0bHN5bQ0KCVxkbVxiaW5cZG1jIC1j IC1Jcm9vdCAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1lIC13eCAtRF9ESCBi YWNrZW5kXGh0bWwNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJT IC1jcHAgIC1lIC13eCAtRF9ESCAtSS4gYmFja2VuZFxjZ2VsZW0NCglcZG1cYmlu XGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1lIC13eCAtRF9ESCBi YWNrZW5kXGNnZW4NCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJT IC1jcHAgIC1lIC13eCAtRF9ESCBiYWNrZW5kXGNncmVnDQoJXGRtXGJpblxkbWMg LWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFja2Vu ZFxvdXQNCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAg IC1lIC13eCAtRF9ESCBiYWNrZW5kXGJsb2Nrb3B0DQoJXGRtXGJpblxkbWMgLWMg LUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxj Z29iag0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAg LWUgLXd4IC1EX0RIIC1JLiBiYWNrZW5kXGNnDQoJXGRtXGJpblxkbWMgLWMgLUli YWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxjZ2N2 DQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAt d3ggLURfREggYmFja2VuZFx0eXBlDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5k O3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxkdA0KCVxkbVxi aW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RI IC1JLiBiYWNrZW5kXGRlYnVnDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3Rr IC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxjb2RlDQoJXGRtXGJp blxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREgg YmFja2VuZFxjZzg3DQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFS UyAtY3BwICAtZSAtd3ggLURfREggYmFja2VuZFxjZ3NjaGVkDQoJXGRtXGJpblxk bWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggYmFj a2VuZFxlZQ0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNw cCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRcc3ltYm9sIC1vY3N5bWJvbC5vYmoNCglc ZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1lIC13eCAt RF9ESCAtSS4gYmFja2VuZFxjZ2NvZA0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2Vu ZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRcY29kMQ0KCVxk bVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1E X0RIIGJhY2tlbmRcY29kMg0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAt RE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRcY29kMw0KCVxkbVxiaW5c ZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJh Y2tlbmRcY29kNA0KCVxkbVxiaW5cZG1jIC1jIC1JYmFja2VuZDt0ayAtRE1BUlMg LWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRcY29kNQ0KCVxkbVxiaW5cZG1jIC1j IC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRc b3V0YnVmDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3Bw ICAtZSAtd3ggLURfREggYmFja2VuZFxiY29tcGxleA0KCVxkbVxiaW5cZG1jIC1j IC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIC1Jcm9vdCBp YXNtDQoJXGRtXGJpblxkbWMgLWMgLUliYWNrZW5kO3RrIC1ETUFSUyAtY3BwICAt ZSAtd3ggLURfREggYmFja2VuZFxwdHJudGFiDQoJXGRtXGJpblxkbWMgLWMgLUli YWNrZW5kO3RrIC1ETUFSUyAtY3BwICAtZSAtd3ggLURfREggLUkuIGJhY2tlbmRc YWENCglcZG1cYmluXGRtYyAtYyAtSWJhY2tlbmQ7dGsgLURNQVJTIC1jcHAgIC1l IC13eCAtRF9ESCAtSS4gYmFja2VuZFx0aV9hY2hhcg0KCVxkbVxiaW5cZG1jIC1j IC1JYmFja2VuZDt0ayAtRE1BUlMgLWNwcCAgLWUgLXd4IC1EX0RIIGJhY2tlbmRc bWQ1DQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNw cCAtRF9ESCByb290XGxzdHJpbmcuYw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtc ZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggcm9vdFxhcnJheS5jDQoJXGRtXGJp blxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9ESCByb290 XGdudWMuYw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtcZG1caW5jbHVkZSAgLW8g IC1jcHAgLURfREggcm9vdFxtYW4uYw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtc ZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggcm9vdFxybWVtLmMNCglcZG1cYmlu XGRtYyAtYyAtSXJvb3Q7XGRtXGluY2x1ZGUgIC1vICAtY3BwIC1EX0RIIHJvb3Rc cG9ydC5jDQoJXGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAg LWNwcCAtRF9ESCByb290XHJvb3QuYw0KCVxkbVxiaW5cZG1jIC1jIC1Jcm9vdDtc ZG1caW5jbHVkZSAgLW8gIC1jcHAgLURfREggcm9vdFxzdHJpbmd0YWJsZS5jDQoJ XGRtXGJpblxkbWMgLWMgLUlyb290O1xkbVxpbmNsdWRlICAtbyAgLWNwcCAtRF9E SCByb290XGRjaGFyLmMNCglzYyAtb2RtZC5leGUgbWFycy5vYmogZW51bS5vYmog c3RydWN0Lm9iaiBkc3ltYm9sLm9iaiBpbXBvcnQub2JqIGlkLm9iaiAgc3RhdGlj YXNzZXJ0Lm9iaiBpZGVudGlmaWVyLm9iaiBtdHlwZS5vYmogZXhwcmVzc2lvbi5v YmogIG9wdGltaXplLm9iaiB0ZW1wbGF0ZS5vYmogbGV4ZXIub2JqIGRlY2xhcmF0 aW9uLm9iaiBjYXN0Lm9iaiAgaW5pdC5vYmogZnVuYy5vYmogdXRmLm9iaiB1bmlh bHBoYS5vYmogcGFyc2Uub2JqIHN0YXRlbWVudC5vYmogIGNvbnN0Zm9sZC5vYmog dmVyc2lvbi5vYmogaW5pZmlsZS5vYmogdHlwaW5mLm9iaiAgbW9kdWxlLm9iaiBz Y29wZS5vYmogZHVtcC5vYmogY29uZC5vYmogaW5saW5lLm9iaiBvcG92ZXIub2Jq ICBlbnRpdHkub2JqIGNsYXNzLm9iaiBtYW5nbGUub2JqIGF0dHJpYi5vYmogaW1w Y252dGFiLm9iaiAgbGluay5vYmogYWNjZXNzLm9iaiBkb2Mub2JqIG1hY3JvLm9i aiBoZHJnZW4ub2JqIGRlbGVnYXRpemUub2JqICBpbnRlcnByZXQub2JqIHRyYWl0 cy5vYmogIGJ1aWx0aW4ub2JqIGNsb25lLm9iaiBsaWJvbWYub2JqIGFycmF5b3Au b2JqIGlyc3RhdGUub2JqICBnbHVlLm9iaiBtc2Mub2JqIHBoLm9iaiB0ay5vYmog czJpci5vYmogdG9kdC5vYmogZTJpci5vYmogdG9jc3ltLm9iaiAgdXRpbC5vYmog Yml0Lm9iaiBlaC5vYmogdG9vYmoub2JqIHRvY3R5cGUub2JqIHRvY3ZkZWJ1Zy5v YmogdG9pci5vYmogZ28ub2JqIGdkYWcub2JqIGdvdGhlci5vYmogZ2Zsb3cub2Jq IGdsb29wLm9iaiB2YXIub2JqIGVsLm9iaiAgbmV3bWFuLm9iaiBnbG9jYWwub2Jq IG9zLm9iaiBudGVoLm9iaiBldmFsdTgub2JqIGNnY3Mub2JqICBydGxzeW0ub2Jq IGh0bWwub2JqIGNnZWxlbS5vYmogY2dlbi5vYmogY2dyZWcub2JqIG91dC5vYmog IGJsb2Nrb3B0Lm9iaiBjZ29iai5vYmogY2cub2JqIGNnY3Yub2JqIHR5cGUub2Jq IGR0Lm9iaiAgZGVidWcub2JqIGNvZGUub2JqIGNnODcub2JqIGNnc2NoZWQub2Jq IGVlLm9iaiBjc3ltYm9sLm9iaiAgY2djb2Qub2JqIGNvZDEub2JqIGNvZDIub2Jq IGNvZDMub2JqIGNvZDQub2JqIGNvZDUub2JqIG91dGJ1Zi5vYmogIGJjb21wbGV4 Lm9iaiBpYXNtLm9iaiBwdHJudGFiLm9iaiBhYS5vYmogdGlfYWNoYXIub2JqIG1k NS5vYmogbHN0cmluZy5vYmogYXJyYXkub2JqIGdudWMub2JqIG1hbi5vYmogcm1l bS5vYmogcG9ydC5vYmogcm9vdC5vYmogIHN0cmluZ3RhYmxlLm9iaiBkY2hhci5v YmogLWNwcCAtbW4gLUFyIA0KbGluayBtYXJzK2VudW0rc3RydWN0K2RzeW1ib2wr aW1wb3J0K2lkK3N0YXRpY2Fzc2VydCtpZGVudGlmaWVyK210eXBlK2V4cHJlc3Np b24rb3B0aW1pemUrdGVtcGxhdGUrbGV4ZXIrZGVjbGFyYXRpb24rY2FzdCtpbml0 K2Z1bmMrdXRmK3VuaWFscGhhK3BhcnNlK3N0YXRlbWVudCtjb25zdGZvbGQrdmVy c2lvbitpbmlmaWxlK3R5cGluZittb2R1bGUrc2NvcGUrZHVtcCtjb25kK2lubGlu ZStvcG92ZXIrZW50aXR5K2NsYXNzK21hbmdsZSthdHRyaWIraW1wY252dGFiK2xp bmsrYWNjZXNzK2RvYyttYWNybytoZHJnZW4rZGVsZWdhdGl6ZStpbnRlcnByZXQr dHJhaXRzK2J1aWx0aW4rY2xvbmUrbGlib21mK2FycmF5b3AraXJzdGF0ZStnbHVl K21zYytwaCt0aytzMmlyK3RvZHQrZTJpcit0b2NzeW0rdXRpbCtiaXQrZWgrdG9v YmordG9jdHlwZSt0b2N2ZGVidWcrdG9pcitnbytnZGFnK2dvdGhlcitnZmxvdytn bG9vcCt2YXIrZWwrbmV3bWFuK2dsb2NhbCtvcytudGVoK2V2YWx1OCtjZ2NzK3J0 bHN5bStodG1sK2NnZWxlbStjZ2VuK2NncmVnK291dCtibG9ja29wdCtjZ29iaitj ZytjZ2N2K3R5cGUrZHQrZGVidWcrY29kZStjZzg3K2Nnc2NoZWQrZWUrY3N5bWJv bCtjZ2NvZCtjb2QxK2NvZDIrY29kMytjb2Q0K2NvZDUrb3V0YnVmK2Jjb21wbGV4 K2lhc20rcHRybnRhYithYSt0aV9hY2hhcittZDUrbHN0cmluZythcnJheStnbnVj K21hbitybWVtK3BvcnQrcm9vdCtzdHJpbmd0YWJsZStkY2hhcixkbWQuZXhlLCx1 c2VyMzIra2VybmVsMzIvbm9pOw0KDQoJbm1ha2UgLWZ3aW4zMi5tYWsgQz1iYWNr ZW5kIFRLPXRrIFJPT1Q9cm9vdCBjbGVhbg0KCWRlbCAqLm9iag0KCWRlbCB0b3Rh bC5zeW0NCglkZWwgbXNncy5oIG1zZ3MuYw0KCWRlbCBlbHh4eC5jIGNkeHh4LmMg b3B0YWIuYyBkZWJ0YWIuYyBmbHRhYmxlcy5jIHR5dGFiLmMNCglkZWwgaW1wY252 dGFiLmMNCg== ------------zWYzISqI0TB6UaUJtxZveh--
Mar 05 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 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
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?

...And is it related to the fix of issue #2582 (Significantly Increased 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 next sibling parent 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
prev sibling 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 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 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
next sibling parent "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
prev sibling 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=

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