On 4/11/2017 6:46 AM, Jacob Carlborg wrote:
> http://www.sealiesoftware.com/blog/archive/2009/01/27/objc_explain_Non-fragile_ivars.html

Looks like it solves it by adding another layer of indirection:

"the performance overhead of the extra ivar offset variable is small."

On 11 April 2017 at 14:11, Matthias Klumpp via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
>>
>> On 10 April 2017 at 23:52, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Monday, 10 April 2017 at 20:43:06 UTC, Iain Buclaw wrote:
>>>>
>>>>
>>>> Master sports Phobos 2.071.  Someone will have to see whether latter versions can be built using it.
>>>
>>>
>>>
>>> … and some weird Frankensteinian mix of several frontend versions, I take it, maybe enough to build Phobos, but not necessarily compatible for user code? Or did you port all the changes since 2.068.2 back to C++?
>>>
>>>  — David
>>
>>
>> All the regression fixes and none of the bugs!
>>
>> The current situation is that it should be link-compatible with current upstream/stable.  Enough so that when someone has the time to test, it should just be a case switching the sources and building the D version.
>
>
> First of all, thank you for your tremendous work on GDC! Fellow developers and me were also pretty stunned by you maintaining a quite large amount of different GDC versions in parallel without a huge team - that's some impressive work!
>

It was worse when we were using `#if D_GCC_VER == 33' macros to support all versions in the same branch. ;-)

Having a really good CI helps too for when the periodic merges are done.


> What is the thing that's blocking GDCs GCC inclusion? Just manpower? Also,
> you were talking about "bugs" on several occasions, what's the thing with
> that? Is it GCC or general Phobos bugs? It would probably be awesome to have
> a summary blogpost or similar on the state of GDC, that could potentially
> also attract volunteers.
> Anyway, all a bit off-topic :-)

Manpower has got something to do with it when you have two fast ships sailing and you have one foot in each.

I think I only mentioned bugs once here, and was talking strictly about the D front-end, which deals with the parsing and semantic analysis of D sources.  Every release there are listed new features, regressions fixed, etc.  The regressions fixed have a higher precedent for me at least.

On Tue, 2017-04-11 at 17:02 +0000, David Nadlinger via Digitalmars-d wrote:
> On Tuesday, 11 April 2017 at 14:49:03 UTC, Russel Winder wrote:
> > Having played a bit with GtkD, you always want this as a shared library for development.
> 
> Why would a shared library be preferable to a static library for that (which might still be re-used between different projects, etc.)?
> 

I have only the data that compiling and linking a GtkD application against a shared library is a lot shorter than against a static library. I'll get proper data, but tomorrow – that upstairs have a water leak and our kitchen ceiling is about to fall in (again, third time) means I am not competent just now.

Hassle me Thursday if I have presented data.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
> All the regression fixes and none of the bugs!

That's an interesting approach (spoken with British language sensibilities).

Is anybody using GDC on a big "modern" D2 codebase (metaprogramming-heavy, …) right now? From my experience with Thrift, Weka, and so on, even regression fixes have a habit of breaking that sort of code in weird and wonderful ways. And that's not even mentioning other improvements/fixes/additions people might be relying on.

Right now, the frontend version serves as a convenient aid for users to navigate those issues (apart, of course, from us trying to improve things by making semantic analysis more deterministic, etc). If something works on DMD 2.072.2, then users can also expect it to work on the corresponding LDC version as well. I'm not sure you are helping anybody by introducing another set of weird in-between versions.

 — David

On Tuesday, 11 April 2017 at 12:03:27 UTC, Matthias Klumpp wrote:
> On Monday, 10 April 2017 at 22:15:53 UTC, David Nadlinger wrote:
>> So do we need to put a reminder about the ABI being unstable into set of every release notes to make sure we won't get angry bug reports once users actually build their own D code against your packages? ;)
>
> Nah, there are several options here, one would simply be to tell people not to use the distro packages with anything but the default D compiler used in the respective Debian release.

So as long as one sticks to packages in the official apt repos, all the libraries are guaranteed to be built with the distributed compiler as well?

When you mentioned that you'd read the release notes regarding the ABI change, I got the impression that you had to manually rebuild the world for that to happen – hence my tongue-in-cheek remark about reminding you to do this in the release notes.

Otherwise, you might get lucky as far as the distributed applications are concerned (i.e. happen not to hit any ABI issues), but users might still be hosed when it comes to their own code.

 — David

On Tuesday, 11 April 2017 at 18:13:11 UTC, Russel Winder wrote:
> I have only the data that compiling and linking a GtkD application against a shared library is a lot shorter than against a static library.

Sure, but that might be easily fixed, and if you really want to use shared libraries, you can always make Dub create/use a library in a local directory (and set the rpath appropriately, …). I don't quite see how any of this is related to the topic at hand (distro packaging).

I'd indeed be interested in some data on the linking times, though. Be sure to test with ld.gold as well, if you are not using it already.

 — David

On 2017-04-11 19:34, Walter Bright wrote:

> Looks like it solves it by adding another layer of indirection:
>
> "the performance overhead of the extra ivar offset variable is small."

Yes, there are always tradeoffs. But as you've said, exceptions are already slow ;)

-- 
/Jacob Carlborg

On Tuesday, 11 April 2017 at 18:14:40 UTC, David Nadlinger wrote:
> On Tuesday, 11 April 2017 at 12:03:27 UTC, Matthias Klumpp wrote:
>> On Monday, 10 April 2017 at 22:15:53 UTC, David Nadlinger wrote:
>>> So do we need to put a reminder about the ABI being unstable into set of every release notes to make sure we won't get angry bug reports once users actually build their own D code against your packages? ;)
>>
>> Nah, there are several options here, one would simply be to tell people not to use the distro packages with anything but the default D compiler used in the respective Debian release.
>
> So as long as one sticks to packages in the official apt repos, all the libraries are guaranteed to be built with the distributed compiler as well?

Yes. Unfortunately there will be three of them which aren't compatible with each other, so we will kind of have to settle with one as default.

> When you mentioned that you'd read the release notes regarding the ABI change, I got the impression that you had to manually rebuild the world for that to happen – hence my tongue-in-cheek remark about reminding you to do this in the release notes.

Well, it's a matter of telling the build admins or making a proper transition package (doesn't exit yet for D), but yeah, technically we'd need to rebuild all D stuff on ABI changes.

On 11 April 2017 at 20:13, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
>>
>> All the regression fixes and none of the bugs!
>
>
> That's an interesting approach (spoken with British language sensibilities).
>
> Is anybody using GDC on a big "modern" D2 codebase (metaprogramming-heavy, …) right now? From my experience with Thrift, Weka, and so on, even regression fixes have a habit of breaking that sort of code in weird and wonderful ways. And that's not even mentioning other improvements/fixes/additions people might be relying on.
>
> Right now, the frontend version serves as a convenient aid for users to navigate those issues (apart, of course, from us trying to improve things by making semantic analysis more deterministic, etc). If something works on DMD 2.072.2, then users can also expect it to work on the corresponding LDC version as well. I'm not sure you are helping anybody by introducing another set of weird in-between versions.
>
>  — David

And DMD didn't help by switching codebase to D without first ironing out all implementation regressions and interoperability.  Every release between 2.069 and 2.074 is a broken release as far I'm concerned.  The most recent is getting closer, but there are likely still many things missing that need to be exposed to C++ (mostly ::create functions).

Am Tue, 11 Apr 2017 14:21:57 +0000
schrieb Matthias Klumpp <mak@debian.org>:

> can be used by Automake (native),

Do you maintain D support for automake? I wrote some basic D support
for autoconf and libtool
(https://github.com/D-Programming-GDC/GDC/tree/master/libphobos/m4) but
no automake support except for some hacks in
https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/d_rules.am

I guess I should upstream this some time.

-- Johannes