Re: full path to source file __FILE__

[sdhdfhed via Digitalmars-d-learn]

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: Terminix Stable 1.2.0 Released

[sdhdfhed via Digitalmars-d-announce]

On Friday, 22 July 2016 at 13:54:41 UTC, Gerald wrote:
I've pushed out the latest stable version of Terminix, a tiling 
terminal emulator for Linux written in D using GtkD. The 
following new features have been added:


Design changes as per discussion in #372
Support for background images
Limited support for automatic profile switching
Globally disable shortcuts
Copy on select preference
Support for a Visual Bell
Numerous bug fixes

More information is available at 
https://github.com/gnunn1/terminix.


I'm always looking for contributors, so if anyone is interested 
in lending a hand feel free to join the party.


Is terminix already 'officially' packaged by any distro ?

Re: proposal: private module-level import for faster compilation

[sdhdfhed via Digitalmars-d]

On Friday, 22 July 2016 at 10:47:33 UTC, Bauss wrote:

On Wednesday, 20 July 2016 at 07:50:13 UTC, Timothee Cour wrote:

typo:
s/dmd -c -o- -deps A.d/dmd -c -o- -deps B.d

On Wed, Jul 20, 2016 at 12:45 AM, Timothee Cour 
 wrote:



[...]


I believe private import is already reserved. It's being used 
618 places inside of official D code.


See: 
https://github.com/search?q=org%3Adlang+private+import=Code


it's legit in several tests that verify the protection attributes 
but otherwise it's approximatively 600 times useless ;) since 
import are private by default.


But therorically you're right, it already has a specific 
semantic. And it's probably perfectly legit in some cases, like 
here:


public:
   declA;
   declB;
   private import stuff;
   declX;

where it's used to temprarily override the protection attribute 
of the scope.

Re: full path to source file __FILE__

[sdhdfhed via Digitalmars-d-learn]

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__

[sdhdfhed via Digitalmars-d-learn]

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__

[sdhdfhed via Digitalmars-d-learn]

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 !