Re: Overflows in Phobos
On Thursday, 28 July 2016 at 00:17:16 UTC, Walter Bright wrote: On 7/27/2016 3:47 PM, qznc wrote: On Wednesday, 27 July 2016 at 07:59:54 UTC, Walter Bright wrote: "The expression assert(0) is a special case; it signifies code that should be unreachable. If it is reached at runtime, either AssertError is thrown or execution is terminated in an implementation-defined manner. Any code after the assert(0) is considered unreachable." Why that last phrase about "considered unreachable"? If "AssertError is thrown or execution is terminated" it implies that execution will not continue after assert(0). Yeah, you're right. Another possibility would be "assert(0) never returns". This assumes that throwing an exception is not "returning", which is reasonable, since control flow does not leave via return statement.
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
The point is though, that I WANT to use the GC. I want the
memory cleaned up for me, and I don't mind little pauses once
in a while. I just don't want careless allocations to happen in
certain performance-sensitive contexts, like per-frame updates.
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
As utterly moronic as this seems, this was a real bug that I
had to fix. Our game was literally topping out at 2GB of memory
usage after ~30 seconds and crashing.
Note: it wasn't my code ;)
If that code was written in D with the feature I'm asking for,
draw() would have been marked with @nogc. The person who wrote
the above code would have either had to store the font
somewhere else, or insert a @assumenogc{} section to actually
do that. So it either would not have happened, or would have
been much easier to find.
If you found that your game/app was using too much GC,
searching for "@assumenogc" would likely uncover the cause, as
long as your root classes were annotated correctly. The
@assumenogc annotation would plainly show where allocations
were happening that maybe shouldn't be.
If @assumegc has to be manually checked to see if it is
over-allocating whenever the application is going out of memory,
then it is no more useful than running the gc-profiler when the
application is over-allocating. The profiler is even better,
because with @assumegc you have to check ALL marked functions to
find the leaking one, while the gc-profiler would just put it on
top of the report, making your job easier. So IMHO we already
have an instrument to solve these problems.
Re: Make D language as Apache foundation project
On Wednesday, 27 July 2016 at 13:20:50 UTC, lkfsdg wrote: On Wednesday, 27 July 2016 at 13:08:17 UTC, eugene wrote: Hello everyone, why not to make a D language as a project of Apache foundation as it happened to groovy? stupid, D has its own organization. Why the acrid tone. :(
Things that make writing a clean binding system more difficult
As mentioned in the D blog the other day, the binding system as
used by Remedy will both be open sourced and effectively
completely rewritten from when we shipped Quantum Break. As I'm
still deep within that rewrite, a bunch of things are still fresh
in my mind that aren't that great when it comes to D and doing
such a system.
These are things I also expect other programmers to come across
in one way or another, being that they seem like a simple way to
do things but getting them to behave require non-trivial
workarounds.
I also assume "lodge a bug" will be the response to these. But
there are some cases where I think documentation or
easily-googleable articles will be required instead/as well. And
in the case of one of these things, it's liable to start a long
circular conversation chain.
1) Declaring a function pointer with a ref return value can't be
done without workarounds.
Try compiling this:
ref int function( int, int ) functionPointer;
It won't let you, because only parameters and for loop symbols
can be ref types. Despite the fact that I intend the function
pointer to be of a kind that returns a ref int, I can't declare
that easily. Easy, declare an alias, right?
alias RefFunctionPointer = ref int function( int, int );
Alright, cool, that works. But thanks to the binding system
making heavy use of function pointers via code-time generated
code, that means we then have to come up with a unique name for
every function pointer symbol we'll need. Eep.
Rather, I have to do something like this:
template RefFunctionPointer( Params... ) if( Params.length > 1 )
{
ref Params[ 0 ] dodgyFunction( Params[ 1 .. $ ] );
alias RefFunctionPointer = typeof( &dodgyFunction );
}
RefFunctionPointer!( int, int, int ) functionPointer;
This can also alternately be done by generating a mixin string
for the alias inside of the template and not requiring a dummy
function to get the type from. Either way, it gets rid of the
unique name requirement but now we have template expansion in the
mix. Which is something I'll get to in a second...
Needless to say, this is something I wasted a lot of time on
three years ago when I was getting the bindings up to speed
originally. Turns out it's not any better in DMD 2.071.
2) Expansion of code (static foreach, templates) is slow to the
point where string mixins are a legitimate compile-time
optimisation
Take an example of whittling down a tuple/variable argument list.
Doing it recursively would look something like this:
template SomeEliminator( Symbols... )
{
static if( Symbols.length >= 1 )
{
static if( SomeCondition!( Symbol[ 0 ] ) )
{
alias SomeEliminator = TypeTuple!( Symbol[ 0 ], Symbols[ 1
.. $ ] );
}
else
{
alias SomeEliminator = TypeTuple!( Symbols[ 1 .. $ ] );
}
}
else
{
alias SomeEliminator = TypeTuple!( );
}
}
Okay, that works, but the template expansion is a killer on
compile-time performance. It's legitimately far quicker on the
compiler to do this:
template SomeEliminator( Symbols... )
{
string SymbolSelector()
{
string[] strOutputs;
foreach( iIndex, Symbol; Symbols )
{
static if( SomeCondition!( Symbol ) )
{
strOutputs ~= "Symbols[ " ~ iIndex.stringof ~ " ]";
}
}
return strOutputs.joinWith( ", " );
}
mixin( "alias SomeEliminator = TypeTuple!( " ~ SymbolSelector()
~ " );" );
}
With just a small codebase that I'm working on here, it chops
seconds off the compile time. Of course, maybe there's something
I'm missing here about variable parameter parsing and doing it
without a mixin is quite possible and just as quick as the mixin,
but that would make it the third method I know of to achieve the
same effect. The idiomatic way of doing this without mixins
should at least be defined, and optimised at the compiler level
so that people don't get punished for writing natural D code.
Then there was this one that I came across:
outofswitch: switch( symbolName )
{
foreach( Variable; VariablesOf!( SearchType ) )
{
case Variable.Name:
doSomething!( Variable.Type )();
break outofswitch;
}
default:
writeln( symbolName, " was not found!" );
break;
}
This caused compile time to blow way out. How far out? By
rewriting it like this, I cut compile times in half (at that
point, from 10 seconds to 5):
switch( symbolName )
{
mixin( generateSwitchFor!( SearchType )() );
default:
writeln( symbolName, " was not found!" );
break;
}
Now, I love mixins, both template form and string form. The
binding system uses them extensively. But mixins like this are
effectively a hack. Anytime I have to break out a mixin because
my compile time doubled from a seemingly simple piece of code is
not good.
3) __ctfe is not a CTFE symbol.
This one bit me when I was trying to be efficient for runtime
usage while allowing
Re: Things that make writing a clean binding system more difficult
On 7/28/2016 1:33 AM, Ethan Watson wrote:
1) Declaring a function pointer with a ref return value can't be done without
workarounds.
Try compiling this:
ref int function( int, int ) functionPointer;
It won't let you, because only parameters and for loop symbols can be ref types.
Despite the fact that I intend the function pointer to be of a kind that returns
a ref int, I can't declare that easily. Easy, declare an alias, right?
alias RefFunctionPointer = ref int function( int, int );
C/C++ have essentially the same problem, if you want to declare a function
pointer parameter that has different linkage.
The trouble is there's an ambiguity in the grammar. I don't really have anything
better than the two step process you outlined.
4) Forward declaring a function prototype means I can never declare that
function elsewhere (say, for example, with a mixin)
Do you mean:
void foo();
void foo() { }
?
Re: Things that make writing a clean binding system more difficult
On Thursday, 28 July 2016 at 08:49:35 UTC, Walter Bright wrote:
Do you mean:
void foo();
void foo() { }
?
Exactly this. I've been unable to get it to work.
Re: Things that make writing a clean binding system more difficult
On 7/28/2016 1:54 AM, Ethan Watson wrote:
On Thursday, 28 July 2016 at 08:49:35 UTC, Walter Bright wrote:
Do you mean:
void foo();
void foo() { }
?
Exactly this. I've been unable to get it to work.
https://issues.dlang.org/show_bug.cgi?id=16329
The reason it's an enhancement request rather than a bug is that with D's
support for forward referenced functions, having to declare them first followed
later by a definition was deemed unnecessary.
This pattern is, of course, necessary in C/C++ because they do not allow forward
referenced declarations outside of aggregates.
Re: Things that make writing a clean binding system more difficult
On 7/28/2016 1:33 AM, Ethan Watson wrote: I also assume "lodge a bug" will be the response to these. Indeed. That's the process. 2) Expansion of code (static foreach, templates) is slow to the point where string mixins are a legitimate compile-time optimisation https://issues.dlang.org/show_bug.cgi?id=16330
Re: Make D language as Apache foundation project
On Wednesday, 27 July 2016 at 15:44:21 UTC, Seb wrote: http://dlang.org/foundation.html Wow. This page details Andrei's full name: Tudor Andrei Cristian Alexandrescu. (o_O)
[OT] Re: Make D language as Apache foundation project
On Thursday, 28 July 2016 at 09:19:03 UTC, Jack Applegame wrote: On Wednesday, 27 July 2016 at 15:44:21 UTC, Seb wrote: http://dlang.org/foundation.html Wow. This page details Andrei's full name: Tudor Andrei Cristian Alexandrescu. (o_O) It's probably to avoid any confusion with the other Andrei Alexandrescu. (warning big LOL) http://adevarul.ro/locale/targoviste/performanTA-targovisteanul-andrei-alexandrescu-campion-national-culturism-1_50abbb487c42d5a6637f642b/index.html
Documented unittests & code coverage
Some time ago we moved some example code from documentation comments into documented unittests. Some of these more complicated examples are incomplete and therefore are not expected to actually run. These are also not very useful as real unittests as they do not contain any asserts or verification of results. Making them documented unittests was mainly done to make sure these examples keep compiling when there are library changes. I just had a quick look at https://github.com/dlang/phobos/pull/4587 and some example output: https://codecov.io/gh/wilzbach/phobos/src/5fc9eb90076101c0266fb3491ac68527d3520fba/std/digest/digest.d#L106 And it seems that this 'idiom' messes up code coverage results: The code in the unittest is never executed (we just want syntactically valid code) and therefore shows up as untested code. The code coverage shows 46 missed lines for std.digest.digest, but only 8 of these actually need testing. So how do we solve this? * Ignore lines in documented unittests for code coverage? * Make these examples completely executable, at the expense of documentation which will then contain useless boilerplate code * Move these examples back to the documentation block? And as a philosophical question: Is code coverage in unittests even a meaningful measurement? We write unittests to test the library code. But if there's a line in a unittests which is never executed, this does not directly mean there's a problem in library code, as long as all library code is still tested. It may be an oversight in the unittest in the worst case, but how important are ovesights / bugs in the unittests if they don't affect library code in any way?
Re: Things that make writing a clean binding system more difficult
On Thursday, 28 July 2016 at 08:33:22 UTC, Ethan Watson wrote:
This also isn't the only use case I have. I'm a game engine
programmer. We write a lot of abstracted interfaces with
platform specific implementations. I know, I know, version(X){}
your code, right? But that's not how everyone works. Some
implementations really do require their own file for
maintenance and legal purposes.
The usual idea for PAL structure is to put implementations in
separate folders:
src/lin/pal/utils.d - module pal.utils;
src/win/pal/utils.d - module pal.utils;
Then you can just import pal.utils; and invoke the compiler with
-Isrc/lin option.
Re: How do I use the ScopedAllocator?
On Monday, 25 July 2016 at 07:33:25 UTC, Yuxuan Shui wrote: Valgrind reports double free anyways. I think it's just the inaccuracy of the glibc double free detection. Please file a bug - thanks! https://issues.dlang.org/ I found this, maybe related: https://issues.dlang.org/show_bug.cgi?id=16046
Import from github
Hello everyone, can i do in D something like this: import "github.com/julienschmidt/httprouter" like in Golang?
Re: Import from github
On Thursday, 28 July 2016 at 13:31:59 UTC, eugene wrote: Hello everyone, can i do in D something like this: import "github.com/julienschmidt/httprouter" like in Golang? No, but many D libraries you find on github are registered on DUB, so you can use it to manage your dependencies (if that library is not registered on DUB, ask its maintainer to register it, as it's the best way to manage your dependencies in D).
Re: Import from github
On Thursday, 28 July 2016 at 13:39:43 UTC, Lodovico Giaretta wrote: On Thursday, 28 July 2016 at 13:31:59 UTC, eugene wrote: Hello everyone, can i do in D something like this: import "github.com/julienschmidt/httprouter" like in Golang? No, but many D libraries you find on github are registered on DUB, so you can use it to manage your dependencies (if that library is not registered on DUB, ask its maintainer to register it, as it's the best way to manage your dependencies in D) You might also subscribe to this thread: https://github.com/dlang/dub/issues/50
Re: Code coverage in Phobos
On Sunday, 10 July 2016 at 02:38:07 UTC, Seb wrote: On Wednesday, 25 May 2016 at 02:34:44 UTC, Seb wrote: On Tuesday, 29 March 2016 at 20:50:57 UTC, Seb wrote: Okay I see that for the long run we need a better way to handle the testing infrastructure :/ Actually the idea of achieving "100% coverage" is that we test every line at least once and don't let this testing by done by users. So to refresh the discussion - there were two general ideas 1) Find "bad", "dangerous" modules, e.g. /xml.d 64% /zlib.d 60% /experimental/allocator/typed.d 54% /experimental/allocator/building_blocks/segregator.d 50% /experimental/allocator/building_blocks/bucketizer.d 48% /encoding.d 66% /container/binaryheap.d 59% /digest/digest.d 72% 2) Increase coverage for generic, platform-independent modules like std.algorithm to 100% I know it's a lot of work, but shouldn't that make our jobs us maintainers easier (=catch the bugs before you have to fix them?). Therefore I am bumping this ;-) Just a quick follow-up on this. I finally managed to work a bit on the export to Codecov.io - it's pretty neat as it will warn reviewers if the coverage decreases due to changes in a PR. Moreover according to Codecov.io, Phobos currently has an overall coverage of 88.15% (the actual coverage is a bit higher, because I had to disable a few tests for Travis and missing, "uncovered" lines are also reported for e.g. deprecated lines). So if someone wants to improve not well-tested modules, at [1] is a list of all modules in Phobos with their coverage. Some highlights include: regex: 51% encoding.d: 62% mathspecial: 57% mmfile: 61% process: 69% socket: 66% zlib: 60% Hopefully in a few days this will be part of Phobos (see [2] for details) and thus automatically updated ;-) [1] https://codecov.io/gh/wilzbach/phobos/tree/5fc9eb90076101c0266fb3491ac68527d3520fba/std [2] https://github.com/dlang/phobos/pull/4587 Short update - the experiment is now live. Please help to kill the uncovered bits in Phobos :) A short overview of features CodeCov provides: 1) A CodeCov bot will warn the reviewers if (a) the code coverage decreased or (b) there are new, unhit lines added within a PR. 2) For every commit one can browse the current code coverage of all modules https://codecov.io/gh/dlang/phobos/tree/77bee525787a90759211dfeb7103ca608bb44bf0/std 3) They provide a handy dashboard with an overview of historic information https://codecov.io/gh/dlang/phobos (It's a bit empty atm, it might look like this: https://codecov.io/gh/libmir/mir) 4) CodeCov has a bunch of other features, for example browser extensions that integrate the code coverage report directly onto Github diffs: https://github.com/codecov/browser-extension That being said the current approach isn't perfect (see the PR for details), but it's hopefully a start to pay more attention to code coverage ;-)
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 07:12:06 UTC, Lodovico Giaretta
wrote:
On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
The point is though, that I WANT to use the GC. I want the
memory cleaned up for me, and I don't mind little pauses once
in a while. I just don't want careless allocations to happen
in certain performance-sensitive contexts, like per-frame
updates.
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
As utterly moronic as this seems, this was a real bug that I
had to fix. Our game was literally topping out at 2GB of
memory usage after ~30 seconds and crashing.
Note: it wasn't my code ;)
If that code was written in D with the feature I'm asking for,
draw() would have been marked with @nogc. The person who wrote
the above code would have either had to store the font
somewhere else, or insert a @assumenogc{} section to actually
do that. So it either would not have happened, or would have
been much easier to find.
If you found that your game/app was using too much GC,
searching for "@assumenogc" would likely uncover the cause, as
long as your root classes were annotated correctly. The
@assumenogc annotation would plainly show where allocations
were happening that maybe shouldn't be.
If @assumegc has to be manually checked to see if it is
over-allocating whenever the application is going out of
memory, then it is no more useful than running the gc-profiler
when the application is over-allocating. The profiler is even
better, because with @assumegc you have to check ALL marked
functions to find the leaking one, while the gc-profiler would
just put it on top of the report, making your job easier. So
IMHO we already have an instrument to solve these problems.
It's not about running out of memory. It's a performance issue.
Example: In the following class, it would be perfectly fine, and
even expected to allocate in start() but not in update(). This is
because start() gets called once on object initialization, but
update() would get called every frame.
class NPC {
//
void start() { this.hat = new Hat(); }
void update() @nogc {
this.timer += Clock.currTime;
check(this.timer);
updateUI();
}
}
Finally, the use of a profiler, and @nogc/@assumenogc wouldn't be
mutually exclusive. If a profiler had a filter-by-attribute
functionality, you could set it to @nogc functions, and it would
narrow down the results to the functions where allocations
actually matter.
Bit
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote: It's not about running out of memory. It's a performance issue. Example: In the following class, it would be perfectly fine, and even expected to allocate in start() but not in update(). This is because start() gets called once on object initialization, but update() would get called every frame. Vladimir implemented counting in -profile=gc, it gives you the number of allocations and the amount allocated for each allocation point.
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat wrote: On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote: It's not about running out of memory. It's a performance issue. Example: In the following class, it would be perfectly fine, and even expected to allocate in start() but not in update(). This is because start() gets called once on object initialization, but update() would get called every frame. Vladimir implemented counting in -profile=gc, it gives you the number of allocations and the amount allocated for each allocation point. I'm not sure if this point is meant to be for or against what I'm suggesting, but still, I'm thinking in terms of *proactively* writing efficient code, not allowing an app get to the point where you need to run a profiler. The situation is similar to using @safe. You *could* just write code however you want, wait until it crashes, then try to find the problem using Valgrind or something, but that's bad for obvious reasons. Bit
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 16:45:05 UTC, bitwise wrote:
On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat
wrote:
On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote:
It's not about running out of memory. It's a performance
issue.
Example: In the following class, it would be perfectly fine,
and even expected to allocate in start() but not in update().
This is because start() gets called once on object
initialization, but update() would get called every frame.
Vladimir implemented counting in -profile=gc, it gives you the
number of allocations and the amount allocated for each
allocation point.
I'm not sure if this point is meant to be for or against what
I'm suggesting, but still, I'm thinking in terms of
*proactively* writing efficient code, not allowing an app get
to the point where you need to run a profiler.
The situation is similar to using @safe. You *could* just write
code however you want, wait until it crashes, then try to find
the problem using Valgrind or something, but that's bad for
obvious reasons.
Bit
Just my 2 cents on naming: what you want sounds a lot more like
@warngc than @assumenogc or whatever was floating around before.
What such an attribute should do and if its worth implementing is
hard to figure out, though. Presumably you'd have your update()
method marked @warngc but then how is the compiler supposed to
know that an allocation like this:
class A {
void update() @warngc {
if(rareCondition()) {
// something that allocates
}
}
}
is perfectly fine, but something like this
class B {
void update() @warngc {
if(almostAlwaysTrue()) {
// something that allocates
}
}
}
is not?
That issue aside, what exactly do you envision the compiler to
tell you (examples of error messages and code patterns it should
detect, examples of code patterns that it should NOT detect and
are fine) incase it automagically finds problematic code?
I'm having trouble putting a thumb on what you want following
this thread, because what you are describing feels a bit vague to
me.
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 16:45:05 UTC, bitwise wrote: On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat wrote: On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote: It's not about running out of memory. It's a performance issue. Example: In the following class, it would be perfectly fine, and even expected to allocate in start() but not in update(). This is because start() gets called once on object initialization, but update() would get called every frame. Vladimir implemented counting in -profile=gc, it gives you the number of allocations and the amount allocated for each allocation point. I'm not sure if this point is meant to be for or against what I'm suggesting, but still, I'm thinking in terms of *proactively* writing efficient code, not allowing an app get to the point where you need to run a profiler. Well, here in my opinion there's the wrong attitude of profiling only when it becomes necessary (i.e. the app is slow or uses too much ram). This is wrong. You should profile before this happens; you should profile to see if the time/memory is spent in the parts of the application that should spend it and you should profile whenever you care about making good code and not just "code that works". You should profile while you add features, to see their impact on the overall performance. Profiling at the end, when you have a 100K LOC codebase deployed, because a user ran out of memory is too late: too late to allow to easily spot the problem and too late to think an alternative approach/algorithm/design, instead of just patching the problem.
Re: New __FILE_DIR__ trait?
On Thursday, 28 July 2016 at 06:21:06 UTC, Jonathan Marler wrote:
auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure
{
return fileFullPath.dirName;
}
Doesn't work, I don't think you can wrap such things ( __FILE__
and such ):
import std.stdio;
int main()
{
printNormal();
printWrapped();
return 0;
}
void printNormal(int line = __LINE__)
{
writefln("%s", line);
}
void printWrapped(int line = __MY_LINE__)
{
writefln("%s", line);
}
// wrapped version
int __MY_LINE__(int line = __LINE__)
{
return line;
}
$ rdmd demo.d
5
15 (should be 6!)
Thus, the suggested implementation of __DIR__ would behave very
differently from a builtin one. I'm not saying we need a builtin
one, however, it might not be a good idea to name it this way.
Re: New __FILE_DIR__ trait?
By the way, I really think __FILE_FULL_PATH__ should be a rdmd feature, not dmd. rdmd could set an environment variable "RDMD_FULL_PATH" or something like this (replacing argv[0]), instead of potentially making the compilation depend on the working copy location on disk...
[OT] Re: @gc attribute for bypassign @nogc
On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote: ... I like the typo in the title. Let's make a game: "write the `bypassign` function, its ddoc, and its unittests" :)
Re: Code coverage in Phobos
On 7/28/2016 7:16 AM, Seb wrote: 4) CodeCov has a bunch of other features, for example browser extensions that integrate the code coverage report directly onto Github diffs: https://github.com/codecov/browser-extension I installed the browser extension for Chrome, but it says "no coverage" for every Phobos PR I tried it on. Also, the umbrella icon is greyed out. Something's amiss?
Re: Code coverage in Phobos
On 7/28/2016 7:16 AM, Seb wrote: Short update - the experiment is now live. Please help to kill the uncovered bits in Phobos :) Thank you very much for doing this! Raising the visibility of code coverage will push towards much better unittesting of Phobos.
Re: [OT] Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 17:54:20 UTC, jdfgjdf wrote:
On Sunday, 24 July 2016 at 22:13:02 UTC, bitwise wrote:
...
I like the typo in the title. Let's make a game:
"write the `bypassign` function, its ddoc, and its unittests"
:)
Entry one:
/**
* Bypassign is a struct wrapper that bypasses the original
type's `opAssign()`,
* thus any assignation to the wrapped type is a noop.
*/
struct Bypassign(T)
if (is(T == struct))
{
private T _bypassigned;
alias _bypassigned this;
void opAssign(T)(auto ref T t)
{/*bypassignation*/}
}
///
unittest
{
static struct Foo
{
int i;
alias i this;
}
Bypassign!Foo bpaFoo;
bpaFoo = 1;
assert(bpaFoo == 0);
}
Re: Code coverage in Phobos
On Thursday, 28 July 2016 at 17:56:49 UTC, Walter Bright wrote: On 7/28/2016 7:16 AM, Seb wrote: 4) CodeCov has a bunch of other features, for example browser extensions that integrate the code coverage report directly onto Github diffs: https://github.com/codecov/browser-extension I installed the browser extension for Chrome, but it says "no coverage" for every Phobos PR I tried it on. Also, the umbrella icon is greyed out. Something's amiss? Hmm I guess we bumped into this issue: https://github.com/codecov/browser-extension/issues/22 - last time their support team was pretty fast, so I hope we can resolve this issue soon :) Do you see the Code coverage overlay for this diff? https://github.com/dlang/phobos/commit/6db08d3dadb007d930a4042a6140ca4fb22ea540 and on this file? https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d Older PRs don't show a coverage report, because the report needs to be uploaded & they don't have this in their `.travis.yml` yet. However rebasing should fix this.
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
It sounds like -vgc and --profile=gc are exactly what you want.
@nogc is meant to *guarantee* that the GC will not be called
within a function or any other functions called by that function.
Taking that guarantee away makes it effectively useless.
Re: Code coverage in Phobos
On 7/28/2016 11:51 AM, Seb wrote: Do you see the Code coverage overlay for this diff? https://github.com/dlang/phobos/commit/6db08d3dadb007d930a4042a6140ca4fb22ea540 Yes. Took me a moment to realize the green box meant covered. and on this file? https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d Yes. Older PRs don't show a coverage report, because the report needs to be uploaded & they don't have this in their `.travis.yml` yet. However rebasing should fix this. Thanks! Looks like I'll rebase all of my PRs and we'll see how it works!
Re: Things that make writing a clean binding system more difficult
On Thursday, July 28, 2016 01:49:35 Walter Bright via Digitalmars-d wrote: > On 7/28/2016 1:33 AM, Ethan Watson wrote: > > 1) Declaring a function pointer with a ref return value can't be done > > without workarounds. > > > > Try compiling this: > > > > ref int function( int, int ) functionPointer; > > > > It won't let you, because only parameters and for loop symbols can be ref > > types. Despite the fact that I intend the function pointer to be of a > > kind that returns a ref int, I can't declare that easily. Easy, declare > > an alias, right? > > > > alias RefFunctionPointer = ref int function( int, int ); > > C/C++ have essentially the same problem, if you want to declare a function > pointer parameter that has different linkage. > > The trouble is there's an ambiguity in the grammar. I don't really have > anything better than the two step process you outlined. Well, if we decided to make parens with ref legal, then we could make it work. e.g. ref(int) function(int, int) functionPointer; Now, I don't know of any other case where you'd actually use parens with ref if it were legal, but it would solve this particular case if we wanted to provide a way around the ambiguity. - Jonathan M Davis
Re: Documented unittests & code coverage
On Thursday, July 28, 2016 12:15:27 Johannes Pfau via Digitalmars-d wrote: > And as a philosophical question: Is code coverage in unittests even a > meaningful measurement? We write unittests to test the library code. But > if there's a line in a unittests which is never executed, this does not > directly mean there's a problem in library code, as long as all library > code is still tested. It may be an oversight in the unittest in the > worst case, but how important are ovesights / bugs in the unittests if > they don't affect library code in any way? https://issues.dlang.org/show_bug.cgi?id=14856 - Jonathan M Davis
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 16:58:14 UTC, default0 wrote:
On Thursday, 28 July 2016 at 16:45:05 UTC, bitwise wrote:
On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat
wrote:
On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote:
It's not about running out of memory. It's a performance
issue.
Example: In the following class, it would be perfectly fine,
and even expected to allocate in start() but not in
update(). This is because start() gets called once on object
initialization, but update() would get called every frame.
Vladimir implemented counting in -profile=gc, it gives you
the number of allocations and the amount allocated for each
allocation point.
I'm not sure if this point is meant to be for or against what
I'm suggesting, but still, I'm thinking in terms of
*proactively* writing efficient code, not allowing an app get
to the point where you need to run a profiler.
The situation is similar to using @safe. You *could* just
write code however you want, wait until it crashes, then try
to find the problem using Valgrind or something, but that's
bad for obvious reasons.
Bit
Just my 2 cents on naming: what you want sounds a lot more like
@warngc than @assumenogc or whatever was floating around
before. What such an attribute should do and if its worth
implementing is hard to figure out, though. Presumably you'd
have your update() method marked @warngc but then how is the
compiler supposed to know that an allocation like this:
class A {
void update() @warngc {
if(rareCondition()) {
// something that allocates
}
}
}
is perfectly fine, but something like this
class B {
void update() @warngc {
if(almostAlwaysTrue()) {
// something that allocates
}
}
}
is not?
That issue aside, what exactly do you envision the compiler to
tell you (examples of error messages and code patterns it
should detect, examples of code patterns that it should NOT
detect and are fine) incase it automagically finds problematic
code?
I'm having trouble putting a thumb on what you want following
this thread, because what you are describing feels a bit vague
to me.
I think you're complicating the issue quite a bit here.
It's very simple:
@nogc { /* in this scope, compiler disallows GC allocations. */ }
@nogc {
@assumenogc { /* here, GC allocations are allowed */ }
}
@assumenogc would simply reverse the effects of the @nogc flag on
a given scope.
So @nogc could be applied to performance critical scopes, as it
is now. The exception would be, that if I as a programmer knew
that I was only making a small one-time allocation, and that the
GC was still enabled, I could do so by surrounding the allocation
with @assumenogc.
Bit
Re: Code coverage in Phobos
On 7/28/2016 11:51 AM, Seb wrote: Older PRs don't show a coverage report, because the report needs to be uploaded & they don't have this in their `.travis.yml` yet. However rebasing should fix this. I rebased https://github.com/dlang/phobos/pull/4657 but it still shows [No coverage]
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 18:53:35 UTC, Meta wrote:
On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
It sounds like -vgc and --profile=gc are exactly what you want.
@nogc is meant to *guarantee* that the GC will not be called
within a function or any other functions called by that
function. Taking that guarantee away makes it effectively
useless.
I understand that @assumenogc may not be exactly the right
approach, but the underlying idea is sound, which is to have the
compiler to disallow all GC allocations in some annotated scope,
just like @nogc, but to allow the programmer to override the
@nogc restriction in certain cases.
There may be alternative approaches, and the @warngc idea was
just one random suggestion.
The point is, a mixture of @nogc and @assumenogc would achieve
exactly what I'm looking for. The only problem is that it may
cause issues for people that are using @nogc under a different
set of assumptions.
Bit
Re: Code coverage in Phobos
On Thursday, 28 July 2016 at 20:30:50 UTC, Walter Bright wrote: On 7/28/2016 11:51 AM, Seb wrote: Older PRs don't show a coverage report, because the report needs to be uploaded & they don't have this in their `.travis.yml` yet. However rebasing should fix this. I rebased https://github.com/dlang/phobos/pull/4657 but it still shows [No coverage] ... but it shows that those three lines are never hit ;-) As far as I understood [1] the problem is that the CodeCov browser extension has troubles handling merge commits. I will ping you once they resolved the issue and the PR view is working. For now you can click on "Last update 6db08d3...bb94012" to see the diff with overlayed code coverage. [1] https://github.com/codecov/browser-extension/issues/22
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 20:32:18 UTC, bitwise wrote:
On Thursday, 28 July 2016 at 18:53:35 UTC, Meta wrote:
On Thursday, 28 July 2016 at 00:23:57 UTC, bitwise wrote:
While working on a past project(C++), I found this little gem:
void draw() {
Font* f = new Font("arial.ttf", 16);
drawText(f, "hello world");
}
It sounds like -vgc and --profile=gc are exactly what you
want. @nogc is meant to *guarantee* that the GC will not be
called within a function or any other functions called by that
function. Taking that guarantee away makes it effectively
useless.
I understand that @assumenogc may not be exactly the right
approach, but the underlying idea is sound, which is to have
the compiler to disallow all GC allocations in some annotated
scope, just like @nogc, but to allow the programmer to override
the @nogc restriction in certain cases.
There may be alternative approaches, and the @warngc idea was
just one random suggestion.
The point is, a mixture of @nogc and @assumenogc would achieve
exactly what I'm looking for. The only problem is that it may
cause issues for people that are using @nogc under a different
set of assumptions.
Also, @assumenogc or whatever does not play well with public
APIs: if a library function is marked @nogc, its user can no
longer know if it is really @nogc or if it does allocate via
@assumenogc. This is not a good thing, as the user may want
*absolutely* no GC allocation in his program, and may even have
disabled the GC at program startup. Also, the code of that
maybe-not-@nogc library may not be available to check for this
thing. Maybe the user doesn't want to trust the library writer,
and so wants the compiler to guarantee no allocations at all.
Re: @gc attribute for bypassign @nogc
On 07/28/2016 10:46 PM, Lodovico Giaretta wrote: Also, the code of that maybe-not-@nogc library may not be available to check for this thing. Maybe the user doesn't want to trust the library writer, and so wants the compiler to guarantee no allocations at all. If you can't check the code, you have to trust the library writer. One can hack around @nogc as it is. It's not like dmd checks the object file for GC allocations.
Re: Things that make writing a clean binding system more difficult
On Thursday, 28 July 2016 at 20:16:11 UTC, Jonathan M Davis wrote: Well, if we decided to make parens with ref legal, then we could make it work. e.g. ref(int) function(int, int) functionPointer; Now, I don't know of any other case where you'd actually use parens with ref if it were legal, but it would solve this particular case if we wanted to provide a way around the ambiguity. - Jonathan M Davis On a somewhat related tangent, I was looking for the history of why ref was included in the language. My recollection of Andrei's book is that it just takes ref as a given, instead of pass by reference or address in C++, rather than say why that decision was made. I found that ref was added in D 1.011 as a replacement for inout. Looking through some of the D 1.0 documentation, I see that "C++ does not distinguish between in, out and ref (i.e. inout) parameters." but not much else.
D for competitive programming
I wanted to try topcoder problems (never used this site before) and I found out that it doesn't support dlang. They only have c++, java, c#, vb.net, python languages. It would be great to see D on this list. I found this thread https://apps.topcoder.com/forums/?module=Thread&threadID=703674 and it seems that it's not that easy to add new langauge and they are not very interested. And I think that one of the keys to make D more popular and attract more people to try it would be to promote D as a language for learning algorithms and competitive programming. This niche is mostly occupied by c++ and java. I think that D might be a very good candidate to push these languages in CP. I've also checked google code jam statistics and unfortunately D isn't very popular here compared to say golang or scala. https://www.go-hero.net/jam/16/languages https://www.go-hero.net/jam/15/languages https://www.go-hero.net/jam/14/languages https://www.go-hero.net/jam/13/languages
Re: Things that make writing a clean binding system more difficult
On 7/28/16 4:16 PM, Jonathan M Davis via Digitalmars-d wrote: On Thursday, July 28, 2016 01:49:35 Walter Bright via Digitalmars-d wrote: On 7/28/2016 1:33 AM, Ethan Watson wrote: 1) Declaring a function pointer with a ref return value can't be done without workarounds. Try compiling this: ref int function( int, int ) functionPointer; It won't let you, because only parameters and for loop symbols can be ref types. Despite the fact that I intend the function pointer to be of a kind that returns a ref int, I can't declare that easily. Easy, declare an alias, right? alias RefFunctionPointer = ref int function( int, int ); C/C++ have essentially the same problem, if you want to declare a function pointer parameter that has different linkage. The trouble is there's an ambiguity in the grammar. I don't really have anything better than the two step process you outlined. Well, if we decided to make parens with ref legal, then we could make it work. e.g. ref(int) function(int, int) functionPointer; Now, I don't know of any other case where you'd actually use parens with ref if it were legal, but it would solve this particular case if we wanted to provide a way around the ambiguity. No, because that implies a type-modifier. ref does not modify the type at all, it just specifies the storage class. -Steve
Re: D for competitive programming
On 7/28/16 5:20 PM, urxvt1 wrote: I wanted to try topcoder problems (never used this site before) and I found out that it doesn't support dlang. They only have c++, java, c#, vb.net, python languages. It would be great to see D on this list. I found this thread https://apps.topcoder.com/forums/?module=Thread&threadID=703674 and it seems that it's not that easy to add new langauge and they are not very interested. And I think that one of the keys to make D more popular and attract more people to try it would be to promote D as a language for learning algorithms and competitive programming. This niche is mostly occupied by c++ and java. I think that D might be a very good candidate to push these languages in CP. I used to be very into topcoder a long time ago and have some inside knowledge of how the system works (I used to write problem sets for them, and even extended their java app a couple times). They are likely not going to take a look at D because their main goal is one of matching high-demand component developers with buyers for those components. This is why you see those languages as the main pieces. I doubt D would fit in there. We need to make D more popular so they have no choice but to add it :) I believe they added C++ (it used to be Java only) to expand their reach to more developers (at the time, topcoder just did job searching, or maybe not even yet, it was very early), I don't know if they have a C++ component system. -Steve
Re: D for competitive programming
On Thursday, 28 July 2016 at 21:20:29 UTC, urxvt1 wrote: I wanted to try topcoder problems (never used this site before) and I found out that it doesn't support dlang. They only have c++, java, c#, vb.net, python languages. It would be great to see D on this list. I found this thread https://apps.topcoder.com/forums/?module=Thread&threadID=703674 and it seems that it's not that easy to add new langauge and they are not very interested. And I think that one of the keys to make D more popular and attract more people to try it would be to promote D as a language for learning algorithms and competitive programming. This niche is mostly occupied by c++ and java. I think that D might be a very good candidate to push these languages in CP. I've also checked google code jam statistics and unfortunately D isn't very popular here compared to say golang or scala. https://www.go-hero.net/jam/16/languages https://www.go-hero.net/jam/15/languages https://www.go-hero.net/jam/14/languages https://www.go-hero.net/jam/13/languages For what it's worth - HackerRank (a similar platform) supports D (2.071.1!). Sometimes writing the customer support & complaining about outdated versions does help :) https://www.hackerrank.com/environment
Re: @gc attribute for bypassign @nogc
On Thursday, 28 July 2016 at 21:07:22 UTC, ag0aep6g wrote:
On 07/28/2016 10:46 PM, Lodovico Giaretta wrote:
Also, the code of that maybe-not-@nogc library may not be
available to
check for this thing. Maybe the user doesn't want to trust the
library
writer, and so wants the compiler to guarantee no allocations
at all.
If you can't check the code, you have to trust the library
writer. One can hack around @nogc as it is. It's not like dmd
checks the object file for GC allocations.
Yeah... So on one hand, currently, you could potentially have
some random hack misbehaving inside @nogc code with no way to
detect it, whereas a simple search for @assumenogc would
immediately tell you if the @nogc convention was being broken for
any reason. On the other hand, adding @assumenogc may increase
the amount of instances where this is happening, cause this
search to be mandatory for every package you decide to download.
Maybe if there were 3 variations, this could work:
// use current convention. 100% guarantee, no allocations.
@nogc
// same as current, but restriction can be broken by @nogc(off)
@nogc(weak)
// allows allocations. Can only override @nogc(weak), but not
@nogc.
@nogc(off)
Example:
class NPC {
Cake cake;
void start() {
cake = new Cake(); // OK
}
void update() @nogc(weak) {
cake = new Cake(); // error: cannot allocate here
@nogc(off) {
cake = new Cake(); // ok: alloc allowed in @nogc(off)
}
}
void draw() @nogc {
@nogc(off) {// error: @nogc(off) not legal inside @nogc
cake = new Cake();
}
bar(); // error: nogc(weak) not callable here
}
void bar() @nogc(weak) { }
}
Re: Code coverage in Phobos
On 7/28/2016 1:46 PM, Seb wrote: For now you can click on "Last update 6db08d3...bb94012" to see the diff with overlayed code coverage. I don't see where that link is.
Re: Documented unittests & code coverage
On 7/28/2016 3:15 AM, Johannes Pfau wrote: And as a philosophical question: Is code coverage in unittests even a meaningful measurement? Yes. I've read all the arguments against code coverage testing. But in my usage of it for 30 years, it has been a dramatic and unqualified success in improving the reliability of shipping code.
Re: Documented unittests & code coverage
On Thursday, 28 July 2016 at 23:14:42 UTC, Walter Bright wrote: On 7/28/2016 3:15 AM, Johannes Pfau wrote: And as a philosophical question: Is code coverage in unittests even a meaningful measurement? Yes. I've read all the arguments against code coverage testing. But in my usage of it for 30 years, it has been a dramatic and unqualified success in improving the reliability of shipping code. @Walter: the discussion is not about code coverage in general, but whether code coverage within unittests should be reported, because we are only interested in the coverage of the library itself and as Johannes and Jonathan pointed out there are some valid patterns (e.g. scope(failure)) that are used within unittests and never called. However as Jonathan mentioned in the Bugzilla issue, the downside of not counting within unittest blocks is that potential bugs in the unittests can't be catched that easy anymore.
Re: Code coverage in Phobos
On Thursday, 28 July 2016 at 23:11:04 UTC, Walter Bright wrote: On 7/28/2016 1:46 PM, Seb wrote: For now you can click on "Last update 6db08d3...bb94012" to see the diff with overlayed code coverage. I don't see where that link is. Sorry about being so vague. e.g. on this PR (https://github.com/dlang/phobos/pull/4657), there is the following message. The link "Last update" is on the last line. Current coverage is 88.68% (diff: 87.09%) Merging #4655 into master will increase coverage by <.01% @@ master #4655 diff @@ == Files 121121 Lines 73827 73849+22 Methods 0 0 Messages 0 0 Branches 0 0 == + Hits 65471 65492+21 - Misses 8356 8357 +1 Partials 0 0 Powered by Codecov. Last update 6db08d3...2002c65 <-- CLICK HERE
Re: Code coverage in Phobos
On 7/28/2016 4:39 PM, Seb wrote: e.g. on this PR (https://github.com/dlang/phobos/pull/4657), there is the following message. The link "Last update" is on the last line. Ok, I see it now. Thanks!
Re: Things that make writing a clean binding system more difficult
On 28.07.2016 10:49, Walter Bright wrote:
On 7/28/2016 1:33 AM, Ethan Watson wrote:
1) Declaring a function pointer with a ref return value can't be done
without
workarounds.
Try compiling this:
ref int function( int, int ) functionPointer;
It won't let you, because only parameters and for loop symbols can be
ref types.
Despite the fact that I intend the function pointer to be of a kind
that returns
a ref int, I can't declare that easily. Easy, declare an alias, right?
alias RefFunctionPointer = ref int function( int, int );
C/C++ have essentially the same problem, if you want to declare a
function pointer parameter that has different linkage.
The trouble is there's an ambiguity in the grammar. I don't really have
anything better than the two step process you outlined.
...
My parser accepts the following:
int function(int,int)ref functionPointer;
I wasn't really aware that this was illegal in DMD. (Other function
attributes, such as pure, are accepted.)
In fact, even the following is disallowed:
int foo(int)ref{}
Should I file an enhancement request?
Re: Documented unittests & code coverage
On Thursday, July 28, 2016 16:14:42 Walter Bright via Digitalmars-d wrote: > On 7/28/2016 3:15 AM, Johannes Pfau wrote: > > And as a philosophical question: Is code coverage in unittests even a > > meaningful measurement? > > Yes. I've read all the arguments against code coverage testing. But in my > usage of it for 30 years, it has been a dramatic and unqualified success in > improving the reliability of shipping code. The issue isn't whether we should have code coverage testing. We agree that that's a great thing. The issue is whether the lines in the unit tests themselves should count towards the coverage results. https://issues.dlang.org/show_bug.cgi?id=14856 gives some good examples of why having the unittest blocks themselves counted in the total percentage is problematic and can lead to dmd's code coverage tool listing than 100% coverage in a module that is fully tested. What's critical is that the code itself has the coverage testing not that the lines in the tests which are doing that testing be counted as part of the code that is or isn't covered. I know that it will frequently be the case that I will not get 100% code coverage per -cov for the code that I write simply because I frequently do stuff like use scope(failure) writefln(...) to print useful information on failure in unittest blocks so that I can debug what happened when things go wrong (including when someone reports failures on their machine that don't happen on mine). D's code coverage tools are fantastic to have, but they do need a few tweaks if we want to actually be reporting 100% code coverage for fully tested modules. A couple of other reports that I opened a while back are https://issues.dlang.org/show_bug.cgi?id=14855 https://issues.dlang.org/show_bug.cgi?id=14857 - Jonathan M Davis
Re: D for competitive programming
On 29.07.2016 00:07, Seb wrote: On Thursday, 28 July 2016 at 21:20:29 UTC, urxvt1 wrote: I wanted to try topcoder problems (never used this site before) and I found out that it doesn't support dlang. They only have c++, java, c#, vb.net, python languages. It would be great to see D on this list. I found this thread https://apps.topcoder.com/forums/?module=Thread&threadID=703674 and it seems that it's not that easy to add new langauge and they are not very interested. And I think that one of the keys to make D more popular and attract more people to try it would be to promote D as a language for learning algorithms and competitive programming. This niche is mostly occupied by c++ and java. I think that D might be a very good candidate to push these languages in CP. I've also checked google code jam statistics and unfortunately D isn't very popular here compared to say golang or scala. https://www.go-hero.net/jam/16/languages https://www.go-hero.net/jam/15/languages https://www.go-hero.net/jam/14/languages https://www.go-hero.net/jam/13/languages For what it's worth - HackerRank (a similar platform) supports D (2.071.1!). Sometimes writing the customer support & complaining about outdated versions does help :) https://www.hackerrank.com/environment http://codeforces.com/ is currently at DMD32 v2.069.2.
Re: Things that make writing a clean binding system more difficult
On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
> My parser accepts the following:
>
> int function(int,int)ref functionPointer;
>
> I wasn't really aware that this was illegal in DMD. (Other function
> attributes, such as pure, are accepted.)
>
> In fact, even the following is disallowed:
> int foo(int)ref{}
>
>
> Should I file an enhancement request?
Except that ref isn't a function attribute. It's an attribute on the return
type. So, it doesn't make sense for it to be on the right. That would be
like having the const on the right-hand side of a member function apply to
the return type rather than the function itself.
- Jonathan M Davis
Re: Documented unittests & code coverage
On 7/28/2016 9:48 PM, Jonathan M Davis via Digitalmars-d wrote: gives some good examples of why having the unittest blocks themselves counted in the total percentage is problematic and can lead to dmd's code coverage tool listing than 100% coverage in a module that is fully tested. What's critical is that the code itself has the coverage testing not that the lines in the tests which are doing that testing be counted as part of the code that is or isn't covered. I know that it will frequently be the case that I will not get 100% code coverage per -cov for the code that I write simply because I frequently do stuff like use scope(failure) writefln(...) to print useful information on failure in unittest blocks so that I can debug what happened when things go wrong (including when someone reports failures on their machine that don't happen on mine). D's code coverage tools are fantastic to have, but they do need a few tweaks if we want to actually be reporting 100% code coverage for fully tested modules. A couple of other reports that I opened a while back are As soon as we start taking the % coverage too seriously, we are in trouble. It's never going to be cut and dried what should be tested and what is unreasonable to test, and I see no point in arguing about it. The % is a useful indicator, that is all. It is not a substitute for thought. As always, use good judgement.
Re: Documented unittests & code coverage
On Thursday, July 28, 2016 22:12:58 Walter Bright via Digitalmars-d wrote: > As soon as we start taking the % coverage too seriously, we are in trouble. > It's never going to be cut and dried what should be tested and what is > unreasonable to test, and I see no point in arguing about it. > > The % is a useful indicator, that is all. It is not a substitute for > thought. > > As always, use good judgement. True, but particularly when you start doing stuff like trying to require that modules have 100% coverage - or that the coverage not be reduced by a change - it starts mattering - especially if it's done with build tools. The current situation is far from the end of the world, but I definitely think that we'd be better off if we fixed some of these issues so that the percentage reflected the amount of the actual code that's covered rather than having unit tests, assert(0) statements, invariants, etc. start affecting code coverage when they aren't what you're trying to cover at all. - Jonathan M Davis
Re: Documented unittests & code coverage
On Friday, 29 July 2016 at 05:12:58 UTC, Walter Bright wrote: As soon as we start taking the % coverage too seriously, we are in trouble. It's never going to be cut and dried what should be tested and what is unreasonable to test, and I see no point in arguing about it. The % is a useful indicator, that is all. It is not a substitute for thought. As always, use good judgement. In the context of the bug, we are not the ones interpreting the statistic, we're the ones measuring and reporting it to users, and it's being measured incorrectly. By deciding not to fix a bug that causes an inaccurate statistic to be reported, you're making a decision on the user's behalf that coverage % is unimportant without knowing their circumstances. If you're going to include coverage % in the report, then a job worth doing is worth doing well.
Re: Things that make writing a clean binding system more difficult
On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
My parser accepts the following:
int function(int,int)ref functionPointer;
I wasn't really aware that this was illegal in DMD. (Other function
attributes, such as pure, are accepted.)
In fact, even the following is disallowed:
int foo(int)ref{}
Should I file an enhancement request?
Except that ref isn't a function attribute.
Yes it is.
int x;
ref{
int foo(){ return x;}
}
pragma(msg, typeof(&foo()));
It's an attribute on the return type.
There is no such thing. Types cannot have attributes.
So, it doesn't make sense for it to be on the right. That would be
like having the const on the right-hand side of a member function apply to
the return type rather than the function itself.
...
You have it backwards.
Re: Things that make writing a clean binding system more difficult
On Friday, July 29, 2016 08:29:19 Timon Gehr via Digitalmars-d wrote:
> On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
> > On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
> >> My parser accepts the following:
> >>
> >> int function(int,int)ref functionPointer;
> >>
> >> I wasn't really aware that this was illegal in DMD. (Other function
> >> attributes, such as pure, are accepted.)
> >>
> >> In fact, even the following is disallowed:
> >> int foo(int)ref{}
> >>
> >>
> >> Should I file an enhancement request?
> >
> > Except that ref isn't a function attribute.
>
> Yes it is.
>
> int x;
> ref{
> int foo(){ return x;}
> }
> pragma(msg, typeof(&foo()));
That's downright bizzarre given that ref applies to the return type and not
to the this pointer (and that function doesn't even have a this pointer,
since it's not a member function).
> > It's an attribute on the return type.
>
> There is no such thing. Types cannot have attributes.
Sure they can. e.g.
auto func(ref int param) {...}
The same with in and out. They apply to the type of the parameter without
actually being part of it.
> > So, it doesn't make sense for it to be on the right. That would be
> > like having the const on the right-hand side of a member function apply to
> > the return type rather than the function itself.
> > ...
>
> You have it backwards.
It looks to me like the compiler is treating ref in a schizophrenic manner
given that when it's used on a parameter, it treats it as part of the
parameter, whereas with the return type, it's treating it as a function
attribute instead of associating it with the return type. I'd guess that
that stems from the fact that while ref is really supposed to be associated
with the type, it's not actually part of the type.
- Jonathan M Davis
Re: Documented unittests & code coverage
On 7/28/2016 10:49 PM, Jonathan M Davis via Digitalmars-d wrote: True, but particularly when you start doing stuff like trying to require that modules have 100% coverage - or that the coverage not be reduced by a change - it starts mattering - especially if it's done with build tools. The current situation is far from the end of the world, but I definitely think that we'd be better off if we fixed some of these issues so that the percentage reflected the amount of the actual code that's covered rather than having unit tests, assert(0) statements, invariants, etc. start affecting code coverage when they aren't what you're trying to cover at all. Worrying about this just serves no purpose. Code coverage percentages are a guide, an indicator, not a requirement in and of itself. Changing the code in order to manipulate the number to meet some metric means the reviewer or the programmer or both have failed.
