Re: using __traits to get line number of a member
On 11/12/21 11:00 PM, forkit wrote:
> // nope. writes the line no. of the foreach loop
mixin(m) seems to solve the issue, which I think necessitates 'static if':
static foreach(m; __traits(allMembers, mixin(__MODULE__)))
{
static if(m == "std" || m == "object" || m == "main")
{
// Ignore
} else {
writefln("The name of the first user member is: %s", m);
writeln(__traits(getLocation, mixin(m))[1]); // <-- HERE
}
}
It works because we mix-in the value of the string 'm', which becomes a
symbol.
('foreach' instead of 'static foreach' works as well.)
Ali
Re: using __traits to get line number of a member
On Saturday, 13 November 2021 at 06:05:37 UTC, Stanislav Blinov wrote: On Saturday, 13 November 2021 at 05:31:51 UTC, forkit wrote: Code below is self explanatory. Any assistance on how to get the line number is welcome ;-) https://dlang.org/spec/traits.html#getLocation That? Thanks. That seems to be the one, except: writeln(__traits(getLocation, m)[1]); // nope. writes the line no. of the foreach loop writeln(__traits(getLocation, myClass)[1]); // yes, but I have to provide the name manually here, which i would not know. I would have thought m referred to myClass at this point in the loop. But that doesn't seem to be the case.
Re: using __traits to get line number of a member
On Saturday, 13 November 2021 at 05:31:51 UTC, forkit wrote: Code below is self explanatory. Any assistance on how to get the line number is welcome ;-) https://dlang.org/spec/traits.html#getLocation That?
using __traits to get line number of a member
Code below is self explanatory.
Any assistance on how to get the line number is welcome ;-)
// ++
module test;
import std;
class myClass{ void foo(){}}
void myFunction1(){}
void main()
{
// list the first user defined member of this module (other
than main)
int i;
foreach(m; __traits(allMembers, mixin(__MODULE__)))
{
// we can ignore these members
// "std" and "object" are created by the compiler, and
"main" I'm not interested in.
if(m == "std" || m == "object" || m == "main")
{
i = 1;
continue;
}
writefln("The name of the first user member is: %s", m);
// On this next line, m.lineNumber is just a stub holder
till an actual solution is found
//writefln("The line number on which that member begins,
is: %s, m.lineNumber);
if(i == 1)
break;
}
//writeln("Nothing to see here.");
}
void myFunction2(){}
// +
Re: How to use dmd code coverage
On Friday, 12 November 2021 at 22:27:48 UTC, forkit wrote: On Friday, 12 November 2021 at 19:32:31 UTC, Dr Machine Code wrote: On Thursday, 11 November 2021 at 23:51:42 UTC, foxit wrote: [...] is your IDE more of a REPL thing? It's a custom IDE for me, that I wrote using Winforms/C# (developed in VS2010), that lets me quickly and easily write|compile|execute code in many languages without having to worry about first creating/saving files, or working at the command prompt. I call it EZ Compiler ;-) Here is a screen dump pic of it(not sure how long the link lasts though) https://imgur.com/a/PvBm2q4 MD 
Re: Cannot compile C file using ImportC
On Friday, 12 November 2021 at 08:12:22 UTC, Ola Fosheim Grøstad wrote: Maybe there are some metaprogramming advantages, but I cannot think of any. Well, one advantage might be that it could be easier to do escape analysis of C code. Not really sure if there is a difference compared to doing it over the IR, though.
Re: How to use dmd code coverage
On Friday, 12 November 2021 at 19:32:31 UTC, Dr Machine Code wrote: On Thursday, 11 November 2021 at 23:51:42 UTC, foxit wrote: On Thursday, 11 November 2021 at 22:35:21 UTC, forkit wrote: [...] Actually, the reason I got soo confused is clear to me now. I have my own GUI IDE, which I wrote myself (winforms/C#) cause I got so fed up with creating/saving files everytime I just wanted to play with some code. [...] is your IDE more of a REPL thing? It's a custom IDE for me, that I wrote using Winforms/C# (developed in VS2010), that lets me quickly and easily write|compile|execute code in many languages without having to worry about first creating/saving files, or working at the command prompt. I call it EZ Compiler ;-) Here is a screen dump pic of it(not sure how long the link lasts though) https://imgur.com/a/PvBm2q4
Re: Dub says that there is an invalid semVer format, but I don't see how.
On Thursday, 11 November 2021 at 01:57:10 UTC, rikki cattermole wrote: On 11/11/2021 2:13 PM, Ruby The Roobster wrote: Branch ~master: Invalid SemVer format: testing.0.0 Branch ~testing: Invalid SemVer format: testing.0.0 Version 0.1.2: Invalid SemVer format: testing.0.0 testing is a branch. You are using ~>testing for it. To use a branch in the SEMVER is ~branch. https://dub.pm/package-format-json.html#version-specs This was not causing me issues before. It worked until I added the v0.1.2 tag.
Linker issues with DMD and LDC
I get this error when trying to compile a program using [dhtslib](https://github.com/blachlylab/dhtslib) with DMD or any LDC version < 1.25.0. ``` _D39TypeInfo_S7dhtslib3sam6record9SAMRecord6__initZ: error: undefined reference to `_D7dhtslib3sam6record9SAMRecord15__fieldPostblitMFNbNiNlNeZv' ``` Though I only experience this when trying to create an array of `SAMRecord`s. One solution I have found is using `std.array.Appender` instead of arrays. Another solution I have found is to define an explicit postblit for `SAMRecord`, though the implicitly generated postblit should work. Looking through ldc changelogs, the closest thing I could attribute this to is this change for ldc-1.25.0: - Struct TypeInfos are emitted into referencing object files only, and special TypeInfo member functions into the owning object file only. (#3491) I posted this question [previously](https://forum.dlang.org/post/flpztfooingrpkxan...@forum.dlang.org), though I explained the problem poorly. I don't understand why my fixes work or what is causing the issue in the first place. Is there something I should be doing differently? Is this a compiler or language bug?
Re: How to use dmd code coverage
On Thursday, 11 November 2021 at 23:51:42 UTC, foxit wrote: On Thursday, 11 November 2021 at 22:35:21 UTC, forkit wrote: [...] Actually, the reason I got soo confused is clear to me now. I have my own GUI IDE, which I wrote myself (winforms/C#) cause I got so fed up with creating/saving files everytime I just wanted to play with some code. [...] is your IDE more of a REPL thing?
Re: Is DMD still not inlining "inline asm"?
On Friday, 12 November 2021 at 15:10:19 UTC, max haughton wrote: Not always. The attribute is intended for naked asm since inlining could be completely wrong in this case. Got that! Thanks for the info!
Re: Is DMD still not inlining "inline asm"?
On Friday, 12 November 2021 at 11:32:16 UTC, rempas wrote: On Thursday, 11 November 2021 at 19:22:33 UTC, max haughton wrote: There's an attribute to tell it the function is safe to inline. And can't you do that with inline asm? Not always. The attribute is intended for naked asm since inlining could be completely wrong in this case.
Re: Is DMD still not inlining "inline asm"?
On Friday, 12 November 2021 at 00:46:05 UTC, Elronnd wrote: GCC can do it. Somewhat notoriously, LTO can lead to bugs from underspecified asm constraints following cross-TU inlining. That's really interesting to hear! Do we have any cases where this happened to software that was used for production?
Re: Is DMD still not inlining "inline asm"?
On Thursday, 11 November 2021 at 19:22:33 UTC, max haughton wrote: There's an attribute to tell it the function is safe to inline. And can't you do that with inline asm?
Re: Cannot compile C file using ImportC
On Thursday, 11 November 2021 at 02:03:22 UTC, Steven Schveighoffer wrote: I don't think ImportC is that much of a game changer (you can already make C bindings with quite a small effort, and there are tools to get you 90% there), but a broken/not working ImportC will be a huge drawback to the language, so it's important to get it right. The advantage I though of when I suggested something similar many years ago was that it would enable inlining of C functions, but since then LLVM has gotten whole program optimization over the IR, so now the advantage is more limited. Maybe there are some metaprogramming advantages, but I cannot think of any.
