Re: Weird interaction with public and non-public imports

2021-01-28 Thread SealabJaster via Digitalmars-d-learn

On Thursday, 28 January 2021 at 13:13:46 UTC, Paul Backus wrote:

...


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

These issues are always so subtle and specific yet so annoying, 
e.g.:


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

and

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


Re: Weird interaction with public and non-public imports

2021-01-28 Thread Paul Backus via Digitalmars-d-learn

On Thursday, 28 January 2021 at 13:07:13 UTC, SealabJaster wrote:

Please see: https://run.dlang.io/is/2mwcPH

I'd expect that the `isInstanceOf` would be true instead of 
false here.


Commenting out the public import changes the output of 
`fullyQualifiedName`. I can kind of see why this happens, but 
it's kind of annoying when things like `isInstanceOf` silently 
fail due to this.


Looks like a bug to me. I recommend filing a bug report on 
issues.dlang.org.


Weird interaction with public and non-public imports

2021-01-28 Thread SealabJaster via Digitalmars-d-learn

Please see: https://run.dlang.io/is/2mwcPH

I'd expect that the `isInstanceOf` would be true instead of false 
here.


Commenting out the public import changes the output of 
`fullyQualifiedName`. I can kind of see why this happens, but 
it's kind of annoying when things like `isInstanceOf` silently 
fail due to this.


For context: I found this after getting a compiler error after 
stitching a bunch of D files together, which is why there's a mix 
of a public import and local import in the same file.


Part of me feels like it's a bug since if the alias `T` is using 
one "version" (for lack of a better word) of `Nullable`, then 
surely that same "version" would be given to `isInstanceOf`?


It can get a bit more interesting as well: 
https://run.dlang.io/is/n5jzJs


Re: Mixin and imports

2020-06-08 Thread data pulverizer via Digitalmars-d-learn
On Monday, 8 June 2020 at 16:02:02 UTC, Steven Schveighoffer 
wrote:

On 6/8/20 11:11 AM, jmh530 wrote:

On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote:

[snip]

Out of curiosity what does the "." in front of `foo` mean? 
[snip]


ag0aep6g provided the link to it [snip]


The dot operator simply specifies that the symbol you are 
looking for is defined at global scope, so it just changes the 
lookup rules.


Even though it makes the code clearer what foo you are looking 
at, it was not necessary -- removing the dot works.


In some cases it is necessary to use the . lookup rule, because 
you have another symbol that will be picked first.


For example:

int x;

template bar(string x)
{
   mixin("alias " ~ x ~ " = .x;");
}

-Steve


Thanks both of you. It's one of those puzzling things that was at 
the back of mind that has just been resolved.




Re: Mixin and imports

2020-06-08 Thread Steven Schveighoffer via Digitalmars-d-learn

On 6/8/20 11:11 AM, jmh530 wrote:

On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote:

[snip]

Out of curiosity what does the "." in front of `foo` mean? I've seen 
that in some D code on the compiler in GitHub and have no idea what it 
does. I tried Googling it to no avail. It doesn't have anything to do 
with UFCS does it?


Thanks


ag0aep6g provided the link to it, but it's one of those things that has 
been difficult for me to understand as well. I believe the original code 
had `foo` in a template. So in that case it was necessary. I'm not sure 
if it still is in my simplified version.


The dot operator simply specifies that the symbol you are looking for is 
defined at global scope, so it just changes the lookup rules.


Even though it makes the code clearer what foo you are looking at, it 
was not necessary -- removing the dot works.


In some cases it is necessary to use the . lookup rule, because you have 
another symbol that will be picked first.


For example:

int x;

template bar(string x)
{
   mixin("alias " ~ x ~ " = .x;");
}

-Steve


Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn

On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote:

[snip]

Out of curiosity what does the "." in front of `foo` mean? I've 
seen that in some D code on the compiler in GitHub and have no 
idea what it does. I tried Googling it to no avail. It doesn't 
have anything to do with UFCS does it?


Thanks


ag0aep6g provided the link to it, but it's one of those things 
that has been difficult for me to understand as well. I believe 
the original code had `foo` in a template. So in that case it was 
necessary. I'm not sure if it still is in my simplified version.


Re: Mixin and imports

2020-06-08 Thread ag0aep6g via Digitalmars-d-learn

On 08.06.20 16:27, data pulverizer wrote:
Out of curiosity what does the "." in front of `foo` mean? I've seen 
that in some D code on the compiler in GitHub and have no idea what it 
does. I tried Googling it to no avail. It doesn't have anything to do 
with UFCS does it?


https://dlang.org/spec/module.html#module_scope_operators


Re: Mixin and imports

2020-06-08 Thread data pulverizer via Digitalmars-d-learn

On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote:


```
...
template foo(string f) {
mixin("alias foo = .foo!(" ~ f ~ ");");
}
...
```


Out of curiosity what does the "." in front of `foo` mean? I've 
seen that in some D code on the compiler in GitHub and have no 
idea what it does. I tried Googling it to no avail. It doesn't 
have anything to do with UFCS does it?


Thanks


Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn

On Monday, 8 June 2020 at 12:20:46 UTC, Adam D. Ruppe wrote:

[snip]

Why do you even want foo!"fabs"? Usually when I see people 
having this problem it is actually a misunderstanding of what 
is possible with the foo!fabs style - which is better in 
basically every way and can be used in most the same places.


So what's your bigger goal?


There were some other functions in the module that allow the use 
of function!"thinginquotes". However, most of those functions are 
using the "thinginquotes" to avoid writing 
function!(SomeEnum.thinginquotes). That really isn't the thing to 
fix in this case. So I think it makes sense for me to give up 
what I was trying to do.


Re: Mixin and imports

2020-06-08 Thread FunkyD via Digitalmars-d-learn

On Monday, 8 June 2020 at 10:41:53 UTC, jmh530 wrote:

On Monday, 8 June 2020 at 10:28:39 UTC, Paul Backus wrote:

[snip]


Thanks for that suggestion. That works for me.

Unfortunately, it's probably not worth the extra effort though, 
versus doing foo!fabs in my case.


If they are all from std.math you can easily mixin in the 
template.


just import std.math there then it should work.

If you want more general arbitrary functions you can get the 
module of the function by using an alias. Alternatively you can 
just pass the function itself as an alias or template parameter. 
There are ways to do what you want but it's kinda hacky. I can't 
remember the details though. Basically you use mixins and traits 
to get the module the symbol exists in and then you can use a 
string mixin to import that module.




Re: Mixin and imports

2020-06-08 Thread Adam D. Ruppe via Digitalmars-d-learn

On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote:
In the code below, foo!fabs compiles without issue, but 
foo!"fabs" does not because the import is not available in the 
string mixin.


Why do you even want foo!"fabs"? Usually when I see people having 
this problem it is actually a misunderstanding of what is 
possible with the foo!fabs style - which is better in basically 
every way and can be used in most the same places.


So what's your bigger goal?


Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn

On Monday, 8 June 2020 at 10:28:39 UTC, Paul Backus wrote:

[snip]


Thanks for that suggestion. That works for me.

Unfortunately, it's probably not worth the extra effort though, 
versus doing foo!fabs in my case.


Re: Mixin and imports

2020-06-08 Thread Paul Backus via Digitalmars-d-learn

On Monday, 8 June 2020 at 10:23:24 UTC, jmh530 wrote:

On Monday, 8 June 2020 at 04:13:08 UTC, Mike Parker wrote:

[snip]


The problem isn't the mixin. It's the template. Templates take 
the scope of their declaration, not their instantiation. So 
the mixin is getting the template's scope.


Anyway, this appears to work:

`double z = foo!"std.math.fabs"(x);`


Thanks, that makes sense.

However, I get the same error with the code below. Am I doing 
something wrong?


double foo(alias f)(double x) {
return f(x);
}

template foo(string f)
{
mixin("alias foo = .foo!(" ~ f ~ ");");
}

void main() {
static import std.math;
double x = 2.0;
double y = foo!(std.math.fabs)(x);
double z = foo!"std.math.fabs"(x);
}


If you want to refer to symbols in the scope where the template 
is instantiated, you will have to move the mixin outside of the 
template:


double foo(alias f)(double x) {
return f(x);
}

template foo(string f)
{
enum foo = "foo!(" ~ f ~ ")";
}

void main() {
import std.math: fabs;
double x = 2.0;
double y = foo!(fabs)(x);
double z = mixin(foo!"fabs")(x);
}


Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn

On Monday, 8 June 2020 at 04:13:08 UTC, Mike Parker wrote:

[snip]


The problem isn't the mixin. It's the template. Templates take 
the scope of their declaration, not their instantiation. So the 
mixin is getting the template's scope.


Anyway, this appears to work:

`double z = foo!"std.math.fabs"(x);`


Thanks, that makes sense.

However, I get the same error with the code below. Am I doing 
something wrong?


double foo(alias f)(double x) {
return f(x);
}

template foo(string f)
{
mixin("alias foo = .foo!(" ~ f ~ ");");
}

void main() {
static import std.math;
double x = 2.0;
double y = foo!(std.math.fabs)(x);
double z = foo!"std.math.fabs"(x);
}


Re: Mixin and imports

2020-06-07 Thread Mike Parker via Digitalmars-d-learn

On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote:
In the code below, foo!fabs compiles without issue, but 
foo!"fabs" does not because the import is not available in the 
string mixin. If I move the import to the top of the module, 
then it works. However, then if I move foo to another module, 
then it will no longer compile since it is in different modules.


Is there any way I can make sure the mixin knows about the 
import?



The problem isn't the mixin. It's the template. Templates take 
the scope of their declaration, not their instantiation. So the 
mixin is getting the template's scope.


Anyway, this appears to work:

`double z = foo!"std.math.fabs"(x);`





Mixin and imports

2020-06-07 Thread jmh530 via Digitalmars-d-learn
In the code below, foo!fabs compiles without issue, but 
foo!"fabs" does not because the import is not available in the 
string mixin. If I move the import to the top of the module, then 
it works. However, then if I move foo to another module, then it 
will no longer compile since it is in different modules.


Is there any way I can make sure the mixin knows about the import?

I am just using fabs as an example. Ideally, I would want to use 
any function from any other module. I can figure out how to do 
it, for instance, if the only functions that were allowed were 
those in one module, like std.math.


```
double foo(alias f)(double x) {
return f(x);
}

template foo(string f) {
mixin("alias foo = .foo!(" ~ f ~ ");");
}

void main() {
import std.math: fabs;

double x = 2.0;
double y = foo!fabs(x);
double z = foo!"fabs"(x);
}
```


Detecting unneeded imports in CI

2020-02-06 Thread Joseph Rushton Wakeling via Digitalmars-d-learn

Hello folks,

Are there any well-established CI patterns/tools for detecting 
unneeded imports in D code?  Ideally including detecting unused 
symbols from selective imports?


Thanks and best wishes,

 -- Joe


Re: Unused imports

2020-01-30 Thread Francesco Mecca via Digitalmars-d-learn

On Thursday, 30 January 2020 at 16:23:54 UTC, Michael wrote:

Is there a way to detect unused imports?

It happened to me that I used imports which I did not need in 
the end. So, I'd like to remove them easily.


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

TL;DR
This has come up in the past and the typical answer was: "This 
should be implemented as a third party tool using dmd as a 
library".


It is a problem that there are no currently available tools to do 
that (maybe visual-d greys out unused imports) but I do agree 
that it should be provided as a third party.


Such a functionality could end up in:
https://github.com/dlang-community/D-Scanner

and it is also a good first time project for a beginner in the D 
ecosystem.


Unused imports

2020-01-30 Thread Michael via Digitalmars-d-learn

Is there a way to detect unused imports?

It happened to me that I used imports which I did not need in the 
end. So, I'd like to remove them easily.





Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-04-28 16:18:59 +, kdevel said:


This compiles with dmd v2.085.1:

$ cat A/a.d
module A.a;
import A.b;

$ cat A/b.d
module A.b;
struct myStruct {
int i;
}

$ cat A/c.d
module A.c;
import A.a;
import A.b;

struct myOtherStruct {
myStruct ms;
}

void main ()
{
import std.stdio;
myOtherStruct mos;
mos.writeln;
}


Yes, as long as you are adding the imports all over, things can work. 
But as said, if you creating bindings for a larger C library, this is 
not practicable.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Packages / imports & references between modules

2019-04-28 Thread kdevel via Digitalmars-d-learn

On Sunday, 28 April 2019 at 14:24:08 UTC, Robert M. Münch wrote:

On 2019-04-28 11:44:03 +, Mike Parker said:

They're different symbols because they're in different 
modules. The module and package name is part of the symbol 
name.


Ok, that's what I assumed too.


 Just import A.b in A.a.


Won't help. I just commented the lines DStep generated for 
forward referenced structs.


This compiles with dmd v2.085.1:

$ cat A/a.d
module A.a;
import A.b;

$ cat A/b.d
module A.b;
struct myStruct {
   int i;
}

$ cat A/c.d
module A.c;
import A.a;
import A.b;

struct myOtherStruct {
   myStruct ms;
}

void main ()
{
   import std.stdio;
   myOtherStruct mos;
   mos.writeln;
}




Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-04-28 11:44:03 +, Mike Parker said:

They're different symbols because they're in different modules. The 
module and package name is part of the symbol name.


Ok, that's what I assumed too.


 Just import A.b in A.a.


Won't help. I just commented the lines DStep generated for forward 
referenced structs.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Packages / imports & references between modules

2019-04-28 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 28 April 2019 at 11:12:50 UTC, Robert M. Münch wrote:



One more problem now showing up, when I do this:

A/a.d
module A.a;
struct myStruct;

A/b.d
module A.b;
struct myStruct {...}

A/c.d
module A.c;
import A;
struct myOtherStruct {
myStruct ms;
}

I now get an error in file A/c.d that a.a.myStruct conflicts 
with a.b.myStruct. Looks like these symbols are different for 
D. Is there a way to tell D that one is only a forward 
reference and is the same when D sees the struct declaration 
later?


They're different symbols because they're in different modules. 
The module and package name is part of the symbol name. Just 
import A.b in A.a.




Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-04-27 16:30:48 +, Adam D. Ruppe said:

This will never work in D. The module needs to work by itself. It can 
see public imports from another module it itself imports:


module A.c;

import A; // thanks to this, it can see a `public import A.a;` from the 
A package..



But without that explicit import, it cannot see anything outside 
itself. You might be able to get away with listing the `public import`s 
in package.d, and then just `import A;` in each individual module 
though.


One more problem now showing up, when I do this:

A/a.d
module A.a;
struct myStruct;

A/b.d
module A.b;
struct myStruct {...}

A/c.d
module A.c;
import A;
struct myOtherStruct {
myStruct ms;
}

I now get an error in file A/c.d that a.a.myStruct conflicts with 
a.b.myStruct. Looks like these symbols are different for D. Is there a 
way to tell D that one is only a forward reference and is the same when 
D sees the struct declaration later?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-04-27 16:30:48 +, Adam D. Ruppe said:

There is no "same level" really (except for the `package` protection 
level); it is just inside the module or outside the module for imports.


Hi Adamn, ok, got it. The docs are indicating that the "public import" 
is only working along the nested import chain. Maybe it's possible to 
make this much more clear? I don't know how to submit doc enhancements 
or a comment what should be enhanced.



But I see what you are doing now...


A/c.d
module A.c;
struct myOtherStruct {
myStruct ms;
}


This will never work in D. The module needs to work by itself. It can 
see public imports from another module it itself imports:


Aha, that was the missing link for me.


module A.c;

import A; // thanks to this, it can see a `public import A.a;` from the 
A package..



Ok, at least I can use such a simple full package import. Are there are 
any disadvantages when I just import everything?



But without that explicit import, it cannot see anything outside itself.


Ok.

You might be able to get away with listing the `public import`s in 
package.d, and then just `import A;` in each individual module though.


Yes, going to check that option.

But it won't just inherit stuff from other modules, like C's #include 
does. A D module is parsed independently of other modules.


Got it.


maybe dstep could automatically add imports to generated files too.


Going to submit an issue for this. Thanks for your answer, helps a lot.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Packages / imports & references between modules

2019-04-27 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 27 April 2019 at 16:24:40 UTC, Robert M. Münch wrote:
I thought that public only applies to the upward chain, not to 
the same level.


There is no "same level" really (except for the `package` 
protection level); it is just inside the module or outside the 
module for imports.


But I see what you are doing now...


A/c.d
module A.c;
struct myOtherStruct {
myStruct ms;
}


This will never work in D. The module needs to work by itself. It 
can see public imports from another module it itself imports:


module A.c;

import A; // thanks to this, it can see a `public import A.a;` 
from the A package..



But without that explicit import, it cannot see anything outside 
itself.



You might be able to get away with listing the `public import`s 
in package.d, and then just `import A;` in each individual module 
though.


But it won't just inherit stuff from other modules, like C's 
#include does. A D module is parsed independently of other 
modules.


works. But this would end up in adding a lot of imports to 
avoid the "undefined identifier" problem to many files manually 
and somehow break the DStep workflow.


maybe dstep could automatically add imports to generated files 
too.


Re: Packages / imports & references between modules

2019-04-27 Thread Robert M. Münch via Digitalmars-d-learn

On 2019-04-27 15:06:01 +, Adam D. Ruppe said:


On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:

import A.a;


`import` by itself is a private import, meaning it cannot be seen from 
outside the module.


Make it `public import` and it can be seen from the outside; the other 
modules importing it can access them too.


I thought that public only applies to the upward chain, not to the same level.

However, using public doens't help as there are still some undefined 
identifiers between modules on the same level. I think I need to 
elaborate on my case a bit more:


I use DStep to convert some C library headers. And these use forward 
references to structs.


A/a.d
module A.a;
struct myStruct;

A/b.d
module A.b;
struct myStruct {...}

A/c.d
module A.c;
struct myOtherStruct {
myStruct ms;
}

A/package.d
import A.a;
import A.b;
import A.c;

I get an "undefined identifier" error in A/c.d for myStruct. Changing A/c.d to:

A/c.d
module A.c;
import A.b;
struct myOtherStruct {
myStruct ms;
}

works. But this would end up in adding a lot of imports to avoid the 
"undefined identifier" problem to many files manually and somehow break 
the DStep workflow.


So, is there a way to avoid this? With public import it doesn't seem to work.

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Packages / imports & references between modules

2019-04-27 Thread Adam D. Ruppe via Digitalmars-d-learn

On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote:

import A.a;


`import` by itself is a private import, meaning it cannot be seen 
from outside the module.


Make it `public import` and it can be seen from the outside; the 
other modules importing it can access them too.


Packages / imports & references between modules

2019-04-27 Thread Robert M. Münch via Digitalmars-d-learn

A/a.d has  module A.a;
A/b.d has  module A.b;

A/package.d
import A.a;
import A.b;

A.b needs to access something from A.a

I assumed if I do

import package.d

that A.b sees the content of A.a now and doens't need an explicit line with

a/b.d
import A.a;

But this doesn't seem to be the case. Or am I missing something?

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: imports in a Separate File?

2018-12-11 Thread Ron Tarrant via Digitalmars-d-learn
On Tuesday, 11 December 2018 at 15:39:18 UTC, Steven 
Schveighoffer wrote:


Use public imports in your header file. This will pretend that 
the symbols imported reside in the module itself.


i.e. inside importedStuff.d:

public {
   // 120 import statements
}

-Steve


Thanks, Steve. Works like a charm... but you knew that.


Re: imports in a Separate File?

2018-12-11 Thread Steven Schveighoffer via Digitalmars-d-learn

On 12/11/18 10:27 AM, Ron Tarrant wrote:
I ran across a code example 
(https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/TestWindow/TestWindow.d) 
in which the first ~120 lines are mostly import statements.


And it got me wondering...

I tried to off-load a bunch of imports into a pseudo-header file — 
importedStuff.d — and then in the actual code file I just did:


import importedStuff;

but found myself swimming in undefined identifier errors.

Is there a way to do this so I wouldn't have to scroll 120 lines into a 
file before finding code? Or does this mean I still haven't caught onto 
what I was told the last time I was on this forum?


(And here's a grammar question, just for the heck of it: Why isn't forum 
spelled with an 'n,' like column?)




Use public imports in your header file. This will pretend that the 
symbols imported reside in the module itself.


i.e. inside importedStuff.d:

public {
   // 120 import statements
}

-Steve


imports in a Separate File?

2018-12-11 Thread Ron Tarrant via Digitalmars-d-learn
I ran across a code example 
(https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/TestWindow/TestWindow.d) in which the first ~120 lines are mostly import statements.


And it got me wondering...

I tried to off-load a bunch of imports into a pseudo-header file 
— importedStuff.d — and then in the actual code file I just did:


import importedStuff;

but found myself swimming in undefined identifier errors.

Is there a way to do this so I wouldn't have to scroll 120 lines 
into a file before finding code? Or does this mean I still 
haven't caught onto what I was told the last time I was on this 
forum?


(And here's a grammar question, just for the heck of it: Why 
isn't forum spelled with an 'n,' like column?)




Re: Imports and Subfolders and Links (Oh, My!)

2018-12-09 Thread Ron Tarrant via Digitalmars-d-learn

Thanks everyone.


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread Ron Tarrant via Digitalmars-d-learn

So, the upshot of it all seems to be that the -i's have it.


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread H. S. Teoh via Digitalmars-d-learn
On Fri, Dec 07, 2018 at 07:01:18PM +, Adam D. Ruppe via Digitalmars-d-learn 
wrote:
> On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote:
[...]
> > when I compile rather than compiling modules over and over
> > needlessly.
> 
> Oh, lots of us compile everything at once. It works quite well and is
> fast for many applications that you don't need to do anything more.

Yes, the D compiler is fast enough that for a small project, recompiling
everything vs. compile a single source file doesn't make a noticeable
difference in compilation time.

For larger projects, the general recommendation is to use the package as
your unit of recompilation, i.e., if you have your source tree structure
like this:

package1/
package1/mod1.d
package1/mod2.d
package2/
package2/mod1.d
package2/mod2.d

then when you recompile, if package1/* hasn't been touched, but
package2/mod2.d was changed, then recompile package2/* into a static
library, and relink your application.

The above example is greatly simplified, of course; generally, your
package subdirs would have 10+ source files or so before this sort of
per-package recompilation actually benefits compilation times.  In some
of my projects, where package subdirs are relatively small, I just lump
the source files inside together with everything else and just recompile
the whole thing at once.  IME, separately recompiling individual .d
files generally slows down compilation rather than speed it up -- the
linker has more work to do to resolve cross-references that the compiler
would have statically resolved had you passed all source files at once
instead.


> > Does D have the concept of makefiles? I haven't run across any
> > reference to such things so far.
> 
> Yes, you can use a makefile with D basically the same as with C. But
> you may find it actually builds slower than just dmd -i main.d

This is true for most small to medium-sized projects. For larger
projects, it does help to compile different packages separately (perhaps
in parallel if your build system supports that).

In my own projects, I actually use my build system more to resolve other
complex tasks than to individually compile D source files; I'd just
specify what amounts to `dmd *.d` in a single build rule, and most of
the rest of the build script is to handle other tasks, like generating
code from input data, preprocessing resource files, building/signing
packages, compiling code in other languages (Java, C, etc.),
installation to the staging area for testing, etc.. So ironically, most
of my build rules concern stuff other than compilation.  :-D


T

-- 
Stop staring at me like that! It's offens... no, you'll hurt your eyes!


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread Adam D. Ruppe via Digitalmars-d-learn

On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote:
Are you talking about a list of import statements here or is 
there another way/place I would list them?


On the dmd command line. So say your program has a.d and b.d, you 
would compile with `dmd a.d b.d`.


Or as you had some success with, the newer compilers let you just 
do `dmd -i a.d` and it finds the rest based on the import 
statements.



I'm not sure what you mean by 'library' in this statement.


For example, since you are using gtkd.lib, you don't have to 
include all of gtkd's source files. (The compiler needs to be 
able to FIND them, but you don't have to list them.)


If you were using a makefile, you may only list one file at a 
time to compile each separately, then link together all the 
generate .obj files as a separate step.


Just still trying to understand when it would be necessary to 
use a prefix and dot separator in an import statement.


The most practical answer is "always".

There's some exceptions that work for simple cases, but even then 
you put yourself at potential conflicts if some library author 
decided to pick the same name.


So you are really better off just always using some prefix and 
always listing the full name.


module myprojectname.mymodulename;

at the top of every file in your source tree. (Or you can use 
more dots if you want to further subdivide it, like 
"myprojectname.helper.whatever.mymodulename").


And when importing it, always list the full name, exactly the 
same as you listed it in the module definition.


import myprojectname.mymodulename;
import myprojectname.helper.whatever.mymodulename;


Every time you use it, from any location. Then it will work in 
all cases, whether compiling all at once (which I recommend btw), 
or using a makefile, or any other build system, even if you 
decide to bring in more libraries or your program grows beyond 
the super simple cases.


You can organize the subfolders based on those dot names (or do 
the dot names based on the subfolders if that is existing) and 
that will ease the process a bit more. But regardless of the 
folder layout and file locations, always use the full names and 
be sure they match in module and import statements.


when I compile rather than compiling modules over and over 
needlessly.


Oh, lots of us compile everything at once. It works quite well 
and is fast for many applications that you don't need to do 
anything more.


Does D have the concept of makefiles? I haven't run across any 
reference to such things so far.


Yes, you can use a makefile with D basically the same as with C. 
But you may find it actually builds slower than just dmd -i 
main.d


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread H. S. Teoh via Digitalmars-d-learn
On Sat, Dec 08, 2018 at 06:48:46AM +1300, rikki cattermole via 
Digitalmars-d-learn wrote:
> On 08/12/2018 6:41 AM, Ron Tarrant wrote:
> > Does D have the concept of makefiles? I haven't run across any
> > reference to such things so far.
> 
> Make isn't a D specification application (it doesn't really specialize
> in any language) dmd, druntime and Phobos are all built using it.
> 
> Though for user code, dub is the package+build manager that is more
> commonly used.

You can surely use Makefiles to compile your D code.  DMD, druntime, and
Phobos use Makefiles. :-D

Though due to limitations with makefiles, I prefer to use SCons. I'd use
dub as a package manager, but I find its limitations as a build manager
too frustrating and a total deal-breaker for the kind of builds I need
to do, so I generally avoid using it as such.


T

-- 
Prosperity breeds contempt, and poverty breeds consent. -- Suck.com


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread rikki cattermole via Digitalmars-d-learn

On 08/12/2018 6:41 AM, Ron Tarrant wrote:
Does D have the concept of makefiles? I haven't run across any reference 
to such things so far.


Make isn't a D specification application (it doesn't really specialize 
in any language) dmd, druntime and Phobos are all built using it.


Though for user code, dub is the package+build manager that is more 
commonly used.


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread Ron Tarrant via Digitalmars-d-learn

On Friday, 7 December 2018 at 16:43:02 UTC, Adam D. Ruppe wrote:
That's wrong: the import name and the module name should always 
match, in full, including all the dot parts.


So if you "import app.modulename;", the other file must have 
"module app.modulename;"


Okay. I guess the instructions I saw were for an earlier version 
of D... or I misunderstood. (either is likely?)


Moreover, you should either 1) list all modules in your 
application


Are you talking about a list of import statements here or is 
there another way/place I would list them?



not in a library on the command line,


I'm not sure what you mean by 'library' in this statement.

or 2) if using the newest compiler versions, pass the -i flag 
so the compiler will automatically include them for you.


I tried this and it worked.

Just still trying to understand when it would be necessary to use 
a prefix and dot separator in an import statement.


The bottom line here is, I have an application (Corkboard) I 
wrote in PHPGtk years ago and I'm learning D by transposing it. 
I'd like to maintain the code organization I had in the original 
— subfolders, etc. At the same time, I'd like to put my big-boy 
pants on and make it look like I know what I'm doing when I 
compile rather than compiling modules over and over needlessly.


Does D have the concept of makefiles? I haven't run across any 
reference to such things so far.


Re: Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread Adam D. Ruppe via Digitalmars-d-learn

On Friday, 7 December 2018 at 16:39:34 UTC, Ron Tarrant wrote:

import subfolder.ModuleName;

And in the module files, the first statement is:

module ModuleName;


That's wrong: the import name and the module name should always 
match, in full, including all the dot parts.


So if you "import app.modulename;", the other file must have 
"module app.modulename;"



dmd -m64 -Lgtkd.lib main.d


Moreover, you should either 1) list all modules in your 
application not in a library on the command line, or 2) if using 
the newest compiler versions, pass the -i flag so the compiler 
will automatically include them for you.




Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread Ron Tarrant via Digitalmars-d-learn

Trying to wrap my brain around imports, etc.

In various places around the Internet, I've read that if I have 
modules in a subfolder/subdirectory, my import statement would 
look like this:


import subfolder.ModuleName;

And in the module files, the first statement is:

module ModuleName;

However, I'm having trouble getting past the compile errors.

Scenario:
current folder contains - main.d

In main.d, the import statements:
import app.CountryTreeView
import app.CountryListStore

In the subfolder (named: app) I have two module files:
 - CountryTreeView.d (module CountryTreeView)
 - CountryListStore.d (module CountryListStore)

When I compile using:

dmd -m64 -Lgtkd.lib main.d

I get a bunch of unresolved external symbol errors for classes 
and modules. The import statements in main.d don't import 
anything from the subfolder.


Removing 'app.' from the import statements and compiling with:

dmd -m64 -Lgktd.lib main.d -Iapp CountryListStore CountryTreeView

it works.

Two questions:
1) Under what circumstances would I prefix the folder/directory 
name in a statement importing modules I've built myself?

2) What would the dmd compile command look like?




Re: public imports

2018-12-05 Thread Sjoerd Nijboer via Digitalmars-d-learn

On Wednesday, 5 December 2018 at 23:18:49 UTC, H. S. Teoh wrote:
Maybe if you described to us exactly what you want to do, we 
could find a way to do it that doesn't involve language holes 
that are not guaranteed to work?


Honestly I don't know.
I was just messing around.
My initial question was, is this a bug or a feature.
For which I got an answer.



Re: public imports

2018-12-05 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Dec 05, 2018 at 10:57:37PM +, Sjoerd Nijboer via 
Digitalmars-d-learn wrote:
[...]
> I was trying to get some form of persistant import outside of the
> function/template scope in the module scope, depending on the
> parameters of the function or template.  I hoped I could find
> something funny or maybe some usefull trick.  Unfortunately I couldn't
> :/
[...]


Maybe if you described to us exactly what you want to do, we could find
a way to do it that doesn't involve language holes that are not
guaranteed to work?


T

-- 
Spaghetti code may be tangly, but lasagna code is just cheesy.


Re: public imports

2018-12-05 Thread Sjoerd Nijboer via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 21:21:12 UTC, Adam D. Ruppe 
wrote:
Looks intended. It doesn't really make sense to have a public 
import inside a function.


I was trying to find a weird corner of the language and maybe do 
something funny with conditional imports.
They don't work in functions, however public imports do work in 
templates, but act as imports that are only visible in that scope.


I was trying to get some form of persistant import outside of the 
function/template scope in the module scope, depending on the 
parameters of the function or template.

I hoped I could find something funny or maybe some usefull trick.
Unfortunately I couldn't :/




Re: public imports

2018-12-05 Thread Paul Backus via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 21:13:29 UTC, Sjoerd Nijboer 
wrote:

A small question.
Is it intended behaviour that public imports inside function 
calls fail with the message "Error: found public instead of 
statement", or is it an underdocumented feature?


void foo()
{
public import bar;
}


An import statment inside a function is already limited to that 
function's scope, so making it public doesn't really make sense.


That said, the language specification [1] doesn't say anything 
about this kind of import being an error, so it's definitely 
underdocumented. The error message is also not as good as it 
could be.


[1] https://dlang.org/spec/module.html#scoped_imports


Re: public imports

2018-12-05 Thread Adam D. Ruppe via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 21:13:29 UTC, Sjoerd Nijboer 
wrote:

A small question.
Is it intended behaviour that public imports inside function 
calls fail with the message "Error: found public instead of 
statement", or is it an underdocumented feature?


Looks intended. It doesn't really make sense to have a public 
import inside a function.


public imports

2018-12-05 Thread Sjoerd Nijboer via Digitalmars-d-learn

A small question.
Is it intended behaviour that public imports inside function 
calls fail with the message "Error: found public instead of 
statement", or is it an underdocumented feature?


void foo()
{
public import bar;
}


Re: Linker error for core.sys.windows.winuser imports when compiling as 64 bit.

2018-07-01 Thread Chris M. via Digitalmars-d-learn

On Sunday, 1 July 2018 at 01:16:59 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 00:42:30 spikespaz via 
Digitalmars-d-learn wrote:
Hey guys, I'm getting a linker error when compiling with DMD 
`-m63` that I don't get as 23 bit.


I'm importing `ShowWindow` from `core.sys.windows.winuser`, 
and I get the following:


C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: 
undefined

symbol: ShowWindow
error: link failed
Error: linker exited with status 1

My compiler command is `dmd main.d -m64 -i -O -release -inline
-boundscheck=off
`.

I don't think the source code would make a difference other 
than to say that I'm calling `ShowWindow`.


Any help would be much appreciated. Thanks!


Well, per the MSDN page, that symbol is in User32.lib, so make 
sure that you're linking against it - though why it would link 
against it with 32-bit and not 64-bit, I don't know.


- Jonathan M Davis


Check to make sure it's actually defined in user32.lib. I'm 
having a similar issue and would love to know why these functions 
are apparently not being defined


https://forum.dlang.org/thread/ncarbitntjeobljra...@forum.dlang.org


Re: Linker error for core.sys.windows.winuser imports when compiling as 64 bit.

2018-06-30 Thread Jonathan M Davis via Digitalmars-d-learn
On Sunday, July 01, 2018 00:42:30 spikespaz via Digitalmars-d-learn wrote:
> Hey guys, I'm getting a linker error when compiling with DMD
> `-m63` that I don't get as 23 bit.
>
> I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I
> get the following:
>
> C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: undefined
> symbol: ShowWindow
> error: link failed
> Error: linker exited with status 1
>
> My compiler command is `dmd main.d -m64 -i -O -release -inline
> -boundscheck=off
> `.
>
> I don't think the source code would make a difference other than
> to say that I'm calling `ShowWindow`.
>
> Any help would be much appreciated. Thanks!

Well, per the MSDN page, that symbol is in User32.lib, so make sure that
you're linking against it - though why it would link against it with 32-bit
and not 64-bit, I don't know.

> Also, how does formatting work? Markdown doesn't seem to work, or
> HTML.

For the web forum you mean? It's just a web client for the newsgroups that
we use, and many folks interact with it as a newsgroup or via the mailing
list interface rather than through forum.dlang.org. So, it's expected that
everything will be in plain text.

- Jonathan M Davis



Linker error for core.sys.windows.winuser imports when compiling as 64 bit.

2018-06-30 Thread spikespaz via Digitalmars-d-learn
Hey guys, I'm getting a linker error when compiling with DMD 
`-m63` that I don't get as 23 bit.


I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I 
get the following:


C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: undefined 
symbol: ShowWindow

error: link failed
Error: linker exited with status 1

My compiler command is `dmd main.d -m64 -i -O -release -inline 
-boundscheck=off

`.

I don't think the source code would make a difference other than 
to say that I'm calling `ShowWindow`.


Any help would be much appreciated. Thanks!

Also, how does formatting work? Markdown doesn't seem to work, or 
HTML.


Re: errnoEnforce: which imports?

2018-06-29 Thread kdevel via Digitalmars-d-learn

On Friday, 29 June 2018 at 09:22:03 UTC, Jonathan M Davis wrote:

Shall I create a bug report?


Yes. Aside from someone trying it out and complaining about it, 
it probably wouldn't be noticed or fixed, since it's one of the 
few tests that doesn't work as a ddoc-ed unit test.


Issue 19041 - errnoEnforce: example does not compile


Re: errnoEnforce: which imports?

2018-06-29 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, June 29, 2018 09:08:40 kdevel via Digitalmars-d-learn wrote:
> On Friday, 29 June 2018 at 02:28:04 UTC, Jonathan M Davis wrote:
> > [...] really, that example needs to be completely redone.
>
> Shall I create a bug report?

Yes. Aside from someone trying it out and complaining about it, it probably
wouldn't be noticed or fixed, since it's one of the few tests that doesn't
work as a ddoc-ed unit test.

- Jonathan M Davis



Re: errnoEnforce: which imports?

2018-06-29 Thread kdevel via Digitalmars-d-learn

On Friday, 29 June 2018 at 02:28:04 UTC, Jonathan M Davis wrote:

[...] really, that example needs to be completely redone.


Shall I create a bug report?


Re: errnoEnforce: which imports?

2018-06-28 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, June 29, 2018 01:25:39 kdevel via Digitalmars-d-learn wrote:
> In https://dlang.org/phobos/std_exception.html#errnoEnforce this
> example is shown:
>
> ---
> auto f = errnoEnforce(fopen("data.txt"));
> auto line = readln(f);
> enforce(line.length); // expect a non-empty line
> ---
>
> I added
>
> import std.stdio;
> import std.exception;
>
> and get an error message which reminds me of C++:
>
> zz.d(8): Deprecation: std.stdio.fopen(R1, R2)(R1 name, R2 mode =
> "r") if ((isInputRange!R1 && isSomeChar!(ElementEncodingType!R1)
>
> || isSomeString!R1) && (isInputRange!R2 &&
>
> isSomeChar!(ElementEncodingType!R2) || isSomeString!R2)) is not
> visible from module zz
> zz.d(8): Error: function std.stdio.fopen!(string, string).fopen
> is not accessible from module zz
> zz.d(9): Error: template std.stdio.readln cannot deduce function
> from argument types !()(shared(_IO_FILE)*), candidates are:
> [...]/dmd2/linux/bin64/../../src/phobos/std/stdio.d(4068):
> std.stdio.readln(S = string)(dchar terminator = '\x0a') if
> (isSomeString!S)
> [...]/dmd2/linux/bin64/../../src/phobos/std/stdio.d(4102):
> std.stdio.readln(C)(ref C[] buf, dchar terminator = '\x0a') if
> (isSomeChar!C && is(Unqual!C == C) && !is(C == enum))
> [...]/dmd2/linux/bin64/../../src/phobos/std/stdio.d(4109):
> std.stdio.readln(C, R)(ref C[] buf, R terminator) if
> (isSomeChar!C && is(Unqual!C == C) && !is(C == enum) &&
> isBidirectionalRange!R && is(typeof(terminator.front ==
> (dchar).init)))
> make: *** [zz.o] Error 1
>
> What's wrong here?

It looks like that example is using a private function from std.stdio which
wraps core.stdc.stdio.fopen. It also passes a FILE* to readln, which is
completely wrong. readln as a free function works with std.stdio.stdin and
does not accept a FILE*, whereas readln on std.stdio.File obviously operates
on File, since it's a member function on File. You could use
core.stdc.stdio.fopen to get a FILE and pass it to File's constructor, and
then call readln on the file, but really, that example needs to be
completely redone.

The error message for fopen stems from the fact that it's private, and that
message is longer than it would be otherwise because of an import bug that
was previously fixed but generates a deprecation message for now so as not
to immediately break code. The error messages after that have to do with the
compiler showing you the various overloads of readln that don't match FILE*.

- Jonathan M Davis



errnoEnforce: which imports?

2018-06-28 Thread kdevel via Digitalmars-d-learn
In https://dlang.org/phobos/std_exception.html#errnoEnforce this 
example is shown:


---
auto f = errnoEnforce(fopen("data.txt"));
auto line = readln(f);
enforce(line.length); // expect a non-empty line
---

I added

   import std.stdio;
   import std.exception;

and get an error message which reminds me of C++:

zz.d(8): Deprecation: std.stdio.fopen(R1, R2)(R1 name, R2 mode = 
"r") if ((isInputRange!R1 && isSomeChar!(ElementEncodingType!R1) 
|| isSomeString!R1) && (isInputRange!R2 && 
isSomeChar!(ElementEncodingType!R2) || isSomeString!R2)) is not 
visible from module zz
zz.d(8): Error: function std.stdio.fopen!(string, string).fopen 
is not accessible from module zz
zz.d(9): Error: template std.stdio.readln cannot deduce function 
from argument types !()(shared(_IO_FILE)*), candidates are:
[...]/dmd2/linux/bin64/../../src/phobos/std/stdio.d(4068):
std.stdio.readln(S = string)(dchar terminator = '\x0a') if 
(isSomeString!S)
[...]/dmd2/linux/bin64/../../src/phobos/std/stdio.d(4102):
std.stdio.readln(C)(ref C[] buf, dchar terminator = '\x0a') if 
(isSomeChar!C && is(Unqual!C == C) && !is(C == enum))
[...]/dmd2/linux/bin64/../../src/phobos/std/stdio.d(4109):
std.stdio.readln(C, R)(ref C[] buf, R terminator) if 
(isSomeChar!C && is(Unqual!C == C) && !is(C == enum) && 
isBidirectionalRange!R && is(typeof(terminator.front == 
(dchar).init)))

make: *** [zz.o] Error 1

What's wrong here?


Re: Is it bad form to put code in package.d other than imports?

2018-01-03 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jan 03, 2018 at 12:43:52AM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn 
> wrote:
> > I've only understood that imports should go in package.d. I'm seeing
> > more and more packages on code.dlang.org using it for the packages
> > primary code. Is this alright? As far as I can tell it's just bad
> > form. It would be nice to have one of the maintainers higher up the
> > food chain comment on this!
[...]
> In terms of functionality, there really isn't much special about
> package.d.  If there were, we probably wouldn't have been able to talk
> Walter into it.  We were able to precisely because public imports
> already worked in a way that allowed package.d to work. We just needed
> the feature to be added to make it possible to import a package. So,
> package.d allows that, but beyond that, it's just a normal module. It
> typically containts public imports for the rest of the package, but it
> doesn't have to, and it can contain whatever code you want to put in
> there. You can do whatever you want with it, though really, using it
> for much of anything at all beyond splitting up a package in place is
> beyond the scope of why it was introduced. But ultimately, there's
> nothing really special about package.d, and different folks have
> different ideas about it and how it should be used.
[...]

I personally have used package.d to put declarations that are common to
a particular package, e.g., package-global enums, constants, that sort
of thing. This is particular the case when the package's submodules
aren't usually directly imported by outside code, in which case I tend
to think of package.d as the "baseline, common declarations", and if
outside code demands, it can import a more specific submodule that
exposes a more specific API for that package.

As Jonathan said, you can use package.d pretty much for whatever you
want.


T

-- 
Claiming that your operating system is the best in the world because more 
people use it is like saying McDonalds makes the best food in the world. -- 
Carl B. Constantine


Re: Is it bad form to put code in package.d other than imports?

2018-01-03 Thread Soulsbane via Digitalmars-d-learn
On Wednesday, 3 January 2018 at 07:43:52 UTC, Jonathan M Davis 
wrote:
On Wednesday, January 03, 2018 06:10:10 Soulsbane via 
Digitalmars-d-learn wrote:

[...]


The entire reason that the package.d feature was added was so 
that it would be possible to split a module into a package 
without breaking code. Anything beyond that was beyond the 
scope of the purpose of the feature, albeit not necessarily in 
conflict with its original purpose.


[...]


Wow! Thanks Johnathan for the thorough explanation!


Re: Is it bad form to put code in package.d other than imports?

2018-01-02 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn 
wrote:
> I've only understood that imports should go in package.d. I'm
> seeing more and more packages on code.dlang.org using it for the
> packages primary code. Is this alright? As far as I can tell it's
> just bad form. It would be nice to have one of the maintainers
> higher up the food chain comment on this!
>
> Thanks!

The entire reason that the package.d feature was added was so that it would
be possible to split a module into a package without breaking code. Anything
beyond that was beyond the scope of the purpose of the feature, albeit not
necessarily in conflict with its original purpose.

For better or worse, a number of folks like being able to just import an
entire package at once using it, so it's not uncommon for folks to set it up
to do that, though personally, I'm not a fan of that.

All Phobos has done with package.d thus far is split modules into packages,
not add it for importing packages that already exist. As for leaving code in
package.d, the only package in Phobos that I'm aware of doing that on a
permanent basis is std.range, and I have no idea why that was done. When
std.algorithm and std.container were split, package.d was used for
documentation purposes (which makes a lot of sense), but there's no real
code in there. std.datetime's package.d has some now-deprecated
functionality that was left in there rather than being put in a module when
std.datetime was split, because there was no point in putting it in a
module. In the long run though, all of that will be gone from std.datetime's
package.d, and it too will only be used for documentation. I have no idea
what folks have been doing on code.dlang.org.

In terms of functionality, there really isn't much special about package.d.
If there were, we probably wouldn't have been able to talk Walter into it.
We were able to precisely because public imports already worked in a way
that allowed package.d to work. We just needed the feature to be added to
make it possible to import a package. So, package.d allows that, but beyond
that, it's just a normal module. It typically containts public imports for
the rest of the package, but it doesn't have to, and it can contain whatever
code you want to put in there. You can do whatever you want with it, though
really, using it for much of anything at all beyond splitting up a package
in place is beyond the scope of why it was introduced. But ultimately,
there's nothing really special about package.d, and different folks have
different ideas about it and how it should be used.

Personally, I don't think that it's very clean to be putting stuff other
than documentation in package.d, and I don't really like the idea of setting
it up to import the entire package under normal circumstances; I see it
simply as a way to split up a module in place without breaking code, but
that's just how I feel about it. I don't know that there are much in the way
of objective arguments about package.d and how it should be used.

However, at this point, the trend in best practices is towards using scoped,
selective imports as much as possible (since that reduces compilation times
and more closely associates the imports with what's using them), and that
pretty much flies in the face of the idea of importing an entire package at
once. You _can_ use selective imports and package.d together, but it also
makes the compiler do more work than if you just selectively imported from
the module that the symbol is actually in. And if you're putting code
directly in package.d, then it's not possible to import just that module
unless it doesn't have any public imports in it. So, from a flexibility
standpoint, it makes more sense to avoid putting symbols directly in
package.d.

However, AFAIK, there really isn't much in the way of best practices with
regards to package.d. All Phobos has done with it has been to split modules
into packages like it was originally intended, and beyond that, folks have
kind of done whatever they want. You may find a bunch of people agreeing
with you that folks shouldn't be putting normal code in package.d, but
AFAIK, there's no real general agreement on the matter one way or the other.
There isn't really even agreement about whether package.d should be used
when it isn't needed (and it's pretty much only needed when splitting up a
module in-place).

- Jonathan M Davis



Is it bad form to put code in package.d other than imports?

2018-01-02 Thread Soulsbane via Digitalmars-d-learn
I've only understood that imports should go in package.d. I'm 
seeing more and more packages on code.dlang.org using it for the 
packages primary code. Is this alright? As far as I can tell it's 
just bad form. It would be nice to have one of the maintainers 
higher up the food chain comment on this!


Thanks!


Re: Private imports and Objects

2017-11-30 Thread Patrick Schluter via Digitalmars-d-learn
On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis 
wrote:
Object exists primarily because D didn't originally have 
templates, and when you don't have templates, having a single 
base class is the only way to have a function accept any class, 
and for something like a container, you'd pretty much be forced 
to use void* without Object if you don't have templates. 
However, once templates were added to D, the benefits of Object 
were significantly reduced, and it's arguably not a 
particularly good idea to be writing code that operates on 
Object. However, it's far too late in the game to get rid of 
Object.


And they come in very handy when one ports code from Java. As a 
first approach a simple 1 to 1 adaptation of the code makes the 
porting so much easier. Templates and D magic can come afterwards.





Re: Private imports and Objects

2017-11-30 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, November 30, 2017 10:54:44 helxi via Digitalmars-d-learn wrote:
> On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, November 30, 2017 06:29:43 helxi via
>
> > Digitalmars-d-learn wrote:
> []
>
> > I don't understand the question. You're asking whether casting
> > from a base class to a derived class creates overhead? Or are
> > you asking whether having a base class for all classes creates
> > overhead? Or something else?
> >
> > Object exists primarily because D didn't originally have
> > templates, and when you don't have templates, having a single
> > base class is the only way to have a function accept any class,
> > and for something like a container, you'd pretty much be forced
> > to use void* without Object if you don't have templates.
> > However, once templates were added to D, the benefits of Object
> > were significantly reduced, and it's arguably not a
> > particularly good idea to be writing code that operates on
> > Object. However, it's far too late in the game to get rid of
> > Object.
> >
> > At one point, it was decided to remove Object's member
> > functions, because having them on Object needlessly locks in a
> > particular set of attributes for those functions, and if we did
> > that, then there really wouldn't be much reason to use Object
> > directly, but that change has never happened, and it's not
> > clear that it's going to happen, since there are a number of
> > technical issues that make it a bit of a pain to do
> > (particularly if we don't want to break a lot of code). One of
> > the bigger issues is that the AA implementation in druntime
> > needs to be templated so that it doesn't need to operate on
> > Object, and that's proven to be a bit of a challenge.
> >
> > https://issues.dlang.org/show_bug.cgi?id=9769
> > https://issues.dlang.org/show_bug.cgi?id=9770
> > https://issues.dlang.org/show_bug.cgi?id=9771
> > https://issues.dlang.org/show_bug.cgi?id=9772
> >
> > - Jonathan M Davis
>
> I was actually referring to both. Override functions such as
> opCmp, opEquals, toString, toHash etc --wouldn't they be
> inherently expensive? I thought they are virtual functions. Also,
> with regards to casting, wouldn't this be an extra legwork? Both
> of these seem to be a performance handicap to me. But I'm no
> expert on this matter. Maybe the compiler optimises it away since
> normally you'd cast to a constant subclass.

Virtual functions do have a cost but not a huge one, and to a point, they're
kind of the whole point of classes. If you don't need inheritance, then use
a struct. D separates structs and classes so that classes have inheritance
and are always reference types (like in Java), whereas structs don't have
inheritance. Classes in D cost about what they would cost in C++ or Java.
Unlike C++, they do have an invisible monitor member to enable synchronized
to work, and public member functions are virtual by default, but in general,
calling a function on a class in D costs what it would to call a virtual
function in C++ - and if you don't need virtual functions, then why use a
class? You can mark individual member functions as final to devirtualize
them (assuming that they're not overriding a base class member), but if you
don't need any virtual functions, then you don't need inheritance, and you
don't need a class.

As for casting, I don't know what the concern is. You typically construct a
class object and then either reference it through a class reference of its
actual type or through a class reference of a base type, just like you would
in C++, Java, C#, etc. You don't typically need explicit casting, and
implicit casting is only going to happen if you assign the object to another
reference of a base type of the current reference. Casting class objects
shouldn't be any more expensive in D than it is in other languages.

Having Object exist doesn't really affect much of any of this. It just
provides a common base class. The functions that are on it don't need to be
there, and if we were doing things from scratch, they certainly wouldn't be,
but it doesn't make functions or casting more expensive. Any extra cost
that's there is inherent to inheritance in general, and that's the whole
reason that classes exist.

- Jonathan M Davis



Re: Private imports and Objects

2017-11-30 Thread helxi via Digitalmars-d-learn
On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis 
wrote:
On Thursday, November 30, 2017 06:29:43 helxi via 
Digitalmars-d-learn wrote:

[]
I don't understand the question. You're asking whether casting 
from a base class to a derived class creates overhead? Or are 
you asking whether having a base class for all classes creates 
overhead? Or something else?


Object exists primarily because D didn't originally have 
templates, and when you don't have templates, having a single 
base class is the only way to have a function accept any class, 
and for something like a container, you'd pretty much be forced 
to use void* without Object if you don't have templates. 
However, once templates were added to D, the benefits of Object 
were significantly reduced, and it's arguably not a 
particularly good idea to be writing code that operates on 
Object. However, it's far too late in the game to get rid of 
Object.


At one point, it was decided to remove Object's member 
functions, because having them on Object needlessly locks in a 
particular set of attributes for those functions, and if we did 
that, then there really wouldn't be much reason to use Object 
directly, but that change has never happened, and it's not 
clear that it's going to happen, since there are a number of 
technical issues that make it a bit of a pain to do 
(particularly if we don't want to break a lot of code). One of 
the bigger issues is that the AA implementation in druntime 
needs to be templated so that it doesn't need to operate on 
Object, and that's proven to be a bit of a challenge.


https://issues.dlang.org/show_bug.cgi?id=9769 
https://issues.dlang.org/show_bug.cgi?id=9770 
https://issues.dlang.org/show_bug.cgi?id=9771 
https://issues.dlang.org/show_bug.cgi?id=9772


- Jonathan M Davis


I was actually referring to both. Override functions such as 
opCmp, opEquals, toString, toHash etc --wouldn't they be 
inherently expensive? I thought they are virtual functions. Also, 
with regards to casting, wouldn't this be an extra legwork? Both 
of these seem to be a performance handicap to me. But I'm no 
expert on this matter. Maybe the compiler optimises it away since 
normally you'd cast to a constant subclass.


Re: Private imports and Objects

2017-11-29 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, November 30, 2017 06:29:43 helxi via Digitalmars-d-learn wrote:
> 1. Why are imports visible from outside the package when you do
> selective imports?
>
> //mod.d
> module mod;
>
> import std.stdio : writeln;
>
> public void greet()
> {
>  writeln("Hello");
> }
>
>
> //app.d
> import mod;
>
> void main()
> {
>   mod.greet();
>   writeln("You should not be seeing this.");
>
> }
>
> Compiles just fine and prints "You should not be seeing this."
> just fine with `$dub build`. Even if I use package imports the
> result stays the same.

If you use a version of dmd that's at least semi-recent, you should see a
deprecation message. It works due to a long standing bug that has been
fixed, but when it was fixed, a number of aspects of imports were
overhauled, and it was decided to phase in the new behavior to minimize code
breakage, and as such, it should be printing a deprecation message at the
moment, whereas in the future, it will become an error like it should be.

> 2. Classes that do not inherit (base classes) actually inherit
> from 'Object`. For which, often times one converts the Object to
> its subclasses. What's the rationale behind this?
> Isn't this going to add overhead?

I don't understand the question. You're asking whether casting from a base
class to a derived class creates overhead? Or are you asking whether having
a base class for all classes creates overhead? Or something else?

Object exists primarily because D didn't originally have templates, and when
you don't have templates, having a single base class is the only way to have
a function accept any class, and for something like a container, you'd
pretty much be forced to use void* without Object if you don't have
templates. However, once templates were added to D, the benefits of Object
were significantly reduced, and it's arguably not a particularly good idea
to be writing code that operates on Object. However, it's far too late in
the game to get rid of Object.

At one point, it was decided to remove Object's member functions, because
having them on Object needlessly locks in a particular set of attributes for
those functions, and if we did that, then there really wouldn't be much
reason to use Object directly, but that change has never happened, and it's
not clear that it's going to happen, since there are a number of technical
issues that make it a bit of a pain to do (particularly if we don't want to
break a lot of code). One of the bigger issues is that the AA implementation
in druntime needs to be templated so that it doesn't need to operate on
Object, and that's proven to be a bit of a challenge.

https://issues.dlang.org/show_bug.cgi?id=9769
https://issues.dlang.org/show_bug.cgi?id=9770
https://issues.dlang.org/show_bug.cgi?id=9771
https://issues.dlang.org/show_bug.cgi?id=9772

- Jonathan M Davis



Private imports and Objects

2017-11-29 Thread helxi via Digitalmars-d-learn
1. Why are imports visible from outside the package when you do 
selective imports?


//mod.d
module mod;

import std.stdio : writeln;

public void greet()
{
writeln("Hello");
}


//app.d
import mod;

void main()
{
mod.greet();
writeln("You should not be seeing this.");

}

Compiles just fine and prints "You should not be seeing this." 
just fine with `$dub build`. Even if I use package imports the 
result stays the same.


2. Classes that do not inherit (base classes) actually inherit 
from 'Object`. For which, often times one converts the Object to 
its subclasses. What's the rationale behind this?

Isn't this going to add overhead?




Re: Imports

2017-10-05 Thread Ali Çehreli via Digitalmars-d-learn

On 10/05/2017 03:34 PM, Jiyan wrote:

> PS: is it spam to say thank you?

Thank you for asking! :p

I used to have strong feelings about this in the past. I still think 
it's spam; I don't expect any thanks from anyone and I think gratitude 
should be  implied.


Some people have different opinions: They say it makes them happy to see 
an explicit gratitude.


I don't care anymore especially because it's not very common anyway.

Ali



Re: Imports

2017-10-05 Thread Jiyan via Digitalmars-d-learn

On Thursday, 5 October 2017 at 12:35:26 UTC, Mike Parker wrote:

On Thursday, 5 October 2017 at 12:25:27 UTC, Mike Parker wrote:


[...]


Right. I had to go back and look at what I wrote in Learning D, 
which is the last (and only) time I played around with the 
default module behavior. I always use module statements (and 
you should too).


[...]


Thank you :)

PS: is it spam to say thank you?


Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 5 October 2017 at 12:25:27 UTC, Mike Parker wrote:



And actually, now that I think about it, this is probably one 
of those situations where the defualt fails. So yes, you'll 
need a module name.


Right. I had to go back and look at what I wrote in Learning D, 
which is the last (and only) time I played around with the 
default module behavior. I always use module statements (and you 
should too).


When you import dir.sub and the compiler finds it's missing in 
its imported module list, it will look in for the `dir/sub.d` 
from the current working directory. If it doesn't find it, you 
get an import error. If you do this:


dmd main.d ../dir/sub.d

Then sub.d can have any module statement you want -- you could do 
this:


module this.is.the.sub.module;

And it wouldn't matter, as long as main.d imported 
this.is.the.sub.module and not dir.sub. However, if sub.d has no 
module statement, the compiler isn't going to infer a package. 
It's going to be in the default package, so it's simply `sub` and 
not `dir.sub`. If you import dir.sub, the compiler will still 
look for a subdirectory named `dir`, but it won't find it.


This latter bit is your issue. dub is passing dir/sub.d to the 
compiler, but without a module statement the compiler treats it 
simply as `sub` and your `dir.sub` import fails.


Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 5 October 2017 at 12:18:57 UTC, Mike Parker wrote:

Regardless, every module should have a module name at the top. 
There are situations where the inferred package & module names 
can't work.


Ugh. Sorry, I mean for sourcePaths you have to pass `src` and 
not `dir`.


And actually, now that I think about it, this is probably one of 
those situations where the defualt fails. So yes, you'll need a 
module name.


Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 5 October 2017 at 12:17:23 UTC, Mike Parker wrote:

On Thursday, 5 October 2017 at 11:44:00 UTC, Jiyan wrote:

[...]


But as i see it with sourcePaths the directories are not 
influencing
the module names(in the directories except "source"), so 
"dir.sub"
will just have the name "sub" is there a way around that, 
except

naming every module like:

module dir.sub;


You have to pass the parent directory of dir rather than dir 
itself, e.g.:


- src
-- dir
--- sub.d

dmd -Isrc

Regardless, every module should have a module name at the top. 
There are situations where the inferred package & module names 
can't work.


Ugh. Sorry, I mean for sourcePaths you have to pass `src` and not 
`dir`.


Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn

On Thursday, 5 October 2017 at 11:44:00 UTC, Jiyan wrote:

[...]


But as i see it with sourcePaths the directories are not 
influencing
the module names(in the directories except "source"), so 
"dir.sub"

will just have the name "sub" is there a way around that, except
naming every module like:

module dir.sub;


You have to pass the parent directory of dir rather than dir 
itself, e.g.:


- src
-- dir
--- sub.d

dmd -Isrc

Regardless, every module should have a module name at the top. 
There are situations where the inferred package & module names 
can't work.


Re: Imports

2017-10-05 Thread Jiyan via Digitalmars-d-learn

On Thursday, 5 October 2017 at 00:28:32 UTC, Mike Parker wrote:

On Wednesday, 4 October 2017 at 16:31:35 UTC, Jiyan wrote:

[...]



If you have this directory tree:

- mylib
-- pack1
--- a.d
--- b.d
 pack2
- c.d

[...]


Thank you, i think i kinda got that :)

But as i see it with sourcePaths the directories are not 
influencing

the module names(in the directories except "source"), so "dir.sub"
will just have the name "sub" is there a way around that, except
naming every module like:

module dir.sub;


Re: Imports

2017-10-04 Thread Mike Parker via Digitalmars-d-learn

On Wednesday, 4 October 2017 at 16:31:35 UTC, Jiyan wrote:

Hey,

as i see it the -Ipath command for dmd just imports the files 
within a directory but it doesnt work for sub directories, so i 
can write something like:


import subdirectoryFromPath.file;

Also with dub this doesnt seem possible (sourcePaths seems to 
work as the -I command).


Is there a way to do what i want? Or am i doing something wrong?



If you have this directory tree:

- mylib
-- pack1
--- a.d
--- b.d
 pack2
- c.d

Then you would pass -Imylib to the compiler. In your code, you 
can write the following:


import pack1.a;
import pack1.pack2.c;

You don't import files or directories, just packages and modules. 
By default, package names correspond to directory names and 
module names correspond to file names, but they don't have to 
(it's best practice, though).


And by the way what is the difference from sourcePaths to 
importPaths?


sourcePaths where DUB can find additional files, outside of the 
default source directory, to pass to the compiler for 
compilation. importPaths will all be passed to the compile as -I. 
It seems you think that importing a module causes its source file 
to be automatically compiled. That doesn't happen.


imports are strictly for the compiler to know which symbols are 
available for the current module to use. It does not attempt to 
compile imported modules. Imported modules might be part of your 
program or they might be part of a precompiled library. In the 
latter case, they don't need to be compiled because they already 
are. So the compiler leaves it up to you to decide which modules 
need to be compiled.


Dub, by default, will make sure all modules in your source 
directory are compiled. It will also guarantee the compiler knows 
where to find them for imports. Sometimes, you might also want to 
import files from a library that isn't available from 
code.dlang.org. You can use importPaths to tell dub additional 
paths to give the compiler. If those files are part of a 
precompiled library you can link the library and you're done. If 
they aren't, you can use sourcePaths to tell DUB that all the 
source modules in the additional paths also need to be passed to 
the compiler for compiling and linking into the final executable.


Imports

2017-10-04 Thread Jiyan via Digitalmars-d-learn

Hey,

as i see it the -Ipath command for dmd just imports the files 
within a directory but it doesnt work for sub directories, so i 
can write something like:


import subdirectoryFromPath.file;

Also with dub this doesnt seem possible (sourcePaths seems to 
work as the -I command).


Is there a way to do what i want? Or am i doing something wrong?
And by the way what is the difference from sourcePaths to 
importPaths?




Re: Template mixins and selective imports

2017-08-03 Thread jmh530 via Digitalmars-d-learn

On Thursday, 3 August 2017 at 19:05:47 UTC, Meta wrote:

On Thursday, 3 August 2017 at 19:03:55 UTC, Meta wrote:

`mixin vectorize!sin vsin; alias sin = vsin;` and see if it


Should be `alias sin = vsin.sin;`


Thanks, this pointed me in the right direction. I got the line 
below working.


mixin vectorize!sin temp;
alias vsin = temp.sin;
auto z = vsin(x);

I couldn't give it the name of sin or the name of the identifier.

This is a little ugly and would require the user to make the 
adjustment themselves.


Below seems to work if the user doesn't import the relevant 
function, though it will still result in errors if they 
selectively import that function. I think the combination of the 
two will be sufficient.



private enum _vectorizeAlt(string mod, string func) = "
auto " ~ func ~ "(SliceKind kind, size_t[] packs, Iterator)
   (Slice!(kind, packs, 
Iterator) slice)

{
import mir.ndslice.topology : map;
return slice.map!(" ~ mod ~ "." ~ func ~ ");
}
";

mixin template vectorizeAlt(string mod, string func)
{
mixin("static import " ~ mod ~ ";");
import mir.ndslice.slice : SliceKind, Slice;

mixin(_vectorizeAlt!(mod, func));
}

unittest
{
import std.stdio : writeln;
import mir.ndslice.slice : sliced;
import mir.ndslice.topology : map;

auto x = [0.0, 1.0, 2.0, 3.0].sliced;

mixin vectorizeAlt!("std.math", "sin");
auto y = sin(x);
}


Re: Template mixins and selective imports

2017-08-03 Thread Meta via Digitalmars-d-learn

On Thursday, 3 August 2017 at 19:03:55 UTC, Meta wrote:

`mixin vectorize!sin vsin; alias sin = vsin;` and see if it


Should be `alias sin = vsin.sin;`




Re: Template mixins and selective imports

2017-08-03 Thread Meta via Digitalmars-d-learn

On Thursday, 3 August 2017 at 15:29:47 UTC, jmh530 wrote:
I am trying to create a vectorize function that mixes in a new 
version of function with the same name that applies the 
function (to an ndslice).


The code below compiles without error and has the behavior I 
would expect.


However, when I change the function import to a selective 
import (e.g. from import std.math; to import std.math : sin;), 
then I get errors implying that the overload is not actually 
created.


Ideally, I would like to get this working with any kind of 
import.


One thing I noticed is that the fullyQualifiedName of sin 
changes quite a bit depending on whether you use one or the 
other.


This may be related to either of the following:
https://issues.dlang.org/show_bug.cgi?id=16287
https://issues.dlang.org/show_bug.cgi?id=16023



---

import std.traits : isFunction;

private enum _vectorize(string f) = "
import mir.ndslice.slice : SliceKind, Slice;

auto " ~ f ~ "(SliceKind kind, size_t[] packs, Iterator)
   (Slice!(kind, packs, 
Iterator) slice)

{
import mir.ndslice.topology : map;
return slice.map!(f);
}
";

mixin template vectorize(alias f)
if (isFunction!f)
{
mixin(_vectorize!(__traits(identifier, f)));
}

unittest
{
import std.stdio : writeln;
import mir.ndslice.slice : sliced;
import mir.ndslice.topology : map;
import std.math; //import std.math : sin;

auto x = [0.0, 1.0, 2.0, 3.0].sliced;

auto y = x.map!(sin);
writeln(y);

mixin vectorize!(sin);
auto z = sin(x);
writeln(z);
}


I'm not 100% certain, but I believe you have to bring the 
vectorized overload of sin into the overload set, so first try 
`mixin vectorize!sin vsin; alias sin = vsin;` and see if it works.


https://dlang.org/spec/function.html#overload-sets


Template mixins and selective imports

2017-08-03 Thread jmh530 via Digitalmars-d-learn
I am trying to create a vectorize function that mixes in a new 
version of function with the same name that applies the function 
(to an ndslice).


The code below compiles without error and has the behavior I 
would expect.


However, when I change the function import to a selective import 
(e.g. from import std.math; to import std.math : sin;), then I 
get errors implying that the overload is not actually created.


Ideally, I would like to get this working with any kind of import.

One thing I noticed is that the fullyQualifiedName of sin changes 
quite a bit depending on whether you use one or the other.


This may be related to either of the following:
https://issues.dlang.org/show_bug.cgi?id=16287
https://issues.dlang.org/show_bug.cgi?id=16023



---

import std.traits : isFunction;

private enum _vectorize(string f) = "
import mir.ndslice.slice : SliceKind, Slice;

auto " ~ f ~ "(SliceKind kind, size_t[] packs, Iterator)
   (Slice!(kind, packs, 
Iterator) slice)

{
import mir.ndslice.topology : map;
return slice.map!(f);
}
";

mixin template vectorize(alias f)
if (isFunction!f)
{
mixin(_vectorize!(__traits(identifier, f)));
}

unittest
{
import std.stdio : writeln;
import mir.ndslice.slice : sliced;
import mir.ndslice.topology : map;
import std.math; //import std.math : sin;

auto x = [0.0, 1.0, 2.0, 3.0].sliced;

auto y = x.map!(sin);
writeln(y);

mixin vectorize!(sin);
auto z = sin(x);
writeln(z);
}


Re: Imports incorrectly part of "allMembers" trait output?

2017-01-03 Thread ketmar via Digitalmars-d-learn

On Tuesday, 3 January 2017 at 06:23:01 UTC, bauss wrote:
It seems to be a bug that it takes std as there's no std as a 
part of object, not even as an import.


there is. think of it as "ephemeral namespace entity" (kind of 
alias to "name bin" that compiler created, the entity that 
exists, just has no corresponding D type). as i wrote ealier, it 
will be useful eventually to walk import chains in CTFE.


Re: Imports incorrectly part of "allMembers" trait output?

2017-01-03 Thread ketmar via Digitalmars-d-learn
given the way your code is written, "std" namespace *is* a 
member. it will be very useful when we'll fix other bugs and 
recursive `allMembers` scan will become possible. so while it 
came from namespaces implementation, i don't see this as a bug. 
it is little annoying, yes, 'cause you *have* to sort module ids 
out in your code. luckily, it is fairly easy, as module has no 
valid D type.


Re: Imports incorrectly part of "allMembers" trait output?

2017-01-02 Thread bauss via Digitalmars-d-learn

On Monday, 2 January 2017 at 18:56:40 UTC, Mike Bierlee wrote:

When compiling the following code with DMD 2.072.2:

class LeClass {
import std.stdio;
}

void main() {
foreach (memberName; __traits(allMembers, LeClass)) {
pragma(msg, memberName);
}
}

The following output is shown in the console:

std
toString
toHash
opCmp
opEquals
Monitor
factory

Note how "std" is part of the output of allMembers. Is this a 
bug or is this intended behavior? I don't think imports are 
necessarily members of a class. It also happens for static 
imports.


It seems to be a bug that it takes std as there's no std as a 
part of object, not even as an import.


However there is: __traits(derivedMembers, T) which should only 
give you members of your actual class and not anything inherited 
from base classes and/or object.


Imports incorrectly part of "allMembers" trait output?

2017-01-02 Thread Mike Bierlee via Digitalmars-d-learn

When compiling the following code with DMD 2.072.2:

class LeClass {
import std.stdio;
}

void main() {
foreach (memberName; __traits(allMembers, LeClass)) {
pragma(msg, memberName);
}
}

The following output is shown in the console:

std
toString
toHash
opCmp
opEquals
Monitor
factory

Note how "std" is part of the output of allMembers. Is this a bug 
or is this intended behavior? I don't think imports are 
necessarily members of a class. It also happens for static 
imports.


Re: obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Laeeth Isharc via Digitalmars-d-learn

On Wednesday, 5 October 2016 at 12:12:24 UTC, Basile B. wrote:
On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc 
wrote:

I noticed the problem before - previously it was my fault.

I had a circulator dependency where A imported B, B did a 
selective import of C and C imported A selectively.  That led 
to link problems with module constructors.


[...]


It looks like there's a conflict between HackerPilot's fork and 
the phobos version.
But HackerPilot's fork is not used anymore. Have you pulled the 
latest versions recently (or dub upgrade if you use DUB) ?


(verification: 
https://github.com/economicmodeling/containers/commit/528cae2880c0e5faa57d192621ad0533b0124b7b)


Aha,  thank you.   Obvious after the fact now you point it out,  
and I guess that must be it.


Laeeth



Re: obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Basile B. via Digitalmars-d-learn

On Wednesday, 5 October 2016 at 12:12:24 UTC, Basile B. wrote:
On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc 
wrote:

I noticed the problem before - previously it was my fault.

I had a circulator dependency where A imported B, B did a 
selective import of C and C imported A selectively.  That led 
to link problems with module constructors.


[...]


It looks like there's a conflict between HackerPilot's fork and 
the phobos version.
But HackerPilot's fork is not used anymore. Have you pulled the 
latest versions recently (or dub upgrade if you use DUB) ?


(verification: 
https://github.com/economicmodeling/containers/commit/528cae2880c0e5faa57d192621ad0533b0124b7b)


Forgot to say but let's say you're not using DUB but rather git 
modules + script/makefile...git fails to physically delete the 
submodules when it has to (i.e after "git pull && git submodules 
update" the content is still there). So you have to delete the 
content of the folder experimental_allocator manually. Then 
update your build script or makefile.


Re: obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Basile B. via Digitalmars-d-learn

On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote:

I noticed the problem before - previously it was my fault.

I had a circulator dependency where A imported B, B did a 
selective import of C and C imported A selectively.  That led 
to link problems with module constructors.


[...]


It looks like there's a conflict between HackerPilot's fork and 
the phobos version.
But HackerPilot's fork is not used anymore. Have you pulled the 
latest versions recently (or dub upgrade if you use DUB) ?


(verification: 
https://github.com/economicmodeling/containers/commit/528cae2880c0e5faa57d192621ad0533b0124b7b)


obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Laeeth Isharc via Digitalmars-d-learn

I noticed the problem before - previously it was my fault.

I had a circulator dependency where A imported B, B did a 
selective import of C and C imported A selectively.  That led to 
link problems with module constructors.


Here I noticed it in a different context.  Simple two-page main 
code imports dateparser from code.dlang.org.  dateparser uses 
emsi containers, which use std.experimental.allocator.


If I don't import std.experimental.allocator in main module 
(where it isn't actually used) I get the link errors below.  If I 
import it, it goes away.


Might be fixed in 2.071.2 - will upgrade when I can.

Not certain it's a bug and if it is whether it might be fixed, 
but if you think I should I will report.


I can't share code publicly, but I can share gist privately.

Laeeth.

Linking...
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o):(.bss+0x0): 
multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator6__initZ'

../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):(.bss+0x0):
 first defined here
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function 
`_D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv':

(.text._D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv+0x0):
 multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv'
../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator8allocateMOFNemZAv+0x0):
 first defined here
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function 
`_D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb':

(.text._D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb+0x0):
 multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb'
../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator10reallocateMOFKAvmZb+0x0):
 first defined here
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function 
`_D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv':

(.text._D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv+0x0):
 multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv'
../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator22resolveInternalPointerMOFPvZAv+0x0):
 first defined here
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function 
`_D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb':

(.text._D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb+0x0):
 multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb'
../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text._D3std12experimental9allocator12gc_allocator11GCAllocator10deallocateMOFAvZb+0x0):
 first defined here
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o):(.bss+0x1): 
multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator8instanceOS3std12experimental9allocator12gc_allocator11GCAllocator'

../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):(.bss+0x1):
 first defined here
/usr/lib/libphobos2.a(gc_allocator_2c45_42b.o): In function 
`_D3std12experimental9allocator12gc_allocator11GCAllocator7collectMOFNeZv':

(.text._D3std12experimental9allocator12gc_allocator11GCAllocator7collectMOFNeZv+0x0):
 multiple definition of 
`_D3std12experimental9allocator12gc_allocator11GCAllocator7collectMOFNeZv'
../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/libexperimental_allocator.a(gc_allocator_b2_42b.o):../../../../../../../../home/laeeth/.dub/packages/experimental_allocator-2.70.0-b1/src/std/experimental/allocator/gc_allocator.d:(.text

Re: imports && -run [Bug?]

2016-05-13 Thread zabruk70 via Digitalmars-d-learn

On Friday, 13 May 2016 at 06:33:40 UTC, Jacob Carlborg wrote:
Even better is to use "rdmd" which will automatically track and 
compile dependencies.


but i should warn about annoing bug with local import
http://forum.dlang.org/post/mailman.1984.1373610213.13711.digitalmar...@puremagic.com
https://issues.dlang.org/show_bug.cgi?id=7016


Re: imports && -run [Bug?]

2016-05-13 Thread Jacob Carlborg via Digitalmars-d-learn

On 2016-05-13 08:27, Andrew Edwards wrote:


I fail to see why the compiler would be less capable at this task than
rdmd. Since it is already build to accept multiple input files and knows
more about what's going on during compilation than rdmd will ever know,
in does not make sense that it should inferior in this regard: yet rdmd
takes one imput file and sorts out all dependencies.


There's no technical reason why the compiler is not doing this, as far 
as I know.


--
/Jacob Carlborg


Re: imports && -run [Bug?]

2016-05-13 Thread Jacob Carlborg via Digitalmars-d-learn

On 2016-05-13 08:10, tsbockman wrote:


According to the DMD compiler manual, the -run switch only accepts a
single source file:
 -run srcfile args...

After the first source file, any further arguments passed to DMD will be
interpreted as arguments to be passed to the program being run.


To elaborate, since the second file "inc" is not passed to the compiler, 
it will not compile that file, therefore you get linker errors. The 
solution is to pass all extra files before the -run flag.


Even better is to use "rdmd" which will automatically track and compile 
dependencies. Using rdmd it's enough to pass a single file to compile 
all dependencies and run the resulting binary: "rdmd mod".



Have you tried using DUB? It has lots of convenient features, including
a `run` command that supports multiple source files:
 http://code.dlang.org/docs/commandline#run


Dub is a great tool when a project grows larger than a few files.

--
/Jacob Carlborg


Re: imports && -run [Bug?]

2016-05-13 Thread Andrew Edwards via Digitalmars-d-learn

On 5/13/16 3:10 PM, tsbockman wrote:

On Friday, 13 May 2016 at 01:16:36 UTC, Andrew Edwards wrote:

command: dmd -run mod inc

output:

Undefined symbols for architecture x86_64:
  "_D3inc5printFZv", referenced from:
  __Dmain in mod.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
--- errorlevel 1

None of the variations of imports work when compiled with the -run
switch but all work perfectly well without it.


According to the DMD compiler manual, the -run switch only accepts a
single source file:
 -run srcfile args...

After the first source file, any further arguments passed to DMD will be
interpreted as arguments to be passed to the program being run.


Thanks, I guess I just expected it to work the same as rdmd does and 
didn't even bother trying to look in the manual regarding this.


I fail to see why the compiler would be less capable at this task than 
rdmd. Since it is already build to accept multiple input files and knows 
more about what's going on during compilation than rdmd will ever know, 
in does not make sense that it should inferior in this regard: yet rdmd 
takes one imput file and sorts out all dependencies.



Have you tried using DUB? It has lots of convenient features, including
a `run` command that supports multiple source files:
 http://code.dlang.org/docs/commandline#run


I've used dub before but it is not desired for what I'm trying to do. 
rdmd does the trick. Thank you.


Re: imports && -run [Bug?]

2016-05-13 Thread tsbockman via Digitalmars-d-learn

On Friday, 13 May 2016 at 01:16:36 UTC, Andrew Edwards wrote:

command: dmd -run mod inc

output:

Undefined symbols for architecture x86_64:
  "_D3inc5printFZv", referenced from:
  __Dmain in mod.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

--- errorlevel 1

None of the variations of imports work when compiled with the 
-run switch but all work perfectly well without it.


According to the DMD compiler manual, the -run switch only 
accepts a single source file:

-run srcfile args...

After the first source file, any further arguments passed to DMD 
will be interpreted as arguments to be passed to the program 
being run.


Have you tried using DUB? It has lots of convenient features, 
including a `run` command that supports multiple source files:

http://code.dlang.org/docs/commandline#run


imports && -run [Bug?]

2016-05-12 Thread Andrew Edwards via Digitalmars-d-learn

module mod;
// import inc; [1]
// import inc: p=print; [1]
// static import inc; [1]

void main()
{
// import inc: print; // [2]
print();

// static import inc; // [3]
// inc.print();
}

--
module inc;

/*public*/ void print() // [4]
{
import std.stdio: writeln;
writeln("You made it!");
}

--
compiler: DMD v2.071.0
os: OS X El Capitan (10.11.3)

--
command: dmd -run mod inc

output:

Undefined symbols for architecture x86_64:
  "_D3inc5printFZv", referenced from:
  __Dmain in mod.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)

--- errorlevel 1

None of the variations of imports work when compiled with the -run 
switch but all work perfectly well without it.


Re: Question about dub and imports

2016-04-18 Thread Jonathan Villa via Digitalmars-d-learn

On Monday, 18 April 2016 at 21:23:02 UTC, Jonathan Villa wrote:
I'm trying to build a vibe.d application, but I made a little 
library (just source code) that I want to add to the project.


[...]


Close the question,

looks like I found it: importPaths.



Question about dub and imports

2016-04-18 Thread Jonathan Villa via Digitalmars-d-learn
I'm trying to build a vibe.d application, but I made a little 
library (just source code) that I want to add to the project.


So, in the generated dub.sdl file I added at the end:
sourcePaths "../D/src"
sourceFiles "../D/src/alfred/package.d"

The problem is at build time DUB tries to create a library file 
and it fails.
I don't want to it to create a .lib file, just "look at this path 
so when I write `import alfred;` you know where this refers to`.


I'm pretty new using the dub thing, I have look in 
https://code.dlang.org/package-format?lang=sdl but I get a little 
confused.


I have already did this in a non-dub project, adding the import 
path with -I and listing the files and it never actually 
generated a lib.


Or is there a way to just inject a direct line to the build 
params like "-I../D/src" alfred/types.d alfred/command.d ...(etc) 
when running dub in my vibe-d project???


(Is really neccesary to look my little source library like a .lib 
file and try to generate it?)


JV


Re: Problem with circular imports of modules with static ctors an immutable variables

2016-04-15 Thread Marc Schütz via Digitalmars-d-learn

On Friday, 15 April 2016 at 05:35:24 UTC, Uranuz wrote:
In my program I have error with circular imports of modules 
with static ctors. So I decided to move ctors in separate file 
and import it only from the 1st file. But problem is that in 
the first file I have immutables that should be initialized in 
shared static ctor. However doing it from another module's ctor 
gives compilation error: "Error: cannot modify immutable 
expression".

1. Is it a bug?


Not really. The rules are there to avoid cyclic initialization 
dependencies, but they are a bit coarse at the moment.



2. Could I solve this problem another way?


You could put the immutable globals in the the same module as the 
shared ctors, and publicly import them in the "real" modules they 
are intended to be in. You might have to play around with 
`package` protection if you want to make them invisible in the 
helper module, too.


Problem with circular imports of modules with static ctors an immutable variables

2016-04-14 Thread Uranuz via Digitalmars-d-learn
In my program I have error with circular imports of modules with 
static ctors. So I decided to move ctors in separate file and 
import it only from the 1st file. But problem is that in the 
first file I have immutables that should be initialized in shared 
static ctor. However doing it from another module's ctor gives 
compilation error: "Error: cannot modify immutable expression".

1. Is it a bug?
2. Could I solve this problem another way?

Example code:

module mod;

import mod_init;

static immutable string[string] aa;

...

--
module mod_init;

import mod;

shared static this
{
   aa = [ "a": "b", "c": "d" ]; //This gives compilation error
}

...


Re: How to warn of unused imports?

2016-02-09 Thread Basile B. via Digitalmars-d-learn

On Tuesday, 9 February 2016 at 17:54:30 UTC, Basile B. wrote:

On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be 
pretty straightforward, since within DMD you can access the 
AST. Alternatively, implementing DIP50 might let you do it 
outside the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.


If you don't understand what's a "golem":

AlquiaDa was the golem of the CIA (in the 80's while russians 
were fighting in Afgnan). Useful until a certain point.


Useful until a certain point...


It's time for me to leave...once again alcool drives me crazy...
Latest weeks I've been ofensive against two guys: kinsley and 
lopatim...it's time for me to leave.


https://www.youtube.com/watch?v=6ixdPnLFVIo

seeya.


Re: How to warn of unused imports?

2016-02-09 Thread Basile B. via Digitalmars-d-learn

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside 
the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.


Re: How to warn of unused imports?

2016-02-09 Thread Basile B. via Digitalmars-d-learn

On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote:

On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote:

On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote:

Otherwise, it sounds like a decent enhancement request for 
DMD. I know other compilers who do this warning.


It definitely does sound like a decent enhancement request. I 
didn't know it wasn't implemented yet, but it should be pretty 
straightforward, since within DMD you can access the AST. 
Alternatively, implementing DIP50 might let you do it outside 
the compiler.


http://wiki.dlang.org/DIP50


DIP50 is a "golem"

It looks usefull, and it will help in many cases...but after a 
while it'll become a problem.


If you don't understand what's a "golem":

AlquiaDa was the golem of the CIA (in the 80's while russians 
were fighting in Afgnan). Useful until a certain point.


Useful until a certain point...


Re: How to warn of unused imports?

2016-02-08 Thread Daniel Kozak via Digitalmars-d-learn
V Mon, 08 Feb 2016 08:25:09 +
cy via Digitalmars-d-learn  napsáno:

> When I factor out code from my modules, it really, really often 
> leaves import statements that just sit there doing nothing, 
> making it look like my program is more complex than it is. How do 
> I get warned for leaving those, and a list of which ones I can 
> safely remove?

I dont think there is a way right now. But in a future dscanner.
https://github.com/Hackerpilot/Dscanner/issues/134



How to warn of unused imports?

2016-02-08 Thread cy via Digitalmars-d-learn
When I factor out code from my modules, it really, really often 
leaves import statements that just sit there doing nothing, 
making it look like my program is more complex than it is. How do 
I get warned for leaving those, and a list of which ones I can 
safely remove?


  1   2   3   >