Re: LDC 0.15.0 alpha1 released! Please help test!
https://aur.archlinux.org/pkgbase/ldc-alpha updated
Re: D2 port of Sociomantic CDGC available for early experiments
On Tuesday, 7 October 2014 at 20:06:43 UTC, Walter Bright wrote: On 10/6/2014 9:51 AM, Dicebot wrote: https://github.com/D-Programming-Language/druntime/pull/985 Thank you. This is great progress! I understand the caveats, but can this be put into a shape where it can be pulled despite being a work in progress? I.e. have the code be disabled by default? That will help encourage the community to help out with the gaps. BTW, why not dub package? GC is pluggable, so can be shipped as a 3rd-party library.
Re: D2 port of Sociomantic CDGC available for early experiments
On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: I've come to even hate anything GUI (except maybe the editor), I'd hate to even think about browsing the file system with a mouse anymore. Yes, you can: Windows Explorer does support keyboard input :)
Re: D2 port of Sociomantic CDGC available for early experiments
On Thu, 23 Oct 2014 07:12:25 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Friday, 17 October 2014 at 17:53:18 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: I've come to even hate anything GUI (except maybe the editor), I'd hate to even think about browsing the file system with a mouse anymore. Yes, you can: Windows Explorer does support keyboard input :) at least it supports most useful shortcut: alt+f4. signature.asc Description: PGP signature
Re: Endovena: a dependency injection framework.
Unity uses UnityContainer. So there can be a discriminator in the name.
Re: Endovena: a dependency injection framework.
Eeek please don't rename, people that find names confusing can use `import endovena = o3o.endovena;` or something like that. Keep names concise, although there are a lot of C++ devs in the D community so perhaps you could just call it Contnr :D we all know how c++ guys like their shortened names for no reason. On Thu, Oct 23, 2014 at 9:17 AM, Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Unity uses UnityContainer. So there can be a discriminator in the name.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 07:09:04 UTC, Kagamin wrote: On Tuesday, 7 October 2014 at 20:06:43 UTC, Walter Bright wrote: On 10/6/2014 9:51 AM, Dicebot wrote: https://github.com/D-Programming-Language/druntime/pull/985 Thank you. This is great progress! I understand the caveats, but can this be put into a shape where it can be pulled despite being a work in progress? I.e. have the code be disabled by default? That will help encourage the community to help out with the gaps. BTW, why not dub package? GC is pluggable, so can be shipped as a 3rd-party library. Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do).
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote: Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do). The idea is that you specify CDGC dub package a dependency for your application and dub links your application with it, so you end up with CDGC in your application.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 09:53:44 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 08:46:46 UTC, Dicebot wrote: Currently druntime is packaged as part of Phobos library binary so I don't see easy way to do it. It could be possible to do the replacement at the startup using GC Proxy instrastructure but CDGC does not currently support it (though it is not complicated to do). The idea is that you specify CDGC dub package a dependency for your application and dub links your application with it, so you end up with CDGC in your application. Uh, what will it link to? extern(C) function like gc_malloc? druntime links to those statically itself so you will get application that links to different GC than druntime itself. Or am I misunderstanding what you propose?
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote: Uh, what will it link to? extern(C) function like gc_malloc? druntime links to those statically itself so you will get application that links to different GC than druntime itself. The reason is CDGC provides symbols like gc_malloc and after that the linker has no reason to pull default GC from the library: it doesn't pull what's not necessary.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 11:03:35 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 09:57:38 UTC, Dicebot wrote: Uh, what will it link to? extern(C) function like gc_malloc? druntime links to those statically itself so you will get application that links to different GC than druntime itself. The reason is CDGC provides symbols like gc_malloc and after that the linker has no reason to pull default GC from the library: it doesn't pull what's not necessary. It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. Now, if druntime defines gc_alloc, it won't link. You have to extract all conflicting symbols out of druntime. However, one could provide a full druntime patched with CDGC as a dub module, and that might work, I suppose.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote: It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. At best, they won't clash :) If the default GC is not pulled by the linker, why should they clash? Now, if druntime defines gc_alloc, it won't link. You have to extract all conflicting symbols out of druntime. Do you consider possibility of breaking changes as a blocker for feasibility of 3rd-party libraries?
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 22 de October a las 10:41 me escribiste: NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly. Which is my point. This is a super common mechanism. I never ever had problems with this. Did you? Did honestly you even know they existed? Yes. But this is beside the point, which I hope I have clarified now? No. My conclusion is we don't agree mainly on this: I think there are cases where you want runtime configuration to propagate or be set more or less globally. You think no one will ever want some runtime option to propagate. The rest of the argument is based on that difference. Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Runtime configuration will be most of the time some to be done either by the developer (in which case it would be nicer to have a programatic way to configure it), or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Usually runtime options will be completely meaningless for a regular user. Also, will you document them when you use --help? Will you omit them? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- De tan fina la condesa, por no cagarse, reza. -- Ricardo Vaporeso
Re: D2 port of Sociomantic CDGC available for early experiments
On Thursday, 23 October 2014 at 14:02:33 UTC, Kagamin wrote: On Thursday, 23 October 2014 at 13:13:06 UTC, Mathias LANG wrote: It will clash at best, or just ignore cdgc, as objects are considered as a whole, in link order. At best, they won't clash :) If the default GC is not pulled by the linker, why should they clash? We could experiment with separately linking the GC. It wouldn't be hard to do, though the link line might be a bit weird, since core, rt, and gc are all interdependent in terms of link dependencies.
Re: D2 port of Sociomantic CDGC available for early experiments
On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Regan Heath, el 22 de October a las 10:41 me escribiste: NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly. Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these. The same is not true of many potential D GC/allocation/debug flags, we do not necessarily want them to propagate at all and in fact we may want to target a single exe in a process tree i.e. parent - not this child1 - this one child2 - not this My conclusion is we don't agree mainly on this: I think there are cases where you want runtime configuration to propagate or be set more or less globally. I agree that there are cases we might want it to propagate *from a parent exe downwards* or similar but this is not what I would call more or less globally it's very much less than globally. The scope we want is going to be either a single exe, or that exe and some or all of it's children and possibly only for a single execution. Sure, you *could* wrap a single execution in it's own session and only set the envvar within that session but it's far simpler just to pass a command line arg. Likewise, you could set an envvar in a session and run multiple executions within that session, but again it's simpler just to pass an arg each time. Basically, I don't see what positive benefit you get from an envvar over a command line switch, especially if you assume/agree that the most sensible default these switches is 'off' and that they should be enabled specifically. I think what we disagree about here is the scope it should apply and whether propagation should be the default behaviour. You think no one will ever want some runtime option to propagate. Nope, I never said that. Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Surely not, unix is the king of command line switches. Runtime configuration will be most of the time some to be done either by the developer (in which case it would be nicer to have a programatic way to configure it) Agreed. or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Disagree. It's not something we ever want at a system level, it's somewhere within the range of a single session - single execution. Usually runtime options will be completely meaningless for a regular user. Also, will you document them when you use --help? Or course not, just as you would not document the envvar(s). R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D2 port of Sociomantic CDGC available for early experiments
Regan Heath, el 23 de October a las 17:24 me escribiste: On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella l...@llucax.com.ar wrote: Regan Heath, el 22 de October a las 10:41 me escribiste: NO, this is completely false, and why I think you are not entirely familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects ALL, EACH and EVERY program for example. D or not D. Every single dynamically linked program. True. And the reason these behave this way is because we *always* want them to - the same is NOT true of the proposed vars for D. No, not at all, you very rarely want to change LD_PRELOAD and LD_LIBRARY_PATH globaly. Sure, but when you do change them you will want them to propagate, by default, which is why envvars are used for these. No, not at all, specially with LD_PRELOAD, I think you almost never want to propagate it. I think LD_PRELOAD is the closest example to what one would want to do with runtime options (and some of the stuff, like replacing the GC, could be done using LD_PRELOAD, actually, but you have to replace it all, you have much less fine grained control, is major surgery). Also, I don't have much of a problem with having command-line options to configure the runtime too, although I think in linux/unix is much less natural. Surely not, unix is the king of command line switches. Is not about quantity, is about separation of concerns. Historically in Linux a program only manages the switches it really knows, is not common to hijack programs arguments in Linux (even when is done by some applications, like GTK+, but is all under your control, you explicitly pass the command-line arguments to the library, so it's quite a different case). Anything that you don't control in your program, is handled by environment variables. or on a system level, by a system administrator / devops (in which case for me environment variables are superior for me). Disagree. It's not something we ever want at a system level, it's somewhere within the range of a single session - single execution. Why? On a single core I want ALL my applications by default NOT to use the concurrent GC, as it will make things slower, while on a multi-core I want to use the concurrent GC by default. You have an use case right there. If I have tons of memory, I would want to have all my programs preallocate 100MiB to speed up things. There might be more in the future, who knows... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- Parece McGuevara's o CheDonald's
