Re: __FILE__ and __LINE__ in case of import expression
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 the compiler could detect when you are using a string literal vs. a generated or imported string, and change the behavior accordingly. -Steve
Re: __FILE__ and __LINE__ in case of import expression
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 http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L6018 http://dpldocs.info/experimental-docs/source/arsd.cgi.d.html#L6058 I actually do kinda a lot. It is kinda useful for adding declarations with mixed in names (the whole declaration must be mixed in even if the only unique part is the name), or the first instance there is to version out features where the compiler's parser worked (I maintain compatibility with 2+ year old compilers too and if the parser changes, version alone will not work). 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.
Re: __FILE__ and __LINE__ in case of import expression
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 line back up to the original file's line number
perfectly.
Who does that though? Why not just write "some code here" right in the
file? (I know that the string interpolation DIP might make this more likely)
And honestly, if it says the source is "mixin-50, line 1", I think
people will get it.
Whereas, if the code is like:
mixin(generateTheMixin());
and it says the line is 67, and line 67 has nothing to do with the mixin
source or the location it's mixed in, but instead, you need to subtract
the line number of mixing in from 67 to get the *real* line number, I
think the utility is really gone at that point.
-Steve
Re: __FILE__ and __LINE__ in case of import expression
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
number perfectly.
Re: __FILE__ and __LINE__ in case of import expression
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 thing is just a big string literal at the location of the import statement. So it adds the number of \n's in the string literal to the original line number to get the mixin line number. Look at the OP. It says line 22. Neither test.d nor the imported foo.d has 22 lines. While not necessarily a "bug", it's not very useful. The compiler should output a useful line number. I shouldn't have to do math to figure out what it "really" means. I'd argue that should be the line number based on the mixin source. The file name already is based on the line the string was mixed in, so both items contain useful data. To be fair to the compiler, when you are mixing in an import, the mixin doesn't know that the string came from an imported file, so it can't really determine the file automatically. But the line number should be reasonable. -Steve
Re: __FILE__ and __LINE__ in case of import expression
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 location of the import statement. So it adds the number of \n's in the string literal to the original line number to get the mixin line number.
Re: __FILE__ and __LINE__ in case of import expression
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 test.main(string[] args)',
file full path: 'C:\Users\andrey\foo.d-mixin-1'
I can actually fix this issue as well.
Changes in test.d:
test(); // line #16 (1)
mixin("#line 1 \"foo.d\"\n" ~ import("foo.d")); // line #17 (2)
test(); // line #18 (3)
Output:
file: 'test.d', line: '16', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[] args)',
file full path: 'C:\Users\andrey\test.d'
file: 'foo.d', line: '6', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[] args)',
file full path: 'C:\Users\andrey\foo.d'
file: 'test.d', line: '18', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[] args)',
file full path: 'C:\Users\andrey\test.d'
Was just in the process of responding with this technique!
I think what you probably did first is:
int main(string[] args)
{
test();
#line 1 "foo.d"
mixin(import("foo.d"));
return 0;
}
Which sets the line and file of test.d at that point. But when the mixin
happens, I believe the parser/lexer sets the filename, but does not set
the line number to something different.
The hybrid line number (original source line number + mixin line number)
seems like a bug to me.
-Steve
Re: __FILE__ and __LINE__ in case of import expression
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: 'C:\Users\andrey\foo.d-mixin-1'
I can actually fix this issue as well.
Changes in test.d:
test(); // line #16
(1)
mixin("#line 1 \"foo.d\"\n" ~ import("foo.d")); // line #17
(2)
test(); // line #18
(3)
Output:
file: 'test.d', line: '16', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[]
args)',
file full path: 'C:\Users\andrey\test.d'
file: 'foo.d', line: '6', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[]
args)',
file full path: 'C:\Users\andrey\foo.d'
file: 'test.d', line: '18', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[]
args)',
file full path: 'C:\Users\andrey\test.d'
Re: __FILE__ and __LINE__ in case of import expression
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 is neither 'test.d' not 'foo.d' and line number is 22 although both test.d and foo.d are shorter. You can override the filename and line number to the lexer: https://dlang.org/spec/lex.html#special-token-sequence vibe.d does this so when errors from the trans-piled diet files happen, they match (mostly) back to the diet file, not the source file where they are mixed in. I understand that I can create a workaround but want to check first whether this is desired behavior or a bug that should be fixed? That's a good question. I would say it should say line 17 or line 6 (preferably the latter). That may be considered a bug, I don't know. 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: 'C:\Users\andrey\foo.d-mixin-1'
Re: __FILE__ and __LINE__ in case of import expression
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 big string literal there. It
isn't a separate file at that point, the import expression just
pastes in the file contents as a string, and then mixin makes a
chunk of code from it.
These two features are not really meant to be used together, at
least not without some custom translation code in the middle.
Currently this is for illustration only but why can't I do this?
This can be an alternative to `rdmd --eval` that takes code from
a file, not as CLI parameter.
Re: vibe.d and my first web service
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 new vibe.d (0.9.0) was released... Testing with it memory problem has disappeared!!! +1 to vibe.d :-) I'm glad you came around.
Re: __FILE__ and __LINE__ in case of import expression
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 and foo.d are shorter. You can override the filename and line number to the lexer: https://dlang.org/spec/lex.html#special-token-sequence vibe.d does this so when errors from the trans-piled diet files happen, they match (mostly) back to the diet file, not the source file where they are mixed in. I understand that I can create a workaround but want to check first whether this is desired behavior or a bug that should be fixed? That's a good question. I would say it should say line 17 or line 6 (preferably the latter). That may be considered a bug, I don't know. -Steve
Re: __FILE__ and __LINE__ in case of import expression
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 point, the import expression just pastes
in the file contents as a string, and then mixin makes a chunk of
code from it.
These two features are not really meant to be used together, at
least not without some custom translation code in the middle.
__FILE__ and __LINE__ in case of import expression
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 = __FUNCTION__,
string pretty = __PRETTY_FUNCTION__,
string fileFullPath = __FILE_FULL_PATH__)
{
writefln("file: '%s', line: '%s', module: '%s',\nfunction:
'%s', " ~
"pretty function: '%s',\nfile full path: '%s'",
file, line, mod, func, pretty, fileFullPath);
}
int main(string[] args)
{
test(); // line #16(1)
mixin(import("foo.d")); // line #17(2)
return 0;
}
/
foo.d:
// empty line 1
// empty line 2
// empty line 3
// empty line 4
// empty line 5
test(); // line 6
/
Execution result is:
dmd -J. -run test.d
file: 'test.d', line: '16', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[]
args)',
file full path: 'C:\Users\andrey\test.d'
file: 'test.d-mixin-17', line: '22', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[]
args)',
file full path: 'C:\Users\andrey\test.d-mixin-17'
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 and foo.d are shorter.
I understand that I can create a workaround but want to check
first whether this is desired behavior or a bug that should be
fixed?
Re: vibe.d and my first web service
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 problem has disappeared!!! +1 to vibe.d :-)
Re: vibe.d and my first web service
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, Debugging?, an standard library battle, not a good database connection library, missing web framework) and Walter adding more and more compiler functionalities (all of them nice ones) I decided to forget DLang for a time (C# covered my needs really well). Last month I decided it was time to start a new project (my own company) and I reviewed some languages/frameworks for web development (REST services, image processing, PDF generation, ...): Java based ones (I'm experienced with scala/playframework and spring/java, and Kotlin is really nice), c# and Net core, Node/Typescript (Last 6 years I have been mainly a node backend developer) and, finally, native ones (GO, Rust and D... I developed some windows apps in 90's using Symantec C++ but 20 years are a really long time). I really wanted to give D an opportunity: lets go with vibe.d I tested vibe.d on my ubuntu 20.04 and SURPRISE: the hello world project began to eat all my machine memory (just requesting with Firefox and CTRL+F5 pressed continuosly). Using an HAPROXY between calls and backend memory problems disappeared. Process doesn't stop properly after CTRL+C... but I decided not to be so demanding. I discovered hunt-framework (with a fantastic ORM implementation) and my eyes shinned. I tried an example project. Like vibe.d, I began to perform requests with Firefox and CTRL+F5 pressed and application stopped immediately (yesterday I discovered it is a SIGPIPE unmanaged signal that stops the process). I'm quite sure if I use HAPROXY to intermediate between requests and backend, the problem will disappear, but I don't want to perform this test, because I decided not to use hunt-framework neither. Finally I'm using Rust (with Rocket and Diesel): it's my money folks :). Sorry for this not constructive post. DLang needs to bright in some market niche to attract developers and to solve the actual most demanded needs: a lot of developers, like me, expect a good/robust framework for backend development (web/rest/microservices/data processing) and a de-facto standard library for Database integration. In my opinion, "hunt-framework" (or similar) should be one of the central projects of DLang next years (like vibe.d in the past) with a really impressive documentation (English, please!!!) demonstrating how robust, performant and expressive D lang is. Actually your feedback is very constructive, thanks a lot. The ctrl+c issue can be solved with a work around, by adding the version "VibeHighEventPriority". I have only a very small vibed backend application (websockset) and never noticed the memory issue. Also another forum user which has a quite large web application in productive use didn't mentioned this issue. Could I ask you to open a github issue for vibe-d describing your findings regarding the memory issue? As far as I remember the GC does not immediately runs, but only at a certain limit. Maybe your memory issue isn't really an issue but the desired behavior. (Not an expert here, just what I remember). Kind regards Andre Thanks a lot Andre, I opened immediately the issues to receive some feedback: In vibe.d https://github.com/vibe-d/vibe.d/issues/2459 In hunt-framework https://github.com/huntlabs/hunt-framework/issues/161 With vibe.d case, memory is never recalled. Problems disappear in vibe.d when I introduce an intermediate HAPROXY... this gave me an idea about the origin of the problem: Local pipe closed by destination (that haproxy manages nicely) Linux man page about write and EPIPE: https://linux.die.net/man/2/write EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.) I have to recognize I learned this last days (I am not a native linux developer, but I began to recall my past knowledge about it :-) The main reason I have dropped the 2 frameworks for my new project: * Entry "ready for use" projects simple examples must work (I can't be confident that projects based on them will be stable on production if basic projects fail in development)
Re: SIGUSR1 in clock_nanosleep()? how to isolate this issue?
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.
