From: P Z. <zol...@gm...> - 2010-01-20 22:29:50
|
Hi, I've started writing a testbench for the math classes in ktechlab [1]. At the attempt of compiling an error popped up, complaining about some declarations in kdebug.h [2]. The latter one is part of KDE, AFAIK version 3, so that is an issue here. The question is, what should be done? Port the code to KDE4 or use standard (or Qt's) output methdos, which remove the dependency of math related classes on KDE (this is the logical way for me). When something works, I'll push it to git; also change the files in SVN? What's your opinion? Zoltan [1] matrix.cpp matrix.h qmatrix.cpp qmatrix.h qvector.cpp qvector.h [2] /usr/include/kdebug.h:183: error: declaration of \u2018operator<<\u2019 as non-function /usr/include/kdebug.h:183: error: expected \u2018;\u2019 before \u2018(\u2019 token /usr/include/kdebug.h:193: error: expected `;' before \u2018kdbgstream\u2019 /usr/include/kdebug.h:193: error: declaration of \u2018operator<<\u2019 as non-function /usr/include/kdebug.h:193: error: expected \u2018;\u2019 before \u2018(\u2019 token /usr/include/kdebug.h:202: error: expected `;' before \u2018void\u2019 /usr/include/kdebug.h:240: error: expected \u2018,\u2019 or \u2018...\u2019 before \u2018&\u2019 token /usr/include/kdebug.h:240: error: \u2018kdbgstream& kdbgstream::operator<<(int)\u2019 cannot be overloaded /usr/include/kdebug.h:143: error: with \u2018kdbgstream& kdbgstream::operator<<(int)\u2019 |
From: Alan G. <ag...@sp...> - 2010-01-20 22:59:06
|
P Zoltan wrote: > Hi, > > > I've started writing a testbench for the math classes in ktechlab [1]. At > the attempt of compiling an error popped up, complaining about some > declarations in kdebug.h [2]. The latter one is part of KDE, AFAIK version > 3, so that is an issue here. > The question is, what should be done? Port the code to KDE4 or use > standard (or Qt's) output methdos, which remove the dependency of math > related classes on KDE (this is the logical way for me). > When something works, I'll push it to git; also change the files in SVN? > What's your opinion? I wrote my own test for that and used it to hunt down a few bugs... Look for a file called mathtest.cpp in the directory "testing". -- DO NOT USE OBAMACARE. DO NOT BUY OBAMACARE. Powers are not rights. |
From: Julian B. <ju...@sv...> - 2010-01-21 02:10:49
|
On Wednesday 20 January 2010 23:49:04 Alan Grimes wrote: > I wrote my own test for that and used it to hunt down a few bugs... > > Look for a file called mathtest.cpp in the directory "testing". Yeah, I'd suggest to reuse that code in the new tests. |
From: Julian B. <ju...@sv...> - 2010-01-21 02:09:42
|
On Thursday 21 January 2010 01:30:30 P Zoltan wrote: > I've started writing a testbench for the math classes in ktechlab [1]. At > the attempt of compiling an error popped up, complaining about some > declarations in kdebug.h [2]. The latter one is part of KDE, AFAIK version > 3, so that is an issue here. Yes, it's KDE3.. Seems, you are trying to print something of the wrong type here. You need to overload the stream operator for that type (if it's not a KDE/Qt type) to use it with kdDebug(). I've never done that, so you should consult the Qt documentation (kdDebug() should behave similar to qDebug() in this matter) > The question is, what should be done? Port the code to KDE4 or use > standard (or Qt's) output methdos, which remove the dependency of math > related classes on KDE (this is the logical way for me). > When something works, I'll push it to git; also change the files in SVN? > > What's your opinion? I'd suggest the following: Since you need to implement the test-cases, anyway. Why not doing it using Qts testing framework. You can use the recent API of the math classes and implement it as Qt4 test-cases. You might want to borrow some ideas and code from some of KDEs test-cases (may be KDevPlatform test- cases would be a good start). You should do all that on a local copy of the kde4-port branch in my repository. I can help creating cmake code to automatically run the tests. After finishing the tests, or during writing them.. or whenever, the math-classes should be ported to use KDE4/Qt4 classes. Since KDE will be a dependency anyway, I don't see the point, why we shouldn't use it. Do we really want to make parts of the project independent from KDE/Qt? I don't know of any projects, other then KTechLab, that could re-use our code. kDebug() from KDE4 has quite some nice features, so I always use it when printing debug-output. It's easily possible to hide/show debug-output from different components, during runtime. (see kdebugdialog) And it will not produce any object code when compiled in release mode. So there are 2 benefits when writing the tests for KDE/Qt4: (1) we got some nice test cases and can automatically run them from cmake (2) math-related classes are ported to Qt4 and can be used, soon I don't think, we should invest much of our time into creating new code for the kde3 version, any longer. > [2] > /usr/include/kdebug.h:183: error: declaration of \u2018operator<<\u2019 as > non-function > /usr/include/kdebug.h:183: error: expected \u2018;\u2019 before > \u2018(\u2019 token > /usr/include/kdebug.h:193: error: expected `;' before > \u2018kdbgstream\u2019 > /usr/include/kdebug.h:193: error: declaration of \u2018operator<<\u2019 as > non-function > /usr/include/kdebug.h:193: error: expected \u2018;\u2019 before > \u2018(\u2019 token > /usr/include/kdebug.h:202: error: expected `;' before \u2018void\u2019 > /usr/include/kdebug.h:240: error: expected \u2018,\u2019 or > \u2018...\u2019 before \u2018&\u2019 token > /usr/include/kdebug.h:240: error: \u2018kdbgstream& > kdbgstream::operator<<(int)\u2019 cannot be overloaded > /usr/include/kdebug.h:143: error: with \u2018kdbgstream& > kdbgstream::operator<<(int)\u2019 bye then julian |
From: Julian B. <ju...@sv...> - 2010-01-21 03:16:20
|
On Thursday 21 January 2010 02:42:21 Julian Bäume wrote: > On Thursday 21 January 2010 01:30:30 P Zoltan wrote: > > I've started writing a testbench for the math classes in ktechlab [1]. > You should do all that > on a local copy of the kde4-port branch in my repository. I can help > creating cmake code to automatically run the tests. After finishing the > tests, or during writing them.. or whenever, the math-classes should be > ported to use KDE4/Qt4 classes. Well, I couldn't keep my hands of it and just pushed some guiding code into the kde4-port branch. I have a local branch named kde4-unittests, and merged some changes into kde4-port branch to provide a starting point for the tests. Just have a look into the tests directory. Since src/math/* doesn't depend on Qt nor KDE, there was nearly no need to port anything. I needed to export some symbols, so some changes were needed, but these are minor ones (see commit messages). This was necessary to link against libktlmath.so from the test program. I enabled the build of tests, so the tests should be build with the project. Run "make test" to run the tests. (For now, there is only one test) You can run single tests by manually running the *.shell files in the build directory. (see the tests/math subdir). You need to run the .shell files to make sure the shared libraries from the build directory are used instead of any installed ones. Well, I should go to bed, now ;) bye then julian |
From: P Z. <zol...@gm...> - 2010-01-21 09:36:39
|
On Thu, 21 Jan 2010 02:42:21 +0100, Julian Bäume <ju...@sv...> wrote: > On Thursday 21 January 2010 01:30:30 P Zoltan wrote: > Yes, it's KDE3.. Seems, you are trying to print something of the wrong > type > here. You need to overload the stream operator for that type (if it's > not a > KDE/Qt type) to use it with kdDebug(). I've never done that, so you > should > consult the Qt documentation (kdDebug() should behave similar to > qDebug() in > this matter) > This is strange: as you mentioned in the next mail, there was almost nothing to port in /src/math, but the only thing I've done was to copy /src/math from svn (~ rev. 550 ?), and try to compile them only with Qt. >> The question is, what should be done? Port the code to KDE4 or use >> standard (or Qt's) output methdos, which remove the dependency of math >> related classes on KDE (this is the logical way for me). >> When something works, I'll push it to git; also change the files in >> SVN? >> >> What's your opinion? > I'd suggest the following: Since you need to implement the test-cases, > anyway. > Why not doing it using Qts testing framework. You can use the recent API > of > the math classes and implement it as Qt4 test-cases. You might want to > borrow > some ideas and code from some of KDEs test-cases (may be KDevPlatform > test- > cases would be a good start). You should do all that on a local copy of > thestillkde4-port branch in my repository. I can help creating cmake > code to > automatically run the tests. After finishing the tests, or during writing > them.. or whenever, the math-classes should be ported to use KDE4/Qt4 > classes. > > Since KDE will be a dependency anyway, I don't see the point, why we > shouldn't > use it. Do we really want to make parts of the project independent from > KDE/Qt? I don't know of any projects, other then KTechLab, that could > re-use > our code. kDebug() from KDE4 has quite some nice features, so I always > use it > when printing debug-output. It's easily possible to hide/show > debug-output > from different components, during runtime. (see kdebugdialog) And it > will not > produce any object code when compiled in release mode. > > So there are 2 benefits when writing the tests for KDE/Qt4: > (1) we got some nice test cases and can automatically run them from cmake > (2) math-related classes are ported to Qt4 and can be used, soon > Actually I was following Qt4's testing tutorial. I've generated a project and makefile with qmake-qt4, so it didn't include any KDE stuff. That's why I've got the error. I want to create tests using qt's infrastructure, as it looks really nice and simple. Thank you for cmake files, as those are a bit complicated for me, yet. I'll check out all the repositories and make something working, probabily until sunday. > I don't think, we should invest much of our time into creating new code > for > the kde3 version, any longer. Agreed. |
From: Julian B. <ju...@sv...> - 2010-01-21 20:21:11
|
On Thursday 21 January 2010 12:37:19 P Zoltan wrote: > On Thu, 21 Jan 2010 02:42:21 +0100, Julian Bäume <ju...@sv...> wrote: > > On Thursday 21 January 2010 01:30:30 P Zoltan wrote: > > Yes, it's KDE3.. Seems, you are trying to print something of the wrong > > type > > here. You need to overload the stream operator for that type (if it's > > not a > > KDE/Qt type) to use it with kdDebug(). I've never done that, so you > > should > > consult the Qt documentation (kdDebug() should behave similar to > > qDebug() in > > this matter) > This is strange: as you mentioned in the next mail, there was almost > nothing to port in /src/math, but the only thing I've done was to copy > /src/math from svn (~ rev. 550 ?), and try to compile them only with Qt. Yes, I mentioned that, too. ;) And it's fine for me not to depend on Qt for those classes. But we should also remove output to stdout from these classes. There are a few methods, printing to stdout. Are they really needed at runtime? Or are they for debugging purposes, only. In the later case, we should switch to kDebug() or kWarning(), to make sure end-users only see important output. If these methods are only used for testing and debugging mode, these methods should move into the test-case. (And also not pollute the users stdout) > Actually I was following Qt4's testing tutorial. I've generated a project > and makefile with qmake-qt4, so it didn't include any KDE stuff. That's > why I've got the error. I want to create tests using qt's infrastructure, > as it looks really nice and simple. Yeah. That should be enough. The tests are stand-alone programs anyway. So it doesn't matter much, which libraries you link against. bye then julian |
From: P Z. <zol...@gm...> - 2010-01-23 22:49:38
|
On Wed, 20 Jan 2010 23:49:04 +0100, Alan Grimes <ag...@sp...> wrote: > I wrote my own test for that and used it to hunt down a few bugs... > > Look for a file called mathtest.cpp in the directory "testing". > Basically that's what I've wanted to do in the matrix test. Meanwhile I've found a huge problem with the qvector header: Qt has a header with the same. And it also tests inside if QVECTOR_H is defined. So I've got several very strange build errors... Due to this, I've renamed the math files to quickvector and quickmatrix. The original error was due to kdebug.h being included. It wasn't used anywhere. Just pushed some tests in my git repository, in the branch testing-1, folder matrixtest. The tests consist of generating random matrixes and making operations on them. The results are compared with Eigen's implementation. Bulding the test: enter the build directory, then with "qmake-qt4" command generate the Makefile; type make, and get a "build" executable. Running the executable is equivalend of running the tests. Have fun, Zoltan |
From: Julian B. <ju...@sv...> - 2010-01-26 10:38:28
|
On Sunday 24 January 2010 01:50:34 P Zoltan wrote: > Meanwhile I've found a huge problem with the qvector header: Qt has a > header with the same. And it also tests inside if QVECTOR_H is defined. So > I've got several very strange build errors... Due to this, I've renamed > the math files to quickvector and quickmatrix. Eeks, that's indeed a problem ;) another solution would have been to use a proper namespace for that. But I'm fine with renaming the files, also. > The original error was due to kdebug.h being included. It wasn't used > anywhere. > > Just pushed some tests in my git repository, in the branch testing-1, > folder matrixtest. > > Bulding the test: enter the build directory, then with "qmake-qt4" > command generate the Makefile; type make, and get a "build" executable. > Running the executable is equivalend of running the tests. Let me comment on your work. At first, it didn't compile for me. quickvector.cpp uses memset, which is declared in <cstring>. After including it, it compiles and runs fine. Next step would be to integrate this into the kde4-port branch. This should be done without the eigen sources. We should just add a (soft) dependency to eigen for the tests. And built the test, when eigen is found. I could do that in the cmake files. Shouldn't be much of a problem. Then we should merge your changes to the maths classes into the kde4-port branch. Another minor issue, i mentioned, while reading the patches (git log -p). There are a lot of trailing white-spaces in your code. Your should try to avoid them. What editor are you using? Kate can be configured to visualise trailing-white-space and automatically remove them on save. Same counts for vim. You can also see these in git diff (before commit, just have a short look into the diff). You need to do some git configuration to see it, though: color.ui=true core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol core.pager=less -FXRS I think, these options should do the trick. Well :) enough for now. bye then julian |
From: P Z. <zol...@gm...> - 2010-02-04 05:32:05
|
On Tue, 26 Jan 2010 11:28:47 +0100, Julian Bäume <ju...@sv...> wrote: > On Sunday 24 January 2010 01:50:34 P Zoltan wrote: >> Meanwhile I've found a huge problem with the qvector header: Qt has a >> header with the same. And it also tests inside if QVECTOR_H is defined. >> So >> I've got several very strange build errors... Due to this, I've renamed >> the math files to quickvector and quickmatrix. > Eeks, that's indeed a problem ;) another solution would have been to use > a > proper namespace for that. But I'm fine with renaming the files, also. > The problem is that namespace won't help with defines. Anyway, it works now. > Let me comment on your work. At first, it didn't compile for me. > quickvector.cpp uses memset, which is declared in <cstring>. After > including > it, it compiles and runs fine. Added it to the repository. I'll upload it soon. > > Next step would be to integrate this into the kde4-port branch. This > should be > done without the eigen sources. We should just add a (soft) dependency to > eigen for the tests. And built the test, when eigen is found. I could do > that > in the cmake files. Shouldn't be much of a problem. Then we should merge > your > changes to the maths classes into the kde4-port branch. The situation is that Eigen is purely header-based implementation; it has no lib to link against. All the classes are built inside the final program (this allows serious optimisations). So the chances of having Eigen sources at somebody's system are very close to zero. I consider a waste of time to separately download Eigen and set its path. As now I consider the tests good-enough, I'll try to integrate it with the rest. The next interesting operation should be creating a test for the document and simulator, together, so simple circuits can be tested. If those tests are ready, we could try to integrate the simulator with the qt4 port; the problems should be revealed fast by using the testcases. > > Another minor issue, i mentioned, while reading the patches (git log -p). > There are a lot of trailing white-spaces in your code. Your should try to > avoid them. What editor are you using? Kate can be configured to > visualise > trailing-white-space and automatically remove them on save. Same counts > for > vim. You can also see these in git diff (before commit, just have a > short look > into the diff). You need to do some git configuration to see it, though: > > color.ui=true > core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol > core.pager=less -FXRS > > I think, these options should do the trick. I should check those configurations; also learning git more deeper would be necessary, as there are some open questions for me, like how to remove a file from a planned commit (in case of an accidental git add); also how to keep track of remote branches and push / pull from them in an efficient manner. All these should be described in the wiki. Also an idiot-proof git checkout guide is needed, as there is some working code in the repository. Another question about sourceforge: is there any read-only access mode with uses some more common port? git:// port seems blocked from me, so I have to use ssh in order to download the changes; that's not very convenient for me. About the trailing spaces: I created them by using gedit :D Now I'll start using kate; hopefully the visibility of the trailing spaces will reduce the number of such problems. > > Well :) enough for now. > > bye then > julian Zoltan |
From: P Z. <zol...@gm...> - 2010-02-14 11:27:16
|
On Thu, 21 Jan 2010 04:15:43 +0100, Julian Bäume <ju...@sv...> wrote: > On Thursday 21 January 2010 02:42:21 Julian Bäume wrote: >> On Thursday 21 January 2010 01:30:30 P Zoltan wrote: >> > I've started writing a testbench for the math classes in ktechlab >> [1]. >> You should do all that >> on a local copy of the kde4-port branch in my repository. I can help >> creating cmake code to automatically run the tests. After finishing the >> tests, or during writing them.. or whenever, the math-classes should be >> ported to use KDE4/Qt4 classes. > Well, I couldn't keep my hands of it and just pushed some guiding code > into > the kde4-port branch. I have a local branch named kde4-unittests, and > merged > some changes into kde4-port branch to provide a starting point for the > tests. > Just have a look into the tests directory. Since src/math/* doesn't > depend on > Qt nor KDE, there was nearly no need to port anything. I needed to > export some > symbols, so some changes were needed, but these are minor ones (see > commit > messages). This was necessary to link against libktlmath.so from the test > program. > > I enabled the build of tests, so the tests should be build with the > project. > Run "make test" to run the tests. (For now, there is only one test) You > can > run single tests by manually running the *.shell files in the build > directory. > (see the tests/math subdir). You need to run the .shell files to make > sure the > shared libraries from the build directory are used instead of any > installed > ones. > There is some problem with my system -- I can't get the circuit documents in my build. The plugins are built and installed in a folder in my home directory, but it looks like they aren't loaded. How could I debug this problem? In the menu: settings -> configure ktechlab -> plugins, I can't see any plugin related to ktechlab. > Well, I should go to bed, now ;) > > bye then > julian > |
From: Julian B. <ju...@sv...> - 2010-02-14 14:04:01
|
hey, On Sunday 14 February 2010 14:29:13 P Zoltan wrote: > There is some problem with my system -- I can't get the circuit documents > in my build. The plugins are built and installed in a folder in my home > directory, but it looks like they aren't loaded. How could I debug this > problem? In the menu: settings -> configure ktechlab -> plugins, I can't > see any plugin related to ktechlab. Did you run kbuildsycoca4 after make install? This is needed for the KPluginLoader to recognise the installed desktop file to know about the plugins you installed. You also need to set the environment variables to also contain your local ktechlab installation (this is needed for kbuildsycoca4 to find the desktop file and stuff like that) I described that in the wiki: https://sourceforge.net/apps/mediawiki/ktechlab/index.php?title=Compiling_the_source Just scroll to the bottom of the page.. If this doesn't help, run kdebugdialog and select debug from KPluginLoader and kdevplatform (shell). After that you should be able to see the problem in the output in a terminal. Just a short introductions how plugins work: You create a shared library and a .desktop file. This contains meta-data to describe your plugin, the shared library, of course, contains object code. After that KDE needs to be aware of that plugin. This is done by kbuildsycoca4. Then you will be able to load the .so files with KPluginLoader. Since we use KDevPlatforms plugin system, this is even more easy. You can ask the KDevelop::PluginLoader to load plugins. There are some ways to describe, which plugins you want to load. But more about that later. bye then julian |
From: P Z. <zol...@gm...> - 2010-02-14 17:40:41
|
On Sun, 14 Feb 2010 14:36:10 +0100, Julian Bäume <ju...@sv...> wrote: > hey, > > Did you run kbuildsycoca4 after make install? This is needed for the > KPluginLoader to recognise the installed desktop file to know about the > plugins you installed. You also need to set the environment variables to > also > contain your local ktechlab installation (this is needed for > kbuildsycoca4 to > find the desktop file and stuff like that) I described that in the wiki: > https://sourceforge.net/apps/mediawiki/ktechlab/index.php?title=Compiling_the_source > Just scroll to the bottom of the page.. Okay, now I have the ktechlab plugins in that list. Still, after activating them, I can't open or create new circuit. What should be done to see something? > > If this doesn't help, run kdebugdialog and select debug from > KPluginLoader and > kdevplatform (shell). After that you should be able to see the problem > in the > output in a terminal. If course I have only the kde3 version installed. But as I've read on the web, it just edits ~/.kde4/share/config/kdebugrc . So a "full debug" version of that file should be enough. > > Just a short introductions how plugins work: > You create a shared library and a .desktop file. This contains meta-data > to > describe your plugin, the shared library, of course, contains object > code. > After that KDE needs to be aware of that plugin. This is done by > kbuildsycoca4. Then you will be able to load the .so files with > KPluginLoader. > Since we use KDevPlatforms plugin system, this is even more easy. You > can ask > the KDevelop::PluginLoader to load plugins. There are some ways to > describe, > which plugins you want to load. But more about that later. > > bye then > julian |
From: Julian B. <ju...@sv...> - 2010-02-15 04:03:20
|
On Sunday 14 February 2010 20:42:39 P Zoltan wrote: > On Sun, 14 Feb 2010 14:36:10 +0100, Julian Bäume <ju...@sv...> wrote: > > Did you run kbuildsycoca4 after make install? This is needed for the > > KPluginLoader to recognise the installed desktop file to know about the > > plugins you installed. You also need to set the environment variables to > > also > > contain your local ktechlab installation (this is needed for > > kbuildsycoca4 to > > find the desktop file and stuff like that) I described that in the wiki: > > https://sourceforge.net/apps/mediawiki/ktechlab/index.php?title=Compiling > > _the_source Just scroll to the bottom of the page.. > > Okay, now I have the ktechlab plugins in that list. Still, after > activating them, I can't open or create new circuit. What should be done > to see something? For now, I only implemented loading circuit files and importing projects. There is some code in ktl-project branch, which is able to add and remove files in the project, but I had some problems with it, so I haven't merged it into kde4-port, yet. If you open a circuit file, there should at least happen something. If no plugin handling circuit files can be found, you will get an error message and will be asked, if you want to open the file as plain text. If the plugin is found, it should load the circuit file. SVG files for most of the components are shipped, so you should see most of the circuit. If you don't see any components (only the "wires"), there is a problem with basic_ec plugin. I fixed some issues in there, so you might want to update your tree. If error messages complaining about missing plugins pop up, make sure plugins are loaded. If they don't show up in the Plugin-list, re-run kbuildsycoca4. At the moment, only the Circuit plugin should show up in the list, all others are loaded as so-called "project" plugins. This is done in the background. Well, I hope this helped a bit.. bye then julian |