digitalmars.D - Version Identifiers for Platforms / Architectures not supported by DMD
- Iain Buclaw (8/8) Nov 05 2011 I have had a recent pull request regarding the updating of some of GDC's...
- Jonathan M Davis (17/28) Nov 05 2011 dmd's version identifiers are annoyingly variable (e.g. linux is camelca...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (3/31) Nov 05 2011 That's exactly how it is. :)
- Walter Bright (3/5) Nov 05 2011 What they do is follow the casing and spelling of the pre-defined macros...
- Nick Sabalausky (3/9) Nov 06 2011 That makes it easy to remember! (Not!)
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (5/15) Nov 06 2011 I have to say, following C compilers in macro definitions is more
- Michel Fortin (14/20) Nov 06 2011 I find this statement puzzling. According to
- Walter Bright (24/40) Nov 06 2011 Based on my research:
- Manu (11/41) Nov 07 2011 I've been running into this problem on consoles.
- Jacob Carlborg (7/17) Nov 07 2011 Perhaps "Mac" for Mac OS and "darwin" for Mac OS X and iOS. Both Mac OS
- Manu (24/32) Nov 07 2011 True-ish, but they're not even slightly the same from a developer
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (5/38) Nov 07 2011 I'm not sure I see the idea in having a platform value separate from an
- Manu (3/6) Nov 07 2011 Platform identifies some sort of common foundation; as dawrin is to OSX/...
- Jacob Carlborg (14/38) Nov 07 2011 That's correct but it also depends on what you're developing. Say if you...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/44) Nov 07 2011 That list is, in fact, very out of date. I have some pending patches in
- Iain Buclaw (5/17) Nov 07 2011 I don't see any real need to have identifiers for console platforms buil...
- Manu (14/33) Nov 07 2011 ... I guess. But I reckon it's a bit of a pain in the arse to remember t...
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (4/54) Nov 07 2011 My only actual complaint here would be the casing of the 'l'. The
- Nick Sabalausky (18/46) Nov 07 2011 You're completely contradicting your claim here of having used the gcc
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (4/60) Nov 07 2011 Yes, this would be a good idea. This approach could deprecate 'linux' in...
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (3/82) Nov 07 2011 I propose: https://github.com/D-Programming-Language/dmd/pull/501
- Brad Roberts (3/89) Nov 07 2011 If any change is to be made, and I'm not sure it's a good idea to change...
- Walter Bright (5/7) Nov 07 2011 I don't see any gain to changing the existing identifiers. It's all bike...
- Jonathan M Davis (11/19) Nov 07 2011 I could see an argument for adding new version identifiers for one or tw...
- Daniel Murphy (17/17) Nov 08 2011 There is always one backwards compatible solution:
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (14/31) Nov 09 2011 That's not backwards-compatible. What if someone out there is really
-
Daniel Murphy
(7/10)
Nov 09 2011
"Alex Rønne Petersen"
wrote in message - Walter Bright (33/36) Nov 09 2011 Sorry, I don't love the idea. I dislike it for its inconsistency with th...
- kennytm (4/49) Nov 09 2011 Perhaps DMD should generate a warning if a version of platforms does not
- Jonathan M Davis (9/12) Nov 09 2011 Well, that does get a bit fuzzy. For instance, rather than duplicating t...
- kennytm (2/16) Nov 09 2011 I said version(Platform)s, not static if.
- Jonathan M Davis (11/30) Nov 09 2011 LOL. Yes. And I meant version(Platform). I obviously had my wires crosse...
- kennytm (8/42) Nov 10 2011 Yes, but imagine there's a non-POSIX non-Windows platform (e.g. an embed...
- Jonathan M Davis (9/53) Nov 10 2011 I'm not completely against the idea. I'm just pointing out that it's mor...
- Nick Sabalausky (10/28) Nov 10 2011 I don't think you're going to get most people to go through the bother o...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/14) Nov 11 2011 I have sent a pull request to update d-p-l.org with the new version
- Andrei Alexandrescu (3/26) Nov 11 2011 Done. Thanks!
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (6/38) Nov 14 2011 Amendment:
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/49) Nov 14 2011 By the way, I just noticed that on
I have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change. Regards Iain
Nov 05 2011
On Saturday, November 05, 2011 20:48:32 Iain Buclaw wrote:I have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-ve rsion Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change.dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase). Most of them, however, are Pascal-cased, so for consistency, it's probably better to make them all Pascal-cased, but given the lack of consistency and the fact that you don't necessarily get any errors when you use an incorrectly-spelled version identifier, you generally have to look it up regardless, and if you always have to look it up, the exact casing doesn't necessarily matter. Still, I'd argue that version identifiers in general should just be Pascal- cased since that seems to be the most common casing used, and ideally, they'd be consistent. For acronyms, that would mean all uppercase, so assuming that AIX is an acronym, then AIX would be the correct way to go, and assuming that alpha isn't an acronym, then Alpha would be the correct way to go (I'm not particularly familiar with non-x86 architectures, so I don't know whether they're acronyms or not - though I'd guess that AIX is and Alpha isn't). - Jonathan M Davis
Nov 05 2011
On 05-11-2011 22:07, Jonathan M Davis wrote:On Saturday, November 05, 2011 20:48:32 Iain Buclaw wrote:That's exactly how it is. :) - AlexI have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-ve rsion Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change.dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase). Most of them, however, are Pascal-cased, so for consistency, it's probably better to make them all Pascal-cased, but given the lack of consistency and the fact that you don't necessarily get any errors when you use an incorrectly-spelled version identifier, you generally have to look it up regardless, and if you always have to look it up, the exact casing doesn't necessarily matter. Still, I'd argue that version identifiers in general should just be Pascal- cased since that seems to be the most common casing used, and ideally, they'd be consistent. For acronyms, that would mean all uppercase, so assuming that AIX is an acronym, then AIX would be the correct way to go, and assuming that alpha isn't an acronym, then Alpha would be the correct way to go (I'm not particularly familiar with non-x86 architectures, so I don't know whether they're acronyms or not - though I'd guess that AIX is and Alpha isn't). - Jonathan M Davis
Nov 05 2011
On 11/5/2011 2:07 PM, Jonathan M Davis wrote:dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase).What they do is follow the casing and spelling of the pre-defined macros of the local C compiler.
Nov 05 2011
"Walter Bright" <newshound2 digitalmars.com> wrote in message news:j95116$79g$1 digitalmars.com...On 11/5/2011 2:07 PM, Jonathan M Davis wrote:That makes it easy to remember! (Not!)dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase).What they do is follow the casing and spelling of the pre-defined macros of the local C compiler.
Nov 06 2011
On 06-11-2011 13:07, Nick Sabalausky wrote:"Walter Bright"<newshound2 digitalmars.com> wrote in message news:j95116$79g$1 digitalmars.com...I have to say, following C compilers in macro definitions is more error-prone than just defining a more sane, standardized set of version identifiers. Not everyone writing D code will be familiar with C. - AlexOn 11/5/2011 2:07 PM, Jonathan M Davis wrote:That makes it easy to remember! (Not!)dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase).What they do is follow the casing and spelling of the pre-defined macros of the local C compiler.
Nov 06 2011
On 2011-11-06 04:04:22 +0000, Walter Bright <newshound2 digitalmars.com> said:On 11/5/2011 2:07 PM, Jonathan M Davis wrote:I find this statement puzzling. According to <http://predef.sourceforge.net/preos.html>: * There's no OSX macro on OS X, just __APPLE__ and __MACH__. * There's no Solaris macro on Solaris, only 'sun' and '__sun'. * There's no Windows/Win32/Win64 macro on Windows, there's __WINDOWS__/_WIN32/_WIN64. * There's no FreeBSD macro on FreeBSD, instead you have __FreeBSD__. Beside linux, I don't see any of the predefined version identifiers corresponding to the platform's standard C macros. -- Michel Fortin michel.fortin michelf.com http://michelf.com/dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase).What they do is follow the casing and spelling of the pre-defined macros of the local C compiler.
Nov 06 2011
On 11/6/2011 6:40 AM, Michel Fortin wrote:On 2011-11-06 04:04:22 +0000, Walter Bright <newshound2 digitalmars.com> said:Based on my research: _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000 _WIN64 Windows for AMD64 linux Linux __APPLE__ Mac OSX __FreeBSD__ FreeBSD __OpenBSD__ OpenBSD __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary) Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful :-) and are unnecessary for D since the version tags are in a separate namespace. Had to come up with one for Solaris. APPLE is hopelessly generic, considering Apple has produced many operating systems. __WINDOWS__ is not what DMC uses. See http://www.digitalmars.com/ctg/predefined.html Some people have protested that I have "trivialized" Linux by using "linux", but I am perplexed why that's ok for gcc but not for D. And finally, there is no such thing as a "sane" version identifier scheme. For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did). Even if someone comes up with a naming scheme for D that most agree is sane, intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.On 11/5/2011 2:07 PM, Jonathan M Davis wrote:I find this statement puzzling. According to <http://predef.sourceforge.net/preos.html>: * There's no OSX macro on OS X, just __APPLE__ and __MACH__. * There's no Solaris macro on Solaris, only 'sun' and '__sun'. * There's no Windows/Win32/Win64 macro on Windows, there's __WINDOWS__/_WIN32/_WIN64. * There's no FreeBSD macro on FreeBSD, instead you have __FreeBSD__. Beside linux, I don't see any of the predefined version identifiers corresponding to the platform's standard C macros.dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, whereas Windows is Pascal-cased and OSX is all uppercase).What they do is follow the casing and spelling of the pre-defined macros of the local C compiler.
Nov 06 2011
I've been running into this problem on consoles. I'd vote for creating a standard, only creating new identifiers according to that standard, and also adding standardised versions of existing identifiers (leaving also the ones don't conform, possibly remove them in D3) The __APPLE__ one is a problem, how to identify iOS? OS8/9? I've been tinkering with PSP... what about Android, PS3, XBox(/360), etc... Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names? On 7 November 2011 03:33, Jonathan M Davis <jmdavisProg gmx.com> wrote:On Sunday, November 06, 2011 16:17:59 Walter Bright wrote:And finally, there is no such thing as a "sane" version identifierscheme.For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did). Even if someone comes up with a naming scheme for D that most agree issane,intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.I think that what it comes down to is that most D programmers are looking for consistency and don't care what C is doing with its version identifiers. You have to look up what they are regardless, since even if you know the C identifiers and you know that D is trying to follow them, there's still no guarantee that they're the same. It may not be worth making breaking changes (e.g. changing linux to Linux) at this point, but at minimum, I'd argue that new version identifiers should be more consistent. And I believe that some have argued in the pas that we should just add Linux to make it consistent, but leave linux to avoid code breakage (which has the upside of increasing consistency but the downside of creating two version identifiers for the same thing). - Jonathan M Davis
Nov 07 2011
On 2011-11-07 09:23, Manu wrote:I've been running into this problem on consoles. I'd vote for creating a standard, only creating new identifiers according to that standard, and also adding standardised versions of existing identifiers (leaving also the ones don't conform, possibly remove them in D3) The __APPLE__ one is a problem, how to identify iOS? OS8/9?Perhaps "Mac" for Mac OS and "darwin" for Mac OS X and iOS. Both Mac OS X and iOS builds on the same foundation.I've been tinkering with PSP... what about Android, PS3, XBox(/360), etc... Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names?There are version identifiers for different architectures as well, e.g. X86, X86_64 and so on. -- /Jacob Carlborg
Nov 07 2011
Both Mac OS X and iOS builds on the same foundation.True-ish, but they're not even slightly the same from a developer perspective. People often make that mistake, where technologies are similar, but neglect the fact that you have to do fundamentally different things on the devices. They need to be distinguished. If darwin is defined, then it ALSO needs a OSX/iOS for disambiguation in addition.I've been tinkering with PSP... what about Android, PS3, XBox(/360), etc...Yes, but they need to be declared standard, and listed somewhere. If they're not reliable, then you'll inevitably be in the same mess as cross platform C apps where you need a global header that parses and munges a huge pile of arbitrary defines into useful macros for your app. For any platform/architecture, there should ALWAYS be available at least identifiers for PLATFORM, OS, and ARCHITECTURE. An identifier for TOOLCHAIN is often useful too, since different toolchains for the same system might be slight different, eg. console game dev in particular... GCC, SN, Codewarrior, proprietary compilers; all target exactly the same thing, but require some toolchain specific code. Basically I think if those three (I'd argue for 4) things aren't present, standardised, and dependable, there will always eventually be the mess we all love in the top of C header files. For instance, the OSX example above, I'd suggest something like: PLATFORM = darwin OS = OSX/iOS ARCHITECTURE = X86/PPC/ARM TOOLCHAIN = [whatever]Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names?There are version identifiers for different architectures as well, e.g. X86, X86_64 and so on.
Nov 07 2011
On 07-11-2011 11:55, Manu wrote:Both Mac OS X and iOS builds on the same foundation. True-ish, but they're not even slightly the same from a developer perspective. People often make that mistake, where technologies are similar, but neglect the fact that you have to do fundamentally different things on the devices. They need to be distinguished. If darwin is defined, then it ALSO needs a OSX/iOS for disambiguation in addition. I've been tinkering with PSP... what about Android, PS3, XBox(/360), etc... Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names? There are version identifiers for different architectures as well, e.g. X86, X86_64 and so on. Yes, but they need to be declared standard, and listed somewhere. If they're not reliable, then you'll inevitably be in the same mess as cross platform C apps where you need a global header that parses and munges a huge pile of arbitrary defines into useful macros for your app. For any platform/architecture, there should ALWAYS be available at least identifiers for PLATFORM, OS, and ARCHITECTURE. An identifier for TOOLCHAIN is often useful too, since different toolchains for the same system might be slight different, eg. console game dev in particular... GCC, SN, Codewarrior, proprietary compilers; all target exactly the same thing, but require some toolchain specific code. Basically I think if those three (I'd argue for 4) things aren't present, standardised, and dependable, there will always eventually be the mess we all love in the top of C header files. For instance, the OSX example above, I'd suggest something like: PLATFORM = darwin OS = OSX/iOS ARCHITECTURE = X86/PPC/ARM TOOLCHAIN = [whatever]I'm not sure I see the idea in having a platform value separate from an OS value. Otherwise I agree; OS, architecture, and toolchain should always be identifiable. - Alex
Nov 07 2011
I'm not sure I see the idea in having a platform value separate from an OS value. Otherwise I agree; OS, architecture, and toolchain should always be identifiable.Platform identifies some sort of common foundation; as dawrin is to OSX/iOS Linux running on an xbox is still running on an xbox, and definitely distinct from linux running on any old pc.
Nov 07 2011
On 2011-11-07 11:55, Manu wrote:True-ish, but they're not even slightly the same from a developer perspective. People often make that mistake, where technologies are similar, but neglect the fact that you have to do fundamentally different things on the devices. They need to be distinguished. If darwin is defined, then it ALSO needs a OSX/iOS for disambiguation in addition.That's correct but it also depends on what you're developing. Say if you develop a library for handling strings (not drawing) they would probably be exactly the same on Mac OS X and iOS.Yes, but they need to be declared standard, and listed somewhere. If they're not reliable, then you'll inevitably be in the same mess as cross platform C apps where you need a global header that parses and munges a huge pile of arbitrary defines into useful macros for your app.This is a list of all predefined version identifiers: http://d-programming-language.org/version.html#PredefinedVersionsFor any platform/architecture, there should ALWAYS be available at least identifiers for PLATFORM, OS, and ARCHITECTURE. An identifier for TOOLCHAIN is often useful too, since different toolchains for the same system might be slight different, eg. console game dev in particular... GCC, SN, Codewarrior, proprietary compilers; all target exactly the same thing, but require some toolchain specific code.What is "platform" in this case.Basically I think if those three (I'd argue for 4) things aren't present, standardised, and dependable, there will always eventually be the mess we all love in the top of C header files. For instance, the OSX example above, I'd suggest something like: PLATFORM = darwin OS = OSX/iOS ARCHITECTURE = X86/PPC/ARM TOOLCHAIN = [whatever]Ok, so for linux it could be the following? platform = linux os = ubuntu architecture = x86 tool chain = gcc -- /Jacob Carlborg
Nov 07 2011
On 07-11-2011 13:29, Jacob Carlborg wrote:On 2011-11-07 11:55, Manu wrote:That list is, in fact, very out of date. I have some pending patches in my fork here: https://github.com/alexrp/d-programming-language.org/commits/master I'll send those upstream when the GDC patch is merged.True-ish, but they're not even slightly the same from a developer perspective. People often make that mistake, where technologies are similar, but neglect the fact that you have to do fundamentally different things on the devices. They need to be distinguished. If darwin is defined, then it ALSO needs a OSX/iOS for disambiguation in addition.That's correct but it also depends on what you're developing. Say if you develop a library for handling strings (not drawing) they would probably be exactly the same on Mac OS X and iOS.Yes, but they need to be declared standard, and listed somewhere. If they're not reliable, then you'll inevitably be in the same mess as cross platform C apps where you need a global header that parses and munges a huge pile of arbitrary defines into useful macros for your app.This is a list of all predefined version identifiers: http://d-programming-language.org/version.html#PredefinedVersions- AlexFor any platform/architecture, there should ALWAYS be available at least identifiers for PLATFORM, OS, and ARCHITECTURE. An identifier for TOOLCHAIN is often useful too, since different toolchains for the same system might be slight different, eg. console game dev in particular... GCC, SN, Codewarrior, proprietary compilers; all target exactly the same thing, but require some toolchain specific code.What is "platform" in this case.Basically I think if those three (I'd argue for 4) things aren't present, standardised, and dependable, there will always eventually be the mess we all love in the top of C header files. For instance, the OSX example above, I'd suggest something like: PLATFORM = darwin OS = OSX/iOS ARCHITECTURE = X86/PPC/ARM TOOLCHAIN = [whatever]Ok, so for linux it could be the following? platform = linux os = ubuntu architecture = x86 tool chain = gcc
Nov 07 2011
== Quote from Manu (turkeyman gmail.com)'s article--001485ec112698f20204b120c415 Content-Type: text/plain; charset=UTF-8 I've been running into this problem on consoles. I'd vote for creating a standard, only creating new identifiers according to that standard, and also adding standardised versions of existing identifiers (leaving also the ones don't conform, possibly remove them in D3) The __APPLE__ one is a problem, how to identify iOS? OS8/9? I've been tinkering with PSP... what about Android, PS3, XBox(/360), etc... Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names?I don't see any real need to have identifiers for console platforms built into the compiler. As you'd pretty much always would be using a homebrew cross- compiler, and can simply pass -version=PSP on the command-line in the build command.
Nov 07 2011
On 8 November 2011 00:33, Iain Buclaw <ibuclaw ubuntu.com> wrote:== Quote from Manu (turkeyman gmail.com)'s article... I guess. But I reckon it's a bit of a pain in the arse to remember to do that everywhere (and edit scripts all over the place when cross compiling). I don't really see why a platform specific toolchain wouldn't know what it is, and define its self as such. Not to mention, if you leave it up to the user to expect some arbitrary version identifier passed into their code, you'll never find a standard accepted by all code for a platform... it'll just be a total mess like C is now. I say it should be proactively selected to encourage standardisation on one, and it should be asserted by the compiler automatically. 10 years of arguing with different compilers and libs for the same platforms disagreeing on how to identify the thing has taught me that much :/--001485ec112698f20204b120c415 Content-Type: text/plain; charset=UTF-8 I've been running into this problem on consoles. I'd vote for creating a standard, only creating new identifiers according to that standard, and also adding standardised versions of existing identifiers (leaving also the ones don't conform, possibly remove them in D3) The __APPLE__ one is a problem, how to identify iOS? OS8/9? I've been tinkering with PSP... what about Android, PS3, XBox(/360),etc...Some of these platforms exist on multiple architectures... how to distinguish the architecture from the platform? Standardisation of arch names?I don't see any real need to have identifiers for console platforms built into the compiler. As you'd pretty much always would be using a homebrew cross- compiler, and can simply pass -version=PSP on the command-line in the build command.
Nov 07 2011
On 07-11-2011 01:17, Walter Bright wrote:On 11/6/2011 6:40 AM, Michel Fortin wrote: > On 2011-11-06 04:04:22 +0000, Walter Bright <newshound2 digitalmars.com> said: > >> On 11/5/2011 2:07 PM, Jonathan M Davis wrote: >>> dmd's version identifiers are annoyingly variable (e.g. linux is camelcased, >>> whereas Windows is Pascal-cased and OSX is all uppercase). >> >> What they do is follow the casing and spelling of the pre-defined macros of >> the local C compiler. > > I find this statement puzzling. According to > <http://predef.sourceforge.net/preos.html>: > > * There's no OSX macro on OS X, just __APPLE__ and __MACH__. > * There's no Solaris macro on Solaris, only 'sun' and '__sun'. > * There's no Windows/Win32/Win64 macro on Windows, there's > __WINDOWS__/_WIN32/_WIN64. > * There's no FreeBSD macro on FreeBSD, instead you have __FreeBSD__. > > Beside linux, I don't see any of the predefined version identifiers > corresponding to the platform's standard C macros. Based on my research: _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000 _WIN64 Windows for AMD64 linux Linux __APPLE__ Mac OSX __FreeBSD__ FreeBSD __OpenBSD__ OpenBSD __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary) Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful :-) and are unnecessary for D since the version tags are in a separate namespace. Had to come up with one for Solaris. APPLE is hopelessly generic, considering Apple has produced many operating systems. __WINDOWS__ is not what DMC uses. See http://www.digitalmars.com/ctg/predefined.html Some people have protested that I have "trivialized" Linux by using "linux", but I am perplexed why that's ok for gcc but not for D.My only actual complaint here would be the casing of the 'l'. The version identifier itself seems fine to me.And finally, there is no such thing as a "sane" version identifier scheme. For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did). Even if someone comes up with a naming scheme for D that most agree is sane, intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.- Alex
Nov 07 2011
"Walter Bright" <newshound2 digitalmars.com> wrote in message news:j9784p$24tu$1 digitalmars.com...Based on my research: _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000 _WIN64 Windows for AMD64 linux Linux __APPLE__ Mac OSX __FreeBSD__ FreeBSD __OpenBSD__ OpenBSD __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary) Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful :-) and are unnecessary for D since the version tags are in a separate namespace. Had to come up with one for Solaris. APPLE is hopelessly generic, considering Apple has produced many operating systems. __WINDOWS__ is not what DMC uses. See http://www.digitalmars.com/ctg/predefined.htmlYou're completely contradicting your claim here of having used the gcc idents. Obviously you changed the idents, and you had a reason for each one. There's pretty damn good reason for changing "linux" too. At least Phobos is finally ditching the absolutely rediculous philosophy of "always use naming conventions from random other places, and don't ever even think about being internally-consistent".Some people have protested that I have "trivialized" Linux by using "linux", but I am perplexed why that's ok for gcc but not for D.Strawman.And finally, there is no such thing as a "sane" version identifier scheme. For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did).You're really stretching to say those aren't "sane" names. They're just names, they're not even intended to be identifiers. To make identifiers *for* them, removing the illegal chars (and using a non-schizophrenic casing scheme) is an obvious and non-problematic solution. Picking *ONE* of them to be lowercased instead of upper camel cased like the rest (or any other inconsistent casing) isn't merely "not sane", it's also completely unnecessary.Even if someone comes up with a naming scheme for D that most agree is sane, intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.Adding "Linux" as a preferred alternative to "linux" will not break large swaths of code.
Nov 07 2011
On 07-11-2011 14:20, Nick Sabalausky wrote:"Walter Bright"<newshound2 digitalmars.com> wrote in message news:j9784p$24tu$1 digitalmars.com...Yes, this would be a good idea. This approach could deprecate 'linux' in favor of 'Linux' as 'darwin' was deprecated in favor of 'OSX'. - AlexBased on my research: _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000 _WIN64 Windows for AMD64 linux Linux __APPLE__ Mac OSX __FreeBSD__ FreeBSD __OpenBSD__ OpenBSD __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary) Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful :-) and are unnecessary for D since the version tags are in a separate namespace. Had to come up with one for Solaris. APPLE is hopelessly generic, considering Apple has produced many operating systems. __WINDOWS__ is not what DMC uses. See http://www.digitalmars.com/ctg/predefined.htmlYou're completely contradicting your claim here of having used the gcc idents. Obviously you changed the idents, and you had a reason for each one. There's pretty damn good reason for changing "linux" too. At least Phobos is finally ditching the absolutely rediculous philosophy of "always use naming conventions from random other places, and don't ever even think about being internally-consistent".Some people have protested that I have "trivialized" Linux by using "linux", but I am perplexed why that's ok for gcc but not for D.Strawman.And finally, there is no such thing as a "sane" version identifier scheme. For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did).You're really stretching to say those aren't "sane" names. They're just names, they're not even intended to be identifiers. To make identifiers *for* them, removing the illegal chars (and using a non-schizophrenic casing scheme) is an obvious and non-problematic solution. Picking *ONE* of them to be lowercased instead of upper camel cased like the rest (or any other inconsistent casing) isn't merely "not sane", it's also completely unnecessary.Even if someone comes up with a naming scheme for D that most agree is sane, intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.Adding "Linux" as a preferred alternative to "linux" will not break large swaths of code.
Nov 07 2011
On 07-11-2011 14:59, Alex Rønne Petersen wrote:On 07-11-2011 14:20, Nick Sabalausky wrote:I propose: https://github.com/D-Programming-Language/dmd/pull/501 - Alex"Walter Bright"<newshound2 digitalmars.com> wrote in message news:j9784p$24tu$1 digitalmars.com...Yes, this would be a good idea. This approach could deprecate 'linux' in favor of 'Linux' as 'darwin' was deprecated in favor of 'OSX'. - AlexBased on my research: _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000 _WIN64 Windows for AMD64 linux Linux __APPLE__ Mac OSX __FreeBSD__ FreeBSD __OpenBSD__ OpenBSD __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary) Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful :-) and are unnecessary for D since the version tags are in a separate namespace. Had to come up with one for Solaris. APPLE is hopelessly generic, considering Apple has produced many operating systems. __WINDOWS__ is not what DMC uses. See http://www.digitalmars.com/ctg/predefined.htmlYou're completely contradicting your claim here of having used the gcc idents. Obviously you changed the idents, and you had a reason for each one. There's pretty damn good reason for changing "linux" too. At least Phobos is finally ditching the absolutely rediculous philosophy of "always use naming conventions from random other places, and don't ever even think about being internally-consistent".Some people have protested that I have "trivialized" Linux by using "linux", but I am perplexed why that's ok for gcc but not for D.Strawman.And finally, there is no such thing as a "sane" version identifier scheme. For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did).You're really stretching to say those aren't "sane" names. They're just names, they're not even intended to be identifiers. To make identifiers *for* them, removing the illegal chars (and using a non-schizophrenic casing scheme) is an obvious and non-problematic solution. Picking *ONE* of them to be lowercased instead of upper camel cased like the rest (or any other inconsistent casing) isn't merely "not sane", it's also completely unnecessary.Even if someone comes up with a naming scheme for D that most agree is sane, intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.Adding "Linux" as a preferred alternative to "linux" will not break large swaths of code.
Nov 07 2011
On Mon, 7 Nov 2011, Alex R?nne Petersen wrote:On 07-11-2011 14:59, Alex R?nne Petersen wrote:If any change is to be made, and I'm not sure it's a good idea to change anything at all here, I'd go with all lower case for all of them.On 07-11-2011 14:20, Nick Sabalausky wrote:I propose: https://github.com/D-Programming-Language/dmd/pull/501 - Alex"Walter Bright"<newshound2 digitalmars.com> wrote in message news:j9784p$24tu$1 digitalmars.com...Yes, this would be a good idea. This approach could deprecate 'linux' in favor of 'Linux' as 'darwin' was deprecated in favor of 'OSX'. - AlexBased on my research: _WIN32 Microsoft NT, Windows 95, Windows 98, Win32s, Windows 2000 _WIN64 Windows for AMD64 linux Linux __APPLE__ Mac OSX __FreeBSD__ FreeBSD __OpenBSD__ OpenBSD __sun&&__SVR4 Solaris, OpenSolaris (yes, both macros are necessary) Hence FreeBSD rather than freebsd or Freebsd. The underscores just looked awful :-) and are unnecessary for D since the version tags are in a separate namespace. Had to come up with one for Solaris. APPLE is hopelessly generic, considering Apple has produced many operating systems. __WINDOWS__ is not what DMC uses. See http://www.digitalmars.com/ctg/predefined.htmlYou're completely contradicting your claim here of having used the gcc idents. Obviously you changed the idents, and you had a reason for each one. There's pretty damn good reason for changing "linux" too. At least Phobos is finally ditching the absolutely rediculous philosophy of "always use naming conventions from random other places, and don't ever even think about being internally-consistent".Some people have protested that I have "trivialized" Linux by using "linux", but I am perplexed why that's ok for gcc but not for D.Strawman.And finally, there is no such thing as a "sane" version identifier scheme. For one thing, OS vendors do not pick sane names. OS/2 is not an identifier. Neither is OS X. Nor is GNU/Linux. Nor do the OS vendors pick any sane identifiers for their own systems (look at what Sun did).You're really stretching to say those aren't "sane" names. They're just names, they're not even intended to be identifiers. To make identifiers *for* them, removing the illegal chars (and using a non-schizophrenic casing scheme) is an obvious and non-problematic solution. Picking *ONE* of them to be lowercased instead of upper camel cased like the rest (or any other inconsistent casing) isn't merely "not sane", it's also completely unnecessary.Even if someone comes up with a naming scheme for D that most agree is sane, intuitive, and attractive, switching to it would again silently break a large swath of existing D code. D cannot advance by constantly breaking things.Adding "Linux" as a preferred alternative to "linux" will not break large swaths of code.
Nov 07 2011
On 11/7/2011 2:29 PM, Brad Roberts wrote:If any change is to be made, and I'm not sure it's a good idea to change anything at all here, I'd go with all lower case for all of them.I don't see any gain to changing the existing identifiers. It's all bikeshedding with the illusion of progress, yet making arbitrary amounts of work for others as they have to go edit their code. We've got much more important things that need doing.
Nov 07 2011
On Monday, November 07, 2011 17:04 Walter Bright wrote:On 11/7/2011 2:29 PM, Brad Roberts wrote:I could see an argument for adding new version identifiers for one or two (leaving in the old ones for backwards compatability) of them if it made them all consistent, but outright changing any of them would break too much code, and changing most or all of them would _definitely_ break too much code. Yes, I'd prefer that linux be Linux, but I'm not sure that it's a good idea to have both Linux and linux work, and I definitely agree that changing any of those identifiers at this point would be too disruptive. So, while I think that the current situation is less than ideal, I think that we're pretty much stuck at this point. - Jonathan M DavisIf any change is to be made, and I'm not sure it's a good idea to change anything at all here, I'd go with all lower case for all of them.I don't see any gain to changing the existing identifiers. It's all bikeshedding with the illusion of progress, yet making arbitrary amounts of work for others as they have to go edit their code. We've got much more important things that need doing.
Nov 07 2011
There is always one backwards compatible solution: We could make version identifiers case insensitive. It's a change from everywhere else in the language, but... There is no 'correct' casing for os/architecture etc windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions. Invalid identifiers are _silently_ accepted. eg. version(Linux) {} Would anybody ever _actually_ mean Linux here? Because it works on a is/is not defined basis, this is one case where case sensitivity harms usability. You never get an error for messing up the casing, unless you explicitly add a static assert in an else clause. Does anybody really define both 'MyVersion' and 'myVersion' and expect them to do different things? I think the inconsistency and the small addition to the spec are worth it to have the compiler silently and automatically do the right thing, and remove the impact of some incredibly inconsistent and arbirtary casing choices.
Nov 08 2011
On 09-11-2011 02:29, Daniel Murphy wrote:There is always one backwards compatible solution: We could make version identifiers case insensitive.That's not backwards-compatible. What if someone out there is really using Foo and fOO for two different things? I know this sounds far-fetched, but the possibility is there.It's a change from everywhere else in the language, but... There is no 'correct' casing for os/architecture etc windows vs Windows, linux vs Linux, x86 vs X86 are meaningless distinctions.It's proper spelling of the titles of the architectures/OSs. I don't see how this is not correct.Invalid identifiers are _silently_ accepted. eg. version(Linux) {} Would anybody ever _actually_ mean Linux here?Maybe... they could have: version (linux) { version (Linux); } to fix the inconsistency that is in place now. ;)Because it works on a is/is not defined basis, this is one case where case sensitivity harms usability. You never get an error for messing up the casing, unless you explicitly add a static assert in an else clause.Very true. But you're supposed to do that anyway, as Walter pointed out in a post to the druntime mailing list, because it aids portability.Does anybody really define both 'MyVersion' and 'myVersion' and expect them to do different things? I think the inconsistency and the small addition to the spec are worth it to have the compiler silently and automatically do the right thing, and remove the impact of some incredibly inconsistent and arbirtary casing choices.In general, I agree, but this would be a breaking change no matter how you look at it. I'm not sure if that's a good idea. - Alex
Nov 09 2011
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message news:j9dviv$1jbd$4 digitalmars.com... ...In general, I agree, but this would be a breaking change no matter how you look at it. I'm not sure if that's a good idea. - AlexThanks for the comments. I expect this change would fix many, many more bugs than it causes. But, as it is a breaking change (very slightly), and a special case, I doubt this will ever happen unless Walter loves the idea. Walter?
Nov 09 2011
On 11/9/2011 6:46 AM, Daniel Murphy wrote:But, as it is a breaking change (very slightly), and a special case, I doubt this will ever happen unless Walter loves the idea. Walter?Sorry, I don't love the idea. I dislike it for its inconsistency with the rest of the language. The trend in programming languages and operating systems has, for a long time, been towards case sensitivity. BTW, the correct way to write version sensitive code is: version (linux) { ... } else version (OSX) { ... } else static assert(0, "unsupported OS version"); Otherwise, it's miserable to find and tweak all the version sensitive code in your codebase. Here's a WRONG WRONG WRONG way: version (linux) { ... } else /* Windows */ { ... } Looks stupid, but I tend to often see stuff like this in C, C++ and D source code. Even in my own. This is also why there's no ! for versions: version (!linux) { ... } Aaaaggghhhh. I'm pretty fed up with seeing that crap in C code. And if you see any of it in dmd or phobos sources, please file a bugzilla report! Show no mercy.
Nov 09 2011
Walter Bright <newshound2 digitalmars.com> wrote:On 11/9/2011 6:46 AM, Daniel Murphy wrote:Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert.But, as it is a breaking change (very slightly), and a special case, I doubt this will ever happen unless Walter loves the idea. Walter?Sorry, I don't love the idea. I dislike it for its inconsistency with the rest of the language. The trend in programming languages and operating systems has, for a long time, been towards case sensitivity. BTW, the correct way to write version sensitive code is: version (linux) { ... } else version (OSX) { ... } else static assert(0, "unsupported OS version"); Otherwise, it's miserable to find and tweak all the version sensitive code in your codebase. Here's a WRONG WRONG WRONG way: version (linux) { ... } else /* Windows */ { ... } Looks stupid, but I tend to often see stuff like this in C, C++ and D source code. Even in my own. This is also why there's no ! for versions: version (!linux) { ... } Aaaaggghhhh. I'm pretty fed up with seeing that crap in C code. And if you see any of it in dmd or phobos sources, please file a bugzilla report! Show no mercy.
Nov 09 2011
On Thursday, November 10, 2011 04:07:43 kennytm wrote:Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert.Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis
Nov 09 2011
Jonathan M Davis <jmdavisProg gmx.com> wrote:On Thursday, November 10, 2011 04:07:43 kennytm wrote:I said version(Platform)s, not static if.Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert.Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis
Nov 09 2011
On Thursday, November 10, 2011 05:08:03 kennytm wrote:Jonathan M Davis <jmdavisProg gmx.com> wrote:LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when I wrote that. std.file uses version(Posix) {} else version(Windows) {} without an else block, except for the first one in the file which _does_ have an else which has a static assert(0) in it. Requiring that all such version blocks had elses would invalidate that approach. - Jonathan M DavisOn Thursday, November 10, 2011 04:07:43 kennytm wrote:I said version(Platform)s, not static if.Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert.Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis
Nov 09 2011
Jonathan M Davis <jmdavisProg gmx.com> wrote:On Thursday, November 10, 2011 05:08:03 kennytm wrote:Yes, but imagine there's a non-POSIX non-Windows platform (e.g. an embedded system), and we make stdio to support it. After we add a version(NewPlatform) branch to the one containing the static assert, the compiler can no longer help us to know some version statement in the middle may have missed the NewPlatform. This is a contrived example, and I agree it would often be too strict, so I think there should be individual warning switches.Jonathan M Davis <jmdavisProg gmx.com> wrote:LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when I wrote that. std.file uses version(Posix) {} else version(Windows) {} without an else block, except for the first one in the file which _does_ have an else which has a static assert(0) in it. Requiring that all such version blocks had elses would invalidate that approach. - Jonathan M DavisOn Thursday, November 10, 2011 04:07:43 kennytm wrote:I said version(Platform)s, not static if.Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert.Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis
Nov 10 2011
On Thursday, November 10, 2011 13:10 kennytm wrote:Jonathan M Davis <jmdavisProg gmx.com> wrote:I'm not completely against the idea. I'm just pointing out that it's more restrictive that way and potentially messier in code with a lot of version statements. There's no question that the vast majority of people aren't going to have an else clause with a static assert when versioning OSes. And it wouldn't surprise me if something like 99% of the people who do do it do it because Walter pointed out the need to them or someone else who Walter had pointed it out to pointed it out to them. - Jonathan M DavisOn Thursday, November 10, 2011 05:08:03 kennytm wrote:Yes, but imagine there's a non-POSIX non-Windows platform (e.g. an embedded system), and we make stdio to support it. After we add a version(NewPlatform) branch to the one containing the static assert, the compiler can no longer help us to know some version statement in the middle may have missed the NewPlatform. This is a contrived example, and I agree it would often be too strict, so I think there should be individual warning switches.Jonathan M Davis <jmdavisProg gmx.com> wrote:LOL. Yes. And I meant version(Platform). I obviously had my wires crossed when I wrote that. std.file uses version(Posix) {} else version(Windows) {} without an else block, except for the first one in the file which _does_ have an else which has a static assert(0) in it. Requiring that all such version blocks had elses would invalidate that approach. - Jonathan M DavisOn Thursday, November 10, 2011 04:07:43 kennytm wrote:I said version(Platform)s, not static if.Perhaps DMD should generate a warning if a version of platforms does not have an else clause or that version's else clause's content is not another version statement or a static assert.Well, that does get a bit fuzzy. For instance, rather than duplicating that else clause all over the place in std.file, only the first static if-else clause has the else with the static assert in it. All of the others just have the branches that work and don't have an else clause. If we were to require that there be an else like that, then std.file wouldn't compile. And while it wouldn't be all that bad to have to put an else on all of those static-ifs, it _would_ result in unnecessary code duplication. - Jonathan M Davis
Nov 10 2011
"Walter Bright" <newshound2 digitalmars.com> wrote in message news:j9f442$k3p$1 digitalmars.com...On 11/9/2011 6:46 AM, Daniel Murphy wrote:I don't think you're going to get most people to go through the bother of doing this, do you? I agree this is the right thing to do, *now that I see it pointed out*, but even at that it's going to remain tempting not to bother (and easy to forget). Maybe there should be an error when no part of a version...else chain gets used? That way the "static assert(0);" becomes implicit, and people aren't going to fuck it up by forgetting, not knowing to do it, or feeling too lazy to bother.But, as it is a breaking change (very slightly), and a special case, I doubt this will ever happen unless Walter loves the idea. Walter?Sorry, I don't love the idea. I dislike it for its inconsistency with the rest of the language. The trend in programming languages and operating systems has, for a long time, been towards case sensitivity. BTW, the correct way to write version sensitive code is: version (linux) { ... } else version (OSX) { ... } else static assert(0, "unsupported OS version");
Nov 10 2011
On 05-11-2011 21:48, Iain Buclaw wrote:I have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change. Regards IainI have sent a pull request to update d-p-l.org with the new version identifiers supported in GDC, LDC, and SDC: https://github.com/D-Programming-Language/d-programming-language.org/pull/32 Can I bug someone to review this? - Alex
Nov 11 2011
On 11/11/11 6:44 AM, Alex Rønne Petersen wrote:On 05-11-2011 21:48, Iain Buclaw wrote:Done. Thanks! AndreiI have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change. Regards IainI have sent a pull request to update d-p-l.org with the new version identifiers supported in GDC, LDC, and SDC: https://github.com/D-Programming-Language/d-programming-language.org/pull/32 Can I bug someone to review this? - Alex
Nov 11 2011
On 11-11-2011 18:15, Andrei Alexandrescu wrote:On 11/11/11 6:44 AM, Alex Rønne Petersen wrote:Amendment: https://github.com/D-Programming-Language/d-programming-language.org/pull/36 I think this is one of those funny cases where copy/pasting would have been a better idea. :) - AlexOn 05-11-2011 21:48, Iain Buclaw wrote:Done. Thanks! AndreiI have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change. Regards IainI have sent a pull request to update d-p-l.org with the new version identifiers supported in GDC, LDC, and SDC: https://github.com/D-Programming-Language/d-programming-language.org/pull/32 Can I bug someone to review this? - Alex
Nov 14 2011
On 15-11-2011 02:15, Alex Rønne Petersen wrote:On 11-11-2011 18:15, Andrei Alexandrescu wrote:By the way, I just noticed that on http://www.d-programming-language.org/version.html the D_InlineAsm_X86_64 entry is being hyphenated. I don't think this is a good thing, considering it *is* an identifier. Could we get rid of that somehow? - AlexOn 11/11/11 6:44 AM, Alex Rønne Petersen wrote:Amendment: https://github.com/D-Programming-Language/d-programming-language.org/pull/36 I think this is one of those funny cases where copy/pasting would have been a better idea. :) - AlexOn 05-11-2011 21:48, Iain Buclaw wrote:Done. Thanks! AndreiI have had a recent pull request regarding the updating of some of GDC's OS and Arch version identifiers. https://bitbucket.org/goshawk/gdc/pull-request/2/make-some-system-and-cpu-version Such changes include, aix -> AIX; ALPHA -> Alpha; and a few more. While I welcome any change suggestions, I would love to hear the opinion of D users on the proposed change. Regards IainI have sent a pull request to update d-p-l.org with the new version identifiers supported in GDC, LDC, and SDC: https://github.com/D-Programming-Language/d-programming-language.org/pull/32 Can I bug someone to review this? - Alex
Nov 14 2011