1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Debiugger

Discussion in 'Support' started by vefatica, Sep 10, 2010.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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.


    Only if I force indentation on certain commands.

    Rex Conn
    JP Software
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    The /Ixx options only affect TCC startup, not the IDE.


    Tried it here on 4 different systems; cannot reproduce it on any of them.

    Rex Conn
    JP Software
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---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
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    If you start it from TCC, it already does. Do you have an example where it
    isn't?

    Rex Conn
    JP Software
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     
  14. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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?
     
  16. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    Not reproducible here (v11 or v12).

    Rex Conn
    JP Software
     
  17. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,859
    Likes Received:
    83
    Because there's no reason for you to be using them. They're only there for
    diagnosing startup problems.


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


    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,952
    Likes Received:
    30
    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.
     

Share This Page