yeha :-) +1
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
On Tuesday, 14 August 2012 at 14:41:20 UTC, F i L wrote:
[...]
Then we'll need to write software simple enough to enjoy
micro-managing that software to keep it on task.
Can I get it for the offshoring projects I work on? :)
On 2012-08-14 23:05, Walter Bright wrote:
It does pass them correctly to D functions, just not to C ones if the
struct contains a mix of floating and integer types.
Ok, so if my structs don't contain any floating point types I will be
fine? All other types are ok? Is this in the 2.060
On Wednesday, 15 August 2012 at 10:28:15 UTC, Jacob Carlborg
wrote:
On 2012-08-14 23:05, Walter Bright wrote:
It does pass them correctly to D functions, just not to C ones
if the
struct contains a mix of floating and integer types.
Ok, so if my structs don't contain any floating point
On Wednesday, 15 August 2012 at 11:15:35 UTC, Paulo Pinto wrote:
Does this not required that the D and C compiler are in sync
about data layout?
Small sizes structs are often kept in registers.
Yes, extern(C) is intended to be fully ABI-compatible with the
respective C ABI on the host
On 8/15/2012 3:28 AM, Jacob Carlborg wrote:
On 2012-08-14 23:05, Walter Bright wrote:
It does pass them correctly to D functions, just not to C ones if the
struct contains a mix of floating and integer types.
Ok, so if my structs don't contain any floating point types I will be fine?
Yes.
On 2012-08-15 21:48, Walter Bright wrote:
Ok, so if my structs don't contain any floating point types I will be
fine?
Yes.
All other types are ok?
Yes.
Is this in the 2.060 release
Yes.
or do I have get the latest sources from github?
No.
Thank you.
--
/Jacob Carlborg
On 8/14/2012 2:44 AM, Bernard Helyer wrote:
Clearly the solution is to look into cloning technologies.
There can be only one.
On Monday, 13 August 2012 at 22:07:51 UTC, Alex Rønne Petersen
wrote:
On 13-08-2012 23:58, Andrej Mitrovic wrote:
On 8/13/12, Walter Bright newshou...@digitalmars.com wrote:
I've thought many times about adding a D feature that allows
one to specify
use
this random character string instead of
On 14-08-2012 09:25, Paulo Pinto wrote:
On Monday, 13 August 2012 at 22:07:51 UTC, Alex Rønne Petersen wrote:
On 13-08-2012 23:58, Andrej Mitrovic wrote:
On 8/13/12, Walter Bright newshou...@digitalmars.com wrote:
I've thought many times about adding a D feature that allows one to
specify
use
On 8/13/2012 4:05 PM, Nick Sabalausky wrote:
Well, not *exactly* the same boat. I always, perhaps mistakenly, assumed
the OMF issue would eventually get addressed. To see it pretty much
verified that it *won't* be happening is very discouraging and
frustrating. The existence of GDC and LDC
On Tuesday, 14 August 2012 at 08:28:45 UTC, Walter Bright wrote:
On 8/13/2012 4:05 PM, Nick Sabalausky wrote:
Well, not *exactly* the same boat. I always, perhaps
mistakenly, assumed
the OMF issue would eventually get addressed. To see it pretty
much
verified that it *won't* be happening is
Alex Rønne Petersen a...@lycus.org wrote in message
news:k0bs29$1bpl$1...@digitalmars.com...
On 13-08-2012 23:34, Walter Bright wrote:
On 8/13/2012 12:41 PM, Sean Kelly wrote:
I've thought many times about adding a D feature that allows one to
specify use this random character string instead
On 13-08-2012 23:43, Walter Bright wrote:
On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote:
I've wanted a feature like that on several occasions (mostly when
interfacing
with non-C/C++ languages). How hard it would it be to implement?
Theoretically,
it sounds simple enough.
You could do it
On 2012-08-13 20:29, Walter Bright wrote:
True, but consider that dmd is a 64 bit app, and nobody either complains
about it or notices, and dmd by default produces a 64 bit app, and as
far as I can tell, nobody has noticed that either.
I was agreeing with you :) One thing that we do notice is
Bernard Helyer wrote:
Clearly the solution is to look into cloning technologies.
Nah, we just need to write a software sophisticated enough that
it can write software itself.
Then we'll need to write software simple enough to enjoy
micro-managing that software to keep it on task.
On 14-08-2012 14:00, Daniel Murphy wrote:
Alex Rønne Petersen a...@lycus.org wrote in message
news:k0bs29$1bpl$1...@digitalmars.com...
On 13-08-2012 23:34, Walter Bright wrote:
On 8/13/2012 12:41 PM, Sean Kelly wrote:
I've thought many times about adding a D feature that allows one to
specify
On Tue, 14 Aug 2012 11:44:43 +0200, Bernard Helyer b.hel...@gmail.com
wrote:
On Tuesday, 14 August 2012 at 08:28:45 UTC, Walter Bright wrote:
On 8/13/2012 4:05 PM, Nick Sabalausky wrote:
Well, not *exactly* the same boat. I always, perhaps mistakenly,
assumed
the OMF issue would
On 8/14/2012 7:30 AM, Jacob Carlborg wrote:
I was agreeing with you :) One thing that we do notice is when interfacing with
C libraries. I'm thinking of the bug where DMD doesn't pass structs correctly on
64bit. What's the status of that BTW?
It does pass them correctly to D functions, just
On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
Even still, it's a far cry to compare ditching 16-bit with
(effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
important, and yes, 32-bit is becoming less and less important, but I
still think you're very much jumping the gun here.
On Sunday, August 12, 2012 23:21:48 Walter Bright wrote:
On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
Even still, it's a far cry to compare ditching 16-bit with
(effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
important, and yes, 32-bit is becoming less and less
On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote:
[…]
OSX has a lot less backwards compatibility to worry about.
Not entirely true.
semi-rant
Apple's strategy appears to be that computers are non-upgradable,
non-repairable, disposable items that last until the next release:
everyone is
On Sun, 12 Aug 2012 23:21:48 -0700
Walter Bright newshou...@digitalmars.com wrote:
On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
Even still, it's a far cry to compare ditching 16-bit with
(effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
important, and yes, 32-bit is
On Monday, 13 August 2012 at 01:18:14 UTC, Sean Cavanaugh wrote:
On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
On 8/13/12, Sean Cavanaughworksonmymach...@gmail.com wrote:
we had to modify the code
Sure enough I've found your name:
On Monday, 13 August 2012 at 07:05:11 UTC, Russel Winder wrote:
On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote:
[…]
OSX has a lot less backwards compatibility to worry about.
Not entirely true.
semi-rant
Apple's strategy appears to be that computers are
non-upgradable,
On 8/12/2012 11:29 PM, Jonathan M Davis wrote:
On Sunday, August 12, 2012 23:21:48 Walter Bright wrote:
On 8/12/2012 10:50 PM, Nick Sabalausky wrote:
Even still, it's a far cry to compare ditching 16-bit with
(effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more
important, and
On Monday, 13 August 2012 at 09:52:05 UTC, Walter Bright wrote:
64 bits is far more important. We don't have arrows for every
target, we have to pick the juiciest ones.
Does that mean that we get x64 support on Windows (without legacy
OMF support)? Linking with MSVC-produced libraries will
On 2012-08-13 08:21, Walter Bright wrote:
We'll see. It has already happened on OSX.
The good think on Mac OS X is that basically all system libraries are
universal binaries (both 32 and 64bit) meaning it really doesn't matter
for the user if an application is 32 or 64bit.
BTW, around
On 2012-08-13 09:04, Russel Winder wrote:
semi-rant
Apple's strategy appears to be that computers are non-upgradable,
non-repairable, disposable items that last until the next release:
everyone is supposed buy the latest version as soon as it comes out and
so be on the latest kit(*).
But
On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote:
It's not the current plan. Frankly, I think 32 bits is rapidly
becoming irrelevant on the desktop.
Bullshit.
While I agree with the sentiment (in fact, one of my newest
computers
is 32 bit; I got a mini laptop - not quite
On Monday, August 13, 2012 02:51:30 Walter Bright wrote:
64 bits is far more important. We don't have arrows for every target, we
have to pick the juiciest ones.
I have no idea how much mork work it is to add 32-bit COFF on top of adding
64-bit COFF, and I'm totally fine with just targeting
On 8/13/2012 3:55 AM, d_follower wrote:
Does that mean that we get x64 support on Windows (without legacy OMF support)?
Linking with MSVC-produced libraries will work, too?
Yes.
On 8/13/2012 6:23 AM, Jacob Carlborg wrote:
On 2012-08-13 08:21, Walter Bright wrote:
We'll see. It has already happened on OSX.
The good think on Mac OS X is that basically all system libraries are universal
binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an
On Aug 13, 2012, at 12:04 AM, Russel Winder rus...@winder.org.uk wrote:
On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote:
[…]
OSX has a lot less backwards compatibility to worry about.
Not entirely true.
semi-rant
Apple's strategy appears to be that computers are
On Monday, 13 August 2012 at 18:29:13 UTC, Walter Bright wrote:
On 8/13/2012 6:23 AM, Jacob Carlborg wrote:
On 2012-08-13 08:21, Walter Bright wrote:
We'll see. It has already happened on OSX.
The good think on Mac OS X is that basically all system
libraries are universal
binaries (both 32
On 8/13/2012 12:41 PM, Sean Kelly wrote:
Strangely,libc on OSX is very backwards-compatible. To the point where buggy
functions were preserved as-is and updated versions exported via weird labels
linked by the compiler using some evil macro code. Needless to say, D
unfortunalely links to the
On 13-08-2012 23:34, Walter Bright wrote:
On 8/13/2012 12:41 PM, Sean Kelly wrote:
Strangely,libc on OSX is very backwards-compatible. To the point where
buggy
functions were preserved as-is and updated versions exported via weird
labels
linked by the compiler using some evil macro code.
On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote:
I've wanted a feature like that on several occasions (mostly when interfacing
with non-C/C++ languages). How hard it would it be to implement? Theoretically,
it sounds simple enough.
You could do it with a pragma or something. It's always going
On 8/13/12, Walter Bright newshou...@digitalmars.com wrote:
I've thought many times about adding a D feature that allows one to specify
use
this random character string instead of the identifier as the symbol name
when
writing the object file, but never got around to it.
Isn't that what .def
No doubt that COFF 64 bits it are good and with high priority,
though small, but support of COFF 32 bits will be a gift that
will add popularity to dmd. Anyway I have words that add + to 64
bit and to 32 bit tools that supports linking with ms toolset.
On 13-08-2012 23:58, Andrej Mitrovic wrote:
On 8/13/12, Walter Bright newshou...@digitalmars.com wrote:
I've thought many times about adding a D feature that allows one to specify
use
this random character string instead of the identifier as the symbol name
when
writing the object file, but
On 8/14/12, Alex Rønne Petersen a...@lycus.org wrote:
That's a Windows-ism.
I think it's technically a linker-ism. Surely LD supports a similar feature?
On Mon, 13 Aug 2012 11:23:09 +0200
Paulo Pinto pj...@progtools.org wrote:
On Monday, 13 August 2012 at 01:18:14 UTC, Sean Cavanaugh wrote:
On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
On 8/13/12, Sean Cavanaughworksonmymach...@gmail.com wrote:
we had to modify the code
Sure enough
On Mon, 13 Aug 2012 15:42:19 +0200
Adam D. Ruppe destructiona...@gmail.com wrote:
On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote:
It's not the current plan. Frankly, I think 32 bits is rapidly
becoming irrelevant on the desktop.
Bullshit.
While I agree with the
On Mon, 13 Aug 2012 11:25:29 +0200
Paulo Pinto pj...@progtools.org wrote:
On Monday, 13 August 2012 at 07:05:11 UTC, Russel Winder wrote:
Apple's strategy appears to be that computers are
non-upgradable,
non-repairable, disposable items that last until the next
release:
It is this
Al 12/08/12 06:18, En/na Walter Bright ha escrit:
On 8/11/2012 8:29 PM, 拖狗散步 wrote:
Walter Bright They say you're an old man, I think your avatar is really so
young?
Every night, I drink the blood of unborn children.
Now I understand many many things... :-)
--
Jordi Sayol
On 11-08-2012 10:16, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
On Sat, 11 Aug 2012 10:16:37 +0200, Walter Bright
newshou...@digitalmars.com wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
On 8/12/2012 1:38 AM, Alex Rønne Petersen wrote:
One question: Will the 32-bit tool chain also be able to use the MSVC runtime
and linker eventually?
It's not the current plan. Frankly, I think 32 bits is rapidly becoming
irrelevant on the desktop.
On 8/12/2012 4:12 PM, Walter Bright wrote:
On 8/12/2012 1:38 AM, Alex Rønne Petersen wrote:
One question: Will the 32-bit tool chain also be able to use the MSVC
runtime
and linker eventually?
It's not the current plan. Frankly, I think 32 bits is rapidly becoming
irrelevant on the desktop.
On 12.08.2012 23:21, Sean Cavanaugh wrote:
Post windows 8 launch we should start seeing mainstream games shipping
32 and 64 bit binaries together in the same box. We already have moved
off of 32 bit in house for our editors and tools. The biggest hangup is
Microsoft keeps shipping 32 bit
On 8/12/2012 6:43 PM, torhu wrote:
On 12.08.2012 23:21, Sean Cavanaugh wrote:
Post windows 8 launch we should start seeing mainstream games shipping
32 and 64 bit binaries together in the same box. We already have moved
off of 32 bit in house for our editors and tools. The biggest hangup is
On 8/13/12, Sean Cavanaugh worksonmymach...@gmail.com wrote:
we had to modify the code
Sure enough I've found your name:
http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx
I noticed you before here but never realized you worked on Halo. It's
cool to see people of your caliber
On 8/12/2012 8:15 PM, Andrej Mitrovic wrote:
On 8/13/12, Sean Cavanaughworksonmymach...@gmail.com wrote:
we had to modify the code
Sure enough I've found your name:
http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx
I noticed you before here but never realized you worked on
On 13.08.2012 02:59, Sean Cavanaugh wrote:
On 8/12/2012 6:43 PM, torhu wrote:
On 12.08.2012 23:21, Sean Cavanaugh wrote:
Post windows 8 launch we should start seeing mainstream games shipping
32 and 64 bit binaries together in the same box. We already have moved
off of 32 bit in house for our
On 8/12/2012 8:22 PM, torhu wrote:
Ok, so using LARGEADDRESSAWARE doesn't improve the situation on XP 64?
What about on Vista 64?
On XP64 it would help some, but the video adapter is still mapped to a
huge contiguous range due to the XP driver model. Basically you get 1
extra GB (2.3GB
On Sun, 12 Aug 2012 14:12:43 -0700
Walter Bright newshou...@digitalmars.com wrote:
On 8/12/2012 1:38 AM, Alex Rønne Petersen wrote:
One question: Will the 32-bit tool chain also be able to use the
MSVC runtime and linker eventually?
It's not the current plan. Frankly, I think 32 bits is
On 8/12/2012 9:44 PM, Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote:
Frankly, I think 32 bits is rapidly
becoming irrelevant on the desktop.
Bullshit. There will always be plenty of things that don't need 64-bits
and/or will only incur unnecessary bloat with 64-bit.
On Sun, 12 Aug 2012 21:54:07 -0700
Walter Bright newshou...@digitalmars.com wrote:
On 8/12/2012 9:44 PM, Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote:
Frankly, I think 32 bits is rapidly
becoming irrelevant on the desktop.
Bullshit. There will always be plenty
On 8/11/12 10:16 , Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
Am 11.08.2012 10:16, schrieb Walter Bright:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
dmd -c -m64 hello.d
cl hello.obj
hello
hello world!
Yeehaa! Best news of the last years and even two news that is
:-)
+1
Cool1
No, it ain't much, some of it is jury rigged, and there's a heluva lot more work
to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
-
dmd -c -m64
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
On Saturday, 11 August 2012 at 14:04:39 UTC, 拖狗散步 wrote:
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright
wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import
On 8/11/12 4:16 AM, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
On 2012-08-11 10:16, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
On Sat, 11 Aug 2012 01:16:37 -0700, Walter Bright
newshou...@digitalmars.com wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
On 8/11/2012 6:28 PM, Adam Wilson wrote:
This is a glorious day indeed!
I see everyone likes this direction we're going. Great!
On Sunday, 12 August 2012 at 01:52:08 UTC, Walter Bright wrote:
On 8/11/2012 6:28 PM, Adam Wilson wrote:
This is a glorious day indeed!
I see everyone likes this direction we're going. Great!
Walter Bright They say you're an old man, I think your avatar is
really so young?
On 8/11/2012 8:29 PM, 拖狗散步 wrote:
Walter Bright They say you're an old man, I think your avatar is really so
young?
Every night, I drink the blood of unborn children.
On Sat, 11 Aug 2012 21:18:17 -0700, Walter Bright
newshou...@digitalmars.com wrote:
On 8/11/2012 8:29 PM, 拖狗散步 wrote:
Walter Bright They say you're an old man, I think your avatar is really
so young?
Every night, I drink the blood of unborn children.
Actively working at scaring them
76 matches
Mail list logo
