Re: Passing directory as compiler argument not finding file
On Friday, 13 April 2018 at 13:39:23 UTC, Tony wrote: On Friday, 13 April 2018 at 12:46:32 UTC, Cym13 wrote: On Friday, 13 April 2018 at 01:27:06 UTC, Tony wrote: I think that the typical model (at least in other languages) is to only compile one D source file at a time. Compile the b.d file with the -c option to create an object file. Then put the object file in a library file (either static (easier) or dynamic). Then you can use the -L compiler option to specify the directory of the library and the -l compiler option to specify the library (library name is shortened - libb.a referenced as -lb). Regardless of whether that would work or not this is the opposite of what's recommended in D. D compilers expect you to compile everything at once, or at least by module. That's where it works best when it comes to optimizations etc. What does "or at least by module" mean? Is it possible to have a module that is made up of more than one source file? Sorry, I really meant "package" here, not module. What information does a D compiler get when you stick a.d and b.d on the command line that it doesn't get if you compile a.d and import b.d ? Hmm. I can't quite remember honnestly. What I do remember is Andrei saying times and times again that D supports compilation by package and not incremental compilation (which is difficult because of CTFE and templates), but on second thought maybe you won't run into issues if compiling each module separately as long as you compile them all. However I'm pretty sure you'll get worse compilation times as the compiler can't make use of symbol cache etc. That may be the main reason why people generally avoid compiling separately each module and just put every file on the command line. AFAIK dmd is designed to be used that way.
Re: Why is the error message coming by the end of the compilation?
On Friday, 13 April 2018 at 20:50:38 UTC, bauss wrote:
What I'm doing is basically this:
static foreach (viewResult; generateViewsResult)
{
pragma(msg, "Compiling: " ~ viewResult.name);
mixin(viewResult.source);
pragma(msg, "Compiled: " ~ viewResult.name);
}
I would've expect the compiling to be before the error message,
but the compiled after the error message.
However it seems like it doesn't do that, but as I can't
reproduce it I'm just wondering what causes it.
The compiler is free to examine your source code in any order
that produces the same artifacts on success and self-consistent
error messages otherwise. In this case, it evaluated the pragmas
and the `mixin` in one pass, then the function body in a separate
pass.
The best way I've found to debug mixins is to pragma(msg) the
code I wanted to mix in, then insert it myself.
Re: Why is the error message coming by the end of the compilation?
On 4/13/18 4:50 PM, bauss wrote:
I can't seem to reproduce this with any other smaller projects, so my
question is really what could trigger this behavior.
See: https://i.imgur.com/OmqJ8Sr.png
Whenever I try to just do this kind of thing by itself then it behaves
correctly.
Ex: (As you can see it prints the error messages in the order it should.)
https://run.dlang.io/
What I'm doing is basically this:
static foreach (viewResult; generateViewsResult)
{
pragma(msg, "Compiling: " ~ viewResult.name);
mixin(viewResult.source);
pragma(msg, "Compiled: " ~ viewResult.name);
}
I would've expect the compiling to be before the error message, but the
compiled after the error message.
It may be on a later semantic pass that the error occurs, I'm not sure.
Only thing I can think of.
However it seems like it doesn't do that, but as I can't reproduce it
I'm just wondering what causes it.
I'm suspecting that it's something to do with dub and that it's within a
dependency that's compiled as a source library, but I've yet to test it
out completely.
Try verbose output maybe?
It's really impossible to debug mixins when you have no idea which mixin
the error actually come from, which is what I'm trying to solve.
You may want to try using __traits(compiles) in a debug version to see
whether it will compile or not, and if not, print the thing you are
trying to compile.
-Steve
Why is the error message coming by the end of the compilation?
I can't seem to reproduce this with any other smaller projects,
so my question is really what could trigger this behavior.
See: https://i.imgur.com/OmqJ8Sr.png
Whenever I try to just do this kind of thing by itself then it
behaves correctly.
Ex: (As you can see it prints the error messages in the order it
should.)
https://run.dlang.io/
What I'm doing is basically this:
static foreach (viewResult; generateViewsResult)
{
pragma(msg, "Compiling: " ~ viewResult.name);
mixin(viewResult.source);
pragma(msg, "Compiled: " ~ viewResult.name);
}
I would've expect the compiling to be before the error message,
but the compiled after the error message.
However it seems like it doesn't do that, but as I can't
reproduce it I'm just wondering what causes it.
I'm suspecting that it's something to do with dub and that it's
within a dependency that's compiled as a source library, but I've
yet to test it out completely.
It's really impossible to debug mixins when you have no idea
which mixin the error actually come from, which is what I'm
trying to solve.
Re: Why is the error message coming by the end of the compilation?
On Friday, 13 April 2018 at 20:50:38 UTC, bauss wrote: https://run.dlang.io/ Sorry posted wrong link for run.dlang.io. https://run.dlang.io/is/HQlbgv
Re: How do you check for nonempty string?
On Friday, 13 April 2018 at 17:41:00 UTC, Adam D. Ruppe wrote: On Friday, 13 April 2018 at 17:38:39 UTC, Dr.No wrote: string s = null; if(s !is null && s[0] == '/') is this correct? No, that doesn't work if the string = "a"[$..$] for example Just use if(s.length && s[0]) instead just `if (s.length)` is enough.
Re: How do you check for nonempty string?
On Friday, 13 April 2018 at 17:38:39 UTC, Dr.No wrote: string s = null; if(s !is null && s[0] == '/') is this correct? No, that doesn't work if the string = "a"[$..$] for example Just use if(s.length && s[0]) instead
How do you check for nonempty string?
s.length > 0 or s !is null? used to C++/C#'s world I cautch myself doing something like this: if(s !is null && s.length > 0 && s[0] == '/) then a I remembered the D's way, which length is probably a function not a property (in the C++/C#'s sense, which needs this as first parameter, hence s.length with s being null would result in error). But it seems it's just enough: string s = null; if(s !is null && s[0] == '/') is this correct?
Re: Passing directory as compiler argument not finding file
On Friday, 13 April 2018 at 12:46:32 UTC, Cym13 wrote: On Friday, 13 April 2018 at 01:27:06 UTC, Tony wrote: I think that the typical model (at least in other languages) is to only compile one D source file at a time. Compile the b.d file with the -c option to create an object file. Then put the object file in a library file (either static (easier) or dynamic). Then you can use the -L compiler option to specify the directory of the library and the -l compiler option to specify the library (library name is shortened - libb.a referenced as -lb). Regardless of whether that would work or not this is the opposite of what's recommended in D. D compilers expect you to compile everything at once, or at least by module. That's where it works best when it comes to optimizations etc. What does "or at least by module" mean? Is it possible to have a module that is made up of more than one source file? What information does a D compiler get when you stick a.d and b.d on the command line that it doesn't get if you compile a.d and import b.d ?
Re: Passing directory as compiler argument not finding file
On Friday, 13 April 2018 at 01:27:06 UTC, Tony wrote: I think that the typical model (at least in other languages) is to only compile one D source file at a time. Compile the b.d file with the -c option to create an object file. Then put the object file in a library file (either static (easier) or dynamic). Then you can use the -L compiler option to specify the directory of the library and the -l compiler option to specify the library (library name is shortened - libb.a referenced as -lb). Regardless of whether that would work or not this is the opposite of what's recommended in D. D compilers expect you to compile everything at once, or at least by module. That's where it works best when it comes to optimizations etc.
Re: trouble building dlang.org
On Tuesday, 10 April 2018 at 15:58:10 UTC, Zach Tollen wrote: I'm trying to update the language spec. I have the standard dmd installed on my Mac in `~/dlang/dmd` using the install script from the website "curl -fsS https://dlang.org/install.sh | bash -s dmd". Okay, good, done. Actually no D installation is needed for building dlang.org (the docs are correct on that one) Now, according to: dlang.org/CONTRIBUTING.md: "git clone https://github.com/dlang/dlang.org cd dlang.org" Okay, done. Now: "make -f posix.mak html" ... So I'm here wondering wuzzup? The basic instructions in CONTRIBUTING.md aren't working. Anyone? Yep, `make -f posix.mak html` should work. The problem was that the auto-checkout of dmd got broken. Here's the fix: https://github.com/dlang/dlang.org/pull/2340
