On 13-01-10 12:17 AM, Andrei Alexandrescu wrote:
On 1/9/13 9:15 PM, Pierre Rouleau wrote:
On 13-01-08 9:09 PM, Andrei Alexandrescu wrote:
Would it also make sense to have a separate mailing list to post and
discuss D development process announcements such as this important one?
That would ma
On 13-01-08 9:09 PM, Andrei Alexandrescu wrote:
As part of our continued efforts to improve the process, we have added
the "preapproved" tag to bugzilla.
An enhancement request that has the "preapproved" tag is considered
reviewed and vetted by Walter (and myself on occasion). An
implementation
On 1/9/2013 11:02 AM, Jacob Carlborg wrote:
As I said, I don't know assembly but here's the output:
Good time to learn it!
And I'm not kidding.
On 1/9/13 9:15 PM, Pierre Rouleau wrote:
On 13-01-08 9:09 PM, Andrei Alexandrescu wrote:
As part of our continued efforts to improve the process, we have added
the "preapproved" tag to bugzilla.
An enhancement request that has the "preapproved" tag is considered
reviewed and vetted by Walter (
On 13-01-10 12:15 AM, Pierre Rouleau wrote:
That would make it easier for some trying to learn the development
process of the group.
s/some/someone/
--
/Pierre Rouleau
On 1/4/2013 12:10 PM, r_m_r wrote:
I was wondering if it is possible to integrate some javascript in the changelog
page to automatically generate the list of fixed issues as suggested by Jonathan
(As an example, please see the attached file: jq.html).
Thanks for doing this. It's an interesting
On 2013-01-09 11:38, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup
records. Then there's no need to guess :-)
As I said, I don't know assembly but here's the output:
Original
On Wed, 9 Jan 2013 12:54:54 -0500
Nick Sabalausky wrote:
> Yea, this change is definitely a notable step backwards in
> presentation and usability.
>
And it doesn't help that, once again, the changelog is showing the
*next* release with no indication that it hasn't actually been released.
On 2013-01-09 19:53, John Colvin wrote:
Surely __thread is redundant there, seeing as x will be TLS by default?
We're talking C here and it's not default in C.
--
/Jacob Carlborg
On Wednesday, 9 January 2013 at 10:38:33 UTC, Walter Bright wrote:
On 1/9/2013 2:28 AM, Jacob Carlborg wrote:
On 2013-01-09 11:26, Jacob Carlborg wrote:
I think it sounds like that but I don't know. I'm just trying
to figure
out how TLS is implemented on Mac OS X 10.7+.
Also, there's nothin
On 2013-01-09 17:16, David Nadlinger wrote:
I also think this is the best way of approaching such problems. If you
can, also try to find the source code for the involved code. In case of
trying to understand the OS X TLS mechanism, I found the following files
from dyld to be helpful:
http://ope
On Wed, 09 Jan 2013 01:09:21 -0800
Jonathan M Davis wrote:
> 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 e
On Wednesday, 9 January 2013 at 10:38:33 UTC, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the
fixup records. Then there's no need to guess :-)
I also think this is the best way of appr
On 2013-01-09 11:38, Walter Bright wrote:
Watcha do is something like this:
__thread int x;
int foo() { return x; }
Compile, disassemble, and look at the code generated and the fixup
records. Then there's no need to guess :-)
Sure, I've already done that. I compared one version using "__thre
Leandro Lucarella:
And given how D community works, seems to make more sense to put
"Improvement Proposals" in bugzilla directly. The only drawback
I see on
this is maybe big improvement proposals get less visibility and
are not
easily differentiable from minor enhancements or even bugs.
Le
Andrei Alexandrescu, el 8 de January a las 18:09 me escribiste:
> Hello,
>
>
> As part of our continued efforts to improve the process, we have
> added the "preapproved" tag to bugzilla.
>
> An enhancement request that has the "preapproved" tag is considered
> reviewed and vetted by Walter (and
bearophile, el 9 de January a las 04:05 me escribiste:
> Andrei Alexandrescu:
>
> >We will follow later today with a preapproved enhancement request.
> >(Of course, we will also preapprove enhancements written by
> >others, too.)
>
> I don't remember of other language communities doing this, but
On Wed, Jan 9, 2013 at 9:52 AM, Andrei Alexandrescu
wrote:
> There is something to be said about proportional response. Shall we stop this
> now?
I propose to start another thread, maybe more constructive, where I
propose a small text describing what's new in 2.061. Is that OK?
On 1/9/2013 2:28 AM, Jacob Carlborg wrote:
On 2013-01-09 11:26, Jacob Carlborg wrote:
I think it sounds like that but I don't know. I'm just trying to figure
out how TLS is implemented on Mac OS X 10.7+.
Also, there's nothing else that calls this tlv_get_addr function or the thunk so
I'm gues
On 2013-01-09 11:00, deadalnix wrote:
Isn't it horrible performancewise ?
I think it sounds like that but I don't know. I'm just trying to figure
out how TLS is implemented on Mac OS X 10.7+.
--
/Jacob Carlborg
On 2013-01-09 11:26, Jacob Carlborg wrote:
I think it sounds like that but I don't know. I'm just trying to figure
out how TLS is implemented on Mac OS X 10.7+.
Also, there's nothing else that calls this tlv_get_addr function or the
thunk so I'm guessing it's the compiler that calls it.
--
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
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, 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 lis
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
h
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 frie
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 wo
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
28 matches
Mail list logo