[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #22 from Mathias Lang  ---
> I think what you are saying is that a mixed in template could affect existing 
> *imports*, right? But an import can already do that! Ignoring imports with 
> mixins doesn't fix this problem.

An import can already hijack an import if it appears at scope lexically
'closer' to the looked-up symbol, but yes, imports can still hijack.
I don't know if there is any solution to that issue, short of allowing only one
level of import, which of course is out of question.

> The mixin could not hijack local symbols, right? I thought that was the 
> larger point -- you are referring to class/local symbols, or even module 
> functions, and suddenly that changes through a hijacked import.

It could be implemented both ways, since those are two different lists of
imports. I believe the sane way to do it (and the approach I used IIRC) would
be to look up mixed in / inherited imports after local ones.

> I get that it's good to prevent hijacking as much as possible. But this 
> doesn't disallow hijacking to any further degree than is already disallowed. 
> In other words, preventing mixins from hijacking imported symbols doesn't 
> remove the problem, and just makes the language inconsistent.

It disallows some imports, so it *does* prevent hijacking by definition.
Whether or not those hijackings are a common enough source of bugs, and the
feature it disallows is useful, is up to one's judgment.

As for inconsistency, I disagree. With the separated lookup, there is no way to
inherit an 'import scope'. This means any hijacking can only ever come from an
import that is in your module. I believe that was the important property Walter
was after: https://issues.dlang.org/show_bug.cgi?id=15966#c3

Note that as the original author of this issue (and the similar #15966) I'm
only the messenger, and not the one that took the decision.
IOW, I'm fighting someone else's war here, and he's the one you have to
convince if you want this overturned :-)

--

Re: DConf Videos

[Walter Bright via Digitalmars-d]

On 6/6/2016 3:40 AM, sarn wrote:

What's the best source of DConf videos at the moment?  Are there are any edited
versions released?

I'd like to share some of my favourite talks.


http://wiki.dlang.org/Videos

(though it needs updating)

Re: full path to source file __FILE__

[Jonathan M Davis via Digitalmars-d-learn]

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 quite odd.

In some cases, it could also be viewed as a security risk. For instance, on
*nix systems, it would almost certainly give away the username of the user
that built it.

Also, it would result in needlessly long error messages when exceptions were
thrown, which could impact performance as well as making log files that much
more annoying.

I'm definietly inclined to think that making __FILE__ absolute would be a
mistake. Maybe something else like __FILE_ABSOLUTE__ would be okay, but in
this particular case, I'd argue that you should just not make it a script if
you need additional files that are next to it rather than in a known place.
And as far as your example of build files goes, it's normal to have to run
stuff like that in the directory where it lives (e.g. that's what happens
with make), so while I understand that it may be annoying, I don't think
that it's a compelling use case for changing what __FILE__ does.

- Jonathan M Davis

[Issue 16312] "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16312

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #1 from Mathias Lang  ---
Note: Only when compiled with `-de`.

They are two things at play here:

- First, when the compiler encounter an error, it 'poison' the AST node.
That can lead to wrong error messages in places not adjusted to deal with the
poisoning.

- Second, the compiler treat a non-fatal error (e.g. a warning when `-w` is
provided or a deprecation when `-de` is provided) as a fatal one. This can have
extremely dangerous consequences, e.g. the following will still compiles, just
have different behaviour:

```
class Deprecated
{
int j;
this (T) (T i)
{
this.j = (i, T.init);
}
}

template Foo (T) if (__traits(compiles, { T a = new T(42); }))
{
enum Foo = "First instance";
}

template Foo (T) if (!__traits(compiles, { T a = new T(42); }))
{
enum Foo = "Second instance";
}

pragma(msg, Foo!(Deprecated));
```

The second bug is well known, so I suppose this ER is about the first point ?

--

[Issue 16312] "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16312

Marco Leise  changed:

   What|Removed |Added

   Severity|enhancement |minor

--

Re: Building phobos GDC

[Lodovico Giaretta via Digitalmars-d-learn]

On Friday, 22 July 2016 at 20:26:50 UTC, Rufus Smith wrote:
On Friday, 22 July 2016 at 19:52:59 UTC, Lodovico Giaretta 
wrote:

On Friday, 22 July 2016 at 18:30:13 UTC, Rufus Smith wrote:
Trying to compile code that uses GDC, had to import phobos 
files from dmd in to project since they are not in the GDC's 
phobo lib(the core.sys.windows stuff).


Almost all the errors are related to stuff like

PALETTEENTRY* peNew() return { return _peNew.ptr; }


Does that even make sense?


I'll add that, in general, it's a bad idea to mix the 
libraries of the various compilers. In fact, the library has 
the same release cycle as the frontend, and is specific to the 
frontend version it comes with. GDC is several frontend 
versions behind DMD, so GDC cannot support the new features / 
characteristics of the recent DMD libraries.
You should always use a Phobos version as old as the frontend 
of the compiler you're using.


I don't agree with this. The versions are too far out of sync. 
It is better to test the different versions together because 
they are not consistent. As I yet I can neither use GDC or LDC 
because they don't compile the code that works with DMD. This 
is a problem with those compilers. If one could guarantee that 
the oldest compiler was always compatible, 
eventually(reasonably), with the newest one, it would be a 
different story. But bugs creep in. I'd rather work with the 
reference compiler, the actual one the language is based off 
of, rather than work with one that is not even guaranteed to be 
maintained properly.


With dmd, I know exactly what I'm getting and I only bother 
with the other compilers due to performance, which is not 
priority when developing. Hence, I hope that the other 
compilers are up to speed once I am finished with developing. 
This is a risk, but no more than expecting those compilers to 
eventually be updated. Given that the maintenance of LDC and 
GDC are rather low compared to DMD, I'd rather stick with DMD.


LDC is fairly up to date. In fact, it recently shipped an alpha 
version with support for the 2.071 frontend, while DMD 2.072 is 
still in beta. So, not that bad, just one version behind. I 
started a project a couple months ago with DMD 2.071. I'm still 
working on it, and now I can also use LDC.

The real problem is GDC, which apparently is currently at 2.066.

[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15498

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #12 from Marco Leise  ---
Hmm, recently I see different "overlapping fields" error messages popping up
after certain types of deprecations are detected on the involved fields. There
may be a connection: https://issues.dlang.org/show_bug.cgi?id=16312

--

[Issue 16312] New: "Error: Overlapping fields" caused by use of deprecated features in referred to fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16312

  Issue ID: 16312
   Summary: "Error: Overlapping fields" caused by use of
deprecated features in referred to fields
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: diagnostic, rejects-valid
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: marco.le...@gmx.de

The compiler sees fields as overlapping when there are certain types of
deprecated features involved in the types of those fields. The two trigger
features I could make out are using full symbol paths to bypass imports (i.e.
using core.stdc.stdlib.free without importing core.stdc.stdlib) and providing a
struct ctor with all arguments having defaults. If such a "deprecated" struct
is then used with other fields in an aggregate in a way it would not be allowed
for overlapping fields, an error is printed. Here is a short example:

struct Deprecated
{
this(int i = 0) {}
}

class Bogus
{
Deprecated* a = null;
int seems_to_overlap = 0;
}

Deprecation: constructor app.Deprecated.this all parameters have default
arguments, but structs cannot have default constructors.
Error:   overlapping default initialization for field a and
seems_to_overlap

Whether or not the compiler would actually silently overlap the two fields
under other circumstances is not known to me.

Related in some way:
https://issues.dlang.org/show_bug.cgi?id=15498
(Unhelpful error message "destructors, postblits and invariants are not allowed
in overlapping fields")

--

Re: Building phobos GDC

[Rufus Smith via Digitalmars-d-learn]

On Friday, 22 July 2016 at 19:52:59 UTC, Lodovico Giaretta wrote:

On Friday, 22 July 2016 at 18:30:13 UTC, Rufus Smith wrote:
Trying to compile code that uses GDC, had to import phobos 
files from dmd in to project since they are not in the GDC's 
phobo lib(the core.sys.windows stuff).


Almost all the errors are related to stuff like

PALETTEENTRY* peNew() return { return _peNew.ptr; }


Does that even make sense?


I'll add that, in general, it's a bad idea to mix the libraries 
of the various compilers. In fact, the library has the same 
release cycle as the frontend, and is specific to the frontend 
version it comes with. GDC is several frontend versions behind 
DMD, so GDC cannot support the new features / characteristics 
of the recent DMD libraries.
You should always use a Phobos version as old as the frontend 
of the compiler you're using.


I don't agree with this. The versions are too far out of sync. It 
is better to test the different versions together because they 
are not consistent. As I yet I can neither use GDC or LDC because 
they don't compile the code that works with DMD. This is a 
problem with those compilers. If one could guarantee that the 
oldest compiler was always compatible, eventually(reasonably), 
with the newest one, it would be a different story. But bugs 
creep in. I'd rather work with the reference compiler, the actual 
one the language is based off of, rather than work with one that 
is not even guaranteed to be maintained properly.


With dmd, I know exactly what I'm getting and I only bother with 
the other compilers due to performance, which is not priority 
when developing. Hence, I hope that the other compilers are up to 
speed once I am finished with developing. This is a risk, but no 
more than expecting those compilers to eventually be updated. 
Given that the maintenance of LDC and GDC are rather low compared 
to DMD, I'd rather stick with DMD.

Re: Building phobos GDC

[Lodovico Giaretta via Digitalmars-d-learn]

On Friday, 22 July 2016 at 18:30:13 UTC, Rufus Smith wrote:
Trying to compile code that uses GDC, had to import phobos 
files from dmd in to project since they are not in the GDC's 
phobo lib(the core.sys.windows stuff).


Almost all the errors are related to stuff like

PALETTEENTRY* peNew() return { return _peNew.ptr; }


Does that even make sense?


I'll add that, in general, it's a bad idea to mix the libraries 
of the various compilers. In fact, the library has the same 
release cycle as the frontend, and is specific to the frontend 
version it comes with. GDC is several frontend versions behind 
DMD, so GDC cannot support the new features / characteristics of 
the recent DMD libraries.
You should always use a Phobos version as old as the frontend of 
the compiler you're using.

[Issue 16310] std.zip: can't specify archive member order

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16310

Chris Wright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Chris Wright  ---
https://github.com/dlang/phobos/pull/4637

--

Re: Building phobos GDC

[Lodovico Giaretta via Digitalmars-d-learn]

On Friday, 22 July 2016 at 18:30:13 UTC, Rufus Smith wrote:
Trying to compile code that uses GDC, had to import phobos 
files from dmd in to project since they are not in the GDC's 
phobo lib(the core.sys.windows stuff).


Almost all the errors are related to stuff like

PALETTEENTRY* peNew() return { return _peNew.ptr; }


Does that even make sense?


The peculiarity of this code is that it uses DIP 25.
I don't know if GDC supports it, nor if you need some compiler 
switch.

In DMD you need the -dip25 switch.

For more infos on DIP 25: https://wiki.dlang.org/DIP25

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

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__ contains? 
LDC tells
me the same path as specified on the command line, and that is 
specified

relative to current directory, where the compiler is called, so
absolutePath(__FILE__) should give the right result.


The issue which is not being expressed completely by Jonathan, 
is that rdmd caches the build.


So if I run the script from one directory, then cd elsewhere, 
it has the same __FILE__ as before, but the cwd has moved. So 
it won't work.


I had assumed rdmd would rebuild, but it doesn't.

-Steve


Thanks for pointing this out, somehow I overlooked this use case.

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

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" 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.


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 quite odd. Both a relative and absolute version are useful in 
different cases.

Re: full path to source file __FILE__

[Steven Schveighoffer via Digitalmars-d-learn]

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 that is specified
relative to current directory, where the compiler is called, so
absolutePath(__FILE__) should give the right result.


The issue which is not being expressed completely by Jonathan, is that 
rdmd caches the build.


So if I run the script from one directory, then cd elsewhere, it has the 
same __FILE__ as before, but the cwd has moved. So it won't work.


I had assumed rdmd would rebuild, but it doesn't.

-Steve

Re: Terminix Stable 1.2.0 Released

[Gerald via Digitalmars-d-announce]

On Friday, 22 July 2016 at 17:30:30 UTC, sdhdfhed wrote:

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 ?


It has been packaged for Debian though there is still an issue 
with LDC to be sorted out:


https://github.com/gnunn1/terminix/issues/25#issuecomment-233138093

The biggest challenge is getting D's tool chain supported, the 
release of 1.0 of LDC is what is making this possible for 
Terminix since DMD is a non-starter for most distros.

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: full path to source file __FILE__

[Kagamin via Digitalmars-d-learn]

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 current directory, where the compiler is 
called, so absolutePath(__FILE__) should give the right result.

Building phobos GDC

[Rufus Smith via Digitalmars-d-learn]

Trying to compile code that uses GDC, had to import phobos files 
from dmd in to project since they are not in the GDC's phobo 
lib(the core.sys.windows stuff).


Almost all the errors are related to stuff like

PALETTEENTRY* peNew() return { return _peNew.ptr; }


Does that even make sense?

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__

[Jonathan Marler via Digitalmars-d-learn]

On Friday, 22 July 2016 at 09:37:24 UTC, sdhdfhed wrote:

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.


Again that's Walter's call.  The __FILE__ trait seems to be used 
most useful for error messages.  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, but 
might make others things harder.  I'm not particularly for or 
against either solution (not sure why you're trying to convince 
me of this one), that would be up to the owners of the language :)

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

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 you combine it with current working directory, this should 
give you the full path.


Looks like std.path gives you a mechanism, I think this should 
work:


import std.path;
auto p = __FILE__.absolutePath;

http://dlang.org/phobos/std_path.html#.absolutePath

-Steve


That doesn't work in the example I provided:

/somedir/clean.d
/somedir/build

Say clean.d is meant to remove the build directory that lives in 
the same path as the clean.d script itself.


shell/anypath> rdmd /somedir/clean.d
Removing /somedir/build...

Since you are running the script from "anypath", the information 
that clean.d exists at /somedir is lost.  The last component to 
know where the file was found is the compiler itself.

Terminix Stable 1.2.0 Released

[Gerald via Digitalmars-d-announce]

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.

Re: full path to source file __FILE__

[Steven Schveighoffer via Digitalmars-d-learn]

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 full path.


Looks like std.path gives you a mechanism, I think this should work:

import std.path;
auto p = __FILE__.absolutePath;

http://dlang.org/phobos/std_path.html#.absolutePath

-Steve

Re: full path to source file __FILE__

[Adam D. Ruppe via Digitalmars-d-learn]

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 files are 
all put together with the exe.


He's trying to make a "script" that is run with rdmd that 
pretends to work just like an exe and works with files around it.

JSON Serialization with runtime filtering.

[Alexander Milushev via Digitalmars-d-learn]

I there any json serialization library which allow to make 
decision about ignoring fields in runtime? I trying to write rest 
client but server accept either 'cmd' or 'args' field for example 
and I need to find solution.

Re: full path to source file __FILE__

[Kagamin via Digitalmars-d-learn]

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 from any directory, 
you also can't use the current directory.  As you can see, what 
you really want to know is where the script itself lives.


Don't just ignore Adam's question :)
https://dlang.org/phobos/std_path.html#.absolutePath
https://dlang.org/phobos/std_file.html#.getcwd - why this won't 
work for you?

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

[Bauss via Digitalmars-d]

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

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: DConf Videos

[Joakim via Digitalmars-d]

On Thursday, 7 July 2016 at 14:10:12 UTC, Dicebot wrote:

On Thursday, 30 June 2016 at 17:56:41 UTC, Jack Stouffer wrote:
I've reminded Dylan about it. Should be out soon, but no 
exact ETA.


Still no word?


Sorry, getting delayed again >_<


Will there be direct downloads, like in previous years?

Re: DConf 2016 on YouTube

[Rene Zwanenburg via Digitalmars-d-announce]

On Thursday, 21 July 2016 at 16:35:44 UTC, Ali Çehreli wrote:

Stealing the opportunity to announce this news... :)

  
https://www.youtube.com/playlist?list=PL3jwVPmk_PRyTWWtTAZyvmjDF4pm6EX6z


Reddit:


https://www.reddit.com/r/programming/comments/4txf9w/dconf_2016_video_playlist/

Ali


This is great, my thanks to everyone involved!

Re: union initalization

[Johannes Pfau via Digitalmars-d-learn]

Am Fri, 22 Jul 2016 01:48:52 +
schrieb Rufus Smith :

> I would like to combine two types
> 
> 
> template Foo(A, B = 4)
> {
>  union
>  {
> byte b = B;
> int a = A << 8;
>  }
> }
> 
> 
> I get an error about overlapping default initialization. They 
> don't actually overlap in this case because of the shift.

To be pedantic about this: The initializers actually do overlap. As A
<< 8 shifts in zeroes, these bits are initialized as well. I think
there's no idiomatic way to initialize only part of an integer.

Re: full path to source file __FILE__

[Jonathan Marler 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:

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.

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

[Dicebot via Digitalmars-d]

On 07/22/2016 10:23 AM, Kagamin wrote:
> On Friday, 22 July 2016 at 06:38:25 UTC, Jacob Carlborg wrote:
>> The .di/header for module "a" don't need to include "import b" because
>> "Bar" is not part of the interface of module "a".
> 
> It works for your example, but doesn't work for idiomatic D code, which
> is always heavily templated.

.. which naturally leads to watching about Benjamin DConf talk about
fixing "export" and that is where everything clicks together. Organizing
large projects as bunch of small static libraries per package and
defining public API of those via `export` (and not just public) would
achieve this topic goal and much more, all without changing the language.

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

[Kagamin via Digitalmars-d]

On Friday, 22 July 2016 at 06:38:25 UTC, Jacob Carlborg wrote:
The .di/header for module "a" don't need to include "import b" 
because "Bar" is not part of the interface of module "a".


It works for your example, but doesn't work for idiomatic D code, 
which is always heavily templated.

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 !

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

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?


What kind of files are we talking about. Resource files, config 
files? Are they static? For static resource files you can 
bundle them in the executable with a string import. For config 
files it might be better to store it in a completely different 
directory, like the user's home directory. This actually 
depends on what kind of config files and the operating system.


I suppose I should have been more specific.  The script actually 
operates on the filesystem relative to where it lives.  It copies 
files, modifies directories, etc.  It is meant to be ran from any 
directory, but is only meant to modify the filesystem relative to 
where it lives.  Take a simple example of a clean script:


/somedir/clean.d
/somedir/build

Say clean.d is meant to remove the build directory that lives in 
the same path as the clean.d script itself.


shell/anypath> rdmd /somedir/clean.d
Removing /somedir/build...

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 from any directory, 
you also can't use the current directory.  As you can see, what 
you really want to know is where the script itself lives.

Re: full path to source file __FILE__

[Jonathan Marler via Digitalmars-d-learn]

On Friday, 22 July 2016 at 05:41:00 UTC, fdgdsgf 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 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, but I'm at a loss on how to do this in D.  Since rdmd 
compiles the executable to the %TEMP% directory, thisExePath 
won't work.


BATCH
-
echo "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 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.

Re: New __FILE_DIR__ trait?

[Jonathan Marler via Digitalmars-d]

On Friday, 22 July 2016 at 04:10:38 UTC, rikki cattermole wrote:

On 22/07/2016 2:08 PM, Jonathan Marler wrote:
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.


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/5959

Re: full path to source file __FILE__

[Jacob Carlborg via Digitalmars-d-learn]

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 files? 
Are they static? For static resource files you can bundle them in the 
executable with a string import. For config files it might be better to 
store it in a completely different directory, like the user's home 
directory. This actually depends on what kind of config files and the 
operating system.


--
/Jacob Carlborg

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

[Jacob Carlborg via Digitalmars-d]

On 2016-07-21 10:52, Kagamin wrote:


As I see dependency resolution has function granularity, but headers
have only file granularity. How do you expect headers to work on finer
granularity level? If a module depends on another module, the header
must assume it depends on all members of that module and if one member
indirectly changes due to its private dependencies, it must be assumed
that all depending modules must be recompiled, because they depend on
the changed module even if they don't depend on the changed member and
its private dependencies.

Not sure if tup can solve this problem. It can if it builds full
dependency graph for each file instead of having one graph for the whole
project.


A guess:

module a;

import b;

void foo()
{
Bar bar;
}

module b;

struct Bar {}

The .di/header for module "a" don't need to include "import b" because 
"Bar" is not part of the interface of module "a".


--
/Jacob Carlborg

Re: union initalization

[Ali Çehreli via Digitalmars-d-learn]

On 07/21/2016 08:00 PM, Rufus Smith wrote:

>> Bitfields may actually be useful in this case:
>>
>>   https://dlang.org/phobos/std_bitmanip.html#.bitfields
>>
>
> They don't allow default assignment though?

A factory function can help:

import std.bitmanip;

struct S(int a_init, byte b_init) {
mixin (bitfields!(int, "a", 24,
  byte, "b", 8));
@disable this();
}

auto makeS(int a_init, byte b_init = 4)() {
auto s = S!(a_init, b_init).init;
s.a = a_init;
s.b = b_init;
return s;
}

void main() {
const s = makeS!42();
assert(s.a == 42);
assert(s.b == 4);
}

>> The following at least compiles:
>>
>> struct Foo(int A, byte B = 4)
>> {
>> union
>> {
>> byte b = void;
>> int a = void;
>> uint __both = (A << 8) | B;
>> }
>> }
>>
>> void main() {
>> auto f = Foo!(42)();
>> }
>>
>> Ali
>
> Maybe... I don't like extra member.

Me neither. Besides, 'b' coincides with a different part of 'a' 
depending on the endianness of the system.


Ali