On 1/6/2013 11:57 PM, Jacob Carlborg wrote:
> On 2013-01-07 00:14, Walter Bright wrote:
>
>> Where it is not implemented is in druntime. The folks who work on
>> druntime are the ones that need convincing.
>
> I didn't know you had stopped working on the runtime.

I now focus on the compiler, though I'll contribute now and then on the library.

On 2013-01-07 01:36, Walter Bright wrote:

> The thing is, roadmaps are a lot like planning for a war. The moment the
> first shot is fired, all the plans go out the window. What we need to
> get done next is a constantly evolving situation, based on:

On occasion developer are asking what they can work on and then we don't have a roadmap to point to.

-- 
/Jacob Carlborg

On Sunday, 6 January 2013 at 23:19:48 UTC, Walter Bright wrote:
> DMD implements its own TLS on OS X because the OS X C compiler says "not implemented" when you try to create TLS variables. I had no other option.

Note that this no longer appears to be the case, at least with clang (OS X 10.7.5):
----
#include <stdio.h>
__thread int foo;
int main(){
    foo = 4;
    printf("%d\n", foo);
}
----
$ clang test.c
$ ./a.out
4
$ clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.2
Thread model: posix

(llvm-)gcc still complains:
$ gcc test.c
test.c:2: error: thread-local storage not supported for this target
$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Though I believe it will probably fail with older OS X versions which don't have TLS support.

Robert

On 2013-01-07 11:14, Robert Clipsham wrote:

> Note that this no longer appears to be the case, at least with clang (OS
> X 10.7.5):

Mac OS X Lion (10.7) got support for TLS. But that means that the whole TLS needs to be redone in the compiler (output data to correct segments and similar) and in the runtime. The compiler would also need to be able to fallback to emulating as it currently does or we will loose the support for Mac OS X 10.6. Alternatively it might be possible to run the "real" TLS on Mac OS X 10.6 but then we would need to implement some parts of the dynamic linker into the D runtime.

-- 
/Jacob Carlborg

On Monday, 7 January 2013 at 10:14:54 UTC, Robert Clipsham wrote:
> Though I believe it will probably fail with older OS X versions which don't have TLS support.

Yes, it is not supported by linker and dyld versions shipping with OS X 10.7. This is also the reason why LDC 2 only supports OS X 10.7+, as LLVM does not implement a workaround for older versions (although implementing one up to the point where it is good enough for D should be doable without too much effort).

David

On 01/06/2013 10:18 PM, Pierre Rouleau wrote:
> On 13-01-06 9:45 PM, Jonathan M Davis wrote:
>> On Sunday, January 06, 2013 21:22:18 Pierre Rouleau wrote:
>>> Is this something that the most influential people in the D project want
>>> to fix?
>>
>> What exactly do you want fixed?
>
> Really, I would like to be able to start using D at work. And be in a
> position to be able to convince people to use it.

I found myself in the same position. My argument was:
 1. There is a clear language reference
 2. There are multiple implementations (DMD, GDC)
 3. D has a lot of really nice features that make it better than C

Now, you have to bear in mind, we don't do bytecode compiled languages that run on a VM - it's just not our thing, we use too much real hardware. Basically, D gives us all the fancy nice Java and C# features while letting us access real hardware without having to write a C shim to do it.

We do not require a fancy cohesive roadmap, because we realize it's a FLOSS project and is therefore subject to the whims of its developers. If we want to influence said development, then we'll jump in or issue a bounty for things to be fixed.

In the grand scheme of things, we've found this strategy to produce more time savings and value than it consumes. However, this does take a certain amount of buy in from your company management. Luckily, one of the company founders was an early embracer of Linux.

-- 
Matthew Caron, Software Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office

On 01/05/2013 03:01 AM, Nick Sabalausky wrote:
> On Thu, 03 Jan 2013 08:20:19 -0500
> Matthew Caron <matt.caron@redlion.net> wrote:
>
>> On 01/02/2013 04:18 PM, Walter Bright wrote:
>>>> Why would you need to? If your mail store is IMAP, just let it
>>>> rebuild.
>>>
>>> I don't store email on the server, I store it locally.
>>
>> I gave that up years ago when I ended up with more than one device.
>> Too much "did I get that email on my laptop or my desktop?" And now
>> with tablet, phone, laptop, desktop, and several kiosk machines
>> around the house (because how else do you watch Firefly whilst
>> loading custom hunting ammunition in the gun room?) and then the
>> device proliferation continues...
>>
>
> Turn off "Delete email from server ten seconds after downloading it".
> Either increase it to a sane time period, or disable delete-from-server
> entirely. Problem solved. Worked fine for me.

Isn't this just "leave email on the server", which is what I suggested?

Of course, what you're saying is "use POP with leave on server enabled". A better solution is to just use IMAP.

> Accessing *sent* messages can be a different story though, but using
> your email client's setting for "BCC outgoing messages to..." to send
> to a special "messages I sent" address works well enough. Unless you
> need to use some shitty Fisher-Price email client like the one in iOS,
> because then you're just fucked. (But if you need to rely on iOS,
> you'll probably have bigger problems anyway.)

Or, you just use IMAP.

>> Windows is only
>> suitable for playing video games, and I'm looking forward to Steam's
>> release for Linux such that I can power on the Wintendo less and
>> less.
>
> Steam on Linux? That's like installing hydraulics on a Formula 1
> or a rusty nail in a jock strap. Nothing that involves "Steam" is
> suitable for playing videogames, whether Win/Lin or anything else.

It's view it as an online shop which allows you to buy and install games for your platform. I have no issue with this. I don't use all the fancy extra social video game crap.

> I'd be willing to *release* a game, *non-exclusively*, on steam just
> for the visibility and for the subset of PC gamers that are
> unfortunately dumb enough to think steam isn't DRM, but that's all
> steam is good for. Gabe can suck the shit out of my ass for destroying
> the last non-orwellian gaming platform in existence and
> essentially turning it into a goddamn iPhone.

You don't have to use it, you know. There are other games. GOG.com has a pile, and many of them run just fine under Wine and or DosBOX. I'd like to see them do more Linux, and I hope that the Steam port will be the beginning of more entries on to the platform.

(Of course, I thought the same thing about Loki)
-- 
Matthew Caron, Software Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office

On 13-01-07 7:49 AM, Matthew Caron wrote:
> On 01/06/2013 10:18 PM, Pierre Rouleau wrote:
>> On 13-01-06 9:45 PM, Jonathan M Davis wrote:
>>> On Sunday, January 06, 2013 21:22:18 Pierre Rouleau wrote:
>>>> Is this something that the most influential people in the D project
>>>> want
>>>> to fix?
>>>
>>> What exactly do you want fixed?
>>
>> Really, I would like to be able to start using D at work. And be in a
>> position to be able to convince people to use it.
>
> However, this does take a
> certain amount of buy in from your company management.

It does, and from other people too.

> Luckily, one of
> the company founders was an early embracer of Linux.
>
It's not the case for my situation.

The worst part I see is that bug fixes and new feature introductions are lumped together inside releases. Combined with the fact that the development is not predictable means that if you develop products with D you have to keep updating it.  If you get stuck with a bug and wait for the release that fixes it, when that release comes out it could very well bring new language features that break the code that you have already written.

It would be nice to have bug fixes separated from new feature introductions by having major and minor releases and branches for these releases.  Contributors of a release could backport bug fix in the release they use if that was required by their project using the now old compiler version.

Of course I realize that this means more overall work, more people, someone or a set of people in charge of release management, etc...



-- 
/Pierre Rouleau

On 2013-01-07 09:04, Walter Bright wrote:

> Please nail down what is necessary first. (BTW, I don't know how the
> compiler can tell what image an address comes from. Remember, shared
> libraries are loaded at runtime, not compile time.)

I'll try and do that.

-- 
/Jacob Carlborg

On 01/07/2013 08:09 AM, Pierre Rouleau wrote:
> It would be nice to have bug fixes separated from new feature
> introductions by having major and minor releases and branches for these
> releases.  Contributors of a release could backport bug fix in the
> release they use if that was required by their project using the now old
> compiler version.
>
> Of course I realize that this means more overall work, more people,
> someone or a set of people in charge of release management, etc...

I also think that you'd be hard-pressed to find anyone who does development like that, proprietary or open source. It's not uncommon to have bugfix only releases, but having a new features release that doesn't fix any bugs is, in my experience, unheard of.

Also, I'd be STRONGLY against it, because I have a fix bugs first mentality, and if you find a bug while implementing a new feature, it should be fixed.


-- 
Matthew Caron, Software Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office