Re: full path to source file __FILE__
On Friday, 22 July 2016 at 14:02:03 UTC, Jonathan Marler wrote:
The __FILE__ trait seems to be used most useful for error
messages.
Another usage is for testing parsers or string functions directly
on the source. E.g in "devel" mode the main function
void main(string[] args)
{
version(devel)
{
// dont mess with params, use the text in source to catch
most simple bugs.
File f = File(__FILE__, "r");
}
else
{
// load using args
}
}
I could see him wanting it to be a relative path sometimes and
an absolute one other times. By redefining it to always be
absolute would solve this problem,
I'm for this, always absolute. Eventually forced by a new switch:
default behavior is not changed.
Re: full path to source file __FILE__
On Friday, 22 July 2016 at 08:36:37 UTC, Jonathan Marler wrote: On Friday, 22 July 2016 at 07:57:35 UTC, sdhdfhed wrote: On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote: On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote: What's wrong with __FILE__.dirName ? It's kinda weird, sometimes I've noticed that the __FILE__ keyword is an absolute path, and sometimes it isn't. If it was always an absolute path, that would work. I decided to take a stab at implementing this in the dmd compiler: https://github.com/dlang/dmd/pull/5959 It adds a __FILE_FULL_PATH__ trait which would solve the issue. Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ? I mean that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword ! It's definitely confirmed. And now that I've walked through the source code, I see that it wasn't implemented to be an absolute path, it just happens to be some of the time depending on how the file is found. I'm sure Walter will have an opinion as to what solution he prefers. Either redefining the __FILE__ trait or adding a new one. He's communicating fixes to the PR on github so that a good sign. We'll see. Yes, i've seen he 's started to review. I don't know if you've seen my other suggestion but another solution would be to force relative fnames passed to the compiler to be translated to absolute. This is also why I've never seen a relative __FILE__. The build tool I use always does the expansion in intern before calling the compiler.
Re: full path to source file __FILE__
On Friday, 22 July 2016 at 07:57:35 UTC, sdhdfhed wrote: On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote: [...] Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ? I mean that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword ! make a PR that expands the sources passed to the dmd to their absolute name. This is more likely to fix your issue and to be accepted.
Re: full path to source file __FILE__
On Friday, 22 July 2016 at 07:47:14 UTC, Jonathan Marler wrote: On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf wrote: What's wrong with __FILE__.dirName ? It's kinda weird, sometimes I've noticed that the __FILE__ keyword is an absolute path, and sometimes it isn't. If it was always an absolute path, that would work. I decided to take a stab at implementing this in the dmd compiler: https://github.com/dlang/dmd/pull/5959 It adds a __FILE_FULL_PATH__ trait which would solve the issue. Personally I've never seen a relative __FILE__. Is this an issue that's confirmed ? I mean that it would be better to fix __FILE__ so that its result is always absolute then. I think that such a "PPR" (punk-pull-request) has 0% chance of being accepted, especially since it adds a special keyword !
