On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:

> It's pretty self-evident that if you put a breakpoint on the name of a
> function, you want it to break every time that function is called.

Perhaps, but it's also self-evident that the function *name* isn't 
executed, so it makes no sense to set a breakpoint on a line that 
contains non-executable code, since a breakpoint interrupts the flow of 
*executable* code. ;-)

> (It's also pretty self-evident that having some visual feedback about
> where you can and can't put breakpoints would help enourmously.)

Now *that* I can't argue with. ;-)

Jim

Post a reply to this message

On 26/10/2010 04:27 PM, Jim Henderson wrote:
> On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
>
>> It's pretty self-evident that if you put a breakpoint on the name of a
>> function, you want it to break every time that function is called.
>
> Perhaps, but it's also self-evident that the function *name* isn't
> executed

Oh really?

> so it makes no sense to set a breakpoint on a line that
> contains non-executable code, since a breakpoint interrupts the flow of
> *executable* code. ;-)

Until now, I haven't seen a debugger that prohibits you putting 
breakpoints on (say) a completely empty line. I mean, hell, isn't the 
debugger's job supposed to be to make your job *easier*? :-P

> Now *that* I can't argue with. ;-)

Heh. All it needs now is for some helpful soul to suggest that I submit 
a source code patch. :-P

Post a reply to this message

On Tue, 26 Oct 2010 16:38:18 +0100, Invisible wrote:

> On 26/10/2010 04:27 PM, Jim Henderson wrote:
>> On Mon, 25 Oct 2010 21:52:54 +0100, Orchid XP v8 wrote:
>>
>>> It's pretty self-evident that if you put a breakpoint on the name of a
>>> function, you want it to break every time that function is called.
>>
>> Perhaps, but it's also self-evident that the function *name* isn't
>> executed
> 
> Oh really?

Yes, really.  A function name is non-executable code - it's a reference.

>> so it makes no sense to set a breakpoint on a line that contains
>> non-executable code, since a breakpoint interrupts the flow of
>> *executable* code. ;-)
> 
> Until now, I haven't seen a debugger that prohibits you putting
> breakpoints on (say) a completely empty line. I mean, hell, isn't the
> debugger's job supposed to be to make your job *easier*? :-P

You've never used Borland's C compiler then.  Or MASM, or TASM. ;-)

How exactly does it make the job easier if the debugger lets you set 
breakpoints in places that logically make absolutely no sense?

>> Now *that* I can't argue with. ;-)
> 
> Heh. All it needs now is for some helpful soul to suggest that I submit
> a source code patch. :-P

Well, submit a patch. ;-)

You're welcome.

Jim

Post a reply to this message

> Yes, really.  A function name is non-executable code - it's a reference.
>
> How exactly does it make the job easier if the debugger lets you set
> breakpoints in places that logically make absolutely no sense?

I'd argue that setting a breakpoint on a function name means the code breaks 
every time that function is called.  That seems pretty logical to me.

Post a reply to this message

Mike Raiford wrote:
> Remember: The function declaration is just that: A declaration. It has 
> no code. 

That's your inner nerd speaking.

The actual answer is "if he tries to put a breakpoint on the function name, 
he wants to breakpoint when the function is called, so we'll actually put 
the breakpoint on the first executable statement of the function."

This is exactly the way in which open source software tends to suck: written 
by geeks, for geeks, which is great unless you're not a geek. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On Tue, 26 Oct 2010 17:05:31 +0100, scott wrote:

>> Yes, really.  A function name is non-executable code - it's a
>> reference.
>>
>> How exactly does it make the job easier if the debugger lets you set
>> breakpoints in places that logically make absolutely no sense?
> 
> I'd argue that setting a breakpoint on a function name means the code
> breaks every time that function is called.  That seems pretty logical to
> me.

If I want to do that, I'll set it up on the first line of executable code 
in the function.  That makes logical sense to me.

If I go into, say, the NetWare kernel debugger (which I have spent many, 
many months in), I can set a breakpoint at a "function", but the function 
is a reference to the first executable line of machine code inside the 
function IIRC (Now I think of it, it might be on the call itself - I may 
need to restart my VM and look again at that).

Jim

Post a reply to this message

On 10/26/2010 12:33 PM, Darren New wrote:
> Mike Raiford wrote:
>> Remember: The function declaration is just that: A declaration. It has
>> no code.
>
> That's your inner nerd speaking.
>

I don't think it's inner :)

>
> This is exactly the way in which open source software tends to suck:
> written by geeks, for geeks, which is great unless you're not a geek. :-)
>

YES! Exactly. Though I do like some OSS projects. But this is a major 
issue with OSS is it tends to be developed with exactly that mindset.

-- 
~Mike

Post a reply to this message

>> This is exactly the way in which open source software tends to suck:
>> written by geeks, for geeks, which is great unless you're not a geek. :-)
>
> YES! Exactly. Though I do like some OSS projects. But this is a major
> issue with OSS is it tends to be developed with exactly that mindset.

"Patches welcome."

Post a reply to this message

Invisible wrote:
>>> This is exactly the way in which open source software tends to suck:
>>> written by geeks, for geeks, which is great unless you're not a geek. 
>>> :-)
>>
>> YES! Exactly. Though I do like some OSS projects. But this is a major
>> issue with OSS is it tends to be developed with exactly that mindset.
> 
> "Patches welcome."

Oh, yes, that works great.

Problem: Only programmers are comfortable with the program.

Solution: Submit code.

Yeah. Think about that one.
-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

>> "Patches welcome."
>
> Oh, yes, that works great.
>
> Problem: Only programmers are comfortable with the program.
>
> Solution: Submit code.
>
> Yeah. Think about that one.

I suspect that the open source model can work - but only for the 
products that are so popular that there's a crapload of users trying it 
out, and a crapload of developers sufficiently motivated to fix the 
"boring" stuff.

Obligatory XKCD reference: http://xkcd.com/619/

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message