December 03, 2017
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
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
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
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
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
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;
4 5 6 7 8 9 10 11 12 13 14
Next ›   Last »