March 05, 2012
On Mon, Mar 05, 2012 at 06:12:43PM +0100, Andrej Mitrovic wrote: [...]
> Also, I find your message signatures amusing. :P

I have a file of amusing quotes that I collected over the years from various sources (including some not-so-funny ones I made up myself), and a 1-line perl script hooked to my Mutt compose function that randomly selects a quote and puts it on my signature line.  Once in a while it can coincidentally pick a quote relevant to the actual discussion in the message body, which makes it even funnier.


T

-- 
Laissez-faire is a French term commonly interpreted by Conservatives to mean 'lazy fairy,' which is the belief that if governments are lazy enough, the Good Fairy will come down from heaven and do all their work for them.
March 05, 2012
"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jj252v$15vf$1@digitalmars.com...
> On 3/4/2012 11:50 PM, Chad J wrote:
>> Problems:
>> - I have to rerun the program in a debugger to see the stack trace. This
>> is a
>> slow workflow. It's a big improvement if the segfault is hard to find,
>> but only
>> a small improvement if the segfault is easy to find. Very bad if I'm
>> prototyping
>> experimental code and I have a bunch to go through.
>
> I don't get this at all. I find it trivial to run the program with a debugger:
>
>   gdb foo
>   >run
>
> that's it.
>

Not all software is minimally-interactive CLI.

>> I'm pretty sure other languages like C# and Java get this right. Haven't
>> used
>> those two in a while though. Haxe... totally got this right. Also
>> Actionscript 3
>> by proxy. Hell, even Synergy/DE, the DIBOL (!!) derivative that I use at
>> work,
>> /gets this right/. I get stacktraces for null dereferences in these
>> languages.
>> It's /really/ convenient and useful. I consider D to be very backwards in
>> this
>> regard.
>
> Notably, C and C++ do not do what you suggest.

So what? C and C++ suck ass. That's why D exists.


March 05, 2012
"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jj32l2$1dk$1@digitalmars.com...
> On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
>> On 2012-03-05 11:38, Walter Bright wrote:
>>> Notably, C and C++ do not do what you suggest.
>>
>> Just because C and C++ do something in a certain way doesn't make it a
>> valid
>> reason to do the same thing in D.
>>
>> I think this is an argument we need to stop using immediately. It just
>> shows
>> we're stuck in our ways, can't innovate and can't think for our self.
>
>
> Doing things differently than well established practice requires a strong reason. There are often good reasons for that established practice that aren't obvious.
>

Ok, then what's the strong reason for abandoning the practice here that's been well established by damn near everying other than C/C++?


March 05, 2012
On 2012-03-05 20:02, Walter Bright wrote:
> On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
>> On 2012-03-05 11:38, Walter Bright wrote:
>>> Notably, C and C++ do not do what you suggest.
>>
>> Just because C and C++ do something in a certain way doesn't make it a
>> valid
>> reason to do the same thing in D.
>>
>> I think this is an argument we need to stop using immediately. It just
>> shows
>> we're stuck in our ways, can't innovate and can't think for our self.
>
>
> Doing things differently than well established practice requires a
> strong reason. There are often good reasons for that established
> practice that aren't obvious.

Yeah, C and C++ might not do what's suggested but basically all other languages do it.

-- 
/Jacob Carlborg
March 05, 2012
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:ewuffoakafwmuybbzztb@forum.dlang.org...
> On Monday, 5 March 2012 at 03:24:32 UTC, Chad J wrote:
>> It's that I simply cannot expect users to run my code in a debugger.
>
> :) I'm lucky if I can get more from my users than
> "the site doesn't work"!
>

I *hate* those reports!!

But they get worse than that: Fairly soon after retaliating to a "Durr...It don't work!" email with a nice formal (and painfully friendly) explanation of how and why to give me useful reports (which he even acknowledged as being a good point), I got from the same damn person (ie *the top guy in charge of the project in question!*): "So-and-so person told me that one of *their* people told them that the site didn't work when they tried it last week." WHAT THE FUCKING FUCK?!?!?! Shit like that I'm inclined to just blame on user error. I mean, crap, with a report like that, how am I supposed to know they spelled the URL right or even had a fucking internet connection at all? Or even a damn computer.

I swear, as soon as a computer enters the picture, most people turn shit stupid (well, more stupid than usual): I can't imagine that *even these people* would go up to an auto mechanic as say "Driving to Detroit didn't work!" But that's exactly the crap I have to put up with. And then *I* have to (politely!) explain to these shitheads how to not be a moron...only to have them come back and pull the same shit two weeks later? Fuck, and people wonder why I hate humans.


March 05, 2012
"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jiunst$qrm$1@digitalmars.com...
>
> 3. Intercepting and recovering from seg faults, div by 0, etc., all sounds great on paper. In practice, it is almost always wrong. The only exception (!) to the rule is when sandboxing a plugin (as you suggested).
>

The purpose of catching exceptions is to respond to a condition. Recovery is merely *one* such type of response.


March 05, 2012
On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix <deadalnix@gmail.com> wrote:

> Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
>> On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix <deadalnix@gmail.com> wrote:
>>
>>> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
>>>> Isn't it quite unsafe to throw an exception in a signal ?
>>
>> One does not need to throw an exception. Just print a stack trace. I've
>> advocated for this multiple times. I agree it costs nothing to
>> implement, and who cares about safety when the app is about to crash?!
>>
>>> The signal handler is called on top of the stack, but the information
>>> to retrieve the stack trace are system dependant. BTW, using lib like
>>> libsigsegv can help a lot to make it safe. It isn't safe ATM, but it
>>> is doable.
>>
>> libsigsegv is used to perform custom handling of page faults (e.g.
>> loading pages of memory from a database instead of the MMC). You do not
>> need libsigsegv to handle SEGV signals.
>>
>> -Steve
>
> No you don't, but if you want to know if you are facing a stackoverflow or a null deference for exemple, this greatly help the implementation.

It's somewhat off the table with it's GPL license.  But even so, I don't see that it helps here, we are not looking to continue execution, just more information on the crash than "Segmentation Fault".

-Steve
March 05, 2012
Steven Schveighoffer wrote:
> On Mon, 05 Mar 2012 13:29:09 -0500, deadalnix <deadalnix@gmail.com> wrote:
> 
>> Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
>>> On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix <deadalnix@gmail.com> wrote:
>>>
>>>> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
>>>>> Isn't it quite unsafe to throw an exception in a signal ?
>>>
>>> One does not need to throw an exception. Just print a stack trace. I've advocated for this multiple times. I agree it costs nothing to implement, and who cares about safety when the app is about to crash?!
>>>
>>>> The signal handler is called on top of the stack, but the information to retrieve the stack trace are system dependant. BTW, using lib like libsigsegv can help a lot to make it safe. It isn't safe ATM, but it is doable.
>>>
>>> libsigsegv is used to perform custom handling of page faults (e.g. loading pages of memory from a database instead of the MMC). You do not need libsigsegv to handle SEGV signals.
>>>
>>> -Steve
>>
>> No you don't, but if you want to know if you are facing a stackoverflow or a null deference for exemple, this greatly help the implementation.
> 
> It's somewhat off the table with it's GPL license.  But even so, I don't see that it helps here, we are not looking to continue execution, just more information on the crash than "Segmentation Fault".
> 
	I wonder if deadalnix isn't confusing with libSegFault which is
part of GNU's glibc: http://blog.andrew.net.au/2007/08/15/

		Jerome

PS: Sorry if this message is sent twice, there was an error the first time and it looks like it didn't get through...
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



March 05, 2012
On Mon, 05 Mar 2012 05:38:20 -0500, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/4/2012 11:50 PM, Chad J wrote:
>> Problems:
>> - I have to rerun the program in a debugger to see the stack trace. This is a
>> slow workflow. It's a big improvement if the segfault is hard to find, but only
>> a small improvement if the segfault is easy to find. Very bad if I'm prototyping
>> experimental code and I have a bunch to go through.
>
> I don't get this at all. I find it trivial to run the program with a debugger:
>
>    gdb foo
>    >run
>
> that's it.

This argument continually irks me to no end.  It seems like the trusty (rusty?) sword you always pull out when defending the current behavior, but it falls flat on its face when a programmer is faced with a Seg Fault that has occurred on a program that was running for several days/weeks, possibly not in his development environment, and now he must run it via a debugger to wait another several days/weeks to (hopefully) get the same error.

Please stop using this argument, it's only valid on trivial bugs that crash immediately during development.

I wholeheartedly agree that we should use the hardware features that we are given, and that NullPointerException is not worth the bloat.  But we should be doing *something* better than just printing "Segmentation Fault".

-Steve
March 05, 2012
On Mon, Mar 05, 2012 at 05:31:34PM -0500, Steven Schveighoffer wrote: [...]
> I wholeheartedly agree that we should use the hardware features that we are given, and that NullPointerException is not worth the bloat. But we should be doing *something* better than just printing "Segmentation Fault".
[...]

On Linux, you can catch SIGSEGV and print a stacktrace in the signal handler. This is pretty standard procedure.

In theory, we *could* have druntime install a handler for SIGSEGV upon program startup that prints a stacktrace and exits (or do whatever the equivalent is on Windows, if compiled on Windows).


T

-- 
Let's eat some disquits while we format the biskettes.