Menu
▾
▴
kdiff3-user — User questions about KDiff3.
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(2) |
Mar
(30) |
Apr
(22) |
May
(8) |
Jun
(6) |
Jul
(4) |
Aug
(3) |
Sep
(14) |
Oct
|
Nov
(14) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(12) |
Feb
(5) |
Mar
(8) |
Apr
|
May
(9) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(4) |
Oct
(18) |
Nov
(9) |
Dec
(6) |
| 2006 |
Jan
(3) |
Feb
(6) |
Mar
(5) |
Apr
(7) |
May
(7) |
Jun
(7) |
Jul
(2) |
Aug
(5) |
Sep
(18) |
Oct
(10) |
Nov
(6) |
Dec
(1) |
| 2007 |
Jan
(13) |
Feb
(9) |
Mar
(20) |
Apr
(7) |
May
(3) |
Jun
|
Jul
(7) |
Aug
(7) |
Sep
|
Oct
(8) |
Nov
(16) |
Dec
|
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(3) |
| 2009 |
Jan
(22) |
Feb
(15) |
Mar
(7) |
Apr
|
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
(8) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
(9) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(8) |
Sep
(2) |
Oct
|
Nov
|
Dec
(4) |
| 2013 |
Jan
(3) |
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2015 |
Jan
(9) |
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: John W <jw...@gm...> - 2017-09-25 21:59:01
|
Hello, The main page for kdiff3 links to GPLv2 as its license [1]. However, in the source code, there is code whose comments say it is licensed under GPLv3 [2]. I am no lawyer, but doesn't that mean the codebase, taken as a whole, cannot be claimed to be GPLv2, as it is on the homepage? This makes a world of difference in some organizations. Thanks -John [1] http://kdiff3.sourceforge.net/COPYING [2] kdiff3-0.9.98/src-QT4/guiutils.h |
|
From: Jonas P. <jns...@gm...> - 2016-12-30 18:55:19
|
Hi, I am a happy user of kdiff3 since several years, but lately after installing Ubuntu 16.04, it is nearly impossible to load two huge files for a diff. With huge files I mean 50Mb each or so. It takes more than a minute or so, and it used to take just a few seconds. I tried to build an older version, but got qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory I am not sure exactly what package to install, it seems qt4 is missing or something. I am however also hesitant to try further with building a version that is so many years old... Any help to get my old wonderful tool back would be much appreciated! /Jonas |
|
From: Damian S. <sav...@ya...> - 2016-10-08 11:28:16
|
Hi, I'm having trouble comparing 2 directories where one directory contains sym links. I want kdiff3 to follow the sym links.So in the settings I enabled: settings > configure kdiff3 > Directory > Follow file links [TRUE] settings > configure kdiff3 > Directory > Find hidden files and directories [FALSE] but I keep getting this message Error: Conflicting file typesI didnt find any reports of a bug on this feature, so I guess Im doing something wrong, just not sure what? Here is an example of my file structure and command:. ├── dss_workspace │ ├── a -> ../repo/a │ ├── b -> ../repo/b │ └── c -> ../repo/c ├── gitrepo │ ├── a │ ├── b │ └── c └── repo ├── a ├── b └── c > kdiff3 gitrepo dss_workspace I've tried this on two different machines: > kdiff3 -v Qt: 4.6.2 KDE: 4.3.4 (KDE 4.3.4) kdiff3: 0.9.95 And > kdiff3 -v Qt: 4.8.6 KDE Development Platform: 4.14.13 kdiff3: 0.9.98 (64 bit) Thanks Damian |
|
From: Laura H. <lau...@gm...> - 2015-09-29 05:59:17
|
Hi I use your tool often to compare files - Often I dont want to merge all of the changes together but just parts What would be really useful is to be able to mark or cross off an item in the list so I know which ones I have looked through. So something to indicate I've reviewed these changes and I'm ok with it? thanks Laura |
|
From: Maurice v. d. P. <gri...@kf...> - 2015-08-24 23:16:48
|
Hi everyone, A while ago I wrote to this list about tdiff3, a text-based diff/merge program I had recently started working on, and I would like to give you an update on this. I'm happy to say that it has progressed nicely since then and you can now see what it looks like in the screenshot at the github page: https://github.com/Griffon26/tdiff3 On the same page you'll find a bit about the development status of the project as well as a description of the 3 steps needed to compile & run tdiff3 on your own linux/unix system. Now is when the development fun really starts! The basic framework of the program is there, so every improvement made from now on will be directly visible to users of the application. And there are many different areas to work on. Be it a status bar to show if saving the file succeeded (some work with ncurses) or using mmap on input files to reduce memory usage or adding the feature to manually edit the merge result (playing with internal data structures to have edits overlay selected lines from input files). If you think this project is interesting, have questions about it or have any other comments, I'd be happy to hear from you. Also if you know someone who might be interested in this, please spread the word. Best regards, Maurice. P.S.: Joachim, thanks for your part in writing this file ;-P https://github.com/Griffon26/tdiff3/blob/master/source/diff.d On Sat, Jan 31, 2015 at 10:33:10PM +0100, Maurice van der Pot wrote: > In a nutshell this program will: > - have an ncurses user interface, allowing it to be used in a terminal > - use the same diff/alignment algorithm as kdiff3 > - support merging of very large files without significant slowdown or > running out of memory -- Maurice van der Pot Kdiff3 developer gri...@kf... http://kdiff3.sourceforge.net Tdiff3 developer https://github.com/Griffon26/tdiff3 |
|
From: Thomas K. <jac...@gm...> - 2015-05-07 18:59:20
|
What are the plans for the 0.9.99 release? Could it include a fix for http://sourceforge.net/p/kdiff3/bugs/142/ ? What other bugs or features would make sense for 0.9.99? |
|
From: David B. <xe...@gm...> - 2015-04-10 10:14:33
|
On the other hand, it does put its icon into the quick launch bar. Is there a way to fix the missing menus after the fact? I did not find any related option in the preferences. On 9 April 2015 at 17:16, David Balažic <xe...@gm...> wrote: > Hi! > > I just installed kdiff3 0.9.98 32 bit for Windows on Win7 and the > context menu is missing (for Explorer). In the installer I deselected > all options, except: > - Software > - Integration/Explorer > > Any idea? > > I also tried log-off/login and rebooting. Starting KDiff3 from start > menu works, just the context menu is missing. > > I have also TSVN and ESET v5.0 installed > > Exact download: > http://softlayer-ams.dl.sourceforge.net/project/kdiff3/kdiff3/0.9.98/KDiff3-32bit-Setup_0.9.98-3.exe > > Regards, > David |
|
From: David B. <xe...@gm...> - 2015-04-09 15:16:32
|
Hi! I just installed kdiff3 0.9.98 32 bit for Windows on Win7 and the context menu is missing (for Explorer). In the installer I deselected all options, except: - Software - Integration/Explorer Any idea? I also tried log-off/login and rebooting. Starting KDiff3 from start menu works, just the context menu is missing. I have also TSVN and ESET v5.0 installed Exact download: http://softlayer-ams.dl.sourceforge.net/project/kdiff3/kdiff3/0.9.98/KDiff3-32bit-Setup_0.9.98-3.exe Regards, David |
|
From: Peter V. <pet...@go...> - 2015-04-07 13:56:16
|
Hi, I really love the kdiff3 software - using it now since 2008! :) I would have two suggestions that I came upon using it: - Filter for specifc files: When you open the "Open" dialog and compare folders, I would like to be able to either compare all files in the selected folder or I would like to be able to choose a subset. This is currently only possible via the "global" settings, but I would like to see the option to be usable for a single comparison and keep the option it the "global" settings as "default if not specified otherwise" - Option to flatten folders: I could not find that option (maybe I simply missed that setting). Lets say, I have the following folder structure to compare: A\file1.c A\file2.c B\B_sub\file1.c B\file2.c When I do a compare between "A" and "B" I would see that file2.c is compared, but file1.c is not compared (there are two files, one in each folder that is missing in the other). I would like to see such a "flatten" option so that simply files with the same name are compared regardless of the folder. I know, that this can lead to conflicts, as there might be a B\file1.c present as well as a B\B_sub\file1.c But ideally, the program would at first check if all file names are unique in the specific folder structure to be compared. If not, throw an error that one needs to deactivate the "flatten" option. I hope that gives some input on what I would like to see. Please let me know, if there are any questions or if something is unclear. Thanks a lot! - Peter |
|
From: Valentin R. <kd...@ru...> - 2015-01-31 21:58:35
|
On 31/01/15 22:33:10, Maurice van der Pot wrote: > Hi everyone, > > For some time I've been wanting to make a text-based user interface for > kdiff3, but after studying kdiff3's code and talking to Joachim Eibl > I've come to the conclusion that it would be too intrusive a change to > add this functionality to kdiff3. > > That's why I've recently started working on a new text-based alternative > to kdiff3, called tdiff3. Excellent news! Even if I'm a regular kdiff3 user, I'll think I'll definitely try out your version, as a further step to a full text-mode session. I'm now using I3 and a whole bunch of tools around vim, but when diffing, I still use kdiff3 because it's a nice piece of software. So if you're reusing it's handling algorithm, I'll surely use it. > Regards, Valentin |
|
From: Maurice v. d. P. <gri...@kf...> - 2015-01-31 21:33:20
|
Hi everyone, For some time I've been wanting to make a text-based user interface for kdiff3, but after studying kdiff3's code and talking to Joachim Eibl I've come to the conclusion that it would be too intrusive a change to add this functionality to kdiff3. That's why I've recently started working on a new text-based alternative to kdiff3, called tdiff3. In a nutshell this program will: - have an ncurses user interface, allowing it to be used in a terminal - use the same diff/alignment algorithm as kdiff3 - support merging of very large files without significant slowdown or running out of memory This program is in a very early stage of development and is not yet usable for diffing/merging. Unlike kdiff3 this program is written in D, but this language should feel very familiar to C++ programmers. I would welcome any questions, help or contributions from interested users or programmers. Take a look at the code on github (https://github.com/Griffon26/tdiff3) and send me a message either on or off this list. I'm hoping that eventually some of the design choices made for this program (large file support, external diff process) can be ported back into kdiff3 as well. Regards, Maurice. -- Maurice van der Pot Kdiff3 developer gri...@kf... http://kdiff3.sourceforge.net |
|
From: Joachim E. <Joa...@gm...> - 2015-01-12 19:08:45
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi Maurice,</div> <div>Thank you for this enlightning analysis.</div> <div> </div> <div>Too many calls to loadGlyph is indeed bad for performance.</div> <div>In method getMaxTextWidth I took care to create only only instance of QTextLayout, because otherwise one call to loadGlyph would happen per line.</div> <div> </div> <div>Normally glyphs are cached, so there is no need to load them again and again.</div> <div>Perhaps you could compare different encodings too (cp1252 vs. utf8)?</div> <div>(I assume the typeset is latin mostly.)</div> <div> </div> <div>Best regards,</div> <div>Joachim</div> <div> <div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);"> <div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Sonntag, 11. Januar 2015 um 01:26 Uhr<br/> <b>Von:</b> "Maurice van der Pot" <gri...@kf...><br/> <b>An:</b> kdi...@li...<br/> <b>Betreff:</b> Re: [Kdiff3-user] kdiff3 consumes 100% cpu, seems hung</div> <div>On Mon, Jan 05, 2015 at 06:15:06PM +0100, Joachim Eibl wrote:<br/> > I suppose this is an effect of KDiff3-0.9.98 trying to analyze line<br/> > lengths for variable width fonts, where each character has to be analyzed.<br/> > If KDiff3 becomes responsive again after a long wait and only for long<br/> > files then that is the reason.<br/> <br/> Looking at the callgrind output the time is being spent in 1.9M calls of<br/> QFontEngineFT::loadGlyph (for reference, on my machine that function is<br/> only called 358 times).<br/> <br/> There are cases where this function is called while<br/> DiffTextWindow::prepareTextLayout is on the call stack, but I find it hard<br/> to tell why the loadGlyph function would be called so often.<br/> prepareTextLayout is called 32K times in his profile and 31K times in<br/> mine.<br/> <br/> #0 QFontEngineFT::loadGlyph (this=this@entry=0x1158040, set=set@entry=0x1158128, glyph=2, subPixelPosition=subPixelPosition@entry=..., format=format@entry=QFontEngine::Format_None, fetchMetricsOnly=fetchMetricsOnly@entry=true)<br/> at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine_ft.cpp:816<br/> #1 0x00007ffff75fbf03 in loadGlyph (fetchMetricsOnly=true, format=QFontEngine::Format_None, subPixelPosition=..., glyph=<optimized out>, this=0x1158040) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine_ft_p.h:281<br/> #2 QFontEngineFT::recalcAdvances (this=0x1158040, glyphs=0x7fffffffac98, flags=...) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine_ft.cpp:1611<br/> #3 0x00007ffff7528052 in hb_getAdvances (font=<optimized out>, glyphs=0x115f320, numGlyphs=61, advances=0x115f4a0, flags=<optimized out>) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine.cpp:105<br/> #4 0x00007ffff6d4b0f6 in HB_HeuristicPosition (item=item@entry=0x7fffffffb030) at /var/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/harfbuzz/src/harfbuzz-shaper.cpp:441<br/> #5 0x00007ffff6d4cfff in HB_BasicShape (shaper_item=0x7fffffffb030) at /var/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/harfbuzz/src/harfbuzz-shaper.cpp:624<br/> #6 0x00007ffff6d51c03 in HB_ShapeItem (shaper_item=0x7fffffffb030) at /var/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/harfbuzz/src/harfbuzz-shaper.cpp:1419<br/> #7 0x00007ffff7559b20 in QTextEngine::shapeTextWithHarfbuzz (this=this@entry=0x115d270, item=item@entry=0) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextengine.cpp:1342<br/> #8 0x00007ffff755a4b2 in QTextEngine::shapeText (this=this@entry=0x115d270, item=item@entry=0) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextengine.cpp:935<br/> #9 0x00007ffff755a7d5 in QTextEngine::shape (this=this@entry=0x115d270, item=item@entry=0) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextengine.cpp:1450<br/> #10 0x00007ffff756bbaf in QTextLine::layout_helper (this=this@entry=0x7fffffffb970, maxGlyphs=maxGlyphs@entry=2147483647) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextlayout.cpp:1761<br/> #11 0x00007ffff756cb9e in QTextLine::setNumColumns (this=this@entry=0x7fffffffb970, numColumns=numColumns@entry=2147483647) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextlayout.cpp:1550<br/> #12 0x00007ffff756cc05 in QTextLayout::endLayout (this=0x7fffffffba90) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextlayout.cpp:644<br/> #13 0x0000000000431235 in DiffTextWindowData::prepareTextLayout (this=0x1115380, textLayout=..., visibleTextWidth=-1) at difftextwindow.cpp:870<br/> #14 0x000000000042ee37 in DiffTextWindow::getMaxTextWidth (this=0x110f0d0) at difftextwindow.cpp:341<br/> #15 0x0000000000476f8c in KDiff3App::setHScrollBarRange (this=0x8450b0) at pdiff.cpp:428<br/> #16 0x000000000047733a in KDiff3App::resizeDiffTextWindowHeight (this=0x8450b0, newHeight=57) at pdiff.cpp:471<br/> <br/> What do you think?<br/> <br/> Regards,<br/> Maurice.<br/> <br/> --<br/> Maurice van der Pot<br/> <br/> Kdiff3 developer gri...@kf... <a href="http://kdiff3.sourceforge.net" target="_blank">http://kdiff3.sourceforge.net</a><br/> <br/> ------------------------------------------------------------------------------<br/> Dive into the World of Parallel Programming! The Go Parallel Website,<br/> sponsored by Intel and developed in partnership with Slashdot Media, is your<br/> hub for all things parallel software development, from weekly thought<br/> leadership blogs to news, videos, case studies, tutorials and more. Take a<br/> look and join the conversation now. <a href="http://goparallel.sourceforge.net" target="_blank">http://goparallel.sourceforge.net</a>_______________________________________________<br/> Kdiff3-user mailing list<br/> Kdi...@li...<br/> <a href="https://lists.sourceforge.net/lists/listinfo/kdiff3-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/kdiff3-user</a></div> </div> </div> </div></div></body></html> |
|
From: Maurice v. d. P. <gri...@kf...> - 2015-01-11 00:26:50
|
On Mon, Jan 05, 2015 at 06:15:06PM +0100, Joachim Eibl wrote:
> I suppose this is an effect of KDiff3-0.9.98 trying to analyze line
> lengths for variable width fonts, where each character has to be analyzed.
> If KDiff3 becomes responsive again after a long wait and only for long
> files then that is the reason.
Looking at the callgrind output the time is being spent in 1.9M calls of
QFontEngineFT::loadGlyph (for reference, on my machine that function is
only called 358 times).
There are cases where this function is called while
DiffTextWindow::prepareTextLayout is on the call stack, but I find it hard
to tell why the loadGlyph function would be called so often.
prepareTextLayout is called 32K times in his profile and 31K times in
mine.
#0 QFontEngineFT::loadGlyph (this=this@entry=0x1158040, set=set@entry=0x1158128, glyph=2, subPixelPosition=subPixelPosition@entry=..., format=format@entry=QFontEngine::Format_None, fetchMetricsOnly=fetchMetricsOnly@entry=true)
at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine_ft.cpp:816
#1 0x00007ffff75fbf03 in loadGlyph (fetchMetricsOnly=true, format=QFontEngine::Format_None, subPixelPosition=..., glyph=<optimized out>, this=0x1158040) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine_ft_p.h:281
#2 QFontEngineFT::recalcAdvances (this=0x1158040, glyphs=0x7fffffffac98, flags=...) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine_ft.cpp:1611
#3 0x00007ffff7528052 in hb_getAdvances (font=<optimized out>, glyphs=0x115f320, numGlyphs=61, advances=0x115f4a0, flags=<optimized out>) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qfontengine.cpp:105
#4 0x00007ffff6d4b0f6 in HB_HeuristicPosition (item=item@entry=0x7fffffffb030) at /var/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/harfbuzz/src/harfbuzz-shaper.cpp:441
#5 0x00007ffff6d4cfff in HB_BasicShape (shaper_item=0x7fffffffb030) at /var/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/harfbuzz/src/harfbuzz-shaper.cpp:624
#6 0x00007ffff6d51c03 in HB_ShapeItem (shaper_item=0x7fffffffb030) at /var/tmp/portage/dev-qt/qtcore-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/harfbuzz/src/harfbuzz-shaper.cpp:1419
#7 0x00007ffff7559b20 in QTextEngine::shapeTextWithHarfbuzz (this=this@entry=0x115d270, item=item@entry=0) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextengine.cpp:1342
#8 0x00007ffff755a4b2 in QTextEngine::shapeText (this=this@entry=0x115d270, item=item@entry=0) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextengine.cpp:935
#9 0x00007ffff755a7d5 in QTextEngine::shape (this=this@entry=0x115d270, item=item@entry=0) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextengine.cpp:1450
#10 0x00007ffff756bbaf in QTextLine::layout_helper (this=this@entry=0x7fffffffb970, maxGlyphs=maxGlyphs@entry=2147483647) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextlayout.cpp:1761
#11 0x00007ffff756cb9e in QTextLine::setNumColumns (this=this@entry=0x7fffffffb970, numColumns=numColumns@entry=2147483647) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextlayout.cpp:1550
#12 0x00007ffff756cc05 in QTextLayout::endLayout (this=0x7fffffffba90) at /var/tmp/portage/dev-qt/qtgui-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/gui/text/qtextlayout.cpp:644
#13 0x0000000000431235 in DiffTextWindowData::prepareTextLayout (this=0x1115380, textLayout=..., visibleTextWidth=-1) at difftextwindow.cpp:870
#14 0x000000000042ee37 in DiffTextWindow::getMaxTextWidth (this=0x110f0d0) at difftextwindow.cpp:341
#15 0x0000000000476f8c in KDiff3App::setHScrollBarRange (this=0x8450b0) at pdiff.cpp:428
#16 0x000000000047733a in KDiff3App::resizeDiffTextWindowHeight (this=0x8450b0, newHeight=57) at pdiff.cpp:471
What do you think?
Regards,
Maurice.
--
Maurice van der Pot
Kdiff3 developer gri...@kf... http://kdiff3.sourceforge.net
|
|
From: Neal B. <ndb...@gm...> - 2015-01-07 12:39:58
|
Dunno, I could google it. I use kde. Perhaps if you add your question to the bug report (set the option 'need information from ...'), the original reporter can give more information. (I'm just the messenger here). If you still don't get an answer, let me know and I'll look into it. On Tue, Jan 6, 2015 at 4:20 PM, Maurice van der Pot <gri...@kf...> wrote: > On Sun, Jan 04, 2015 at 10:43:13PM +0100, Maurice van der Pot wrote: > > When I get some time I will try to install an old version of fedora in a > > virtual machine. > > Ok, I now have a virtual machine with Fedora 19 and one with Fedora 21, > but I don't see any difference yet in kdiff3's performance. > > Neal, can you give me a hint on how to change the window manager to > WindowMaker after I've installed the package? > > Regards, > Maurice. > > -- > Maurice van der Pot > > Kdiff3 developer gri...@kf... http://kdiff3.sourceforge.net > > -- *Those who don't understand recursion are doomed to repeat it* |
|
From: Maurice v. d. P. <gri...@kf...> - 2015-01-06 21:20:36
|
On Sun, Jan 04, 2015 at 10:43:13PM +0100, Maurice van der Pot wrote: > When I get some time I will try to install an old version of fedora in a > virtual machine. Ok, I now have a virtual machine with Fedora 19 and one with Fedora 21, but I don't see any difference yet in kdiff3's performance. Neal, can you give me a hint on how to change the window manager to WindowMaker after I've installed the package? Regards, Maurice. -- Maurice van der Pot Kdiff3 developer gri...@kf... http://kdiff3.sourceforge.net |
|
From: Joachim E. <Joa...@gm...> - 2015-01-05 17:15:14
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi Neal,</div> <div> </div> <div>I suppose this is an effect of KDiff3-0.9.98 trying to analyze line lengths for variable width fonts, where each character has to be analyzed.</div> <div>If KDiff3 becomes responsive again after a long wait and only for long files then that is the reason.</div> <div> </div> <div>I indend to implement a better heuristic in the next version so not all lines have to be analyzed (except when word-wrap is on).</div> <div> </div> <div>My original intention was to make this long analysis abortable, but this slipped through.</div> <div> </div> <div>If you have a modern machine with many cores then the task will be distributed evenly on all cores, so these users would only notice a slowdown for much larger files.</div> <div>Specifying the type of machine in the bug-report would be helpful.</div> <div> </div> <div> <div>Best regards,</div> <div>Joachim</div> <div> </div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Sonntag, 04. Januar 2015 um 20:31 Uhr<br/> <b>Von:</b> "Neal Becker" <ndb...@gm...><br/> <b>An:</b> kdi...@li...<br/> <b>Betreff:</b> [Kdiff3-user] kdiff3 consumes 100% cpu, seems hung</div> <div name="quoted-content"> <div>Any thoughts on this bug report? <div> <div><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1175257" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1175257</a></div> <div> </div> <div> </div> -- <div class="gmail_signature"> <div><i>Those who don't understand recursion are doomed to repeat it</i></div> </div> </div> </div> ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. <a href="http://goparallel.sourceforge.net" target="_blank">http://goparallel.sourceforge.net</a>_______________________________________________ Kdiff3-user mailing list Kdi...@li... <a href="https://lists.sourceforge.net/lists/listinfo/kdiff3-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/kdiff3-user</a></div> </div> </div> </div></div></body></html> |
|
From: Maurice v. d. P. <gri...@kf...> - 2015-01-04 22:01:41
|
On Sun, Jan 04, 2015 at 02:31:40PM -0500, Neal Becker wrote: > Any thoughts on this bug report? I responded to this bug report because of your earlier mail to this list. What would help me to debug this problem is access to a version that doesn't have the problem and runs on my non-KDE system, so I can tell if it is a regression or a problem that has always been in there. It will also allow me to check if it's in kdiff3 or not, because if I build an old version from source on my system it performs similarly to kdiff3-qt-0.9.98. When I get some time I will try to install an old version of fedora in a virtual machine. In the mean time, if anyone can provide any of the following this would be great: - two files that show this problem - startup duration of the good version vs startup duration of the bad one - a version of kdiff3-qt that doesn't have the problem Regards, Maurice. -- Maurice van der Pot Kdiff3 developer gri...@kf... http://kdiff3.sourceforge.net |
|
From: Neal B. <ndb...@gm...> - 2015-01-04 19:31:47
|
Any thoughts on this bug report? https://bugzilla.redhat.com/show_bug.cgi?id=1175257 -- *Those who don't understand recursion are doomed to repeat it* |
|
From: Neal B. <ndb...@gm...> - 2014-12-17 14:24:45
|
Can anyone comment on this bug report? https://bugzilla.redhat.com/show_bug.cgi?id=1175257 -- *Those who don't understand recursion are doomed to repeat it* |
|
From: Konstantin S. <fr...@gm...> - 2014-10-21 01:48:13
|
Hi, With new version of kdiff, whitespace changes are no longer limited to changes-only -- that's a lost feature Another issue is that whitespace color is same as text color, which makes it hard to read the document. Displaying whitespaces is a great idea, but they should stand out by having a different color (I usually use black for text, light gray for whitespaces) Please add this functionality |
|
From: jeff k. <ki...@gm...> - 2014-09-30 13:35:16
|
Hi. I just installed kdiff on my own pc and it is quite nice thought I would like to see a certain feature, but I’ll leave that for a future moment. I’d like to know if there is an unzip install as I mostly use an overly protected pc provided by my customer which prevents me from installing software (very frustrating as someone who customizes software for a living). I won’t be able to do anything to the registry (windows environment.. 7) so I’ll miss out on the context menus. Just thought I’d ask Thanks for your time and I apologize if its painfully obvious already. Jeff |
|
From: Joachim E. <Joa...@gm...> - 2014-08-24 01:21:05
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Hi Maurice,</div> <div> </div> <div>This looks very promising.</div> <div>I also looked into the moveup changes but can't yet tell what implications it might have.</div> <div>But I'll do some tests myself too.</div> <div> </div> <div>Yet I must warn you that I currently find very little time to work on kdiff3.</div> <div> </div> <div>Best regards,</div> <div>Joachim</div> <div> </div> <div> </div> <div> </div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Donnerstag, 21. August 2014 um 02:07 Uhr<br/> <b>Von:</b> "Maurice van der Pot" <gri...@kf...><br/> <b>An:</b> "Joachim Eibl" <Joa...@gm...><br/> <b>Cc:</b> kdi...@li...<br/> <b>Betreff:</b> Alignment algorithm improvements! (was: Large set of testdata for alignmenttest)</div> <div name="quoted-content">On Tue, Aug 19, 2014 at 07:27:35PM +0200, Maurice van der Pot wrote:<br/> > 3) generate test data systematically<br/> > Disadvantage: the data set gets big really quickly if you cover all<br/> > possible combinations of lines, even for small fragments<br/> > 4) generate test data from real-life merges<br/> > Disadvantage: the data gets big even more quickly than with 3,<br/> > because there is a lot of overlap in which merged file tests which<br/> > behaviour of kdiff3 and each file contains many lines that are<br/> > irrelevant to the test<br/> <br/> I went ahead and implemented both 3 and 4. Both scripts are included in<br/> the merge request I created on sourceforge:<br/> <a href="https://sourceforge.net/p/kdiff3/code/merge-requests/2/" target="_blank">https://sourceforge.net/p/kdiff3/code/merge-requests/2/</a><br/> <br/> <br/> This test set was a prerequisite for some improvements on the alignment<br/> algorithm that I have done and which I am pretty excited about!<br/> (see my moveup branch on sourceforge:<br/> <a href="https://sourceforge.net/u/griffon26/kdiff3/ci/moveup/tree/" target="_blank">https://sourceforge.net/u/griffon26/kdiff3/ci/moveup/tree/</a>)<br/> <br/> <br/> The test sets have allowed me to not only catch mistakes I made during<br/> the implementation of the improvements, but also found one or two<br/> deficiencies in the existing code. Once I fixed those the alignment<br/> even improved a little more.<br/> <br/> <br/> The testdata I used was generated with:<br/> generate_testdata_from_permutations.py -r 7 -s 0<br/> <br/> The differences became:<br/> <a href="http://www.kfk4ever.com/~griffon26/alignment_changes_after_moveup.txt" target="_blank">http://www.kfk4ever.com/~griffon26/alignment_changes_after_moveup.txt</a><br/> In this output the actual result is the output of the code with my improvements<br/> (my moveup branch), while 'expected result' is the output of the original code<br/> (my alignmenttest branch).<br/> <br/> I have obviously not checked the results of all test cases, but the<br/> samples I took looked like pure improvements. One example:<br/> <br/> Running test with testdata/permutations/perm_02739_*.txt... NOK<br/> Actual result (written to testdata/permutations/perm_02739_actual_result.txt):<br/> ----------------------------------------------------------------------------------------------<br/> 0 aaa 0 aaa 0 aaa<br/> 1 bbb 1 bbb<br/> 2 ccc 1 ccc<br/> 2 ddd 3 xxxddd 2 ddd<br/> 4 eee<br/> 3 5 3<br/> ----------------------------------------------------------------------------------------------<br/> Expected result:<br/> ----------------------------------------------------------------------------------------------<br/> 0 aaa 0 aaa 0 aaa<br/> 1 bbb 1 bbb<br/> 2 ddd 2 ccc 1 ccc<br/> 3 xxxddd 2 ddd<br/> 4 eee<br/> 3 5 3<br/> ----------------------------------------------------------------------------------------------<br/> <br/> As you can see in the old version ddd in file A was not aligned with ddd in file C.<br/> The new version fixes this.<br/> <br/> I also ran the new code against test data generated from the linux kernel git repo.<br/> I checked a handful of the differences there and they were also either<br/> improvements or neutral changes.<br/> <br/> <br/> Hoping to hear from you soon,<br/> <br/> Maurice.<br/> <br/> --<br/> Maurice van der Pot<br/> <br/> Gnome Planner Developer gri...@kf... <a href="http://live.gnome.org/Planner" target="_blank">http://live.gnome.org/Planner</a><br/> </div> </div> </div> </div></div></body></html> |
|
From: Francis G. <fr...@ho...> - 2014-08-23 02:25:22
|
Date: Thu, 21 Aug 2014 02:07:51 +0200 From: gri...@kf... To: Joa...@gm... CC: kdi...@li... Subject: [Kdiff3-user] Alignment algorithm improvements! (was: Large set of testdata for alignmenttest) > I have obviously not checked the results of all test cases, but the > samples I took looked like pure improvements. One example: > > Running test with testdata/permutations/perm_02739_*.txt... NOK > Actual result (written to testdata/permutations/perm_02739_actual_result.txt): > ---------------------------------------------------------------------------------------------- > 0 aaa 0 aaa 0 aaa > 1 bbb 1 bbb > 2 ccc 1 ccc > 2 ddd 3 xxxddd 2 ddd > 4 eee > 3 5 3 > ---------------------------------------------------------------------------------------------- > Expected result: > ---------------------------------------------------------------------------------------------- > 0 aaa 0 aaa 0 aaa > 1 bbb 1 bbb > 2 ddd 2 ccc 1 ccc > 3 xxxddd 2 ddd > 4 eee > 3 5 3 > ---------------------------------------------------------------------------------------------- > > As you can see in the old version ddd in file A was not aligned with ddd in file C. > The new version fixes this. I've had this happen to me. It's easy enough to add manual alignment markers... unless there's no corresponding line to mark in the other file (file B here)! Francis Gagné |
|
From: Maurice v. d. P. <gri...@kf...> - 2014-08-21 00:07:59
|
On Tue, Aug 19, 2014 at 07:27:35PM +0200, Maurice van der Pot wrote: > 3) generate test data systematically > Disadvantage: the data set gets big really quickly if you cover all > possible combinations of lines, even for small fragments > 4) generate test data from real-life merges > Disadvantage: the data gets big even more quickly than with 3, > because there is a lot of overlap in which merged file tests which > behaviour of kdiff3 and each file contains many lines that are > irrelevant to the test I went ahead and implemented both 3 and 4. Both scripts are included in the merge request I created on sourceforge: https://sourceforge.net/p/kdiff3/code/merge-requests/2/ This test set was a prerequisite for some improvements on the alignment algorithm that I have done and which I am pretty excited about! (see my moveup branch on sourceforge: https://sourceforge.net/u/griffon26/kdiff3/ci/moveup/tree/) The test sets have allowed me to not only catch mistakes I made during the implementation of the improvements, but also found one or two deficiencies in the existing code. Once I fixed those the alignment even improved a little more. The testdata I used was generated with: generate_testdata_from_permutations.py -r 7 -s 0 The differences became: http://www.kfk4ever.com/~griffon26/alignment_changes_after_moveup.txt In this output the actual result is the output of the code with my improvements (my moveup branch), while 'expected result' is the output of the original code (my alignmenttest branch). I have obviously not checked the results of all test cases, but the samples I took looked like pure improvements. One example: Running test with testdata/permutations/perm_02739_*.txt... NOK Actual result (written to testdata/permutations/perm_02739_actual_result.txt): ---------------------------------------------------------------------------------------------- 0 aaa 0 aaa 0 aaa 1 bbb 1 bbb 2 ccc 1 ccc 2 ddd 3 xxxddd 2 ddd 4 eee 3 5 3 ---------------------------------------------------------------------------------------------- Expected result: ---------------------------------------------------------------------------------------------- 0 aaa 0 aaa 0 aaa 1 bbb 1 bbb 2 ddd 2 ccc 1 ccc 3 xxxddd 2 ddd 4 eee 3 5 3 ---------------------------------------------------------------------------------------------- As you can see in the old version ddd in file A was not aligned with ddd in file C. The new version fixes this. I also ran the new code against test data generated from the linux kernel git repo. I checked a handful of the differences there and they were also either improvements or neutral changes. Hoping to hear from you soon, Maurice. -- Maurice van der Pot Gnome Planner Developer gri...@kf... http://live.gnome.org/Planner |
|
From: Maurice v. d. P. <gri...@kf...> - 2014-08-19 17:27:43
|
Hi Joachim and others, tl;dr: I'm asking for some ideas on how to get a good test set for the diff/alignment algorithm of kdiff3. A while ago I wrote the alignmenttest in the test directory. This test checks how kdiff3 arranges the lines of 3 files in a three-way diff/merge, so which parts of the file it decides to put next to each other. This is a test that can be useful for catching regressions when making changes to the alignment algorithm, but only if there is a large enough test set available. I've been thinking about how to create such a test set, but would like to gather some feedback. I can think of a few ways to create such a set: 1) manually create test cases based on the decisions that kdiff3 makes throughout this algorithm Disadvantage: this is a lot of work. Also it is not easy to construct input and expected output that will trigger a specified outcome of a decision that is made on an intermediate representation in the code 2) compose it from merges that showed problems in kdiff3's behaviour. Disadvantage: it takes a *looooong* time before you get decent coverage 3) generate test data systematically Disadvantage: the data set gets big really quickly if you cover all possible combinations of lines, even for small fragments 4) generate test data from real-life merges Disadvantage: the data gets big even more quickly than with 3, because there is a lot of overlap in which merged file tests which behaviour of kdiff3 and each file contains many lines that are irrelevant to the test The first problem with large test sets is that you will not want to check them in and distribute them with the source code of kdiff3. The second is that a change in the algorithm likely affects a *lot* of test cases, so you'll spend a lot of time looking through the test cases that have started failing to see if the new behaviour is better than the old. However, I do think there's still value in 3, where the effort of investigating new failures is much lower per test case than with 4. The 'input' data can be generated with a simple script. The 'expected output' must be generated with the alignmenttest executable of a "known good" kdiff3 version. Can anyone come up with better/alternative ideas for creating test data? Regards, Maurice. P.S.: I have scripts for 3 and 4, so if anyone wants them just ask. The script for 4 finds merge commits in an arbitrary git repository (I used the linux kernel repo), gets the files that were merged in these commits and saves them to a format suitable for the alignmenttest. -- Maurice van der Pot Gnome Planner Developer gri...@kf... http://live.gnome.org/Planner |
12 messages has been excluded from this view by a project administrator.
