Re: Blog post: using dynamic libraries in dub
On Thursday, 21 December 2017 at 13:30:32 UTC, David Nadlinger wrote: There would probably have to be some sort of compatibility flag to avoid breaking all libraries on systems where symbols are visible externally by default (Linux, ...). — David Agree, although this currently really is a bad default. Having all symbols visible by default can lead to really long shared library load times especially with template heavy code. I've seen reports of shared libaries using boost in c++ having load times of 60 seconds and above due to the number of visible symbols. Ideally we should end up with visibility hidden being the default and only making symbols visible which use "export", because that is what it was designed for in the first place.
Re: Blog post: using dynamic libraries in dub
On Wednesday, 20 December 2017 at 08:09:53 UTC, Martin Nowak wrote: At some point `dub build` should get a `--shared` option to change the meaning of `library` target types from `staticLibrary` to `dynamicLibrary`. The shared libs could be linked with absolute paths. Would this work in all cases? Do tls variables work across Linux shared libraries? Do we expect all dub libraries to have correct export annotations once export goes live?
Re: Minecraft written in D - on Android
On Tuesday, 26 April 2016 at 08:42:21 UTC, Vadim Lopatin wrote: Demo of DlangUI Scene3D engine - Minecraft-like voxel rendering - is available for Android/ARM. Post screenshots please.
Re: Visual D 0.3.38 released
Awesome work Rainer, thank you very much. But the download is not working for me, I'm getting a ec_error_revoked_certificate Kind Regards Benjamin Thaut
Re: Visual D 0.3.38 released
Am 12.04.2014 13:42, schrieb Rainer Schuetze: On 12.04.2014 13:21, Benjamin Thaut wrote: Awesome work Rainer, thank you very much. But the download is not working for me, I'm getting a ec_error_revoked_certificate Hmmm, maybe github/amazonaws are currently changing their certificates. If you are using Firefox, according to some tutorials you should disable OCSP in Options-Advanced-Certificates-Validation. That works for me, but I don't know what security holes are punched into the browser. Rainer It also works if I remove the s from https in the url it jumps to.
Re: Visual D 0.3.37 released
Am 05.02.2014 13:21, schrieb Manu: Any chance you can release a beta with that settings bug fixed? I've supervised 2 new VD installs the last couple of days, and they all suffer the problem with the mspdb dll path not being remembered in the exe path settings. Temporary workaround: http://stuff.benjamin-thaut.de/D/visualdfix.reg Download and run. This is for visual studio 2010. If you need it for a different version you have to open it with a text editor and change 10.0 to 11.0 for 2012 and 12.0 for 2013. Kind Regards Benjamin Thaut
Re: DirectX bindings
Am 03.02.2014 10:55, schrieb evilrat: it has been for a long time since i released this bindings, so i wonder if anyone uses this in their projects? it would be nice to see some results of projects using this bindings :) I'm currently using them. But there is nothing showabe yet. I will keep you posted.
Re: dmd 2.065 beta 2
Am 29.01.2014 08:43, schrieb deadalnix: Awesome, that compile my code and test suite are passing. Everything looks good ! As usual, my code doesn't compile. I filed a bug report: https://d.puremagic.com/issues/show_bug.cgi?id=12023
Re: Start of dmd 2.064 beta program
Am 18.10.2013 20:45, schrieb Andrei Alexandrescu: Walter and I frequently think of ways to gently steer people toward working on specific items. Votes, categorization, discussions are of limited impact. On occasion we've emailed major contributors directly and asked politely but point blank if they could look into an issue (sometimes something they had an expertise in, or even an issue they had caused). The rate of success has been very low. People still love working on things, just not on the things they're told to. I think you should continue to do that. Even if it only has a small sucess rate. I for example wouldn't have noticed that the stack trace code I submitted into druntime did cause long startup times for D-Programms that are run directly from the root of a disk drive if Walter wouldn't have send me the e-mail with the bug in it. After the e-mail I even fixed the bug ;-) Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
Am 18.10.2013 09:33, schrieb deadalnix: On Friday, 18 October 2013 at 07:21:47 UTC, Walter Bright wrote: On 10/17/2013 11:45 PM, deadalnix wrote: Also, when NOT using the unittest flag, a lot of my code do not compile, symbol _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing. See: http://d.puremagic.com/issues/show_bug.cgi?id=11284 I blasted everything from dmd/druntime/phobos and my own project and recompiled everything from master for D projects and then my project is compiled with the new dmd, everything with the same flag. I highly doubt that this fit into cases 1 to 4 as you mention. I'll however double check with that in mind. That also doesn't explain why I get a closure bug (frame pointer or frame content is corrupted) when compiling with unittest. The code that fail isn't even unittested ! I have a similar issue than yours. The symbol that is missing for me is not even contained within any version or debug block. See: http://d.puremagic.com/issues/show_bug.cgi?id=11280 Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements?
Re: Start of dmd 2.064 beta program
Am 15.10.2013 11:25, schrieb Walter Bright: On 10/15/2013 1:50 AM, Benjamin Thaut wrote: Am 14.10.2013 23:19, schrieb Walter Bright: On 10/14/2013 6:25 AM, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... Is it possible you are linking together code compiled with different command line -version or -debug switches? I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements? dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library. The funny thing is, its not a template. Nothing fancy at all. Just a struct with two members. And the linker complains that the __init member of that struct is missing. Error 42: Symbol Undefined _D6thBase6plugin8ScanPair6__initZ Also the library and importer are compiled with exactly the same -debug and -version switches. I did setup a dustmite reduce process but its going to take a few hours for that to complete. Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
Am 13.10.2013 00:16, schrieb Walter Bright: http://ftp.digitalmars.com/dmd2beta.zip This zip does not contain the latest version of Optlink. The one at http://ftp.digitalmars.com/optlink.zip seems to be newer. Kind Regards Benjamin Thaut
Re: Start of dmd 2.064 beta program
Am 14.10.2013 10:59, schrieb Walter Bright: On 10/14/2013 12:50 AM, Benjamin Thaut wrote: Am 13.10.2013 00:16, schrieb Walter Bright: http://ftp.digitalmars.com/dmd2beta.zip This zip does not contain the latest version of Optlink. The one at http://ftp.digitalmars.com/optlink.zip seems to be newer. That one is dated 04-10-13, while the one in the zip file is dated 08/28/13, so I'm not sure why the former is newer. My bad. German dates... We write the the day first then the month and then the year.
Re: Start of dmd 2.064 beta program
Am 13.10.2013 00:16, schrieb Walter Bright: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED This isn't a release candidate, in particular the documentation needs work, but we need to shake the tree for any undetected regressions. Further beta announcements go in the dmd-beta mailing list. Note that this release contains: 29 enhancements 307 dmd bugs fixed 14 druntime bugs fixed 73 phobos bugs fixed I just upgraded to dmd 2.064 and there are most likely multiple new struct lifetime bugs. I'm going to file them as soon as I find them, but first I have to get the debugger working again. The patch I used for dmd to be able to debug D programs with visual studio no longer works for dmd 2.064.
Re: Start of dmd 2.064 beta program
Am 14.10.2013 15:14, schrieb Benjamin Thaut: Am 13.10.2013 00:16, schrieb Walter Bright: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED This isn't a release candidate, in particular the documentation needs work, but we need to shake the tree for any undetected regressions. Further beta announcements go in the dmd-beta mailing list. Note that this release contains: 29 enhancements 307 dmd bugs fixed 14 druntime bugs fixed 73 phobos bugs fixed I just upgraded to dmd 2.064 and there are most likely multiple new struct lifetime bugs. I'm going to file them as soon as I find them, but first I have to get the debugger working again. The patch I used for dmd to be able to debug D programs with visual studio no longer works for dmd 2.064. I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating...
Re: Article series about patterns idioms in D
Am 13.07.2013 13:10, schrieb Jakob Ovrum: On Friday, 12 July 2013 at 06:53:48 UTC, Benjamin Thaut wrote: Feedback is welcome. One of the article says that only one AliasThis is allowed per type, which is only half the truth. Multiple AliasThis are meant to be allowed by the language but has not been implemented. Thanks for the information, didn't know that. Still I like to only advertise things that are already working. Kind Regards Benjamin Thaut
Article series about patterns idioms in D
I started a small article series on D specific patterns idioms on my blog. I'm going to add more over time and hope that there are at least some in there which are not already known to everyone. You can find them here: http://3d.benjamin-thaut.de/?cat=17 Currently there are two: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 2) D templated interface idiom: http://3d.benjamin-thaut.de/?p=94 Feedback is welcome. Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
D strives to prevent implict conversion between user defined types at all costs. I don't think this is true. Implicit conversions are very useful. What D prevents are implicit conversions that can result in data loss, such as integer truncation. I did talk about implict conversions between user defined types. D does not have implict construction, or implict casting like C++ does. I did not talk about builtin types. -- Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
Am 12.07.2013 17:12, schrieb Tobias Pankrath: On Friday, 12 July 2013 at 09:42:28 UTC, Benjamin Thaut wrote: D strives to prevent implict conversion between user defined types at all costs. I don't think this is true. Implicit conversions are very useful. What D prevents are implicit conversions that can result in data loss, such as integer truncation. I did talk about implict conversions between user defined types. D does not have implict construction, or implict casting like C++ does. I did not talk about builtin types. What's about alias this? Did you even read the article? -- Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
Am 12.07.2013 15:26, schrieb Ary Borenszweig: On 7/12/13 3:53 AM, Benjamin Thaut wrote: I started a small article series on D specific patterns idioms on my blog. I'm going to add more over time and hope that there are at least some in there which are not already known to everyone. You can find them here: http://3d.benjamin-thaut.de/?cat=17 Currently there are two: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 2) D templated interface idiom: http://3d.benjamin-thaut.de/?p=94 Feedback is welcome. Kind Regards Benjamin Thaut This sentence worries me a bit: The code shown above has been tested with dmd 2.063.2 It seems like every minor release of D works different than previous ones. Is that true? Isn't it enough to say D2? Can something be done to prevent this? The shown code should work all versions of D 2.0 since 2.053 (I'm using it since then). I only mentioned the version of the dmd compiler, because I previously had issues with some of my articles where someone would say but that statement is not true, it works with the current version of dmd. Kind Regards Benjamin Thaut -- Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
Am 12.07.2013 21:00, schrieb Walter Bright: On 7/12/2013 2:42 AM, Benjamin Thaut wrote: D strives to prevent implicit conversion between user defined types at all costs. Ok - but I think it would be clearer if the statement added for user defined types. For me there is already a between user defined types in the following sentence: D strives to prevent implicit conversions between user defined types at all costs. Is that not clear enough?
Re: DConf 2013 Day 2 Talk 5: A Precise Garbage Collector for D by Rainer Schütze
Am 08.06.2013 09:50, schrieb Rainer Schuetze: On 06.06.2013 22:27, Benjamin Thaut wrote: Am 06.06.2013 08:28, schrieb Rainer Schuetze: On 05.06.2013 16:14, bearophile wrote: Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1fpw2r/dconf_2013_day_2_talk_5_a_precise_garbage/ Is this useful to make the GC precise regarding the stack too? http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570 I was imagining something similar too. The part about multi-threading in the paper isn't too convincing, though. Especially the need for GC safe points in tight loops to block a thread during collection will not get many friends in the D community. I think you don't really need percise scanning which is thread safe. If you have one pool per thread, and you can scan the thread local pools percisley within the thread that would be enough. Because you would then be able to do generational garbage collection for the thread local pools. If you have to scan one of (or the) global pool, percise scanning of the stacks is not really needed, the old impercises scanning is sufficient, you just have to pin those memory blocks you might think are referenced from stack memory. Wouldn't that mean a write-barrier for every pointer assignment? Not for every pointer assignment, only for pointers that are on the heap. Also most of these write barries could be skipped with really cheap tests most of the time. But to be able to actually do thread local pools a bit more then write barriers would be needed. For each of the following situations a call into druntime would be needed. 1) Creating a shared or immutable object 2) Casting to shared or immutable 3) Assigning a shared, immutable, __gshared global or static variable Considering string is immutable(char)[], would you want to allocate all temporary strings on the global heap? Also, I don't like to have possible expensive operations for casting. Good point, didn't think about that yet. In Order to improve the performance of the GC we have to sacrifice performance in other places of the language in my opinion. Given the fact that the current GC is 3 times slower then manual memory mangement (in my test case). It should be easly possible to take a performance hit here and there but end up beeing faster in the end anyway. The current GC is especially bad with short lived allocations and I don't think this is going to get any better when only using a Mark Sweep. The D community has to see that to get a state of the art GC some perfomance sacrifces have to be done. If those are not wanted we can go back to manual memory management right away, in my opinion. I recently also had a long talk with Claus Gittinger (created the SmalltalkX VM) about the topic. He also had the same opinion on the topic. He also stated that it is going to be very hard if not impossible to implement a state of the Art GC into a language like D which does not have any restrictions in the language which help with that Task. If you have these and you are able to percisley scan the stack for the current thread only you will then be able to move all of the referenced memory from the thread local pool to the global pool if any of the above calls happen. This would mean that most of the time only thread local garbage collection would be neccessary and you won't have to stop other threads from doing whatever they are doing. Only in rare cases it should be necessary to scan the global pool. I agree that a thread local pool can give good performance improvements. But as long as you still have a global heap (which you probably cannot eliminate), it's not a simplification to have thread local garbage collections in addition. No one said that it is a simplification. Its always going to get more complicated if you want a better GC. The problem to implement it is that shared semantics are still pretty undefined. AFAICT shared is only a type modifier that has different conversion rules than non-shared types. There are no runtime guarantees with shared, even less with the absence of shared, and even if they exist, __gshared and casting are meant to subvert them. Then maybe the semantics of shared should be defined with a GC in mind.
Re: Unmanaged - a D framework on github
Am 30.03.2013 16:38, schrieb D-Ratisueur: Its too late...errors are made,anyway you got the stuff: http://www.youtube.com/watch?v=KZKAVl_qX_Y. I Should wait a few weeks before announcing Unmanaged...I feel quite shamefull right now... This was no criticism on your project. I'm only pointing out issues in the language you can't really do anything about. Kind Regards Benjamin Thaut
Re: Unmanaged - a D framework on github
Am 17.03.2013 16:20, schrieb Jakob Ovrum:
On Saturday, 16 March 2013 at 14:40:58 UTC, D-ratiseur wrote:
new is overriden in TUObject because the purpose of the library is to
bypass the garbage collector and to bypass the GC you have to
override new and delete.(at least according to the manual:
articles,mem managment).
The documentation on this is old and misleading.
Overloading of new and delete is deprecated (the delete operator in its
entirety is deprecated).
Having them overloadable was not a very good idea. The current approach
is to have new always mean GC memory, which is why there is no need
for delete. This way, code that uses 'new' won't break horribly or leak
depending on the type involved, important for generic code. Code that
doesn't use the GC has to be designed for it; you can't just remove the
GC under everyone's noses and expect things to work.
For different kinds of memory, you should simply use a different
allocator. For example, here's a rough approximation of a pair of
functions using malloc/free for class allocation:
T alloc(T)() if(is(T == class))
{
enum size = __traits(classInstanceSize, T);
auto p = enforceEx!OutOfMemoryError(malloc(size));
return emplace!T(p[0 .. size]);
}
void dealloc(T)(ref T obj) if(is(T == class))
{
free(cast(void*)obj);
obj = null;
}
It can easily be overloaded to support all types.
In the future, Phobos will have a custom memory allocator library, which
modules like std.container will use, though to which extent is not clear
(for example, will it also use the custom allocator for exception
objects?). Nevertheless it will probably be a good base for other
libraries to easily support non-GC allocators.
You still can't replace evertything with custom alloc templates and have
nice syntax. There are at least two cases where it does not work nicely:
1) Arrays (no new T [size] syntax)
2) Inner classes (a template can't automatically capture the outer class)
So I think overloading new and delete actually has its place. But the
way it is currently implemented in D is useless in my eyes.
Kind Regards
Benjamin Thaut
Re: Unmanaged - a D framework on github
Am 20.03.2013 13:42, schrieb Jacob Carlborg:
On 2013-03-20 08:57, Benjamin Thaut wrote:
You still can't replace evertything with custom alloc templates and have
nice syntax. There are at least two cases where it does not work nicely:
1) Arrays (no new T [size] syntax)
2) Inner classes (a template can't automatically capture the outer class)
So I think overloading new and delete actually has its place. But the
way it is currently implemented in D is useless in my eyes.
Instead of having a special keyword like we have now. We could have, as
has been suggested before, a regular function or method.
With a class, there's also the possibility to return a different type or
a singleton:
class Foo
{
Foo new ()
{
return Bar.new();
}
}
class Bar : Foo {}
But with a regular function you always have the problem that you need to
pass the constructor argumnets along. If there are implict conversion
form literals to constructor arguments neccessary this will fail as soon
as you pass them through a function.
Kind Regards
Benjamin Thaut
--
Kind Regards
Benjamin Thaut
Re: Instructions how to build MinGW-GDC
Am 11.03.2013 02:41, schrieb Vladimir Panteleev: On Sunday, 10 March 2013 at 18:07:26 UTC, Benjamin Thaut wrote: I struggeled building mingw-gdc the past few days, so I though I post up to date build instructions now that I figured how it works: http://3d.benjamin-thaut.de/?p=71#more-71 Benjamin, could you please update the wiki page as well? http://gdcproject.org/wiki/MinGW64 I think it's better if we kept such oft-changing instructions in one publicly-editable place rather than scattered all over the web. I will, wasn't aware that anyone can edit the wiki. Kind Regards Benjamin Thaut
Instructions how to build MinGW-GDC
I struggeled building mingw-gdc the past few days, so I though I post up to date build instructions now that I figured how it works: http://3d.benjamin-thaut.de/?p=71#more-71 Kind Regards Benjamin Thaut
Re: Another opportunity for a major design win has presented itself
Am 08.02.2013 08:18, schrieb Walter Bright: On 2/7/2013 10:36 PM, Oleg Kuporosov wrote: That is cool, but what is the target platform - Win/Lin, 32/64? Initially, Linux. Once that is worked out, doing the others should be straightforward. Well windows will be quite some work because DLLs are not really fully supported yet. Starting with these two issues: http://d.puremagic.com/issues/show_bug.cgi?id=3956 http://d.puremagic.com/issues/show_bug.cgi?id=6673 I will make bug reports for all the dll issues I found in the next few days. Kind Regards Benjamni Thaut
Re: Runtime code reloading in D, part 1
Am 05.01.2013 12:15, schrieb Jacob Carlborg: On 2012-12-30 13:32, Benjamin Thaut wrote: An article about runtime code reloading in the context of game developement. A topic I'm currently working on in my spare time. I hope it holds some valuable information for everyone working with D. http://3d.benjamin-thaut.de/?p=25 This looks very cool. Question, are you manually triggering the code for generating the RTTI? BTW, have you seen this old project implementing runtime reflection: http://flectioned.kuehne.cn/ Yes I know flectioned. But I did not require that much RTTI information. No I'M not manually triggering the code for generating the RTTI. As mentioned in the article it is done via the RTInfo template inside object_.d / object.di which is automatically instanciated for each type used during compilation. Kind Regards Benjamin Thaut
Re: Runtime code reloading in D, part 1
Am 05.01.2013 05:24, schrieb ixid: On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote: Am 31.12.2012 15:02, schrieb DypthroposTheImposter: Do you find that D without GC is more effective than C++? Seems like you would be stuck using structs which seems somewhat limiting, even compared to C++... UE4 has similar reloading capabilities(using DLLs), though they use C++ and rely more on the ability to serialize everything Why should I be stuck with structs? Its the exact same as in C++. I did build my own new and delete operators (as templates). It's not that hard and works pretty well, only the syntax is not ideal in some cases. I can use everything you can use with D+GC. Sometimes you have to be carefull with implict allocations (e.g. closures, array literals) but I have a leak detector that points me to these directly and usually its easy to free these manually. And I'm quite a bit more productive then in C++. Module constructors with a defined order instead of random static initalizers, code generation isnstead of huge amounts of boilerplate code and many other features are the cause of this. Kind Regards Benjamin Thaut Is D moving away from your sort of use? Games and bioinformatics would seem to be the areas the language should be trying to get people to start using it in. The features you're using seem very much like they should be a part and mode of using the language. I wouldn't say its moving away from it. Some recent changes to druntime have made it significantly less leaking. But on the other hand a API design like toString() which pretty much does leak in almost all cases don't exactly help a GC free D. In Summary it feels to me that GC free D is not important to the community or the active contributors. I also see D's biggest chances in becoming popular in the performance critical fields of programming. Which would be systems programming, Gaming and others. For programming fields in which a GC is applicable people tend to use languages like C# or Java, because they are truly safe (see the recent ref is unsafe discussion in the newsgroup), they have nice productivity features like runtime code changing through the VM and have a way better GC because the language was designed from the beginning to support a advanced GC. Kind Regards Benjamin Thaut
Re: Runtime code reloading in D, part 1
Am 06.01.2013 12:17, schrieb Jacob Carlborg: On 2013-01-06 11:30, Benjamin Thaut wrote: Yes I know flectioned. But I did not require that much RTTI information. No I'M not manually triggering the code for generating the RTTI. As mentioned in the article it is done via the RTInfo template inside object_.d / object.di which is automatically instanciated for each type used during compilation. Ah, so you modified the existing RTInfo? I didn't know that existed. It does not exist. The current RTInfo template just outputs a null pointer for every type. It is planned that the RTInfo template will be used for a percise GC in the future. (Did you read the article? ^^) Kind Regards Benjamin Thaut
Re: Runtime code reloading in D, part 1
Am 06.01.2013 12:50, schrieb Jacob Carlborg: On 2013-01-06 12:28, Benjamin Thaut wrote: It does not exist. The current RTInfo template just outputs a null pointer for every type. Yes, but it still exists. It is planned that the RTInfo template will be used for a percise GC in the future. (Did you read the article? ^^) Yes, I've read the article. How do you think I otherwise could have come up with these questions :) I can see now that you wrote: This template is instanciated for every type that is used during compilation and thus is ideal to generate RTTI information I get it now. Here is the full implementation if you are interested: https://github.com/Ingrater/druntime/blob/master/src/rtti.d Kind Regards Benjamin Thaut
Re: Runtime code reloading in D, part 1
Am 06.01.2013 13:23, schrieb Jacob Carlborg: On 2013-01-06 13:19, Benjamin Thaut wrote: Here is the full implementation if you are interested: https://github.com/Ingrater/druntime/blob/master/src/rtti.d Thanks. Is that possible to do without having to modify the runtime? No. The template has to be known inside of object_.d/object.di so it is not possible without modifing the runtime. Also you usually want to have RTTI info for druntime/phobos too.
Re: Runtime code reloading in D, part 1
Am 06.01.2013 20:55, schrieb Philippe Sigaud: On Sun, Jan 6, 2013 at 6:49 PM, Dmitry Olshansky dmitry.o...@gmail.com mailto:dmitry.o...@gmail.com wrote: Regarding toString there is a better signature that avoids useless allocations: void toString(scope void delegate(const (char)[]) sink); It takes a delegate to output string representation directly to the destination via 'sink' delegate (that may e.g. write chars to file). Plus the 'scope' part of declaration avoids allocating the said delegate on the heap. I'd even say that string toString(); is an artifact of the past, instead to!string should be used (if allocating a string is fine). I know you explained that already, but see, that again slipped my mind. This toString(sink) thingy seems cool, but is there a documentation on it somewhere? Without a related doc, I fear no one will know this exists. There was a language change request for it in the wiki, but I can't find it anymore. Kind Regards Benjamin Thaut
Re: Runtime code reloading in D, part 1
Am 31.12.2012 15:02, schrieb DypthroposTheImposter: Do you find that D without GC is more effective than C++? Seems like you would be stuck using structs which seems somewhat limiting, even compared to C++... UE4 has similar reloading capabilities(using DLLs), though they use C++ and rely more on the ability to serialize everything Why should I be stuck with structs? Its the exact same as in C++. I did build my own new and delete operators (as templates). It's not that hard and works pretty well, only the syntax is not ideal in some cases. I can use everything you can use with D+GC. Sometimes you have to be carefull with implict allocations (e.g. closures, array literals) but I have a leak detector that points me to these directly and usually its easy to free these manually. And I'm quite a bit more productive then in C++. Module constructors with a defined order instead of random static initalizers, code generation isnstead of huge amounts of boilerplate code and many other features are the cause of this. Kind Regards Benjamin Thaut
Re: DConf 2013: The new Call for Submissions is out!
Am 29.12.2012 22:00, schrieb Andrei Alexandrescu: http://dconf.org Please consider submitting and let your friends know about it! Andrei Does North America airfare mean that you only get it when you travel from within the US or does this also apply for people outside of the US? Kind Regards Benjamin Thaut
Runtime code reloading in D, part 1
An article about runtime code reloading in the context of game developement. A topic I'm currently working on in my spare time. I hope it holds some valuable information for everyone working with D. http://3d.benjamin-thaut.de/?p=25 Kind Regards Benjamin Thaut
Re: Runtime code reloading in D, part 1
Am 30.12.2012 14:27, schrieb bearophile: This seems one of the situations where knowing why is almost more important than doing: understanding the cause, and maybe even fixing it, will help future D programmers. Bye, bearophile The problem only happens if you have a POD struct in a library file (.lib). If the POD struct is directly in the main executable everything works just fine. The only hint Walter gave me when I opened a thread in the D newsgroup was look at the difference of the object files. I don't really know how that should be done atm. Kind Regards Benjamin Thaut
Re: ICE 0.1: a moddable shoot-em-up in D
Did you do something special about the GC? Does it run at all or do you somehow pool your objects? Kind Regards Benjamin Thaut
Re: ICE 0.1: a moddable shoot-em-up in D
Am 21.12.2012 00:07, schrieb Kiith-Sa: To clarify: yes, GC runs all the time. It doesn't have a whole lot to collect, though. It'd be inconvenient to disable it as I use stuff like closures for GUI, etc. It is nice to hear that leaving the GC enabled did work out for you. But basically is sounds like you are doing manual memory management after all. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Here a small update: I found a piece of code that did manually slow down the simulation in case it got to fast. This code never kicked in with the GC version, because it never reached the margin. The manual memory managed version however did reach the margin and was slowed down. With this piece of code removed the manual memory managed version runs at 5 ms which is 200 FPS and thus nearly 3 times as fast as the GC collected version. Kind Regards Benjamin Thaut
Re: D1 D2 alpha's for Win64
Am 20.10.2012 18:40, schrieb Jesse Phillips: On Saturday, 20 October 2012 at 16:26:43 UTC, Jesse Phillips wrote: Thanks for the reply. So I didn't get through all the remarks of that page: This function is implemented using a compiler intrinsic where possible. For more information, see the WinBase.h header file and _InterlockedIncrement. But that doesn't say it always is. Oh well, now I know some of the Win32 API only exists in the compiler. What about core.atomic.atomicOp!+= ? Kind Regards Benjamin Thaut
Re: Win64 milestone
Am 10.09.2012 09:07, schrieb Walter Bright: On 9/9/2012 10:07 PM, Benjamin Thaut wrote: Am 09.09.2012 23:37, schrieb Walter Bright: On 9/9/2012 1:56 PM, Nick Sabalausky wrote: Any particular version requirements on MSVC? Or too early to tell? Beats me. I just bought VC and am making it work with that. Are we going to get propper Dll support? I mean importing data symbols and a dll compatible c-runtime. It'll probably work like Win32 DLLs. Hm, a major showstopper for the current DLL support ist, that dmd does not generate code to correctly import data symbols. Kind Regards Benjamin Thaut -- Kind Regards Benjamin Thaut
Re: Win64 milestone
Am 10.09.2012 10:35, schrieb Walter Bright: On 9/10/2012 12:56 AM, Benjamin Thaut wrote: Hm, a major showstopper for the current DLL support ist, that dmd does not generate code to correctly import data symbols. What is the bugzilla entry for that? Its a pretty old ticket, Rainer Schulze implemented library code that patches the data symbol tables manually to get phobos to work as a DLL but the patch is quite old: http://d.puremagic.com/issues/show_bug.cgi?id=4071 Look at the dll_patchImportRelocations function in the druntime patch Usually the compiler should generate code to get the correct import address for each data symbol if I understood it correctly. Also there are a lot more issues with dlls, you can't export certain symbols that are needed, for example the module info internal symbols. Rainer fixed this by adding a -exportall switch to dmd. And of course there are the runtime issues with the TLS storage and Module (De)Initialization. -- Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
The full sourcecode for the non-GC version is now aviable on github. The GC version will follow soon. https://github.com/Ingrater/Spacecraft Kind Regards Benjamin Thaut
Re: Win64 milestone
Am 09.09.2012 23:37, schrieb Walter Bright: On 9/9/2012 1:56 PM, Nick Sabalausky wrote: Any particular version requirements on MSVC? Or too early to tell? Beats me. I just bought VC and am making it work with that. Are we going to get propper Dll support? I mean importing data symbols and a dll compatible c-runtime. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 07.09.2012 01:53, schrieb Sean Kelly: On Sep 6, 2012, at 10:50 AM, Benjamin Thaut c...@benjamin-thaut.de wrote: Am 06.09.2012 15:30, schrieb ponce: The problem with intstrumentation is, that I can not recompile druntime for the MinGW GDC, as this is not possible with the binary release of MinGW GDC and I did not go thorugh the effort to setup the whole build. I'm open to suggestions though how I could profile the GC without recompiling druntime. If someone else wants to profile this, I can also provide precompiled versions of both versions. You don't necessarily need to recompile anything with a sampling profiler like AMD Code Analyst or Very Sleepy I just tried profiling it with Very Sleepy but basically it only tells me for both versions that most of the time is spend in gcx.fullcollect. Just that the GDC version spends less time in gcx.fullcollect then the DMD version. As I can not rebuild druntime with GDC it will be quite hard to get detailed profiling results. I'm open for suggestions. What version flags are set by GDC vs. DMD in your target apps? The way stop the world is done on Linux vs. Windows is different, for example. I did build druntime and phobos with -release -noboundscheck -inline -O for DMD. For MinGW GDC I just used whatever version of druntime and phobos came precompiled with it, so I can't tell you which flags have been used to compile that. But I can tell you that cygwin is not required to run or compile, so I think its not using any posix stuff. I'm going to upload a zip-package with the source for the GC version soon, but I have to deal with some licence stuff first. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 07.09.2012 18:36, schrieb Andrei Alexandrescu: You mentioned some issues in Phobos with memory allocation, that you had to replace with your own code. It would be awesome if you could post more about that, and possibly post a few pull requests where directly applicable. Thanks, Andrei Let me give a bit more details about what I did and why. Druntime: I added a reference counting mechanism. core.refcounted in my druntime branch. I created a reference counted array which is as close to the native D array as currently possible (compiler bugs, type system issues, etc). also in core.refcounted. It however does not replace the default string or array type in all cases because it would lead to reference counting in uneccessary places. The focus is to get only reference couting where absolutly neccessary. I'm still using the standard string type as a only valid for current scope kind of string. I created a allocator base interface which is used by everything that allocates, also I created replacement templates for new and delete. Located in core.allocator I created a new hashmap container wich is cache friendly and does not leak memory. Located in core.hashmap I created a memory tracking allocator in core.allocator which can be turned on and off with a version statement (as it has to run before and after module ctors dtors etc) I changed all parts of druntime that do string processing to use the reference counted array, so it no longer leaks. I made the Thread class reference counted so it no longer leaks. I fixed the type info comparsion and numerous other issues. Of all these changes only the type info fix will be easily convertible into the default druntime because it does not depend on any of my other stuff. I will do a merge request for this fix as soon as I find some time. Phobos: I threw away most of phobos because it didn't match my requirements. The only modules I kept are std.traits, std.random, std.math, std.typetuple, std.uni The parts of these modules that I use have been changed so they don't leak memory. Mostly this comes down to use reference counted strings for exception error message generation. I did require the option to specify a allocator for any function that allocates. Either by template argument, by function parameter or both, depending on the case. As custom allocators can not be pure this is a major issue with phobos, because adding allocators to the functions would make them unpure instantly. I know about the C-Linkage pure hack but its really a hack and it does not work for templates. So I think most of my changes are not directly applicable because: - You most likely won't like the way I implemented reference counting - You might won't like my allocator design - My standard library goes more into the C++ direction and is not as easly usable as phobos (as performance comes first for me, and usability is second) - All my changes heavily depend on some of the functionality I added to druntime. - The neccessary changes to phobos would break a lot of code because some of the function properties like pure couldn't be used any more, as a result of language limitations. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 06.09.2012 01:10, schrieb Walter Bright: On 9/5/2012 4:03 AM, Benjamin Thaut wrote: GC collection times: DMD GC Version: 8.9 ms GDC GC Version: 4.1 ms I'd like it if you could add some instrumentation to see what accounts for the time difference. I presume they both use the same D source code. The code is identical, I did not change anything in the GC code. So it uses whatever code comes with the MinGW GDC 2.058 release. The problem with intstrumentation is, that I can not recompile druntime for the MinGW GDC, as this is not possible with the binary release of MinGW GDC and I did not go thorugh the effort to setup the whole build. I'm open to suggestions though how I could profile the GC without recompiling druntime. If someone else wants to profile this, I can also provide precompiled versions of both versions. -- Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 06.09.2012 15:30, schrieb ponce: The problem with intstrumentation is, that I can not recompile druntime for the MinGW GDC, as this is not possible with the binary release of MinGW GDC and I did not go thorugh the effort to setup the whole build. I'm open to suggestions though how I could profile the GC without recompiling druntime. If someone else wants to profile this, I can also provide precompiled versions of both versions. You don't necessarily need to recompile anything with a sampling profiler like AMD Code Analyst or Very Sleepy I just tried profiling it with Very Sleepy but basically it only tells me for both versions that most of the time is spend in gcx.fullcollect. Just that the GDC version spends less time in gcx.fullcollect then the DMD version. As I can not rebuild druntime with GDC it will be quite hard to get detailed profiling results. I'm open for suggestions. Kind Regards Benjamin Thaut
GC vs. Manual Memory Management Real World Comparison
I rewrote a 3d game I created during my studies with D 2.0 to manual memory mangement. If I'm not studying I'm working in the 3d Engine deparement of Havok. As I needed to pratice manual memory management and did want to get rid of the GC in D for quite some time, I did go through all this effort to create a GC free version of my game. The results are: DMD GC Version: 71 FPS, 14.0 ms frametime GDC GC Version: 128.6 FPS, 7.72 ms frametime DMD MMM Version: 142.8 FPS, 7.02 ms frametime GC collection times: DMD GC Version: 8.9 ms GDC GC Version: 4.1 ms As you see the manual managed version is twice as fast as the garbage collected one. Even the highly optimized version created with GDC is still slower the the manual memory management. You can find the full article at: http://3d.benjamin-thaut.de/?p=20#more-20 Feedback is welcome. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 13:10, schrieb Alex Rønne Petersen: Is source code available anywhere? Also, I have to point out that programming for a garbage collected runtime is very different from doing manual memory management. The same patterns don't apply, and you optimize in different ways. For instance, when using a GC, it is very recommendable that you allocate up front and use object pooling - and most importantly, don't allocate at all during your render loop. The sourcecode is not aviable yet, as it is in a repository of my university, but I can zip it and upload the current version if that is wanted. But it currently does only support Windows and does not have any setup instructions yet. I do object pooling in both versions, as in game developement you usually don't allocate during the frame. But still in the GC version you have the problem that way to many parts of the language allocate and you don't event notice it when using the GC. Just to clarify, I'm into 3d engine developement since about 7 years now. So I'm not a newcomer to the subject. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 14:07, schrieb Benjamin Thaut:
class A {}
class B : A{}
A a = new A();
B b = new B();
if(a == b) //this will allocate
{
}
Should be:
class A {}
class B : A{}
const(A) a = new A();
const(B) b = new B();
if(a == b) //this will allocate
{
}
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 14:14, schrieb Alex Rønne Petersen:
Where's the catch? From looking in druntime, I don't see where the
allocation could occur.
Everything is in object_.d:
equals_t opEquals(Object lhs, Object rhs)
{
if (lhs is rhs)
return true;
if (lhs is null || rhs is null)
return false;
if (typeid(lhs) == typeid(rhs))
return lhs.opEquals(rhs);
return lhs.opEquals(rhs)
rhs.opEquals(lhs);
}
Will trigger a comparison of the TypeInfo objects with
if (typeid(lhs) == typeid(rhs))
Which will after some function calls trigger opEquals of TypeInfo
override equals_t opEquals(Object o)
{
/* TypeInfo instances are singletons, but duplicates can exist
* across DLL's. Therefore, comparing for a name match is
* sufficient.
*/
if (this is o)
return true;
TypeInfo ti = cast(TypeInfo)o;
return ti this.toString() == ti.toString();
}
Then because they are const, TypeInfo_Const.toString() will be called:
override string toString()
{
return cast(string) (const( ~ base.toString() ~ ));
}
which allocates, due to array concardination.
But this only happens, if they are not of the same type, and if one of
them has a storage qualifier.
Kind Regards
Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 14:34, schrieb Peter Alexander:
On Wednesday, 5 September 2012 at 12:27:05 UTC, Benjamin Thaut wrote:
Then because they are const, TypeInfo_Const.toString() will be called:
override string toString()
{
return cast(string) (const( ~ base.toString() ~ ));
}
which allocates, due to array concardination.
Wow.
I already have a fix for this.
https://github.com/Ingrater/druntime/commit/74713f7af496fd50fe4cfe60b3d9906b87efbdb6
https://github.com/Ingrater/druntime/commit/05c440b0322d39cf98425f50172c468c6659efb8
If I find a good description how to do pull requests, I might be able to
do one.
Kind Regards
Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 15:07, schrieb Iain Buclaw:
On 5 September 2012 14:04, Iain Buclaw ibuc...@ubuntu.com wrote:
On 5 September 2012 13:27, Benjamin Thaut c...@benjamin-thaut.de wrote:
Am 05.09.2012 14:14, schrieb Alex Rønne Petersen:
Where's the catch? From looking in druntime, I don't see where the
allocation could occur.
Everything is in object_.d:
equals_t opEquals(Object lhs, Object rhs)
{
if (lhs is rhs)
return true;
if (lhs is null || rhs is null)
return false;
if (typeid(lhs) == typeid(rhs))
return lhs.opEquals(rhs);
return lhs.opEquals(rhs)
rhs.opEquals(lhs);
}
Will trigger a comparison of the TypeInfo objects with
if (typeid(lhs) == typeid(rhs))
Which will after some function calls trigger opEquals of TypeInfo
override equals_t opEquals(Object o)
{
/* TypeInfo instances are singletons, but duplicates can exist
* across DLL's. Therefore, comparing for a name match is
* sufficient.
*/
if (this is o)
return true;
TypeInfo ti = cast(TypeInfo)o;
return ti this.toString() == ti.toString();
}
This got fixed. Said code is now:
override equals_t opEquals(Object o)
{
if (this is o)
return true;
auto c = cast(const TypeInfo_Class)o;
return c this.info.name == c.info.name;
}
Causing no hidden allocation.
Oops, let me correct myself.
This was hacked at to call the *correct* opEquals method above.
bool opEquals(const Object lhs, const Object rhs)
{
// A hack for the moment.
return opEquals(cast()lhs, cast()rhs);
}
Regards
Still, comparing two type info objects will result in one or multiple
allocations most of the time.
Kind Regards
Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 16:57, schrieb bearophile: Benjamin Thaut: http://3d.benjamin-thaut.de/?p=20#more-20 Regardind your issues list, most of them are fixable, like the one regarding array literals, and even the one regarding the invariant handler. But I didn't know about this, and I don't know how and if this is fixable: The new statement will not free any memory if the constructor throws a exception. Insights welcome. Bye, bearophile Well, as overloading new and delete is deprecated, and the new which is part of the language only works together with a GC I don't think that anything will be done about this. Its not a big problem in D because you can't create arrays of objects so that multiple constructors will be called at the same time. (Which is the biggest issue in c++ with exceptions and constructors). Also doe to memory pre initialization the object will always be in a meaningfull state, which helps with exception handling too. My replacement just calls the constructor, and if a exception is thrown, the destructor is called and the memory is freed, then the new statement returns null. Works flawlessley so far. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 16:07, schrieb anonymous: It was interesting to read it. What about GDC MMM? The GDC druntime does have a different folder structure, which makes it a lot more time consuming to add in the changes. Also it is not possible to rebuild phobos or druntime with the binary release of GDC Mingw. You need the complete build setup for GDC mingw to do that. As this is not documented very well and quite some work I didn't go through that additional effort. Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
My standard library is now aviable on github: https://github.com/Ingrater/thBase Kind Regards Benjamin Thaut
Re: GC vs. Manual Memory Management Real World Comparison
Am 05.09.2012 19:31, schrieb Johannes Pfau: Would be great if some of the code could be merged into phobos, especially the memory tracker. But also things like memory or object pools would be great in phobos, an emplace wrapper which accepts a custom alloc function to replace new (and something similar for delete), etc. We really need a module for manual memory management (std.mmm?). And functions which currently use the GC to allocate should get overloads which take buffers (Or better support custom allocators, but that needs an allocator design first). I personally really like my composite template, which allows for direct composition of one class instance into another. It does not introduce additional indirections and the compiler will remind you, if you forgett to initialize it. https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d#L670 Kind Regards Benjamin Thaut
Re: D 2.0 Stacktrace
Am 10.10.2010 21:31, schrieb Denis Koroskin: On Wed, 06 Oct 2010 15:50:25 +0400, Benjamin Thaut c...@benjamin-thaut.de wrote: I wrote a small piece of sourcecode that generates stacktraces in D 2.0 under windows. It works both with the pdb and cv debug symbol format. For Exceptions that are derived from the Error class the trace information is automatically appended, this causes all builtin D errors to get a stacktrace information. The only point where this does not work is the Access Vioaltion error, as it does not call the stacktrace callback function for some reason. It is very easy to use, just copy the two files from the zip archive to your root source directory and import the stacktrace module inside your main file. For more informaiton and the download go to: http://3d.benjamin-thaut.de Let me know what you think. Kind Regards Benjamin Thaut I noticed your stacktraces should symbols but no file name/line numbers. I've sent another Stacktracer implementation to Phobos mailing list recently that primarily shows file name/line number while manually parsing .map file for symbolic info and shows none if .map file is absent. That was being criticized, and I agree with it. It also doesn't depend on dbghelp.dll and is able to show sane results even when the said .dll is missing. I think we could merge our projects, taking advantages from both. What do you think? My stackwalker does show filenames and line numbers but you need to compile with -g -debug so that there is line/file information in the symbols. If you look at the example stacktrace at http://3d.benjamin-thaut.de/?p=15 you can see filenames and line numbers -- Kind Regards Benjamin Thaut
Re: D 2.0 Stacktrace - similar problems
Am 08.10.2010 03:16, schrieb Austin Hastings: On 10/6/2010 4:00 PM, Yao G. wrote: I forgot to mention. I'm compiling the file using: dmd test.d C:\dmd\src\stacktrace.d C:\dmd\src\dbghelp.d -g -w I have a similar problem as Yao. I've got XP SP3/x86 with dbghelp.dll version 5.1.2600.5512 in the windows\system32 directory. I copied dbghelp.dll version 6.12.2.633 from a recent install of Debugging Tools for Windows (x86) into the directory with the stacktrace sources. $ ls -alG total 1211 drwxr-xr-x 2 Austin 0 Oct 7 21:12 . drwxr-xr-x 3 Austin 0 Oct 7 20:11 .. -rw-r--r-- 1 Austin 9020 Oct 7 21:04 dbghelp.d -rwxr-xr-x 1 Austin 1213200 Oct 7 20:21 dbghelp.dll -rw-r--r-- 1 Austin 1331 Oct 7 20:11 licence.txt -rw-r--r-- 1 Austin 1277 Oct 7 20:11 readme.txt -rw-r--r-- 1 Austin 11335 Oct 7 20:11 stacktrace.d -rw-r--r-- 1 Austin 90 Oct 7 20:11 test.d I compile using: $ dmd -g -w test.d stacktrace.d dbghelp.d which succeeds no problem. I put code in to check the result of the loadLibrary call, and it reports: Got valid dll handle Path: d:\devel\d\libs\src\stacktrace\dbghelp.dll So the right version is being opened. But I still get: object.Exception: Test 00 4223864 01 4223927 02 4223617 03 4439269 04 RegisterWaitForInputIdle I'm fairly certain I meet all the basic requirements: compile with -g for debug info, copy a late version of dbghelp.dll into application directory. But I'm getting the InputIdle failure, which acts like it doesn't matter. Is there an upper limit on the dbghelp.dll version? I notice that Yao reported using 6.7.5, while 6.12 is leading edge. What version are you using, Benjamin? Thanks in advance for any help, I'm really looking forward to using this module. =Austin Hm I don't have a XP machine to test on. But as Symbol 04 is resolved, it seems to work. It just can not resolve symbols inside your application. There is no upper limit to dbghelp.dll. I'm on Windows 7 with dbghelp version 6.1.7600.16385. Most likely the probelm are the CV debugging symbols, as it was kind of hacky to get it to read those. Try converting your application with cv2pdb to pdb debugging symbols and see if this fixes the problem. -- Kind Regards Benjamin Thaut
D 2.0 Stacktrace
I wrote a small piece of sourcecode that generates stacktraces in D 2.0 under windows. It works both with the pdb and cv debug symbol format. For Exceptions that are derived from the Error class the trace information is automatically appended, this causes all builtin D errors to get a stacktrace information. The only point where this does not work is the Access Vioaltion error, as it does not call the stacktrace callback function for some reason. It is very easy to use, just copy the two files from the zip archive to your root source directory and import the stacktrace module inside your main file. For more informaiton and the download go to: http://3d.benjamin-thaut.de Let me know what you think. Kind Regards Benjamin Thaut
Re: D 2.0 Stacktrace
That thread is from me. I did not issue a bug report yet, but I posted a question if there was any progress on this issue. Kind Regards Benjamin Thaut
Re: D 2.0 Stacktrace
You have to compile with the -g option so that dmd produces debugging symbols. Without symbols you will get just the addresses in your callstack. Didn't check for warnings, will fix that. Kind Regards Benjamin Thaut
