Activity for michael-m
-
michael-m committed [r210] on Code
reorg inline-hilite SCHEDULING + SAFER anti-skew tag (vL*) positioning and insertion strategy
-
grammar (of all things)
-
Please update copyright info in README.txt
-
Revised License information has been incorporated As promised, the update to remove the incorrect Mailing address for FSF, in favor of their URL has been committed, staged to take effect on whatever next operation (fix/release) will occur.
-
tkdiff 5.7 does not work with macos tcl-tk (8.5)
-
Apologies for the delay in finalizing the disposition of this Ticket As it turns out, not 24 hours earlier, V5.7 had been released with just such a README disclaimer for the Mac platform; but perhaps not as strongly worded as it should have been. As of V6.0 (strangely enough, again released just yesterday), a far more declarative statement to NOT USE that platforms "included" Tcl/Tk 8.5 offering was provided, with instructions on where to obtain a working replacement. We can only hope that Apple...
-
update of GNU license info
-
Official TkDiff Version 6.0 is released
-
Original issue has been addressed via new Release (Version 6.0) Unfortunately the recently appended request arrived too late to be included, and will be addressed shortly, but staged for the NEXT release (whenever that may occur). Small question however - is the former Snail-Mail address INCORRECT or simply no longer en' vogue?
-
Invalid multibyte or wide char in test file causes crash with tk9.0
-
Issue has been addressed via new release (Version 6.0)
-
Not compatible with tk 9.0
-
Issue has been addressed via new release (Version 6.0)
-
Official TkDiff Version 6.0 is released
-
reorganized hID scheduling logic for Ratcliff inlining
-
... misspecifed packing option (+ unrelate tweaks)
-
access to topical Help directly from the newDiff Dialog
-
prevent L/R mis-alignments of OCCASIONAL Chg hunks
-
Primarily to support TclTk 9.0 (and compensate for lost V8.x.x deprecations)
-
Invalid multibyte or wide char in test file causes crash with tk9.0
-
Sadly, that document fails to describe how things GOT that way, only what one should do once it does. After a great deal of hunting, it was discovered that something called an encoding "profile" was what is NEW in V9.0.x and can now be seen from the 'encoding' and 'fconfigure OR chan configure' commands - yet oddly MISSING from 'open'!! There are 3 provided "profiles": 1. tcl8 2. replace 3. strict for which V9.x chose #3 as the DEFAULT - thus the complaints when a "mixed" encoding occurs. The #2...
-
Please update copyright info in README.txt
-
Understood, and thank you for the followup. As a "relative" neophyte to contributing to the FOSS world, I appreciate the mentoring toward 'accepted practices'. There is a new version in the works (owing to a recent upgrade to a major Tcl/Tk release) and I assure you the Copyright information will be updated at that time.
-
Not entirely certain of the rules (if any) governing this. While Bryan was clearly a major force in the early days of the tool and has contributed much - not only in actual code, but even an IDEA that I subsequently utilized FAR LATER, and thus is clearly a missing attribution (as is Dorothy, who presided longer than anyone, over uncounted modifications by my reckoning); yet badukaire (according to my records) contributed a patch (not in 2012, but 2005?) which then languished until I joined in 2017!!...
-
avoid TclTk 9.0 'namespace' interactions
-
improper logic supplying default revision values to 2/3rds of 12 SCMS repaired
-
Primarily to support TclTk 9.0 (and compensate for lost V8.x.x deprecations)
-
Dorothy is correct. The preference in question is on the 'General' tab of the Preferences dialog window and labeled 'Text window size' expressed in a WidthxHeight format. As the windows are side by side, that means the width of the TOOL is actually computed as TWICE the requested width (plus all the other things like scrollbars, etc). Furthermore, on the 'Appearance' tab, another preference (Text widget options) allows you to specify the FONT those text windows should USE, and is the base unit of...
-
Wow. I hate to admit this, but you ARE correct (frankly, that whole line should have been ELIMINATED a long time ago - which is what I intend to do going forward). Feel free to delete it as it is ALREADY covered by the one on line#32! Better yet, place an octothorp (#) as the first char ON that line (making it a comment); that way you'll still have the same line numbers in YOUR script as the 'official' one, in case you need to report yet MORE issues! The only reason it worked until now is because...
-
Wait - line #32 (package require Tk 8.5-) should be the ONLY place to have needed editing -- where (and why) did you make a SECOND edit?? A text searches only turns up seven additional occurrences of a 8.5 string of text, ALL of which are buried within comments, and as documentation, need not change NOR have any effect whatsoever.
-
OK - so with regard to the version-check failure. I personally would contend that this is a coding bug, but whomever wrote it originally probably failed to interpret closely the exact syntax required to express the notion of a minimum, but open-ended semantic. Instead, what was actually written was a minimum, but terminated at the next MAJOR version. Accordingly, while you stated changing the version (from 8.5 to 9.0 worked for you, the real fix should be the value "8.5-" (note the trailing dash...
-
In a general sense, perhaps. But by and large, TkDiff is written well within the bounds of classic TCL scripting only, and underwent a serious (>70%) code refactoring in the V8.5-8.6 time frame, making it thus relatively impervious to a majority of changes taking place in version 9.0. Such changes are mostly those of prior announced deprecations finally being removed because of the now new MAJOR version number(eg. 8 -->> 9). Many of whose 'deprecations' date back to pre-V8.6 which, given the glacial...
-
Gonna need some time to investigate. Technically the version check in TkDiff should only require a MINIMUM of TK 8.5, so I don't understand WHY 9.0 (clearly more recent) is unacceptable. The fact you say it seems to RUN is encouraging (it SHOULD, as Tcl/Tk has a history of generally maintaining backward compatibility). Post anything else you find to this ticket and I'll do the same with what I can learn.
-
highlight not working for last line difference
-
view -> inline compare (recursive) requires a reload to highlight changes
-
Well, a LOT has happened between V4.2 and V5.6; so the fact they might behave marginally different between then (over a decade ago) and now is not terribly descriptive of a "problem". Back then, the recursive approach reported EVERYTHING different in any given pair of lines. Over the past several years (and intervening releases) the recursive approach has become considerably more detailed and configurable. Nowadays you can specify exactly WHICH (if any) of the various suppression idioms (Blanks,...
-
Official TkDiff Version 5.7 is released
-
forgot to bump release to 5.7
-
chglog updated for release 5.7
-
OK. Turns out there were multiple issues (almost a wonder it functioned as well as it did) but nevertheless the fix(es) are now completed. For the record, the OBSERVED issue only involved Diff hunks whose "highlight-able" size (in lines) was SOME multiple of 5 PLUS 1; whereby the "plus 1" (aka that FINAL line) failed to get marked-up. As this is rather difficult to anticipate and CLEARLY data dependent, an updated release will be forthcoming shortly. Thank you again, both for spotting and reporting...
-
Inline instantiation realigned: prevents Heuristic+1 dropouts; broken syntax; better reading
-
Bookmark annotation prompt now tracks instance AFTER 1st use
-
highlight not working for last line difference
-
My, what sharp little eyes you have! All kidding aside, you appear to be correct, although it may take a little time to work out the exact triggering situation (eg. is it ANY 16-line hunk, the last physical hunk, only at file EOL, etc.). The 61 suggests its not some "power-of-2" related issue, but we will find out eventually. I applaud your industriousness for finding even the beginning of a "pattern". Will report more after I do some investigating. Standby.
-
Add missing trigger event when recursive inlines are activated
-
view -> inline compare (recursive) requires a reload to highlight changes
-
Well, a LOT has happened between V4.2 and V5.6; so the fact they might behave marginally different between then (over a decade ago) and now is not terribly descriptive of a "problem". Back then, the recursive approach reported EVERYTHING different in any given pair of lines. Over the past several years (and intervening releases) the recursive approach has become considerably more detailed and configurable. Nowadays you can specify exactly WHICH (if any) of the various suppression idioms (Blanks,...
-
Miscellaneous fixes:
-
Adjust math to attempt CENTERING Thumb of the DiffMap pseudo-scrollbar relative to the colorbars.
-
diff against '/dev/null' failes
-
Fair enough. While it seems a bit tedious to go to the trouble of running diff just to prove whats readily known, I agree the operational disruption (aborting) could be annoying. However, your suggested patch needs to handle more than just a Unix-like world (eg. "nul" on a Windows platform). As its likely you've already adjusted your own copy (having diagnosed the problem), the official fix will be available in an upcoming release (whenever that next occurs). Thanks for reporting the issue.
-
Allow implied "null content" (eg. UNIX "/dev/null" or Windows "nul") files to Diff, despite the obvious result.
-
Well, my reading of that recommendation, is you do that if you REQUIRE a specific SHELL to process the request. I suppose I could go look at the TCL SrcCode at how "exec" is implemented, but given that the user can cause the problem to disappear by changing the choice of SHELL in his environment, I'm fairly certain TCL is making use of it. That wouldn't logically happen if it always used /bin/sh. But the TCSH error report did talk about the rather odd (to me) arrangement of builtin Vars (status,...
-
Thanks for the extra info. Not sure how much it helped, BUT.... As Dorothy commented, TCSH itself isn't NECESSARILY the problem (she notes zero issues). This suggests (as she indicated) an "environmental" issue peculiar to your machine(s). And this is where things could get "sticky" - given something I stumbled across (thanks to Google). I found an old(er) RedHat bugzilla report (circa 2012, number 638995) that indicated an unfortunate patch in TCSH itself regarding how the exit code of a Shell command...
-
Ummm, OK - but your description is a bit vague. For one you neglected to supply HOW you were invoking the tool (what does your commandline look like?). You suggest that done thru BASH all is OK, but thru TCSH it 'fails'; but TECHNICALLY speaking "Files are identical" is merely a STATUS message - not a failure. Yet I'll presume you have actually provided some kind of filenames OF WHICH you honestly believe differences SHOULD occur. Perhaps a larger snapshot would have conveyed more information? For...
-
Was poking about and noticed this had never been answered. My apologies. As of version 5.0, TkDiff (roughly June of 2020) has had the ability to SPECIFY which Version Control System you would prefer to use. Prior to that time, there was a fixed precedence list of all the various choices and the first one POSSIBLE was always chosen. Nowadays, while TkDiff still checks for which systems appear to be available, it will permit ANY that ARE found to be SELECTED as the "preferred" choice for any individual...
-
tkdiff 5.6 jumping around
-
All's well that ends well? Closing the ticket. Thanks for reporting (it's how things get better). For what its worth, a general review of the code under concern suggests it should NOT have been able to occur as described, but that doesn't mean it didn't happen for you. Apparently your computer wished to take off for the Thanksgiving break a day or two early (lol)! We will take this up should it ever be reported again.
-
You can safely ignore the error message. While I agree it shouldn't happen, it is innocuous and unrelated to the original problem. Its most likely nothing but an unfortunate confluence of your mouse position at the time the main display comes into existence, and then happens to DETECT the mouse being moved OUT of some screen element that was expected to have popped-up a ToolTip (which never happened, because the move INTO the screen element was never seen). I've made a note to repair this.
-
Your description comes across as somewhat vague; Not exactly sure what is meant by "jumping up and down". Presuming you are correct about no changes to the Tcl/Tk versions in the Fedora upgrade you made, I can only comment on the nature of the changes made for TkDiff V5.6. You should not have needed to remove the prior ".tkdiffrc" file, as all that would do is revert your personal preferences from whatever you had saved them as to NOW become the values that exist as the hardcoded (builtin) defaults...
-
Official TkDiff Version 5.6 Released
-
merge window issues TK errors !
-
V5.6
-
Mostly good news. It definitely is a INTEGER .vs. REAL problem, but it was introduced IN V5.4 (which you reported as working). It appears it was intended to fix the very problem that is now occurring, but failed because it was applied in an incorrect physical location. That it worked (for you) is likely why it worked for me when it was originally fixed - purely on the inconsistencies of data used to test. Just need to reposition the fix properly and push it out the door. Thanks for bringing it to...
-
merge window issues TK errors !
-
Hmmm. That's not good at all. I was able to duplicate the problem (a GOOD thing) and after a QUICK look at the error message, I can see WHY it complains (0.12345.0 is NOT a well formed number). Now all that's required is to find what allowed that to happen. Off the top of my head it LOOKS like some equation was EXPECTED to return an integer - but DIDN'T; I just have to find out why! Sounds easy.... we will see....standby... P.S. - probably should have been written as a BUG ticket (Support is more...
-
Official TkDiff Version 5.5.3 Released
-
Repair typo-caused crash PLUS ineffective prior VPATH-logic fix; also clarify help-info
-
tkdiff -rREV1 crashes
-
LATE UPDATE Its true that I earlier accepted the argument that the change from "OR" logic to "AND" SEEMED to support the notion that only VPATH-based files should be in the vicinity of the code being changed. But (it turns out) that was NOT the reason the "OR" was in place - it exists to recognize the case where VPATH is in effect but only a SINGLE FileSpec was provided, which REQUIRES an SCM to be involved - and if that IS VPATH, then the Rev data MUST be rewritten (because of how VPATH as an SCM...
-
Main screen comparison highlighting disagreees with current line
-
Not a bug. Just a distinction between HOW the two displays go about presenting the data. In the over/under single-line display, bytes are compared in a strictly POSITIONAL method (think arrays of chars where only the two chars in position "N" are ever compared). But in the MAIN display, it is sequential RUNS of chars that are compared (subject to specific suppression categories that mostly deal with optional White Space variations). They INTENTIONALLY do not show the same results (although its not...
-
While the issue is true, it is ALSO of little concern, and was ALREADY repaired, per response to a comment from ticket #90. No immediate release is planned, as the only visible perception is to the content of a normally silent debug-only message. It has zero effect on the operation of the tool itself. It will simply become part of whatever (and whenever) the next release occurs. PS. a much simpler patch is "string trim $opts(customeCode)" (at that same location) avoiding the setup costs of the regular...
-
tkdiff needlessly obeys 2 blank lines as custom code after save prefs
-
tkdiff -d suggested improvements
-
Unneeded. Ability exists via alternate methods.
-
better recognize EFFECTIVELY empty CustomCode
-
Official TkDiff Version 5.5.2 Released
-
tkdiff -rREV1 crashes
-
tkdiff fails to highlight in-line changed characters
-
Repair missing-Var crashes plus minor initialization faults
-
Okay - so I cant explain why all the inquire-* procs seem to have lost their initializations for the MSG/msg variables, but they all need them for exactly the reasons already pointed out. Will be fixing that straight away (and because it AGAIN stops crashes, I suppose there will be a V5.5.2 appearing shortly as well). Regarding the "-v", Tkdiff has this odd rule about command line arguments (invented long before I got here) that states: Any arguments not understood to be valid TkDiff arguments are...
-
W.r.t. the glitch with MSG: its an admittedly ugly construct that is intended to optionally pass back messaging that may have occurred to the calling proc (hence the uplevels). What I find disconcerting when looking at this again, is I would think to work properly each layer of the call stack should have initialized its OWN local level as having empty values, such that the check at the end (where you say it dies) could then decide whether to pass the value UPWARD if anything happened in the current...
-
OK. You win - cant argue that logic - But as far as its origin, I suspect it was a leftover from an earlier implementation attempt that should have been updated but got skipped. Mea Culpa.
1 >
