Re: dmd 2.065.0
Steven Schveighoffer wrote in message news:op.xbs1naiueav7ka@stevens-macbook-pro.local... A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident. But wild guesses don't help fix bugs :) Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1yts5n/facebook_open_sources_flint_a_c_linter_written_in/ An interesting comment from Reddit: klusarkI'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
Re: Facebook open sources flint, a C++ linter written in D
bearophile wrote in message news:bskrlqgtwkqdyoqwk...@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!
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
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: klusarkI'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.
Re: dmd 2.065.0
On Tuesday, 25 February 2014 at 10:28:41 UTC, Daniel Murphy wrote: Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054 I find it so ironical that Walter warns that this may break the code and few comments later says that more appropriate fix is not an option because I don't want to break anything with this release :P
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
Dicebot wrote in message news:rkgevwccvxaynrbbi...@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...
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
You don't need to port lints to use them.
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: dmd 2.065.0
On Tue, 25 Feb 2014 05:28:42 -0500, Daniel Murphy yebbliesnos...@gmail.com wrote: Steven Schveighoffer wrote in message news:op.xbs1naiueav7ka@stevens-macbook-pro.local... A wild wild guess is that there was code in the compiler that used to require it (after all, it was required a long time ago), and somehow it got reactivated by accident. But wild guesses don't help fix bugs :) Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. This was the wrong fix. Druntime should be modified to use TypeInfo.equals instead of TypeInfo.compare. Compare is no longer needed, since it's only used to check for equality. Note that the docs say BOTH opEquals and opCmp should be specified, because either can be used. I would suggest a proper interim fix is to only reject key types that define opEquals, but not opCmp. Then switch to using equals in druntime. Finally, get rid of AA's as a specialized type, map them cleanly to a template. -Steve
Re: dmd 2.065.0
On 2014-02-24 21:29, Walter Bright wrote: Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change. I've been compiling Tango with the latest version for a couple of releases now. I found some issues for this release. Some were fixed. Some where code that should not have compiled previously. Then I hit the issue with opCmp and I failed to find a reduced test case. Why should I need opCmp in a struct containing only two ints? -- /Jacob Carlborg
Re: dmd 2.065.0
On Monday, 24 February 2014 at 08:45:31 UTC, Andrew Edwards wrote: The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release. Nice job wrangling the new release schedule and shepherding your first release out the door, hopefully the first of many to come. Hope it's not too much more work than you thought it'd be when I recommended that you talk to the core devs about taking on the position. Also, kudos to all the contributors, nice to see an amd64 build for FreeBSD finally.
Re: dmd 2.065.0
On 2014-02-24 21:29, Walter Bright wrote: Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change. Answering some of your comments here: Q: If the project fails to compile or run, who is responsible for debugging it A: Preferably we have some way to run a bunch of projects as part of the test suite. Developers sign up their projects if they want to participate. If a build fails the developer gets a notification. The developer is responsible for debugging. If a project has successfully passed the 10 latest releases but the 11th fails I think the DMD/Phobos developers could have a quick look to see if it's something obvious. Q: Individual projects tend to stick with particular subsets of the language. They may be large code bases, but likely exercise relatively small parts of the language, and so their successful compilation is not very indicative of much. A: That's not entirely true. I can tell you that DMD has broken DWT, one way or another, for, at least, the 10 latest releases. -- /Jacob Carlborg
Re: Facebook open sources flint, a C++ linter written in D
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
Re: dmd 2.065.0
On Tue, 25 Feb 2014 12:11:46 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: I would suggest a proper interim fix is to only reject key types that define opEquals, but not opCmp. Then switch to using equals in druntime. Sorry, I meant define opCmp but not opEquals. Some types can be compared for equality but are not ordered (AA's for example!) -Steve
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: dmd 2.065.0
On Monday, 24 February 2014 at 20:24:04 UTC, Walter Bright wrote: On 2/24/2014 9:48 AM, Brad Anderson wrote: On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote: First thing I noticed though, the Windows installer seemed to forget where my existing D installation is, and tried to install it somewhere else. I thought this got fixed months ago? Regression in the installer? Nope, not a regression. That never got implemented. Is there a bugzilla issue for this? Nope.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: dmd 2.065.0
On 2/25/2014 2:28 AM, Daniel Murphy wrote: Walter + Andrei did it, and it was completely intentional, and it was known that it would break code. https://github.com/D-Programming-Language/dmd/pull/3054 It was intended to only break code that was already broken (would fail at runtime). It appears that this turned out to not be entirely true.
Re: dmd 2.065.0
On 2/25/2014 11:03 AM, Brad Anderson wrote: On Monday, 24 February 2014 at 20:24:04 UTC, Walter Bright wrote: On 2/24/2014 9:48 AM, Brad Anderson wrote: On Monday, 24 February 2014 at 17:42:07 UTC, Manu wrote: First thing I noticed though, the Windows installer seemed to forget where my existing D installation is, and tried to install it somewhere else. I thought this got fixed months ago? Regression in the installer? Nope, not a regression. That never got implemented. Is there a bugzilla issue for this? Nope. Please make one - otherwise it'll get overlooked.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: dmd 2.065.0
On 25 February 2014 17:30, Jacob Carlborg d...@me.com wrote: On 2014-02-24 21:29, Walter Bright wrote: Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change. Answering some of your comments here: Q: If the project fails to compile or run, who is responsible for debugging it A: Preferably we have some way to run a bunch of projects as part of the test suite. Developers sign up their projects if they want to participate. If a build fails the developer gets a notification. The developer is responsible for debugging. If a project has successfully passed the 10 latest releases but the 11th fails I think the DMD/Phobos developers could have a quick look to see if it's something obvious. Q: Individual projects tend to stick with particular subsets of the language. They may be large code bases, but likely exercise relatively small parts of the language, and so their successful compilation is not very indicative of much. A: That's not entirely true. I can tell you that DMD has broken DWT, one way or another, for, at least, the 10 latest releases. +1 I've have old projects break for silly reasons. A forward reference regression here, an ICE suddenly appeared there. These things happen and never get caught during the beta phase because. 1) I'm not actively developing the project. 2) I have a compiled binary I use sometimes day in day out, and have no reason to recompile it. :)
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: dmd 2.065.0
On 2/24/2014 12:29 PM, Walter Bright wrote: Looks like we need to do something about this: http://www.reddit.com/r/programming/comments/1ytfc5/d_2065_released_with_396_fixes_and_improvements/cfnmkih At a minimum, add it to the changelog. Or possibly remove that change. https://d.puremagic.com/issues/show_bug.cgi?id=12255
Re: dmd 2.065.0
24-Feb-2014 12:45, Andrew Edwards пишет: The final release of DMD 2.065 is now available. [1] contains complete descriptions of all changes, enhancements and fixes for this release. Available binaries can be accessed at [2]. Since the website will lag slightly behind, links are provided below for convenience. Awesome. Thanks to everybody behind the release engineering. I don't know how good or painful it gets for these involved but from the outside (as a core developer) I see remarkable progress in handling the process. -- Dmitry Olshansky
Re: dmd 2.065.0
On Tue, 25 Feb 2014 14:33:05 -0500, Walter Bright
newshou...@digitalmars.com wrote:
On 2/25/2014 2:28 AM, Daniel Murphy wrote:
Walter + Andrei did it, and it was completely intentional, and it was
known that
it would break code.
https://github.com/D-Programming-Language/dmd/pull/3054
It was intended to only break code that was already broken (would fail
at runtime). It appears that this turned out to not be entirely true.
I just wrote this and compiled on 2.064:
import std.stdio;
struct S
{
int x;
int y;
bool opEquals(ref const(S) other) const { return other.x == x;}
}
void main()
{
int[S] aa;
aa[S(1, 2)] = 5;
aa[S(1, 3)] = 6;
writeln(aa);
}
Output:
[S(1, 2):5, S(1, 3):6]
Now, clearly this is not correct, and should be flagged by the compiler,
or fixed in the runtime.
I suggest this path:
1. Switch AA to using the 'equals' function
2. Do not allow keys that provide opCmp function but not opEquals (these
will not work correctly)
This will provide a sane implementation and not break existing code when
the default opEquals and opCmp are used (both will act the same as far as
AAs are concerned).
-Steve
Re: dmd 2.065.0
On 2014-02-25 20:49, Steven Schveighoffer wrote:
I just wrote this and compiled on 2.064:
import std.stdio;
struct S
{
int x;
int y;
bool opEquals(ref const(S) other) const { return other.x == x;}
}
void main()
{
int[S] aa;
aa[S(1, 2)] = 5;
aa[S(1, 3)] = 6;
writeln(aa);
}
Output:
[S(1, 2):5, S(1, 3):6]
Now, clearly this is not correct, and should be flagged by the compiler,
or fixed in the runtime.
I suggest this path:
1. Switch AA to using the 'equals' function
2. Do not allow keys that provide opCmp function but not opEquals (these
will not work correctly)
This will provide a sane implementation and not break existing code when
the default opEquals and opCmp are used (both will act the same as far
as AAs are concerned).
The thing is that the compiler complains about a deceleration looking
like this:
struct TagIndex
{
uint tag, index;
}
Neither opEquals or opCmp is overloaded. A simple test case will also
show that the compiler doesn't not complain about a missing opCmp. I
have not been able to create a reduced test case for this.
--
/Jacob Carlborg
Re: Facebook open sources flint, a C++ linter written in D
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
Re: dmd 2.065.0
On Tue, 25 Feb 2014 15:12:41 -0500, Jacob Carlborg d...@me.com wrote:
The thing is that the compiler complains about a deceleration looking
like this:
struct TagIndex
{
uint tag, index;
}
If the compiler generates opEquals and opCmp, then it's guaranteed
opEquals(x, y) is equivalent to opCmp(x, y) == 0.
The compiler should NOT complain about this, which I should have more
clearly stated (I thought I had).
Neither opEquals or opCmp is overloaded. A simple test case will also
show that the compiler doesn't not complain about a missing opCmp. I
have not been able to create a reduced test case for this.
I realized, after trying to get opCmp to work, I was missing a piece --
toHash! I couldn't get the thing to only store one key!
So I have to update my requirements. Here are the two cases where a struct
T should be usable as an AA key:
1. Neither opCmp nor opEquals are defined (and defaults are generated).
2. Both opEquals and toHash are defined.
Any other key types should be disallowed.
-Steve
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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: klusarkI'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
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
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
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: Facebook open sources flint, a C++ linter written in D
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: klusarkI'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
Re: COMPO
On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation You must forgive me for harping on about this, but I am going to be persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of a man-year's work. So I won't let go lightly. Today I have posted two new .deb files (i386/amd64) on the COMPO web site - http://britseyeview.com/compo/. There's decent online documentation at the same place. The stage of operations is now QA, and since I am the author, you know that at this point, I need help ;=) The source code is also up-to-date on https://github.com/britseye/compo. Come on guys, give me an hour of your precious time. Steve However I go about building this, I get linker errors about libusps4cb.a Where can I find the source for this library? Or at the very least can you upload a x86_64 version?
Re: Facebook open sources flint, a C++ linter written in D
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.
Re: https everywhere
On Friday, 21 February 2014 at 20:34:12 UTC, Walter Bright wrote: dlang.org and dconf.org now support https, https://dlang.org https://dconf.org Note that this is a self-signed certificate, and so when you first access it you'll get a dire warning from your browser. Captcha in the forum to avoid spam do not work when using HTTPS
Re: Facebook open sources flint, a C++ linter written in D
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/majnjuhxdefjuqjlp...@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
# works!
Re: Facebook open sources flint, a C++ linter written in D
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: klusarkI'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
Re: Facebook open sources flint, a C++ linter written in D
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!
Re: Facebook open sources flint, a C++ linter written in D
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.)
Re: Facebook open sources flint, a C++ linter written in D
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
