December 03, 2017 Re: Thoughts about D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael V. Franklin | On 12/3/2017 4:25 PM, Michael V. Franklin wrote:
> It would be great for the compiler devs to run through this exercise themselves and make changes to the compiler/runtime interface to remove the irrelevant requirements the compiler is imposing.
I don't agree that creating a stub druntime is better, for reasons mentioned before.
As for changing the way the compiler generates code so it is more pay-only-for-what-you-use, I'm all for it. I mentioned already work being done in this direction, PRs for more are welcome.
|
December 03, 2017 Re: Thoughts about D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael V. Franklin | On 12/3/2017 5:01 PM, Michael V. Franklin wrote: > Would it help for me to file bugzilla issues for things like this? No, because "why does the compiler do xxx" isn't really a bug report. You could ask on the learn n.g., or use obj2asm to examine the generated code. You can also grep the druntime source for what _d_dso_registry does. > The reason I haven't thus far, is that this is just a symptom of a larger issue. It needs a development strategy to be solved holistically. Having a new process isn't going to do much, because at some point someone has to put in work. It's the doing work that produces results. |
December 03, 2017 Re: Thoughts about D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Michael V. Franklin | On 12/3/2017 5:12 PM, Michael V. Franklin wrote:
> Ok, well perhaps that makes sense compiling with -fPIC, but the "relocation R_X86_64_32 against `.rodata.str1.1'" seems unnecessary.
Why certain relocations are there is not at all a simple subject. And changing them tends to produce all sorts of frustrating bugs :-(
|
December 03, 2017 Re: Thoughts about D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | On 12/3/17 00:09, Dmitry Olshansky wrote: > On Saturday, 2 December 2017 at 23:44:39 UTC, Walter Bright wrote: >> On 12/2/2017 4:38 AM, Iain Buclaw wrote: >>> But then you need to bloat your program with debug info in order to >>> understand what, why, and how things went wrong. >> >> Most of the time (for me) that isn't necessary, because the debugger >> still shows where it failed and that's enough. >> >> Besides, you can always rerun the test case with a debug build. > > Ehm, if it’s a simple reproducable tool. > Good luck debugging servers like that. > > I have to agree with this. I make my living on server side software, and we aren't allowed (by legal) to connect to the server to run debuggers. The *only* thing I have is logging. If the program crashes with no option to trap an exception or otherwise log the crash this could cost me weeks-to-months of debugging time. -- Adam Wilson IRC: LightBender import quiet.dlang.dev; |
December 03, 2017 Re: Thoughts about D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam Wilson | On 12/3/2017 8:59 PM, Adam Wilson wrote:
> I have to agree with this. I make my living on server side software, and we aren't allowed (by legal) to connect to the server to run debuggers. The *only* thing I have is logging. If the program crashes with no option to trap an exception or otherwise log the crash this could cost me weeks-to-months of debugging time.
As I said, the halt behavior will be an option. Nobody is taking away anything.
|
December 03, 2017 Re: Thoughts about D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 12/3/17 21:28, Walter Bright wrote: > On 12/3/2017 8:59 PM, Adam Wilson wrote: >> I have to agree with this. I make my living on server side software, >> and we aren't allowed (by legal) to connect to the server to run >> debuggers. The *only* thing I have is logging. If the program crashes >> with no option to trap an exception or otherwise log the crash this >> could cost me weeks-to-months of debugging time. > > As I said, the halt behavior will be an option. Nobody is taking away > anything. Awesome. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev; |
Copyright © 1999-2021 by the D Language Foundation