www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Facebook open sources flint, a C++ linter written in D

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
This is a first on so many levels.

https://news.ycombinator.com/item?id=7293396

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


Andrei
Feb 24 2014
next sibling parent Justin Whear <justin economicmodeling.com> writes:
On Mon, 24 Feb 2014 13:06:29 -0800, Andrei Alexandrescu wrote:


 This is a first on so many levels.
 
 https://news.ycombinator.com/item?id=7293396
 
 http://www.reddit.com/r/programming/comments/1yts5n/


facebook_open_sources_flint_a_c_linter_written_in/

 
 
 Andrei


The real first is that I managed to comment on your reddit within two 
minutes of submission.
Feb 24 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu 
wrote:

 This is a first on so many levels.

 https://news.ycombinator.com/item?id=7293396

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


 Andrei


Congratulations! This is great news. D is sure to get tons of 
exposure from this, and it proves how D is useful for real world 
work.
Feb 24 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


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



3. Reserved identifiers (checkDefinedNames). A C and C++ naming 
rule that often gets forgotten is that all identifiers starting 
with an underscore followed by an uppercase letter, plus all 
identifiers containing two consecutive underscores, are reserved 
by the implementation. (Of course there are exceptions to the 
rule in our code, such as _GNU_SOURCE or _XOPEN_SOURCE, which is 
why flint keeps aside a whitelist while checking for reserved 
identifier patterns.)<


D language has similar rules, but I don't rember if the D 
compiler warns against usage of similar identifiers.



8. Initializing a variable from itself 
(checkInitializeFromItself). We found that people wrote 
constructors like:


class X {
    ...
    int a_;
    X(const X& rhs) : a_(a_) {}
    X(int a) : a_(a_) {}
};

The intent was to use a_(rhs.a_) in the first constructor and 
a_(a) in the second. That hardly ever helps, and the compiler 
keeps mum about it. We like to say, "There's a flint rule for 
that," in order to resolve the problem.<

I'd like a similar warning in the D compiler for a similar (very) 
common bug:

class Foo {
    int x;
    this(int x_) { this.x = x; }
}
void main() {}



16. Check against throwing new-allocated bald pointers 
(checkThrowsHeapException). This eliminates the throw new T 
anti-pattern.<


I don't fully understand this.

The "throw new Exception(...)" pattern in D was recently 
discussed, and sometimes re-using an Exception is more efficient.




20. Pass cheap types by value (checkFollyStringPieceByValue). 
Certain user-defined types, such as iterators or pair of 
iterators, are small and cheap to copy so it's virtually always 
better to pass them by value instead of the conservative 
reference to const. Folly's StringPiece is an example - it 
occupies two words and has raw copy semantics.<


In D there is about the same problem.

Additionally the D compiler doesn't warn if you do kind of the 
opposite:

alias MyArr = int[5000];
void foo(MyArr x) {}
void main() {}

Bye,
bearophile
Feb 24 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:bskrlqgtwkqdyoqwkxqn forum.dlang.org... 


 D language has similar rules, but I don't rember if the D 
 compiler warns against usage of similar identifiers.


It doesn't!


 [snip etc]


The D compiler is not a lint tool!
Feb 25 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Murphy:


 D language has similar rules, but I don't rember if the D 
 compiler warns against usage of similar identifiers.


 It doesn't!


Perhaps it should?



 [snip etc]


 The D compiler is not a lint tool!


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.

Bye,
bearophile
Feb 25 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Feb 25 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:


 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.


What are the advantages and disadvantages of doing as you say?

Bye,
bearophile
Feb 25 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 25 February 2014 at 12:58:03 UTC, bearophile wrote:

 Dicebot:


 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.


 What are the advantages and disadvantages of doing as you say?

 Bye,
 bearophile


Disadvantages:
1) need to distribute extra tool
2) need to keep it in sync with language

Advantages:
1) can't affect compilation semantics (__traits(compiles) + dmd 
-w)
2) allows defining project-specific rule set
3) becomes possible to define exceptions from general rules 
without affecting language
4) makes it possible to add lot of different checks without 
endless arguments about their applicability for all programs
Feb 25 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 25 February 2014 at 12:58:03 UTC, bearophile wrote:

 Dicebot:


 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.


 What are the advantages and disadvantages of doing as you say?


http://en.wikipedia.org/wiki/Separation_of_concerns
Feb 25 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 2/25/14, 3:07 PM, deadalnix wrote:

 On Tuesday, 25 February 2014 at 12:58:03 UTC, bearophile wrote:

 Dicebot:


 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.


 What are the advantages and disadvantages of doing as you say?


 http://en.wikipedia.org/wiki/Separation_of_concerns


Yes, it can be a separate module in the source code of the compiler.

The compiler is the only one that has most information to provide lint 
errors.

If the lint has tests, if you change the compiler you immediately can 
tell if the linter stopped working correctly or needs an update.

If it's separated then it's always the turtle chasing the rabbit.
Feb 25 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 25 February 2014 at 18:34:49 UTC, Ary Borenszweig 
wrote:

 Yes, it can be a separate module in the source code of the 
 compiler.

 The compiler is the only one that has most information to 
 provide lint errors.

 If the lint has tests, if you change the compiler you 
 immediately can tell if the linter stopped working correctly or 
 needs an update.

 If it's separated then it's always the turtle chasing the 
 rabbit.


Ideally, you'd provide semantic analysis as a library, and use it 
in the compiler AND in the linter.

That is even more separation of concerns, and that works well.
Feb 25 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 10:34 AM, Ary Borenszweig wrote:

 If it's separated then it's always the turtle chasing the rabbit.


I like Adam's idea of improving reflection so such linters could be written as
D 
code and compiled in.
Feb 25 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 25.02.2014 20:36, schrieb Walter Bright:

 On 2/25/2014 10:34 AM, Ary Borenszweig wrote:

 If it's separated then it's always the turtle chasing the rabbit.


 I like Adam's idea of improving reflection so such linters could be
 written as D code and compiled in.


Yes, other languages are starting to offer such capabilities via 
compiler plugins.

Could be something interesting.

--
Paulo
Feb 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 12:54 PM, Paulo Pinto wrote:

 Am 25.02.2014 20:36, schrieb Walter Bright:

 On 2/25/2014 10:34 AM, Ary Borenszweig wrote:

 If it's separated then it's always the turtle chasing the rabbit.


 I like Adam's idea of improving reflection so such linters could be
 written as D code and compiled in.


 Yes, other languages are starting to offer such capabilities via compiler
plugins.

 Could be something interesting.


I don't mean as a compiler plugin.
Feb 25 2014
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Dicebot"  wrote in message news:rkgevwccvxaynrbbixfu forum.dlang.org... 


 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.


Exactly.

This sort of thing would make an excellent compiler plugin...
Feb 25 2014
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 25.02.2014 13:48, schrieb 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.


Yeah, it worked really great for C.

Developers created C compilers in other systems and never ported lint
as part of the process.

End result being a portable macro assembler, as safe as, writing in pure 
assembly.

--
Paulo
Feb 25 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
You don't need to port lints to use them.
Feb 25 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:


 End result being a portable macro assembler, as safe as, 
 writing in pure assembly.


I'd even like warnings active on default in D, plus a compiler 
switch to disable them. Lot of people in D.learn don't even 
activate warnings.

Bye,
bearophile
Feb 25 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 25 February 2014 at 15:43:30 UTC, bearophile wrote:

 I'd even like warnings active on default in D, plus a compiler 
 switch to disable them. Lot of people in D.learn don't even 
 activate warnings.


Those warning that _can_ be activated by default, should be just 
turned into errors. Same crap as with C.
Feb 25 2014
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 25.02.2014 16:49, schrieb Dicebot:

 On Tuesday, 25 February 2014 at 15:43:30 UTC, bearophile wrote:

 I'd even like warnings active on default in D, plus a compiler switch
 to disable them. Lot of people in D.learn don't even activate warnings.


 Those warning that _can_ be activated by default, should be just turned
 into errors. Same crap as with C.


There I agree.

Actually a good approach the Go guys have, everything that can be a 
warning, is an error.
Feb 25 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 8:05 AM, Paulo Pinto wrote:

 Actually a good approach the Go guys have, everything that can be a warning, is
 an error.


D started with and maintained that approach for many years. It was a position I 
strongly advocated.
Feb 25 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 25 February 2014 at 22:42:53 UTC, Walter Bright wrote:

 On 2/25/2014 8:05 AM, Paulo Pinto wrote:

 Actually a good approach the Go guys have, everything that can 
 be a warning, is
 an error.


 D started with and maintained that approach for many years. It 
 was a position I strongly advocated.


To be completely honest, at the moment warning lobby has happened 
it was more reasonable because there was not even slight 
possibility of lint-like tool creation back then. But now we have 
DScanner and DDMD is not that far away too which allows for more 
purism in this question.
Feb 25 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 2:47 PM, Dicebot wrote:

 To be completely honest,


I should hope so :-)


 at the moment warning lobby has happened it was more
 reasonable because there was not even slight possibility of lint-like tool
 creation back then. But now we have DScanner and DDMD is not that far away too
 which allows for more purism in this question.


I tend to agree. The existence of warnings in the compiler is a red flag that 
the language design needs work.

But I still support the existence of warnings in the compiler as a means to
ease 
transitioning away from obsolete features.
Feb 25 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:


 Those warning that _can_ be activated by default, should be 
 just turned into errors. Same crap as with C.


Programming is not a black/white thing 
(http://en.wiktionary.org/wiki/Manichaean#Adjective ) :-)

Bye,
bearophile
Feb 25 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 25 February 2014 at 16:07:34 UTC, bearophile wrote:

 Programming is not a black/white thing 
 (http://en.wiktionary.org/wiki/Manichaean#Adjective ) :-)


Which is exactly why you can't put this stuff into compiler - 
providing comparable amount of cofigurability as expected from 
dedicated lint tool will considerably complicate it. And sticking 
no non-configurable defaults is akin to -Werror in C: either you 
enable it and pollute your code with hacks to prevent triggerring 
of warnings in rare legit cases or just ignore for most time.
Feb 25 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 7:36 AM, Paulo Pinto wrote:

 Yeah, it worked really great for C.

 Developers created C compilers in other systems and never ported lint
 as part of the process.

 End result being a portable macro assembler, as safe as, writing in pure
assembly.


This is hyperbole. C's type system made it far safer than assembler.
Feb 25 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 25 February 2014 at 22:37:46 UTC, Walter Bright wrote:

 On 2/25/2014 7:36 AM, Paulo Pinto wrote:

 Yeah, it worked really great for C.

 Developers created C compilers in other systems and never 
 ported lint
 as part of the process.

 End result being a portable macro assembler, as safe as, 
 writing in pure assembly.


 This is hyperbole. C's type system made it far safer than 
 assembler.


Of course you are right about it, but that is how I personally 
look to C,
given my experience with Turbo Pascal, Modula-2 and Oberon for 
the same purposes.

--
Paulo
Feb 25 2014
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 25, 2014 12:48:17 Dicebot wrote:

 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.


+1

- Jonathan M Davis
Feb 26 2014
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
Mar 02 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Mar 02 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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!
Mar 02 2014
parent "Dicebot" <public dicebot.lv> writes:
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.
Mar 02 2014
prev sibling next sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu 
wrote:

 This is a first on so many levels.

 https://news.ycombinator.com/item?id=7293396

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


 Andrei


Awesomeness. Look forward to learning from its style.
Thanks

Joseph
Feb 24 2014
prev sibling next sibling parent reply "bachmeier" <no spam.com> writes:
On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu 
wrote:

 This is a first on so many levels.

 https://news.ycombinator.com/item?id=7293396

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


 Andrei



Is your job title really "D Language Evangelist"?
Feb 24 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/24/14, 4:46 PM, bachmeier wrote:

 On Monday, 24 February 2014 at 21:07:00 UTC, Andrei Alexandrescu wrote:

 This is a first on so many levels.

 https://news.ycombinator.com/item?id=7293396

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



 Andrei



 Is your job title really "D Language Evangelist"?


On paper it's "Research Scientist". But we are really allowed to 
describe our jobs any way we want.

Andrei
Feb 25 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 25 February 2014 at 00:46:03 UTC, bachmeier wrote:

 On Monday, 24 February 2014 at 21:07:00 UTC, Andrei 
 Alexandrescu wrote:

 This is a first on so many levels.

 https://news.ycombinator.com/item?id=7293396

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


 Andrei



 Is your job title really "D Language Evangelist"?


Usually, I understand XXX evangelist as "My job is to use
twitter".
Feb 25 2014
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 26 February 2014 at 00:57:55 UTC, deadalnix wrote:

 Usually, I understand XXX evangelist as "My job is to use
 twitter".


Oh, so _that's_ why the text of the Bible comes in individual 
numbered verses of less than 140 characters each!
Feb 25 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


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


An interesting comment from Reddit:

klusark>I've been trying to build this for the past hour. It 
requires folly. folly requires some "double-conversion" library, 
but you can't use the default version, you have to build it with 
scripts from folly's source. After I finally get folly to get 
past configure stage I get some random python error in one of the 
build scripts. I just gave up at this point. I'm sure I could get 
it working, but the time isn't worth it.<

Bye,
bearophile
Feb 25 2014
next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Tuesday, 25 February 2014 at 11:22:23 UTC, bearophile wrote:

 Andrei Alexandrescu:


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


 An interesting comment from Reddit:

 klusark>I've been trying to build this for the past hour. It 
 requires folly. folly requires some "double-conversion" 
 library, but you can't use the default version, you have to 
 build it with scripts from folly's source. After I finally get 
 folly to get past configure stage I get some random python 
 error in one of the build scripts. I just gave up at this 
 point. I'm sure I could get it working, but the time isn't 
 worth it.<

 Bye,
 bearophile


It's kind of strange (to say the least) that a D project depends 
on folly and gtest - the C++ libraries. I understand that flint 
is not purely a D project. It also builds the C++ binary and 
library which depends on this stuff.

But I find it important to separate the 2. And the D version 
should be made as easy to setup as possible. That is - no friggin 
autotools, makefiles and folly/boost/gtest dependencies.

I honestly think that this stuff stands in the way of the D's 
adoption big time. And this flint project should really be 
separated into C++ and D part. With D part using unittests, 
phobos and dub. So using it would be as simple as "dub build" and 
"dub test".

The difference would be even more noticeable with a neighbor C++ 
project requiring all that autotools nonsense.

Being a C++ developer for a decade now, personally, I can handle 
the D adoption curve since in its current state it's not worse 
than C++'s anyway. But every time I feel really awkward 
recommending D to someone else. Since I know they will encounter 
many problems which require arcane (to newcomer's mind) knowledge.

Maybe another valuable example would be a "go fix" alternative. 
After every release I hear the voices "It broke every line of my 
code", "This release is a behemoth", "D was never and will never 
be stable", etc. And I really think that if it could be handled 
by "dub fix" - nobody would ever complain.

At DConf 2013 Andrei told to that question something like - "What 
do you actually want? A bash script in the error message to fix 
that for a whole project? Well, I guess this could be done."

So, to summarize, I guess my point is, that today's tools work so 
smooth and with such low entering cost, that an 
old-dog-C++-programmer considers it magic and doesn't really 
value it accordingly. And since the D crowd is mostly the 
old-dog-C++-programmers crowd - this aspect is really 
"underlooked". But the (sad or great or mere) fact is that 
today's students are not old-dog-C++-programmers and they have 
really hard time using D today. So hard, that they would actually 
rather use Python or Go (oh, my) or Haskell (sic!) instead of D 
in their work.
Feb 25 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/25/14, 3:22 AM, bearophile wrote:

 Andrei Alexandrescu:


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


 An interesting comment from Reddit:

 klusark>I've been trying to build this for the past hour. It requires
 folly. folly requires some "double-conversion" library, but you can't
 use the default version, you have to build it with scripts from folly's
 source. After I finally get folly to get past configure stage I get some
 random python error in one of the build scripts. I just gave up at this
 point. I'm sure I could get it working, but the time isn't worth it.<

 Bye,
 bearophile


Ironically that's for the obsoleted C++ program. The D program is 
trivial to build.

Andrei
Feb 25 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Ironically that's for the obsoleted C++ program. The D program 
 is trivial to build.


Oh, I didn't know/understand that. Sorry for the noise.

Bye,
bearophile
Feb 25 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 3:40 PM, Andrei Alexandrescu wrote:

 Ironically that's for the obsoleted C++ program. The D program is trivial to
build.


Maybe the C++ version should undergo a git rm :-)

Or at least, put it on another branch.
Feb 25 2014
parent John J <john.joyus gmail.com> writes:
On 02/25/2014 06:53 PM, Walter Bright wrote:

 On 2/25/2014 3:40 PM, Andrei Alexandrescu wrote:

 Ironically that's for the obsoleted C++ program. The D program is
 trivial to build.


 Maybe the C++ version should undergo a git rm :-)

 Or at least, put it on another branch.


+1
Feb 26 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 25 February 2014 at 23:40:02 UTC, Andrei Alexandrescu 
wrote:

 On 2/25/14, 3:22 AM, bearophile wrote:

 Andrei Alexandrescu:


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


 An interesting comment from Reddit:

 klusark>I've been trying to build this for the past hour. It 
 requires
 folly. folly requires some "double-conversion" library, but 
 you can't
 use the default version, you have to build it with scripts 
 from folly's
 source. After I finally get folly to get past configure stage 
 I get some
 random python error in one of the build scripts. I just gave 
 up at this
 point. I'm sure I could get it working, but the time isn't 
 worth it.<

 Bye,
 bearophile


 Ironically that's for the obsoleted C++ program. The D program 
 is trivial to build.

 Andrei


Somewhat related, what ideas in Folly do you think we should 
borrow for Phobos?

It seems like there is a lot of nice stuff in there: 
https://github.com/facebook/folly/blob/master/folly/docs/Overview.md
Feb 25 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/25/14, 3:58 PM, Brad Anderson wrote:

 On Tuesday, 25 February 2014 at 23:40:02 UTC, Andrei Alexandrescu wrote:

 On 2/25/14, 3:22 AM, bearophile wrote:

 Andrei Alexandrescu:


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


 An interesting comment from Reddit:

 klusark>I've been trying to build this for the past hour. It requires
 folly. folly requires some "double-conversion" library, but you can't
 use the default version, you have to build it with scripts from folly's
 source. After I finally get folly to get past configure stage I get some
 random python error in one of the build scripts. I just gave up at this
 point. I'm sure I could get it working, but the time isn't worth it.<

 Bye,
 bearophile


 Ironically that's for the obsoleted C++ program. The D program is
 trivial to build.

 Andrei


 Somewhat related, what ideas in Folly do you think we should borrow for
 Phobos?

 It seems like there is a lot of nice stuff in there:
 https://github.com/facebook/folly/blob/master/folly/docs/Overview.md


I like throwErrno and friends a lot.

Andrei
Feb 25 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Wednesday, 26 February 2014 at 01:47:24 UTC, Andrei 
Alexandrescu wrote:

 I like throwErrno and friends a lot.


What's that? git grep over folly's repo comes up with 0 results.

Is this like our cenforce? (I think it should be made public.)
Feb 25 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 25 February 2014 at 23:40:02 UTC, Andrei Alexandrescu 
wrote:

 On 2/25/14, 3:22 AM, bearophile wrote:

 Andrei Alexandrescu:


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


 An interesting comment from Reddit:

 klusark>I've been trying to build this for the past hour. It 
 requires
 folly. folly requires some "double-conversion" library, but 
 you can't
 use the default version, you have to build it with scripts 
 from folly's
 source. After I finally get folly to get past configure stage 
 I get some
 random python error in one of the build scripts. I just gave 
 up at this
 point. I'm sure I could get it working, but the time isn't 
 worth it.<

 Bye,
 bearophile


 Ironically that's for the obsoleted C++ program. The D program 
 is trivial to build.

 Andrei


You should make that clearer in the README
Feb 25 2014
parent "Jay Norwood" <jayn prismnet.com> writes:
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/
Feb 28 2014
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 24 February 2014 21:06, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 This is a first on so many levels.

 https://news.ycombinator.com/item?id=7293396

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


 Andrei



Awesome!
Feb 25 2014
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
I'd like to point out a cool fact: with D, we can do a number of 
lint like things in the language itself, especially if we extend 
rtinfo (I wrote about this a little while ago and might do a pull 
request soon)

checkBlacklistedIdentifiers -- would require modifying the header 
but we could  disable them

checkOSSIncludes - scan for imports, would be easier with rtinfo 
for modules though! but worst case i'm pretty sure we could do 
this as a runtime unit test with moduleinfo

Eliminate common mistakes, checkImplicitCast - a UDA + RTInfo + 
compile time reflection means this is checked by D


well a lot of these are obviated by D itself too...  but checking 
reflection, especially with a project-wide rtinfo extension so 
you don't have to static assert in every module, gives D the 
potential to lint itself with some user-defined semantics.
Feb 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/25/2014 6:53 AM, Adam D. Ruppe wrote:

 well a lot of these are obviated by D itself too...  but checking reflection,
 especially with a project-wide rtinfo extension so you don't have to static
 assert in every module, gives D the potential to lint itself with some
 user-defined semantics.


This is a most interesting idea. Please pursue.
Feb 25 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 25 February 2014 at 19:37:04 UTC, Walter Bright wrote:

 This is a most interesting idea. Please pursue.


I talked about it a little while ago  in a thread on the forum 
(it was also my dconf submission but since I don't really want to 
travel anyway that surely won't happen).

http://forum.dlang.org/thread/majnjuhxdefjuqjlpbmv forum.dlang.org

The basic thing is to change object.d's RTInfo template to import 
an empty module and mixin a name. Projects would be able to 
override it by just writing their own module with the same name 
instead. Then, the compiler goes looking and prefers the user's 
one from the one in druntime.

It's doable right now, but we could improve it by adding an 
rtinfo like thing for modules too, or maybe even functions.

Some related bugzillas to rtinfo:

add it for modules too:
https://d.puremagic.com/issues/show_bug.cgi?id=10023

some bugs:
https://d.puremagic.com/issues/show_bug.cgi?id=10442
https://d.puremagic.com/issues/show_bug.cgi?id=10786

add it for built-in types too (not strictly necessary here)
https://d.puremagic.com/issues/show_bug.cgi?id=11670


I would *love* to have access to the call stack and local 
variables too, then we can do custom things a la  safe in the lib 
too. But I think we can go one step at a time, checking user 
structs and classes is possible today and gives some good 
possibilities.


Among the things I've done in my proof of concept:

rtinfo.d:
module core.rtinfo;
mixin template ProjectRtInfo(T) {
    import lint.virtuals;
    static assert(virtualCheck!T);
}

test.d:
import lint.virtuals;

class Foo {
         void foo() {}
}


$ dmd test53 virtuals.d  rtinfo.d
Warning Foo.foo is virtual

test.d:
import lint.virtuals;

class Foo {
          virtual void foo() {}
}
$ dmd test53 virtuals.d  rtinfo.d
Feb 25 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-02-25 15:53, Adam D. Ruppe wrote:

 I'd like to point out a cool fact: with D, we can do a number of lint
 like things in the language itself, especially if we extend rtinfo (I
 wrote about this a little while ago and might do a pull request soon)


One thing you cannot do is anything about the formatting of the source code.

-- 
/Jacob Carlborg
Feb 26 2014
prev sibling parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
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.
Feb 28 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 01 2014