• Benjamin Thaut (6/6) Oct 13 2013 I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code
• Walter Bright (2/6) Oct 14 2013 Not aware of any such changes.
• Benjamin Thaut (13/21) Oct 14 2013 I actually found it. I havily use core.sys.windows.stacktrace in my code...
• Walter Bright (2/7) Oct 14 2013 It means it isn't a correct 32 bit object file.
• Benjamin Thaut (3/13) Oct 14 2013 And what could cause this? I already tried manually deleting everything
• Walter Bright (2/17) Oct 14 2013 I can't reproduce that error, and neither can the autotester.
• Benjamin Thaut (8/27) Oct 14 2013 I found it: src\rt\minit.obj is corrupt. When I copy the file from the
• Nick Sabalausky (16/24) Oct 14 2013 Automatic line ending conversions need to be nuked from existence.
• Benjamin Thaut (5/29) Oct 14 2013 Visual Studio requests CRLF file endings...
• Michal Minich (6/10) Oct 14 2013 Visual Studio (at least 2010) keeps whatever original CR / LF or
• Andrej Mitrovic (4/5) Oct 14 2013 There's your problem right there. I'd say a sane diff view would make
• Nick Sabalausky (10/17) Oct 14 2013 Github's entire web frontend is horrible. They don't even know how to
• PauloPinto (9/32) Oct 15 2013 Sadly that is the future. :(
• Benjamin Thaut (2/7) Oct 14 2013 https://github.com/D-Programming-Language/druntime/pull/638

Benjamin Thaut <code benjamin-thaut.de> writes:

I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code 
dmd 2.063.2 generates in debug mode is significantly slower then the 
code generated by dmd 2.062. Have there been changes to the debug mode 
that affect execution speed? Like additional debug checks?

Kind Regards
Benjamin Thaut

Walter Bright <newshound2 digitalmars.com> writes:

On 10/13/2013 11:29 PM, Benjamin Thaut wrote:
 I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd
 2.063.2 generates in debug mode is significantly slower then the code generated
 by dmd 2.062. Have there been changes to the debug mode that affect execution
 speed? Like additional debug checks?

Not aware of any such changes.

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 14.10.2013 09:09, schrieb Walter Bright:
 On 10/13/2013 11:29 PM, Benjamin Thaut wrote:
 I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd
 2.063.2 generates in debug mode is significantly slower then the code
 generated
 by dmd 2.062. Have there been changes to the debug mode that affect
 execution
 speed? Like additional debug checks?

 Not aware of any such changes.

I actually found it. I havily use core.sys.windows.stacktrace in my code 
and I did make some modifications on my druntime branch which I 
accidentially reverted when merging in druntime 2.063.2
These changes make stacktracing on windows faster by a factor of 10. 
Thats why I see such a performance impact with dmd 2.063

I'm currently preparing a pull request for this but I ran into an issue. 
When compiling the latest druntime with the latest dmd for windows 
32-bit I get the following error message:

lib\druntime.lib: Error: corrupt object module

On windows 64-bit everything works fine. Any ideas why this happens?

Kind Regards
Benjamin Thaut

Walter Bright <newshound2 digitalmars.com> writes:

On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
 When
 compiling the latest druntime with the latest dmd for windows 32-bit I get the
 following error message:

 lib\druntime.lib: Error: corrupt object module

 On windows 64-bit everything works fine. Any ideas why this happens?

It means it isn't a correct 32 bit object file.

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 14.10.2013 10:56, schrieb Walter Bright:
 On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
 When
 compiling the latest druntime with the latest dmd for windows 32-bit I
 get the
 following error message:

 lib\druntime.lib: Error: corrupt object module

 On windows 64-bit everything works fine. Any ideas why this happens?

 It means it isn't a correct 32 bit object file.

And what could cause this? I already tried manually deleting everything 
thats not checked into git. "make -f win32.mak clean" doesn't help either.

Walter Bright <newshound2 digitalmars.com> writes:

On 10/14/2013 1:57 AM, Benjamin Thaut wrote:
 Am 14.10.2013 10:56, schrieb Walter Bright:
 On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
 When
 compiling the latest druntime with the latest dmd for windows 32-bit I
 get the
 following error message:

 lib\druntime.lib: Error: corrupt object module

 On windows 64-bit everything works fine. Any ideas why this happens?

 It means it isn't a correct 32 bit object file.

 And what could cause this? I already tried manually deleting everything thats
 not checked into git. "make -f win32.mak clean" doesn't help either.

I can't reproduce that error, and neither can the autotester.

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 14.10.2013 11:01, schrieb Walter Bright:
 On 10/14/2013 1:57 AM, Benjamin Thaut wrote:
 Am 14.10.2013 10:56, schrieb Walter Bright:
 On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
 When
 compiling the latest druntime with the latest dmd for windows 32-bit I
 get the
 following error message:

 lib\druntime.lib: Error: corrupt object module

 On windows 64-bit everything works fine. Any ideas why this happens?

 It means it isn't a correct 32 bit object file.

 And what could cause this? I already tried manually deleting
 everything thats
 not checked into git. "make -f win32.mak clean" doesn't help either.

 I can't reproduce that error, and neither can the autotester.

I found it: src\rt\minit.obj is corrupt. When I copy the file from the 
2.064 beta package it builds sucessfully. Might have to do something 
with the line ending settings in git.

Maybe a .gitattributes file setting *.obj to binary should be added to 
the druntime repository to prevent issues like this.

Kind Regards
Benjamin Thaut

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 14 Oct 2013 11:09:54 +0200
Benjamin Thaut <code benjamin-thaut.de> wrote:
 
 I found it: src\rt\minit.obj is corrupt. When I copy the file from
 the 2.064 beta package it builds sucessfully. Might have to do
 something with the line ending settings in git.
 
 Maybe a .gitattributes file setting *.obj to binary should be added
 to the druntime repository to prevent issues like this.
 

Automatic line ending conversions need to be nuked from existence.
Git's EOL-conversion "feature" should never have existed in the first
place. I can only imagine it happened because some early Git developer
must have thought Windows was still stuck in 1991. Or maybe they
thought Windows developers write code in notepad.

*Any* Git installation that has any form of EOL-conversions enabled is
absolutely in error and will eventually just breed problems. And any
sane editor will respect the line endings of any file it opens, if it
doesn't it's a POS and needs to be fixed/replaced. So there should never
be any problem, and never be any need for any of Git's "helpful"
automatic data butchering.

(Same goes for FTP, but at least FTP has an excuse: It existed back
when there *was* such as thing as "Unix line endings" and "Windows line
endings".)

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 14.10.2013 13:30, schrieb Nick Sabalausky:
 On Mon, 14 Oct 2013 11:09:54 +0200
 Benjamin Thaut <code benjamin-thaut.de> wrote:
 I found it: src\rt\minit.obj is corrupt. When I copy the file from
 the 2.064 beta package it builds sucessfully. Might have to do
 something with the line ending settings in git.

 Maybe a .gitattributes file setting *.obj to binary should be added
 to the druntime repository to prevent issues like this.

 Automatic line ending conversions need to be nuked from existence.
 Git's EOL-conversion "feature" should never have existed in the first
 place. I can only imagine it happened because some early Git developer
 must have thought Windows was still stuck in 1991. Or maybe they
 thought Windows developers write code in notepad.

 *Any* Git installation that has any form of EOL-conversions enabled is
 absolutely in error and will eventually just breed problems. And any
 sane editor will respect the line endings of any file it opens, if it
 doesn't it's a POS and needs to be fixed/replaced. So there should never
 be any problem, and never be any need for any of Git's "helpful"
 automatic data butchering.

 (Same goes for FTP, but at least FTP has an excuse: It existed back
 when there *was* such as thing as "Unix line endings" and "Windows line
 endings".)

Visual Studio requests CRLF file endings...

But I fully agree CRLF should die.

Kind Regards
Benjamin Thaut

"Michal Minich" <michal.minich gmail.com> writes:

On Monday, 14 October 2013 at 11:34:06 UTC, Benjamin Thaut wrote:
 Visual Studio requests CRLF file endings...

 But I fully agree CRLF should die.

 Kind Regards
 Benjamin Thaut

Visual Studio (at least 2010) keeps whatever original CR / LF or 
CRLF line endings were in file when you opened it. Even warns you 
when file contains mixed line endings and keeps each line as it 
were. You can change/normalize them in men File/Advance Save 
Options.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 10/14/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:
 And any sane editor

There's your problem right there. I'd say a sane diff view would make
it obvious that CRLF or tabs were injected, and yet github's diff view
is a piece of ass.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 14 Oct 2013 16:19:23 +0200
Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 10/14/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>
 wrote:
 And any sane editor

 
 There's your problem right there. I'd say a sane diff view would make
 it obvious that CRLF or tabs were injected, and yet github's diff view
 is a piece of ass.

Github's entire web frontend is horrible. They don't even know how to
write a freaking web page:
http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers

(BUt really, I'm not sure there's an ajaxy site in the world that isn't
garbage. Ex:
http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmars-d puremagic.com
ie "For reference, that's considerably less than the chrome process
that hosts gmail (200mb!)")

"PauloPinto" <pjmlp progtools.org> writes:

On Tuesday, 15 October 2013 at 06:38:22 UTC, Nick Sabalausky 
wrote:
 On Mon, 14 Oct 2013 16:19:23 +0200
 Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 10/14/13, Nick Sabalausky 
 <SeeWebsiteToContactMe semitwist.com>
 wrote:
 And any sane editor

 
 There's your problem right there. I'd say a sane diff view 
 would make
 it obvious that CRLF or tabs were injected, and yet github's 
 diff view
 is a piece of ass.

 Github's entire web frontend is horrible. They don't even know 
 how to
 write a freaking web page:
 http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers

 (BUt really, I'm not sure there's an ajaxy site in the world 
 that isn't
 garbage. Ex:
 http://forum.dlang.org/post/mailman.1442.1379388733.1719.digitalmars-d puremagic.com
 ie "For reference, that's considerably less than the chrome 
 process
 that hosts gmail (200mb!)")

Sadly that is the future. :(

I am looking forward that native mobile applications kill these 
web applications trend, but I am in the minority.

And I do write web applications as well, so I do know both sides 
of the fence.

--
Paulo

Benjamin Thaut <code benjamin-thaut.de> writes:

Am 14.10.2013 09:24, schrieb Benjamin Thaut:
 I actually found it. I havily use core.sys.windows.stacktrace in my code
 and I did make some modifications on my druntime branch which I
 accidentially reverted when merging in druntime 2.063.2
 These changes make stacktracing on windows faster by a factor of 10.
 Thats why I see such a performance impact with dmd 2.063

https://github.com/D-Programming-Language/druntime/pull/638