>>>> 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.

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;

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.

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

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.

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.

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?

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.

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.

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?