Re: Problem with imports in class hierarchy
On Thursday, 28 April 2005 at 02:36:54 UTC, Jarrett Billingsley wrote: "Marco Falda" wrote in message news:d4nime$j36$1...@digitaldaemon.com... I am wondering however why it is not possible to import module A through module A1 in A11 by using a simple "import A" (in A1). You can, but it's bad practice. Whenever making modules that will be imported, always use private import to import other modules into them. Otherwise, it's very easy to pollute the namespace with names you don't need. şurdaki oyunda okey oyna oyunu : https://www.okeydeyim.com.tr/
Re: Weird interaction with public and non-public imports
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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!)
Thanks everyone.
Re: Imports and Subfolders and Links (Oh, My!)
So, the upshot of it all seems to be that the -i's have it.
Re: Imports and Subfolders and Links (Oh, My!)
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!)
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!)
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!)
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!)
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!)
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!)
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
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
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
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
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
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
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.
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.
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.
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?
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?
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?
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?
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?
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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?
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
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
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
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
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/exper
Re: imports && -run [Bug?]
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?]
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?]
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?]
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?]
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?]
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
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
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
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
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?
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?
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?
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?
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
