#3846 genStubs.tcl (or something) is broken

obsolete: 8.5.0
closed-fixed
9
2008-12-07
2007-11-19
Jeffrey Hobbs
No

The genstubs script has some code to prevent duplication of entries for macosx and unix items. Unfortunately it doesn't seem to work very well. If you create a unix item in tclInt.decls after slot 20 (listed for macosx), you lose the macosx items completely. This should not happen.

This needs to be corrected prior to 8.5.0 otherwise we will lost binary compat with any attempt to add more stubs in the currently broken generation script.

Discussion

  • Don Porter
    Don Porter
    2007-11-19

    • assigned_to: nobody --> jenglish
     
  • Joe English
    Joe English
    2007-11-19

    Logged In: YES
    user_id=68433
    Originator: NO

    Status query: is the stubs table currently broken, or is it just _going to be_ broken if anything new is added?

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2007-11-19

    Logged In: YES
    user_id=72656
    Originator: YES

    The current stubs table is OK, but it is VERY fragile, and this needs to be addressed prior to 8.5.0 because any new "unix" entries will mysteriously kill the existing macosx ones on regen. I had to reorder to make this work, which makes 8.5b3's internal stubs different than 8.5b2s.

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    looking into this, the problem is that the current code assumes there will never be any unix entries with higher indexes than macosx or aqua or x11 ones.

     
    • assigned_to: jenglish --> das
     
    • priority: 8 --> 9
     
  • Logged In: YES
    user_id=90580
    Originator: NO

    back to working on this, block 8.5.0 for this, my new code will make the generated files look significantly different (but functionally identical)

     
  • Don Porter
    Don Porter
    2007-12-06

    Logged In: YES
    user_id=80530
    Originator: NO

    Please give me the best ETA you can on this,
    so I can plan for whether an additional RC
    makes sense.

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    need another 24hrs, no time to work on it today, sorry...

     
  • patch to tcl HEAD

     
    Attachments
  • Logged In: YES
    user_id=90580
    Originator: NO

    fix committed, patches against tcl and tk HEAD attached, sorry this took
    longer than anticipated...

    Unfortunately, I discovered that genStubs.tcl had a bug that could cause
    it to erroneously generate both a 'unix' entry and an 'aqua' entry for a
    given stubs table slot. To preserve stubs table backwards compatibility,
    I now generate a dummy stubs entry before every aqua entry, however this
    also preserves the bug that the correspondence between emitted entry
    number and actual position of the entry in the stubs table is broken,
    e.g. TkIntStubs entry 113 for aqua is in fact at position 114 in the
    table, entry 114 at position 116 etc (this should only affect things
    like ffidl which look up stubs table entries by number, I considered
    preserving stubs table backwards compat to be more important).

    File Added: tclGenStubs.diff

     
    • status: open --> closed-fixed
     
  • patch to tk HEAD

     
    Attachments
  • Logged In: YES
    user_id=90580
    Originator: NO

    File Added: tkGenStubs.diff

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2007-12-10

    • status: closed-fixed --> open-fixed
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2007-12-10

    Logged In: YES
    user_id=72656
    Originator: YES

    Isn't this only for the internal stubs though? The only possible consumer would be Tile. If tile isn't using it, I think correcting this for 8.5.0 is probably the "Right Thing".

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    yes, the functions affected by this are all in tkIntStubs, specifically:
    TkClipBox, TkCreateRegion, TkDestroyRegion, TkIntersectRegion, TkRectInRegion, TkSetRegion, TkUnionRectWithRegion, TkpCreateNativeBitmap, TkpDefineNativeBitmaps, TkpGetNativeAppBitmap
    If we fix the bug for 8.5.0 (not opposed to it), any extensions using these via stubs will have an 8.4 <-> 8.5 compatibility problem

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    FWIW tktreectrl uses a number of the affected functions: TkCreateRegion, TkDestroyRegion, TkUnionRectWithRegion, TkClipBox, TkSetRegion

     
  • Logged In: NO

    It would probably be better to fix this now. An 8.4 <-> 8.5 transition problem is less bad than an 8.5.0 <-> 8.5.1 problem would be.

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    if we decide to fix the bug, it certainly should be done now, before 8.5.0

    I don't see a huge downside to keeping the status quo however; and given there is at least one widely used extension that will break, the disadvantages of the fix may outweigh the benefits?

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    in fact many more entries in tkIntStubs are affected, anything above entry 112 will be shifted on aqua if we fix this issue, including the generic entries from 135 to 157, so this likely would affect much more extension code than previously thought...
    Given this, I no longer believe fixing the issue is a viable option, but if the consensus is to go ahead and fix it, I'll go along...

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2007-12-12

    Logged In: YES
    user_id=72656
    Originator: YES

    OK, the extra entries I can live with, but I'm a little concerned with the shifting stubs numbers for aqua entries. I have myself pointed directly at stub entry numbers for magic upwards compat (build on 8.4, work with new stuff in 8.5 if available). Is that part addressable?

     
  • Logged In: YES
    user_id=90580
    Originator: NO

    I don't see how, the extra entries are what creates the shifting stub numbers (or maybe I don't understand your question):
    every aqua entry in tkIntStubs will be preceded by a bogus entry, causing entry 113 to be at position 114 in the TkIntStubs array, entry 114 at position 116, entry 115 at position 118 etc. This is exactly what is broken in the 8.4 stubs table, and to preserve backwards compat we have to reproduce that shift in 8.5

     
    • milestone: --> obsolete: 8.5.0
    • status: open-fixed --> closed-fixed
     
  • no idea why this is still open, nothing further that needs to be done here, closing