On Friday, 21 August 2020 at 09:50:38 UTC, ddcovery wrote:
On Friday, 21 August 2020 at 08:48:34 UTC, ddcovery wrote:
On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
[...]
Thanks a lot Andre,
I opened immediately the issues to receive some feedback:
[...]
EDIT: 23 days ago
On Friday, 21 August 2020 at 14:01:24 UTC, Andrey Zherikov wrote:
mixin(import("foo.d")); // line #17(2)
Why are you doing this? This kind of thing is almost never an
ideal solution in D.
See, the compiler just sees a big string literal there. It isn't
a separate file at that
On 8/21/20 10:01 AM, Andrey Zherikov wrote:
How can I get __FILE__ and __LINE__ values correct in case of import
expression?
...
So the output from line #16 (1) is correct although from line #17 (2) is
not: file name is neither 'test.d' not 'foo.d' and line number is 22
although both test.d
On Friday, 21 August 2020 at 08:48:34 UTC, ddcovery wrote:
On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
[...]
Thanks a lot Andre,
I opened immediately the issues to receive some feedback:
[...]
EDIT: 23 days ago new vibe.d (0.9.0) was released... Testing with
it memory
How can I get __FILE__ and __LINE__ values correct in case of
import expression?
Below is my test code.
/
test.d:
module test;
import std.stdio;
void test(string file = __FILE__, size_t line = __LINE__,
string mod = __MODULE__, string func =
On Friday, 21 August 2020 at 21:06:11 UTC, Steven Schveighoffer
wrote:
The hybrid line number (original source line number + mixin
line number) seems like a bug to me.
I'm not so sure without seeing all the code. Remember to the
compiler, the mixin thing is just a big string literal at the
On Friday, 21 August 2020 at 21:42:21 UTC, Steven Schveighoffer
wrote:
While not necessarily a "bug", it's not very useful.
Maybe not in this case, but it is perfectly accurate for cases
like:
mixin(q{
some code here
});
Where it will actually line back up to the original file's line
On 8/21/20 5:56 PM, Adam D. Ruppe wrote:
On Friday, 21 August 2020 at 21:42:21 UTC, Steven Schveighoffer wrote:
While not necessarily a "bug", it's not very useful.
Maybe not in this case, but it is perfectly accurate for cases like:
mixin(q{
some code here
});
Where it will actually
On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer
wrote:
Who does that though?
An incompetent coder:
http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L5713
http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L5943
On Friday, 21 August 2020 at 20:44:27 UTC, Andrey Zherikov wrote:
Thanks for this link! I can use "#line" to fix line number but
not file name:
file: 'foo.d-mixin-1', line: '6', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[]
args)',
file full path:
On Friday, 21 August 2020 at 15:34:49 UTC, Steven Schveighoffer
wrote:
On 8/21/20 10:01 AM, Andrey Zherikov wrote:
How can I get __FILE__ and __LINE__ values correct in case of
import expression?
...
So the output from line #16 (1) is correct although from line
#17 (2) is not: file name
On Friday, 21 August 2020 at 15:27:14 UTC, Adam D. Ruppe wrote:
On Friday, 21 August 2020 at 14:01:24 UTC, Andrey Zherikov
wrote:
mixin(import("foo.d")); // line #17(2)
Why are you doing this? This kind of thing is almost never an
ideal solution in D.
See, the compiler just sees a
On 8/21/20 5:08 PM, Adam D. Ruppe wrote:
On Friday, 21 August 2020 at 21:06:11 UTC, Steven Schveighoffer wrote:
The hybrid line number (original source line number + mixin line
number) seems like a bug to me.
I'm not so sure without seeing all the code. Remember to the compiler,
the mixin
On 8/21/20 4:54 PM, Andrey Zherikov wrote:
On Friday, 21 August 2020 at 20:44:27 UTC, Andrey Zherikov wrote:
Thanks for this link! I can use "#line" to fix line number but not
file name:
file: 'foo.d-mixin-1', line: '6', module: 'test',
function: 'test.main', pretty function: 'int
On 8/21/20 6:34 PM, Adam D. Ruppe wrote:
On Friday, 21 August 2020 at 22:12:48 UTC, Steven Schveighoffer wrote:
And honestly, if it says the source is "mixin-50, line 1", I think
people will get it.
I could probably live with that too, but the status quo is pretty useful
as-is.
I wonder if
On Thursday, 20 August 2020 at 21:36:04 UTC, Andre Pany wrote:
On Thursday, 20 August 2020 at 18:13:46 UTC, ddcovery wrote:
On Monday, 17 August 2020 at 15:45:05 UTC, aberba wrote:
[...]
After 18 years following DLang, and some disagrees about
productivity lacks at the beggining (no IDE,
On Thursday, 20 August 2020 at 18:58:43 UTC, mw wrote:
Hi,
I run into an issue: it's SIGUSR1 in clock_nanosleep()
[...]
Anyone has some suggestions on how to isolate this issue?
Thanks.
Try "handle SIGUSR1 nostop noprint" and "handle SIGUSR2 nostop
noprint" in gdb.
17 matches
Mail list logo
