Debiugger

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Thanks for the old icons and remembering the folding margin setting.

Insert tabs as spaces now seems correct ... sort of. I unchecked it (real tabs) and that's remembered. But if I open the "Tabs" dialog, "Tabs as spaces" is checked (even if it's not the current settiing) and even if I "cancel" that dialog it changes from real tabs (my setting) to tabs as spaces.

X-ing the console after debugging (but stopped) is OK now but doing it while debugging still produces "Windows cannot end ...".

Cosmetic only (and maybe not worth attention): if you click PAUSE while running without debugging, it doesn't pause (that's expected) but it does enable a few icons.

Is it not possible to repeat the previous line's indent with the new software? That was convenient.
 

rconn

Administrator
Staff member
May 14, 2008
10,103
85
#2
> X-ing the console after debugging (but stopped) is OK now but doing it
> while debugging still produces "Windows cannot end ...".
Not reproducible here. (And I haven't changed anything there for several
weeks, so if it's behaving differently it's probably because you're doing
something different.)

Try it without any plugins.


> Is it not possible to repeat the previous line's indent with the new
> software? That was convenient.
Only if I force indentation on certain commands.

Rex Conn
JP Software
 
#3
Not reproducible here. (And I haven't changed anything there for several
weeks, so if it's behaving differently it's probably because you're doing
something different.)

Try it without any plugins.
Just did (/IP /II /IS), with a simple BTM that said only "DELAY 60". When I started without debuggung, I could X the console (everything disappeared). When I Start\Run to end or breakpoint and tried to X the console, I got "Windows cannot end ...". Tried again with just /IP ... the same.
 

rconn

Administrator
Staff member
May 14, 2008
10,103
85
#4
> Just did (/IP /II /IS), with a simple BTM that said only "DELAY 60".
The /Ixx options only affect TCC startup, not the IDE.


> When I started without debuggung, I could X the console (everything
> disappeared). When I Start\Run to end or breakpoint and tried to X the
> console, I got "Windows cannot end ...". Tried again with just /IP ...
> the same.
Tried it here on 4 different systems; cannot reproduce it on any of them.

Rex Conn
JP Software
 
#5
On Fri, 10 Sep 2010 23:52:15 -0400, vefatica <> wrote:

|Just did (/IP /II /IS), with a simple BTM that said only "DELAY 60". When I started without debuggung, I could X the console (everything disappeared). When I Start\Run to end or breakpoint and tried to X the console, I got "Windows cannot end ...". Tried again with just /IP ... the same.

It would seem the only thing it could be is a ConsoleCtrlHandler returning TRUE.
Otherwise, Windows would be able to end ...
 
#6
On Sat, 11 Sep 2010 01:36:21 -0400, rconn <> wrote:

|---Quote---
|> Just did (/IP /II /IS), with a simple BTM that said only "DELAY 60".
|---End Quote---
|The /Ixx options only affect TCC startup, not the IDE.

I see. It would probably be a good idea if IDE could be started with the
variety of options that TCC has since it acts as TCC. Maybe when started from
TCC it could inherit those options.

|---Quote---
|> When I started without debuggung, I could X the console (everything
|> disappeared). When I Start\Run to end or breakpoint and tried to X the
|> console, I got "Windows cannot end ...". Tried again with just /IP ...
|> the same.
|---End Quote---
|Tried it here on 4 different systems; cannot reproduce it on any of them.

I'll look further in the morning.
 
#7
| ---Quote---
|| Just did (/IP /II /IS), with a simple BTM that said only "DELAY 60".
| ---End Quote---
| The /Ixx options only affect TCC startup, not the IDE.

How can we force the debugger to operate under the same conditions as
the debugged program (batch file) would, i.e., how can we ensure:
1/ the same set of plugins
2/ the same set of options, local/global selections
3/ the same set of variables, functions and aliases
4/ the same set of default directories on each drive
&c.
The operation of many programs, including batch files, is strongly
dependent on what took place in the specific TCC instance previously. How
can they be debugged?
--
Steve
 

rconn

Administrator
Staff member
May 14, 2008
10,103
85
#8
> It would seem the only thing it could be is a ConsoleCtrlHandler
> returning TRUE.
> Otherwise, Windows would be able to end ...
IDE has a console signal handler, and it definitely does not return TRUE.

What it could be is that your configuration isn't shutting down within the
required 4-5 seconds (due to TCEXIT and/or plugins).

Rex Conn
JP Software
 
#10
On Sat, 11 Sep 2010 10:00:47 -0400, rconn <> wrote:

|---Quote---
|> How can we force the debugger to operate under the same conditions
|> as the debugged program (batch file) would, i.e., how can we ensure:
|---End Quote---
|If you start it from TCC, it already does. Do you have an example where it
|isn't?

For one, if TCC is atarted with /IP and BDEBUGGER is executed, IDE loads
plugins, as evidenced by debugging a BTM calling PLUGINS.

So I emptied my plugins directory, started TCC with /IP /II /IS, and debugged
this

Code:
PLUGINS
DELAY 60
In the console I saw

Code:
TCC: V:\ideset.btm [1]  No plugins loaded
That's odd!

And when I X'd the console, Windows said it couldn't end ... [that dialog gave,
in its title bar, the title of the console window].
 
#11
On Sat, 11 Sep 2010 10:00:45 -0400, rconn <> wrote:

|---Quote---
|> It would seem the only thing it could be is a ConsoleCtrlHandler
|> returning TRUE.
|> Otherwise, Windows would be able to end ...
|---End Quote---
|IDE has a console signal handler, and it definitely does not return TRUE.
|
|What it could be is that your configuration isn't shutting down within the
|required 4-5 seconds (due to TCEXIT and/or plugins).

I do have a TCEXIT. It says just

Code:
if %_transient == 0 .AND. %_pipe == 0 dirhistory /a %_cwd
I put a BEEP in it. In those cases where X-ing the console with IDE running
works, I hear two beeps. When X-ing the console doesn't work (Windows cannot
end ...) I hear no beeps.
 
#12
I do have a TCEXIT. It says just

Code:

if %_transient == 0 .AND. %_pipe == 0 dirhistory /a %_cwd
I put a BEEP in it. In those cases where X-ing the console with IDE running
works, I hear two beeps. When X-ing the console doesn't work (Windows cannot end ...) I hear no beeps.
Aha! Removing the TCEXIT.BTM makes the "Windows cannot end" problem go away. But emptying TCEXIT.BTM does not! The mere existence of TCEXIT seems to be a problem. FWIW, v12's uses the start/exit BTMs of v11 (TCStartPath=d:\tc11).
 
#13
And, if I start TCC v12 like this

Code:
d:\tc12\tcc.exe  /ipsxi
then

Code:
BDEBUGGER btmfile
I see, in the console,

Code:
v:\> bdebugger ideset.btm
TCC: (Sys) The system cannot find the file specified.
 ""
iff %_transient == 1 .OR. %_pipe == 1 then
quit
Those lines are coming from d:\tc12\tcstart.btm!!! (remember, the INI file says "TCStartPath=d:\tc11"). And it would seem the /II wasn't propagated to IDE.
 

rconn

Administrator
Staff member
May 14, 2008
10,103
85
#14
> Those lines are coming from d:\tc12\tcstart.btm!!! (remember, the INI
> file says "TCStartPath=d:\tc11"). And it would seem the /II wasn't
> propagated to IDE.
That's what I said before -- if you're using the /Ixx options, and want to
pass them to the debugger (which IMO nobody in their right mind would
actually *want* to do), you have to specify them as BDEBUGGER arguments.
/Ix arguments (which are NEVER intended to be used except (briefly) for
debugging purposes) are not inherited.

This is not new behavior.

Rex Conn
JP Software
 
#15
That's what I said before -- if you're using the /Ixx options, and want to
pass them to the debugger (which IMO nobody in their right mind would
actually *want* to do), you have to specify them as BDEBUGGER arguments.
/Ix arguments (which are NEVER intended to be used except (briefly) for
debugging purposes) are not inherited.
Who would have known? BDEBUGGER's help mentions only the /C option. And BDEBUGGER doesn't like them anyway:

Code:
v:\> bdebugger /ipsix ideset.btm
TCC: (Sys) The parameter is incorrect.
 "/ipsix ideset.btm"
And what's so crazy about wanting IDE to act just like the TCC which started it?
 

rconn

Administrator
Staff member
May 14, 2008
10,103
85
#17
> Who would have known? BDEBUGGER's help mentions only the /C option.
Because there's no reason for you to be using them. They're only there for
diagnosing startup problems.


> And BDEBUGGER doesn't like them anyway:
>
> Code:
> ---------
> v:\> bdebugger /ipsix ideset.btm
> TCC: (Sys) The parameter is incorrect.
> "/ipsix ideset.btm"
> ---------
BDEBUGGER doesn't support /IX (which would be meaningless, and apt to screw
up the parent TCC process).


> And what's so crazy about wanting IDE to act just like the TCC which
> started it?
Why would you want to start TCC in a severely crippled state (which is ONLY
there for test purposes), and then try to develop batch files -- which would
then likely not work as expected in a normal TCC?

The /I... options have never been inherited by child processes, whether IDE
or TCC. (IMHO this would be a *really* bad idea!)

Rex Conn
JP Software
 
#18
On Sat, 11 Sep 2010 15:09:06 -0400, rconn <> wrote:

|BDEBUGGER doesn't support /IX (which would be meaningless, and apt to screw
|up the parent TCC process).

I see that now.


|---Quote---
|> And what's so crazy about wanting IDE to act just like the TCC which
|> started it?
|---End Quote---
|Why would you want to start TCC in a severely crippled state (which is ONLY
|there for test purposes), and then try to develop batch files -- which would
|then likely not work as expected in a normal TCC?

Some (not I) might argue that they want to be confident a batch file will work
independently of aliases, TCSTART, and plugins. BDEBUGGER accepting /ipsi is
good enough for me. It should probably be documented.
 
#19
On Sat, 11 Sep 2010 15:09:02 -0400, rconn <> wrote:

|---Quote---
|> Aha! Removing the TCEXIT.BTM makes the "Windows cannot end" problem go
|> away. But emptying TCEXIT.BTM does not! The mere existence of TCEXIT
|> seems to be a problem. FWIW, v12's uses the start/exit BTMs of v11
|> (TCStartPath=d:\tc11).
|---End Quote---
|Not reproducible here (v11 or v12).

Confirmed again here (also with v11). When TCEXIT is absent there's no problem
X-ing the console while running "DELAY 60" to end. With TCEXIT present, even if
empty, there is a problem. /ipsi[x] on IDE [TCC] doesn't change that.