September 09, 2015
On 09/09/2015 09:45 PM, Brad Roberts via dmd-internals wrote:
> I'm very much in favor of seeing shared libraries become a reality, but there's a necessary process that's needed to ensure the required behavior: backwards abi compatibility.  The major projects that ship shared libraries (ie, libgcc, libc, etc) have tooling (that I've never looked at) to detect breakage.  This covers both no changes to existing symbols as well as controlled and acknowledged introduction of new symbols.  Production quality shared library support is a big step up in responsibility.

We just killed the idea to make shared libraries the default.
https://github.com/D-Programming-Language/dmd/pull/5044
I don't think a stable ABI is feasible anytime soon and w/o that shared
libraries are a PITA.
But I still want to ship shared libs with FBSD so that they can be used
optionally.



September 09, 2015
On 09/09/2015 09:40 PM, Vladimir Panteleev via dmd-internals wrote:
> That's just cold. So do you want me to stop checking if filed bugs are regressions? That doesn't seem logical to me.
> 
> Many people seem to not realize that the bugs they run into are actually regressions and their code worked fine in older versions of D, but I do not think that these are less important to fix.

Sorry if that sounded harsh. All I'm saying is that we need to be
careful when filling our only prioritization scheme, e.g. try to look at
https://issues.dlang.org/buglist.cgi?cmdtype=runnamed&namedcmd=regression and
tell me what's important.

>> b/c that's the only working communication channel we have for high priority stuff.
> 
> Bugzilla has a priority field, but it doesn't seem to be used much.

Indeed, there is priority and severity. We should use both much more consistently b/c there are important bugs (affecting many users) that aren't severe and severe regressions that aren't too important.



September 09, 2015
On 9/9/15 1:08 PM, Martin Nowak via dmd-internals wrote:
> On 09/09/2015 09:45 PM, Brad Roberts via dmd-internals wrote:
>> I'm very much in favor of seeing shared libraries become a reality, but
>> there's a necessary process that's needed to ensure the required
>> behavior: backwards abi compatibility.  The major projects that ship
>> shared libraries (ie, libgcc, libc, etc) have tooling (that I've never
>> looked at) to detect breakage.  This covers both no changes to existing
>> symbols as well as controlled and acknowledged introduction of new
>> symbols.  Production quality shared library support is a big step up in
>> responsibility.
>
> We just killed the idea to make shared libraries the default.
> https://github.com/D-Programming-Language/dmd/pull/5044
> I don't think a stable ABI is feasible anytime soon and w/o that shared
> libraries are a PITA.
> But I still want to ship shared libs with FBSD so that they can be used
> optionally.

I know it's a terminology nitpick, but it outlines a typical pattern in communication w/in the D community.  Very black and white thinking.  The idea isn't killed, it's just deferred.  And not building towards it is certainly going to defer it for a long time.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
September 09, 2015
> I don't think a stable ABI is feasible anytime soon and w/o that shared
> libraries are a PITA.

Other systems have similar issues - many of us have fought almost-but-not-quite-compatible glibc versions. I think many systems and applications live with the (albeit primitive) versioning tools that rely on embedding the version in the filename, symbolic links, etc. -- Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
September 09, 2015
On 09/09/2015 04:06 PM, Martin Nowak via dmd-internals wrote:
> On 09/09/2015 09:50 PM, Andrei Alexandrescu wrote:
>> That sounds reasonable but I must disagree. For one thing, the wiggling
>> is going a lot more often on the increase than on the decrease.
>
> We know very well where the bloat comes from (ModuleInfos, class
> references, eager template analysis) and unless someone tackles those
> bigger issues, the small stuff really doesn't matter that much.
> In the meantime we're reverting useful code b/c hello world must not
> grow
> https://github.com/D-Programming-Language/phobos/pull/2956#issuecomment-128717113.

My hypothesis goes, once we put the ratchet in motion, motivation will grow to tackle these issues. Without it things will wiggle forever, and more one way than the other. -- Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
September 09, 2015
On 09/09/2015 11:01 PM, Andrei Alexandrescu wrote:
> My hypothesis goes, once we put the ratchet in motion, motivation will grow to tackle these issues. Without it things will wiggle forever, and more one way than the other. -- Andrei

That might be true.



September 09, 2015
On Wednesday, 9 September 2015 at 20:16:59 UTC, Martin Nowak wrote:
> Indeed, there is priority and severity. We should use both much more consistently b/c there are important bugs (affecting many users) that aren't severe and severe regressions that aren't too important.

We could start by changing the field's default value away from P1. Not sure whom to contact for that, though.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
September 09, 2015
On Wednesday, 9 September 2015 at 19:50:12 UTC, Andrei Alexandrescu wrote:
> That's how we got HHVM from 5x slower to 4x faster than the baseline: by working on every percent. And by not letting things wiggle.

I'd like to integrate http://digger.k3.1azy.net/trend/ with https://github.com/CyberShadow/DAutoTest so we get instant feedback for every PR, hopefully I'll find time for this this month.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
September 10, 2015
On 09/09/2015 08:46 PM, Martin Nowak via dmd-internals wrote:
> It's definitely on the agenda but doesn't preclude working on the current implementation b/c it's unclear whether we can actually come up with a feasible and better solution.

To mention one thing that might solve many of our problems apart from
the above refactoring
(https://github.com/D-Programming-Language/dmd/pull/4780#issuecomment-124087604).

We should do more things in the compiler lazily and need a proper pipeline that keeps track of dependencies (and detects cycles).

The 3rd regression caused by the template change was order dependent and happened b/c code for a function was generated before calling codegen for it's nested module.

https://github.com/D-Programming-Language/dmd/pull/5058#issuecomment-139055923 https://issues.dlang.org/show_bug.cgi?id=15032#c4

Seems like a good idea to talk to deadalnix about how that works in SDC.



September 09, 2015
On Wednesday, 9 September 2015 at 20:16:59 UTC, Martin Nowak wrote:
> https://issues.dlang.org/buglist.cgi?cmdtype=runnamed&namedcmd=regression

FYI this link isn't working for me, I think it's tied to your Bugzilla account.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals