On 2013-01-08 21:49, Walter Bright wrote:

> So it won't run any 64 bit software?

It can run 64bit software just fine. Mac OS X has been able to do that for a long time. 10.6 was the first version the kernel tries to run in 64bit mode (depends on the computer).

Just because the kernel doesn't run in 64bit doesn't mean that the rest of the software can't run in 64bit.

> For at least a couple releases now, dmd for OS X has only included the
> 64 bit binaries for dmd. Not a single person has noticed (at least
> nobody has commented on it).
>
> We do build and test the OS X 32 bit dmd binaries, but left them off of
> the install package.

There is no problem.

-- 
/Jacob Carlborg

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

>> Me neither. Mac OS X 10.6 was released August 28, 2009. There have
>> been two
>> major releases since then.
>
> Sounds like we can pull the plug.

I've been trying to see if it's possible to get the market share for Mac OS X 10.6. This site claims it has just below 30% :

http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomb=*2

-- 
/Jacob Carlborg

On 2013-01-07 13:41, David Nadlinger wrote:

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

I've looked a bit at this and if we want to emulate TLS and support dynamic libraries on Mac OS X 10.6 I think we basically need to do what the dynamic linker does on 10.7.

-- 
/Jacob Carlborg

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've done some investigation. Currently DMD inserts a call to the __tls_get_addr function when accessing a TLS variable. This is implemented in druntime.

In Mac OS X 10.7 it works similar but instead of inserting a call to __tls_get_addr there's a struct looking like this (written in D) :

struct TLVDescriptor
{
    void* function (TLVDescriptor*) thunk;
    size_t key;
    size_t offset;
}

The dynamic linker will iterate all loaded images and extract the section containing the TLS data. I guess this section consists of a list of TLVDescriptor*. The dynamic linker will set the "thunk" to a function "tlv_get_addrs", implemented in assembly in the dynamic linker. It will set the key to a key created by "pthread_key_create". It will also map the image with this key. This key is same for all TLVDescriptor of a given image.

Instead of calling "__tls_get_addr" I think that the compiler will need to call the thunk passing in the TLVDescriptor itself to the thunk.

The "tlv_get_addrs" function will then extract the key and from that key it can get the image the address belongs to.

Does that make any sens? Is that something the DMD could do, that is call the thunk instead of "__tls_get_addr".?

-- 
/Jacob Carlborg

On Friday, January 04, 2013 14:13:22 Walter Bright wrote:
> On 1/3/2013 10:44 PM, Jonathan M Davis wrote:
> > P.S. Also, as a future improvement, we _really_ shouldn't be linking to bugzilla for our list. I've never seen a release notes document or changelog do that in my entire life. It would be _far_ more user friendly to list the changes like we did before with the bug number for each entry linking to the bug report (and it's what most projects to do from what I've seen).
> What we used to do was, literally (and I mean literally) copy/paste the bugzilla entry title and stick it in the changelog.
> 
> It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete.
> 
> I don't understand your rationale that it's _far_ more user friendly. It's the exact same list, in the exact same order, with the exact same text.

Okay, _far_ more friendly is probably an exaggeration, but I definitely think that it's unfriendly to redirect people to bugzilla for the changelog, and several other people have said the same in this thread.

The normal thing to do is do what we did before and list all of the changes on a single page which people can look over at a glance without caring one whit about bugzilla (beyond possibly clicking on one of the bug numbers for more details). It also means fewer clicks, because you don't have to click to get at any of the lists. I have _never_ seen any changelog other than ours use bugzilla queries for its contents. They're pretty much always done in a manner that allows them to be put in a text file (one which is frequently provided with the released files themselves or otherwise sitting in the repository along with the README and whatnot).

- Jonathan M Davis

On 1/9/13 12:43 AM, Jonathan M Davis wrote:
> On Friday, January 04, 2013 14:13:22 Walter Bright wrote:
>> It's THE SAME LIST as in the bugzilla list. It's even in the same order.
>> It's just that the bugzilla generated list is complete.
>>
>> I don't understand your rationale that it's _far_ more user friendly. It's
>> the exact same list, in the exact same order, with the exact same text.
>
> Okay, _far_ more friendly is probably an exaggeration

There is something to be said about proportional response. Shall we stop this now?

Thanks much,

Andrei

On Tuesday, January 08, 2013 16:25:10 Nick Sabalausky wrote:
> So then what's this "rvalue ref problem" that's "still on the front burner"?

auto ref / the problem that C++'s const & deals with. The ability to have a function which takes both lvalues and rvalues without copying them unless it has to. We have a solution for it with templated functions but no solution for non-templated functions.

- Jonathan M Davis

On Wednesday, January 09, 2013 00:52:32 Andrei Alexandrescu wrote:
> On 1/9/13 12:43 AM, Jonathan M Davis wrote:
> > On Friday, January 04, 2013 14:13:22 Walter Bright wrote:
> >> It's THE SAME LIST as in the bugzilla list. It's even in the same order. It's just that the bugzilla generated list is complete.
> >> 
> >> I don't understand your rationale that it's _far_ more user friendly.
> >> It's
> >> the exact same list, in the exact same order, with the exact same text.
> > 
> > Okay, _far_ more friendly is probably an exaggeration
> 
> There is something to be said about proportional response. Shall we stop this now?

I think that it's important, and other people in this thread have agreed with me (anyone other than Walter who has disagreed has been silent on the issue). But I gather that you don't agree.

- Jonathan M Davis

We have a solution for it with templated functions but
> no solution for
> non-templated functions.

We have: https://github.com/D-Programming-Language/dmd/pull/1019
It's ready to merge. So maybe in 2.062 this problem is solved.

On Wednesday, 9 January 2013 at 07:57:12 UTC, Jacob Carlborg wrote:
> 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've done some investigation. Currently DMD inserts a call to the __tls_get_addr function when accessing a TLS variable. This is implemented in druntime.
>
> In Mac OS X 10.7 it works similar but instead of inserting a call to __tls_get_addr there's a struct looking like this (written in D) :
>
> struct TLVDescriptor
> {
>     void* function (TLVDescriptor*) thunk;
>     size_t key;
>     size_t offset;
> }
>
> The dynamic linker will iterate all loaded images and extract the section containing the TLS data. I guess this section consists of a list of TLVDescriptor*. The dynamic linker will set the "thunk" to a function "tlv_get_addrs", implemented in assembly in the dynamic linker. It will set the key to a key created by "pthread_key_create". It will also map the image with this key. This key is same for all TLVDescriptor of a given image.
>
> Instead of calling "__tls_get_addr" I think that the compiler will need to call the thunk passing in the TLVDescriptor itself to the thunk.
>
> The "tlv_get_addrs" function will then extract the key and from that key it can get the image the address belongs to.
>
> Does that make any sens? Is that something the DMD could do, that is call the thunk instead of "__tls_get_addr".?

Isn't it horrible performancewise ?