www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Program exited with code -11

reply "Charles Hawkins" <dummy dummymail.com> writes:
My first attempt at a significant D program and I'm getting:
Error executing command run:
Program exited with code -11

How do I find out what that means?
Jun 22 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 02:34:17 UTC, Charles Hawkins wrote:
 How do I find out what that means?
Many return codes have a meaning in the linux documentation: http://www.tldp.org/LDP/abs/html/exitcodes.html#EXITCODESREF (it lists them as unsigned, but you got a signed result. 128 == -1, so -11 falls under the 128+ section in that table) -11 means it exited with signal 11. Do "man 7 signal" in linux to get the signal documentation overview. One of the lines there is: SIGSEGV 11 Core Invalid memory reference Signal #11 is segmentation fault. Since you're a D newbie, I'm guessing you made the mistake of forgetting to new a class before using it: class Foo {} void main() { Foo foo; foo.something(); // this will segfault, killing the program } That's different than C++, D's classes are more like Java. You need to: Foo foo = new Foo(); or auto foo = new Foo(); so it isn't a null reference.
Jun 22 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 02:45:24 UTC, Adam D. Ruppe wrote:
 128 == -1
I'm sorry, I need to stop posting these things without thinking. -1 is actually 255 when you cast it, but I'm pretty sure the shell just does that subtraction from 128 because of the signal reservation codes. I stand by the rest of the post...
Jun 22 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
Thanks, Adam.  I'm coming from OCaml and haven't seen a seg fault 
in years.  Didn't recognize it. :D  Hopefully I can figure it out 
from here.
Jun 22 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins wrote:
 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.
Try to compile with either ldc or gdc and the -g flag, it should give you a backtrace. dmd seems to not like linux wrt backtraces.
Jun 22 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins wrote:
 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.
Try to compile with either ldc or gdc and the -g flag, it should give you a backtrace. dmd seems to not like linux wrt backtraces.
Thanks. I wish! I haven't had any success in compiling with anything but dub. gdc, dmd, rdmd always give me "module mylib is in file 'mylib.d' which cannot be read" on my "import mylib;" statement. I've tried every permutation of -I and -L that I can think of. It almost appears that one either uses dub for everything or nothing and I'm getting pretty frustrated with it as well. Perhaps I should just go back to old-fashioned make files?
Jun 22 2015
next sibling parent reply "Baz" <bb.temp gmx.com> writes:
On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:
 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:
 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.
Try to compile with either ldc or gdc and the -g flag, it should give you a backtrace. dmd seems to not like linux wrt backtraces.
Thanks. I wish! I haven't had any success in compiling with anything but dub. gdc, dmd, rdmd always give me "module mylib is in file 'mylib.d' which cannot be read" on my "import mylib;" statement. I've tried every permutation of -I and -L that I can think of. It almost appears that one either uses dub for everything or nothing and I'm getting pretty frustrated with it as well. Perhaps I should just go back to old-fashioned make files?
in dmd you have to pass - the .lib/.a files a source - the path to the lib source with '-I'. Sometimes when the path is not well indicated you get the error you talk about. This is because the '-I' path must follow carefully the structure of the lib, e.g 'import myLib.package.moduleThis': the '-I' must point to the folder that contains the folder 'myLib'.
Jun 23 2015
next sibling parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Tuesday, 23 June 2015 at 07:25:05 UTC, Baz wrote:
 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:
 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:
 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.
Try to compile with either ldc or gdc and the -g flag, it should give you a backtrace. dmd seems to not like linux wrt backtraces.
Thanks. I wish! I haven't had any success in compiling with anything but dub. gdc, dmd, rdmd always give me "module mylib is in file 'mylib.d' which cannot be read" on my "import mylib;" statement. I've tried every permutation of -I and -L that I can think of. It almost appears that one either uses dub for everything or nothing and I'm getting pretty frustrated with it as well. Perhaps I should just go back to old-fashioned make files?
in dmd you have to pass - the .lib/.a files a source - the path to the lib source with '-I'. Sometimes when the path is not well indicated you get the error you talk about. This is because the '-I' path must follow carefully the structure of the lib, e.g 'import myLib.package.moduleThis': the '-I' must point to the folder that contains the folder 'myLib'.
Sigh. I'm probably doing something stupid. I tried full paths: dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d /home/charles/projects/d/mylib/build/libmylib.a Same result. myprog.d(4) Error: module mylib is in file 'mylib.d' which cannot be read Statement in myprog is: import mylib; I used tab expansion so I'm confident everything is spelled correctly. Since dub will compile it, I also tried copying and pasting its entry from the local packages file (leaves off the "source/mylib/"). Is there a way to find out what command dub is passing to dmd?
Jun 23 2015
next sibling parent "Charles Hawkins" <dummy dummymail.com> writes:
Ok, I think I've answered my own question.  dub -v tells me what 
I need to know.  Looks like I need to do a separate compile & 
link, make file like, just like the old days, or have a very 
complicated command line.  However, if there is a simple way to 
do the above, which it seems there should be, please let me know.
Jun 23 2015
prev sibling next sibling parent "Charles Hawkins" <dummy dummymail.com> writes:
 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.
...I haven't had any success in compiling with anything but dub. gdc, dmd, rdmd always give me "module mylib is in file 'mylib.d' which cannot be read" on my "import mylib;" statement. ...
in dmd you have to pass - the .lib/.a files a source - the path to the lib source with '-I'. Sometimes when the path is not well indicated you get the error you talk about. This is because the '-I' path must follow carefully the structure of the lib, e.g 'import myLib.package.moduleThis': the '-I' must point to the folder that contains the folder 'myLib'.
... dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d /home/charles/projects/d/mylib/build/libmylib.a Same result. myprog.d(4) Error: module mylib is in file 'mylib.d' which cannot be read Statement in myprog is: import mylib; ...
I used -v to imitate what dub is doing and that works, except that I don't see any reference to the compiled library itself. Apparently it is recompiling the library as well, which defeats the main purpose of having a library in the first place. And gdc doesn't seem to recognize std.experimental.logger which is what I used in converting all my debugging code. Sigh.
Jun 23 2015
prev sibling parent reply "anonymous" <anonymous example.com> writes:
On Tuesday, 23 June 2015 at 07:57:26 UTC, Charles Hawkins wrote:

 Sigh.  I'm probably doing something stupid.  I tried full paths:
 dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d
What's that plus sign doing there? Looks wrong.
 /home/charles/projects/d/mylib/build/libmylib.a
 Same result.
 myprog.d(4) Error: module mylib is in file 'mylib.d' which 
 cannot be read
 Statement in myprog is:
 import mylib;
Jun 23 2015
parent "Charles Hawkins" <dummy dummymail.com> writes:
On Tuesday, 23 June 2015 at 11:18:07 UTC, anonymous wrote:
 On Tuesday, 23 June 2015 at 07:57:26 UTC, Charles Hawkins wrote:

 Sigh.  I'm probably doing something stupid.  I tried full 
 paths:
 dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d
What's that plus sign doing there? Looks wrong.
 /home/charles/projects/d/mylib/build/libmylib.a
 Same result.
 myprog.d(4) Error: module mylib is in file 'mylib.d' which 
 cannot be read
 Statement in myprog is:
 import mylib;
Hey, I was right! Something stupid! I really don't think I made it up. Either I copied from some example that was in error, or was looking at something for another language (I've been looking at several lately) that added to a search path. In any event, I was obviously confused. Thanks, all! I think I'm back on track now. In fact, I've got several test programs working with my library. It isn't so large that compiling it every time was that big of a deal, but nice to know I don't have to.
Jun 23 2015
prev sibling parent "Baz" <bb.temp gmx.com> writes:
On Tuesday, 23 June 2015 at 07:25:05 UTC, Baz wrote:
 in dmd you have to pass
 - the .lib/.a files a source
I meant "as source", actually. you pass the .lib or .a file without switch as if it's a main source.
Jun 23 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:
 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:
 [...]
Try to compile with either ldc or gdc and the -g flag, it should give you a backtrace. dmd seems to not like linux wrt backtraces.
Thanks. I wish! I haven't had any success in compiling with anything but dub. gdc, dmd, rdmd always give me "module mylib is in file 'mylib.d' which cannot be read" on my "import mylib;" statement. I've tried every permutation of -I and -L that I can think of. It almost appears that one either uses dub for everything or nothing and I'm getting pretty frustrated with it as well. Perhaps I should just go back to old-fashioned make files?
you can instruct dub to use other compilers with the --compiler option valid options include dmd,ldc,gdc,gdmd,ldmd
Jun 23 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:
 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:
 [...]
Try to compile with either ldc or gdc and the -g flag, it should give you a backtrace. dmd seems to not like linux wrt backtraces.
Thanks. I wish! I haven't had any success in compiling with anything but dub. gdc, dmd, rdmd always give me "module mylib is in file 'mylib.d' which cannot be read" on my "import mylib;" statement. I've tried every permutation of -I and -L that I can think of. It almost appears that one either uses dub for everything or nothing and I'm getting pretty frustrated with it as well. Perhaps I should just go back to old-fashioned make files?
you can instruct dub to use other compilers with the --compiler option valid options include dmd,ldc,gdc,gdmd,ldmd
Ah, a "sort of" hidden option. I've only been typing "dub" and thus, "dub --help". Didn't think to do "dub build --help". Is there a quick way to get gdc to recognize std.experimental.logger? I'm already spoiled by it. Choosing between it and a backtrace is difficult.
Jun 24 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 24 June 2015 at 07:52:10 UTC, Charles Hawkins wrote:
 On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins 
 wrote:
 [...]
you can instruct dub to use other compilers with the --compiler option valid options include dmd,ldc,gdc,gdmd,ldmd
Ah, a "sort of" hidden option. I've only been typing "dub" and thus, "dub --help". Didn't think to do "dub build --help". Is there a quick way to get gdc to recognize std.experimental.logger? I'm already spoiled by it. Choosing between it and a backtrace is difficult.
I believe it's available as a dub package albeit outdated, should be roughly similar though.
Jun 24 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Wednesday, 24 June 2015 at 16:21:47 UTC, weaselcat wrote:
 On Wednesday, 24 June 2015 at 07:52:10 UTC, Charles Hawkins 
 wrote:
 On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote:
 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins 
 wrote:
 [...]
you can instruct dub to use other compilers with the --compiler option valid options include dmd,ldc,gdc,gdmd,ldmd
[...] Is there a quick way to get gdc to recognize std.experimental.logger? I'm already spoiled by it. Choosing between it and a backtrace is difficult.
I believe it's available as a dub package albeit outdated, should be roughly similar though.
Thanks. I've changed to thread topic to "Help the old man learn D". :) logger package allows those statements to compile with gdc although I'm now getting lots of errors saying "undefined identifier format" even though I'm importing std.format, but not all of them are being flagged. Once I get it to where those are the only errors, perhaps I can figure it out. I'm converting one of my OCaml programs and I have a class (call it Dispatcher) that uses callbacks. With OCaml, it didn't matter if the callbacks were functions or methods but apparently D makes a distinction, which I can understand. I guess this is an opinion question, but should I duplicate Dispatcher's register functions and data structures to handle both, or do I define global functions that call the called-back methods (there's only one instance of the called-back class) and pass those to Dispatcher? Or is there a better way?
Jun 26 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote:
 Thanks.  I've changed to thread topic to "Help the old man 
 learn D". :)  logger package allows those statements to compile 
 with gdc although I'm now getting lots of errors saying 
 "undefined identifier format" even though I'm importing 
 std.format,
I believe the `format` method used to be in `std.string` a few releases ago, try importing that one.
Jun 26 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Friday, 26 June 2015 at 14:52:51 UTC, Marc Schütz wrote:
 On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote:
 Thanks.  I've changed to thread topic to "Help the old man 
 learn D". :)  logger package allows those statements to 
 compile with gdc although I'm now getting lots of errors 
 saying "undefined identifier format" even though I'm importing 
 std.format,
I believe the `format` method used to be in `std.string` a few releases ago, try importing that one.
Thank you! That explains why it wasn't flagging all of them since some of my modules import std.string as well. I think I've answered my own question regarding the callbacks as well. I realized that the only reason I made those sections of code classes in OCaml, even though there would only be one instance of them, was so I could do forward referencing. I'm hoping that I'll get function pointers instead of delegate pointers if I convert the class back to a module.
Jun 26 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Friday, 26 June 2015 at 15:33:25 UTC, Charles Hawkins wrote:
 On Friday, 26 June 2015 at 14:52:51 UTC, Marc Schütz wrote:
 On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote:
[...]
I think I've answered my own question regarding the callbacks as well. I realized that the only reason I made those sections of code classes in OCaml, even though there would only be one instance of them, was so I could do forward referencing. I'm hoping that I'll get function pointers instead of delegate pointers if I convert the class back to a module.
Sorry for talking to myself, but I'm hoping someone will help me out. The above idea doesn't work. It appears that only the main program file is going to have function pointers while modules and classes will have delegates. So, does a library that uses callbacks need 2 callback register functions as well as parallel storage mechanisms, or is there a fairly simple way to make it polymorphic? I was hoping a newbie would be able to use this library, but not many newbies are going to understand this. I suppose I could tell them to call registerFunction and if they get a compiler error, then call registerDelegate? Or am I missing something?
Jun 26 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 26 June 2015 at 16:57:14 UTC, Charles Hawkins wrote:
 Sorry for talking to myself, but I'm hoping someone will help 
 me out.  The above idea doesn't work.  It appears that only the 
 main program file is going to have function pointers while 
 modules and classes will have delegates.  So, does a library 
 that uses callbacks need 2 callback register functions as well 
 as parallel storage mechanisms, or is there a fairly simple way 
 to make it polymorphic?  I was hoping a newbie would be able to 
 use this library, but not many newbies are going to understand 
 this.  I suppose I could tell them to call registerFunction and 
 if they get a compiler error, then call registerDelegate?  Or 
 am I missing something?
I don't fully understand what you're doing, but functions can easily be turned into delegates using std.functional.toDelegate [1]: import std.functional : toDelegate; registerDelegate((&topLevelFunction).toDelegate); [1] http://dlang.org/phobos/std_functional.html#.toDelegate
Jun 26 2015
parent "Charles Hawkins" <dummy dummymail.com> writes:
On Friday, 26 June 2015 at 17:11:54 UTC, Marc Schütz wrote:
 On Friday, 26 June 2015 at 16:57:14 UTC, Charles Hawkins wrote:
[...]
I don't fully understand what you're doing, but functions can easily be turned into delegates using std.functional.toDelegate [1]: import std.functional : toDelegate; registerDelegate((&topLevelFunction).toDelegate); [1] http://dlang.org/phobos/std_functional.html#.toDelegate
Thanks, Marc. That should work if my brute force duplicate code doesn't. Thanks to everyone, at long last my project compiles with dmd. It crashes right away, but that's not unexpected since I haven't used pointers in several years. Unfortunately, compiling with gdc spits out a bunch of errors regarding getopt so I'm back to sprinkling log statements to find the problem.
Jun 26 2015