On 2012-12-10 13:43, Walter Bright wrote:

> BTW, I've fixed every bug report on the dynamic libraries where anyone
> identified an issue with how dmd generates PIC code for dynamic libraries.

Yeah, that's great. But that doesn't make dynamic libraries magically work. The runtime still need to support it. On Mac OS X there will most likely need to be made some changes to the compiler as well. I'm thinking mostly to support TLS, the ___tls_get_addr need to receive an image (mach_header) in addition to the address of the variable.

-- 
/Jacob Carlborg

On 2012-12-10 14:03, Jacob Carlborg wrote:

> Yeah, that's great. But that doesn't make dynamic libraries magically
> work. The runtime still need to support it. On Mac OS X there will most
> likely need to be made some changes to the compiler as well. I'm
> thinking mostly to support TLS, the ___tls_get_addr need to receive an
> image (mach_header) in addition to the address of the variable.

On the other hand, TLS has nothing to do with D1, my bad.

-- 
/Jacob Carlborg

On 12/10/2012 5:03 AM, Jacob Carlborg wrote:
> On 2012-12-10 13:43, Walter Bright wrote:
>
>> BTW, I've fixed every bug report on the dynamic libraries where anyone
>> identified an issue with how dmd generates PIC code for dynamic libraries.
>
> Yeah, that's great. But that doesn't make dynamic libraries magically work. The
> runtime still need to support it.

I know.

10.12.2012 15:11, Walter Bright пишет:
> On 12/10/2012 12:56 AM, Denis Shelomovskij wrote:
>> A long time ago I wrote one (not open source) application in D1+Tango.
>> I'm still supporting it. The last D1 compiler I can use is 1.066 as
>> then a fatal
>> regression was introduced and templates became unusable because of
>> ICE. Am I the
>> only one who use templates in D1? If not, what is the purpose for all
>> this
>> needless D1 releases as compiler doesn't work for almost any project with
>> templates?
>
> What is the bugzilla issue number for that? In bugzilla, you can tag
> issues as being "regressions", and I don't recall seeing one like you
> describe. Here is the current list of regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>
>
>
>> And let me beat utterly:
>>
>> Now imagine: a person updated a compiler and get ICE. On *huge*
>> codebase. What
>> will he do? He will use old working one. But I decided to go further,
>> found a
>> DustMite and decided to find the source of the error. Do you know that
>> current
>> D2 compiler ICE-s with compiling DustMite? Imagine, what will feel a
>> person when
>> bug finding tool ICE-s a compiler? He will probably consider "D is a
>> peace of
>> unstable shit" and go away.
>>
>> And he will be right as it is unforgivable for us to talk about any
>> "stability"
>> of D. "D is for crazy nerd who are ready to find, report and
>> workaround infinite
>> compiler bugs on any complicated code with templates", that's all we
>> can tell.
>>
>> But I finally managed to compile DustMite without ICE, found the
>> regression and
>> reported. Still unfixed...
>
> What is the bugzilla issue number?
>

This was the result of DustMite-ing my sources:
http://d.puremagic.com/issues/show_bug.cgi?id=6296

Currently the bug state is a bit confusing. It is a regression (but I didn't mark it that way, only write in description, sorry) but is resolved as a duplicate of a non-regression unfixed bug 4269. It was a small war between "regression" and "normal" state of 4269 and now it is marked as "normal".

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Sun, Dec 09, 2012 at 11:16:32PM -0800, Jonathan M Davis wrote:
> On Monday, December 10, 2012 08:11:52 deadalnix wrote:
> > 3/ Now that UDA are in master, what to do with them ? They clearly are not ready for release.
> 
> Move them to a branch and remove them from master.
[...]

Wouldn't this be the right time to put the D stable idea to work? Leave UDA in master, but create a 2.061 release branch without UDA, and release that.


T

-- 
Любишь кататься - люби и саночки возить.

On 2012-12-10 20:41, H. S. Teoh wrote:

> Wouldn't this be the right time to put the D stable idea to work? Leave
> UDA in master, but create a 2.061 release branch without UDA, and
> release that.

I think it's the right time.

-- 
/Jacob Carlborg

On Monday, December 10, 2012 11:41:29 H. S. Teoh wrote:
> On Sun, Dec 09, 2012 at 11:16:32PM -0800, Jonathan M Davis wrote:
> > On Monday, December 10, 2012 08:11:52 deadalnix wrote:
> > > 3/ Now that UDA are in master, what to do with them ? They clearly are not ready for release.
> > 
> > Move them to a branch and remove them from master.
> 
> [...]
> 
> Wouldn't this be the right time to put the D stable idea to work? Leave UDA in master, but create a 2.061 release branch without UDA, and release that.

D stable is being run by someone else. It seems like the current plan is for us to continue to put out releases like we have been but the D stable folks will manage a separate repo which only has the stable changes and then fully syncs up with master at some interval. Whether that's the best way to deal with it is another matter, but that at least looks like what they're planning on doing.

Regardless, the UDA stuff can't be in the next release. If we want to create a branch that we do the release from (which we should be doing anyway), then UDA can be explicitly removed from there rather than master, but it needs to not be released regardless.

How D stable gets managed is a related matter, but based on the discussions on that, I expect that that will be sorted out _after_ the next release rather than with the next release (particularly since this is the last release with D1, and Walter is more open to changing how does things after he doesn't have to support D1 anymore).

- Jonathan M Davis

On Monday, December 10, 2012 13:30:39 Jacob Carlborg wrote:
> On 2012-12-10 12:07, Walter Bright wrote:
> > If someone wants to do the work to support them, I'll fold it in.
> 
> Same old, same old. I guess I have to do it myself if I want something done.

That's the way that it works with pretty much everything around here. It's just that there are more people working on D2 and its components than D1. In either case, if no one else has the time or inclination to do what you want, you have to do it. It's one of the major downsides to a volunteer work force.

- Jonathan M Davis

On 2012-12-10 21:04, Jonathan M Davis wrote:

> That's the way that it works with pretty much everything around here. It's
> just that there are more people working on D2 and its components than D1. In
> either case, if no one else has the time or inclination to do what you want,
> you have to do it. It's one of the major downsides to a volunteer work force.

I would think that others have interest in this as well. And it's not just for D1, it's for D2 as well.

-- 
/Jacob Carlborg

On 12/10/2012 12:55 PM, Jacob Carlborg wrote:
> I would think that others have interest in this as well. And it's not just for
> D1, it's for D2 as well.

If that was the only thing others have interest in, then it would be top priority. But there are endless "why haven't you fixed xxx yet?" issues.