On Wednesday, 28 May 2025 at 11:32:53 UTC, Jonathan M Davis wrote:
On Wednesday, May 28, 2025 5:04:06 AM Mountain Daylight Time
realhet via Digitalmars-d-learn wrote:
I've found a way to eliminate !() by using a function:
Just FYI, you almost never want to instantiate a template with
a file a
On Wednesday, 28 May 2025 at 11:32:53 UTC, Jonathan M Davis wrote:
On Wednesday, May 28, 2025 5:04:06 AM Mountain Daylight Time
realhet via Digitalmars-d-learn wrote:
Yes, most of the time I can put __FILE__ and __LINE__ onto a
runtime function parameter.
But this time it is a requirement:
I
On Wednesday, May 28, 2025 5:04:06 AM Mountain Daylight Time realhet via
Digitalmars-d-learn wrote:
> I've found a way to eliminate !() by using a function:
Just FYI, you almost never want to instantiate a template with a file and
line number anyway, because that means that every single template
tring() const => location;
}
auto LOC2(string FILE=__FILE__, size_t LINE=__LINE__)
=> LOCATION_t2(FILE~'('~LINE.text~",1)");
pragma(msg, LOC2);
//LOCATION_t2("onlineapp.d(28,1)")
pragma(msg, LOC2.text);
On Tuesday, 27 May 2025 at 21:16:57 UTC, monkyyy wrote:
On Tuesday, 27 May 2025 at 21:07:51 UTC, realhet wrote:
I stay in safety and choose this way:
```d
enum _LOCATION_(string FILE=__FILE__, size_t LINE=__LINE__) =
FILE~'('~LINE.text~",1)";
enum loc1 = (_LOCA
On Tuesday, 27 May 2025 at 21:07:51 UTC, realhet wrote:
Interesting tricks: alias reassignment and
templateParameterValueSpecialization (wow! It avoids the
redeclaration error I normally get.).
There bugs here, it works in this case(I have theories why) and
in opend its considered a regress
ork at the call site. The simplest extra work is manually
writing __FILE__,__LINE__ btw.
Interesting trick: How to pack a whole AliasSeq into a single
slot. I got to rememper this, it's so cool. template
pack(A...) { alias unpack=A; }
Final thoughts: I think the only conflict is on
On Tuesday, 27 May 2025 at 10:20:40 UTC, realhet wrote:
Hello,
```d
template T1(string FILE=__FILE__, size_t LINE=__LINE__, A...)
{
enum T1 = FILE ~ LINE.text ~ A.text;
}
pragma(msg, T1!(__FILE__,__LINE__, "hello", " world")); //works
pragma(msg, T1!(__FILE__,__LIN
Hello,
```d
template T1(string FILE=__FILE__, size_t LINE=__LINE__, A...)
{
enum T1 = FILE ~ LINE.text ~ A.text;
}
pragma(msg, T1!(__FILE__,__LINE__, "hello", " world")); //works
pragma(msg, T1!(__FILE__,__LINE__,i"Hello $("World")")); //works
pragma
On Tuesday, 25 January 2022 at 12:27:16 UTC, Dennis wrote:
On Tuesday, 25 January 2022 at 12:11:01 UTC, JG wrote:
Any ideas how one can achieve what is written in the subject
line?
```D
void f(T...)(auto ref T args, string file = __FILE__, int line
= __LINE__)
{
writeln(file, ":&q
On Tuesday, 25 January 2022 at 12:27:16 UTC, Dennis wrote:
On Tuesday, 25 January 2022 at 12:11:01 UTC, JG wrote:
Any ideas how one can achieve what is written in the subject
line?
```D
void f(T...)(auto ref T args, string file = __FILE__, int line
= __LINE__)
{
writeln(file, ":&q
On Tuesday, 25 January 2022 at 12:11:01 UTC, JG wrote:
Any ideas how one can achieve what is written in the subject
line?
```D
void f(T...)(auto ref T args, string file = __FILE__, int line =
__LINE__)
{
writeln(file, ":", line, ": ", args);
}
```
Any ideas how one can achieve what is written in the subject line?
f below does achieve this but I one would expect that it produces
significant template bloat.
g achieves the aim but isn't very elegant.
import std;
void f(string file=__FILE__,size_t line=__LINE__,R...
= __LINE__, string path =
__FILE__[0..$], A...)(A a) {
import core.stdc.stdio;
printf("[%s:%d] \n", path.ptr, line);
}
extern(C) int main() {
doTest();
return 0;
}
-
retult: [abc.d:4]
expect: [test.d:4]
It's a known bug:
On 8/4/21 10:27 PM, Ali Çehreli wrote:
I wonder whether this feature is thanks to 'lazy' parameters, which are
actually delegates.
No, the default parameters are used directly as if they were typed in at
the call site (more or less, obviously the `__FILE__` example is weird).
On 8/4/21 7:17 PM, Steven Schveighoffer wrote:
>> The compiler has to evaluate the default argument as constant
>> expression in order to use it as default value..
>
> This is not true, you can use runtime calls as default values.
What??? I just checked and it works! :)
string bar() {
imp
On 7/26/21 1:05 PM, Stefan Koch wrote:
On Monday, 26 July 2021 at 12:01:23 UTC, Adam D Ruppe wrote:
On Monday, 26 July 2021 at 11:43:56 UTC, workman wrote:
__FILE__[0..$]
Why do you have that [0..$] there? It is probably breaking the
__FILE__ magic.
Correct.
The compiler has to evaluate
On Monday, 26 July 2021 at 12:01:23 UTC, Adam D Ruppe wrote:
On Monday, 26 July 2021 at 11:43:56 UTC, workman wrote:
__FILE__[0..$]
Why do you have that [0..$] there? It is probably breaking the
__FILE__ magic.
Correct.
The compiler has to evaluate the default argument as constant
On Monday, 26 July 2021 at 11:43:56 UTC, workman wrote:
__FILE__[0..$]
Why do you have that [0..$] there? It is probably breaking the
__FILE__ magic.
file test.d:
-
module test;
import abc;
void doTest(){
log!"test"();
}
---
file abc.d:
-
module abc;
import test;
void log(string fmt, int line = __LINE__, string path =
__FILE__[0..$],
Thanks for all your answers!
On Thursday, 22 October 2020 at 16:03:45 UTC, H. S. Teoh wrote:
On Thu, Oct 22, 2020 at 03:32:57PM +, Andrey Zherikov via
Digitalmars-d-learn wrote:
There are two ways how __FILE__, __LINE__ etc. can se used in
function parameters: as regular parameters and as template
parameters
On Thu, Oct 22, 2020 at 03:32:57PM +, Andrey Zherikov via
Digitalmars-d-learn wrote:
> There are two ways how __FILE__, __LINE__ etc. can se used in function
> parameters: as regular parameters and as template parameters:
[...]
> What is recommended way?
> What are pros/cons of e
There are two ways how __FILE__, __LINE__ etc. can se used in
function parameters: as regular parameters and as template
parameters:
void rt(string file=__FILE__, int line=__LINE__, string
func=__FUNCTION__)
{
writeln(file,"(",line,"): ",func);
}
void ct(string fil
of this is that mixin() changes __FILE__
to point to the location of this mixin. But import expression doesn't do
so. So if import("file") could change __FILE__ to "file" and __LINE__ to
1 internally that will make sense IMHO.
I mean something like this:
On Sunday, 23 August 2020 at 12:50:36 UTC, Andrey Zherikov wrote:
Even this approach can lead to unclear result if you move
'q{...}' outside of mixin:
Yes, that's why I write it very specifically the way I do, with
q{ and mixin on the same line.
tring file = __FILE__, size_t line = __LINE__)
{
writefln("file: '%s', line: '%s'", file, line);
}
int main(string[] args)
{
enum code = q{
// empty line 15
// empty line 16
// empty line 17
// empty line 18
// empty line 19
d 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.
As far as I understand behavior of this is that mixin() changes
__FILE__ t
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 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/
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 lin
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
nu
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 thi
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
lo
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(st
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\a
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 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
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
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
only a compile-time string.
I'm not a fan of string mixins (ask Adam how they're the scourge
of good programming, a wart on D's behind, and so on :p), but I
found no good way to do this without them:
string ctLog(Args...)(string file = __FILE__, size_t line =
__LINE__) {
On Tuesday, 18 August 2020 at 08:03:04 UTC, Per Nordlöw wrote:
Forgot to mention that I want to support variadic arguments to
`ctLog` similar to what is done with
And these arguments should be of any template argument kind, not
only a compile-time string.
On Monday, 17 August 2020 at 22:37:12 UTC, Simen Kjærås wrote:
mixin template ctLog(string msg, string file = __FILE__, size_t
line = __LINE__) {
pragma(msg, file, "(", line, "): ", msg);
}
Thanks.
Forgot to mention that I want to support variadic arguments to
`ctLog
On Monday, 17 August 2020 at 21:18:41 UTC, Per Nordlöw wrote:
I'm using
pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", "A
useful debug message");
to print compile-time information formatted as standard
compiler diagnostics.
These are picked up
I'm using
pragma(msg, __FILE__, "(", __LINE__, ",1): Debug: ", "A
useful debug message");
to print compile-time information formatted as standard compiler
diagnostics.
These are picked up by Emacs Flycheck and overlayed in the editor
and listen in
On Wednesday, 29 May 2019 at 16:08:11 UTC, Exil wrote:
On Wednesday, 29 May 2019 at 08:45:45 UTC, Andre Pany wrote:
[...]
I imagine __FILE__ is used where the code is defined, since it
is defined in "a.d" that is what is used. If you want to know
the file name of where it is use
On Wednesday, 29 May 2019 at 08:45:45 UTC, Andre Pany wrote:
Hi,
I have a module a.d
---
struct TestClass
{
string name;
string fileName;
}
TestClass[] testClasses;
mixin template UnitTest()
{
private static string getFileName(string fileName =
__FILE__
Hi,
I have a module a.d
---
struct TestClass
{
string name;
string fileName;
}
TestClass[] testClasses;
mixin template UnitTest()
{
private static string getFileName(string fileName = __FILE__)
{
return fileName;
}
private static this
On Tuesday, 29 May 2018 at 21:41:37 UTC, Ali Çehreli wrote:
On 05/29/2018 02:34 PM, DigitalDesigns wrote:
> auto x(string fp = __FULL_FILE_PATH__)()
{
pragma(msg, fp);
}
?
__FILE_FULL_PATH__
https://dlang.org/spec/expression#specialkeywords
Ali
Lol, thanks:
On 5/29/18 5:34 PM, DigitalDesigns wrote:
On Wednesday, 27 July 2016 at 13:58:22 UTC, Jonathan Marler wrote:
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because
On 05/29/2018 02:34 PM, DigitalDesigns wrote:
> auto x(string fp = __FULL_FILE_PATH__)()
{
pragma(msg, fp);
}
?
__FILE_FULL_PATH__
https://dlang.org/spec/expression#specialkeywords
Ali
On Wednesday, 27 July 2016 at 13:58:22 UTC, Jonathan Marler wrote:
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler
wrote:
Is there a way to get the full path of the current source
file? Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant t
On Tuesday, 18 April 2017 at 13:48:57 UTC, Stanislav Blinov wrote:
There's a much more concise workaround, both in code written
and generated ;)
import std.stdio;
template func(string file = __FILE__, int line = __LINE__)
{
auto func(T...)(auto ref T args)
{
writeln(&q
On Monday, 17 April 2017 at 14:23:50 UTC, Jonathan M Davis wrote:
On Monday, April 17, 2017 13:45:18 Dmitry via
Digitalmars-d-learn wrote:
[...]
Every time there's a new template instantiation, it's
essentially copy-pasting the entire template. So, if you have
the templated function
[...]
On Tuesday, 18 April 2017 at 13:48:57 UTC, Stanislav Blinov wrote:
On Tuesday, 18 April 2017 at 13:28:06 UTC, Solomon E wrote:
I tried to produce an example of calling a function with
variadic template arguments using special tokens __FILE__ and
__LINE__.
This compiles and runs, producing
On Tuesday, 18 April 2017 at 13:28:06 UTC, Solomon E wrote:
I tried to produce an example of calling a function with
variadic template arguments using special tokens __FILE__ and
__LINE__.
This compiles and runs, producing the output shown, using the
default gdc
provided by Ubuntu 17.04
name, file, line);
sceneCount += 1;
writeln("added " ~ name);
}
}
}
void add(string file = __FILE__, size_t line = __LINE__, T...)(T
args)
{
add_impl!T(file, line, args);
}
void EError(string file, size_t line, string message, string name)
{
On Monday, April 17, 2017 07:23:50 Jonathan M Davis via Digitalmars-d-learn
wrote:
> So, if you're okay with explicitly instantiating your variadic function
> template instead of having the types inferred, then it can work, but
> otherwise, no. Making it work would require a language enhancement
On Monday, 17 April 2017 at 14:23:50 UTC, Jonathan M Davis wrote:
So, if you're okay with explicitly instantiating your variadic
function template instead of having the types inferred, then it
Yes, it's my case. That's a game engine, so some kilobytes isn't
a problem.
Moreover, possible that fu
On Monday, April 17, 2017 13:45:18 Dmitry via Digitalmars-d-learn wrote:
> On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote:
> > They works, but it results in a new template being instantiated
> > for every call, so you really shouldn't use __FILE__ or
>
On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote:
They works, but it results in a new template being instantiated
for every call, so you really shouldn't use __FILE__ or
__LINE__ as template arguments if you can avoid it.
Does it matter if I anyway use template (S...)
at 10:22:47 UTC, Dmitry wrote:
> > void error(string msg, string file = __FILE__, size_t line =
> > __LINE__)
> > {
> >
> > ...
> >
> > }
> >
> > That's what Exception's constructor does as well as functions
> > like std.excepti
On Monday, 17 April 2017 at 10:55:30 UTC, Jonathan M Davis wrote:
On Monday, April 17, 2017 10:30:35 Basile B. via
Digitalmars-d-learn wrote:
On Monday, 17 April 2017 at 10:22:47 UTC, Dmitry wrote:
void error(string msg, string file = __FILE__, size_t line =
__LINE__)
{
...
}
That's
{
> >
> > if (name in listOfScenes)
> > {
> >
> > EError(__FILE__, __LINE__, "scene already
> >
> > exists".L, quoted(name));
> >
> > }
> >
> > ...
> > }
>
On Monday, 17 April 2017 at 10:30:35 UTC, Basile B. wrote:
when used as template value parameter, __FILE__ and
__LINE__evaluate to the file and line of the call site. So help
yourself ans use something like this:
void error(string f = __FILE__, int l = __LINE__)(string msg){}
Thank you
On Monday, 17 April 2017 at 10:22:47 UTC, Dmitry wrote:
Hi there.
Currently for messages about errors I use code like this:
void add(string name, ref Scene scene)
{
if (name in listOfScenes)
{
EError(__FILE__, __LINE__, "scene already
exists".L, q
Hi there.
Currently for messages about errors I use code like this:
void add(string name, ref Scene scene)
{
if (name in listOfScenes)
{
EError(__FILE__, __LINE__, "scene already exists".L,
quoted(name));
}
...
}
Is there way
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran with rdmd. However, the script needs to know it's own
pa
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran with rdmd. However, the script needs to know it's own
pa
On Friday, July 22, 2016 19:28:05 Jonathan Marler via Digitalmars-d-learn
wrote:
> Actually I realized if __FILE__ was always absolute, then all
> your exception messages would contain the full path of the file
> it was thrown from on the machine it was compiled on. This would
> be qu
On Friday, 22 July 2016 at 19:23:30 UTC, Steven Schveighoffer
wrote:
On 7/22/16 2:43 PM, Kagamin wrote:
On Friday, 22 July 2016 at 13:50:55 UTC, Jonathan Marler wrote:
shell/anypath> rdmd /somedir/clean.d
Removing /somedir/build...
So for command rdmd /somedir/clean.d what __FILE__ conta
On Friday, 22 July 2016 at 19:13:31 UTC, sdhdfhed wrote:
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&
On 7/22/16 2:43 PM, Kagamin wrote:
On Friday, 22 July 2016 at 13:50:55 UTC, Jonathan Marler wrote:
shell/anypath> rdmd /somedir/clean.d
Removing /somedir/build...
So for command rdmd /somedir/clean.d what __FILE__ contains? LDC tells
me the same path as specified on the command line, and t
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)
{
On Friday, 22 July 2016 at 13:50:55 UTC, Jonathan Marler wrote:
shell/anypath> rdmd /somedir/clean.d
Removing /somedir/build...
So for command rdmd /somedir/clean.d what __FILE__ contains? LDC
tells me the same path as specified on the command line, and that
is specified relative to curr
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 d
On Friday, 22 July 2016 at 13:30:10 UTC, Steven Schveighoffer
wrote:
On 7/22/16 3:47 AM, Jonathan Marler 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
On 7/22/16 3:47 AM, Jonathan Marler 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 you combine it with current working directory, this should give you
the ful
On Friday, 22 July 2016 at 10:51:57 UTC, Kagamin wrote:
Don't just ignore Adam's question :)
eh he answered it.
On Windows, it is somewhat common for things to be loaded or
modified (especially on older versions when these were still
writable...) from the program's directory. Its support fil
On Friday, 22 July 2016 at 07:53:17 UTC, Jonathan Marler wrote:
It's important to remember that the clean.d script is ran with
rdmd, and that it is meant to be called from any directory.
Since it's ran with rdmd, the thisExePath won't give you the
right directory, and since you can call it fro
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&#x
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__
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
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.
On Friday, 22 July 2016 at 06:45:58 UTC, Jacob Carlborg wrote:
On 2016-07-22 04:24, Jonathan Marler wrote:
The script depends on other files relative to where it exists
on the
file system. I couldn't think of a better design to find
these files
then knowing where the script exists, can you?
ot;Directory of this script is " %~dp0
DLANG
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
What's wrong with __FILE__.dirName ?
It's kinda weird, sometimes I've noticed that the __FILE__
keyword is an
On 2016-07-22 04:24, Jonathan Marler wrote:
The script depends on other files relative to where it exists on the
file system. I couldn't think of a better design to find these files
then knowing where the script exists, can you?
What kind of files are we talking about. Resource files, config
-
import std.stdio;
int main(string[] args) {
writeln("Directory of this script is ", ???);
}
What's wrong with __FILE__.dirName ?
On Thursday, 21 July 2016 at 22:57:06 UTC, Jonathan M Davis wrote:
On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via
Digitalmars-d- learn wrote:
[...]
It would be pretty terrible actually to put the executable in
the source path, and in many cases, the user wouldn't even have
the
On Friday, 22 July 2016 at 01:52:57 UTC, Adam D. Ruppe wrote:
On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler
wrote:
I explain in the original post. Any ideas Adam? Thanks in
advance.
But why does the batch script use it? Since you are rewriting
anyway, maybe you can find an easier
On Thursday, 21 July 2016 at 22:47:42 UTC, Jonathan Marler wrote:
I explain in the original post. Any ideas Adam? Thanks in
advance.
But why does the batch script use it? Since you are rewriting
anyway, maybe you can find an easier/better way to achieve the
goal.
On Thursday, July 21, 2016 19:54:34 Jonathan Marler via Digitalmars-d-learn
wrote:
> Is there a way to get the full path of the current source file?
> Something like:
>
> __FILE_FULL_PATH__
>
> I'm asking because I'm rewriting a batch script in D, meant to be
> ran with rdmd. However, the script
On Thursday, July 21, 2016 18:39:45 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> On 7/21/16 3:54 PM, Jonathan Marler wrote:
> > Is there a way to get the full path of the current source file?
> > Something like:
> >
> > __FILE_FULL_PATH__
> >
> > I'm asking because I'm rewriting a batch s
On Thursday, 21 July 2016 at 22:39:45 UTC, Steven Schveighoffer
wrote:
On 7/21/16 3:54 PM, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to
be ran
with rdmd.
On Thursday, 21 July 2016 at 22:33:39 UTC, Adam D. Ruppe wrote:
On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote:
won't? what this means?
That gives the path to the .exe but he wants the path to the .d.
But why? I would think the current working directory is
probably adequate and th
On 7/21/16 3:54 PM, Jonathan Marler wrote:
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to be ran
with rdmd. However, the script needs to know it's own path. The
original batch sc
On Thursday, 21 July 2016 at 22:28:39 UTC, zabruk70 wrote:
won't? what this means?
That gives the path to the .exe but he wants the path to the .d.
But why? I would think the current working directory is probably
adequate and that's easy to get...
On Thursday, 21 July 2016 at 19:54:34 UTC, Jonathan Marler wrote:
thisExePath won't work.
won't? what this means?
this work on my windows
import std.file: thisExePath;
import std.stdio: writeln;
void main()
{
writeln(thisExePath());
}
Is there a way to get the full path of the current source file?
Something like:
__FILE_FULL_PATH__
I'm asking because I'm rewriting a batch script in D, meant to be
ran with rdmd. However, the script needs to know it's own path.
The original batch script uses the %~dp0 variable for this, bu
1 - 100 of 162 matches
Mail list logo
