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