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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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:
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
Jonathan:
Thank you. In reply to [1]: that is an interesting issue that
I don't really understand right now. Can you explain exactly
where I invoke undefined behavior?
It can be shown with this function:
int*[] foo() {
int x;
int*[] arr = [x];
return arr;
}
Here the value
On 12/27/2013 05:54 AM, Jonathan wrote:
Thanks to everyone that has replied.
@Timon Gehr:
Thank you. In reply to [1]: that is an interesting issue that I don't
really understand right now. Can you explain exactly where I invoke
undefined behavior? It was my understanding that structs are
Timon Gehr:
mixin ADT!q{ Term: Var char | Op char Term[] };
void main(){
const expr = Op('f', [Op('g',[Var('x'), Var('y')]),
Op('a',[]), Var('x')]);
}
Where is ADT defined? (And why isn't it a Phobos patch on GitHub?)
convertNum could be written more compactly as:
char
Am Fri, 27 Dec 2013 13:45:10 +
schrieb bearophile bearophileh...@lycos.com:
Timon Gehr:
mixin ADT!q{ Term: Var char | Op char Term[] };
void main(){
const expr = Op('f', [Op('g',[Var('x'), Var('y')]),
Op('a',[]), Var('x')]);
}
Where is ADT defined? (And why isn't it a
On 12/27/2013 02:45 PM, bearophile wrote:
Timon Gehr:
mixin ADT!q{ Term: Var char | Op char Term[] };
void main(){
const expr = Op('f', [Op('g',[Var('x'), Var('y')]), Op('a',[]),
Var('x')]);
}
Where is ADT defined?
https://d.puremagic.com/issues/show_bug.cgi?id=10431
(And why isn't
Let me just check my understanding: If a function says it
returns a thing of type T, it really does return something whose
outermost shape is T; however, if it contains pointers to other
things, and these were stack allocated, the pointers might be
readdressed.
@Bearophile: in your example,
On Friday, 27 December 2013 at 00:23:58 UTC, Jonathan wrote:
I come from Haskell, so please excuse any functional
programming idiosyncracies I have :)
In Haskell, I have a datatype for representing so called terms
which looks like:
data Term = Var Char | Op Char [Term]
i.e. a Term is a
Found your other post nwm.
Timon Gehr:
https://d.puremagic.com/issues/show_bug.cgi?id=11558
We are getting there :-)
but implying that you are somehow ethically superior and that I
am not human seems to go a little far. :o)
Sorry. In my opinion that kid of code is not very readable,
spaces help to eye to chunk
On 12/27/2013 05:08 PM, Jonathan wrote:
Let me just check my understanding: If a function says it returns a
thing of type T, it really does return something whose outermost shape
is T; however, if it contains pointers to other things, and these were
stack allocated, the pointers might be
On Friday, 27 December 2013 at 16:08:09 UTC, Jonathan wrote:
Let me just check my understanding: If a function says it
returns a thing of type T, it really does return something
whose outermost shape is T; however, if it contains pointers to
other things, and these were stack allocated, the
On 12/27/2013 01:40 AM, Jonathan wrote:
Term makeExTerm(){
Term var1 = Term(1);//x
Term var2 = Term(2);//y
Term var3 = Term(3);//z
Term fxx = Term(4, [var1,var1]);//f(x,x)
Term gfxxy = Term(5, [fxx,var2]);//g(f(x,x),y)
Term hzg = Term(6,
Jonathan:
I come from Haskell, so please excuse any functional
programming idiosyncracies I have :)
Welcome. You are the first Haskell programmer that I know willing
to learn and try D :-)
In Haskell, I have a datatype for representing so called terms
which looks like:
data Term =
On 12/27/2013 02:49 AM, bearophile wrote:
In almost-theory D should allow code like:
import std.stdio, std.typecons, std.variant;
alias Term = Algebraic!(string, Tuple!(string, This[]));
void main() {
const expr = Term(tuple(f, [Term(tuple(g, [x.Term,
y.Term])), Term(tuple(a, [])),
Thanks to everyone that has replied.
@Timon Gehr:
Thank you. In reply to [1]: that is an interesting issue that I
don't really understand right now. Can you explain exactly where
I invoke undefined behavior? It was my understanding that
structs are passed and returned by value, and the
41 matches
Mail list logo
