http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/

Somewhere in that thread was a mention of facebook moving away
from git because it was too slow.  I thought it was interesting
and found this info on the topic ...  They rewrote some sections
of Mercurial to make it scale better, and got it working faster
than git in their environment.

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

On 2/28/14, 3:19 PM, Ivan Kazmenko wrote:
> On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu wrote:
>> https://news.ycombinator.com/item?id=7293396
>> http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/
>>
>
> The relevant link on D_Programming twitter
> (https://twitter.com/D_Programming/status/438089226685399040) points to
> www.facebook.com/... instead of code.facebook.com/... and thus gives
> error 404.

Thanks, sent a correx.

Andrei

25.02.2014 16:48, Dicebot пишет:
> On Tuesday, 25 February 2014 at 11:20:37 UTC, bearophile wrote:
>> Currently the D compiler catches several bugs that are caught only by
>> C lints. Clang shows that you can add lot of lint-like tests to the
>> compiler. I'd like some more tests in the D compiler.
>
> Full stop. It should be other way around - remove all such arguable
> warnings from compiler to dedicated lint tool and never add any single
> one to compiler.

I'd say a good static code analysis require a full compiler frontend and I see no reasons why there can't be such thing in dmd as it is just as required as profiler, unittesting or documentation generation which are already in. Of course it has nothing to do with compiler warnings and is a separate thing. But looks like people aren't interested in it as enhancement request 9811 [1] still has no votes or discussion.

[1] https://d.puremagic.com/issues/show_bug.cgi?id=9811

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

On Sunday, 2 March 2014 at 12:29:15 UTC, Denis Shelomovskij wrote:
> I'd say a good static code analysis require a full compiler frontend and I see no reasons why there can't be such thing in dmd as it is just as required as profiler, unittesting or documentation generation which are already in. Of course it has nothing to do with compiler warnings and is a separate thing. But looks like people aren't interested in it as enhancement request 9811 [1] still has no votes or discussion.

I think built-in profile and documentation is also inferior to having those as separate binaries but distributing together with compiler and being callable from it. Unit test are different because those are much more integrated with language itself.


Compiler as a (dynamic) library is the way to go.

On 3/2/2014 7:35 AM, Dicebot wrote:
> On Sunday, 2 March 2014 at 12:29:15 UTC, Denis Shelomovskij wrote:
>> I'd say a good static code analysis require a full compiler frontend
>> and I see no reasons why there can't be such thing in dmd as it is
>> just as required as profiler, unittesting or documentation generation
>> which are already in. Of course it has nothing to do with compiler
>> warnings and is a separate thing. But looks like people aren't
>> interested in it as enhancement request 9811 [1] still has no votes or
>> discussion.
>
> I think built-in profile and documentation is also inferior to having
> those as separate binaries but distributing together with compiler and
> being callable from it. Unit test are different because those are much
> more integrated with language itself.
>

Personally, I've never really understood the benefit one way or another of related tools being in one binary vs multiple binaries. As I see it, the important thing is that all relevant *source* is well-encapsulated. Unless you're on a system where kilobytes matter (ie, if you're in a time warp), anything else just comes down to a matter of:

git clone url
dmd -profile src.d

vs

git-clone url
dmd-profile src.d

>
> Compiler as a (dynamic) library is the way to go.

Definitely!

On Sunday, 2 March 2014 at 21:41:26 UTC, Nick Sabalausky wrote:
> Personally, I've never really understood the benefit one way or another of related tools being in one binary vs multiple binaries. As I see it, the important thing is that all relevant *source* is well-encapsulated. Unless you're on a system where kilobytes matter (ie, if you're in a time warp), anything else just comes down to a matter of:
>
> ...

Main difference that matters is separation of the code base that makes maintenance of each tool independent from compiler core and thus easier. This also propagates to separation of CLI flags and configuration files and so on, allowing for more combined interface complexity.

git CLI is designed hierarchically so passing all those parameters is obvious. This can't be done for dmd without changing it CLI completely or introducing some weird hacks.