Re: Advanced code coverage analysis
On Wednesday, 6 December 2017 at 03:15:38 UTC, Walter Bright wrote: On 12/5/2017 2:55 AM, Basile B. wrote: On Monday, 4 December 2017 at 20:33:56 UTC, thinwybk wrote: Hi everyone, as far as I know there is a statement coverage analyzer built into DMD https://dlang.org/code_coverage.html . Are there code coverage analyzers for D which support branch coverage and other more advanced coverage metrics https://en.wikipedia.org/wiki/Code_coverage ? Cheers, thinwybk No, the compiler reports only statement coverage. Higher levels reports could be made by a tool that would use the LST file and the AST produced by libdparse. The wiki lists function coverage, statement coverage, branch coverage, and condition coverage. The builtin coverage analyzer does all of them. However, if you put multiple statements, conditions, etc., on one line, you'll get the sum of the usage counts. Indeed, but there's still some room for a tool. I'd add this to my IDE since for now coverage is not indicated in the code editor but in the messages (a message for each line that's not covered). Anyway it's a two days project (at most), i've proposed it to D-Scanner: https://github.com/dlang-community/D-Scanner/issues/540
Re: Adding Markdown to Ddoc
On 12/5/2017 8:37 PM, Mike Parker wrote: Can you see me jumping up and down over here? No, but my seismometer is showing some action!
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Can you see me jumping up and down over here? I don't care about it for source documentation, but if we could start using Mardkown in place of Ddoc macros for the web site, woohoo!
Re: Adding Markdown to Ddoc
We should probably do the opposite. Build a markdown parser and then have a way to give the output an understanding of ddoc features. It will also be usable in other projects ;)
Adding Markdown to Ddoc
https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.)
Re: Advanced code coverage analysis
On 12/5/2017 2:55 AM, Basile B. wrote: On Monday, 4 December 2017 at 20:33:56 UTC, thinwybk wrote: Hi everyone, as far as I know there is a statement coverage analyzer built into DMD https://dlang.org/code_coverage.html . Are there code coverage analyzers for D which support branch coverage and other more advanced coverage metrics https://en.wikipedia.org/wiki/Code_coverage ? Cheers, thinwybk No, the compiler reports only statement coverage. Higher levels reports could be made by a tool that would use the LST file and the AST produced by libdparse. The wiki lists function coverage, statement coverage, branch coverage, and condition coverage. The builtin coverage analyzer does all of them. However, if you put multiple statements, conditions, etc., on one line, you'll get the sum of the usage counts.
Re: (Possibly paid opportunity): PyD - Win 64
On Saturday, 2 December 2017 at 09:12:07 UTC, Thomas Mader wrote: On Friday, 1 December 2017 at 13:30:21 UTC, Laeeth Isharc wrote: Hi. I'd like to get PyD working on Windows 64. I think it's probably just a simple linking / library problem, but don't have time to work on it myself right now. If somebody would be interested in helping, we could pay for help on this. laeeth at kaleidic.io Thanks. Laeeth. Just found https://github.com/ariovistus/pyd/issues/67 Thanks. I didn't try yet but reckon Nic is right - just something small.
Re: Embedded Containers
On Tuesday, 5 December 2017 at 19:13:10 UTC, A Guy With a Question wrote: Ok, so that worked. I still have the problem with importing though: mypackage: Item seems to generate the error: "Error: undefined identifier 'Item'" Which is weird, because I'm able to bring in Array through std.container.array: Array; mypackage.mymodule : Item;
Re: Building is slow!
On Tuesday, 5 December 2017 at 19:28:12 UTC, Ivan Trombley wrote: There are issues with using "--build-mode=singleFile --parallel". On Windows I get errors saying that it can't write out some intermediate files (it looks like the file names may be too long for Windows) and on Linux, it makes the executable at least 3 MB larger in release mode. Also, it doesn't always seem to make building faster. On a 2 core i7 machine, it actually takes nearly twice as long to build. On my old i7-950, simple demo (cairo_clock) compiles (in release mode) below 4 minutes and uses 1.8GB of RAM (linux, one core used). Rebuild is done in about 3 seconds. I think Windows may introduce some problems in case of parallel access to files (especially if something is deleted). But I have no idea why your builds last so long. :/
Re: Embedded Containers
On Tuesday, 5 December 2017 at 22:21:51 UTC, Jonathan M Davis wrote: On Tuesday, December 05, 2017 22:09:12 A Guy With a Question via Digitalmars-d wrote: Is there actually a difference between the c style cast and cast(type)? Other than verbosity... They're not the same. D's cast is not split up like C++'s casts are, but it's not exactly the same as C's cast either - e.g. like C++'s dynamic_cast, if a class to class conversion fails, you get null, which C's cast doesn't do. Also, I think that D's cast is pickier about what it will let you do, whereas C's cast is more likely to want to smash something into something else if you ask it even if it doesn't make sense. And of course, D's cast understands D stuff that doesn't even exist in C (like delegates). I don't know exactly what all of the differences are though. Regardless, the reason for the verbosity is so that you can easily grep for casts in your code. - Jonathan M Davis That's the best reason for verbosity I've heard.
Re: Embedded Containers
On Tuesday, December 05, 2017 22:09:12 A Guy With a Question via Digitalmars-d wrote: > Is there actually a difference between the c style cast and > cast(type)? Other than verbosity... They're not the same. D's cast is not split up like C++'s casts are, but it's not exactly the same as C's cast either - e.g. like C++'s dynamic_cast, if a class to class conversion fails, you get null, which C's cast doesn't do. Also, I think that D's cast is pickier about what it will let you do, whereas C's cast is more likely to want to smash something into something else if you ask it even if it doesn't make sense. And of course, D's cast understands D stuff that doesn't even exist in C (like delegates). I don't know exactly what all of the differences are though. Regardless, the reason for the verbosity is so that you can easily grep for casts in your code. - Jonathan M Davis
Re: Embedded Containers
On Tuesday, 5 December 2017 at 20:38:01 UTC, Timon Gehr wrote: On 05.12.2017 20:11, H. S. Teoh wrote: On Tue, Dec 05, 2017 at 07:09:50PM +, Adam D. Ruppe via Digitalmars-d wrote: On Tuesday, 5 December 2017 at 19:01:48 UTC, A Guy With a Question wrote: alias Items(T) = Array!Item(T); try: Array!(Item!(T)) I'm not quite sure I understand how to create a generic container interface or class in D. Just using the parenthesis should help. The thing with A!B!C is that the reader can easily be confused: did you mean A!(B!C) or (A!B)!C or what? Now the compiler is a bit stupider about this than it should be IMO - it should be able to figure it out and the meaning be fairly clear with association - but it isn't, so you can and must write parens to clarify most the time. Here's an idea for a DIP: make '!' right-to-left associative (i.e., similar to the ^^ exponentiation operator), so that A!B!C is understood as A!(B!C). Rationale: the most common use cases are of the A!(B!C) variety; it's pretty rare IME to need the (A!B)!C form, since usually a template expands to a type, which can then be passed to another template, i.e., A!(B!C). The (A!B)!C form is when the template instantiated with B produces another template that takes another type argument. There aren't many use cases for this that I can think of. ... Curried templates are actually common enough in Phobos. (map, filter, etc.) Though the point is probably moot, because in the current grammar you'd need parentheses as soon as the template argument is anything more than a single token, i.e., you can write A!int but you have to write A!(const(int)). And in the cases where you actually want something of the form A!(B!C), usually the arguments are themselves pretty complicated, so wouldn't benefit from top-level associativity anyway. T IMHO the inconsistency with function call syntax ought to kill this proposal. Also, it is a bit more confusing than it is useful. Related: It's quite annoying that (A!B)!C does not work because the parser thinks it's a C-style cast and errors out even though C-style casts are not even valid D syntax. Is there actually a difference between the c style cast and cast(type)? Other than verbosity...
Re: Embedded Containers
On 05.12.2017 20:11, H. S. Teoh wrote: On Tue, Dec 05, 2017 at 07:09:50PM +, Adam D. Ruppe via Digitalmars-d wrote: On Tuesday, 5 December 2017 at 19:01:48 UTC, A Guy With a Question wrote: alias Items(T) = Array!Item(T); try: Array!(Item!(T)) I'm not quite sure I understand how to create a generic container interface or class in D. Just using the parenthesis should help. The thing with A!B!C is that the reader can easily be confused: did you mean A!(B!C) or (A!B)!C or what? Now the compiler is a bit stupider about this than it should be IMO - it should be able to figure it out and the meaning be fairly clear with association - but it isn't, so you can and must write parens to clarify most the time. Here's an idea for a DIP: make '!' right-to-left associative (i.e., similar to the ^^ exponentiation operator), so that A!B!C is understood as A!(B!C). Rationale: the most common use cases are of the A!(B!C) variety; it's pretty rare IME to need the (A!B)!C form, since usually a template expands to a type, which can then be passed to another template, i.e., A!(B!C). The (A!B)!C form is when the template instantiated with B produces another template that takes another type argument. There aren't many use cases for this that I can think of. ... Curried templates are actually common enough in Phobos. (map, filter, etc.) Though the point is probably moot, because in the current grammar you'd need parentheses as soon as the template argument is anything more than a single token, i.e., you can write A!int but you have to write A!(const(int)). And in the cases where you actually want something of the form A!(B!C), usually the arguments are themselves pretty complicated, so wouldn't benefit from top-level associativity anyway. T IMHO the inconsistency with function call syntax ought to kill this proposal. Also, it is a bit more confusing than it is useful. Related: It's quite annoying that (A!B)!C does not work because the parser thinks it's a C-style cast and errors out even though C-style casts are not even valid D syntax.
unicode combinig mark/ std.uni question
Hello, I have to create very basic IDNA (Internationalized Domain Names in Applications) library. There are two parts in IDNA - user input checks and punycode encoding/decoding. Punycode part already completed, and now I have to add some checks but I'm weak in unicode and cant find proper way to express these tests using std.uni. Here are list of prohibited domain labels (https://tools.ietf.org/html/rfc5891): o Labels whose first character is a combining mark (see The Unicode Standard, Section 2.11 [Unicode]). o Labels containing prohibited code points, i.e., those that are assigned to the "DISALLOWED" category of the Tables document [RFC5892]. o Labels containing code points that are identified in the Tables document as "CONTEXTJ", i.e., requiring exceptional contextual rule processing on lookup, but that do not conform to those rules. Note that this implies that a rule must be defined, not null: a character that requires a contextual rule but for which the rule is null is treated in this step as having failed to conform to the rule. o Labels containing code points that are identified in the Tables document as "CONTEXTO", but for which no such rule appears in the table of rules. Applications resolving DNS names or carrying out equivalent operations are not required to test contextual rules for "CONTEXTO" characters, only to verify that a rule is defined (although they MAY make such tests to provide better protection or give better information to the user). o Labels containing code points that are unassigned in the version of Unicode being used by the application, i.e., in the UNASSIGNED category of the Tables document. Can anybody help with this task? Thanks!
Re: What does the following program do?
On 12/05/2017 06:11 AM, Shachar Shemesh wrote: > "move" was supposed to initialize "source" to init. This does not appear > to be the case. Is that a bug? Where? The same issue came up recently in the learn group regarding moveFront(). The documentation fails to mention that the .init behavior is only for hasElaborateCopyConstructor!(ElementType!R): http://forum.dlang.org/post/ovs6hq$1gfh$1...@digitalmars.com Finally opened an issue about that one: https://issues.dlang.org/show_bug.cgi?id=18036 Ali
Re: Embedded Containers
On Tuesday, 5 December 2017 at 19:19:50 UTC, colin wrote: On Tuesday, 5 December 2017 at 19:13:10 UTC, A Guy With a Question wrote: On Tuesday, 5 December 2017 at 19:09:50 UTC, Adam D. Ruppe wrote: [...] Ok, so that worked. I still have the problem with importing though: mypackage: Item seems to generate the error: "Error: undefined identifier 'Item'" Which is weird, because I'm able to bring in Array through std.container.array: Array; Is Item public in your package? Yes. I fixed it by not referencing it by the package but by the file specific module I created. That worked. All errors are resolved now. Thanks! I think maybe the import issue was because there was a circular import happening. So I have a few sub modules: module item.d other.d package.d where other.d uses Item from item.d. But I was pulling item from package. When I pulled it directly from item.d it compiled fine. So maybe it can't handle the circular referencing there.
Re: Building is slow!
There are issues with using "--build-mode=singleFile --parallel". On Windows I get errors saying that it can't write out some intermediate files (it looks like the file names may be too long for Windows) and on Linux, it makes the executable at least 3 MB larger in release mode. Also, it doesn't always seem to make building faster. On a 2 core i7 machine, it actually takes nearly twice as long to build.
Re: Embedded Containers
On Tue, Dec 05, 2017 at 07:09:50PM +, Adam D. Ruppe via Digitalmars-d wrote: > On Tuesday, 5 December 2017 at 19:01:48 UTC, A Guy With a Question wrote: > > alias Items(T) = Array!Item(T); > > try: > > Array!(Item!(T)) > > > I'm not quite sure I understand how to create a generic container > > interface or class in D. > > Just using the parenthesis should help. The thing with A!B!C is that > the reader can easily be confused: did you mean A!(B!C) or (A!B)!C or > what? Now the compiler is a bit stupider about this than it should be > IMO - it should be able to figure it out and the meaning be fairly > clear with association - but it isn't, so you can and must write > parens to clarify most the time. Here's an idea for a DIP: make '!' right-to-left associative (i.e., similar to the ^^ exponentiation operator), so that A!B!C is understood as A!(B!C). Rationale: the most common use cases are of the A!(B!C) variety; it's pretty rare IME to need the (A!B)!C form, since usually a template expands to a type, which can then be passed to another template, i.e., A!(B!C). The (A!B)!C form is when the template instantiated with B produces another template that takes another type argument. There aren't many use cases for this that I can think of. Though the point is probably moot, because in the current grammar you'd need parentheses as soon as the template argument is anything more than a single token, i.e., you can write A!int but you have to write A!(const(int)). And in the cases where you actually want something of the form A!(B!C), usually the arguments are themselves pretty complicated, so wouldn't benefit from top-level associativity anyway. T -- Doubt is a self-fulfilling prophecy.
Re: Embedded Containers
On Tuesday, 5 December 2017 at 19:13:10 UTC, A Guy With a Question wrote: On Tuesday, 5 December 2017 at 19:09:50 UTC, Adam D. Ruppe wrote: [...] Ok, so that worked. I still have the problem with importing though: mypackage: Item seems to generate the error: "Error: undefined identifier 'Item'" Which is weird, because I'm able to bring in Array through std.container.array: Array; Is Item public in your package?
Re: Embedded Containers
On Tuesday, 5 December 2017 at 19:09:50 UTC, Adam D. Ruppe wrote: On Tuesday, 5 December 2017 at 19:01:48 UTC, A Guy With a Question wrote: alias Items(T) = Array!Item(T); try: Array!(Item!(T)) I'm not quite sure I understand how to create a generic container interface or class in D. Just using the parenthesis should help. The thing with A!B!C is that the reader can easily be confused: did you mean A!(B!C) or (A!B)!C or what? Now the compiler is a bit stupider about this than it should be IMO - it should be able to figure it out and the meaning be fairly clear with association - but it isn't, so you can and must write parens to clarify most the time. Ok, so that worked. I still have the problem with importing though: mypackage: Item seems to generate the error: "Error: undefined identifier 'Item'" Which is weird, because I'm able to bring in Array through std.container.array: Array;
Re: Embedded Containers
On Tuesday, 5 December 2017 at 19:01:48 UTC, A Guy With a
Question wrote:
The following doesn't appear to be valid syntax. Array!Item!T
I get the following error:
"multiple ! arguments are not allowed"
Which is ok...I get THAT error, however, this does not work
either:
alias Items(T) = Array!Item(T);
This gives me the error:
Error: function declaration without return type. (Note that
constructors are always named `this`)
Your wrapping the wrong part in parentheses.
Array!(Item!T)
It would actually be Array!(Item!(T)), but if a single type is
specified you're allowed to omit the parentheses when
instantiating.
Item is defined as follows:
interface Item(T)
{
@property
T member();
}
That part compiles fine. However, even when I remove the
aliasing, I can't import this interface. I get "Error:
undefined identifier 'Item'"
I'm not quite sure I understand how to create a generic
container interface or class in D. Half of how I expect it to
work works, but the other half doesn't. The docs aren't too
helpful. I'm not sure if it's a case where there's just too
much to go through or if what I'm trying to do isn't really
covered. Essentially I'm trying to create an array of this type
'Item' that has some generic members. I think people who come
from C# will kind of get what I'm trying to do here, because
I'm trying to port C# code.
What other problems are you having? I did the same and it was
fairly straightforward.
Re: Embedded Containers
On Tuesday, 5 December 2017 at 19:01:48 UTC, A Guy With a Question wrote: alias Items(T) = Array!Item(T); try: Array!(Item!(T)) I'm not quite sure I understand how to create a generic container interface or class in D. Just using the parenthesis should help. The thing with A!B!C is that the reader can easily be confused: did you mean A!(B!C) or (A!B)!C or what? Now the compiler is a bit stupider about this than it should be IMO - it should be able to figure it out and the meaning be fairly clear with association - but it isn't, so you can and must write parens to clarify most the time.
Re: Embedded Containers
Ah crud, I posted this to the wrong forum. Sorry.
Embedded Containers
The following doesn't appear to be valid syntax. Array!Item!T
I get the following error:
"multiple ! arguments are not allowed"
Which is ok...I get THAT error, however, this does not work
either:
alias Items(T) = Array!Item(T);
This gives me the error:
Error: function declaration without return type. (Note that
constructors are always named `this`)
Item is defined as follows:
interface Item(T)
{
@property
T member();
}
That part compiles fine. However, even when I remove the
aliasing, I can't import this interface. I get "Error: undefined
identifier 'Item'"
I'm not quite sure I understand how to create a generic container
interface or class in D. Half of how I expect it to work works,
but the other half doesn't. The docs aren't too helpful. I'm not
sure if it's a case where there's just too much to go through or
if what I'm trying to do isn't really covered. Essentially I'm
trying to create an array of this type 'Item' that has some
generic members. I think people who come from C# will kind of get
what I'm trying to do here, because I'm trying to port C# code.
Re: What does the following program do?
On Tuesday, 5 December 2017 at 14:11:02 UTC, Shachar Shemesh
wrote:
import std.algorithm: move;
import std.stdio;
import std.string;
class A {
int val;
override string toString() const {
return "A(%s)".format(val);
}
}
struct B {
int val;
}
void main() {
B b = B(12);
B* bp = &b;
B* bp2;
writefln("bp=%s bp2=%s", bp, bp2);
move( bp, bp2 );
writefln("bp=%s bp2=%s", bp, bp2);
A a1 = new A();
a1.val = 42;
A a2;
writefln("a1=%s (%s) a2=%s (%s)", a1, cast(void*)a1, a2,
cast(void*)a2);
move( a1, a2 );
writefln("a1=%s (%s) a2=%s (%s)", a1, cast(void*)a1, a2,
cast(void*)a2);
B b2;
writefln("b=%s b2=%s", b, b2);
move( b, b2 );
writefln("b=%s b2=%s", b, b2);
}
Answer:
bp=7FFFAB559970 bp2=null
bp=7FFFAB559970 bp2=7FFFAB559970
a1=A(42) (7FD1B79E9000) a2=null (null)
a1=A(42) (7FD1B79E9000) a2=A(42) (7FD1B79E9000)
b=B(12) b2=B(0)
b=B(12) b2=B(12)
"move" was supposed to initialize "source" to init. This does
not appear to be the case. Is that a bug? Where?
```
b=B(12) b2=B(0)
b=B(12) b2=B(12)
```
bit will change if you declare destructor in your struct. As per
the documentation:
If T is a struct with a destructor or postblit defined, source
is reset to its .init value after it is moved into target,
otherwise it is left unchanged.
as for others I understand you have the same problem here - per
documentation, these are not structs with destructors, so moving
the pointers (references) doesn't clear the source one.
What does the following program do?
import std.algorithm: move;
import std.stdio;
import std.string;
class A {
int val;
override string toString() const {
return "A(%s)".format(val);
}
}
struct B {
int val;
}
void main() {
B b = B(12);
B* bp = &b;
B* bp2;
writefln("bp=%s bp2=%s", bp, bp2);
move( bp, bp2 );
writefln("bp=%s bp2=%s", bp, bp2);
A a1 = new A();
a1.val = 42;
A a2;
writefln("a1=%s (%s) a2=%s (%s)", a1, cast(void*)a1, a2,
cast(void*)a2);
move( a1, a2 );
writefln("a1=%s (%s) a2=%s (%s)", a1, cast(void*)a1, a2,
cast(void*)a2);
B b2;
writefln("b=%s b2=%s", b, b2);
move( b, b2 );
writefln("b=%s b2=%s", b, b2);
}
Answer:
bp=7FFFAB559970 bp2=null
bp=7FFFAB559970 bp2=7FFFAB559970
a1=A(42) (7FD1B79E9000) a2=null (null)
a1=A(42) (7FD1B79E9000) a2=A(42) (7FD1B79E9000)
b=B(12) b2=B(0)
b=B(12) b2=B(12)
"move" was supposed to initialize "source" to init. This does not appear
to be the case. Is that a bug? Where?
Re: Advanced code coverage analysis
On Monday, 4 December 2017 at 20:33:56 UTC, thinwybk wrote: Hi everyone, as far as I know there is a statement coverage analyzer built into DMD https://dlang.org/code_coverage.html . Are there code coverage analyzers for D which support branch coverage and other more advanced coverage metrics https://en.wikipedia.org/wiki/Code_coverage ? LDC's PGO output can be used for that. See [1]. Except that LDC does not yet output full source mappings for the counters (`-fcoverage-mapping`). Because the DMD frontend rewrites code besides semantic analysis, it is problematic to create correct source mappings, and I have thusfar refrained from implementing that. (For folks interested in contributing to LDC: it'd be a nice project to work on, with nice incremental steps. It's quite possible that there is already enough info in the IR for IR-based (instead of current PGO instrumentation) instrumentation/mapping to work well) -Johan [1] https://clang.llvm.org/docs/SourceBasedCodeCoverage.html
Re: Advanced code coverage analysis
On Monday, 4 December 2017 at 20:33:56 UTC, thinwybk wrote: Hi everyone, as far as I know there is a statement coverage analyzer built into DMD https://dlang.org/code_coverage.html . Are there code coverage analyzers for D which support branch coverage and other more advanced coverage metrics https://en.wikipedia.org/wiki/Code_coverage ? Cheers, thinwybk No, the compiler reports only statement coverage. Higher levels reports could be made by a tool that would use the LST file and the AST produced by libdparse.
