Tcl Source Code

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.

no idea why this is still open, nothing further that needs to be done here, closing

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

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

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

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: 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

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

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=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".

File Added - 257998: tkGenStubs.diff

Logged In: YES 
user_id=90580
Originator: NO

File Added: tkGenStubs.diff

File Added - 257996: tclGenStubs.diff

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

Logged In: YES 
user_id=90580
Originator: NO

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

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

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)

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.

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=68433
Originator: NO

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