|
|
Post by George on May 24, 2020 10:34:03 GMT -5
OK, here's the latest Beta with the changes to DIFF. George SPFLite22.exe (476 KB) |
|
|
|
Post by mueh on May 24, 2020 13:46:34 GMT -5
George: Two Comcerns 1. After a correct ~ on line 23 all new lines 24 25 on right side have a ~ instead of > . If line 23 would have been equal > is set correctly for new lines .  2. An unimportent one DIFF fn1 fn2 1 fails because the match criteria 1 is checked as Tab # when file names are used . DIFF 2 3 1 sets match criteria . Thanks for adding feature of Opening the files . |
|
|
|
Post by George on May 24, 2020 15:29:46 GMT -5
mueh: Please check this using some different minmatch values. The resultant output can be considerably different. it depends on how big the line block is before it gets "back in step. I can't really see that from your screenshot.
minmatch is something no other DIFF tools support, most of them give you no choice and just use the Longest Common Subsequence method. SPFLite DIFF does not. So if you are comparing SPFLite DIFF output to another DIFF tool output, you will never get them to produce the same output. I looked at the LCS algorithm when starting this, but something that generates an academic treatise that goes on for 15-20 pages of cryptic formulas just turned me right off.
The question is: does it reflect the actual changes, not does it match some other DIFF program.
I'll check the parsing problem you described.
George
|
|
|
|
Post by mueh on May 25, 2020 7:37:08 GMT -5
George: My concern is not the missmatch to other DIFF Program . Just added in Previous screenshot the other window because it Shows all the lines . Have now used minmatch value of 2 and concern is that we have a ~ even there is no LINE on left side . I can live with it because i can do nx '4blanks ' 2 all;c ~ > colof| all nx;res and LINE12b LINE12c will show what i would expect . Thanks  |
|
|
|
Post by George on May 25, 2020 9:20:06 GMT -5
mueh: OK, I see the ~ error, definitely a bug.
[UPDATE]
No, not a bug. There is no LINE12 in FileB, just Line12a Line12b and Line12c
So the mismatch is:
FileA FileB
Line11c | Line11c
Line12 ~ Line12a \
~ Line12b > The mismatch is a single line in FileA to 3 lines in FileB
~ Line12c /
Line13 | Line13
[\Update]
Maybe there's a better way to display this type of mismatch, I'm open to suggestions. I think choosing some DIFF colors in Options -> Screen would help greatly.
George
|
|
|
|
Post by George on May 25, 2020 10:16:10 GMT -5
Note: If you downloaded the file from this posting earlier, please do it again. I discovered a nasty error when minmatch was set to 1. Apologies. mueh: OK corrected the parsing error, adding more flexibility in operands needs more tweaking than I thought. Here's an updated Beta. George SPFLite22.exe (476 KB) |
|
|
|
Post by George on May 25, 2020 11:51:06 GMT -5
Robert: First, the latest Beta has no changes to XFORM support. Next, I'm not clear what you're looking for. You have made comments in the past (like removing strikethrough), so you obviously have looked at prior output samples. The current format uses the < and > to indicate lines present on only 1 side, and ~ to indicate lines that are different, these were at MUEHs request, if it helps him in some way, why not? The user also has control of the color used for highlighting the insertions/deletions. What else is there? As to the algorithm used, I picked one that I had used for years back on MVS and it had proven its usefulness. Yes, the old source I resurrected had some flaws that I had to debug and correct, but the method used works well, and at least I understand it. The Longest Common Sub-sequence algorithm, which most other DIFF programs use may indeed be very sophisticated, but it is also almost incomprehensible to mortals such as myself who don't have computer science degrees, nor is there any available code (that I could find and port to PB) on the web. You know me, so you would know my reaction to reading stuff like: Let the input sequences be X[0..m-1] and Y[0..n-1] of lengths m and n respectively.
And let L(X[0..m-1], Y[0..n-1]) be the length of LCS of the two sequences X and Y.
Following is the recursive definition of L(X[0..m-1], Y[0..n-1]).
If last characters of both sequences match (or X[m-1] == Y[n-1]) then
L(X[0..m-1], Y[0..n-1]) = 1 + L(X[0..m-2], Y[0..n-2])
If last characters of both sequences do not match (or X[m-1] != Y[n-1]) then
L(X[0..m-1], Y[0..n-1]) = MAX ( L(X[0..m-2], Y[0..n-1]), L(X[0..m-1], Y[0..n-2]) )
Yeah! Really! I'm supposed to write code based on that? Anyway, here's a snapshot of the latest Beta version output, have a look and return your comments.  George |
|
|
|
Post by George on May 25, 2020 15:59:35 GMT -5
Robert: PB SUBS and FUNCTIONS are perfectly recursive - IF the routine is written that way, to use only passed parameters or local stack variables. And I'm perfectly comfortable with Reusable/Re-entrant code from the MVS days, this isn't a foreign or advanced topic that I don't understand. Back then we had to do it, didn't even have a Stack to use and had to keep the SAVEAREA chain correct as well as manage our local data.
The code I have works, it's a line mode model. so it doesn't isolate and highlight the portions of lines that are different, but I personally don't find that a problem. Show me what lines have changed and I'm happy. When I can't look at two lines and figure out what is different, shoot me.
Yes, I probably over-reacted by posting that LCS description, but stuff like that is all I could find while searching for a bit of sample DIFF type code, other than even more totally cryptic C code, which I 100% could never port to PB.
What is it that you don't like? SPFLite DIFF appears to me to provide a reasonable output showing the differences in files, it's not KDiff3, CSDIFF or any of the other DIFF tools, but I'm not clear just what is is that it is not providing you.
If you want to write a 'better' routine, do so. Start with the premise that you have two strings arrays to compare and a 'print' routine that will print whatever string you pass it.
I'm fine with tweaking / adjusting what I have currently, but so far all I'm hearing is "I'm not comfortable with your DIFF algorithm"
George
|
|
|
|
Post by mueh on May 26, 2020 7:59:17 GMT -5
George: I think SAVE is corrupted in V2.2.20144 and 20146 .
Edit a file and delete all lines after f.e. line 20 . save msg says 20 lines saved .
After Exit and reedit all lines are in file . SAVE appears to be a NOOP also time stamp is changed . No Problem with CREATE/REPLACE .
Can you reproduce ?
Thanks for correcting DIFF Match criteria 1 Problem .
|
|
|
|
Post by mueh on May 26, 2020 9:55:21 GMT -5
George: There is also a Problem with Match criteria 1 and NULL Lines in file . Here the 2 files dm2 (2.88 KB) dm3 (3.02 KB) . The last line 35 from dm3 isn't recognized by DIFF . if NULL line before last line is replaced in both files by a character then it works . Thanks George : Inserted a line in dm3 at line 25 and it also works . If it's to complicated to find Problem Forget this one since it's data dependent . Just for info how it Looks when it works  |
|
|
|
Post by George on May 26, 2020 10:46:25 GMT -5
Robert: The 'problem' mueh reported turned out to not be a problem at all, it was working fine, just a bit of misunderstanding of what was displayed vs the test data used. I was in the middle of trying to figure it out when it became clear than it was working fine.
So right now, I'm not looking to replace what I have because I feel it is working fine. As I said, the algorithm in there is not LCS, in my search I didn't even see any other algorithms that looked similar. So until it proves faulty, I'll leave it alone.
George
|
|
|
|
Post by George on May 27, 2020 11:13:50 GMT -5
Here's the latest Beta. SPFLite22.zip (452.9 KB) Robert: MUEH: DIFF seems to be OK now, several small errors corrected. A serious error in the new faster file write support was corrected (big Oops!) XFORM has been altered as per Robert and my discussions: - Get_EOL_STR$() added to macro functions to retrieve the actual EOL string (not it's name) e.g Not 'CRLF' but X'090A', etc.
- The XFORM_ macros have been removed / replaced.
- For adding lines, use the new Add_Line(LPtr, string) where LPtr is the line after which the string is to be inserted. An LPtr of 0 (zero) means add the line to the end of the file.
- Retrieving lines should use the original Get_Line$(LPtr) function.
- XFORM WRITE functions should use the following return codes
- RC-0 - The file was overwritten, any STATE data should be invalidated.
- RC-4 - The file was overwritten, STATE data should be retained.
- RC-8 - File not written due to errors, the edit session should not be closed if this is an END command.
I've included the 5 sample XFORM macros updated to use the revised macros. George |
|
|
|
Post by George on May 28, 2020 11:56:01 GMT -5
Hmmm, I DO remember it - now. I'd forgotten about it.
If you are going to tweak those sample XFORM macros I included, I'll ignore it. Or I could go in and make that minor change.
George
|
|
