Forward declaration inside Function block, no error?
Today I found a bug in my D code. import std.stdio; // Type your code here, or load an example. void grow() { writeln("grow"); } void someFunc(bool condition) { if(condition) { void grow(); } } I tried to call the grow function, but accidentially copied the return value alongside the function name. I was wondering why this code compiles without errors. the "void grow();" becomes a no-op. In my opinion this could should not compile. Am I missing something here? Kind Regards Benjamin Thaut
Re: Debugging on Windows
On Thursday, 8 February 2018 at 21:09:33 UTC, JN wrote: Hi, is there any way to debug binaries on Windows? I'd at least like to know which line of code made it crash. If it's D code, I get a call trace usually, but if it's a call to a C library, I get a crash and that's it. I am using VSCode and I'd prefer to debug in it if possible, but using other IDEs is a possibility for me if that will help. The best option most likely is to get the Visual Studio Community Edition and then Install the VisualD extension for Visual Studio. This will give you a very good debugging experience with a bulitin D expression evaulator and the usual features the very good Visual Studio debugger comes with. Kind Regards Benjamin Thaut
Re: invalid or corrupt file: duplicate COMDAT / Previous Definition Different
Am 10.01.2018 um 20:32 schrieb Anonymouse: I don't have a reduced testcase yet. I figured I'd ask if it's something known before making the effort. Are you by any chance mixing debug and release builds? Or are the -version specifiers different when compiling the various parts of your program? Check your compiler flags and ansure that they are the same over your entire build process. Especiall -debug -relase -inline -O -version -- Kind Regards Benjamin Thaut
Re: How do I set a class member value by its name in a string?
On Wednesday, 27 December 2017 at 20:04:29 UTC, Marc wrote: I'd like to set the members of a class by its name at runtime, I would do something like this: __traits(getMember, myClass, name) = value; but since name is only know at runtime, I can't use __traits(). What's a workaround for this? You will have to use a combination of compile time and runtime methologies. Essentially what you want is this: void setMemberValue(string name, int value) { switch(name) { case "member1": member1 = value; break; case "member2": member2 = value; break: ... } } As you don't want to write this for all members by hand you should write a function which generates the source code for this switch using static foreach and __traits(allMembers) and then mixin the generated string into the setMemberValue method. If your members can have different types you will also need runtime type that can hold multiple types. For simplicity I just used "int" in the above example. You could use "std.variant" for this.
Re: float.max + 1.0 does not overflow
On Wednesday, 27 December 2017 at 13:40:28 UTC, rumbu wrote: Is that normal? use std.math; float f = float.max; f += 1.0; assert(IeeeFlags.overflow) //failure assert(f == float.inf) //failure, f is in fact float.max On the contrary, float.max + float.max will overflow. The behavior is the same for double and real. This is actually correct floating point behavior. Consider the following program: float nextReprensentableToMax = float.max; // find next smaller representable floating point number (*cast(int*)&nextReprensentableToMax)--; writefln("%f", float.max - nextReprensentableToMax); It computes the difference between float.max and the next smaller reprensentable number in floating point. The difference printed by the program is: 20282409603651670423947251286016.0 As you might notice this is siginificantly bigger then 1.0. Floating point operations work like this: They perform the operation and then round to the nearest representable number in floating point. So adding 1.0 to float.max and then rounding to the nearest representable number will just give you back float.max. If you however add float.max and float.max the next nearest reprensentable number is float.inf. When trying to understand how floating point works I would highly recommend that you read these articles (oldest first): https://randomascii.wordpress.com/category/floating-point/ Kind Regards Benjamin Thaut
Re: DMD Windows 64bit target - how to setup the environment?
On Monday, 25 December 2017 at 16:35:26 UTC, realhet wrote: Now I have my first DMD 64bit windows console app running. (And I'm already afraid of the upcoming windowed application haha) My recommendation for getting setup on Windows with D is as follows: 1) Install the latest visual studio community version: https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=Community&rel=15 2) Install dmd through the windows installer: https://dlang.org/download.html , exe option under windows. This will correctly configure dmd to use the visual studio install from above. From here on dmd will be able to compiler with -m64 and -m32mscoff from the command line. 3) Install VisualD from http://rainers.github.io/visuald/visuald/StartPage.html 4) Create a D project in visual studio and start programming. Compile and debug as usual in Visual Studio. For you command line compilation. Why are you passing -c to the compiler? The idea behind D is that you pass all modules at the same time to the compiler. This allows the compiler to reuse template instances across modules and in general compilation with D is fast enough to be able to recompile everything each time you make changes. No need for a build system. A single batch file with one command in it is usually enough. There is no need to call the linker manually. Dmd will do this for you. Just call dmd like this: dmd -m64 source1.d source2.d source3.d -ofoutput.exe and thats it. You can add additional options like -O -inline -noboundscheck -g -debug -relase. Those are the most commoly used options. Kind Regards Benjamin Thaut
Re: DMD Test Suite Windows
On Wednesday, 20 December 2017 at 10:15:45 UTC, Benjamin Thaut wrote: I found that both the make that comes with msys and the make that comes with mingw work for me. I‘m currently on vacation but once I‘m back and in case you are interrested I can post the batch file I use to run the dmd tests. Here are my scripts: http://stuff.benjamin-thaut.de/D/DmdScripts.zip You need to edit import/config.cmd and put in your paths to visual studio, msys and tdm gcc. A regular mingw also works, but if you use a regular mingw you have to remove the -j4 flag from the run-tests scripts as multi job make is broken in regular mingw (Thats why I use tdm-gcc). The 5 scripts included are: run-tests-win32mscoff.cmd - Runs the dmd test suite with the -m32mscoff flag run-tests-win64.cmd - Runs the dmd test suite with the -m64 flag setup-path-32mscoff.cmd - Sets up the environment so that building of druntime / phobos using the -m32mscoff flag becomes possible. setup-path-64.cmd - Sets up the environment so that building of druntime / phobos using the -m64 flag becomes possible. make-dlls.cmd - A bit of a unlucky name, but makes sense for my local workflow. Builds both druntime and phobos in 64 and 32mscoff. Hope this helps. Kind Regards Benjamin Thaut
Re: DMD Test Suite Windows
On Monday, 18 December 2017 at 16:06:33 UTC, Jonathan Marler wrote: Trying to run the dmd test suite on windows, looks like Digital Mars "make" doesn't work with the Makefile, I tried Gnu Make 3.81 but no luck with that either. Anyone know which version of make it is supposed to work with on windows? Is it supposed to work on windows at all? I found that both the make that comes with msys and the make that comes with mingw work for me. I‘m currently on vacation but once I‘m back and in case you are interrested I can post the batch file I use to run the dmd tests.
Re: Test if a class is extern(c++)
On Monday, 10 April 2017 at 18:56:42 UTC, BBasile wrote: Hello, I have a trait for this: https://github.com/BBasile/iz/blob/master/import/iz/types.d#L650 Hi BBasile, I think your trait is a good starting point for my needs. Thanks.
Test if a class is extern(c++)
In particular I want to know if the vtable of the class has the class info member. Is there any way to do this at compile time? At runtime? Kind Regards Benjamin Thaut
Bug in std.allocator?
Please consider the following program: import std.experimental.allocator.mallocator; import std.experimental.allocator.building_blocks.allocator_list : AllocatorList; import std.experimental.allocator.building_blocks.free_list; import std.experimental.allocator; import std.stdio; enum uint size = 1104; alias ScalableFreeList = AllocatorList!((n) => ContiguousFreeList!(Mallocator, 0, unbounded)(size * 128, size) ); void main(string[] args) { void[][20] allocs; ScalableFreeList allocator; for(int i=0; i < 100; i++) { writefln("pass %d", i); foreach(ref alloc; allocs) { alloc = allocator.allocate(size); writefln("%x", alloc.ptr); } foreach(alloc; allocs) { allocator.deallocate(alloc); } } } I would assume that this program should run forever and never run out of memory. But instead it triggers an assert inside alocator_list in pass 11. So I assume this is some bug in std.allocator? Also whats interresting. The first allocation in each new pass is _not_ the last allocation to be freed. Instead it seems to "leak" one allocation each pass. From the output of the program: 229a290fd60 <- same 229a2932570 <- leaked? pass 11 229a290fd60 <- same Or can anyone see a bug in my program? Kind Regards Benjamin Thaut
std.paralellism.Task value type problems
I would like to use std.paralellism.TaskPool to schedule various tasks I create. The problem however is that these tasks don't have a lifetime which is bound to any function scope I have. So I need to create a new task object on the heap and push it into a array for bookkeeping. The problem however is that std.paralellism.Task is a struct and the only way to instanciate it is to use std.paralelism.task which returns it as a value. I have no idea at the moment how to allocate a instance of std.paralellism.Task on the heap. Any suggestions? Kind Regards Benjamin Thaut
std.experimental.allocator and GC.addRange
Lets assume I have a allocator which cains together multiple building blocks from std.experimental.allocator and at the end there is a mallocator providing the underlying memory. Now I alloacte a type which contains a pointer into GC memory. Obviously the memory of the mallocator is not scanned by the GC so the pointer might become dangling if the GC chooses to collect. I'm wondering if std.experimental.allocator has any building blocks or mechanism to automatically call GC.addRange. Kind Regards Benjamin Thaut
Re: Strange stack variable corruption error after calling extern(C) function
On Wednesday, 4 May 2016 at 17:53:32 UTC, cc wrote: The OS is Win64 though the program is being compiled as 32-bit and I'm using the 32-bit distributed DLL. fmod.dll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows Tried int and long as the return type, same issue both ways. Tried void too just in case, same thing though. Could you please post the definition of FMOD_RESULT. Its possible that the create sound function returns it on stack and not inside a register. This is usually the case if FMOD_RESULT is defined as a struct in C/C++. But its hard to say. In your case I would actually look at the disassembly and step through it to see where its going wrong and messing up the stack.
Re: Strange stack variable corruption error after calling extern(C) function
On Tuesday, 3 May 2016 at 19:06:30 UTC, cc wrote: it fails to link with "Error 42: Symbol Undefined _FMOD_System_CreateSound@20". With extern(C) it compiles and runs but the problem from above persists. Is this on Windows x64? Try replacing FMOD_RESULT by int. When declaring the fmod create sound function and see if that helps.
Re: Stacktraces in static constructors
On Wednesday, 4 May 2016 at 06:37:28 UTC, Nordlöw wrote: On Tuesday, 3 May 2016 at 12:31:10 UTC, Benjamin Thaut wrote: I assume this is on windows? Yes its a known issue (I know No, the problem occurs on my Linux aswell. From core.runtime: static this() { // NOTE: Some module ctors will run before this handler is set, so it's // still possible the app could exit without a stack trace. If // this becomes an issue, the handler could be set in C main // before the module ctors are run. Runtime.traceHandler = &defaultTraceHandler; } So a possible workaround would be to either import core.runtime in each of your modules or manually run the line Runtime.traceHandler = &defaultTraceHandler. Also I find it strange that the trace handler is initialized in a regular module constructor. In my eyes it should be a shared module ctor because the storage behind Runtime.traceHandler is __gshared anyway. Kind Regards Benjamin Thaut
Re: Strange stack variable corruption error after calling extern(C) function
On Tuesday, 3 May 2016 at 11:32:31 UTC, cc wrote: Hello, I've been encountering a strange problem that seems to occur after calling some external C functions. I've been working on a program that incorporates the FMOD C API for playing sound, with a simple D binding based off the C headers, and actually everything works more or less fine, I've had working sound in my program for a few months now. However I recently started noticing some strange behavior, currently using DMD v2.070.2 (haven't tried v2.071 yet, will soon). I can't post the entire program but I'll include the relevant code, I might try to make a small working compilable sample if this isn't enough information. [...] It seems that one of the fmod functions you declared is not correct. Either the fmod api is not using the c calling convention or you made a mistake when declaring the paramters of the fmod functions. You should double check that the functions match the fmod headers. Kind Regards Benjamin Thaut
Re: Stacktraces in static constructors
On Tuesday, 3 May 2016 at 10:52:20 UTC, Nordlöw wrote: On Tuesday, 3 May 2016 at 10:48:51 UTC, Nordlöw wrote: AFAICT, stacktraces are not emitted with debug information when Should be static shared module constructors. errors occur in static module constructors. Is this a know bug? My stacktraces contain no information of the call stack so it's very very tedious work to find the reason for a failing unittest. I assume this is on windows? Yes its a known issue (I know about it). I Don't know if its filed though. As a workaround you can import "core.sys.windows.stacktrace" into each of your modules. That will force the module system to initialize the stacktracing code before the module ctors. The underlying issue is that the module system does not know about the implicit dependeny of every module on the stacktracing module. Kind Regards Benjamin Thaut
Re: Debugging D DLL from C# app with C linkage for native Unity 5 plugin
On Tuesday, 29 March 2016 at 23:41:28 UTC, Thalamus wrote: dmd dllmain.d dll.def -w -wi -g -map -ofLogic.dll -m64 -debug -shared Anyone know what I should try next? Am I missing something simple? :) thanks! Thalamus You should be using "-gc" instead of "-g" when building 64-bit D programs that should be debugged with visual studio. Otherwise the visual studio debugger might get confused over some of the symbol names. (Because they contain '.')
Re: Shared static constructors from C# EXE
On Thursday, 25 February 2016 at 17:46:18 UTC, Thalamus wrote: On Thursday, 25 February 2016 at 16:05:37 UTC, Benjamin Thaut wrote: [...] Thanks Benjamin. When I went to whittle this down to its barest essentials, though, the repro is pretty simple. It involves LIBs, but not Dlls, and it doesn't require anything but a single D EXE. [...] The problem is that when you build with -lib the resulting library is optimized for linker stripping. E.g. everything that is not directly used will not be pulled into the final executable. If you want everything in the final exectuable you shouldn't be using a .lib file. Instead compile with -c resutling in a .obj file and link the resulting .obj file into your executable. Then everything will end up in the final executable even if its not directly used. Kind Regards Benjamin Thaut
Re: Shared static constructors from C# EXE
On Thursday, 25 February 2016 at 14:42:14 UTC, Thalamus wrote: your entry point. Hi Guillaume, Thanks for responding so quickly! I had found that wiki page before and I'd been following the "DLLs with a C Interface" section closely. I had forgotten to add -shared when building the DLL, but the behavior didn't change when I added it. So, I added a call to Runtime.initialize() as the first line of the endpoint I'm exposing. (I also made sure that this was the only endpoint invoked and that it was only invoked once just to be cautious.) I can see Runtime.initialize() being called, but the Class A shared static constructor still is not called when run from the C# EXE. Do you have any other ideas? In the meantime, I'm working on putting together a minimal repro source, but the scenario is a bit complicated so there's a lot of details to whittle away. thanks! Gene You shouldn't be calling Runtime.initialize() manually. Just do the following in one of your source files: import core.sys.windows.dll; mixin SimpleDllMain; This will generate a DllMain that will correctly initialize and deinitialize druntime. Kind Regards Benjamin Thaut
Re: How is the TypeInfo assigned?
On Saturday, 13 February 2016 at 12:44:40 UTC, Tofu Ninja wrote: Is the TypeInfo given by typeid() guaranteed to be the same for a type regardless of where I call it? I guess my question is, is the TypeInfo a valid way to dynamically check types? I am implementing a message passing system for an entity-component system, I was planning to use structs as messages and use the TypeInfo to determine where they are supposed to go. Will this cause any problems? Also will typeid() allocate? Or is the TypeInfo statically allocated at compile time? Also how does shared libs affect this? Will a TypeInfo passed across different libs still match up? Thanks Yes, type infos are garantueed to have identity. You can use their adress to identify a type. The linux shared library mechanism ensures that they have the same adress across multiple shared libraries (if all of these libraries are loaded into the same process) With windows dlls there can be cases where a typeinfo is duplicated. But as dlls don't really work yet, I wouldn't worry about it.
Re: Octree implementation?
On Monday, 1 February 2016 at 02:56:06 UTC, Tofu Ninja wrote: Just out of curiosity, does anyone have an octree implementation for D laying around? Just looking to save some time. https://github.com/Ingrater/thBase/blob/master/src/thBase/container/octree.d Its a loose octree implementation. That means the cells overlap a bit to accomondate for the problem of objects that are on the border between to cells. I don't know though if you can rip out the implementation without some modifications. Kind Regards Benjamin Thaut
Re: Assert failure on 2.070.0 without stack trace
On Thursday, 28 January 2016 at 18:33:19 UTC, Nordlöw wrote: Thanks, I'm aware of these tools. But it's easier to use the stacktrace...if I only get one. The function where the assert() is called is, in turn, called in hundreds of places. Which platform are you on? Are all your binaries compiled with debug symbols? If one or multiple functions on the stack are within phobos or druntime you might not have debug symbols for phobos or druntime. Using inline asm might also destroy your stack frames.
Re: D Dll's usefulness
On Monday, 25 January 2016 at 19:45:21 UTC, Igor wrote: Am I off target here? Dlls are currently not properly supported in D, I would strongly advice against using them. Just link everything statically and be happy for now. Kind Regards Benjamin Thaut
Re: Shared library question
On Saturday, 23 January 2016 at 00:38:45 UTC, Dibyendu Majumdar wrote: On Friday, 22 January 2016 at 22:06:35 UTC, Dibyendu Majumdar wrote: Hi I am trying to create a simple shared library that exports a D function, but when I try to link to it I get errors such as: error LNK2001: unresolved external symbol _D7xxx12__ModuleInfoZ I have uploaded my small test here so if anyone can tell me what I am doing wrong it will hugely appreciated. Thanks! https://github.com/dibyendumajumdar/d-lab/tree/master/sharedlib Dll support on windows is basically non existant at the moment and I strongly advice against trying to use it. Trust me I've been there. I'm currently working on propper Dll support but that is most likely going to take a few more months. Your best option currently is to simply link everything statically. Kind Regards Benjamin
Re: cast fails for classes from windows dll
On Tuesday, 12 January 2016 at 19:00:26 UTC, Andre wrote: Hi, I am not sure, whether this is a current limitation of the windows dll functionality of D or I am doing s.th. which will not work. I have developed in D a windows DLL which creates class instances by passing the name (using object.factory method). In another D application I am using this DLL. My issue is, that the cast fails, although typeid(bar).name shows the correct name . module main; // these classes are in a seperate module // used for the dll & for this application export class Foo {} export class Bar : Foo {} class Baz : Bar {} void main() { // this method calls the dll and returns Foo Foo c = dllCreateClass("main.Baz"); // no failure assert( typeid(c).name == "main.Baz"); // > fails if (auto myBar = cast(Bar) c){} } Kind regards André Thats a limitation of the current dll functionality. The type info of the class gets duplciated into both your executable and the dll and thus the cast fails. Until D properly supports Dlls on windows this is going to stay this way. Currently only a C like interface across dll boundaries is possible.
Re: cairo(D) / x64 / unresolved externals / don't know why
Am 11.01.2016 um 18:27 schrieb Robert M. Münch: Import symbols are symbols used for dll linking and start with "__imp_" Is this a DMD convention or a general one? Never heard about this. This seems to be a general convetion on windows. All c++ compilers I've seen on windows so far emit so called import symbols using the "__imp_" prefix. Basically its just another level of indirection during a function call to be able to resolve function addresses at runtime, e.g. implement dynamic linking. Its kind of a implementation detail, so in theory you don't have to know about it. But it helps when reading linker errors. In case my talk gets accepted for dconf 2016 I'm going to cover this there in more detail. -- Kind Regards Benjamin Thaut
Re: cairo(D) / x64 / unresolved externals / don't know why
On Sunday, 10 January 2016 at 22:22:03 UTC, Robert M. Münch wrote: I made to compile a bunch of libs on Win64 and got my D project compiled as well. Only problem left are some strange unresolved externals. Linking... dmd -of.dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\webchat.exe .dub\build\application-debug-windows-x86_64-dmd_2069-F0A1450B9B033D5CD11F3F60481557B0\webchat.obj ..\vibe-d-0.7.26\lib\win-amd64\libeay32.lib ..\vibe-d-0.7.26\lib\win-amd64\ssleay32.lib ..\cairoD\cairoD.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-ft-1.0.2\lib\DerelictFT.lib C:\Users\robby\AppData\Roaming\dub\packages\derelict-util-2.0.4\lib\DerelictUtil.lib C:\Users\robby\AppData\Roaming\dub\packages\x11-1.0.9\x11.lib ..\vibe-d-0.7.26\vibe-d.lib wsock32.lib ws2_32.lib advapi32.lib user32.lib -LD:\develop\cairo\cairo\src\release\cairo-static.lib -LD:\develop\cairo\libpng\libpng.lib -Lgdi32.lib -m64 -m64 -m64 -m64 -m64 -m64 -g cairo-static.lib(cairo-image-source.obj) : error LNK2001: unresolved external "__imp__hypot" and some more missing in other .obj files: "__imp__ctime64" "__imp_ldiv" "__imp_strncpy" "__imp_rand" IMO this all looks like msvcrt standard lib stuff so wondering why it's not found. Do I explicitly have to link to the msvcrt lib? You should not need to link manually against msvcrt, dmd does this for you. You can view the linker commands that are stored inside a object file via microsoft dumpbin tool "dumpbin /DIRECTIVES your.obj". You should check the declarations of the functions that cause a unresolved external error. If they have a "export" in front of them, remove the export. I can not think of any other reason why dmd would otherwise reference a import symbol. Import symbols are symbols used for dll linking and start with "__imp_" Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough. For debug builds targeting windows 64 I would also highly recommend using "-gc -op" instead of "-g". This will give a much better debugging experience in Visual Studio.
Re: Linking a DLL to a DLL with packages
Am 09.01.2016 um 16:45 schrieb Thalamus: Hi Benjamin, I wouldn't say I need DLLs to work fully _really_ badly. The only non-negligible issue with single very large binaries that's crossed my mind is patching, but we're years away from having to worry about that too much. That being said, I'm definitely willing to do some testing, especially for something that helps us down the road. I'll follow up with you offline. Thanks! Great, some help with bugfixing and testing would be greatly apreciated. I didn't get any e-mail from you yet, I assume you didn't send one? Kind Regards Benjamin Thaut
Re: Linking a DLL to a DLL with packages
On Thursday, 7 January 2016 at 19:29:43 UTC, Thalamus wrote: Hi everyone, First off, I've been working with D for a couple of weeks now and I think it's the bee's knees! :) Except for DLLs. thanks! :) Dlls don't currently work on Windows. The only thing that works is giving your dlls a C-like interface. If you need any kind of D interface (classes, modules, etc) it won't work. I'm currently working on this, if you need it really badly and are willing to help bug testing send me a mail to code at benjamin-thaut.de Kind Regards Benjamin Thaut
Re: Why my app require MSVCR120.dll?
On Friday, 6 November 2015 at 16:21:35 UTC, Suliman wrote: On Friday, 6 November 2015 at 13:50:56 UTC, Kagamin wrote: MSVCR is a C runtime. On Linux it will depend on a C runtime too. But which part of my App depend on C runtime? All of it. Phobos and druntime use the C runtime, that means the language itself depends on the C runtime.
Re: __simd_sto confusion
On Saturday, 3 October 2015 at 14:47:02 UTC, Nachtraaf wrote: I'm trying to create some linear algebra functions using simd intrinsics. I watched the dconf 2013 presentation by Manu Evans but i'm still confused about some aspects and the following piece of code doesn't work. I'm trying to copy the result of a dot product from the register to memory but dmd fails with an overload resolution error, which i guess is due some implicit conversion? dmd error: simd1.d(34): Error: core.simd.__simd_sto called with argument types (XMM, float, __vector(float[4])) matches both: /usr/include/dlang/dmd/core/simd.d(434): core.simd.__simd_sto(XMM opcode, double op1, __vector(void[16]) op2) and: /usr/include/dlang/dmd/core/simd.d(435): core.simd.__simd_sto(XMM opcode, float op1, __vector(void[16]) op2) from the following piece of code: float dot_simd1(float4 a, float4 b) { float4 result = __simd(XMM.DPPS, a, b, 0xFF); float value; __simd_sto(XMM.STOSS, value, result); return value; } What am I doing wrong here? core.simd is horribly broken. I recommend that you avoid it for any serious work. If you want to do simd programming with D get LDC or GDC and use their simd intrinsics instead of core.simd. If you have to do simd with dmd write inline assembly.
Re: Status of Win32 C++ interop
On Tuesday, 8 September 2015 at 12:56:00 UTC, Laeeth Isharc wrote: This is really very clear and helpful, and I appreciate your taking the time. I will place it on the wiki if that's okay. Thats ok. Library support is surely one of the largest impediments to the adoption of D, and we ought to place some emphasis on updating the documentation here: http://dlang.org/cpp_interface.html How does it work when external APIs expect objects from the C++ standard library? strings, and so on? How about funny pointer types? shared_ptr etc? std::vector, std::list? For templated types like std::vector, std::list and shared_ptr you have two options: - Redo the complete implementation on the D side ensuring that the data layout is the same - Or, expose helper functions which call placement new / desturctor of your needed std::vector and do the hidden data trick I described above. The regular functions of std::vector just have to be declared and the linker will find them if and only if the c++ side instanciated the template. Here is one C++ library used by many in finance (at least as a backup). I think there might be a decent amount of value in making this usable from D. (Trying to put my own interests aside!) Paging Andy Smith ? http://quantlib.org/reference/_bermudan_swaption_8cpp-example.html I think you have to make this usable from D yourself ;-) Are there any well-known C++ libraries that you have interfaced to ? Could you give some examples of how long it takes ? I'm interfacing to a 3D engine I'm working on in my spare time with some collegues. So no well known C++ library. Would you be able to drop me an email about something else? No contact info on your blog, but my domain is kaleidicassociates.com and my user id is laeeth@ Will do. Kind Regards Benjamin Thaut
Re: Status of Win32 C++ interop
On Monday, 7 September 2015 at 19:30:44 UTC, drug wrote: 07.09.2015 21:37, Benjamin Thaut пишет: snip So far I haven't found a situation where I couldn't make it work the way I wanted. Its just some work to write the D headers for the C++ classes and vise versa, because you have to duplicate everything once more. An automated tool for this would be nice, but unfotunately there is currently none. Kind Regards Benjamin Thaut It's great. But isn't it based on your custom modifications of compiler and the others? No, the compiler modifications are only for the Windows DLL support. All modifications I did to the c++ binding are already in 2.068
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 16:19:49 UTC, Laeeth Isharc wrote: Hi Benjamin Would you be able to give a little more colour on what the limits are of interoperability for C++ with DMD master or release ? As I understand it destructors and constructors don't work, and obviously it will get tricky passing structures and classes from C++ libraries not ported to D. So, things that work really well are classes. Given that you construct them in the their "native environment". E.g. create D objects in D land and C++ objects in C++ land. I usually use factory methods for this. Manually destroying objects also works if you add some kind of "Destory" method (can be virtual, but doesn't have to be) to your class which simply does a "delete this" or similar. The only problems with interfacing C++ classes to D is if they have a virtual destructor. But there is a easy workaround like so: C++: class SomeBaseClass { public: virtual ~SomeBaseClass(); virtual void SomeVirtualFunc(); } D: extern(C++) class SomeBaseClass { protected: abstract void __cppDtor(); // don't call public: void SomeVirtualFunc(); // default virtual in D } Free functions, static functions, non virtual functions all work flawlessly. I recommend that you create your own pointer type on the C++ side, e.g. DPtr which calls the GC.addRoot / GC.removeRoot methods of the D's gc interface in the apropriate places in case you want to pass D objects into C++ space. If you have a reference counting concept on the c++ side its also possible to build a small proxy object which does reference counting in c++ and calls GC.removeRoot when the last reference count drops. If you want to bind more complex types, e.g. c++ templates you can either declare them extern(C++) in D and the compiler will do the correct mangling, or what I did to make them fully functional on both sides: I did a full implementation both in D and C++. The implementation ensures that the data layout is exactly the same for D and C++ but other than that the implementation is duplicated on both sides and even different in some cases. It still possible to pass this complex type from C++ to D because the data layout is the same. I did this for a custom hash map implementation and passing it around works flawlessly (by reference) I had another complicated case where I wanted a complex value type that is implemented in C++ on the D side. It had a lot of members which types don't have a equivalent in D, so I did the following. extern(C++) { void constructComplexStruct(ComplexStruct* self); void destructComplexStruct(ComplexStruct* self); } struct DefaultCtor {}; // helper type alias defaultCtor = DefaultCtor(); struct ComplexStruct { @disable this(); @disable this(this); this(DefaultCtor) { constructComplexStruct(&this); } ~this() { destructComplexStruct(~this); } extern(C++) void SomeMethodOfComplexStruct(); private: // must be sizeof(ComplexStruct) from c++, use unittest to ensure! void[288] m_data; } constructComplexStruct and destructComplexStruct just do a placement new / call the C++ dtor. Usage then works like this: void someDFunc() { ComplexStruct myStruct(defaultCtor); // constructed using C++ default ctor myStruct.SomeMethodOfComplexStruct(); // call C++ implemented method // destructed using C++ dtor } So far I haven't found a situation where I couldn't make it work the way I wanted. Its just some work to write the D headers for the C++ classes and vise versa, because you have to duplicate everything once more. An automated tool for this would be nice, but unfotunately there is currently none. Kind Regards Benjamin Thaut
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote: On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote: On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote: What about 32bit phobos? Last time I checked (2.067) only x64 was distributed. You have to compile it yourself. Use the win64 makefile and replace the arch=64 with arch=32mscoff. For more details see here: http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html Ah so that didn't change. Did you try it? Do you run hybrid C++/D apps on Win (whether 32 or 64)?. Asking because last time I tried it (Win x64 tho) writeln() call from D side crashed app because stdio wasn't properly initialized even tho rt_init() was successful. I am running hybrid D/C++ apps. I found it to work best when you give D the control over the main method, e.g. the program entry point should be in D land. Then simply call a C++ function from there to initialize your c++ stuff. I'm currently even running hybrid C++/D apps with dlls. E.g. multiple D dlls + multiple C++ dlls loaded by a c++ main program. But to do that I have heavy compiler + runtime modifications which are not ready yet to do a PR for them.
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote: What about 32bit phobos? Last time I checked (2.067) only x64 was distributed. You have to compile it yourself. Use the win64 makefile and replace the arch=64 with arch=32mscoff. For more details see here: http://www.digitalmars.com/d/archives/digitalmars/D/learn/How_to_get_32mscoff_libraries_for_phobos_73980.html
Re: Status of Win32 C++ interop
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote: Hi, what is the current status of: - Win x86/32bit/coff32 interop with C++? - improvements for general C++ interop that were suppose to come with 2.068 If you use either the -m64 or -mscoff32 interop should be pretty good. I'm currently using it heavily and its working quite nicely.
Re: AMD & Windows 7
On Friday, 12 June 2015 at 14:39:55 UTC, Chris wrote: I wish it were an error in the Python code so I could fix it, but it works on all other machines (at least those with Intel). It's only on the HP625 with AMD that this error occurs. Another DLL (which isn't mine) also failed to load, although with a different error message. It might be just this particular model, or AMD, I dunno. I couldn't find anything about it on the internet. Atm I'm using dmd 2.067.1, maybe compiling with GDC or LDC will fix it. That sounds more like its the software installed on the machine and not the processor. Are you sure that all microsoft runtime libraries are installed? If you did use the vs 2012 linker to create the D-dll you need to install this redistributable package: http://www.microsoft.com/en-US/download/details.aspx?id=30679 Did you run Depends on the dll? Usually depends will tell you why the dll does not load: http://www.dependencywalker.com/ Kind Regards Benjamin Thaut
Re: compilation issues in a shared library project
On Sunday, 7 June 2015 at 21:11:38 UTC, Jonathan Villa wrote: Compilation line: Current dictionary: C:\Users\JVortex\Documents\Projects\DataTable2 dmd.exe -O -release "DataBlockHeader.d" "DataBlock.d" "DataTable2.d" "-L/IMPLIB:C:\Users\JVortex\Documents\Projects\DataTable2\bin\Release\DataTable2.lib" "-odobj\Release" "-ofC:\Users\JVortex\Documents\Projects\DataTable2\bin\Release\DataTable2.dll" -w -vcolumns Is that the info you're asking for? If not, please tell me. Shared libraries (DLLs) don't work on windows. They only work for the simplest of all cases (e.g. global functions) and even then there are pitfalls. Just don't do it. The only viable option currently is to link statically or put _all_ your D code into one single Dll and use that Dll from C. Any other use case is bound to fail. I'm currently working on propper dll support for D but it is a lot of work. Kind Regards Benjamin Thaut
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 08:53:10 UTC, Kagamin wrote: There was no word about windows, but process explorer shows page faults and cycles per process from unprivileged account, so I guess, this information is available through some API. Not sure is such system-wide statistics is available too. He is talking about the performance counters build into intel x86 processors (at least thats what I understood) thats something completely different from page faults and cycles per process. And as it is processor specific there is _no_ general api for it.
Re: Accessing x86 Performance Counters
On Wednesday, 13 May 2015 at 03:38:33 UTC, Maxime Chevalier-Boisvert wrote: I was wondering if anyone has written D code to access the x86 performance counters, to get information such as the number of cache misses and cycle count. I considered doing that at one point. So I looked for resources on the topic and it turns out that you need a kernel mode executable to be able to read the performance counters. Luckly there is a open source driver for windows which gives you some API to access the counters from user mode executables. Unfortunately you need to either switch your windows into a "unsafe mode" to allow for loading unsigned drivers or you need to somehow get a certificate to sign the driver (these are quite expensive). At that point I stopped looking into this, because both of these options weren't viable for my use case. Once I find some time I could dig up the resources I found if you are interested.
Re: C++ interface problem
On Wednesday, 29 April 2015 at 19:04:11 UTC, extrawurst wrote: On Wednesday, 29 April 2015 at 13:55:46 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type > 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut Seems i am out of luck. I tried all that. The Steamworks SDK is closed source without debugging symbols. so it wont work.. too bad, this library would have been a good example case of seamless c++-interfacing from D... Did you try windows 64-bit? Calling conventions on 64-bit windows are better standardized.
Re: C++ interface problem
On Monday, 27 April 2015 at 21:19:02 UTC, extrawurst wrote: here is the shortened version of the returned class CSteamID: https://gist.github.com/Extrawurst/936f56ceaa87cf287257 this is the shortened interface (no destructors in the rest of the code either): https://gist.github.com/Extrawurst/b20dc5ab84132ecab30d the method `GetFriendByIndex` is the one crashing on win32. I assume that's because CSteamID is returned by value. Are you defining CSteamID in D as a struct? If not you have to because only structs can be returned by value. The next problem is that CSteamID is 64bits wide, this might be a problem as it can not be returned in a single register. You could try changeing the definition of GetFriendByIndex on the D side to ulong GetFriendByIndex(...) and reinterpret the ulong on the D side. If that does not work however you are most likely out of luck because the way your c++ library returns a value type > 32-bit is not compatible with what dmd expects. Do you have debug symbols for the third party c++ library? Can you step into the virtual function call to actually see if it ends up in the correct function on the c++ side? Kind Regards Benjamin Thaut
Re: C++ interface problem
Am 27.04.2015 um 17:16 schrieb extrawurst: On Monday, 27 April 2015 at 13:14:21 UTC, Benjamin Thaut wrote: On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote: Don't ask me about the compiler, like stated above I have no control over the binaries, it is proprietary. Thats bad to start with. the C++ class basically is: ``` class S { union SteamID_t { struct SteamIDComponent_t { uint32m_unAccountID : 32; unsigned intm_unAccountInstance : 20; unsigned intm_EAccountType : 4; EUniversem_EUniverse : 8; } m_comp; uint64 m_unAll64Bits; } m_steamid; } ``` Where is the fuction declaratiosn for bar? If bar is not virtual you can not use a extern(C++) Interface. If bar is non-virtual you have to use a extern(C++) class. of course it is all virtual. it is a c++-interface. and everything works fine under osx, that would not be the case otherwise, right ? It depends on the compiler, I don't know the vtbl layout on OSX. Does the class have a virtual destructor? If you would post a bit more of S declaration I wouldn't have to guess into the blue. Not knowing the compiler your third party library was compiled with doesn't really help either. Kind Regards Benjamin
Re: C++ interface problem
On Monday, 27 April 2015 at 13:08:33 UTC, extrawurst wrote: Don't ask me about the compiler, like stated above I have no control over the binaries, it is proprietary. Thats bad to start with. the C++ class basically is: ``` class S { union SteamID_t { struct SteamIDComponent_t { uint32 m_unAccountID : 32; unsigned intm_unAccountInstance : 20; unsigned intm_EAccountType : 4; EUniverse m_EUniverse : 8; } m_comp; uint64 m_unAll64Bits; } m_steamid; } ``` Where is the fuction declaratiosn for bar? If bar is not virtual you can not use a extern(C++) Interface. If bar is non-virtual you have to use a extern(C++) class.
Re: C++ interface problem
On Monday, 27 April 2015 at 11:00:23 UTC, extrawurst wrote: Thought about that too and tried uint aswell. does not work either.. Please post the c++ declarations as well. Which c++ compiler do you use for win32? (dmc or msvc) Kind Regards Benjamin
Re: Should this work: export extern(C) auto ...
On Thursday, 19 March 2015 at 12:58:42 UTC, Robert M. Münch wrote: On 2015-03-18 21:50:39 +, Adam D. Ruppe said: It will not work because a function with an auto return value is actually a template, and unused templates won't be put into a dll. Ok, that makes it clear. Thanks. Generally don't expect to many things to work with DLLs at the moment. Generally speaking only exporting global functions works. Don't try to export classes / structs or anything fancy.
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Monday, 9 March 2015 at 14:39:34 UTC, Carl Sturtivant wrote: Please confirm or deny that this is a real bug, as its getting in the way of a genuine project. How should I proceed? I'm working on a 64-bit Windows port of the following. http://www.cs.arizona.edu/icon/ Here's the 32-bit Windows port. http://www.cs.arizona.edu/icon/v95w.htm Among other things I'm using D to implement Icon's coexpressions portably using core.thread.Fiber which works fine at 32 bits. They are implemented using pthreads on other platforms, though historically there used to be a platform dependent assembly code context switch, close to the way that core.thread.Fiber is implemented. The Fiber implementation is 20 times faster at 32 bits. I can reproduce this issue with dmd 2.066.1, please go forward and open a issue on https://issues.dlang.org/ Kind Regards Benjamin Thaut
Re: Initializing defaults based on type.
On Friday, 6 March 2015 at 15:36:47 UTC, anon wrote: Hi, I can't figure this out. struct Pair(T) { T x; T y; alias x c; alias y r; } What would like is that the x and y to be initialized to different values depending on type eg: struct Container { Pair!double sample1; // This will initialize sample1 with 0 for both x and y Pair!intsample2; // This will initialize sample2 with 1 for both x and y } currently I'm using two different struct one with doubles and the other with ints and initialized with default value but was wondering if its possible to do the above. anon struct Pair(T) { static if(is(T == int)) enum int initValue = 1; else enum T initValue = 0; T x = initValue; T y = initValue; alias x c; alias y r; }
Re: Int to float?
Am 05.03.2015 um 21:00 schrieb Taylor Hillegeist: How to I cast a Int to float without changing its binary representation? int someValue = 5; float sameBinary = *(cast(float*)cast(void*)&someValue);
Re: C++ calling convention only
Am 21.02.2015 um 11:30 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= ": For C++, you can just use the newly added namespace support: extern(C++, nobody.uses.this.name) myFunc() {} Thats actually a good idea. Thanks.
Re: C++ calling convention only
On Friday, 20 February 2015 at 13:00:39 UTC, John Colvin wrote: I agree. Wrap it in a mixin / mixin template? Why do you need this? Presumably it'll be hidden in the depths of some library / bindings where beauty is somewhat optional? Using the .mangleof from an extern(D) function should mean it's robust. Well the use case is creating a function which sole purpose it is to create a function pointer from it and pass it to C++. If it recieves C++ mangling however I have to pay attention that it does not conflict with any other C++ symbols. The same goes for extern(C). Sometimes you want to create functions with a C calling convetion so you can create a function pointer from it. With extern(C) its even a bigger problem because the C mangling conflicts a lot easier.
Re: C++ calling convention only
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote: I would duplicate the declaration, once without extern(C++), once with, the use the .mangleof from the 1st to set the mangle of the 2nd with pragma(mangle Yes that would work. But using pragma(mangle) feels so hacky...
C++ calling convention only
Is it possible to declare a function in D which gets the C++ calling convetion but not the C++ mangling? Kind Regards Benjamin Thaut
Re: @nogc with assoc array
Am 16.02.2015 um 18:55 schrieb Jonathan Marler: Why is the 'in' operator nogc but the index operator is not? void main() @nogc { int[int] a; auto v = 0 in a; // OK auto w = a[0]; // Error: indexing an associative // array in @nogc function main may // cause GC allocation } Because the index operator throws a OutOfRange exception and throwing exceptions allocates, maybe?
Re: What is the Correct way to Malloc in @nogc section?
Hi, you can also take a look at my implementation: https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d Look at AllocatorNew and AllocatorDelete Especially important is, that you correctly handle the constructor throwing an exception. You have to catch that exception in your new function, release the memory and rethrow. Kind Regards Benjamin Thaut
Binding C++ value types
When binding C++ value types you might want to use them by placing them on the D-Stack. This however seems to be not supported as the mangling for the constructor is completely wrong. Is this supposed to work? Kind Regards Benjamin Thaut
Re: windows wininet library
Am 01.02.2015 um 17:15 schrieb ketmar: On Sun, 01 Feb 2015 16:07:58 +, John Chapman wrote: On Sunday, 1 February 2015 at 08:37:23 UTC, ketmar wrote: seems that my idea of using D to write a simple windows utility was very wrong. ok, another attempt to use D for our windows developement has failed. i'm in no way can sell manual ".def" creation to our team -- they will make fun of me, showing how their Visual C can compile this code without any troubles and external utilities... It's easier to run coffimplib on the lib files from the Windows SDK. sorry if i'm rude, i really appreciate your advice. i messed myself thinking that this is another thread in "general" NG. The Windows SDK can be downloaded seperately from visual studio: https://msdn.microsoft.com/en-us/windows/desktop/ff851942.aspx They are also backwards compatible, so the latest one should work on XP. But you can also just use the oldest one available to make sure it still works on your machine.
Re: What is @return?
On Thursday, 29 January 2015 at 11:50:29 UTC, FG wrote: @property auto info() @safe @nothrow @pure @return const { return this; } It is mesmerizing... (@ _ @) And soon its gong to look like this: export @property auto info() @safe @nothrow @pure @return const { return this; }
Read from stdin without blocking
I want to read all input from stdin without blocking. That means I simply want to read the remaining input from stdin. All ways I tried so far always end up in me waiting for the user to enter additional input, which is not what I want. I tried around a lot with D's files / streams but couldn't find any way to do that. Any help is appreciated. Kind Regards Benjamin Thaut
Re: Example usage of the core.sync classes
Am 02.01.2015 um 19:45 schrieb Vlad Levenfeld: My personal favorite method is to use the primitives in core.atomic with a double or triple buffer. To double buffer, keep two buffers in an array (data[][] or something) and an integer index that points to the active buffer, then use atomicStore to update active buffer index when you want to swap. Triple buffering can improve runtime performance at the cost of more memory, and in this case you will need two indices and two swap methods, one for the producer and another for the consumer. I use cas with a timed sleep to update the indices in this case. Take it with a grain of salt, I'm far from a pro, but this has worked well for me in the past. I can post some example code if you need it. I have to agree with Vlad here. The usual way is to do double buffering. So you have two buffers which hold all the data that the physics simulation passes to the game logic. While the physics simulation is computing the next frame, the game logic can use the results from the last frame. The only point where sinchronisation is neccessary is when swapping the buffers. You have to ensure that both the game logic and the physics thread are done with their current buffer and then sawp them. The only downside of this approach is, that you will get a small delay (usually the time taken for 1 frame) into the data you pass this way. Sometimes this approach is called the "exractor pattern". I use it to pass data from the game simulation to the renderer, so the renderer can render in paralell with the game simulation computing the next frame. You can find a example of my double buffered solution here: https://github.com/Ingrater/Spacecraft/blob/master/game/sources/renderer/extractor.d I had tripple buffering up and running at some point, but I went back to double buffering, because tripple buffering can cause micro lags and you don't want that. Kind Regards Benjamin Thaut
vibe.d + dub dynamic library
Is it possible to get dub to build vibe.d into a dynamic library? Or is it at least possible to make dub link against the shared version of phobos? I found this blog post about dynamic linktimes, unfortunately it does not describe how to actually make dub use the dynamic version of phobos. https://code.dawg.eu/reducing-vibed-turnaround-time-part-1-faster-linking.html (I'm on linux) Kind Regards Benjamin Thaut
vibe.d mongodb connections
I'm currently trying around with vibe.d and I'm confused about the MongoDB example: import vibe.d; MongoClient client; void test() { auto coll = client.getCollection("test.collection"); foreach (doc; coll.find(["name": "Peter"])) logInfo("Found entry: %s", doc.toJson()); } shared static this() { client = connectMongoDB("127.0.0.1"); } "client" is TLS but is initialized within a shared module consturctor, meaning that only the main thread will have a initialized db-connection. http://vibed.org/api/vibe.db.mongo.mongo/connectMongoDB says: "Thus, the MongoClient instance can - and should - be shared among all fibers in a thread by storing in in a thread local variable." So wouldn't it make more sense that the MongoDB example initializes the "client" variable in a "static this()" instead of a "shared static this()" ? Kind Regards Benjamin Thaut
Re: How do I write __simd(void16*, void16) ?
Am 09.10.2014 21:04, schrieb Etienne: On 2014-10-09 2:32 PM, Benjamin Thaut wrote: I know that GDC stopped supporting D style inline asm a while ago. If you need inline asm with GDC you have to use the gcc style inline assembly. I don't know about ldc though. But generally you want to use the official intrinsics with gdc and ldc because they won't perform any optimizations on inline assembly. Kind Regards Benjamin Thaut Any idea where I can find the headers in D for it? I think a good starting point would be Manu's std.simd module. I don't know if he is still working on it, but a old version can be found here: https://github.com/TurkeyMan/simd/blob/master/std/simd.d If you have further questions you might be well advised to ask him: turkey...@gmail.com You can also find the druntime versions of ldc and gdc on github. For example: https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/simd.di https://github.com/D-Programming-GDC/GDC/blob/master/libphobos/libdruntime/gcc/builtins.d Unforunately the gcc.buildints module seems to be generated during compilation of gdc, so you might want to get a binary version or compile it yourself to see the module. Kind Regards Benjamin Thaut
Re: How do I write __simd(void16*, void16) ?
Am 08.10.2014 21:12, schrieb Etienne: On 2014-10-08 3:04 PM, Benjamin Thaut wrote: I strongly advise to not use core.simd at this point. It is in a horribly broken state and generates code that is far from efficient. If I think I'll have to re-write the xmmintrin.h functions I need as string mixins to inline the assembly. Is that supposed to be compatible with LDC/GDC anyways? I know that GDC stopped supporting D style inline asm a while ago. If you need inline asm with GDC you have to use the gcc style inline assembly. I don't know about ldc though. But generally you want to use the official intrinsics with gdc and ldc because they won't perform any optimizations on inline assembly. Kind Regards Benjamin Thaut
Re: How do I write __simd(void16*, void16) ?
Am 08.10.2014 20:56, schrieb Etienne: I can't seem to find this function anywhere: __simd(void16*, void16) The mangling seems to go through to dmd's glue.lib This is for SSE2 operations: MOVDQU => void _mm_storeu_si128 ( __m128i *p, __m128i a) MOVDQU => __m128i _mm_loadu_si128 ( __m128i *p) Would I have to write this with ASM? I strongly advise to not use core.simd at this point. It is in a horribly broken state and generates code that is far from efficient. If you use core.simd your code will be slower then if you use normal floating point math. Also afaik core.simd is currently only supported by dmd meaning that yuo have to rewrite the code in case you want to go to ldc or gdc. If you need simd with dmd, write inline assembly. If you need simd with the other two compilers, use the gcc intrinsics, they work on both compilers. Kind Regards Benjamin Thaut
Re: Programming a Game in D? :D
Am 22.05.2014 17:39, schrieb David: Hey, I'm really new to D, and pretty new to programming overall too, But I want to make a 3d Game, (just sth. small). I really like D and want to do it in D, but in the Internet there is no shit about programming a game in D ^^ Is there any engine written in D? For example the CryEngine is for C++, so I would have to write a wrapper? So, how do I write a wrapper? I would need a wrapper for DirectX too right? Are there any wrappers ore Engines for D i can use? btw. I know I dont write that in 1 day ^^ Are there any tutorials or sth. on Programming a Game in D? S I just wanna come as far to have a little Cube where i can run around on with a few phisics :) so just the startup to load a world and so on Thanks in advance :) And sry my english sucks :D I wrote a game in D, and its doable. See http://3d.benjamin-thaut.de/?p=20 Its even on github: https://github.com/Ingrater/Spacecraft Kind Regards Benjamin Thaut
Re: Iterate over symbols in tupleof without instance
Am 15.04.2014 14:33, schrieb Dicebot: So, what is wrong with this? void main(string[] args) { Bla bla; foreach(index, a; typeof(Bla.tupleof)) { pragma(msg, hasAttribute!(Bla.tupleof[index], Property).stringof); } } http://dpaste.dzfl.pl/b38035362b29 Nothing, thanks for the solution. It didn't come to my mind, to use the index from iterating over the type tuple to index the symbol tuple. Kind Regards Benjamin Thaut
Re: Iterate over symbols in tupleof without instance
Am 15.04.2014 13:25, schrieb Artur Skawina: On 04/15/14 12:45, Dicebot wrote: void iterate(T)() { foreach (index, member; T.init.tupleof) { pragma(msg, __traits(identifier, T.tupleof[index])); } } struct A { int a, b, c; } void main() { iterate!A(); } Reason why you can't naively iterate over T.tupleof is that current tuple foreach tries to look like normal foreach and thus iteration parameters can't be types. void iterate(T)() { foreach (index, member; typeof(T.tupleof)) { pragma(msg, __traits(identifier, T.tupleof[index])); } } artur I want to iterate over the symbols, not over the types that the symbols have. I need to iterate over the symbols, because UDAs are attached to the symbols. Because of that none of the here listed solutions work for me. Here is a small example of what I'm trying to do: http://dpaste.dzfl.pl/4645d6537447 And no, I can not use __traits(allMembers, T) and __traits(getMember, T, m) because some time ago __traits(getMember, ...) was changed so it can no longer access protected members. (obviously it will work if the type that should be iterated over is within the same module, but thats not the case in practice.) Kind Regards Benjamin Thaut
Iterate over symbols in tupleof without instance
I would like to iterate over T.tupleof at compiletime without having a instance of the given type. So fare the only way I found that works is the following void iterateImpl(T, size_t i)() { static if(i < T.tupleof.length) { // do something with T.tupleof[i] iterateImpl!(T, i+1)(); } } void iterate(T)() { iterateImpl!(T, 0)(); } But this is quite ugly, as there will tons of stack frames on the stack during runtime. I really wanted something like: void iterate(T)() { foreach(size_t i, m; T.tupleof) // error message: "Need this to access " { // do something with m } } Kind Regards Benjamin Thaut
Re: When this will be freed?
Am 02.04.2014 17:57, schrieb Andrea Fontana: On Wednesday, 2 April 2014 at 15:53:52 UTC, Jacob Carlborg wrote: On 2014-04-02 17:45, Andrea Fontana wrote: auto example(char* test) { return toStringz(to!string(test) ~ " world!"); } When that return string will be freed? When there is no reference left to the string, the garbage collector is free to collect it when it chooses to. That's expected. What about: extern(C) auto example() Same as above, extern(C) does not change how memory is collected. If it is a C function, then it depends entirely on that particular function. I mean: if it is an exported function (of a shared library) what happens? There's no reference kept anywhere (in D). So if I'm right it could be freed immediatly by GC. Right? If you pass that string to a C function, there is a reference on the stack. So this string will not be freed until that C-function returns. If that C-Function returns, it is very likely however that this was the only reference and the string will be freed the next time the garbage collector runs. Kind Regards Benjamin Thaut
Re: destructor, postblit constructor --- force calling always
Am 31.03.2014 08:06, schrieb monarch_dodra: On Monday, 31 March 2014 at 01:03:22 UTC, Carl Sturtivant wrote: What about destructors, are they always called, or is this another optimization if the struct is in it's default .init state? In any case, there should be 1 destructor call for every object you declared. Except for thing on the heap. Those are just collected, not destroyed :/ The destructor is always called. There is never a instance that gets destroyed without the destructor beeing called. It can happen however that the destructor gets called on a .init state. This happens for example if you use "std.algorithm.move". To be fully correct your struct should handle the .init state in the destructor (or assert at least so you can find and fix those occurences). Kind Regards Benjamin Thaut
Re: destructor, postblit constructor --- force calling always
Am 30.03.2014 21:35, schrieb Carl Sturtivant: Context: struct values that are (non-ref) parameters & local variables. Is there a way to arrange that a particular struct's special constructors (postblit,destructor) should always be called even on move, or on destruction of a default initialized value, temporary or not, etcetera, i.e. ensure they should always be called? Is a struct's destructor always called when it goes out of scope, even if it is default initialized? D's structs don't have identity. That means, they can be moved without notice at any point in the program. AFAIK the compiler even does that when handling exceptions in a few cases (e.g. with structs on the stack). Having moveable value types allows for a lot of optimizations, both on the compiler side as well as when implementing e.g. containers in user code. So no there is no way to always get notified. I also proposed a move constructor in the past, but the idea was not well recieved. When I needed a move constructor, usually adding another level of indirection solved the problem. Kind Regards Benjamin Thaut
Re: How to build DMD on windows ?
Am 03.03.2014 21:49, schrieb Remo: On Monday, 3 March 2014 at 19:51:45 UTC, Benjamin Thaut wrote: Am 28.02.2014 21:14, schrieb Remo: How to build DMD on windows ? And then run all the test for it? README.md is pretty empty at the moment. Of course it is possible to wait for some Fixes in DMD compiler may be it could be faster just to fix them by my self and then hope that the fix will be accepted... Easiest way (but you need visual studio): 1) checkout the latest version (or a tag) from https://github.com/D-Programming-Language/dmd 2) Open the Visual Studio solution src/dmd_msc_vs10.sln and build using the release target. Benefit from a compiler which is 3 times faster compared to a dmd build with dmc. Kind Regards Benjamin Thaut Thanks, I already found Visual Studio solution. By the way it compiles with VS2012 but not with VS2013. I think no one tried with 2013 yet. Whats the problem?
Re: How to build DMD on windows ?
Am 28.02.2014 21:14, schrieb Remo: How to build DMD on windows ? And then run all the test for it? README.md is pretty empty at the moment. Of course it is possible to wait for some Fixes in DMD compiler may be it could be faster just to fix them by my self and then hope that the fix will be accepted... Easiest way (but you need visual studio): 1) checkout the latest version (or a tag) from https://github.com/D-Programming-Language/dmd 2) Open the Visual Studio solution src/dmd_msc_vs10.sln and build using the release target. Benefit from a compiler which is 3 times faster compared to a dmd build with dmc. Kind Regards Benjamin Thaut
Re: Sorting structs?
Am 29.01.2014 10:33, schrieb Boomerang: Hello everybody. I'm trying to learn D by solving simple exercises. The current exercise: read names and grades of students, then print the names of students in descending order of their grades. In C++, I would define a Student struct, overload the operators: bool operator<(const Student&, const Student&) std::istream& operator>>(std::istream&, Student&) Then I'd store the Students in let's say a std::vector, sort it in reverse, then print it accordingly. But I don't know how to do things in D. I'm reading Cehreli's book, so far I've only finished its first trinity (just before struct). I would appreciate it if you explained your approach and gave source code illustrating it. Thanks! You can either overload the compare operator for the struct struct bla { int i; int opCmp(ref const(bla) rh) { if(this.i < rh.i) return -1; if(this.i > rh.i) return 1; return 0; } } or you could just pass a different compare less expression to sort bla[] arrayToSort; sort!"a.i < b.i"(arrayToSort); You can also pass a lambda or any function as compare less function to sort: sort!((a,b){return a.i < b.i;})(arrayToSort); Kind Regards Benjamin Thaut
Re: Linux dll struct class etc
Am 28.01.2014 03:40, schrieb Mineko: I can't remember whether or not I've asked this.. But either way, is it possible to "export" a class or a struct or something like you do with a windows dll with a linux shared library (dll)? You should be able to use classes from dynamic libraries just like you use classes from static libraries on linux. On windows the dll support is incomplete and it is not possible at the moment, to use a dll the same way as a static library. It is however possible to use factory functions on windows. But you will run into numerous other problems with windows dlls, so I don't recommend it. In case you are interrested read: http://wiki.dlang.org/DIP45 Kind Regards Benjamin Thaut
Re: Profiling
On Saturday, 25 January 2014 at 15:34:57 UTC, Philippe Sigaud wrote: On Fri, Jan 24, 2014 at 10:25 PM, Benjamin Thaut wrote: What Plattform are you profiling on? Linux 32bits. Does it change something? I'm not using any OS-specific part of Phobos, AFAICT. Doesn't really change something. But if you would have been profiling on Windows I could have recommended some profilers / tools. Kind Regards Benjamin Thaut
Re: How to destroy a shared struct.
On Sunday, 26 January 2014 at 17:15:10 UTC, Marco Leise wrote: Since shared hasn't change much in the last years, I assume it is somewhat accepted in its current state. My understanding is that if something cannot be attributed to a single thread, it is "shared". So far so good. Now I wrote an object pool struct with two properties: it can be used by multiple threads during its lifetime and this(this) is disabled. Logically the struct is both created and destroyed while only the creator thread (which holds the data) has access to it and there is no two ways about it. An object can only be destroyed when it is no longer shared. Yet the D compiler asks for a shared ~this(). This sounds as if it asks me to commit a logical error. So the question is, how do I define a shared struct without a shared ~this() which would be broken by definition? I ran into this issue some time ago too. https://d.puremagic.com/issues/show_bug.cgi?id=8295 Walter stated in a discussion on the newsgroup that this is by design. It basically came down to, that shared structs should not be destroyed ... Although I really don't agree with this, it should be fixed. In my opinion it should not be neccessary to have a shared destructor, because as soon as it is destroyed, it is no longer shared. So no special shared destructor should be neccessary.
Re: Linux dll -> Windows dll
Am 25.01.2014 04:13, schrieb Mineko: Alright.. I've been having issues with getting windows DLL's to work with DMD, as in I can't make them and can't even compile without a bunch of errors. So, I need help on that, as the dll part of the site ain't helping. Also, any idea on how to convert some of the dll stuff on https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d to be windows compatible, I was having weird issues with that also. Windows Dlls are fundamentally broken. The only thing that works at the moment are DLLs with a C-Interface (written in D). DLL support on Windows is nowhere near the shared library support on linux. I tried pushing for a fix, but its currently not a priority. See http://wiki.dlang.org/DIP45 Kind Regards Benjamin Thaut
Re: Profiling
Am 24.01.2014 17:31, schrieb Philippe Sigaud: I'm trying to use the `-profile` flag for DMD and, without any documentation, I can't really understand the resulting log files: * They contain only mangled names. Is there a way to get demangled, human-readable symbols? * Can someone tell me what the numbers means? Is there a page somewhere on dlang.org that explains how to use the profiler? Thanks, Philippe What Plattform are you profiling on?
Re: problems with mixins and non-ascii characters
Am 22.01.2014 11:46, schrieb bearophile: Uplink_Coder: is there any workaround for this ? For me this is a feature, not a bug. Bye, bearophile Why that? D is supposed to support unicode identifiers, and in this case it cleary does not?
Re: shared methods
Am 22.01.2014 06:16, schrieb unknown soldier: I'm confused by shared and how to use it. import std.stdio; class Foo { File logFile; void log(in string line) shared { synchronized(this){ logFile.writeln(line); } } } This (or the equivalent code in my full size program) won't compile: source/log.d(256): Error: template std.stdio.File.writeln does not match any function template declaration. Candidates are: /usr/include/dmd/phobos/std/stdio.d(781): std.stdio.File.writeln(S...)(S args) source/log.d(256): Error: template std.stdio.File.writeln(S...)(S args) cannot deduce template function from argument types !()(const(immutable(char)[])) shared Why is logFile suddenly being treated as shared? This does not make sense to me. As a programmer I have acknowledged that log() is a shared function in the declaration 'void log(in string line) shared', so isn't it up to me to ensure that I do proper synchronization within the function? Why is the compiler trying to ensure that all functions called within log() are also marked shared? What is the right thing to do here? Note that I can't just mark log() as not shared; log() must be shared because elsewhere I have: shared Foo sfoo = ... sfoo.log(...) For a shared method the this pointer is also shared. That means that you have to tell the compiler (manually) that it is now safe to use non-shared code. You usually do this by casting the this pointer to a unshared type. class Foo { File logFile; void log(in string line) shared { synchronized(this){ // safe from here on because synchronized auto self = cast(Foo)this; self.logFile.writeln(line); } } } The compiler does not do this for you, because it can not know if accessing any member is truly thread-safe. You might share the logFile with other instances of Foo. This would be a case where the compiler would wrongly remove the shared from this, if it would do so automatically inside synchronized blocks.
Re: struct postblit not called, but still destructed
Am 19.01.2014 18:48, schrieb Lemonfiend: import std.stdio; struct C { A[] _objs; this(A[] objs...) { writeln(` C this()`); _objs = objs; // A.this(this) is not called // yet A.~this IS called } } struct B { A sup; alias sup this; this(A a) { writeln(count, ` B this()`); sup = a; } } struct A { static int count; this(int n) { count++; writeln(count, ` A this()`); } this(this) { count++; writeln(count, ` A this(this)`); } ~this() { count--; writeln(count, ` A ~this()`); } } void main() { A a = A(1); writeln(a.count == 1); B b = B(a); writeln(a.count == 2); C c = C(b); writeln(a.count == 3); } Yes this looks like a bug to me. Please file a bug report at https://d.puremagic.com/issues/ Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 13.01.2014 21:52, schrieb Xavier Bigand: glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) glBindBuffer(GL_ARRAY_BUFFER,10) glEnableVertexAttribArray(0) glVertexAttribPointer(0,3,GL_FLOAT,false,12,) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4 ->glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) ->->glUseProgram(4) ->->glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00]) ->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) ->->glBindBuffer(GL_ARRAY_BUFFER,10) ->->glEnableVertexAttribArray(0) ->->glVertexAttribPointer(0,3,GL_FLOAT,false,12,) ->->glBindBuffer(GL_ARRAY_BUFFER,11) ->->glEnableVertexAttribArray(1) ->->glVertexAttribPointer(1,4,GL_FLOAT,false,16,) ->->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4 This extract seems to correspond of latest gl command called just before the crash after the window resize. It doesn't seems to have any error here. Yes this indeed looks correct. Maybe its even a bug in the driver. Because it happens right after the window resize graphic resource might got invalid and the driver would need to re-create them. The problem ist most likely that you use two array buffers, one for each attribute, instead of using one array buffer and interleaving the attribute (this is the usual way). I could bet, that if you switch over to the interleaved variant, the problem goes away. You could also try to make the three buffers slightly larger and specifiy different pointers to see which one actually causes the invalid read. So that the calls become: > ->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) > ->->glBindBuffer(GL_ARRAY_BUFFER,10) > ->->glEnableVertexAttribArray(0) > ->->glVertexAttribPointer(0,3,GL_FLOAT,false,12,) > ->->glBindBuffer(GL_ARRAY_BUFFER,11) > ->->glEnableVertexAttribArray(1) > ->->glVertexAttribPointer(1,4,GL_FLOAT,false,16,0016) > ->->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,0004) GLSL=4 You could then see from the access violation which of the three buffers the read attempt fails. You could also try to move the glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) right before the glDrawElements call. Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 12.01.2014 17:18, schrieb Xavier Bigand: Le 12/01/2014 11:16, Benjamin Thaut a écrit : Am 12.01.2014 00:47, schrieb Xavier Bigand: I didn't know this menu settings, but activate Access Violation don't change anything. It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut Thank for your support and your time I already tried to debug opengl with gdebugger is used to find those kind of issues. But it doesn't seems working fine with D binaries. I higly recommend using either glIntercept (http://code.google.com/p/glintercept/) or glslDevil (http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL applications. If you have a nvidia card you could also use nvidia nsight to debug your application: https://developer.nvidia.com/nvidia-nsight-visual-studio-edition My guess would be that either your vertex buffer or index buffer is no longer valid, thus gets not bound, and as a result the graphics driver reads from client memory at address null. Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 12.01.2014 00:47, schrieb Xavier Bigand: I didn't know this menu settings, but activate Access Violation don't change anything. It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Ok, I can reproduce this, and it seems that the crash happens somewhere in no mans land. That means there is no debugging information present and the stack frame isn't valid either. So the debugger and druntimes buildin stacktrace code has no chance. My guess would be that this happens inside druntime or phobos. So to debug this issue you will have to build a debug version of druntime and phobos (just modify the DFLAGS variable inside the .mak files accordingly and build them using the digital mars make). And then link against these debug versions (using the -debuglib switch). I would recommend renaming the debug versions so you can use them whenever needed. I will take a deeper look tomorrow. Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 11.01.2014 22:56, schrieb Xavier Bigand: Le 11/01/2014 22:15, Benjamin Thaut a écrit : Am 11.01.2014 20:50, schrieb Xavier Bigand: Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing. That is very strange. Can you reduce this? Or is this project on github somewhere? Did you try using a debugger? Kind Regards Benjamin Thaut Yes it's on github : https://github.com/Flamaros/DQuick/tree/Missing_RAII_Warning Ro reproduce the crash : - You can launch the DQuick-VisualD.sln solution file that is in the root folder. - Launch the Text project (in debug mode) - Resize the Window, it crash directly It seems to be related to the GraphicItem class in startPaint methode, particulary this section of code : debug { if (mRebuildDebugMeshes) updateDebugMesh(); mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Putting it under comment remove the crash. Thank you for your help. If you use VisualD why don't you go to "Debugging->Execptions" in Visual Studio and activate the "Access Violation" under "Win32 Exceptions" to debug that access violation with the visual studio debugger? Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 11.01.2014 20:50, schrieb Xavier Bigand: Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing. That is very strange. Can you reduce this? Or is this project on github somewhere? Did you try using a debugger? Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 11.01.2014 19:16, schrieb Xavier Bigand: Le 11/01/2014 18:45, Benjamin Thaut a écrit : Am 11.01.2014 17:24, schrieb Xavier Bigand: I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode? For x64 exeuctables compile with -g. For x86 executables compile with -g and then run cv2pdb on the final executable. cv2pdb is part of VisualD. Kind Regards Benjamin Thaut Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g. And it does not print a stack trace? Is it possbile that this access violation happens within a module constructor? Try importing core.sys.windows.stacktrace into every single one of your modules and see if that changes something. Kind Regards Benjamin Thaut
Re: [Windows & DMD] No callstack when crash with Access violation reading location 0x00000000
Am 11.01.2014 17:24, schrieb Xavier Bigand: I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode? For x64 exeuctables compile with -g. For x86 executables compile with -g and then run cv2pdb on the final executable. cv2pdb is part of VisualD. Kind Regards Benjamin Thaut
Re: Study on hash associative arrays
Am 09.01.2014 11:48, schrieb bearophile: Through Reddit I've found posts about hash-based associative arrays: http://bannalia.blogspot.it/2013/10/implementation-of-c-unordered.html http://bannalia.blogspot.it/2014/01/a-better-hash-table.html Those little images like this one are excellent at explaining in a short space the basic structure of a data structure: http://4.bp.blogspot.com/-jh0W64vfSt8/UsmZMel5gQI/AvU/k6ThAu4mL2M/s400/boost.multiindex_1.png I think the online documentation should have images like this one for AAs, and other data structures. Do you know what's the structure of the D built-in AAs, and are the ideas in those two posts useful to improve D AAs? Bye, bearophile I recently did a comparison of 3 different hashmap implementations in the following thread: http://forum.dlang.org/thread/dfyowpjhdaemhxhep...@forum.dlang.org?page=4#post-l9nbqj:242qlg:241:40digitalmars.com
Re: Getting backtrace
Am 08.01.2014 21:25, schrieb Xavier Bigand: Is there a way to get backtrace outside exceptions? On which plattform?
Re: Getting backtrace
Am 08.01.2014 21:25, schrieb Xavier Bigand: Is there a way to get backtrace outside exceptions? Found a plattform independend way: import core.runtime; import std.stdio; void main(string[] args) { auto trace = defaultTraceHandler(null); foreach(t; trace) { writefln("%s", t); } }
Re: Debug/reduce stack overflow in DMD on Windows
Am 30.12.2013 14:04, schrieb Jacob Carlborg: I've ported one of my projects[1] from D1 to D2 and it works perfectly fine on Posix. Now when I try to compile the code on Windows I get a stack overflow. I really suck at Windows development, I don't even know where to start. Which debugger should I use that can handle the debug format DMD is compiled with? [1] https://github.com/jacob-carlborg/dvm/tree/master Compile in 64-bit and use Visual Studio or Visual Studio Express to debug the application. If you want to compile in 32-bit you will need to run cv2pdb on the generated exectuable before debugging with visual studio. cv2pdb is part of VisualD which I recommend using for any windows development. Kind Regards Benjamin Thaut
Re: GtkD icon theme issue
Am 30.12.2013 00:24, schrieb Mike Wey: The normal version works on Windows, i'll include these in the installer. As for installing the themes separately you'll need auomake and GnuMake. I don't know if you have these installed, but i've created a zip http://gtkd.org/Downloads/gtk-icon-theme.zip which you can extract in: C:\Program Files\Gtk Runtime\share\ That should be enough to get rid of the errors. Thank you very much. That worked. Kind Regards Benjamin Thaut
GtkD icon theme issue
I'm currently working with a file chooser. Whenever I open a folder that actually contains file I get the following error message: Assertion file 'gtk' line 0: Could not find the icon 'gtk-file'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases Do I need a special version of these icon themes for windows, or will the normal version just work? Is there something special I need to do for installation? Kind Regards Benjamin Thaut