Re: Best memory management D idioms
On 03/08/2017 02:15 AM, XavierAP wrote: I see the default allocator is the same GC heap used by 'new'. Just for my learning curiosity, does this mean that if I theAllocator.make() something and then forget to dispose() it, it will be garbage collected the same once no longer referenced? And so are these objects traversed by the GC? Yes and yes. GCAllocator.allocate calls core.memory.GC.malloc with does pretty much the same thing as the builtin `new`. One difference might be with preciseness. `new` can take the type into account and automatically mark the allocation as NO_SCAN. I'm not sure if GCAllocator can do that. Maybe if you use `make`/`makeArray` to make the allocations. I've also looked at mallocator, [2] can it be used in some way to provide an allocator instead of the default theAllocator? As far as I can tell mallocator is not enough to implement an IAllocator, is there a reason, or where's the rest, am I missing it? To make an IAllocator, use std.experimental.allocator.allocatorObject. The example in the documentation shows how it's done. https://dlang.org/phobos/std_experimental_allocator.html#.allocatorObject
Re: DMD + Dynamic Library.
You have to use "export" for any symbol to be visible from a dll. On Windows by default nothing is exported.
DMD + Dynamic Library.
Hi everyone. My first post here - I'm not one to usually resort
to trying to ask forums directly for help but I'm a bit desperate
at this point as I have wasted about 3 days in total of no-life
googling trying to figure something out here.
My current setup works fine for creation of EXE's and Static
libs. Dynamic libs are the only problem. I have some libraries I
created and used just fine with static libs that I'd like to
start using dynamically as managing them with multiple projects
has just become too cumbersome.
My setup uses Mono-D using -shared and -H(-shared should already
be called as it already generated .lib and .dll files but I added
again just in case) and creating a new EXE project and trying to
use the functions from the generated .di files works fine -> As
long as the lib was generated static. While attempting to use
dynamic generated .lib I always get the error "Library Reference
Missing".
On each of my source files I've attempted adding export
extern(D): right after Module declaration(Which again works just
fine when using static edition of .lib) as well as I've used this
for the dllmain (Which has only been modified slightly from the
ones in guides)
version(Windows) {
import core.sys.windows.windows : HINSTANCE;
extern(Windows) bool DllMain(HINSTANCE hInstance, uint ulReason,
void* reserved) {
import core.sys.windows.dll, core.sys.windows.windows;
switch(ulReason) {
default: assert(0);
case DLL_PROCESS_ATTACH: return dll_process_attach( hInstance,
true );
case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true
); return true;
case DLL_THREAD_ATTACH: return dll_thread_attach( true,
true );
case DLL_THREAD_DETACH: return dll_thread_detach( true,
true );
}
}
}
I've compiled EVERYTHING into x32 for windows and this being of
course with the latest dmd2 compiler.
I'm all out of ideas here. From some of the threads I've come
across researching the .def files that were in the main guides
aren't needed as long as using the export extern(D): however
whether or not they are actually needed or not -> Either the
compiler or linker were throwing errors(I cant remember which).
I've even tried running .def made for example modules as well and
it gave the same error so i know i wasn't just making it
improperly.
I'm literally a couple tests from pulling my hair out so any
wisdom on this issue would be greatly appreciated!
Re: DUB specify version identifier on command line?
On Tuesday, 7 March 2017 at 22:30:30 UTC, XavierAP wrote: I'm talking about the conditional compilation keyword "version", not about version strings. I've looked in DUB's help and reference [1][2] but can't seem to find how to solve my problem. On the command line it seems to be possible to specify debug identifiers, but not version identifiers. [3] It came up while trying to do something specific, so I'll explain this. I'm learning and trying things, and I was playing with dlib.core.memory. Before moving to the next thing I wanted to try printMemoryLog(). This outputs memory debugging info, only when compiled with version(MemoryDebug) [3]. I'm working with Visual D. However for 3rd party package dependencies it's simpler to compile them with dub, and have VS find the lib for my client project. Without the version identifier, my program works: compiles, links to dlib, and runs ok. Then I instruct VS to define version(MemoryDebug) for some configuration. No matter how I re-run dub to build dlib, I get linking errors from the additional functions defined in the imported dlib source which aren't found in the binary lib. I guess it's also possible to specify this by adding to the dub.json file [2], but for me it's more flexible if I can leave it alone and compile different versions from the command line alone. But if the json is the only way please let me know. Otherwise what am I missing? Thanks in advance. [1] http://code.dlang.org/docs/commandline#build [2] http://code.dlang.org/package-format?lang=json#version-specs [3] https://dlang.org/spec/version.html#DebugCondition [4] https://github.com/gecko0307/dlib/blob/master/dlib/core/memory.d Setting version identifiers is done by the `-version=ident` command line flag (this is equivalent to `version = ident` at source level) . This should therefore be settable by the "dflags" dub configuration setting. The way I would do it would be to have a custom configuration that sets "dflags" : [ "other normal flags", "-version= MemoryDebug"] and then build the MemoryDebug dub configuration. Hope that makes sense.
Re: Best memory management D idioms
On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote: To avoid this from the beginning, it may be better to use allocators. You can use "make" and "dispose" from std.experimental.allocator the same way as New/Delete. OK I've been reading on std.experimental.allocator; it looks really powerful and general, more than I need. I see the potential but I don't really have the knowledge to tweak memory management, and the details of the "building blocks" are well beyond me. But even if I don't go there, I guess it's a good thing that I can change my program's allocator by changing one single line or version assigning theAllocator, and benchmark the results among different possibilities. I see the default allocator is the same GC heap used by 'new'. Just for my learning curiosity, does this mean that if I theAllocator.make() something and then forget to dispose() it, it will be garbage collected the same once no longer referenced? And so are these objects traversed by the GC? I've also looked at mallocator, [2] can it be used in some way to provide an allocator instead of the default theAllocator? As far as I can tell mallocator is not enough to implement an IAllocator, is there a reason, or where's the rest, am I missing it? [1] https://dlang.org/phobos/std_experimental_allocator.html [2] https://dlang.org/phobos/std_experimental_allocator_mallocator.html
Re: DMD Refuses to Compile Multiple Source Files
On Wednesday, 18 January 2017 at 04:25:42 UTC, Mike Parker wrote: extern(C), not simply extern. It turns off the name mangling. But really, the proper thing to do is to drop the prototype and import the module with the implementation. It's tge way modules are intended to be used. Unless you're doing something specidic like writing a library that calls an arbitrary user function. Alright, so I misunderstood what ketmar was saying. His solution did work. I'm just not sure I understand what you are trying to say here: I've started using dub for things, and I've learned a lot since this thread. Anyway, thanks for the support with this everybody.
Re: Date formatting in D
On Tuesday, March 07, 2017 22:15:39 Daniel Kozak via Digitalmars-d-learn wrote: > I do not know? Is this some ISO/ANSI format for dates? If yes than we > should add it. If no there is no reason. The ISO formats are already there. There's to/fromISOString and to/fromISOExtString on SysTime, DateTime, Date, and TimeOfDay. What's missing is custom date/time formatting, and it's on my todo list, but I've had enough other stuff going on that I haven't gotten around to it even though I should have done it ages ago. - Jonathan M Davis
Re: Problems with setting up dub for publication
On Sunday, 5 March 2017 at 01:54:22 UTC, Mike Parker wrote: ... I was getting the same problem and created on issue on this project's repository (https://github.com/ZILtoid1991/pixelperfectengine), which I think (although I don't know) was the reason this thread was created. Using the dub.json that I added in that PR will compile. However, since I didn't actually write any code, I doubt that if I imported anything from pixelperfect that it would still work. This is an issue I saw somewhere else... Anyway, building "pixelperfectengine:pixelperfectengine": "*" works with the hello world app.d, although like I said, probably will not if I try to import anything from pixelperfect. Building "pixelperfectengine": "~>0.9.1-rc2" does not work, it still gives me the linker error from the top of this thread. I like dub too. It has worked well for me and seems to be much lighter and less of a mess than at least some IDE's. Right now I finished fixing the d-struct package for the atom text editor, which adds dub support for that, so I don't have to use the command line hardly at all :P. In any case, dub is a great tool, and works well most of the time.
DUB specify version identifier on command line?
I'm talking about the conditional compilation keyword "version", not about version strings. I've looked in DUB's help and reference [1][2] but can't seem to find how to solve my problem. On the command line it seems to be possible to specify debug identifiers, but not version identifiers. [3] It came up while trying to do something specific, so I'll explain this. I'm learning and trying things, and I was playing with dlib.core.memory. Before moving to the next thing I wanted to try printMemoryLog(). This outputs memory debugging info, only when compiled with version(MemoryDebug) [3]. I'm working with Visual D. However for 3rd party package dependencies it's simpler to compile them with dub, and have VS find the lib for my client project. Without the version identifier, my program works: compiles, links to dlib, and runs ok. Then I instruct VS to define version(MemoryDebug) for some configuration. No matter how I re-run dub to build dlib, I get linking errors from the additional functions defined in the imported dlib source which aren't found in the binary lib. I guess it's also possible to specify this by adding to the dub.json file [2], but for me it's more flexible if I can leave it alone and compile different versions from the command line alone. But if the json is the only way please let me know. Otherwise what am I missing? Thanks in advance. [1] http://code.dlang.org/docs/commandline#build [2] http://code.dlang.org/package-format?lang=json#version-specs [3] https://dlang.org/spec/version.html#DebugCondition [4] https://github.com/gecko0307/dlib/blob/master/dlib/core/memory.d
Re: Passing macros from commandline or enumerating versions
The way I like to do it is to pass a module on the command line that contains the custom config. So in the app: --- import myapp.config; // use the variables defined in there like normal --- Now, to define a config file, you do something like: myconfiguration.d # note that the file name can be anything! --- module myapp.config; // but each must use this same module config enum some_key = "some_value"; // and so on --- Now, when you compile, you build it with a particular config by passing one of those files to the compile: dmd myapp.d myconfiguration.d # or whatever single config you want Then you can define as much as you want in the config module, and have as many of them as you want too.
Passing macros from commandline or enumerating versions
Hi, I was wondering, if there is a way to pass a macro with value to the compiled program, i.e., something like -Dfoo="bar". And if that is not possible, if there is a way to enumerate all set versions. I want my application built with different string imported configurations and I have no idea how to tell compiler which configuration to choose, other than hardcoding it. Thanks, Martin
Re: Date formatting in D
Dne 7.3.2017 v 21:29 aberba via Digitalmars-d-learn napsal(a): I've been trying to figure out an inbuilt functionality in phobos for formatting date. In my use case, I've been trying to format current Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT". How do I go by this easily (Currently, long concatenation of strings is what I'm thinking)? I saw this thread[1] from 2011 on similar issue. Has it been resolved? What is the state of toCustomString? [1] http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com Sorry for my previous comments. I have not been reading this post carefully. AFAIK you want some universal (general) format method for dates. This make sense. So if you write pull request I believe it will be accepted.
Re: Date formatting in D
Dne 7.3.2017 v 22:07 aberba via Digitalmars-d-learn napsal(a): On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote: I've been trying to figure out an inbuilt functionality in phobos for formatting date. In my use case, I've been trying to format current Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT". How do I go by this easily (Currently, long concatenation of strings is what I'm thinking)? I saw this thread[1] from 2011 on similar issue. Has it been resolved? What is the state of toCustomString? [1] http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com Just found this http://code.dlang.org/packages/datetimeformat. Why is Phobos not still not having this in 2017? I have looked at some of our many years old codebase and we use http://dlang.org/phobos/std_format.html#.formattedRead and http://dlang.org/phobos/std_format.html#.formattedWrite
Re: Date formatting in D
I do not know? Is this some ISO/ANSI format for dates? If yes than we should add it. If no there is no reason. Dne 7.3.2017 v 22:07 aberba via Digitalmars-d-learn napsal(a): On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote: I've been trying to figure out an inbuilt functionality in phobos for formatting date. In my use case, I've been trying to format current Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT". How do I go by this easily (Currently, long concatenation of strings is what I'm thinking)? I saw this thread[1] from 2011 on similar issue. Has it been resolved? What is the state of toCustomString? [1] http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com Just found this http://code.dlang.org/packages/datetimeformat. Why is Phobos not still not having this in 2017?
Re: Date formatting in D
On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote: I've been trying to figure out an inbuilt functionality in phobos for formatting date. In my use case, I've been trying to format current Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT". How do I go by this easily (Currently, long concatenation of strings is what I'm thinking)? I saw this thread[1] from 2011 on similar issue. Has it been resolved? What is the state of toCustomString? [1] http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com Just found this http://code.dlang.org/packages/datetimeformat. Why is Phobos not still not having this in 2017?
Re: Date formatting in D
On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote: I've been trying to figure out an inbuilt functionality in phobos for formatting date. In my use case, I've been trying to format current Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT". How do I go by this easily (Currently, long concatenation of strings is what I'm thinking)? I saw this thread[1] from 2011 on similar issue. Has it been resolved? What is the state of toCustomString? [1] http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com Straightforward solution: https://dlang.org/library/core/stdc/time/strftime.html http://man7.org/linux/man-pages/man3/strftime.3.html Maybe there is something better.
Re: Best memory management D idioms
On Tuesday, 7 March 2017 at 20:15:37 UTC, XavierAP wrote: On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote: To avoid this from the beginning, it may be better to use allocators. You can use "make" and "dispose" from std.experimental.allocator the same way as New/Delete. Thanks! looking into it. Does std.experimental.allocator have a leak debugging tool like dlib's printMemoryLog()? Yes, but printMemoryLog is anyway useful only for simple searching for memory leaks. For the advanced debugging it is anyway better to learn some memory debugger or profiler.
Date formatting in D
I've been trying to figure out an inbuilt functionality in phobos for formatting date. In my use case, I've been trying to format current Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT". How do I go by this easily (Currently, long concatenation of strings is what I'm thinking)? I saw this thread[1] from 2011 on similar issue. Has it been resolved? What is the state of toCustomString? [1] http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com
Re: Best memory management D idioms
On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote: To avoid this from the beginning, it may be better to use allocators. You can use "make" and "dispose" from std.experimental.allocator the same way as New/Delete. Thanks! looking into it. Does std.experimental.allocator have a leak debugging tool like dlib's printMemoryLog()?
removing module level from ddox output
Is there a way to flatten out the documentation hierarchy generated by ddox? To be more clear, when we generate documentation with dub -b ddox, the main page lists all my modules, and each module page lists all the classes in that module, etc. I want to remove the modules from the main page and just list my classes as if they were in a single module without having to put everything in a single file. We can already do this from a code point of view by publicly importing stuff in package.d, so from the user's perspective there is only a single module with some classes in it (they don't have to worry about how I organized things in various files). Is there a way to make the documentation match this simple import paradigm? I suspect it's possible by redefining some ddoc macros in package.d, but I'm not quite sure how to go about it or if there's and easier way. Thanks!
Re: Best memory management D idioms
On Tuesday, 7 March 2017 at 17:37:43 UTC, XavierAP wrote: On Tuesday, 7 March 2017 at 16:51:23 UTC, Kagamin wrote: There's nothing like that of C++. Don't you think New/Delete from dlib.core.memory fills the bill? for C++ style manual dynamic memory management? It looks quite nice to me, being no more than a simple malloc wrapper with constructor/destructor calling and type safety. Plus printMemoryLog() for debugging, much easier than valgrind. do you want to manage non-memory resources with these memory management mechanisms too? I wasn't thinking about this now, but I'm sure the need will come up. Yes. For simple memory management New/Delete would be enough. But you depend on your libc in this case, that is mostly not a problem. From experience it wasn't enough for some code bases, so the C-world invented some work arounds: 1) Link to an another libc providing a different malloc/free implementations 2) Use macros that default to the libc's malloc/free, but can be set at compile time to an alternative implementation (mbedtls uses for example mbedtls_malloc, mbedtls_calloc and mbedtls_free macros) To avoid this from the beginning, it may be better to use allocators. You can use "make" and "dispose" from std.experimental.allocator the same way as New/Delete. I tried to introduce the allocators in dlib but it failed, because dlib is difficult to modify because of other projects based on it (although to be honest it was mostly a communication problem as it often happens), so I started a similar lib from scratch.
Re: Best memory management D idioms
On Tuesday, 7 March 2017 at 16:51:23 UTC, Kagamin wrote: There's nothing like that of C++. Don't you think New/Delete from dlib.core.memory fills the bill? for C++ style manual dynamic memory management? It looks quite nice to me, being no more than a simple malloc wrapper with constructor/destructor calling and type safety. Plus printMemoryLog() for debugging, much easier than valgrind. do you want to manage non-memory resources with these memory management mechanisms too? I wasn't thinking about this now, but I'm sure the need will come up.
Re: Best memory management D idioms
On Sunday, 5 March 2017 at 20:54:06 UTC, XavierAP wrote: What I want to learn (not debate) is the currently available types, idioms etc. whenever one wants deterministic memory management. There's nothing like that of C++. Currently you have Unique, RefCounted, scoped and individual people efforts on this. BTW, do you want to manage non-memory resources with these memory management mechanisms too?
Re: Cconditional expression in return statement. Bug?
On Tuesday, 7 March 2017 at 14:26:18 UTC, Jack Applegame wrote: I'm pretty sure this is a bug. And very bad bug. I spent several hours looking for it. What do you think? Definitely a very bad bug. It works too if you mark `fun()` as nothrow. Please file a DMD issue.
Cconditional expression in return statement. Bug?
Code (https://dpaste.dzfl.pl/8e7a9c380e99):
import std.stdio;
struct Foo {
int val;
this(int val) {
writefln("%s.this(int)", val);
this.val = val;
}
this(this) {
writefln("%s.this(this)", val);
this.val = val;
}
~this() {
writefln("%s.~this()", val);
this.val = val;
}
}
struct Bar {
Foo foo;
this(Foo foo, bool) { this.foo = foo; }
}
bool fun(bool val) { return !val; }
auto genBar(bool flag) {
return flag ? Bar() : Bar(Foo(10), fun(!flag));
}
void main(string[] args) {
auto bar = genBar(args.length == 0);
}
Compiler generates extra destructor call:
10.this(int)
10.this(this)
10.~this()
10.~this()
10.~this()
If we slightly change function genBar:
auto genBar(bool flag) {
auto a = flag ? Bar() : Bar(Foo(10), fun(!flag));
return a;
}
or
auto genBar(bool flag) {
return flag ? Bar() : Bar(Foo(10), false);
}
then output looks as expected:
10.this(int)
10.this(this)
10.~this()
10.~this()
I'm pretty sure this is a bug. And very bad bug. I spent several
hours looking for it.
What do you think?
Can i using D & LLVM & SDL2 for Android?
Just thought. I do want to know. :-) As far as I know is, * LDC2 woring on NDK(yah!) * Native OpenGLES: http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D * Dlangui working on Android that based on SDL2: https://github.com/buggins/dlangui / https://dlang.org/blog/2016/10/07/project-highlight-dlangui/ regards,
Re: How to compile against GitHub fork of Phobos?
On Tuesday, 7 March 2017 at 01:14:28 UTC, Q. Schroll wrote: I have a fork of the standard-library in the folder "phobos". DMD looking for the built-in phobos is specified in the configuration file (sc.ini on Windows, dmd.conf on Linux), not hardcoded. You may want to remove it from there. When you specify -I on top of this, I guess the compiler looks in both places in some order. You could also clone your modified Phobos to the directory built into the DMD distribution. But maybe you want to have both. You may also keep and use two DMD bin folders, with different configuration files. There are many possibilities for you to configure what you want. Also yes with your configuration I think you should remove the preceding "phobos." from imports, since you're already telling the compiler to look inside the phobos folder.
