On Tuesday, 15 October 2013 at 06:38:22 UTC, Nick Sabalausky
wrote:
On Mon, 14 Oct 2013 16:19:23 +0200
Andrej Mitrovic wrote:
On 10/14/13, Nick Sabalausky
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 in
On Mon, 14 Oct 2013 16:19:23 +0200
Andrej Mitrovic wrote:
> On 10/14/13, Nick Sabalausky
> 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.
Gith
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. Eve
On 10/14/13, Nick Sabalausky 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.
On Mon, 14 Oct 2013 11:09:54 +0200
Benjamin Thaut 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 bina
Am 14.10.2013 13:30, schrieb Nick Sabalausky:
On Mon, 14 Oct 2013 11:09:54 +0200
Benjamin Thaut 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 .git
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 fac
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\d
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
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 ide
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 co
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 m
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 additio
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 Tha
14 matches
Mail list logo
