Recent changes to bugs

xxdiff crashes on launch

Celso Frazao — Mon, 17 Dec 2018 07:27:53 -0000

Downloaded xxdiff-4.0b1.osx.dmg from http://furius.ca/downloads/xxdiff/releases/macosx/ & launched it. Moved xxdiff.app to my Applications folder.
When I double-click it, it just dies with no clues.
When I run it from the Terminal command line (with "open -a xxdiff.app <file1> <file2>"), it pops up a window saying "Diff error: <gibberish>" repeatedly, filling the entire height of my screen. (There is no scroll bar, so I'm unable to view the end of the message). The only thing I'm allowed to do is close the popup window, which terminates the program.</gibberish></file2></file1>

Running on Mac OS X 10.11.6 (El Capitan).

Would greatly appreciate your help troubleshooting this. Thanks.

(Note: "Milestone" field on bug ticket form shouldn't say "Compilation Issues" but there doesn't seem to be any way to change it)

xxdiff very inefficient on large files

Jim — Sun, 19 Aug 2018 14:57:25 -0000

I really like using xxdiff, but every now and then by "accident" I call it on a pair of "large" files, and it takes a long time to display the diffs. For example, I just called it on two files, where the first file has 143708 lines and 8971993 chars. The second file is the same as the first with a few more lines appended.

On a machine with an i7-4980HQ CPU @ 2.80GHz and 16GB of RAM, xxdiff used 4:18 (258 sec) of CPU
time to bring up the window. gdiff needed only 0:03 seconds. I know minimal amounts about both theses toolkits, but if one can do it in 3 seconds, does this suggest that there is a more efficient way to do it Qt?

This is arguably not a bug, but it is also arguably not a feature request. So I submitted this here.

Thanks.

#229 Build fails with bison-3.0

Martin Blais — Sat, 20 Dec 2014 21:00:09 -0000

I've applied a patch by John Schmerge which makes it build with bison 2 and bison 3. If you run into any problems, let me know.

About the source tarball: I don't release a source tarball anymore. Is that a problem? Can you clone from the default branch in Mercurial instead?
Thanks,

#229 Build fails with bison-3.0

Martin Blais — Tue, 09 Sep 2014 19:06:40 -0000

I'll have to look at this in a week or two, I'm swamped at the moment. The patch also had to be reverted.

#229 Build fails with bison-3.0

R.J.V. Bertin — Tue, 09 Sep 2014 12:40:48 -0000

Hi,

When is this patch going to appear in the source tarball? Alternatively, would you mind posting a link to that "another patch" here?

#229 Build fails with bison-3.0

Martin Blais — Sun, 10 Aug 2014 21:23:24 -0000

status: open --> closed
assigned_to: Martin Blais

#231 Underscores and other hanging characters not drawn in v4.0

Nathan Smith — Mon, 28 Jul 2014 20:09:19 -0000

Looks good to me. Thanks everyone!

#231 Underscores and other hanging characters not drawn in v4.0

Martin Blais — Mon, 28 Jul 2014 20:04:35 -0000

status: open --> closed-fixed

#231 Underscores and other hanging characters not drawn in v4.0

Martin Blais — Mon, 28 Jul 2014 19:57:29 -0000

I think I found it.
The leading is negative for the default font.
I must use fm.height().

But if I do just that, it still did not work.
It did not work because I rendered starting at y+1.
I have to clue why I was doing that--this is code I wrote a long, long, long time ago.

I changed it back to render at y+0, and it looks... just right.
I also made a global static inline helper to compute the desired height.

It works now on my box, where the underscores were previously also not showing. Try it and please let me know if that fixes the problem for you too.

Thank you Nathan,

#231 Underscores and other hanging characters not drawn in v4.0

Nathan Smith — Mon, 28 Jul 2014 19:35:25 -0000

The problem is not unique to this code. I found someone having the same problem on stackoverflow: http://stackoverflow.com/questions/13432746/why-is-qfontmetricslinespacing-smaller-than-the-height-of-the-characters-bo. Unfortunately there is no posted solution.