www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - TDPL goes out for preliminary review

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
TDPL, currently counting 398 pages including a small index, has entered 
editorial review this morning. The book draft includes everything except 
the threading chapter. I've marked the personal record of writing one 
chapter in one night :o).

Andrei
Dec 16 2009
next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 16/12/09 19:24, Andrei Alexandrescu wrote:
 TDPL, currently counting 398 pages including a small index, has entered
 editorial review this morning. The book draft includes everything except
 the threading chapter. I've marked the personal record of writing one
 chapter in one night :o).

 Andrei
Congratulations! I can't wait to receive my copy in a few months time :)
Dec 16 2009
prev sibling next sibling parent reply merlin <merlin esilo.com> writes:
Andrei Alexandrescu wrote:
 TDPL, currently counting 398 pages including a small index, has entered 
 editorial review this morning. The book draft includes everything except 
 the threading chapter. I've marked the personal record of writing one 
 chapter in one night :o).
Congratulations. I must profess that over the last couple of months I've been feeling a big uptick of enthusiasm about D2. It is really quit an amazing language and with library and tool support should be I did go through a period of skepticism about D leadership when I realized that D2 was not really backwards compatible with D1 and had trouble understanding why llvm hasn't played a bigger role in the long term planning of the project. I have since come around to the point of view that my fears were mostly misplaced...D2 is something quite special and I think ultimately will take hold. Ok, enough gushing :-). merlin
Dec 16 2009
parent reply retard <re tard.com.invalid> writes:
Wed, 16 Dec 2009 16:55:12 -0500, merlin wrote:

 Andrei Alexandrescu wrote:
 TDPL, currently counting 398 pages including a small index, has entered
 editorial review this morning. The book draft includes everything
 except the threading chapter. I've marked the personal record of
 writing one chapter in one night :o).
Congratulations. I must profess that over the last couple of months I've been feeling a big uptick of enthusiasm about D2. It is really quit an amazing language and with library and tool support should be I did go through a period of skepticism about D leadership when I realized that D2 was not really backwards compatible with D1 and had trouble understanding why llvm hasn't played a bigger role in the long term planning of the project. I have since come around to the point of view that my fears were mostly misplaced...D2 is something quite special and I think ultimately will take hold.
Just like D1 solved the problem of metaprogramming, D2 will solve many, if not most, multi-core threading problems with the immutable and thread local data types.
Dec 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
retard wrote:
 Wed, 16 Dec 2009 16:55:12 -0500, merlin wrote:
 
 Andrei Alexandrescu wrote:
 TDPL, currently counting 398 pages including a small index, has entered
 editorial review this morning. The book draft includes everything
 except the threading chapter. I've marked the personal record of
 writing one chapter in one night :o).
Congratulations. I must profess that over the last couple of months I've been feeling a big uptick of enthusiasm about D2. It is really quit an amazing language and with library and tool support should be I did go through a period of skepticism about D leadership when I realized that D2 was not really backwards compatible with D1 and had trouble understanding why llvm hasn't played a bigger role in the long term planning of the project. I have since come around to the point of view that my fears were mostly misplaced...D2 is something quite special and I think ultimately will take hold.
Just like D1 solved the problem of metaprogramming, D2 will solve many, if not most, multi-core threading problems with the immutable and thread local data types.
Keeping my fingers crossed regarding that one :o). Thank you for your vote of confidence, it is indeed quite a turnaround from people's (and, in fact, some of my) feelings of a few months ago. We've experienced a long, unprecedented, and completely serendipitous windfall of productivity since around the time Don joined the compiler work. I guess there is a correlation there :o). It's just been one lucky strike after another. But let's not forget we have concurrency ahead of us. I encourage you all to chime in with your thoughts and ideas regarding all aspects of concurrency. The recent multicore performance bug is a great starting point. If you try e.g. shared and it's broken, let us know. If you try it and it works, push it til it breaks. If you have ideas on how to make semantic checking better, pipe up. Andrei
Dec 16 2009
next sibling parent reply grauzone <none example.net> writes:
Andrei Alexandrescu wrote:
 But let's not forget we have concurrency ahead of us. I encourage you 
 all to chime in with your thoughts and ideas regarding all aspects of 
 concurrency. The recent multicore performance bug is a great starting 
 point. If you try e.g. shared and it's broken, let us know. If you try 
 it and it works, push it til it breaks. If you have ideas on how to make 
 semantic checking better, pipe up.
There's a guy on the NG who posts once in a while how broken shared is and how he has to use __gshared instead. His threads are being pretty much ignored. And now?
 
 Andrei
Dec 16 2009
parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Thu, 17 Dec 2009 01:13:36 +0100, grauzone wrote:

 Andrei Alexandrescu wrote:
 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you try
 it and it works, push it til it breaks. If you have ideas on how to
 make semantic checking better, pipe up.
There's a guy on the NG who posts once in a while how broken shared is and how he has to use __gshared instead. His threads are being pretty much ignored. And now?
 Andrei
I'm certainly in that category. I will be trying (soon) to put a post together that sets out my issues with 'shared'.
Dec 16 2009
parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Thu, 17 Dec 2009 03:04:59 +0000, Graham St Jack wrote:

 On Thu, 17 Dec 2009 01:13:36 +0100, grauzone wrote:
 
 Andrei Alexandrescu wrote:
 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you try
 it and it works, push it til it breaks. If you have ideas on how to
 make semantic checking better, pipe up.
There's a guy on the NG who posts once in a while how broken shared is and how he has to use __gshared instead. His threads are being pretty much ignored. And now?
 Andrei
I'm certainly in that category. I will be trying (soon) to put a post together that sets out my issues with 'shared'.
Here is my attempt to set out my problems with the "shared" keyword as it now stands. First the good part: writing multi-threaded programs is not easy, and anything the language and compiler can do to make it easier is good. Now for the way I approach writing multi-threaded programs: Keep threads apart from each other wherever possible. Specifically, don't let them access or modify the same data except in well-understood and carefully controlled ways. My preferred way of doing this is for threads to share only a very small amount of data, all of which is mutex protected, and carefully designed to be safe to access by multiple threads. My favourite kind of these is a templated queue (like a "go" channel). Any data passed out from such a "shareable object" has to be either immutable or cloned, so that each thread can rely on its data not being trampled on by other threads. And my wish-list: What I would like is for D to provide a clean way for me to be able to say "this object and all its methods are nice and safe to access from multiple threads", and to also say "all instances of this type are immutable". And I also want the compiler to tell me if it thinks I have multiple threads accessing data in an unsafe way. Finally my issues with D as it stands: Immutable or const objects are a real pain because I can't have a mutable reference to them. Rebindable doesn't seem to work, and I haven't been able to make a version that works well enough. Immutable types don't add any value because you have to keep stating that objects of them are immutable everywhere. Having first-class immutable types would make it MUCH easier to reap the benefits of immutable data. I can't currently see a use for the shared keyword as it stands. It seems to me that what is needed is a keyword more like "shareable", meaning that this object (or data or function?) can be safely accessed by multiple threads. It should be an error to access a non-shareable object with multiple threads. It should also be an error to claim that something is shareable unless it meets some well thought out criteria that the compiler can check. I haven't thought these out yet, but some candidates I like the look of are: * All outputs from the object must be immutable or passed by value (cloned). * All externally accessible methods must be synchronized on the object's monitor. I'm happy that some sort of back-door override like __gshared has to be there for those cases that are actually ok, but only because of some grubby detail that the compiler can't figure out.
Dec 17 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-12-17 23:38:58 -0500, Graham St Jack 
<Graham.StJack internode.on.net> said:

 Immutable or const objects are a real pain because I can't have a mutable
 reference to them. Rebindable doesn't seem to work, and I haven't been
 able to make a version that works well enough.
In my observation, just like the most useful string type is defined as immutable(char)[] and thus is rebindable, most of the immutable objects I need also need to be rebindable. Rebindable being the most needed case, it means that I almost always need to write Rebindable!(immutable Object) for my immutable or const objects, which is a pain. I've been wondering yesterday if being rebindable shouldn't just be the default for objects. The rule would be that reference types are rebindable unless marked with final. So you would have: const(Object) o1; // rebindable const(final Object) o2; // not rebindable immutable(Object) o3; // rebindable immutable(final Object) o4; // not rebindable Final would have no effect on non-reference types (anything but classes and interfaces). I can see how it isn't necessarily coherent with the rest of the const system for value types, but reference types are different from value types too. In essence, I just want the most frequently used type (a rebindable object) to be easier to write than Rebindable!(immutable Object), so I'm open to other ideas too. As for a Rebindable that works, I've made one. Unfortunately, use of alias this is broken because of this bug <http://d.puremagic.com/issues/show_bug.cgi?id=3626>, so for now you need to always use the "get" parameter for comparing to null and other things that don't start with a dot. private template Rebindable(T) if (is(T == class) || isArray!(T)) { static if (!is(T X == const(U), U) && !is(T X == immutable(U), U)) { alias T Rebindable; } else static if (isArray!(T)) { alias const(ElementType!(T))[] Rebindable; } else { struct Rebindable { private U stripped; void opAssign(T another) { stripped = cast(U) another; } this(T value) { this = value; } T get() const { return cast(T)stripped; } T opDot() const { return get; } } } } -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 18 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you try
 it and it works, push it til it breaks. If you have ideas on how to make
 semantic checking better, pipe up.
 Andrei
I think for this to happen, there needs to be a tutorial somewhere explaining what shared is supposed to do (there were so many ideas thrown around that I don't remember them all and don't know which ones got adopted), and how much of it is already implemented.
Dec 16 2009
parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Thu, 17 Dec 2009 00:51:48 +0000, dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you try
 it and it works, push it til it breaks. If you have ideas on how to
 make semantic checking better, pipe up.
 Andrei
I think for this to happen, there needs to be a tutorial somewhere explaining what shared is supposed to do (there were so many ideas thrown around that I don't remember them all and don't know which ones got adopted), and how much of it is already implemented.
I agree. The whole thing is very confused right now, and certainly everything I try in my code doesn't work out. The only way I can use threads tight now is to avoid use of shared at all. If anyone knows how it is supposed to work now, please write out a description.
Dec 16 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 
 But let's not forget we have concurrency ahead of us. I encourage you 
 all to chime in with your thoughts and ideas regarding all aspects of 
 concurrency. The recent multicore performance bug is a great starting 
 point. If you try e.g. shared and it's broken, let us know. If you try 
 it and it works, push it til it breaks. If you have ideas on how to make 
 semantic checking better, pipe up.
I posted several shared issues to the NG a few days ago and got no replies. Most of it was about poor error messages (both misleading text and missing file/line numbers). I should do proper bugzilla entries but haven't tinkered with D much since. As always, this post comes from my phone instead of a proper computer, or else I'd provide a link or do the bugzilla entries while I'm thinking of it. IIRC, the most troublesome error happened when I created "shared this(){...}" constructor and no information on where it caused errors.
 
 Andrei
Dec 16 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 But let's not forget we have concurrency ahead of us. I encourage you 
 all to chime in with your thoughts and ideas regarding all aspects of 
 concurrency. The recent multicore performance bug is a great starting 
 point. If you try e.g. shared and it's broken, let us know. If you try 
 it and it works, push it til it breaks. If you have ideas on how to make 
 semantic checking better, pipe up.
I posted several shared issues to the NG a few days ago and got no replies. Most of it was about poor error messages (both misleading text and missing file/line numbers). I should do proper bugzilla entries but haven't tinkered with D much since. As always, this post comes from my phone instead of a proper computer, or else I'd provide a link or do the bugzilla entries while I'm thinking of it. IIRC, the most troublesome error happened when I created "shared this(){...}" constructor and no information on where it caused errors.
Thanks, Jason. I did see those messages but I didn't want to dilute focus back when you posted them. If you could put together bugzilla entries as you try things, that would be great. The shared constructor I'll experiment with first. Andrei
Dec 16 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you try
 it and it works, push it til it breaks. If you have ideas on how to make
 semantic checking better, pipe up.
I posted several shared issues to the NG a few days ago and got no replies. Most of it was about poor error messages (both misleading text and missing file/line numbers). I should do proper bugzilla entries but haven't tinkered with D much since. As always, this post comes from my phone instead of a proper computer, or else I'd provide a link or do the bugzilla entries while I'm thinking of it. IIRC, the most troublesome error happened when I created "shared this(){...}" constructor and no information on where it caused errors.
Thanks, Jason. I did see those messages but I didn't want to dilute focus back when you posted them. If you could put together bugzilla entries as you try things, that would be great. The shared constructor I'll experiment with first.
I have reproduced and reported most of the issue I had hit with shared. If it's any consolation, I was able to convert my message passing queues to use shared, but hit issues when expanding to cover other uses of shared data within my code base. There may also be an issue with what a shared delegate is supposed to be and what can be inside of one, but I haven't really worried about that too much. It's a hairy issue and partly my fault for using delegates as messages between threads. When sending a message, I cast the delegate to a shared delegate even though it access immutable data and has no side effect except on thread-local data in the receiving thread. bugzilla 3640 shared this() constructor does not work and reports strange errors without line numbers bugzilla 3641 keywords: rejects-valid alias shared T U does not work bugzilla 3642 keywords: diagnostic Poor error message when using shared: function ___ not callable with argument types ___
Dec 23 2009
next sibling parent Jason House <jason.james.house gmail.com> writes:
Jason House wrote:

 bugzilla 3640
      shared this() constructor does not work and reports strange errors
      without line numbers
 
 bugzilla 3641 keywords: rejects-valid
     alias shared T U does not work
 
 bugzilla 3642 keywords: diagnostic
     Poor error message when using shared:
     function ___ not callable with argument types ___
I'll add to that list: bugzilla 3091 keywords: rejects-valid "auto x = new shared foo" does not compile
Dec 23 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu wrote:
 
 Jason House wrote:
 Andrei Alexandrescu Wrote:

 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you try
 it and it works, push it til it breaks. If you have ideas on how to make
 semantic checking better, pipe up.
I posted several shared issues to the NG a few days ago and got no replies. Most of it was about poor error messages (both misleading text and missing file/line numbers). I should do proper bugzilla entries but haven't tinkered with D much since. As always, this post comes from my phone instead of a proper computer, or else I'd provide a link or do the bugzilla entries while I'm thinking of it. IIRC, the most troublesome error happened when I created "shared this(){...}" constructor and no information on where it caused errors.
Thanks, Jason. I did see those messages but I didn't want to dilute focus back when you posted them. If you could put together bugzilla entries as you try things, that would be great. The shared constructor I'll experiment with first.
I have reproduced and reported most of the issue I had hit with shared. If it's any consolation, I was able to convert my message passing queues to use shared, but hit issues when expanding to cover other uses of shared data within my code base. There may also be an issue with what a shared delegate is supposed to be and what can be inside of one, but I haven't really worried about that too much. It's a hairy issue and partly my fault for using delegates as messages between threads. When sending a message, I cast the delegate to a shared delegate even though it access immutable data and has no side effect except on thread-local data in the receiving thread. bugzilla 3640 shared this() constructor does not work and reports strange errors without line numbers bugzilla 3641 keywords: rejects-valid alias shared T U does not work bugzilla 3642 keywords: diagnostic Poor error message when using shared: function ___ not callable with argument types ___
Great. I just got word from Walter that he fixed a lot of shared bugs (most reported and some probably not yet reported), so I expect the situation to get considerably better with the next minor release. Andrei
Dec 23 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 24 Dec 2009 08:13:53 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Jason House wrote:
 Andrei Alexandrescu wrote:

 Jason House wrote:
 Andrei Alexandrescu Wrote:

 But let's not forget we have concurrency ahead of us. I encourage you
 all to chime in with your thoughts and ideas regarding all aspects of
 concurrency. The recent multicore performance bug is a great starting
 point. If you try e.g. shared and it's broken, let us know. If you  
 try
 it and it works, push it til it breaks. If you have ideas on how to  
 make
 semantic checking better, pipe up.
I posted several shared issues to the NG a few days ago and got no replies. Most of it was about poor error messages (both misleading text and missing file/line numbers). I should do proper bugzilla entries but haven't tinkered with D much since. As always, this post comes from my phone instead of a proper computer, or else I'd provide a link or do the bugzilla entries while I'm thinking of it. IIRC, the most troublesome error happened when I created "shared this(){...}" constructor and no information on where it caused errors.
Thanks, Jason. I did see those messages but I didn't want to dilute focus back when you posted them. If you could put together bugzilla entries as you try things, that would be great. The shared constructor I'll experiment with first.
I have reproduced and reported most of the issue I had hit with shared. If it's any consolation, I was able to convert my message passing queues to use shared, but hit issues when expanding to cover other uses of shared data within my code base. There may also be an issue with what a shared delegate is supposed to be and what can be inside of one, but I haven't really worried about that too much. It's a hairy issue and partly my fault for using delegates as messages between threads. When sending a message, I cast the delegate to a shared delegate even though it access immutable data and has no side effect except on thread-local data in the receiving thread. bugzilla 3640 shared this() constructor does not work and reports strange errors without line numbers bugzilla 3641 keywords: rejects-valid alias shared T U does not work bugzilla 3642 keywords: diagnostic Poor error message when using shared: function ___ not callable with argument types ___
Great. I just got word from Walter that he fixed a lot of shared bugs (most reported and some probably not yet reported), so I expect the situation to get considerably better with the next minor release. Andrei
I'll add my experience with shared/local separation. Shared/local as it is now relies solely on convention. For example, I have wrote a large heavily-multithreaded application in D2 without any use of shared (i.e. everything is "local", yet pointers are freely passed among threads). This is because stdlib is not shared aware at all, starting with druntime: thread creation is "broken" in a sense that it allows passing local this pointer through delegate to another thread: class Foo { void bar() { /* do stuff */ } void createNewThread() { auto thread = new Thread(&bar); // local this pointer is bound to delegate thread.start(); // "this" is now accessible from 2 different threads (current one, and a new one) } } A simple fix would be to disallow starting a new thread with a delegate, allowing free function pointers only. Other options would be to introduce "shared delegates" - a delegate that has shared context pointer. I'd suggest starting with fixing signatures of those OS API functions that deal with creating new thread. For example, there are _beginthreadex (Windows) and pthread_create (POSIX) functions that are declared in druntime roughly like this: extern (C) uintptr_t _beginthreadex(void* /+security,+/, uint /+stack_size+/, uint function(void*) /+start_routine+/, void* /+arg+/, uint /+initflag+/, uint* /+thrdaddr+/); // added variable names to make it more clear int pthread_create(pthread_t* /+thread+/, in pthread_attr_t* /+attr+/, void* function(void*) /+start_routine+/, void* /+arg+/); (there are a lot more functions like this, of course) Variable arg is passed from one thread to another, and thus *must* be marked as shared (or unique). The same applies to start_routine (should be "void function(shared void*) start_routine" instead). This will break a lot of code but will at least try to enforce program correctness.
Dec 24 2009
parent Jason House <jason.james.house gmail.com> writes:
Denis Koroskin wrote:

 I'll add my experience with shared/local separation.
 
 Shared/local as it is now relies solely on convention. For example, I have
 wrote a large heavily-multithreaded application in D2 without any use of
 shared (i.e. everything is "local", yet pointers are freely passed among
 threads).
That was my first experience with shared as well. I submitted a ticket [1] to druntime for it over 7 months ago. I'm not sure what the current status of the threading rewrite is. I know Bartosz worked on it until he hit a nasty bug which Don later fixed. [1] http://www.dsource.org/projects/druntime/ticket/23
Dec 24 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu wrote:

 Jason House wrote:
 bugzilla 3640
      shared this() constructor does not work and reports strange errors
      without line numbers
 
 bugzilla 3641 keywords: rejects-valid
     alias shared T U does not work
 
 bugzilla 3642 keywords: diagnostic
     Poor error message when using shared:
     function ___ not callable with argument types ___
 
Great. I just got word from Walter that he fixed a lot of shared bugs (most reported and some probably not yet reported), so I expect the situation to get considerably better with the next minor release. Andrei
The commit logs show that bugzilla 3641 was fixed. I'd appreciate it if someone could translate what other shared coding constructs were fixed by Walter's changes. Even a partial fix to 3640 to include line numbers would probably help people. My grep results below show where the message is being generated. I see there's a variant of error that accepts a location parameter, but this error doesn't use it. What surprises me is that it looks like nearly every call to error lacks a location parameter. I'm confused why this would be. I don't normally notice a lack of line numbers in most error messages I see from dmd. /usr/local/src/dmd/cast.c:104: error("cannot implicitly convert expression (%s) of type %s to %s", Maybe the biggest help for those converting to shared would be inclusion of why a particular variable is shared and causing the error. Shared can be viral, and exactly how a piece of code is getting called in shared context can occasionally be a bit unclear. I think there was a related patch for inclusion of stack traces with templated code?
Dec 24 2009
parent reply Don <nospam nospam.com> writes:
Jason House wrote:
 Maybe the biggest help for those converting to shared would be inclusion of 
 why a particular variable is shared and causing the error.  Shared can be 
 viral, and exactly how a piece of code is getting called in shared context 
 can occasionally be a bit unclear.  I think there was a related patch for 
 inclusion of stack traces with templated code?
The stack trace patch is in.
Dec 25 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Don wrote:

 Jason House wrote:
 Maybe the biggest help for those converting to shared would be inclusion
 of
 why a particular variable is shared and causing the error.  Shared can be
 viral, and exactly how a piece of code is getting called in shared
 context
 can occasionally be a bit unclear.  I think there was a related patch for
 inclusion of stack traces with templated code?
The stack trace patch is in.
Maybe I'm mistaken, but I thought the stack traces only applied to templated code? Is that not correct?
Dec 28 2009
parent Don <nospam nospam.com> writes:
Jason House wrote:
 Don wrote:
 
 Jason House wrote:
 Maybe the biggest help for those converting to shared would be inclusion
 of
 why a particular variable is shared and causing the error.  Shared can be
 viral, and exactly how a piece of code is getting called in shared
 context
 can occasionally be a bit unclear.  I think there was a related patch for
 inclusion of stack traces with templated code?
The stack trace patch is in.
Maybe I'm mistaken, but I thought the stack traces only applied to templated code? Is that not correct?
Yes.
Dec 28 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

I've sent you an email, late.

Bye,
bearophile
Dec 30 2009