Re: Adding linker paths with spaces using dmd and msvc toolchain
On Friday, 30 December 2016 at 04:56:59 UTC, Jerry wrote: On Friday, 30 December 2016 at 03:51:13 UTC, Jeremy DeHaan wrote: How does one correctly add a linker path that has spaces? The quotes get consumed by the command line. The way DMD spawns the linker by creating a new string with all the flags. So it smashes everything into a new string, ignoring how the string was passed into DMD. I think you can use triple quotes, """string with space""", and it should make the string passed to DMD include the string. Might be different for powershell. You mean I could do -L/LIBPATH:"""path"""?
Adding linker paths with spaces using dmd and msvc toolchain
I have a path to where some .libs are, and this path has some spaces in it. Using dmd and the msvc toolchain, I only seem to be able to correctly link .lib files if I pass them to the compiler with their full paths, or if I give the linker a relative path. When I add -L/LIBPATH:"path" to the command line, it ends up looking like this: -L/LIBPATH:"C:\Users\Jeremy DeHaan\Desktop\CODE\dsfml\lib". The linker will complain that it cannot open input file 'DeHaan\Desktop\CODE\dsfml\lib.obj'. How does one correctly add a linker path that has spaces?
Re: understanding std.algorithm.mutation.fill behaivor.
On Wednesday, 28 December 2016 at 08:27:29 UTC, abad wrote:
On Wednesday, 28 December 2016 at 08:10:41 UTC, Nemanja Boric
wrote:
On Wednesday, 28 December 2016 at 05:09:34 UTC, LeqxLeqx wrote:
Perhaps this is a stupid question, and I apologize if it is,
but why doesn't this compile:
import std.algorithm;
import std.stdio;
void main()
{
char[] array = [1, 2, 3, 4];
char value = 2;
fill(array, value);
}
if this does:
import std.algorithm;
import std.stdio;
void main()
{
int[] array = [1, 2, 3, 4];
int value = 2;
fill(array, value);
}
when the only difference is the type, and the 'fill' method
is meant to be generic?
Thanks for your time.
So I don't repeat excellent answer:
http://stackoverflow.com/a/6401889/133707
So in short, unlike in C/C++ world, you should only use char to
store actual text, not data as would be common in C/C++. byte &
ubyte are for that.
I see. That's good to know. Thank you both so much!
Re: Unittest hangs on completion
On Friday, 30 December 2016 at 01:25:50 UTC, Steven Schveighoffer wrote: Looks like that comes from here: https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577 I have serious doubts that this is the correct way to run tests, as share ctors are supposed to have run BEFORE unit tests are allowed to. It's quite possible (and likely) that unit tests are running before critical other shared ctors have completed, which is why something isn't working. In any case, it looks like the unit tests have run, and run successfully, and then main has run, and then it's the teardown of the runtime that's hanging. I'm not 100% certain, because I don't know exactly how this code comes into play -- it's a string in this file. -Steve Huh, shouldn't this problem have manifested itself earlier then? Why only now? I don't remember this happening previously. At the very least I'm pretty sure I first encountered it last week. Unless something in DMD was patched? But then there'd be no way I'm the only one encountering this problem, and there don't appear to be any issues on github's tracker.
Re: Unittest hangs on completion
On 12/29/16 7:49 PM, David Zhang wrote: On Friday, 30 December 2016 at 00:44:50 UTC, Steven Schveighoffer wrote: Where does the "All unit tests have been completed successfully." message come from? That's not standard D, which prints nothing. I should have mentioned that I use dub then, shouldn't I? Anyway, this is what I get: C:\Users\David\Projects\weave>dub test Generating test runner configuration '__test__library__' for 'library' (library). Performing "unittest" build using dmd for x86. weave ~master: building configuration "__test__library__"... Linking... Running .\bin\__test__library__.exe All unit tests have been run successfully. Looks like that comes from here: https://github.com/dlang/dub/blob/master/source/dub/dub.d#L577 I have serious doubts that this is the correct way to run tests, as share ctors are supposed to have run BEFORE unit tests are allowed to. It's quite possible (and likely) that unit tests are running before critical other shared ctors have completed, which is why something isn't working. In any case, it looks like the unit tests have run, and run successfully, and then main has run, and then it's the teardown of the runtime that's hanging. I'm not 100% certain, because I don't know exactly how this code comes into play -- it's a string in this file. -Steve
Re: Unittest hangs on completion
On Friday, 30 December 2016 at 00:44:50 UTC, Steven Schveighoffer wrote: Where does the "All unit tests have been completed successfully." message come from? That's not standard D, which prints nothing. -Steve I should have mentioned that I use dub then, shouldn't I? Anyway, this is what I get: C:\Users\David\Projects\weave>dub test Generating test runner configuration '__test__library__' for 'library' (library). Performing "unittest" build using dmd for x86. weave ~master: building configuration "__test__library__"... Linking... Running .\bin\__test__library__.exe All unit tests have been run successfully.
Re: Unittest hangs on completion
On 12/29/16 3:27 PM, David Zhang wrote: Hi, I've noticed recently, that whenever I unittest, it program hangs either at the very end, or right before they start. When using vanilla unit tests, the program appears to hang after the "All unit tests have been completed successfully." message, and I have to force to program to exit. However, when I use unit-threaded for my unit testing, it gets to the "Running unit tests in dirs ["."]" and then refuses to do anything more. Strangely enough, sometimes commenting out one or two tests seems to fix the issue with unit-threaded, only to resurface when I write a new test. Just what is going on? Where does the "All unit tests have been completed successfully." message come from? That's not standard D, which prints nothing. -Steve
Re: Unittest hangs on completion
On Thursday, 29 December 2016 at 20:50:54 UTC, David Zhang wrote:
On Thursday, 29 December 2016 at 20:33:33 UTC, Stefan Koch
wrote:
It would be very helpful if you could provide example code
that triggers that behavior.
I'd love to, but I'm not actually sure just what it is that
breaks it. I can provide the git repo for one of them though
though:
https://gitlab.com/Straivers/Weave
https://gitlab.com/Straivers/Weave.git
Ok, so after further fiddling, it seems to originate from here:
[from the list class]
@safe unittest {
class A {
int foo;
}
auto list = new List!A();
list ~= [new A, new A, new A];
assert(list.findElement(null).result == null);
}
However, commenting it out, and replacing it with another block
(the test immediately below it, causes it to hang too, or error
out and crash without any error message.
Re: delegate passed in annotation struct cannot be invoked.
On Thursday, 29 December 2016 at 21:19:18 UTC, Alexandru Ermicioi wrote: On Thursday, 29 December 2016 at 21:07:00 UTC, Stefan Koch wrote: It's a delegate and not function. Therefore it will get a frame-ptr regardless, without checking if it is needed or not, or if there is a frame to point to. Since there is no frame to point to you get the error. At least this is my guess. Make the delegate a function and the error should disappear. Yep, making it a function, will eliminate the problem. Though what I'm also curious is why on LDC it compiles and runs, while on DMD it does not? Should it be registered as a bug on issues.dlang.org, or at ldc bug tracker? ldc accepts invalid code there. But it might be that dmd 2.071.2 did that as well. If so It will be fixed as soon as ldc updates the front-end version.
Re: delegate passed in annotation struct cannot be invoked.
On Thursday, 29 December 2016 at 21:07:00 UTC, Stefan Koch wrote: It's a delegate and not function. Therefore it will get a frame-ptr regardless, without checking if it is needed or not, or if there is a frame to point to. Since there is no frame to point to you get the error. At least this is my guess. Make the delegate a function and the error should disappear. Yep, making it a function, will eliminate the problem. Though what I'm also curious is why on LDC it compiles and runs, while on DMD it does not? Should it be registered as a bug on issues.dlang.org, or at ldc bug tracker?
Re: delegate passed in annotation struct cannot be invoked.
On Thursday, 29 December 2016 at 20:55:43 UTC, Alexandru Ermicioi
wrote:
Given code below:
import std.stdio;
struct Annotation {
public int delegate(int) dg;
}
void main() {
import std.traits;
__traits(getAttributes, Cls)[0].dg(20).writeln;
}
@Annotation(delegate int(int d) {
return d;
})
class Cls {
void method() {
}
}
Dmd will complain with following statement for the delegate
passed in annotation:
src/app.d(13,13): Error: delegate app.__dgliteral6 is a nested
function and cannot be accessed from D main.
GDC will just throw internal compiler exception:
src/app.d: In function ‘D main’:
src/app.d:20:2: internal compiler error: in
get_frame_for_symbol, at d/d-codegen.cc:3981
__traits(getAttributes, Cls)[0].dg(20).writeln;
^
LDC will not argue, and compile it flawlessly, and return 20 as
expected.
So the question, is the dmd error correct behavior?
If so, how the delegate is nested, and what is context that it
is nested in?
DMD version is: v2.072.1
LDC version is: v1.1.0 based on v2.071.2 and LLVM 3.8.1
GDC version is: 6.2.1 20161215
It's a delegate and not function.
Therefore it will get a frame-ptr regardless, without checking if
it is needed or not, or if there is a frame to point to.
Since there is no frame to point to you get the error.
At least this is my guess.
Make the delegate a function and the error should disappear.
delegate passed in annotation struct cannot be invoked.
Given code below:
import std.stdio;
struct Annotation {
public int delegate(int) dg;
}
void main() {
import std.traits;
__traits(getAttributes, Cls)[0].dg(20).writeln;
}
@Annotation(delegate int(int d) {
return d;
})
class Cls {
void method() {
}
}
Dmd will complain with following statement for the delegate
passed in annotation:
src/app.d(13,13): Error: delegate app.__dgliteral6 is a nested
function and cannot be accessed from D main.
GDC will just throw internal compiler exception:
src/app.d: In function ‘D main’:
src/app.d:20:2: internal compiler error: in get_frame_for_symbol,
at d/d-codegen.cc:3981
__traits(getAttributes, Cls)[0].dg(20).writeln;
^
LDC will not argue, and compile it flawlessly, and return 20 as
expected.
So the question, is the dmd error correct behavior?
If so, how the delegate is nested, and what is context that it is
nested in?
DMD version is: v2.072.1
LDC version is: v1.1.0 based on v2.071.2 and LLVM 3.8.1
GDC version is: 6.2.1 20161215
Re: Unittest hangs on completion
On Thursday, 29 December 2016 at 20:33:33 UTC, Stefan Koch wrote: It would be very helpful if you could provide example code that triggers that behavior. I'd love to, but I'm not actually sure just what it is that breaks it. I can provide the git repo for one of them though though: https://gitlab.com/Straivers/Weave https://gitlab.com/Straivers/Weave.git
Re: Unittest hangs on completion
On Thursday, 29 December 2016 at 20:27:21 UTC, David Zhang wrote: Hi, I've noticed recently, that whenever I unittest, it program hangs either at the very end, or right before they start. When using vanilla unit tests, the program appears to hang after the "All unit tests have been completed successfully." message, and I have to force to program to exit. However, when I use unit-threaded for my unit testing, it gets to the "Running unit tests in dirs ["."]" and then refuses to do anything more. Strangely enough, sometimes commenting out one or two tests seems to fix the issue with unit-threaded, only to resurface when I write a new test. Just what is going on? It would be very helpful if you could provide example code that triggers that behavior.
Unittest hangs on completion
Hi, I've noticed recently, that whenever I unittest, it program hangs either at the very end, or right before they start. When using vanilla unit tests, the program appears to hang after the "All unit tests have been completed successfully." message, and I have to force to program to exit. However, when I use unit-threaded for my unit testing, it gets to the "Running unit tests in dirs ["."]" and then refuses to do anything more. Strangely enough, sometimes commenting out one or two tests seems to fix the issue with unit-threaded, only to resurface when I write a new test. Just what is going on?
Re: Explain the Modules to me but better...
On Thursday, 29 December 2016 at 18:20:22 UTC, Modules Confuse Me wrote: I'm really getting hung up on a simple thing, such as how to structure my program in the 'D' way. So correct me if I am wrong. In my packages, I should be using 'public' imports correct? So that the imports get forwarded. I'm looking through phobos, to try to get a good idea of how others do it, and I don't see myself doing things too differently... I don't use packages, but there are quite a few examples on code.dlang.org. Here's a random one that I selected: https://github.com/kotet/progress/tree/master/source/progress
Re: Explain the Modules to me but better...
On Thursday, 29 December 2016 at 19:00:25 UTC, Nemanja Boric wrote: On Thursday, 29 December 2016 at 18:20:22 UTC, Modules Confuse Me wrote: [...] If you have following: [...] This all is valid, of course, only if I guessed right your problem :-)
Re: Explain the Modules to me but better...
On Thursday, 29 December 2016 at 18:20:22 UTC, Modules Confuse Me
wrote:
I'm trying to get going with D, but I keep getting hung up on
modules. I personally like having many smaller files. Generally
classes and interfaces all go into their own file. Even if the
overall file ends up being smaller than 10 lines of real code.
After reading:
https://dlang.org/spec/module.html
I seem to have at least enough information to get things
working, but things break down after I start trying to package
everything up into packages. Because it's a pain in the butt to
have to include my interface files in separate imports than the
implemented classes. So, I see D has packages, but whenever I
use them I start getting errors like:
Error: linker exited with status 180314872
I'm really getting hung up on a simple thing, such as how to
structure my program in the 'D' way. So correct me if I am
wrong. In my packages, I should be using 'public' imports
correct? So that the imports get forwarded. I'm looking through
phobos, to try to get a good idea of how others do it, and I
don't see myself doing things too differently...
If you have following:
```
main.d
import a.mod;
import a.mod2;
void main() {
foo();
bar();
}
```
```
a/mod.d
module a.mod;
void foo() {}
```
```
a/mod2.d
module a.mod2;
void bar() {}
```
And you try to compile this with
```
dmd main.d
```
you will get the following error (depends on your system)
```
main.o: In function `_Dmain':
main.d:(.text._Dmain+0x5): undefined reference to
`_D1a3mod3fooFZv'
main.d:(.text._Dmain+0xa): undefined reference to
`_D1a4mod23barFZv'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
```
The reason for this is that dmd doesn't build any module except
the ones in the command line (main.d in your case). So, when it
tries to link, it will not find object files for foo and bar that
are contained in the different module.
Solution could be to pass all files to dmd, so it will build them
all:
```
dmd main.d a/mod.d a/mod2.d
```
or to use `rdmd` which will figure out which files needs
building, so it will
do that for you manually:
```
rdmd main.d
```
Explain the Modules to me but better...
I'm trying to get going with D, but I keep getting hung up on modules. I personally like having many smaller files. Generally classes and interfaces all go into their own file. Even if the overall file ends up being smaller than 10 lines of real code. After reading: https://dlang.org/spec/module.html I seem to have at least enough information to get things working, but things break down after I start trying to package everything up into packages. Because it's a pain in the butt to have to include my interface files in separate imports than the implemented classes. So, I see D has packages, but whenever I use them I start getting errors like: Error: linker exited with status 180314872 I'm really getting hung up on a simple thing, such as how to structure my program in the 'D' way. So correct me if I am wrong. In my packages, I should be using 'public' imports correct? So that the imports get forwarded. I'm looking through phobos, to try to get a good idea of how others do it, and I don't see myself doing things too differently...
Re: Android Status
On Thursday, 29 December 2016 at 10:14:53 UTC, Joakim wrote: On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote: What is the current status for building android apps in D? I would like to create simple graphic based apps but don't wanna get bogged down in trying to get car moving without any wheels. Should all work, but nothing other than small apps have been tested. Try the latest beta, which I just put up: http://forum.dlang.org/post/xetfqojxijgobisfa...@forum.dlang.org If you want something more substantive than my ports of the NDK's sample apps, check out Vadim's Tetris app, which I spent half an hour playing on my phone, :) or his minecraft-like demo (click on the sourceforge link from his forum post to get the apps): http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org Let me know if you have any questions or problems. Thanks, hopefully it works. Had to upgrade to win10 aniversary and it destroyed my system so I am now in the process of getting it back to normal. Hopefully this Bash on Ubuntu is worth it and everything works as advertised...
Re: Android Status
On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote: What is the current status for building android apps in D? I would like to create simple graphic based apps but don't wanna get bogged down in trying to get car moving without any wheels. Should all work, but nothing other than small apps have been tested. Try the latest beta, which I just put up: http://forum.dlang.org/post/xetfqojxijgobisfa...@forum.dlang.org If you want something more substantive than my ports of the NDK's sample apps, check out Vadim's Tetris app, which I spent half an hour playing on my phone, :) or his minecraft-like demo (click on the sourceforge link from his forum post to get the apps): http://forum.dlang.org/thread/cdekkumjynhqoxvmg...@forum.dlang.org Let me know if you have any questions or problems.
Re: Android Status
On Wednesday, 28 December 2016 at 23:33:57 UTC, Ignacious wrote: What is the current status for building android apps in D? I would like to create simple graphic based apps but don't wanna get bogged down in trying to get car moving without any wheels. https://forum.dlang.org/thread/ovkhtsdzlfzqrqneo...@forum.dlang.org?page=2
Re: CTFE difference between dmd and ldc2
On Thursday, 29 December 2016 at 09:24:23 UTC, Joseph Rushton Wakeling wrote: On Tuesday, 27 December 2016 at 22:34:50 UTC, Johan Engelen wrote: Do you see the same with dmd 2.071? (that's the same front-end code as the LDC version tested) Sorry for delay in following up on this. Yes, the same problem occurs with dmd 2.071 (as installed from the deb package downloaded from dlang.org). Specifically, I tested with 2.071.2, which I understand is the exact same frontend version as LDC 1.1.0-beta6. So, looks like the issue could be backend-related?
Re: CTFE difference between dmd and ldc2
On Tuesday, 27 December 2016 at 22:34:50 UTC, Johan Engelen wrote: On Tuesday, 27 December 2016 at 17:56:07 UTC, Stefan Koch wrote: I doubt that this is a CTFE bug since there should be little difference in the ctfe code between ldc and dmd. That said, it is of course a possibility. Do you see the same with dmd 2.071? (that's the same front-end code as the LDC version tested) Sorry for delay in following up on this. Yes, the same problem occurs with dmd 2.071 (as installed from the deb package downloaded from dlang.org).
