www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OpenBSD port of dmd?

reply "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> writes:
Just found this, has anyone tried dmd or friends on OpenBSD?

http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd


Thanks,

Andrei
Mar 16 2012
next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Just found this, has anyone tried dmd or friends on OpenBSD?

 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
OpenBSD would need some druntime work.
Mar 16 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Martin Nowak" <dawg dawgfoto.de> wrote in message 
news:op.wa9r9izqsqugbd localhost...
 On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Just found this, has anyone tried dmd or friends on OpenBSD?

 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
OpenBSD would need some druntime work.
Do you have anything in particular in mind?
Mar 16 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, March 16, 2012 16:00:47 Nick Sabalausky wrote:
 "Martin Nowak" <dawg dawgfoto.de> wrote in message
 news:op.wa9r9izqsqugbd localhost...
 
 On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu
 
 <SeeWebsiteForEmail erdani.org> wrote:
 Just found this, has anyone tried dmd or friends on OpenBSD?
 
 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
OpenBSD would need some druntime work.
Do you have anything in particular in mind?
Probably everything that's not straight Posix would require changes. For instance, every place that has a version(FreeBSD) block would probably need a version(OpenBSD) block. It's probably not all that hard to make the changes, but they'd still need to be done. The very fact that Walter pushes for the model of version(A) {} else version(B) {} else static assert("Unsupported OS"); means that _any_ new OS requires druntime work, even if it's minimal. That's not necessarily a bad thing, since there's a definite chance that the new OS requires additional changes specific to it anyway, but as long as there is sections of druntime are OS-specific without generic versions provided (which isn't going to change), you can't just use druntime with a new OS without updating druntime. - Jonathan M Davis
Mar 16 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2012 1:38 PM, Jonathan M Davis wrote:
 That's not necessarily a bad thing,
It's very deliberate, and it's *certainly* not a bad thing. No ifs, ands, or buts about it. Supporting a new OS by assuming that declarations for some other random OS will work is a recipe for unending frustration and disaster. For example, suppose there is a subtle difference in the layout of the FILE* struct. OOPS! The way the versioning is done it: 1. forces the porter to check that stuff. 2. exposes all the places in the library where there is OS dependent code There should never, EVER, in the library code be something like: version (FreeBSD) ... do something weird with FreeBSD ... else ... do the default ... If you find any code like this in the library, please file a bugzilla entry for it. Instead: version (FreeBSD) ... do something weird with FreeBSD ... else static assert(0, "OS not supported");
Mar 16 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/12 5:27 PM, Walter Bright wrote:
 There should never, EVER, in the library code be something like:

 version (FreeBSD)
 ... do something weird with FreeBSD ...
 else
 ... do the default ...

 If you find any code like this in the library, please file a bugzilla
 entry for it.

 Instead:

 version (FreeBSD)
 ... do something weird with FreeBSD ...
 else
 static assert(0, "OS not supported");
Never say never. There are I/O routines that are specialized for several OSs and fall back to a generic (slower) implementation. Andrei
Mar 16 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2012 4:04 PM, Andrei Alexandrescu wrote:
 Never say never. There are I/O routines that are specialized for several OSs
and
 fall back to a generic (slower) implementation.
I'm going to suggest that is wrong as well. It's fine for a new port to use a generic slow implementation, but that ought to be a deliberate choice, *not* a default that went unnoticed during the porting process.
Mar 16 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2012 4:18 PM, Walter Bright wrote:
 On 3/16/2012 4:04 PM, Andrei Alexandrescu wrote:
 Never say never. There are I/O routines that are specialized for several OSs
and
 fall back to a generic (slower) implementation.
I'm going to suggest that is wrong as well. It's fine for a new port to use a generic slow implementation, but that ought to be a deliberate choice, *not* a default that went unnoticed during the porting process.
I should explain this better. Having a default is wrong because: 1. as mentioned, it can be overlooked in the porting process 2. if the default doesn't work right for some system, the temptation will be to 'fix' the default in ways that are untested (and therefore broken) on other systems. Working on one system's code should not affect other systems! 3. it leaves unknown to the reader what systems that may apply to I know the powerful temptation to avoid copypasta. But I have decades of trying it that way, and it just leads to lots of time wasted tracking down bugs. This includes historical bugs from doing it that way with druntime & phobos.
Mar 16 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/12 6:30 PM, Walter Bright wrote:
 On 3/16/2012 4:18 PM, Walter Bright wrote:
 On 3/16/2012 4:04 PM, Andrei Alexandrescu wrote:
 Never say never. There are I/O routines that are specialized for
 several OSs and
 fall back to a generic (slower) implementation.
I'm going to suggest that is wrong as well. It's fine for a new port to use a generic slow implementation, but that ought to be a deliberate choice, *not* a default that went unnoticed during the porting process.
I should explain this better. Having a default is wrong because: 1. as mentioned, it can be overlooked in the porting process 2. if the default doesn't work right for some system, the temptation will be to 'fix' the default in ways that are untested (and therefore broken) on other systems. Working on one system's code should not affect other systems! 3. it leaves unknown to the reader what systems that may apply to I know the powerful temptation to avoid copypasta. But I have decades of trying it that way, and it just leads to lots of time wasted tracking down bugs. This includes historical bugs from doing it that way with druntime & phobos.
Not convinced. They call it specialization, and it's a powerful concept. We use it in std.algorithm all over the place. Andrei
Mar 16 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jk0l57$20hs$1 digitalmars.com...
 Not convinced. They call it specialization, and it's a powerful concept. 
 We use it in std.algorithm all over the place.

 Andrei
You can do that just as well without using an 'else' block. version(ThisOS) { doItThisWay(); } else version(ThatOS) { doItThatWay(); } else version(SomeOS) { doItSlowWay(); } else version(OtherOS) { doItSlowWay(); } else static assert(0, "OS not implemented"); This means you're forced to choose which way when implementing that new version, instead of hoping that it will work. This is not really the same thing as (eg) specializing searching for narrow strings.
Mar 16 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/12 7:45 PM, Daniel Murphy wrote:
 You can do that just as well without using an 'else' block.

 version(ThisOS)
 {
     doItThisWay();
 }
 else version(ThatOS)
 {
     doItThatWay();
 }
 else version(SomeOS)
 {
     doItSlowWay();
 }
 else version(OtherOS)
 {
     doItSlowWay();
 }
 else
     static assert(0, "OS not implemented");
But why duplicate doItSlowWay(); which may be an arbitrarily long sequence? This seems to accomplish little more than "well I didn't use else". Again: what exactly is wrong with specialization? Andrei
Mar 16 2012
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jk0naq$257e$1 digitalmars.com...
 But why duplicate doItSlowWay(); which may be an arbitrarily long 
 sequence?
If duplicating that block is a problem, there are other ways to do it. version(ThisOS) { version = FastWayA; } else version(ThatOS) { version = FastWayB; } else version(SomeOS) { version = SlowWay; } else version(OtherOS) { version = SlowWay; } else static assert(0, "OS not implemented"); version(FastWayA) { ... } else version (FastWayB) { ... } else version (SlowWay) { ... }
 This seems to accomplish little more than "well I didn't use else".

 Again: what exactly is wrong with specialization?
The advantage is, that when you write the code, you have _no idea_ what platform/os it might need to run on in the future. You _cannot_ know which version is most appropriate for _all_ new platforms, or even if any of them will work at all. The only time to make this decision is when implementing support for a specific platform, and this pattern forces you to consider each place where platform specific behaviour is required. When doing things like this, 100 false positives are much faster to fix than a single false negative causing wrong code/corruption.
Mar 16 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/12 8:16 PM, Daniel Murphy wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jk0naq$257e$1 digitalmars.com...
 But why duplicate doItSlowWay(); which may be an arbitrarily long
 sequence?
If duplicating that block is a problem, there are other ways to do it.
[snip] This is in the same vein: "let's avoid else".
 This seems to accomplish little more than "well I didn't use else".

 Again: what exactly is wrong with specialization?
The advantage is, that when you write the code, you have _no idea_ what platform/os it might need to run on in the future. You _cannot_ know which version is most appropriate for _all_ new platforms, or even if any of them will work at all.
Oh yes I do. Often I know every platform has e.g. getchar() so I can use it. That will definitely work for everyone. Then, if I get to optimize things for particular platforms, great. This is the case for many artifacts.
 The only time to make this decision is when implementing
 support for a specific platform, and this pattern forces you to consider
 each place where platform specific behaviour is required.  When doing things
 like this, 100 false positives are much faster to fix than a single false
 negative causing wrong code/corruption.
I just find it difficult to get convinced about this. Walter has often talked my ear off about this dogma and never produced a convincing argument. Andrei
Mar 16 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jk0ptd$29g2$1 digitalmars.com...
 But why duplicate doItSlowWay(); which may be an arbitrarily long
 sequence?
If duplicating that block is a problem, there are other ways to do it.
[snip] This is in the same vein: "let's avoid else".
Yes.
 This seems to accomplish little more than "well I didn't use else".

 Again: what exactly is wrong with specialization?
The advantage is, that when you write the code, you have _no idea_ what platform/os it might need to run on in the future. You _cannot_ know which version is most appropriate for _all_ new platforms, or even if any of them will work at all.
Oh yes I do. Often I know every platform has e.g. getchar() so I can use it. That will definitely work for everyone. Then, if I get to optimize things for particular platforms, great. This is the case for many artifacts.
Are there really no platforms out there where getchar doesn't exist? What if you need to work around a buggy c standard lib on some platforms? Relying on getchar (and most of the c standard lib) working correctly is probably ok, so long as we never target more exotic architectures. But this is not true generally, and do you really trust everybody who works on the code to make the right choice each time?
 The only time to make this decision is when implementing
 support for a specific platform, and this pattern forces you to consider
 each place where platform specific behaviour is required.  When doing 
 things
 like this, 100 false positives are much faster to fix than a single false
 negative causing wrong code/corruption.
I just find it difficult to get convinced about this. Walter has often talked my ear off about this dogma and never produced a convincing argument. Andrei
Well, he managed to convince me some time ago. Maybe you should try porting code between microcontrollers and see if it makes more sense then. The best part is that if you use this pattern when it isn't needed, the cost is very small.
Mar 16 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jk0ptd$29g2$1 digitalmars.com...
 On 3/16/12 8:16 PM, Daniel Murphy wrote:
 The only time to make this decision is when implementing
 support for a specific platform, and this pattern forces you to consider
 each place where platform specific behaviour is required.  When doing 
 things
 like this, 100 false positives are much faster to fix than a single false
 negative causing wrong code/corruption.
I just find it difficult to get convinced about this. Walter has often talked my ear off about this dogma and never produced a convincing argument.
Walter has produced arguments that have convinced a number of us. Daniel and I, at the very least. What Walter has failed to do is convince *you*, and that's a very, very different thing. Especially when he's pitted against counterarguments like "I just find it difficult to get convinced about this" ;)
Mar 16 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/12 11:50 PM, Nick Sabalausky wrote:
 Walter has produced arguments that have convinced a number of us. Daniel and
 I, at the very least. What Walter has failed to do is convince *you*, and
 that's a very, very different thing. Especially when he's pitted against
 counterarguments like "I just find it difficult to get convinced about this"
 ;)
The burden of proof is not on me, and besides I articulated my argument. Andrei
Mar 16 2012
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Saturday, 17 March 2012 at 01:37:49 UTC, Andrei Alexandrescu 
wrote:
 This is in the same vein: "let's avoid else".
It seems to me more like "final switch" vs. "default:".
Mar 16 2012
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 17 March 2012 at 01:37:49 UTC, Andrei Alexandrescu 
wrote:
 This seems to accomplish little more than "well I didn't use 
 else".

 Again: what exactly is wrong with specialization?
The advantage is, that when you write the code, you have _no idea_ what platform/os it might need to run on in the future. You _cannot_ know which version is most appropriate for _all_ new platforms, or even if any of them will work at all.
Oh yes I do. Often I know every platform has e.g. getchar() so I can use it. That will definitely work for everyone. Then, if I get to optimize things for particular platforms, great. This is the case for many artifacts.
version(PlatformX) { return superfastgetchar(); } else { return getchar(); } Later on, we add support for PlatformY, which also supports superfastgetchar(). If you write code as above then no one will notice. It will just happily use getchar() and suffer because of it. If you static assert on new platforms then it forces you to look at the code for each new platform added and think about what version would be best. As Walter said, you can't know what version will be most appropriate for all new platforms.
Mar 18 2012
parent reply "Tove" <tove fransson.se> writes:
On Sunday, 18 March 2012 at 18:09:42 UTC, Peter Alexander wrote:
 On Saturday, 17 March 2012 at 01:37:49 UTC, Andrei Alexandrescu 
 wrote:
 This seems to accomplish little more than "well I didn't use 
 else".

 Again: what exactly is wrong with specialization?
The advantage is, that when you write the code, you have _no idea_ what platform/os it might need to run on in the future. You _cannot_ know which version is most appropriate for _all_ new platforms, or even if any of them will work at all.
Oh yes I do. Often I know every platform has e.g. getchar() so I can use it. That will definitely work for everyone. Then, if I get to optimize things for particular platforms, great. This is the case for many artifacts.
version(PlatformX) { return superfastgetchar(); } else { return getchar(); } Later on, we add support for PlatformY, which also supports superfastgetchar(). If you write code as above then no one will notice. It will just happily use getchar() and suffer because of it. If you static assert on new platforms then it forces you to look at the code for each new platform added and think about what version would be best. As Walter said, you can't know what version will be most appropriate for all new platforms.
It should be possible to eat the cake and still have it... even if warnings normally are frowned upon(with good reason), using warnings for this would allow the benefits from both "camps"... It would allow a painless "prototype porting" for new operating systems which are similar, yet... even if it does work, at a later point one would still have to go through all the version statements and either silencing the warning, or selecting the optimized path.
Mar 18 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2012 11:28 AM, Tove wrote:
 It should be possible to eat the cake and still have it... even if warnings
 normally are frowned upon(with good reason), using warnings for this would
allow
 the benefits from both "camps"...

 It would allow a painless "prototype porting" for new operating systems which
 are similar, yet... even if it does work, at a later point one would still have
 to go through all the version statements and either silencing the warning, or
 selecting the optimized path.
I know that we've all been trained to avoid copypasta, and have an instinctive "ick" factor when seeing it. But it really is not painful to do a little copypasta for the system versions, nor does there need to be any new language features for this.
Mar 18 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 17-03-2012 02:16, Daniel Murphy wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jk0naq$257e$1 digitalmars.com...
 But why duplicate doItSlowWay(); which may be an arbitrarily long
 sequence?
If duplicating that block is a problem, there are other ways to do it. version(ThisOS) { version = FastWayA; } else version(ThatOS) { version = FastWayB; } else version(SomeOS) { version = SlowWay; } else version(OtherOS) { version = SlowWay; } else static assert(0, "OS not implemented"); version(FastWayA) { .... } else version (FastWayB) { .... } else version (SlowWay) { .... }
 This seems to accomplish little more than "well I didn't use else".

 Again: what exactly is wrong with specialization?
The advantage is, that when you write the code, you have _no idea_ what platform/os it might need to run on in the future. You _cannot_ know which version is most appropriate for _all_ new platforms, or even if any of them will work at all. The only time to make this decision is when implementing support for a specific platform, and this pattern forces you to consider each place where platform specific behaviour is required. When doing things like this, 100 false positives are much faster to fix than a single false negative causing wrong code/corruption.
I think this post is basically proof that we need logical and/or in version statements. I'm just putting that out there.... -- - Alex
Mar 16 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jk0rr8$2c3n$1 digitalmars.com...
 I think this post is basically proof that we need logical and/or in 
 version statements. I'm just putting that out there....

 -- 
 - Alex
Yeah. While I agree with Walter's arguments against this, forcing that approch on everyone that uses D is not the language's job.
Mar 16 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2012 5:16 PM, Andrei Alexandrescu wrote:
 Not convinced. They call it specialization, and it's a powerful concept. We use
 it in std.algorithm all over the place.
I'll admit my argument may not sound convincing. But I've lived this problem for 25 years. Through trial and error, mostly error, I have found what works. Even if the default works, it's performance may be execrable, and it may get overlooked for years until bearophile(!) posts a benchmark showing it sux. Worse, the default may not even work properly on System X. By having no default, the porter quickly finds *all* of the system dependent code sections, and has to make a decision on each one. This is good. And it is NOT a burden. I can say this from experience. Quick test for the skeptical: find all of the default OS specific code in Phobos. (There's no straightforward way to do it.)
Mar 16 2012
parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
I think Walter and Andrei are both right, just about different things.

I think Walter is right that there is no such thing as a default 
implementation when it comes to compatibility with the host environment, 
and asserting is the best course of action.

I think Andrei is right that when a particular environment has some 
advantageous alternate implementation of a feature it can be used while 
leaving the default for the cases where said feature is unavailable.

Walter is concerned with compatibility, Andrei with opportunistic 
optimisation.

Knowing how to tell the difference is the real trick, and that is often 
a much harder thing to pin down. Code that potentially needs to be 
different on every platform should assert when the platform is 
unrecognised. Code which is specialised for just a few platforms and has 
a "known good" default can use else to provide said default. When 
unsure, assert is the more cautious option.

A...
Mar 17 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Pretty much. I'd expect to see:

version (linux) {
    // optimized impl
} else version (OSX) {
    version =3D UseDefault;
} else {
    static assert(false, "unknown platform");
}
version (UseDefault) {
    ...
}

This way, new platforms have to be evaluated, but once they are they can all=
 share whatever common implementation is the default.=20

On Mar 17, 2012, at 3:31 AM, Alix Pexton <alix.DOT.pexton gmail.DOT.com> wro=
te:

 I think Walter and Andrei are both right, just about different things.
=20
 I think Walter is right that there is no such thing as a default implement=
ation when it comes to compatibility with the host environment, and assertin= g is the best course of action.
=20
 I think Andrei is right that when a particular environment has some advant=
ageous alternate implementation of a feature it can be used while leaving th= e default for the cases where said feature is unavailable.
=20
 Walter is concerned with compatibility, Andrei with opportunistic optimisa=
tion.
=20
 Knowing how to tell the difference is the real trick, and that is often a m=
uch harder thing to pin down. Code that potentially needs to be different on= every platform should assert when the platform is unrecognised. Code which i= s specialised for just a few platforms and has a "known good" default can us= e else to provide said default. When unsure, assert is the more cautious opt= ion.
=20
 A...
Mar 17 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/17/12 9:10 AM, Sean Kelly wrote:
 Pretty much. I'd expect to see:

 version (linux) {
      // optimized impl
 } else version (OSX) {
      version = UseDefault;
 } else {
      static assert(false, "unknown platform");
 }
 version (UseDefault) {
      ...
 }
Taking this to its logical conclusion means that _all_ code that is currently unguarded must be guarded by version (UseDefault). Andrei
Mar 17 2012
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Mar 17, 2012, at 9:43 AM, Andrei Alexandrescu <SeeWebsiteForEmail erdani.=
org> wrote:

 On 3/17/12 9:10 AM, Sean Kelly wrote:
 Pretty much. I'd expect to see:
=20
 version (linux) {
     // optimized impl
 } else version (OSX) {
     version =3D UseDefault;
 } else {
     static assert(false, "unknown platform");
 }
 version (UseDefault) {
     ...
 }
=20 Taking this to its logical conclusion means that _all_ code that is curren=
tly unguarded must be guarded by version (UseDefault). No need for logical fallacies. My point was that for code where platform-sp= ecific optimizations are performed, construct the code in such a way that wh= en porting to a new platform, the compiler points at places that bear invest= igation.=20=
Mar 17 2012
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 17/03/2012 16:43, Andrei Alexandrescu wrote:
 On 3/17/12 9:10 AM, Sean Kelly wrote:
 Pretty much. I'd expect to see:

 version (linux) {
 // optimized impl
 } else version (OSX) {
 version = UseDefault;
 } else {
 static assert(false, "unknown platform");
 }
 version (UseDefault) {
 ...
 }
Taking this to its logical conclusion means that _all_ code that is currently unguarded must be guarded by version (UseDefault). Andrei
Firstly, I don't think the name "UseDefault" was well chosen for this example. I don't think its meant to be a catch all for every occasion when version statements are used. Perhaps "NoFeatureXyzIntrinsic" would be clearer. Secondly, if every line of D code is potentially platform-specific and/or inherently inefficient unless optimised with some case specific intrinsic, then there must be some glaring problems with the abstractions that the language provides. I will also reiterate that I believe that there are 2 different cases being considered together here. _Compatibility_, where asserting in the else of a version statement is the best course of action. _Opportunistic-Optimisation_, where providing a default case in the else as a fall back is quite sensible. The scenario which applies can often be easily deduced, it is my experience that optimisations are "versioned-in" while incompatibilities are "versioned-out". i.e. Adding a platform specific optimisation is "versioning-in", and the prior platform agnostic code becomes the default. Proofing a platform specific module is "versioning-out" removing inapplicable code and leaving a note for the maintainer that other platforms will require their own implementation. In the cases where the programmer does not have enough knowledge to know which scenario applies (perhaps not knowing if a particular intrinsic has compatible implementations across all platforms), I find it hard to find any argument in favour of providing a default action that may have unknown effects on another system. A...
Mar 17 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
In truth it would be

else version (Posix)

Anyway, which isn't the bare else Walter was advising against.=20

On Mar 17, 2012, at 5:10 PM, Alix Pexton <alix.DOT.pexton gmail.DOT.com> wro=
te:

 On 17/03/2012 16:43, Andrei Alexandrescu wrote:
 On 3/17/12 9:10 AM, Sean Kelly wrote:
 Pretty much. I'd expect to see:
=20
 version (linux) {
 // optimized impl
 } else version (OSX) {
 version =3D UseDefault;
 } else {
 static assert(false, "unknown platform");
 }
 version (UseDefault) {
 ...
 }
=20 Taking this to its logical conclusion means that _all_ code that is currently unguarded must be guarded by version (UseDefault). =20 Andrei =20 =20
=20 Firstly, I don't think the name "UseDefault" was well chosen for this exam=
ple. I don't think its meant to be a catch all for every occasion when versi= on statements are used. Perhaps "NoFeatureXyzIntrinsic" would be clearer.
=20
 Secondly, if every line of D code is potentially platform-specific and/or i=
nherently inefficient unless optimised with some case specific intrinsic, th= en there must be some glaring problems with the abstractions that the langua= ge provides.
=20
 I will also reiterate that I believe that there are 2 different cases bein=
g considered together here.
 _Compatibility_, where asserting in the else of a version statement is the=
best course of action.
 _Opportunistic-Optimisation_, where providing a default case in the else a=
s a fall back is quite sensible.
=20
 The scenario which applies can often be easily deduced, it is my experienc=
e that optimisations are "versioned-in" while incompatibilities are "version= ed-out".
 i.e. Adding a platform specific optimisation is "versioning-in", and the p=
rior platform agnostic code becomes the default. Proofing a platform specifi= c module is "versioning-out" removing inapplicable code and leaving a note f= or the maintainer that other platforms will require their own implementation= .
=20
 In the cases where the programmer does not have enough knowledge to know w=
hich scenario applies (perhaps not knowing if a particular intrinsic has com= patible implementations across all platforms), I find it hard to find any ar= gument in favour of providing a default action that may have unknown effects= on another system.
=20
 A...
Mar 17 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2012 5:40 PM, Sean Kelly wrote:
 In truth it would be

 else version (Posix)

 Anyway, which isn't the bare else Walter was advising against.
And is Posix really predictably compatible across diverse systems?
Mar 17 2012
next sibling parent reply "Bernard Helyer" <b.helyer gmail.com> writes:
On Sunday, 18 March 2012 at 00:53:17 UTC, Walter Bright wrote:
 On 3/17/2012 5:40 PM, Sean Kelly wrote:
 In truth it would be

 else version (Posix)

 Anyway, which isn't the bare else Walter was advising against.
And is Posix really predictably compatible across diverse systems?
If you restrict yourself to the LCD stuff, yeah mostly. The trouble is you get various nicer ways of doing things that aren't (as) portable.
Mar 17 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Mar 17, 2012, at 6:00 PM, "Bernard Helyer" <b.helyer gmail.com> wrote:

 On Sunday, 18 March 2012 at 00:53:17 UTC, Walter Bright wrote:
 On 3/17/2012 5:40 PM, Sean Kelly wrote:
 In truth it would be
=20
 else version (Posix)
=20
 Anyway, which isn't the bare else Walter was advising against.
=20 And is Posix really predictably compatible across diverse systems?
=20 If you restrict yourself to the LCD stuff, yeah mostly. The trouble is you=
get various nicer ways of doing things that aren't (as) portable. For what it's worth, core.sys.posix is based on the OpenGroup spec. I suppos= e that's the LCD.=20=
Mar 17 2012
parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Sunday, 18 March 2012 at 04:04:30 UTC, Sean Kelly wrote:
 On Mar 17, 2012, at 6:00 PM, "Bernard Helyer" 
 <b.helyer gmail.com> wrote:

 On Sunday, 18 March 2012 at 00:53:17 UTC, Walter Bright wrote:
 On 3/17/2012 5:40 PM, Sean Kelly wrote:
 In truth it would be
 
 else version (Posix)
 
 Anyway, which isn't the bare else Walter was advising 
 against.
And is Posix really predictably compatible across diverse systems?
If you restrict yourself to the LCD stuff, yeah mostly. The trouble is you get various nicer ways of doing things that aren't (as) portable.
For what it's worth, core.sys.posix is based on the OpenGroup spec. I suppose that's the LCD.
Yeah, I've not had problems with the OG stuff.
Mar 17 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Mar 17, 2012, at 5:53 PM, Walter Bright <newshound2 digitalmars.com> wrot=
e:

 On 3/17/2012 5:40 PM, Sean Kelly wrote:
 In truth it would be
=20
 else version (Posix)
=20
 Anyway, which isn't the bare else Walter was advising against.
=20 And is Posix really predictably compatible across diverse systems?
Pretty much. For a lot of calls the OS is allowed to declare them and just r= eturn an error code instead of actually doing what was intended, but the spe= c is otherwise pretty specific about how stuff should work. I've seen spotty= coverages at times (Interix, for example) but if present things tend to wor= k as expected.=20=
Mar 17 2012
prev sibling parent reply Jose Armando Garcia <jsancio gmail.com> writes:
On Sat, Mar 17, 2012 at 7:10 AM, Sean Kelly <sean invisibleduck.org> wrote:
 Pretty much. I'd expect to see:

 version (linux) {
 =A0 =A0// optimized impl
 } else version (OSX) {
 =A0 =A0version =3D UseDefault;
Speaking of version specification, in this particular example is version(UseDefault) only define on this module? The Language reference doesn't seem to mention anything explicitly about this. It does have the following: "Predefined version identifiers are global, i.e. they apply to all modules being compiled and imported." Does this mean that the opposite is true? 'version =3D UseDefault' is only define in the module defined. Thanks, -Jose
 } else {
 =A0 =A0static assert(false, "unknown platform");
 }
 version (UseDefault) {
 =A0 =A0...
 }

 This way, new platforms have to be evaluated, but once they are they can =
all share whatever common implementation is the default.
 On Mar 17, 2012, at 3:31 AM, Alix Pexton <alix.DOT.pexton gmail.DOT.com> =
wrote:
 I think Walter and Andrei are both right, just about different things.

 I think Walter is right that there is no such thing as a default impleme=
ntation when it comes to compatibility with the host environment, and asser= ting is the best course of action.
 I think Andrei is right that when a particular environment has some adva=
ntageous alternate implementation of a feature it can be used while leaving= the default for the cases where said feature is unavailable.
 Walter is concerned with compatibility, Andrei with opportunistic optimi=
sation.
 Knowing how to tell the difference is the real trick, and that is often =
a much harder thing to pin down. Code that potentially needs to be differen= t on every platform should assert when the platform is unrecognised. Code w= hich is specialised for just a few platforms and has a "known good" default= can use else to provide said default. When unsure, assert is the more caut= ious option.
 A...
Mar 17 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/17/2012 9:16 AM, Jose Armando Garcia wrote:
 On Sat, Mar 17, 2012 at 7:10 AM, Sean Kelly<sean invisibleduck.org>  wrote:
 version (linux) {
     // optimized impl
 } else version (OSX) {
     version = UseDefault;
Speaking of version specification, in this particular example is version(UseDefault) only define on this module?
version=identifier; declarations apply only to the module that declaration appears in.
Mar 17 2012
prev sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 17 March 2012 at 00:16:39 UTC, Andrei Alexandrescu 
wrote:
 Not convinced. They call it specialization, and it's a powerful 
 concept. We use it in std.algorithm all over the place.
I think having good-enough defaults works well for std.algorithm, simply because requiring explicit versions of everything would be tedious and error-prone. For platform-dependent code, I think requiring explicit versions is less tedious due to the relative infrequency of having to add a new platform. It's purely a matter magnitude. If std.algorithm only had to support say, five types, with a new type added maybe once a year, I think requiring explicit versions of every parameterized function would be a good idea, too. It forces you to think about things.
Mar 18 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Fri, 16 Mar 2012 21:00:47 +0100, Nick Sabalausky <a a.a> wrote:

 "Martin Nowak" <dawg dawgfoto.de> wrote in message
 news:op.wa9r9izqsqugbd localhost...
 On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Just found this, has anyone tried dmd or friends on OpenBSD?

 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
OpenBSD would need some druntime work.
Do you have anything in particular in mind?
Porting any POSIX/ELF OS should be very simple. - add OS detection to makefiles - add in OS specific struct layouts in core.sys (ucontext_t, siginfo_t, sockaddr...) - add rt.memory functions, using the linker script to find static segment brackets We use the following pattern all over the place. version (Windows) {} else version (OSX) {} else version (linux) {} else version (FreeBSD) {} else static assert(0); For anything but struct layouts the following would be correct. version (Windows) {} else version (linux, OSX) {} // iff specialized else version (POSIX) {} else static assert(0); Because of this you'll need to change core.{thread...} and dmd as well. I'm not stepping into the discussion below but I don't see the point of differencing FreeBSD, NetBSD, OpenBSD, DragonFlyBSD, Darwin, Solaris, OpenIndiana... After all that's what POSIX was made for. Have a look at core.sync.mutex which will work on all of these platforms.
Mar 17 2012
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 16.03.2012 15:53, schrieb Andrei Alexandrescu:
 Just found this, has anyone tried dmd or friends on OpenBSD?

 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd


 Thanks,

 Andrei
It is a bit off-topic, but I have started to look at a possible port to Minix 3.2.0, which now has NetBSD userland. But currently I am only playing around with the dmd source code. -- Paulo
Mar 16 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
 Just found this, has anyone tried dmd or friends on OpenBSD?

 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
There was a start on an OpenBSD port, but it hasn't progressed very far. It shouldn't be hard - if someone wants to pick up the flag on this and run with it, I'd be happy to fold in the changes.
Mar 16 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 16 Mar 2012 12:08:01 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
 Just found this, has anyone tried dmd or friends on OpenBSD?

 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
There was a start on an OpenBSD port, but it hasn't progressed very far. It shouldn't be hard - if someone wants to pick up the flag on this and run with it, I'd be happy to fold in the changes.
AFAICS OpenBSD doesn't support TLS (the __thread tls, posix pthread_getspecific works of course). Can D work at all without TLS support? (We have a similar problem with Android, I know for sure TLS isn't supported there.)
Mar 16 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Mar 16, 2012, at 2:19 PM, Johannes Pfau wrote:

 Am Fri, 16 Mar 2012 12:08:01 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:
=20
 On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
 Just found this, has anyone tried dmd or friends on OpenBSD?
=20
 =
http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
=20
 There was a start on an OpenBSD port, but it hasn't progressed very
 far. It shouldn't be hard - if someone wants to pick up the flag on
 this and run with it, I'd be happy to fold in the changes.
=20 AFAICS OpenBSD doesn't support TLS (the __thread tls, posix pthread_getspecific works of course). Can D work at all without TLS support? =20 (We have a similar problem with Android, I know for sure TLS isn't supported there.)
OSX pre-Lion doesn't support __thread either, so DMD rolls its own = there. The same functionality could probably be used for OpenBSD.
Mar 16 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 16 Mar 2012 14:37:43 -0700
schrieb Sean Kelly <sean invisibleduck.org>:

 On Mar 16, 2012, at 2:19 PM, Johannes Pfau wrote:
 
 Am Fri, 16 Mar 2012 12:08:01 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:
 
 On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
 Just found this, has anyone tried dmd or friends on OpenBSD?
 
 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
There was a start on an OpenBSD port, but it hasn't progressed very far. It shouldn't be hard - if someone wants to pick up the flag on this and run with it, I'd be happy to fold in the changes.
AFAICS OpenBSD doesn't support TLS (the __thread tls, posix pthread_getspecific works of course). Can D work at all without TLS support? (We have a similar problem with Android, I know for sure TLS isn't supported there.)
OSX pre-Lion doesn't support __thread either, so DMD rolls its own there. The same functionality could probably be used for OpenBSD.
That's interesting. GCC does have emulated TLS as well but GCC's implementation doesn't work with the GC. I guess the dmd tls emulation is in the backend, so nothing GDC could use?
Mar 17 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Mar 17, 2012, at 1:25 AM, Johannes Pfau <nospam example.com> wrote:

 Am Fri, 16 Mar 2012 14:37:43 -0700
 schrieb Sean Kelly <sean invisibleduck.org>:
=20
 On Mar 16, 2012, at 2:19 PM, Johannes Pfau wrote:
=20
 Am Fri, 16 Mar 2012 12:08:01 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:
=20
 On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
 Just found this, has anyone tried dmd or friends on OpenBSD?
=20
 http://stackoverflow.com/questions/9698581/programming-in-d-for-openbs=
d
=20
 There was a start on an OpenBSD port, but it hasn't progressed very
 far. It shouldn't be hard - if someone wants to pick up the flag on
 this and run with it, I'd be happy to fold in the changes.
=20 AFAICS OpenBSD doesn't support TLS (the __thread tls, posix pthread_getspecific works of course). Can D work at all without TLS support? =20 (We have a similar problem with Android, I know for sure TLS isn't supported there.)
=20 OSX pre-Lion doesn't support __thread either, so DMD rolls its own there. The same functionality could probably be used for OpenBSD. =20
=20 That's interesting. GCC does have emulated TLS as well but GCC's implementation doesn't work with the GC. I guess the dmd tls emulation is in the backend, so nothing GDC could use?
There's a bit of blackened support to denote tls data, but the rest is in li= brary. Look at core.thread.=20=
Mar 17 2012
parent Johannes Pfau <nospam example.com> writes:
Am Sat, 17 Mar 2012 07:04:20 -0700
schrieb Sean Kelly <sean invisibleduck.org>:

 On Mar 17, 2012, at 1:25 AM, Johannes Pfau <nospam example.com> wrote:
 
 Am Fri, 16 Mar 2012 14:37:43 -0700
 schrieb Sean Kelly <sean invisibleduck.org>:
 
 
 OSX pre-Lion doesn't support __thread either, so DMD rolls its own
 there.  The same functionality could probably be used for OpenBSD.
 
That's interesting. GCC does have emulated TLS as well but GCC's implementation doesn't work with the GC. I guess the dmd tls emulation is in the backend, so nothing GDC could use?
There's a bit of blackened support to denote tls data, but the rest is in library. Look at core.thread.
Thanks. I guess this could be supported in gdc (maybe it's already supported on OSX? I'll have to look that up), it doesn't look too complicated. But it won't work for dynamic libraries and/or dlopen, right?
Mar 17 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 AFAICS OpenBSD doesn't support TLS (the __thread tls, posix
 pthread_getspecific works of course). Can D work at all without TLS
 support?

 (We have a similar problem with Android, I know for sure TLS isn't
 supported there.)
Which is just strange given how little effort is needed to implement this in the runtime loader/libc. Now that C++11 has 'thread_local' the situation will hopefully improve soon.
Mar 17 2012