Re: Code size without documentation comments and unittests
On Saturday, 25 February 2017 at 19:31:06 UTC, Andrei Alexandrescu wrote: What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei Fun fact I found out using this thread: 57.4% of the lines in Phobos are non-code lines.
Re: Code size without documentation comments and unittests
On Sunday, 26 February 2017 at 05:50:32 UTC, Andrei Alexandrescu wrote: What am I missing? I installed dscanner from my package manager (homebrew), so I don't get any of the extra dub noise at all.
Re: assert with format considered harmful
On Sunday, 26 February 2017 at 06:34:07 UTC, Ali Çehreli wrote:
So, obviously, assert message generation is not lazy. This is a
WAT! for me but perhaps there is a good reason for it.
FWIW imho we shouldn't need to write such messages at all.
It shouldn't be to difficult to lower `assert (a BINOP b)` into
sth. like:
(auto ref a, auto ref b) {
if (a BINOP b) return;
onAssertFailed!"BINOP"(a, b, __FILE__, __LINE__,
__FUNCTION__, __MODULE__);
} (e1, e2);
with onAssertFailed being a nice pretty-printer in the direction
of:
assert([1,2,3] == [1,2,4]); // ERROR: ([1,2,3][2] is 3) !=
([1,2,4][2] is 4)
struct A { int x, y; }
auto a = A(1,2);
auto b = A(1,3);
assert(a == b); // ERROR: (a.y is 2) != (b.y is 3)
This idea is formally known as DIP83:
https://wiki.dlang.org/DIP83
Re: Code size without documentation comments and unittests
On Sunday, 26 February 2017 at 05:50:32 UTC, Andrei Alexandrescu wrote: I might be missing something, so bear with me. My current understanding is: * The usual way to run stuff gotten via dub is with "dub run", so that people don't need to deal with version directories and complex paths such as ~/.dub/packages/dscanner-0.4.0/dscanner. * There is no easy way to get rid of the chatteroo prefacing the actual output from the application. One possibility I imagine is a rather gnarly sed script that prints nothing until it detects '^Running ', and then starts printing everything. * There is even no --quiet option (https://code.dlang.org/docs/commandline#run) with run that instructs dub to not inform about things being up to date. Are these correct? In that case, dub runs afoul of the Rule of Silence: the command "dub run xyz" should only output whatever xyz outputs if dub takes no actual additional build steps. By the RoS, there might be a --verbose flag with dmd run that prints the above. What am I missing? I think that the DUB issue list [0] has grown immensely over the last two years as it's nearly only Sönke maintaining - it's not like he doesn't maintain ddox [1], Vibe.d [2], eventcore [3] (an abstraction for event loop libraries that hopefully one day finds its way to Phobos), std.data.json [4] (an kickass Json library), diet-ng [5] (the template system used by Vibe.d), tagged-algebraic [6], the DUB registry [7] and so on. Moreover, Dub's issue list [0] is filled with real bugs and important feature requests (git support, C/C++ integration like Rust, ...). That been said DUB is a build tool and it's good to be in verbose in case of errors and there's `-q` which you can use as expected, e.g: dub run dscanner -q -- --sloc . It's documented in the beginning of the document you linked under "general options". When it's used in the `--single` file mode (aka #!/usr/bin/env dub) it's quiet by default. [0] https://github.com/dlang/dub/issues [1] https://github.com/rejectedsoftware/ddox [2] https://github.com/rejectedsoftware/vibe.d [3] https://github.com/vibe-d/eventcore [4] https://github.com/s-ludwig/std_data_json [5] https://github.com/rejectedsoftware/diet-ng [6] https://github.com/s-ludwig/taggedalgebraic [7] https://github.com/dlang/dub-registry
assert with format considered harmful
If the generation of the error message throws, then the program receives
a FormatException, not the most import AssertError:
import std.string;
void foo(int i) {
// In this case a %s is forgotten but it could be any other trivial
error.
assert(i == 42, format("Bad parameter:", i));
}
void main() {
foo(43);
}
Opened:
https://issues.dlang.org/show_bug.cgi?id=17226
So, obviously, assert message generation is not lazy. This is a WAT! for
me but perhaps there is a good reason for it.
Google found a related article by Peter Alexander:
http://poita.org/2012/09/02/a-better-assert-for-d.html
Ali
Re: CTFE Status 2
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Hi Guys, ref variable handing is coming soon! (only int/uint for now)... Also I have suspicions that there is a bug in my ctfe_evaluator in which the first default arguments can overridden with the this pointer :) I will test "this" tomorrow :) Also I submitted my talk proposal a few hours ago; Of course it's about newCTFE. Cheers, Stefan
Re: If you needed any more evidence that memory safety is the future...
On 02/26/2017 12:17 AM, Ola Fosheim Grostad wrote: On Saturday, 25 February 2017 at 22:37:15 UTC, Chris Wright wrote: The undefined behavior is what happens after the would-be assertion failure occurs. The compiler is free to emit code as if the assertion passed, or if there is no way for the assertion to pass, it is free to do anything it wants. No. That would be implementation defined behaviour. Undefined behaviour means the whole program is illegal, i.e. not covered by the language at all. "Bad things happen" by a different name smells just as foul.
Re: Code size without documentation comments and unittests
On 2/25/17 2:55 PM, Timothee Cour via Digitalmars-d wrote: Try dscanner --sloc although IMO --tokenCount should be the most relevant metric (only caveat is mixin strings with which one could cheat to make token count smaller). Thanks, got that working with ease. The operation of dub has gotten quite a bit smoother, props to Sönke! One thing that I found surprising is the chatter that seems impossible to mute. Here's a session: $ dub run dscanner -- --sloc ../phobos/std/traits.d Building package dscanner in /Users/andrei/.dub/packages/dscanner-0.4.0/ Target libdparse 0.7.0 is up to date. Use --force to rebuild. Target emsi_containers 0.5.3 is up to date. Use --force to rebuild. Target dsymbol 0.2.0 is up to date. Use --force to rebuild. Target inifiled 0.0.6 is up to date. Use --force to rebuild. Target dscanner 0.4.0 is up to date. Use --force to rebuild. Running ../../.dub/packages/dscanner-0.4.0/dscanner --sloc ../phobos/std/traits.d ../phobos/std/traits.d: 3747 total: 3747 I might be missing something, so bear with me. My current understanding is: * The usual way to run stuff gotten via dub is with "dub run", so that people don't need to deal with version directories and complex paths such as ~/.dub/packages/dscanner-0.4.0/dscanner. * There is no easy way to get rid of the chatteroo prefacing the actual output from the application. One possibility I imagine is a rather gnarly sed script that prints nothing until it detects '^Running ', and then starts printing everything. * There is even no --quiet option (https://code.dlang.org/docs/commandline#run) with run that instructs dub to not inform about things being up to date. Are these correct? In that case, dub runs afoul of the Rule of Silence: the command "dub run xyz" should only output whatever xyz outputs if dub takes no actual additional build steps. By the RoS, there might be a --verbose flag with dmd run that prints the above. What am I missing? Thanks, Andrei
Re: If you needed any more evidence that memory safety is the future...
On Saturday, 25 February 2017 at 22:37:15 UTC, Chris Wright wrote: The undefined behavior is what happens after the would-be assertion failure occurs. The compiler is free to emit code as if the assertion passed, or if there is no way for the assertion to pass, it is free to do anything it wants. No. That would be implementation defined behaviour. Undefined behaviour means the whole program is illegal, i.e. not covered by the language at all.
Re: If you needed any more evidence that memory safety is the future...
On 02/25/2017 04:49 PM, Chris Wright wrote: It says it doesn't emit code for assertions. Then it says assertion failures are undefined behavior. How does that even work? Obviously the would-be failure. No need for the docs to be pedantic about everything. It'd read like the average RFC, for the few people who would bother trying to read it.
Re: If you needed any more evidence that memory safety is the future...
On 02/24/2017 12:47 PM, H. S. Teoh via Digitalmars-d wrote: The elephant in the room is that the recent craze surrounding the "cloud" has conveniently collected large numbers of online services under a small number of umbrellas, thereby greatly expanding the impact of any bug that occurs in the umbrella. Instead of a nasty bug that impacts merely one or two domains, we now have a nasty bug that singlehandedly affects 4 *million* domains. Way to go, "cloud" technology! Indeed. The big original *point* of what became the internet, and why the internet got as successful as it did, was decentralization. The past decade or so of recentralization is a shame, to say the least. But I suppose it was inevitable: Now that corporations are involved, corporate interests are involved, and corporate motivator #1 is "control as much of the territory as you can: size == profit".
Re: If you needed any more evidence that memory safety is the future...
On Saturday, 25 February 2017 at 21:49:43 UTC, Chris Wright wrote: On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote: On 25.02.2017 15:38, Chris Wright wrote: On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not. https://dlang.org/dmd-linux.html#switch-release This literally says "[...] assertion failures are undefined behaviour". ... It says it doesn't emit code for assertions. Then it says assertion failures are undefined behavior. How does that even work? LLVM and other optimizers provide functionality for introducing axioms directly. D allows compilers to turn asserts into axioms without proof. If axioms are contradicting each other the whole program becomes potentially undefined (i.e. True and False become arbitrary).
Re: If you needed any more evidence that memory safety is the future...
On Sat, 25 Feb 2017 21:49:43 +, Chris Wright wrote: > On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote: > >> On 25.02.2017 15:38, Chris Wright wrote: >>> On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not. >>> >>> https://dlang.org/dmd-linux.html#switch-release >>> >>> >> This literally says "[...] assertion failures are undefined behaviour". > > ... > > It says it doesn't emit code for assertions. > > Then it says assertion failures are undefined behavior. > > How does that even work? As far as I can tell, it's worded poorly enough to be incorrect. The undefined behavior is what happens after the would-be assertion failure occurs. The compiler is free to emit code as if the assertion passed, or if there is no way for the assertion to pass, it is free to do anything it wants. However, the assertion isn't emitted, so there is no assertion failure. That part is defined behavior; it was defined in the preceding sentence.
Re: If you needed any more evidence that memory safety is the future...
On Sat, 25 Feb 2017 22:12:13 +0100, Timon Gehr wrote: > On 25.02.2017 15:38, Chris Wright wrote: >> On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: >>> If 'disable' (as can be reasonably expected) means the compiler will >>> behave as if they were never present, then it does not. >> >> https://dlang.org/dmd-linux.html#switch-release >> >> > This literally says "[...] assertion failures are undefined behaviour". ... It says it doesn't emit code for assertions. Then it says assertion failures are undefined behavior. How does that even work? > https://en.wikipedia.org/wiki/Confirmation_bias Fuck you.
Re: If you needed any more evidence that memory safety is the future...
On Saturday, 25 February 2017 at 21:12:13 UTC, Timon Gehr wrote: I know my claim seems insane, but it is actually true. http://forum.dlang.org/post/lr4kek$2rd$1...@digitalmars.com The optimizer can currently not take advantage of it. and I don't see how that would change in the near future.
Re: If you needed any more evidence that memory safety is the future...
On 25.02.2017 15:38, Chris Wright wrote: On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not. https://dlang.org/dmd-linux.html#switch-release This literally says "[...] assertion failures are undefined behaviour". https://en.wikipedia.org/wiki/Confirmation_bias Plus I actually tested it. ... Why would that matter? Ketmar described the removal of safety measures. With -release, assertions pose an additional safety risk. Assertions not executing is not undefined behavior. I didn't say it was. I know my claim seems insane, but it is actually true. http://forum.dlang.org/post/lr4kek$2rd$1...@digitalmars.com
Re: Code size without documentation comments and unittests
Try dscanner --sloc although IMO --tokenCount should be the most relevant metric (only caveat is mixin strings with which one could cheat to make token count smaller). TokenCount formatting invariant On Feb 25, 2017 11:36 AM, "Andrei Alexandrescu via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei
Code size without documentation comments and unittests
What would be a simple way to count the "effective" lines in a module, i.e. excluding ddoc comments and unittests? Having a tool for that in tools/ would be neat. -- Andrei
Re: Voting for std.experimental.checkedint
On 2/25/17 11:00 AM, Vladimir Panteleev wrote: On Saturday, 25 February 2017 at 15:21:10 UTC, Andrei Alexandrescu wrote: On 02/25/2017 10:17 AM, rumbu wrote: A lot of bloat code for something extremely basic. If you can do it with less code, I'm all ears. Thanks! -- Andrei Perhaps a simpler example for the most basic use case could be added near the top. In the heat of solving a problem, encountering two pages of theory and explanation for something the usage of which should be simple might be discouraging. Basically, something like: writeln((checked(5) + 7).get); // 12 writeln((checked(10) * 1000 * 1000 * 1000).get); // Overflow on binary operator OK, let's do this: https://github.com/dlang/phobos/pull/5192 https://github.com/dlang/phobos/pull/5195 Thanks, Andrei
Re: If you needed any more evidence that memory safety is the future...
On Friday, 24 February 2017 at 14:35:44 UTC, Jack Stouffer wrote: Why is it that test CIs catch bugs when people should be running tests locally? CI tests all platforms, not just the one a user is on. It does it simultaneously as well. In the case of something like DMD, it's a pain in the ass to setup and run. There's no documentation on how to do it either. I think LDC's wiki has some information on how it needs to be setup but it's a bit different as they are providing information on how to run the tests the way LDC has them setup. Which is different to how it is done in DMD.
Re: Step into in debugging.
hmm.. I didn't change my nickname. It was my answer.
Re: Step into in debugging.
Of course no. When I have some problem I google a solution and often I find it. I'm sure that sharing your solution may be useful for somebody else. But very often people that have solved theirs problem do not share solution - they think something like who cares and so on. You didn't shy to publish your problem and solution and I appreciated it, sincerely.
Re: Voting for std.experimental.checkedint
On Saturday, 25 February 2017 at 15:21:10 UTC, Andrei Alexandrescu wrote: On 02/25/2017 10:17 AM, rumbu wrote: A lot of bloat code for something extremely basic. If you can do it with less code, I'm all ears. Thanks! -- Andrei Perhaps a simpler example for the most basic use case could be added near the top. In the heat of solving a problem, encountering two pages of theory and explanation for something the usage of which should be simple might be discouraging. Basically, something like: writeln((checked(5) + 7).get); // 12 writeln((checked(10) * 1000 * 1000 * 1000).get); // Overflow on binary operator
Re: Voting for std.experimental.checkedint
On 02/25/2017 10:17 AM, rumbu wrote: A lot of bloat code for something extremely basic. If you can do it with less code, I'm all ears. Thanks! -- Andrei
Re: Voting for std.experimental.checkedint
On Friday, 24 February 2017 at 20:37:28 UTC, Dmitry Olshansky wrote: On 2/24/17 4:20 PM, Robert burner Schadek wrote: checkedint got voted in. With 2 Yes and 2 yes with remarks. Remarkably unpopular vote we have here. If I read it right it implies that nobody cares for checked integers. A lot of bloat code for something extremely basic. Newbie asks: How do I check for integer overflow in D? Response: http://dtest.thecybershadow.net/artifact/website-f99d0fe6d09e288faf22f3eb515fc56e3c892179-48800882159648c96641690c7485b586/web/phobos-prerelease/std_experimental_checkedint.html * newbie runs scared. My 2 cents.
Re: If you needed any more evidence that memory safety is the future...
On Saturday, 25 February 2017 at 14:38:33 UTC, Chris Wright wrote: On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not. https://dlang.org/dmd-linux.html#switch-release Plus I actually tested it. Ketmar described the removal of safety measures. With -release, assertions pose an additional safety risk. Assertions not executing is not undefined behavior. http://forum.dlang.org/thread/hqxoldeyugkazolll...@forum.dlang.org
Re: If you needed any more evidence that memory safety is the future...
On Sat, 25 Feb 2017 13:23:03 +0100, Timon Gehr wrote: > If 'disable' (as can be reasonably expected) means the compiler will > behave as if they were never present, then it does not. https://dlang.org/dmd-linux.html#switch-release Plus I actually tested it. > Ketmar described the removal of safety measures. With -release, > assertions pose an additional safety risk. Assertions not executing is not undefined behavior.
Re: If you needed any more evidence that memory safety is the future...
On 25.02.2017 01:50, Chris Wright wrote: On Fri, 24 Feb 2017 21:16:28 +0100, Timon Gehr wrote: On 24.02.2017 16:29, Chris Wright wrote: On Fri, 24 Feb 2017 09:14:24 +0200, ketmar wrote: forget about "-release" dmd arg. forget about "-boundscheck=off". no, really, they won't do you any good. after all, catching a bug in your program when it doesn't run in controlled environment is even more important than catching a bug in debugging session! don't hate your users by giving 'em software with all safety measures removed! please. Especially since -release disables assertions and contracts. No. It does in fact disable assertions and contracts. ... If 'disable' (as can be reasonably expected) means the compiler will behave as if they were never present, then it does not. If it means AssertErrors will not be thrown, then this is indeed what DMD will do in practice, but it is not guaranteed by the spec. Worse. It turns failures into UB. Which is what ketmar described. Ketmar described the removal of safety measures. With -release, assertions pose an additional safety risk.
Re: If you needed any more evidence that memory safety is the future...
On 25.02.2017 04:12, Chris M wrote: On Friday, 24 February 2017 at 20:16:28 UTC, Timon Gehr wrote: On 24.02.2017 16:29, Chris Wright wrote: On Fri, 24 Feb 2017 09:14:24 +0200, ketmar wrote: forget about "-release" dmd arg. forget about "-boundscheck=off". no, really, they won't do you any good. after all, catching a bug in your program when it doesn't run in controlled environment is even more important than catching a bug in debugging session! don't hate your users by giving 'em software with all safety measures removed! please. Especially since -release disables assertions and contracts. No. Worse. It turns failures into UB. How so? With -release, the optimizer is allowed to assume that assertions pass. There is no switch to disable assertions. https://dlang.org/dmd-linux.html#switch-release "compile release version, which means not emitting run-time checks for contracts and asserts. Array bounds checking is not done for system and trusted functions, and assertion failures are undefined behaviour."
