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 ba
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
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
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` silent
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 ope
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
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 doe
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
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 tri
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
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.
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 misunderst
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.
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.
Anyw
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.fa
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,
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 differe
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
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
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.
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
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.
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
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 myOtherStruc
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
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 on
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 impo
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
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.
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
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
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
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
Thanks everyone.
So, the upshot of it all seems to be that the -i's have it.
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 quit
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 succes
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
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 c
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
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
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 Modul
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
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
> someth
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
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
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
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;
}
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`,
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-lin
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:
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 - err
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,
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?
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
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 rem
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 mor
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 breaki
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 i
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 c
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
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
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
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
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
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 opinion
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
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 (a
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, n
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
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:
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 source
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
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
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.
m
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;`
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 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.
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
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
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
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.
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 selectiv
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 selectiv
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.
[..
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
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:/
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
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
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
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...
om:
__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.
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.
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 lib
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
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
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
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 defi
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
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
1 - 100 of 272 matches
Mail list logo
