> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
> studio does something "clever": It moves the breakpoint if its not on a
> valid line to the next valid line once it has the debugging info for the
> module the code file belongs to.

I wouldn't have called that "clever". I would have called that "the most 
basic functionality that any non-toy debugger would be expected to 
have". Certainly I've never seen a debugger with this limitation 
before... (Although I can't claim to have used all that many debuggers.)

Post a reply to this message

Invisible wrote:
> You realise that the UI already highlights the lines that have code on 
> them, right? 

No, I haven't used it that much.

*You* should realize that I was speaking in more general terms. The kind of 
statement "This has to be trivial" or "This has to be obvious" is often 
mistaken, just like "this is obviously impossible" has been slowly being 
beaten out of your vocabulary.  ;-)

Now, I will say, when I bought a compiler for a language touting how easy it 
is to write correct programs, and I got it out and pushed the button for 
"make me a Hello World skeleton project to start with", then pushed the 
"Compile" button and got syntax errors, I felt like "how could you release 
such a POS as an expensive compiler?"  So I'm not saying it's never justified.

> So the code to figure this out already exists. All you have 
> to do is look at where the user put the breakpoint, and select the 
> nearest line that's executable. The only possibly-tricky thing is having 
> the breakpoint set on line X+N put appear to be set on line X.

I would just move the breakpoint. What would be tricky is if you click 
between two functions - do you breakpoint the last line of the previous 
function or the first line of the next function?

> I'm still trying to find a way to run CGI binaries (note: binaries, not 
> scripts) without having to install and configure Apache or something 
> like it.

tclhttpd?

> It seems there are plenty of light-weight HTTP servers, but all of them 
> either lack CGI support entirely, or only support CGI *scripts* (usually 
> in a single language).

I'm pretty sure tcl httpd supports CGI and FastCGI.  If not, it's pretty 
trivial to do so. Basically, copy some header crap into environment 
variables, pipe the incoming request to stdin of the CGI, and pipe the 
stdout back to the browser.

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

Post a reply to this message

Invisible wrote:
>> Or, for that matter, the Visual Studio debugger, FWIW. But, Visual
>> studio does something "clever": It moves the breakpoint if its not on a
>> valid line to the next valid line once it has the debugging info for the
>> module the code file belongs to.
> 
> I wouldn't have called that "clever". 

Note he didn't call it clever. He called it "clever".



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

Post a reply to this message

> *You* should realize that I was speaking in more general terms. The kind
> of statement "This has to be trivial" or "This has to be obvious" is
> often mistaken, just like "this is obviously impossible" has been slowly
> being beaten out of your vocabulary. ;-)

>> So the code to figure this out already exists. All you have to do is
>> look at where the user put the breakpoint, and select the nearest line
>> that's executable. The only possibly-tricky thing is having the
>> breakpoint set on line X+N put appear to be set on line X.
>
> I would just move the breakpoint.

Or you could do that, yes.

> What would be tricky is if you click
> between two functions - do you breakpoint the last line of the previous
> function or the first line of the next function?

Or the first statement outside of a function? Or just refuse to set a 
breakpoint there? There's several possible options.

>> It seems there are plenty of light-weight HTTP servers, but all of
>> them either lack CGI support entirely, or only support CGI *scripts*
>> (usually in a single language).
>
> I'm pretty sure tcl httpd supports CGI and FastCGI. If not, it's pretty
> trivial to do so. Basically, copy some header crap into environment
> variables, pipe the incoming request to stdin of the CGI, and pipe the
> stdout back to the browser.

Constructing and parsing HTTP headers yourself also isn't all that 
hard... and yet it turns out to be unexpectedly non-trivial to do a 
really good job of it yourself. Especially when you're not actually 
trying to write a web server, you just want something to test your CGI with.

Post a reply to this message

Invisible wrote:
> Constructing and parsing HTTP headers yourself also isn't all that 
> hard... 

It didn't *used* to be. Now so much crap has been added to HTTP to support 
everyone using it for something other than hypertext transport that yeah, 
actually parsing the headers and doing the protocol turns out to be pretty 
non-trivial.

-- 
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 22/10/2010 04:49 PM, Darren New wrote:
> Invisible wrote:
>> Constructing and parsing HTTP headers yourself also isn't all that
>> hard...
>
> It didn't *used* to be. Now so much crap has been added to HTTP to
> support everyone using it for something other than hypertext transport
> that yeah, actually parsing the headers and doing the protocol turns out
> to be pretty non-trivial.

http://www.w3.org/Protocols/HTTP/AsImplemented.html

Woah! That's pretty... um... special, right there.

Hmm, I wonder if any modern software actually handles HTTP 0.9 correctly?

Post a reply to this message

Invisible wrote:
> Woah! That's pretty... um... special, right there.

Yep. Like all good protocols ;-) it doesn't have a version number in the 
first version. That's why the "HTTP/1.0" comes at the end of the request 
instead of the beginning.

*Almost* everything since then has been to deal with the fact that HTTP 
isn't being used for transporting hypertext, or to add all the features that 
all the other data transfer protocols already had.

> Hmm, I wonder if any modern software actually handles HTTP 0.9 correctly?

Most web browsers do, yes. When I want to see if something is actually 
running a web server, I'll often telnet in by hand and just "GET /" to see 
that I get some sort of answer.

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

Post a reply to this message

Invisible wrote:
> Woah! That's pretty... um... special, right there.

Oh, and it's also the first internet protocol that said you had to be able 
to handle any kind of line terminator.

-- 
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 Wed, 20 Oct 2010 18:55:25 +0100, Orchid XP v8 wrote:

> When you fire
> up a debugger with support for breakpoints, literally THE FIRST THING
> you're going to do is try to stick breakpoints on top-level functions.
> How did this miss this?!

Not me, because it seems obvious that only code that executes can be 
halted by a breakpoint.  I can't think of a debugger I've ever used that 
lets you set a breakpoint on non-executable code.  Or if I have, I've 
never needed to use that functionality.

Jim

Post a reply to this message

On 25/10/2010 04:31 PM, Jim Henderson wrote:
> On Wed, 20 Oct 2010 18:55:25 +0100, Orchid XP v8 wrote:
>
>> When you fire
>> up a debugger with support for breakpoints, literally THE FIRST THING
>> you're going to do is try to stick breakpoints on top-level functions.
>> How did this miss this?!
>
> Not me, because it seems obvious that only code that executes can be
> halted by a breakpoint.  I can't think of a debugger I've ever used that
> lets you set a breakpoint on non-executable code.  Or if I have, I've
> never needed to use that functionality.

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.

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

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

Post a reply to this message