Re: DLL symbol identity
On Wednesday, 13 May 2015 at 07:49:26 UTC, Benjamin Thaut wrote: On Wednesday, 13 May 2015 at 07:41:27 UTC, Logan Capaldo wrote: If my program only links against DLLs written in D, sure this is no worse than the static library/version flag situation. But one of D's features is C and C++ interop. For instance if I link against a DLL that happens to provide COM objects am I going to start getting weird behaviors because all the DllGetClassObjects are 'unified' and we just pick one? Well this unification will only happen for D libraries. Its not going to do that for non D shared libraries (e.g. written in C or C++). And for shared libraries written in a mix of D and C++ or C, or shared libraries written in D but that expose extern (C) or extern (C++) symbols? Yes it won't happen for explicit LoadLibrary's and GetProcAddresses, but COM or other plugin systems is an example of a situation where many DLLs may expose the same named symbols with different definitions, and there may be situations where people link to those DLLs directly to get other things they provide.
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 11:41:27 UTC, Benjamin Thaut wrote: On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote: Yes it won't happen for explicit LoadLibrary's and GetProcAddresses, but COM or other plugin systems is an example of a situation where many DLLs may expose the same named symbols with different definitions, and there may be situations where people link to those DLLs directly to get other things they provide. Once again, I'm going to patch the import table. The import table gets only generated for symbosl which are _imported_ by a import library. This only happens for things that get imported by D libraries / executables. Linking against multiple dlls via a import library which export the same symbol doesn't work no matter if I do the patching or not. So nothing changes in that regard. Your COM Dlls are not going to break even if each COM dll exports the same symbol. Because these COM specific symbols will not be imported by a D library via a import library, so nothing changes. The problems you think exist do not exist because I only patch the importing table and not the dlls that export the symbols. Even if you mix D with C++ you are not going to have that problem, because you can't link against multiple libraries with the same symbol with C++ either. a.dll provides symbol s1 b.dll provides symbol s1 c.dll imports symbol s1 from a.dll, provides symbol s2 d.dll imports symbol s1 from b.dll, provides symbol s3 e.exe imports symbol s2 from c.dll, imports symbol s3 from d.dll. e.exe only needs the import libs from c.dll and d.dll. You're patching the import tables at runtime correct?. If you patch c and d's import tables their s1 import is going to end up pointing at the same symbol. I can build a.dll and c.dll completely independently of d.dll and b.dll. There's no opportunity to prevent this at compile time. Likewise e.exe doesn't know or care s1 exists so it builds fine as well. You don't need a.lib or b.lib to build e.exe.
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 13:31:15 UTC, Benjamin Thaut wrote: On Wednesday, 13 May 2015 at 12:57:35 UTC, Logan Capaldo wrote: a.dll provides symbol s1 b.dll provides symbol s1 c.dll imports symbol s1 from a.dll, provides symbol s2 d.dll imports symbol s1 from b.dll, provides symbol s3 e.exe imports symbol s2 from c.dll, imports symbol s3 from d.dll. e.exe only needs the import libs from c.dll and d.dll. You're patching the import tables at runtime correct?. If you patch c and d's import tables their s1 import is going to end up pointing at the same symbol. I can build a.dll and c.dll completely independently of d.dll and b.dll. There's no opportunity to prevent this at compile time. Likewise e.exe doesn't know or care s1 exists so it builds fine as well. You don't need a.lib or b.lib to build e.exe. Yes, but exactly the same behavior is currently in place on linux. Also your example is quite a corner case, the usual use case where you wan't symbols of multiple instances of the same template to be merged is more common. Imagine a is msvcr90.dll and b is msvcr100.dll. Or a is msvcrt.dll. Or a is mfc100u.dll and b is mfc110u.dll. This happens all the time, and all we need is for c and d to have a little bit of D in them. Linux (thankfully) doesn't typically have N versions of libc floating around. I _think_ if you only do this for D-mangled symbols you'll get 99% of the benefits (doing the right things for templates etc.) without causing problems for the corner cases.
Re: DLL symbol identity
On Wednesday, 13 May 2015 at 06:17:36 UTC, Benjamin Thaut wrote: On Tuesday, 12 May 2015 at 17:48:50 UTC, Logan Capaldo wrote: q could be a completely different type in a.dll vs. c.dll. Please correct me if I am wrong, but my understanding of how import libs get used you can't detect this at build time and disallow it. Linking d.exe we have no reason to look at a.lib and notice the conflict, and even if we did there's no type information to go off of anyway and you could assume that they were the same. No q can not be a different type in a.dll vs c.dll Because of the mangling of the type it would be called a.q once and c.q so no conflict would arise. Not if q is extern C or extern C++. Is your intent to only apply this unification to extern (D) symbols? Why not? I can't think of anything special about extern (D) declarations. Just as a reminder, linux already does this for _all_ symbols. And it doesn't cause any issues there. The thing that is special about extern (D) symbols is that the module mangling sidesteps my 'q' example. It does cause issues on Linux actually. I've seen it multiple times, usually when first party code and third party both unbeknownst to each other both embed different versions of a popular source only library. If my program only links against DLLs written in D, sure this is no worse than the static library/version flag situation. But one of D's features is C and C++ interop. For instance if I link against a DLL that happens to provide COM objects am I going to start getting weird behaviors because all the DllGetClassObjects are 'unified' and we just pick one?
Re: DLL symbol identity
On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote: I personally would prefer option 2 because it would be easier to use and wouldn't cause lots of additional maintenance effort. Any opinions on this? As both options would be quite some work I don't wan't to start blindly with one and risking it being rejected later in the PR. Kind Regards Benjamin Thaut (2) would be nice but how would a.dll provides a.dll!q b.dll links against a.dll, provides b.dll!w c.dll provides c.dll!q d.exe links against b.dll (b.lib) and c.dll (c.lib). work? q could be a completely different type in a.dll vs. c.dll. Please correct me if I am wrong, but my understanding of how import libs get used you can't detect this at build time and disallow it. Linking d.exe we have no reason to look at a.lib and notice the conflict, and even if we did there's no type information to go off of anyway and you could assume that they were the same. Is your intent to only apply this unification to extern (D) symbols?
Re: How does laziness and UFCS interact?
On Monday, 9 March 2015 at 22:15:43 UTC, Ali Çehreli wrote: You are right. I had the same observation at minute 11:27 below, where I warn against UFCS with assumeWontThrow: http://www.youtube.com/watch?feature=player_detailpagev=oF8K4-bieaw#t=687 Ali Sorry, which is right? I know ifThrown is lazy, I'm curious about the amount of the expression that is evaluated lazily. a.b().c().assumeWontThrow vs. a.b().c().assumeWontThrow ^--+^^-^ | | +- lazy? +- lazy? The video seems to say don't use lazy functions with UFCS because you might think the lazy part gets evaluated first, when it does not. Seems reasonable, although I don't know it's any different than assumeWontThrow(f()).
How does laziness and UFCS interact?
I just became aware of
http://dlang.org/phobos/std_exception.html#.ifThrown . It's neat,
but it seems non-obvious to me how lazy + UFCS should work in
general.
consider
void lazily(T)(lazy T expression)
{
expression();
}
It's clear when saying lazily(a.b().c()); that the whole of
a.b().c() is going to be evaluated lazily. With UFCS though,
I'm more unsure:
is a.b().c().lazily() - lazily(a.b().c()) or is it more akin to
auto tmp = a.b();
lazily(tmp.c());
If the later is it possible to force the former while still using
UFCS, ie is (a.b().c()).lazily() different than
a.b().c().lazily()?
Re: Would you trade 0.1% in performance for a better debugging experience?
On Monday, 17 November 2014 at 23:14:32 UTC, Vladimir Panteleev wrote: I proposed to build Phobos and Druntime with stack frames enabled: This is very much worth it in my opinion. Not just for debugging but being able to profile (sometimes in production, without needing to recompile with instrumentation or debug symbols), can definitely make up for the difference in the long run. Fast, easy stack trace taking has a lot of utility, and can be applied where loading symbols to do the same makes it too slow to consider. Stack traces taken like this can be taken quickly, and symbolized later at your leisure offline.
Re: extern(C) in druntime
On Monday, 10 November 2014 at 19:44:05 UTC, Dicebot wrote: On Monday, 10 November 2014 at 17:48:04 UTC, Sean Kelly wrote: On Monday, 10 November 2014 at 16:59:47 UTC, Dicebot wrote: Right now question is, however, are there any legitimate uses of `extern(C)` in druntime or those all can be replaced with `pragma(mangle, XXX) extern(D)`? I don't think there's any reason to use extern (C) in druntime any more. I guess that nails it, will make a PR What about things that are meant to be called from C? E.g. `rt_init`/`rt_term`?
Re: extern(C) in druntime
On Monday, 10 November 2014 at 23:02:54 UTC, Steven Schveighoffer wrote: On 11/10/14 5:15 PM, Logan Capaldo wrote: On Monday, 10 November 2014 at 19:44:05 UTC, Dicebot wrote: On Monday, 10 November 2014 at 17:48:04 UTC, Sean Kelly wrote: On Monday, 10 November 2014 at 16:59:47 UTC, Dicebot wrote: Right now question is, however, are there any legitimate uses of `extern(C)` in druntime or those all can be replaced with `pragma(mangle, XXX) extern(D)`? [snip] What about things that are meant to be called from C? E.g. `rt_init`/`rt_term`? Those should remain extern(C). Of course, those have no D only features, so they can easily remain extern(C) :) So just to be clear, there are _some_ legitimate uses of extern (C) in druntime, yes? rt_init/rt_term, rt_loadLibrary, thread_init(? think this one can be bootstrapped from D code), ...?
Re: DConf 2014: SDC, a D Compiler as a Library
On Wednesday, 23 July 2014 at 16:07:44 UTC, Andrei Alexandrescu wrote: Last (but not least!) talk of DConf 2014. https://twitter.com/D_Programming/status/491977150694961152 https://www.facebook.com/dlang.org/posts/889844197695929 http://www.reddit.com/r/programming/comments/2bi79s/sdc_a_d_compiler_as_a_library/ Andrei As regards the cleanup support with respect to C++ exceptions, does that also work with e.g. pthread_cancel (on the same platform(s) where C++ dtors run in response to pthread_cancel anyway)? I assume the answer is yes, of course, but figured I would double check.
Re: Patching druntime to use different signals beside SIGUSR1/SIGUSR2?
On Thursday, 10 July 2014 at 20:20:41 UTC, Sean Kelly wrote: Not currently. Mostly because you're the first person to run into this issue (or at least to ask about it, as far as I can recall). Using signals for collection at all is a real sore point for me--I think it's a terrible but necessary hack--so any improvements that can be made regarding this are welcome. I opened a pull request, https://github.com/D-Programming-Language/druntime/pull/888. I am eager for any feedback. I ended up not having a thread_init2 sort of function as typically in this cases thread_init is going to be called indirectly via rt_init, and I didn't want to introduce several layers of 2 functions to pass the parameters all the way down. If it is thought that is a better approach after all I am of course open to maing those changes. Thanks.
Patching druntime to use different signals beside SIGUSR1/SIGUSR2?
Apologies in advance if this belongs on the druntime forum, but it seemed to be full of exclusively automated posts? I'm looking to integrate D into an existing code base. So far so good, but I'm concerned that the relatively rare but non-zero use of SIGUSR1/SIGUSR2 in the code base will, due to murphy's law bound to trip something up and put people in a position of having a confusing and difficult to debug issue. Fortunately we _do_ have a centralized allocator for Posix realtime signals. I was thinking of adding a int rt_init2(int suspendsigno, int resumesigno) function (not looking to bikeshed on the name/arguments at the moment, if people find this reasonable/useful I will happily have that discussion) as an alternative to rt_init(). My questions are basically: 1) I can't think of any reason something would break by making this configurable, but I could be mistaken. is there? 2) Is rt_init() the right sort of function, or should it be at thread_init time? 3) Is there an existing effort in this direction? I tired searching around, but mostly just found evidence that yes, druntime uses sigusr1/sigusr2 as part of the gc implementation on !(windows, osx). Thanks, -Logan
