Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#484 [TIP 280] extended 'info frame'

TIP Implementation
closed-accepted
5
2006-11-29
2006-10-05
Andreas Kupries
No

Implementation of 'info frame' going beyond #211.
Derived from the 'info linenum' of #86.

Discussion

1 2 > >> (Page 1 of 2)
  • Patch against 8.4 implementing the TIP.

     
    Attachments
    • summary: [TIP 211ng] extended 'info frame' --> [TIP 280] extended 'info frame'
     
    • labels: --> 07. Variables
    • milestone: --> TIP Implementation
    • assigned_to: nobody --> andreas_kupries
     
  • Logged In: YES
    user_id=75003

    Uploading a new patch implementing the TIP in 8.4. changes:
    TIP reference 86/211 -> 280, code is conditional
    (TCL_TIP280), bug fixes (mem leaks).

     
  • Patch v2 against 8.4.

     
  • Logged In: YES
    user_id=75003

    Uploading new patch (280 base2). Fixed the use of newer gcc
    features which crept in and break with older versions of
    gcc, or other native compilers (c++ var decl in the middle
    of a block, mixing macro usage with #ifdef).

     
  • Logged In: YES
    user_id=75003

    Next patch (280 base3). normalized 'file' entry, bugfix in
    use of path which seg.faulted when using 'info frame 0' at
    the console of an interactive shell. Additional testcases,
    mostly 'knownBug'.

     
  • Logged In: YES
    user_id=75003

    Next (base4). Moved the normalization from 'info frame' to
    'source'. Otherwise the 'file' entry in the result can be
    wrong for relative paths (pwd changed between the calls of
    'source' and 'info frame'). Thanks to Don Porter for
    pointing this out. Should have no impact on performance due
    to 'source' already doing normalization for reading the
    file, and the result of that getting cached. Also removed
    some debugging cruft from compile.test ... File now
    unchanged again.

     
  • Logged In: YES
    user_id=75003

    Next (base5). Fixed the majority of the knownBug test cases,
    i.e. 'if 1 $body' etc. Currently the only remaining knownBug
    is the handling of cont. lines in {...}-words.

     
  • Logged In: YES
    user_id=75003

    Next (base6). Fix bug in Proc setup and cleanup for
    precompiled bytecode (tbcload). Setup assumed that 'line'
    infomration was not NULL, but can happen, i.e. for
    precompiled bc. Cleanup crashed because iPtr was assumed to
    be valid. Is not for precompiled bc. This also exposed a bug
    in tbcload, ExtractFromProcBody (file cmpRead, line 2567)
    does not fully initialize the Proc structures it allocates.
    Bogus non-NULL proc->iPtr cannot be checked for validity.
    The 'cmdPtr' field is not initialized either. Working on
    tbcload patch ...

     
  • miguel sofer
    miguel sofer
    2006-10-23

    Logged In: YES
    user_id=148712

    The comments reminds me: TclApplyObjCmd also does not
    initialise procPtr->cmdPtr properly, the only non-trash
    field is nsPtr. Not sure if this is relevant.

     
  • Logged In: YES
    user_id=75003

    It will be relevant for the 8.5 implementation. Should use
    'memset', then set all the non empty fields.

     
  • Logged In: YES
    user_id=75003

    Next 8.4 (base7). Implemented line tracking for 'switch',
    additional tests for that, and ensured that dynamic procs
    return type 'proc'. Switch is a bit of a beast with its
    single and multi-word modes. In the single-word mode we have
    to track lines inside the list holding the patterns and
    branch scripts. Unavoidable even if the data is later not
    used. In 8.5 modifying the script compile function is ...
    difficult. A draft forward port has been done, but fails
    parts of the testsuite ...

     
  • Logged In: YES
    user_id=79902

    As the author of the [switch] compiler, I can say that yes,
    it's doing things that are horrific. I learned the hard way
    (through many crashes in testing) that tokens *must* refer
    to the position of the token string within the overall
    script or things go badly askew. The way I ended up doing
    this is definitely a hack, but it is a safe one since any
    time the compiler can't be sure, it just falls back to the
    interpreted code (throwing up its hands in horror in the
    process).

     
  • Logged In: YES
    user_id=75003

    First (base0) 8.5 patch. Fails 4 test cases, otherwise ok.
    Equivalent to 8.4 base7 patch. This patch does not yet deal
    with {expand} yet, nor compiled 'switch', nor 'dict for'
    etc. I.e. 8.5 specific pieces have not been done yet.

     
  • Logged In: YES
    user_id=75003

    Next set of patches, base8 for 8.4, base1 for 8.5. Fixed a
    bug in the new code handling interpreted switch, forgot a
    qualifying condition when releasing data from the context.
    DecrRefcount on a path tcl_obj which was no such, but a
    bytecode*, this smashed its interphandle.

     
1 2 > >> (Page 1 of 2)