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.

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:
>> 
>> 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).

No need for logical fallacies.  My point was that for code where platform-specific optimizations are performed, construct the code in such a way that when porting to a new platform, the compiler points at places that bear investigation.

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?

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.

> 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.

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...

In truth it would be

else version (Posix)

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

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

> 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...

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?

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.

On Mar 17, 2012, at 5:53 PM, Walter Bright <newshound2@digitalmars.com> 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?

Pretty much. For a lot of calls the OS is allowed to declare them and just return an error code instead of actually doing what was intended, but the spec 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 work as expected.