Re: D overview on facepunch.com
On Sunday, 12 August 2012 at 12:04:05 UTC, Jakob Ovrum wrote: On Sunday, 12 August 2012 at 12:02:06 UTC, Andrei Alexandrescu wrote: http://facepunch.com/showthread.php?t=1204676&s=affb44baf90ed48786f63e20a6052df1&p=37188144#post37188144 Andrei I'm the OP. It's still a work in progress, some sections are super-thin and I need to put in more references since I don't explain most of the terms I introduce, and many of them are D-specific (e.g. scope statements). This was very good, at least much of the first items as I didn't get through everything.
Re: D overview on facepunch.com
On Sunday, 12 August 2012 at 12:04:05 UTC, Jakob Ovrum wrote:
On Sunday, 12 August 2012 at 12:02:06 UTC, Andrei Alexandrescu
wrote:
http://facepunch.com/showthread.php?t=1204676&s=affb44baf90ed48786f63e20a6052df1&p=37188144#post37188144
Andrei
I'm the OP.
It's still a work in progress, some sections are super-thin and
I need to put in more references since I don't explain most of
the terms I introduce, and many of them are D-specific (e.g.
scope statements).
You mention in the first post that you're unaware of any IDE for
Mac. MonoDevelop + MonoD is cross platform and works identical
(except for Debugging) on all three platforms.
Also, the way you have MonoD listed ("for Linux..."), it could be
confused as a Linux-Only IDE to a passer-by. I noticed later on a
person was comparing VisualD to VisualStudios-C#. Often, I've had
a much better time with MonoD over VisualD, and for those who
place a lot of importance on intelisense, MonoD has much more
comparable features to C# AtM.
I would recommend amending your MonoD listing to include a "Cross
Platform" label and emphasis on intelisense support *comparable*
to C#.
Mono-D's not all there yet, but it actually feels faster and less
buggy than Mono C#'s built-in intellisense. Project management
and refactoring support are also very complete.
That being said, D is a much more dynamic beast (syntactically)
than C#, so there's more than a few times code-completion simply
fails. Regardless, it's a great development environment and I
wouldn't recommend anything else :)
Re: OSX and 64-bit [Re: First working Win64 program!]
On Mon, 13 Aug 2012 11:25:29 +0200 "Paulo Pinto" 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 type of issues that keeps me away from Apple products. > Along with what I like to call "Orwellian Hipsterism". Or maybe "Orwell-Chic". A noxious combination of intolerably large doses of "trendiness" paired with Big Brother seeping out of every millimeter of the design. And then high prices on top of all that. The idea that Apple is the same company that put out that famous "1984" commercial would be laughable if it weren't so depressing.
Re: First working Win64 program!
On Mon, 13 Aug 2012 15:42:19 +0200 "Adam D. Ruppe" 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 sentiment (in fact, one of my newest > computers > is 32 bit; I got a mini laptop - not quite netbook, but not > regular > laptop either - that is 32 bit), it is worth noting that 32 bit > D isn't going away. > > We're going to be in the same boat we're in now, which does work. 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 doesn't solve the problem either.
Re: First working Win64 program!
On Mon, 13 Aug 2012 11:23:09 +0200 "Paulo Pinto" 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 Cavanaugh 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 having interest in D! :) > > > > I have a theory that game development accelerates the rate at > > which you learn to hate C++ > > On the other hand, you get to learn lots of stuff to write "Game > Programming Gems" chapters about. :) Good point! I mean, what would ever happen to that series if C++ died? They'd have to change it to "Game Programming...Umm...Filler Material...And Maybe a Small Gem or Two" ;) (It is a good series though.)
Re: OSX and 64-bit [Re: First working Win64 program!]
On 8/14/12, Alex Rønne Petersen wrote: > That's a Windows-ism. I think it's technically a linker-ism. Surely LD supports a similar feature?
Re: OSX and 64-bit [Re: First working Win64 program!]
On 13-08-2012 23:58, Andrej Mitrovic wrote: On 8/13/12, Walter Bright 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 files are for? Or maybe this is only used for DLLs? That's a Windows-ism. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
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.
Re: OSX and 64-bit [Re: First working Win64 program!]
On 8/13/12, Walter Bright 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 files are for? Or maybe this is only used for DLLs?
Re: OSX and 64-bit [Re: First working Win64 program!]
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 to look ugly, though.
Re: OSX and 64-bit [Re: First working Win64 program!]
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. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler. An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. 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. 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. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
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 buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler. An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. 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.
Re: First working Win64 program!
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 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. 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 noticed! But it hasn't been a problem. One of the things I've actually been using D for is writing simple tools for work, to be executed while in livedisc environments (diagnostics and the like), so I have to keep both 32b and 64b versions of everything, and the only missing component was 64b for Windows. So yeah, I'm pretty stoked about this.
Re: OSX and 64-bit [Re: First working Win64 program!]
On Aug 13, 2012, at 12:04 AM, 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. > > > 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(*). Therefore Apple don't care about backward > compatibility in the way some other manufacturers do, e.g. JDK for the > last 17 years. Of course sometimes this backfires, cf. many white > MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects > this and will not boot 64-bit. This leads to extraordinary problems > trying to compile some codes where the compiler detects 64-bit processor > and assumes a 64-bit kernel API. To build some applications I first have > to build the whole compiler toolchain so as to deal with this mixed > chaos. > > (*) And as we know there are a lot of people who actually do this, which > is why there is a great market in second hand Apple kit, which is fine > for me, since it is reasonable kit at a reasonable price. Unlike new > kit. > 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 buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler.
Re: First working Win64 program!
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 application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. 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.
Re: First working Win64 program!
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.
Re: First working Win64 program!
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 64-bit COFF for now. I'm just pointing out that there's a definite cost to not having 32-bit COFF support on Windows, whereas your posts seem to imply that you don't think that it's important at all. - Jonathan M Davis
Re: First working Win64 program!
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 netbook, but not regular laptop either - that is 32 bit), it is worth noting that 32 bit D isn't going away. We're going to be in the same boat we're in now, which does work.
Re: OSX and 64-bit [Re: First working Win64 program!]
On 2012-08-13 09:04, Russel Winder wrote: 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 their products last a lot longer than that. I have had my MacBook since around 2006. I had to change battery and I've upgraded the RAM, except from that everything is working great. Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. I never had any problems with 32 vs 64bit on Mac OS X. All system libraries ship with universal binaries (32 and 64bit) and it's dead easy to compile for multiple architectures. -- /Jacob Carlborg
Re: First working Win64 program!
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 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. -- /Jacob Carlborg
Re: First working Win64 program!
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 work, too?
Re: First working Win64 program!
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 yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here. We'll see. It has already happened on OSX. OSX has a lot less backwards compatibility to worry about. I fully understand that is why they are a first mover in leaving 32 bits behind. While D is primarily going to be used for writing new programs (and therefore can choose to be 64-bit), it's a huge impediment to adding D into an existing code base for it not be able to link with Microsoft's 32-bit linker. How much that will ultimately matter, I don't know, but I think that it's pretty much a guarante that we're losing quite a bit in the short term by not having compatability with 32-bit Microsoft C/C+ on Windows. 64 bits is far more important. We don't have arrows for every target, we have to pick the juiciest ones.
Re: OSX and 64-bit [Re: First working Win64 program!]
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. 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(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. It is this type of issues that keeps me away from Apple products.
Re: First working Win64 program!
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 Cavanaugh 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 having interest in D! :) I have a theory that game development accelerates the rate at which you learn to hate C++ On the other hand, you get to learn lots of stuff to write "Game Programming Gems" chapters about. :)
Re: First working Win64 program!
On Sun, 12 Aug 2012 23:21:48 -0700 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 important, but > > I still think you're very much jumping the gun here. > > > We'll see. It has already happened on OSX. > Whaddya kidding me? That's an Apple product. Apple only makes disposable throw-away devices. "Release it. Kill it off after 2 weeks. Let the sheep shower us with more of their money. Repeat until there's no more hipster morons with money." There's "Apple" and then there's "the rest of reality".
Re: OSX and 64-bit [Re: First working Win64 program!]
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. 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(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
