SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: lwaynej on September 11, 2018, 06:17:39 PM
-
diff is broken. I don't have time to figure out the exact details but it is showing invalid diffs.
in the case I am looking at the "No more differences. Close now?" has popped up but there is a diff showing. If I cancel I cannot doing anything with the line. The diff is bogus.
On the left hand side I have
void a()...
void a()...//vsdiff has duplicated this line.
void b()...
and on the right I have
void a()...
void b()...
I am currently merging files from Windows to Linux so there may be line ending differences. I don't know if that is relevant. Unfortunately, I cannot use vsdiff because of this so I can't do any more investigation at work. I will try and carve out some time at home to look into this.
-
SlickEdit Pro 2018 (v23.0.0.5 64-bit)
Serial number: FE11874_BETA
License type: Beta License
License expiration: 2018-10-09 17:00:00
License file: C:\ProgramData\slickedit\23\slickedit.lic
Build Date: September 06, 2018
Emulation: CUA
OS: Windows 7 x64
OS Version: 6.01.7601 Service Pack 1
Memory: 62% Load, 4932MB/7888MB Physical, 7056MB/15774MB Page File, 557MB/8388607MB Virtual
Shell Information: C:\windows\system32\cmd.exe /q
Screen Size: 1920 x 1050, 1920 x 1080
Project Type: Cpp
Language: .h (C/C++)
Encoding: Automatic
Installation Directory: C:\Program Files\SlickEdit Pro 23.0.0 Beta4\ (non-removable drive,NTFS,44156MB free)
Configuration Directory: C:\Users\WJohnson\Documents\My SlickEdit Config\23.0.0\ (non-removable drive,NTFS,44156MB free)
Migrated from: C:\Users\WJohnson\Documents\My SlickEdit Config\22.0.2\
Spill File: C:\Users\WJohnson\AppData\Local\Temp\$slk.6072 (non-removable drive,NTFS,44156MB free)
-
I will look into this, I fixed a case like this for beta 4.
-
I wasn't able to reproduce this with the current build. Are you sure you ran it in beta 4? That's what your information seems to indicate.
-
I am sure it is beta 4.
I am merging between Linux and Windows. There could be line ending differences. If I have time to try the beta again I check if this is the case.
-
I tried line ending differences and haven't seen it yet. I'll keep trying.
-
Your mailbox seems to be suspended so you will not get notifications about answers in this thread.
-
I have updated my profile. I haven't had time to try and narrow this down yet.
Another possible variable, I am doing he diff between a local file and a file on a Samba share (Linux.)
-
I am still having problems with Beta 5. I don't know if they are related.
I am doing a multi-file diff of a directory from Windows. One directory is local and other is on a Linux share (Samba, I think.)
The example happens to be a tab delimited file but I see that same problem with source files (cpp/h) and others.
Diffzilla is showing many files are different.
If I double click on a file it says there are no differences and asks if I want of view the diff anyway.
If I say yes diffzilla shows that there are in fact differences in the file.
I have some screen shots but I will need to obscure some of the info before I can share.
PATH=C:\Program Files\SlickEdit Pro 23.0.0 Beta5\win\...
No other version of slickedit are in the path.
Help/About
=========
SlickEdit Pro 2018 (v23.0.0.6 64-bit)
Serial number: FE11874_BETA
License type: Beta License
License expiration: 2018-10-09 17:00:00
License file: C:\ProgramData\slickedit\23\slickedit.lic
Build Date: September 28, 2018
Emulation: CUA
OS: Windows 7 x64
OS Version: 6.01.7601 Service Pack 1
Memory: 43% Load, 3460MB/7888MB Physical, 4268MB/15774MB Page File, 539MB/8388607MB Virtual
Shell Information: C:\windows\system32\cmd.exe /q
Screen Size: 1920 x 1050, 1920 x 1080
Project Type: Cpp
Language: .mmd (Plain Text)
Encoding: Automatic
Installation Directory: C:\Program Files\SlickEdit Pro 23.0.0 Beta5\ (non-removable drive,NTFS,44243MB free)
Configuration Directory: C:\Users\WJohnson\Documents\My SlickEdit Config\23.0.0\ (non-removable drive,NTFS,44243MB free)
Migrated from: C:\Users\WJohnson\Documents\My SlickEdit Config\22.0.2\
-
Is it consistent on the same files?
If you copy the files locally does it do the same thing?
If you go to the options tab, what do you have set for Date and Size Optimization?
-
It seems to happen consistently with *some* files.
Other files see to work correctly.
I also noticed that the behavior has changed slightly (I think.) When after merging the changes from 1 file to another and then saving, the highlight used to move to the next file and the files were marked at the same. Now they are not moved and the file still shows up as different. Maybe they are different in a way that I have chosen to ignore?
Also, some white space changes don't seem to get saved after doing a merge and then a same. This happens at the end (possible line ending difference) but also at the beginning of a file. I can diff and merge multiple times and it still shows as different.
I will try copy the file locally and see if I get the same behavior. I am on a deadline right now so I don't know when I will be able to give it a try.
-
OK. I know it's tough with company rules, but if you can get me any two files that it has problems with, that will help.
If you right click, there should be a setting for "viewed files". This refers to different files that have been viewed, but are still different. It sounds like maybe you shut this off.
Can you post your diff options?
-
I am having significant problems with RC2. I am running vsdiff from a script and comparing directories. After I merge the changes to the first file that is different and click save I run into a slick-c stack. I cannot access to the slick-c stack windows because of a constant barrage of modal dialog boxes indicating that there is an "invalid handle".
vsdiff +t -hidematching <directory on Samba share> <local directory on C: in my user folder>
-
Also, after switching from multiple monitors to a single screen (moving from a docking station with 2 monitors to stand along laptop) when running the script the diff window comes up off the screen. I have to hit Alt+space and then do a move to get it back on the screen.
-
I can't reproduce this so far.
-
Also, after switching from multiple monitors to a single screen (moving from a docking station with 2 monitors to stand along laptop) when running the script the diff window comes up off the screen. I have to hit Alt+space and then do a move to get it back on the screen.
That will have to be looked into for a hotfix for a point release.
-
Regarding the stack, could you upload your user.cfg.xml to support?
-
Do you have source diff on?
Are you moving changes left to right or right to left? We are seeing some funny things, but no Slick-C stacks so far.
-
It happens intermittently. I also saw a similar crash when doing a block select.
If I click through the dialog boxes enough times the app eventually crashes.
Where/how do I collect the windows equivalent of a core file?
I won't have time to re-install and try again until the end of the week.
also, I tried uninstalling all previous version of the edit and deleting all the settings for this version in my slickedit settings folder.
-
You would have to attach to the editor with Visual Studio and save a dump file.
We made several fixes involved with this over the weekend. I'm not sure the dump file will help because it's pretty far down the line from the original Slick-C stack.
-
If you have a core to send to us, there is a 50MB file size limit on our end, so if the compressed size is larger than that, it will need to be split.
If you upload it, please use the following link and then reply to this topic on the forum (or message us) when the upload is complete. (We aren't auto-notified of uploads.)
http://support.slickedit.com/index.php?case=lwaynej (http://support.slickedit.com/index.php?case=lwaynej)
-
I also have problems with vsdiff from SlickEdit Pro 2018 (v23.0.0.11 32-bit), please see attachment diff_broken.png.
The source files old.js and new.js are attached.
It works fine with vsdiff from SlickEdit Pro 22.0.2, please see attachment diff_working.png.
I must say that in general I am not very happy with the diff quality of vsdiff:
- it is non-deterministic in the sense that the same diff will be displayed differently depending on where in the file it occurs
- it has no awareness of syntax, e.g. it will happily split a function with no changes if just a tiny part of a newly added function matches the start/end of the old function
- it has poor understanding of changes in indentation
-
These issues will be addressed. Any samples you can send will help (I'll make a note of the code in this picture). Probably best to DM them to me.
-
I too am disappointed by DIFF. I had a massive job to do modifying old code and checking into SVN and having been a long time SlickEdit user (I probably upgraded from Brief in the ... what ... 80's?) I decided to download latest version to replace my 2002's Version 7.0.
Setting DIFFzilla as the SVN (command line) difference tool was massively slower than old version ... but I got around that by using SVN checking from within SlickEdit, which is a great improvement ...
But the differencing was poor compared to old version. Lots of much-worse-than-before realignment-after-difference which made it much harder to compare old/new code.
But, much more horrific, after a couple of days of comparing thousands of files, I found some comparisons that were missed altogether. That came to light because a directory-compare found half a dozen files that had differences in before/after versions, but when opened in DIFFzilla it said there were no differences (when actually there were).
This brings into question the thousands of files which I had compared, which did have differences, but maybe there were additional differences on those files that were skipped / missed and therefore I did not review?
#1 image: (pink = proprietary code hidden). The two marked lines do not show as differences at all. (I copied a small portion to separate files to see if I could isolate a small test-case, but unfortunately they then matched correctly)
#2 This is probably just a display bug, I think the alignment of "imaginary line" was correctly identified against "--DELNOW" comment line, but as consequence of the issue it has mucked up the vertical alignment and display (I checked for rogue spaces etc. and there were none, WinDiff found no difference except the "--DELNOW" line
#3 My settings (in case I have got something selected / not-selected which might be allowing within-comment to be ignored or similar)
-
Sorry, forgot to include version no. etc.
SlickEdit Pro 2018 (v23.0.0.11 64-bit)
Build Date: October 30, 2018
Emulation: CUA
OS: Windows 10 x64
OS Version: 10.00.0
Memory: 79% Load, 12978MB/16343MB Physical, 43811MB/52169MB Page File, 5273MB/134217727MB Virtual
Shell Information: C:\WINDOWS\system32\cmd.exe /q
Screen Size: 1440 x 2560, 1440 x 2560
Project Type: Single file project - Other
Language: .TXT (Plain Text)
Encoding: Automatic
Installation Directory: C:\Program Files\SlickEdit Pro 23.0.0\ (non-removable drive,NTFS,147491MB free)
Configuration Directory: C:\Users\xxx\Documents\My SlickEdit Config\23.0.0\ (non-removable drive,NTFS,147491MB free)
Migrated from: C:\Users\xxx\Documents\My SlickEdit Config\21.0.2\
Spill File: C:\Users\xxx\AppData\Local\Temp\$slk.27688 (non-removable drive,NTFS,147491MB free)
-
I'm really upset about the cases where it said lines match that don't. There are some little things that are "suboptimal" that I'm disappointed in but will fix. This takes top priority.
I know proprietary code is always a thing. Any sample you can send me will help. If you PM me for an email address, that is the best way to get them to me if you have any.
Thanks,
Dan
-
I too am disappointed by DIFF. I had a massive job to do modifying old code and checking into SVN and having been a long time SlickEdit user (I probably upgraded from Brief in the ... what ... 80's?) I decided to download latest version to replace my 2002's Version 7.0.
Setting DIFFzilla as the SVN (command line) difference tool was massively slower than old version ... but I got around that by using SVN checking from within SlickEdit, which is a great improvement ...
But the differencing was poor compared to old version. Lots of much-worse-than-before realignment-after-difference which made it much harder to compare old/new code.
But, much more horrific, after a couple of days of comparing thousands of files, I found some comparisons that were missed altogether. That came to light because a directory-compare found half a dozen files that had differences in before/after versions, but when opened in DIFFzilla it said there were no differences (when actually there were).
This brings into question the thousands of files which I had compared, which did have differences, but maybe there were additional differences on those files that were skipped / missed and therefore I did not review?
#1 image: (pink = proprietary code hidden). The two marked lines do not show as differences at all. (I copied a small portion to separate files to see if I could isolate a small test-case, but unfortunately they then matched correctly)
#2 This is probably just a display bug, I think the alignment of "imaginary line" was correctly identified against "--DELNOW" comment line, but as consequence of the issue it has mucked up the vertical alignment and display (I checked for rogue spaces etc. and there were none, WinDiff found no difference except the "--DELNOW" line
#3 My settings (in case I have got something selected / not-selected which might be allowing within-comment to be ignored or similar)
Regarding the first picture where it claimed lines matched that didn't, this is one long continuous comment? And the blacked out sections actually match?
Do the new line characters of the files match? Are the files Unicode? If so, what encoding? Are they both the same encoding?
Was this launched from the editor, vsdiff, or multi-file diff. So far I can't reproduce either of these. I used the attached sample to simulate your code.
If it was launched from vsdiff, there is a possibility it has a different config, but I can tell from looking at it that Source Diff wasn't on, and this was the thing that I was most concerned about.
Thanks,
Dan
-
@Dan Thanks for you candour. Long time fan of VSE so if I'll be happy to help with getting it fixed. I've sent you a PM.
As best as I can tell the files are identical (line endings etc.) except for the commented out lines, but I'll double check that and send you some samples to review.
I did have a fiddle with SourceDiff .. I wonder if it was possible that I changed it back (to OFF) in a DIFF launched from VSE and then didn't exit VSE before doing the DIFF (direct from external route) such that the settings had not been saved? If so my screen-shot of my DIFF settings will be worth nothing!
Can't remember exactly anymore ... either way, I'll sort out a repeatable test and send to you
-
This will be fixed for a point release. In the meantime, you can increase your Wrap line length (Tools>Options>File Options>Load>Wrap line length). The sample you sent me has at least one 8k line, so I would suggest going over 8000.
The files with the wrapped long lines are the culprit of the problem where it said lines matched that didn't.
-
The long line problem is fixed in 23.0.1. I'm looking into the sub-optimal diffs (the ones that differ from 22.0).
Thanks for your patience.
-
I also have problems with vsdiff from SlickEdit Pro 2018 (v23.0.0.11 32-bit), please see attachment diff_broken.png.
The source files old.js and new.js are attached.
It works fine with vsdiff from SlickEdit Pro 22.0.2, please see attachment diff_working.png.
I must say that in general I am not very happy with the diff quality of vsdiff:
- it is non-deterministic in the sense that the same diff will be displayed differently depending on where in the file it occurs
- it has no awareness of syntax, e.g. it will happily split a function with no changes if just a tiny part of a newly added function matches the start/end of the old function
- it has poor understanding of changes in indentation
Sorry to just be getting back to this now, but I've had to cover some other territory to get back to the sub-optimal cases.
Do you recall (I'm hoping maybe you still have these files) if this was the last different section in the file? It looks like it judging by the scroll bar.