digitalmars.D - New __FILE_DIR__ trait?
- Jonathan Marler (19/19) Jul 21 2016 I've got some batch scripts I wanted to convert to D. I'd like
- rikki cattermole (4/21) Jul 21 2016 Temporary work around:
- Jonathan Marler (5/13) Jul 22 2016 Interesting solution. It definitely has a "hacky" feel but I
- Jonathan Marler (7/27) Jul 27 2016 For others who may see this thread, the __FULL_FILE_PATH__
- lkfsdg (5/13) Jul 27 2016 Plz don't forget to propose a PR for the specifications too. The
- Jonathan Marler (3/19) Jul 27 2016 Yes thank you for the reminder. It's good to know that people
- crimaniak (3/6) Jul 27 2016 __DIR__ will be useful, I think. Just directory name, without
- Jonathan Marler (13/20) Jul 27 2016 Sure if others thought it was a good idea. I wouldn't really
- Sebastien Alaiwan (29/33) Jul 28 2016 Doesn't work, I don't think you can wrap such things ( __FILE__
- Sebastien Alaiwan (6/6) Jul 28 2016 By the way, I really think __FILE_FULL_PATH__ should be a rdmd
- Jonathan Marler (3/38) Jul 29 2016 Huh, interesting case, didn't think of that one.
I've got some batch scripts I wanted to convert to D. I'd like users to run them using rdmd, so it's obvious where the source code lives and easy to modify. The problem is that the batch scripts I want to convert rely on the %~dp0 variable, which contains the path to the batch script itself. Note that this variable is different then the current directory. I haven't been able to find a nice way to do this in D. (Note that thisExePath won't work because rdmd compiles the code to a temporary directory, which makes sense.) Having known about the special __FILE__ and __LINE__ traits, I figured there might be a trait for the file directory as well, but it appears there is none. I'd like to see what people think about adding a new trait for this. Maybe something like __FILE_DIR__? This would contain the directory of the source-code file it appears in. Also if this trait was added, one could argue that a trait containing the path and the filename should also be added, maybe something like __FILE_FULL_PATH__? P.S. If you know of an existing solution to this problem please let me know.
Jul 21 2016
On 22/07/2016 2:08 PM, Jonathan Marler wrote:I've got some batch scripts I wanted to convert to D. I'd like users to run them using rdmd, so it's obvious where the source code lives and easy to modify. The problem is that the batch scripts I want to convert rely on the %~dp0 variable, which contains the path to the batch script itself. Note that this variable is different then the current directory. I haven't been able to find a nice way to do this in D. (Note that thisExePath won't work because rdmd compiles the code to a temporary directory, which makes sense.) Having known about the special __FILE__ and __LINE__ traits, I figured there might be a trait for the file directory as well, but it appears there is none. I'd like to see what people think about adding a new trait for this. Maybe something like __FILE_DIR__? This would contain the directory of the source-code file it appears in. Also if this trait was added, one could argue that a trait containing the path and the filename should also be added, maybe something like __FILE_FULL_PATH__? P.S. If you know of an existing solution to this problem please let me know.Temporary work around: Write a program that on calls to rdmd but before that it appends an enum called that, on after it removes it by shrinking the file.
Jul 21 2016
Jonathan Marler <johnnymarler gmail.com> On Friday, 22 July 2016 at 04:10:38 UTC, rikki cattermole wrote:On 22/07/2016 2:08 PM, Jonathan Marler wrote:Interesting solution. It definitely has a "hacky" feel but I suppose it would work. I decided to take a stab at implementing the feature and have a Pull Request here. https://github.com/dlang/dmd/pull/5959P.S. If you know of an existing solution to this problem please let me know.Temporary work around: Write a program that on calls to rdmd but before that it appends an enum called that, on after it removes it by shrinking the file.
Jul 22 2016
On Friday, 22 July 2016 at 02:08:44 UTC, Jonathan Marler wrote:I've got some batch scripts I wanted to convert to D. I'd like users to run them using rdmd, so it's obvious where the source code lives and easy to modify. The problem is that the batch scripts I want to convert rely on the %~dp0 variable, which contains the path to the batch script itself. Note that this variable is different then the current directory. I haven't been able to find a nice way to do this in D. (Note that thisExePath won't work because rdmd compiles the code to a temporary directory, which makes sense.) Having known about the special __FILE__ and __LINE__ traits, I figured there might be a trait for the file directory as well, but it appears there is none. I'd like to see what people think about adding a new trait for this. Maybe something like __FILE_DIR__? This would contain the directory of the source-code file it appears in. Also if this trait was added, one could argue that a trait containing the path and the filename should also be added, maybe something like __FILE_FULL_PATH__? P.S. If you know of an existing solution to this problem please let me know.For others who may see this thread, the __FULL_FILE_PATH__ special trait was added to the dmd compiler with this PR: https://github.com/dlang/dmd/pull/5959 At the time of this post, the latest released version of D is 2.071.1, so this trait should be available on any release after that.
Jul 27 2016
On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:On Friday, 22 July 2016 at 02:08:44 UTC, Jonathan Marler wrote:Plz don't forget to propose a PR for the specifications too. The serious way of doing things include this step. https://dlang.org/spec/lex.html https://github.com/dlang/dmd/blob/master/changelog.dd[...]For others who may see this thread, the __FULL_FILE_PATH__ special trait was added to the dmd compiler with this PR: https://github.com/dlang/dmd/pull/5959 At the time of this post, the latest released version of D is 2.071.1, so this trait should be available on any release after that.
Jul 27 2016
On Wednesday, 27 July 2016 at 14:07:23 UTC, lkfsdg wrote:On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:Yes thank you for the reminder. It's good to know that people understand the value of documentation.On Friday, 22 July 2016 at 02:08:44 UTC, Jonathan Marler wrote:Plz don't forget to propose a PR for the specifications too. The serious way of doing things include this step. https://dlang.org/spec/lex.html https://github.com/dlang/dmd/blob/master/changelog.dd[...]For others who may see this thread, the __FULL_FILE_PATH__ special trait was added to the dmd compiler with this PR: https://github.com/dlang/dmd/pull/5959 At the time of this post, the latest released version of D is 2.071.1, so this trait should be available on any release after that.
Jul 27 2016
On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:For others who may see this thread, the __FULL_FILE_PATH__ special trait was added to the dmd compiler with this PR: https://github.com/dlang/dmd/pull/5959__DIR__ will be useful, I think. Just directory name, without file name.
Jul 27 2016
On Thursday, 28 July 2016 at 00:42:11 UTC, crimaniak wrote:On Wednesday, 27 July 2016 at 13:59:23 UTC, Jonathan Marler wrote:Sure if others thought it was a good idea. I wouldn't really mind typing __FILE_FULL_PATH__.dirName, but others might find __DIR__ useful. Good thing is that it could be added to the standard library (wouldn't have to change the compiler) now that __FULL_FILE_PATH__ has been added. I'm guessing it would have to be a function like this: auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure { return fileFullPath.dirName; } May or may not be useful enough to be added to druntime or phobos, I'll let someone else decide that :)For others who may see this thread, the __FULL_FILE_PATH__ special trait was added to the dmd compiler with this PR: https://github.com/dlang/dmd/pull/5959__DIR__ will be useful, I think. Just directory name, without file name.
Jul 27 2016
On Thursday, 28 July 2016 at 06:21:06 UTC, Jonathan Marler wrote:
auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure
{
return fileFullPath.dirName;
}
Doesn't work, I don't think you can wrap such things ( __FILE__
and such ):
import std.stdio;
int main()
{
printNormal();
printWrapped();
return 0;
}
void printNormal(int line = __LINE__)
{
writefln("%s", line);
}
void printWrapped(int line = __MY_LINE__)
{
writefln("%s", line);
}
// wrapped version
int __MY_LINE__(int line = __LINE__)
{
return line;
}
$ rdmd demo.d
5
15 (should be 6!)
Thus, the suggested implementation of __DIR__ would behave very
differently from a builtin one. I'm not saying we need a builtin
one, however, it might not be a good idea to name it this way.
Jul 28 2016
By the way, I really think __FILE_FULL_PATH__ should be a rdmd feature, not dmd. rdmd could set an environment variable "RDMD_FULL_PATH" or something like this (replacing argv[0]), instead of potentially making the compilation depend on the working copy location on disk...
Jul 28 2016
On Thursday, 28 July 2016 at 17:21:52 UTC, Sebastien Alaiwan wrote:On Thursday, 28 July 2016 at 06:21:06 UTC, Jonathan Marler wrote:Huh, interesting case, didn't think of that one.auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure { return fileFullPath.dirName; }Doesn't work, I don't think you can wrap such things ( __FILE__ and such ): import std.stdio; int main() { printNormal(); printWrapped(); return 0; } void printNormal(int line = __LINE__) { writefln("%s", line); } void printWrapped(int line = __MY_LINE__) { writefln("%s", line); } // wrapped version int __MY_LINE__(int line = __LINE__) { return line; } $ rdmd demo.d 5 15 (should be 6!) Thus, the suggested implementation of __DIR__ would behave very differently from a builtin one. I'm not saying we need a builtin one, however, it might not be a good idea to name it this way.
Jul 29 2016