Re: Weird interaction with public and non-public imports

2021-01-28 Thread SealabJaster via Digitalmars-d-learn
On Thursday, 28 January 2021 at 13:13:46 UTC, Paul Backus wrote: ... https://issues.dlang.org/show_bug.cgi?id=21589 These issues are always so subtle and specific yet so annoying, e.g.: https://issues.dlang.org/show_bug.cgi?id=21496 and https://issues.dlang.org/show_bug.cgi?id=21377

Re: Weird interaction with public and non-public imports

2021-01-28 Thread Paul Backus via Digitalmars-d-learn
On Thursday, 28 January 2021 at 13:07:13 UTC, SealabJaster wrote: Please see: https://run.dlang.io/is/2mwcPH I'd expect that the `isInstanceOf` would be true instead of false here. Commenting out the public import changes the output of `fullyQualifiedName`. I can kind of see why this

Weird interaction with public and non-public imports

2021-01-28 Thread SealabJaster via Digitalmars-d-learn
Please see: https://run.dlang.io/is/2mwcPH I'd expect that the `isInstanceOf` would be true instead of false here. Commenting out the public import changes the output of `fullyQualifiedName`. I can kind of see why this happens, but it's kind of annoying when things like `isInstanceOf`

Re: Mixin and imports

2020-06-08 Thread data pulverizer via Digitalmars-d-learn
On Monday, 8 June 2020 at 16:02:02 UTC, Steven Schveighoffer wrote: On 6/8/20 11:11 AM, jmh530 wrote: On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote: [snip] Out of curiosity what does the "." in front of `foo` mean? [snip] ag0aep6g provided the link to it [snip] The dot

Re: Mixin and imports

2020-06-08 Thread Steven Schveighoffer via Digitalmars-d-learn
On 6/8/20 11:11 AM, jmh530 wrote: On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote: [snip] Out of curiosity what does the "." in front of `foo` mean? I've seen that in some D code on the compiler in GitHub and have no idea what it does. I tried Googling it to no avail. It

Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn
On Monday, 8 June 2020 at 14:27:26 UTC, data pulverizer wrote: [snip] Out of curiosity what does the "." in front of `foo` mean? I've seen that in some D code on the compiler in GitHub and have no idea what it does. I tried Googling it to no avail. It doesn't have anything to do with UFCS

Re: Mixin and imports

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

Re: Mixin and imports

2020-06-08 Thread data pulverizer via Digitalmars-d-learn
On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote: ``` ... template foo(string f) { mixin("alias foo = .foo!(" ~ f ~ ");"); } ... ``` Out of curiosity what does the "." in front of `foo` mean? I've seen that in some D code on the compiler in GitHub and have no idea what it does. I

Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn
On Monday, 8 June 2020 at 12:20:46 UTC, Adam D. Ruppe wrote: [snip] Why do you even want foo!"fabs"? Usually when I see people having this problem it is actually a misunderstanding of what is possible with the foo!fabs style - which is better in basically every way and can be used in most

Re: Mixin and imports

2020-06-08 Thread FunkyD via Digitalmars-d-learn
On Monday, 8 June 2020 at 10:41:53 UTC, jmh530 wrote: On Monday, 8 June 2020 at 10:28:39 UTC, Paul Backus wrote: [snip] Thanks for that suggestion. That works for me. Unfortunately, it's probably not worth the extra effort though, versus doing foo!fabs in my case. If they are all from

Re: Mixin and imports

2020-06-08 Thread Adam D. Ruppe via Digitalmars-d-learn
On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote: In the code below, foo!fabs compiles without issue, but foo!"fabs" does not because the import is not available in the string mixin. Why do you even want foo!"fabs"? Usually when I see people having this problem it is actually a

Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn
On Monday, 8 June 2020 at 10:28:39 UTC, Paul Backus wrote: [snip] Thanks for that suggestion. That works for me. Unfortunately, it's probably not worth the extra effort though, versus doing foo!fabs in my case.

Re: Mixin and imports

2020-06-08 Thread Paul Backus via Digitalmars-d-learn
On Monday, 8 June 2020 at 10:23:24 UTC, jmh530 wrote: On Monday, 8 June 2020 at 04:13:08 UTC, Mike Parker wrote: [snip] The problem isn't the mixin. It's the template. Templates take the scope of their declaration, not their instantiation. So the mixin is getting the template's scope.

Re: Mixin and imports

2020-06-08 Thread jmh530 via Digitalmars-d-learn
On Monday, 8 June 2020 at 04:13:08 UTC, Mike Parker wrote: [snip] The problem isn't the mixin. It's the template. Templates take the scope of their declaration, not their instantiation. So the mixin is getting the template's scope. Anyway, this appears to work: `double z =

Re: Mixin and imports

2020-06-07 Thread Mike Parker via Digitalmars-d-learn
On Monday, 8 June 2020 at 02:55:25 UTC, jmh530 wrote: In the code below, foo!fabs compiles without issue, but foo!"fabs" does not because the import is not available in the string mixin. If I move the import to the top of the module, then it works. However, then if I move foo to another

Mixin and imports

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

Detecting unneeded imports in CI

2020-02-06 Thread Joseph Rushton Wakeling via Digitalmars-d-learn
Hello folks, Are there any well-established CI patterns/tools for detecting unneeded imports in D code? Ideally including detecting unused symbols from selective imports? Thanks and best wishes, -- Joe

Re: Unused imports

2020-01-30 Thread Francesco Mecca via Digitalmars-d-learn
On Thursday, 30 January 2020 at 16:23:54 UTC, Michael wrote: Is there a way to detect unused imports? It happened to me that I used imports which I did not need in the end. So, I'd like to remove them easily. https://issues.dlang.org/show_bug.cgi?id=20442 TL;DR This has come up in the past

Unused imports

2020-01-30 Thread Michael via Digitalmars-d-learn
Is there a way to detect unused imports? It happened to me that I used imports which I did not need in the end. So, I'd like to remove them easily.

Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn
std.stdio; myOtherStruct mos; mos.writeln; } Yes, as long as you are adding the imports all over, things can work. But as said, if you creating bindings for a larger C library, this is not practicable. -- Robert M. Münch http://www.saphirion.com smarter | better | faster

Re: Packages / imports & references between modules

2019-04-28 Thread kdevel via Digitalmars-d-learn
On Sunday, 28 April 2019 at 14:24:08 UTC, Robert M. Münch wrote: On 2019-04-28 11:44:03 +, Mike Parker said: They're different symbols because they're in different modules. The module and package name is part of the symbol name. Ok, that's what I assumed too. Just import A.b in A.a.

Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn
On 2019-04-28 11:44:03 +, Mike Parker said: They're different symbols because they're in different modules. The module and package name is part of the symbol name. Ok, that's what I assumed too. Just import A.b in A.a. Won't help. I just commented the lines DStep generated for

Re: Packages / imports & references between modules

2019-04-28 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 28 April 2019 at 11:12:50 UTC, Robert M. Münch wrote: One more problem now showing up, when I do this: A/a.d module A.a; struct myStruct; A/b.d module A.b; struct myStruct {...} A/c.d module A.c; import A; struct

Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn
On 2019-04-27 16:30:48 +, Adam D. Ruppe said: This will never work in D. The module needs to work by itself. It can see public imports from another module it itself imports: module A.c; import A; // thanks to this, it can see a `public import A.a;` from the A package.. But without

Re: Packages / imports & references between modules

2019-04-28 Thread Robert M. Münch via Digitalmars-d-learn
On 2019-04-27 16:30:48 +, Adam D. Ruppe said: There is no "same level" really (except for the `package` protection level); it is just inside the module or outside the module for imports. Hi Adamn, ok, got it. The docs are indicating that the "public import" i

Re: Packages / imports & references between modules

2019-04-27 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 27 April 2019 at 16:24:40 UTC, Robert M. Münch wrote: I thought that public only applies to the upward chain, not to the same level. There is no "same level" really (except for the `package` protection level); it is just inside the module or outside the module f

Re: Packages / imports & references between modules

2019-04-27 Thread Robert M. Münch via Digitalmars-d-learn
this would end up in adding a lot of imports to avoid the "undefined identifier" problem to many files manually and somehow break the DStep workflow. So, is there a way to avoid this? With public import it doesn't seem to work. -- Robert M. Münch http://www.saphirion.com smarter | better | faster

Re: Packages / imports & references between modules

2019-04-27 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 27 April 2019 at 14:58:01 UTC, Robert M. Münch wrote: import A.a; `import` by itself is a private import, meaning it cannot be seen from outside the module. Make it `public import` and it can be seen from the outside; the other modules importing it can access them too.

Packages / imports & references between modules

2019-04-27 Thread Robert M. Münch via Digitalmars-d-learn
A/a.d has module A.a; A/b.d has module A.b; A/package.d import A.a; import A.b; A.b needs to access something from A.a I assumed if I do import package.d that A.b sees the content of A.a now and doens't need an explicit line with a/b.d import A.a; But this

Re: imports in a Separate File?

2018-12-11 Thread Ron Tarrant via Digitalmars-d-learn
On Tuesday, 11 December 2018 at 15:39:18 UTC, Steven Schveighoffer wrote: Use public imports in your header file. This will pretend that the symbols imported reside in the module itself. i.e. inside importedStuff.d: public { // 120 import statements } -Steve Thanks, Steve. Works like

Re: imports in a Separate File?

2018-12-11 Thread Steven Schveighoffer via Digitalmars-d-learn
On 12/11/18 10:27 AM, Ron Tarrant wrote: I ran across a code example (https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/TestWindow/TestWindow.d) in which the first ~120 lines are mostly import statements. And it got me wondering... I tried to off-load a bunch of imports

imports in a Separate File?

2018-12-11 Thread Ron Tarrant via Digitalmars-d-learn
I ran across a code example (https://github.com/gtkd-developers/GtkD/blob/master/demos/gtkD/TestWindow/TestWindow.d) in which the first ~120 lines are mostly import statements. And it got me wondering... I tried to off-load a bunch of imports into a pseudo-header file — importedStuff.d

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

2018-12-09 Thread Ron Tarrant via Digitalmars-d-learn
Thanks everyone.

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

2018-12-07 Thread Ron Tarrant via Digitalmars-d-learn
So, the upshot of it all seems to be that the -i's have it.

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

2018-12-07 Thread H. S. Teoh via Digitalmars-d-learn
On Fri, Dec 07, 2018 at 07:01:18PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote: [...] > > when I compile rather than compiling modules over and over > > needlessly. > > Oh, lots of us compile everything at once. It works

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

2018-12-07 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote: Are you talking about a list of import statements here or is there another way/place I would list them? On the dmd command line. So say your program has a.d and b.d, you would compile with `dmd a.d b.d`. Or as you had some

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

2018-12-07 Thread H. S. Teoh via Digitalmars-d-learn
On Sat, Dec 08, 2018 at 06:48:46AM +1300, rikki cattermole via Digitalmars-d-learn wrote: > On 08/12/2018 6:41 AM, Ron Tarrant wrote: > > Does D have the concept of makefiles? I haven't run across any > > reference to such things so far. > > Make isn't a D specification application (it doesn't

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

2018-12-07 Thread rikki cattermole via Digitalmars-d-learn
On 08/12/2018 6:41 AM, Ron Tarrant wrote: Does D have the concept of makefiles? I haven't run across any reference to such things so far. Make isn't a D specification application (it doesn't really specialize in any language) dmd, druntime and Phobos are all built using it. Though for user

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

2018-12-07 Thread Ron Tarrant via Digitalmars-d-learn
On Friday, 7 December 2018 at 16:43:02 UTC, Adam D. Ruppe wrote: That's wrong: the import name and the module name should always match, in full, including all the dot parts. So if you "import app.modulename;", the other file must have "module app.modulename;" Okay. I guess the instructions

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

2018-12-07 Thread Adam D. Ruppe via Digitalmars-d-learn
On Friday, 7 December 2018 at 16:39:34 UTC, Ron Tarrant wrote: import subfolder.ModuleName; And in the module files, the first statement is: module ModuleName; That's wrong: the import name and the module name should always match, in full, including all the dot parts. So if you "import

Imports and Subfolders and Links (Oh, My!)

2018-12-07 Thread Ron Tarrant via Digitalmars-d-learn
Trying to wrap my brain around imports, etc. In various places around the Internet, I've read that if I have modules in a subfolder/subdirectory, my import statement would look like this: import subfolder.ModuleName; And in the module files, the first statement is: module ModuleName

Re: public imports

2018-12-05 Thread Sjoerd Nijboer via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 23:18:49 UTC, H. S. Teoh wrote: Maybe if you described to us exactly what you want to do, we could find a way to do it that doesn't involve language holes that are not guaranteed to work? Honestly I don't know. I was just messing around. My initial question

Re: public imports

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

Re: public imports

2018-12-05 Thread Sjoerd Nijboer via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 21:21:12 UTC, Adam D. Ruppe wrote: Looks intended. It doesn't really make sense to have a public import inside a function. I was trying to find a weird corner of the language and maybe do something funny with conditional imports. They don't work in functions

Re: public imports

2018-12-05 Thread Paul Backus via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 21:13:29 UTC, Sjoerd Nijboer wrote: A small question. Is it intended behaviour that public imports inside function calls fail with the message "Error: found public instead of statement", or is it an underdocumented feature? void foo() { public

Re: public imports

2018-12-05 Thread Adam D. Ruppe via Digitalmars-d-learn
On Wednesday, 5 December 2018 at 21:13:29 UTC, Sjoerd Nijboer wrote: A small question. Is it intended behaviour that public imports inside function calls fail with the message "Error: found public instead of statement", or is it an underdocumented feature? Looks intended. It does

public imports

2018-12-05 Thread Sjoerd Nijboer via Digitalmars-d-learn
A small question. Is it intended behaviour that public imports inside function calls fail with the message "Error: found public instead of statement", or is it an underdocumented feature? void foo() { public import bar; }

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

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

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

2018-06-30 Thread Jonathan M Davis via Digitalmars-d-learn
On Sunday, July 01, 2018 00:42:30 spikespaz via Digitalmars-d-learn wrote: > Hey guys, I'm getting a linker error when compiling with DMD > `-m63` that I don't get as 23 bit. > > I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I > get the following: > >

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

2018-06-30 Thread spikespaz via Digitalmars-d-learn
Hey guys, I'm getting a linker error when compiling with DMD `-m63` that I don't get as 23 bit. I'm importing `ShowWindow` from `core.sys.windows.winuser`, and I get the following: C:\D\dmd2\windows\bin\lld-link.exe: warning: main.obj: undefined symbol: ShowWindow error: link failed Error:

Re: errnoEnforce: which imports?

2018-06-29 Thread kdevel via Digitalmars-d-learn
On Friday, 29 June 2018 at 09:22:03 UTC, Jonathan M Davis wrote: Shall I create a bug report? Yes. Aside from someone trying it out and complaining about it, it probably wouldn't be noticed or fixed, since it's one of the few tests that doesn't work as a ddoc-ed unit test. Issue 19041 -

Re: errnoEnforce: which imports?

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

Re: errnoEnforce: which imports?

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

Re: errnoEnforce: which imports?

2018-06-28 Thread Jonathan M Davis via Digitalmars-d-learn
On Friday, June 29, 2018 01:25:39 kdevel via Digitalmars-d-learn wrote: > In https://dlang.org/phobos/std_exception.html#errnoEnforce this > example is shown: > > --- > auto f = errnoEnforce(fopen("data.txt")); > auto line = readln(f); > enforce(line.length); // expect a non-empty line > --- > > I

errnoEnforce: which imports?

2018-06-28 Thread kdevel via Digitalmars-d-learn
In https://dlang.org/phobos/std_exception.html#errnoEnforce this example is shown: --- auto f = errnoEnforce(fopen("data.txt")); auto line = readln(f); enforce(line.length); // expect a non-empty line --- I added import std.stdio; import std.exception; and get an error message which

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

2018-01-03 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jan 03, 2018 at 12:43:52AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn > wrote: > > I've only understood that imports should go in package.d. I'm seeing > > more and more packages

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

2018-01-03 Thread Soulsbane via Digitalmars-d-learn
On Wednesday, 3 January 2018 at 07:43:52 UTC, Jonathan M Davis wrote: On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn wrote: [...] The entire reason that the package.d feature was added was so that it would be possible to split a module into a package without

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

2018-01-02 Thread Jonathan M Davis via Digitalmars-d-learn
On Wednesday, January 03, 2018 06:10:10 Soulsbane via Digitalmars-d-learn wrote: > I've only understood that imports should go in package.d. I'm > seeing more and more packages on code.dlang.org using it for the > packages primary code. Is this alright? As far as I can tell it's > j

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

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

Re: Private imports and Objects

2017-11-30 Thread Patrick Schluter via Digitalmars-d-learn
On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis wrote: Object exists primarily because D didn't originally have templates, and when you don't have templates, having a single base class is the only way to have a function accept any class, and for something like a container,

Re: Private imports and Objects

2017-11-30 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, November 30, 2017 10:54:44 helxi via Digitalmars-d-learn wrote: > On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis > > wrote: > > On Thursday, November 30, 2017 06:29:43 helxi via > > > Digitalmars-d-learn wrote: > [] > > > I don't understand the question. You're asking

Re: Private imports and Objects

2017-11-30 Thread helxi via Digitalmars-d-learn
On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis wrote: On Thursday, November 30, 2017 06:29:43 helxi via Digitalmars-d-learn wrote: [] I don't understand the question. You're asking whether casting from a base class to a derived class creates overhead? Or are you asking

Re: Private imports and Objects

2017-11-29 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, November 30, 2017 06:29:43 helxi via Digitalmars-d-learn wrote: > 1. Why are imports visible from outside the package when you do > selective imports? > > //mod.d > module mod; > > import std.stdio : writeln; > > public void greet() > { > wr

Private imports and Objects

2017-11-29 Thread helxi via Digitalmars-d-learn
1. Why are imports visible from outside the package when you do selective imports? //mod.d module mod; import std.stdio : writeln; public void greet() { writeln("Hello"); } //app.d import mod; void main() { mod.greet(); writeln("You shoul

Re: Imports

2017-10-05 Thread Ali Çehreli via Digitalmars-d-learn
On 10/05/2017 03:34 PM, Jiyan wrote: > PS: is it spam to say thank you? Thank you for asking! :p I used to have strong feelings about this in the past. I still think it's spam; I don't expect any thanks from anyone and I think gratitude should be implied. Some people have different

Re: Imports

2017-10-05 Thread Jiyan via Digitalmars-d-learn
On Thursday, 5 October 2017 at 12:35:26 UTC, Mike Parker wrote: On Thursday, 5 October 2017 at 12:25:27 UTC, Mike Parker wrote: [...] Right. I had to go back and look at what I wrote in Learning D, which is the last (and only) time I played around with the default module behavior. I always

Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 5 October 2017 at 12:25:27 UTC, Mike Parker wrote: And actually, now that I think about it, this is probably one of those situations where the defualt fails. So yes, you'll need a module name. Right. I had to go back and look at what I wrote in Learning D, which is the last

Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 5 October 2017 at 12:18:57 UTC, Mike Parker wrote: Regardless, every module should have a module name at the top. There are situations where the inferred package & module names can't work. Ugh. Sorry, I mean for sourcePaths you have to pass `src` and not `dir`. And actually,

Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 5 October 2017 at 12:17:23 UTC, Mike Parker wrote: On Thursday, 5 October 2017 at 11:44:00 UTC, Jiyan wrote: [...] But as i see it with sourcePaths the directories are not influencing the module names(in the directories except "source"), so "dir.sub" will just have the name

Re: Imports

2017-10-05 Thread Mike Parker via Digitalmars-d-learn
On Thursday, 5 October 2017 at 11:44:00 UTC, Jiyan wrote: [...] But as i see it with sourcePaths the directories are not influencing the module names(in the directories except "source"), so "dir.sub" will just have the name "sub" is there a way around that, except naming every module like:

Re: Imports

2017-10-05 Thread Jiyan via Digitalmars-d-learn
On Thursday, 5 October 2017 at 00:28:32 UTC, Mike Parker wrote: On Wednesday, 4 October 2017 at 16:31:35 UTC, Jiyan wrote: [...] If you have this directory tree: - mylib -- pack1 --- a.d --- b.d pack2 - c.d [...] Thank you, i think i kinda got that :) But as i see it with

Re: Imports

2017-10-04 Thread Mike Parker via Digitalmars-d-learn
On Wednesday, 4 October 2017 at 16:31:35 UTC, Jiyan wrote: Hey, as i see it the -Ipath command for dmd just imports the files within a directory but it doesnt work for sub directories, so i can write something like: import subdirectoryFromPath.file; Also with dub this doesnt seem possible

Imports

2017-10-04 Thread Jiyan via Digitalmars-d-learn
Hey, as i see it the -Ipath command for dmd just imports the files within a directory but it doesnt work for sub directories, so i can write something like: import subdirectoryFromPath.file; Also with dub this doesnt seem possible (sourcePaths seems to work as the -I command

Re: Template mixins and selective imports

2017-08-03 Thread jmh530 via Digitalmars-d-learn
On Thursday, 3 August 2017 at 19:05:47 UTC, Meta wrote: On Thursday, 3 August 2017 at 19:03:55 UTC, Meta wrote: `mixin vectorize!sin vsin; alias sin = vsin;` and see if it Should be `alias sin = vsin.sin;` Thanks, this pointed me in the right direction. I got the line below working.

Re: Template mixins and selective imports

2017-08-03 Thread Meta via Digitalmars-d-learn
On Thursday, 3 August 2017 at 19:03:55 UTC, Meta wrote: `mixin vectorize!sin vsin; alias sin = vsin;` and see if it Should be `alias sin = vsin.sin;`

Re: Template mixins and selective imports

2017-08-03 Thread Meta via Digitalmars-d-learn
On Thursday, 3 August 2017 at 15:29:47 UTC, jmh530 wrote: I am trying to create a vectorize function that mixes in a new version of function with the same name that applies the function (to an ndslice). The code below compiles without error and has the behavior I would expect. However,

Template mixins and selective imports

2017-08-03 Thread jmh530 via Digitalmars-d-learn
I am trying to create a vectorize function that mixes in a new version of function with the same name that applies the function (to an ndslice). The code below compiles without error and has the behavior I would expect. However, when I change the function import to a selective import (e.g.

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

2017-01-03 Thread ketmar via Digitalmars-d-learn
On Tuesday, 3 January 2017 at 06:23:01 UTC, bauss wrote: It seems to be a bug that it takes std as there's no std as a part of object, not even as an import. there is. think of it as "ephemeral namespace entity" (kind of alias to "name bin" that compiler created, the entity that exists, just

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

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

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

2017-01-02 Thread bauss via Digitalmars-d-learn
); } } 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.

Imports incorrectly part of "allMembers" trait output?

2017-01-02 Thread Mike Bierlee via Digitalmars-d-learn
opCmp opEquals Monitor factory Note how "std" is part of the output of allMembers. Is this a bug or is this intended behavior? I don't think imports are necessarily members of a class. It also happens for static imports.

Re: obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Laeeth Isharc via Digitalmars-d-learn
On Wednesday, 5 October 2016 at 12:12:24 UTC, Basile B. wrote: On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote: I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A

Re: obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Basile B. via Digitalmars-d-learn
On Wednesday, 5 October 2016 at 12:12:24 UTC, Basile B. wrote: On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote: I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A

Re: obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Basile B. via Digitalmars-d-learn
On Wednesday, 5 October 2016 at 11:45:49 UTC, Laeeth Isharc wrote: I noticed the problem before - previously it was my fault. I had a circulator dependency where A imported B, B did a selective import of C and C imported A selectively. That led to link problems with module constructors.

obscure messages relating to linking and imports in 2.071.1

2016-10-05 Thread Laeeth Isharc via Digitalmars-d-learn
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

Re: imports && -run [Bug?]

2016-05-13 Thread zabruk70 via Digitalmars-d-learn
On Friday, 13 May 2016 at 06:33:40 UTC, Jacob Carlborg wrote: Even better is to use "rdmd" which will automatically track and compile dependencies. but i should warn about annoing bug with local import http://forum.dlang.org/post/mailman.1984.1373610213.13711.digitalmar...@puremagic.com

Re: imports && -run [Bug?]

2016-05-13 Thread Jacob Carlborg via Digitalmars-d-learn
On 2016-05-13 08:27, Andrew Edwards wrote: I fail to see why the compiler would be less capable at this task than rdmd. Since it is already build to accept multiple input files and knows more about what's going on during compilation than rdmd will ever know, in does not make sense that it

Re: imports && -run [Bug?]

2016-05-13 Thread Jacob Carlborg via Digitalmars-d-learn
On 2016-05-13 08:10, tsbockman wrote: According to the DMD compiler manual, the -run switch only accepts a single source file: -run srcfile args... After the first source file, any further arguments passed to DMD will be interpreted as arguments to be passed to the program being run. To

Re: imports && -run [Bug?]

2016-05-13 Thread Andrew Edwards via Digitalmars-d-learn
6_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 s

Re: imports && -run [Bug?]

2016-05-13 Thread tsbockman via Digitalmars-d-learn
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

imports && -run [Bug?]

2016-05-12 Thread Andrew Edwards via Digitalmars-d-learn
from: __Dmain in mod.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) --- errorlevel 1 None of the variations of imports work when compiled with the -run switch but all work perfectly well without it.

Re: Question about dub and imports

2016-04-18 Thread Jonathan Villa via Digitalmars-d-learn
On Monday, 18 April 2016 at 21:23:02 UTC, Jonathan Villa wrote: I'm trying to build a vibe.d application, but I made a little library (just source code) that I want to add to the project. [...] Close the question, looks like I found it: importPaths.

Question about dub and imports

2016-04-18 Thread Jonathan Villa via Digitalmars-d-learn
I'm trying to build a vibe.d application, but I made a little library (just source code) that I want to add to the project. So, in the generated dub.sdl file I added at the end: sourcePaths "../D/src" sourceFiles "../D/src/alfred/package.d" The problem is at build time DUB tries to create a

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

2016-04-15 Thread Marc Schütz via Digitalmars-d-learn
On Friday, 15 April 2016 at 05:35:24 UTC, Uranuz wrote: In my program I have error with circular imports of modules with static ctors. So I decided to move ctors in separate file and import it only from the 1st file. But problem is that in the first file I have immutables that should

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

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

Re: How to warn of unused imports?

2016-02-09 Thread Basile B. via Digitalmars-d-learn
On Tuesday, 9 February 2016 at 17:54:30 UTC, Basile B. wrote: On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote: On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote: On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote: Otherwise, it sounds like a decent enhancement request

Re: How to warn of unused imports?

2016-02-09 Thread Basile B. via Digitalmars-d-learn
On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote: On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote: Otherwise, it sounds like a decent enhancement request for DMD. I know other compilers who do this warning. It definitely does sound like a decent enhancement request. I didn't

Re: How to warn of unused imports?

2016-02-09 Thread Basile B. via Digitalmars-d-learn
On Tuesday, 9 February 2016 at 15:21:59 UTC, Basile B. wrote: On Monday, 8 February 2016 at 20:48:29 UTC, cy wrote: On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote: Otherwise, it sounds like a decent enhancement request for DMD. I know other compilers who do this warning. It

Re: How to warn of unused imports?

2016-02-08 Thread Daniel Kozak via Digitalmars-d-learn
V Mon, 08 Feb 2016 08:25:09 + cy via Digitalmars-d-learn napsáno: > When I factor out code from my modules, it really, really often > leaves import statements that just sit there doing nothing, > making it look like my program is more complex than it is.

How to warn of unused imports?

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

  1   2   3   >