Menu
▾
▴
cppqed-support — Bugs, questions, feature requests, etc.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(5) |
Jun
|
Jul
|
Aug
(17) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(1) |
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(18) |
Dec
(10) |
| 2014 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(11) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Raimar S. <rai...@ui...> - 2014-01-07 11:16:27
|
On Tuesday, January 07, 2014 11:38:15 Andras Vukics wrote: > Hi Raimar, > > Thanks for your reply, it worked. The only negative I see is that in such a > kdevelop session when the projects are imported separately, kdevelop does > not recognize them as separate git repositories. With monolithic import, > however, git does work in kdevelop. This was not like that so far when I > had only the separate repositories cloned. Can it be that kdevelop gets > confused by the git repository on a level below in the directory hierarchy? Unfortunately this is a drawback, yes. The problem is that the submodules don't have a .git directory but a .git file with an entry pointing to the true .git directory, which is located on the highest level of the super-repository. Kdevelop does not support this (yet). With monolithic import the git support of kdevelop is also not optimal, because you can only commit to the super- repositories, not the submodules. It didn't bother me too much because I'm not using the kdevelop git features at all. > I tried the testsuite and it ran fine both with make and ctest. I must say > I’m very impressed. The documentation is also nice, though at the moment I > do not have time to try and add new tests on the basis of it. One thing > that occured to me: how do you think we can integrate the bazaar „physical” > testsuite which relied on comparison of trajectory outputs via Sebastian’s > pycppqed? I'm glad it works and that you like it. Which parts of pycppqed are needed for the physics test suite? If it is only comparing trajectories, this is already supported by the python test driver. In the long run it is probably best to merge pycppqed into cpypyqed. Best regards Raimar |
|
From: Andras V. <and...@ui...> - 2014-01-07 10:38:44
|
Hi Raimar, Thanks for your reply, it worked. The only negative I see is that in such a kdevelop session when the projects are imported separately, kdevelop does not recognize them as separate git repositories. With monolithic import, however, git does work in kdevelop. This was not like that so far when I had only the separate repositories cloned. Can it be that kdevelop gets confused by the git repository on a level below in the directory hierarchy? I tried the testsuite and it ran fine both with make and ctest. I must say I’m very impressed. The documentation is also nice, though at the moment I do not have time to try and add new tests on the basis of it. One thing that occured to me: how do you think we can integrate the bazaar „physical” testsuite which relied on comparison of trajectory outputs via Sebastian’s pycppqed? Best regards, András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck On Mon, Jan 6, 2014 at 5:21 PM, Raimar Sandner <rai...@ui...>wrote: > On Monday, January 06, 2014 09:33:54 you wrote: > > Hi Raimar, > > I feel that I’m close to the point where I will be able to try the > > testsuite, just one more question beforehand. If I checkout the > > super-repository, the different sub-repositories below it will work in > > exactly the same way as they did, won’t they? And also, I can still use > the > > separate build strategy, only in one level lower in the directory > > hierarchy, can’t I? > > That is correct. You can load the sub-projects as standalone-projects in > kdevelop, you will have a separate build directory in every submodule. > Kdevelop might ask which is the right project root because it is ambiguous, > just choose the submodule instead of the super-repository. > > However, you can only run the testsuite from the super-repository project, > obviously, and this will compile the framework again in the > super-repository > build directory. > > I will add a documentation for the testsuite soon. > > > I’m asking this because I wouldn’t like to keep both the separate > projects > > and the super-project with its subprojects on my machine, but want to > move > > my development to under a checked-out super-project, but work separately > as > > so far. This means moving all my local branches as well. > > Yes this will work, you could even load the super-project to kdevelop > additionally on a as-needed basis. If you want to commit to the super- > repository, you can just ignore the changes in the submodules (just don't > 'git > add' the submodules when committing). I will take care that the right > (current) commits are registered in the super-repository on a regular > basis. > > Best regards > Raimar > |
|
From: Raimar S. <rai...@ui...> - 2014-01-02 14:46:03
|
Hi András,
I have now deleted the testing branch, it was not used anymore. Please try
git clone -b Development --recursive gi...@ge...:cppqed/complete.git
Switching branches in the super-repository is a little bit more complex than for a regular repository, because submodules are not touched. To switch branches or to go from detached head to regular branches, I use my own alias 'git attach', which I have configured in ~/.gitconfig as
[alias]
attach = "submodule foreach 'BRANCH=$(git config --file $toplevel/.gitmodules --get submodule.${name}.branch); git checkout --merge ${BRANCH:-master}'"
Then, in the top level directory it is as easy as, for example:
git checkout python
git attach
git checkout Development
git attach
Also please remember that the default urls of the submodules are read only, you have to change them to the correct read-write urls if you want to push.
Best regards
Raimar
On Thursday, January 02, 2014 11:31:21 Andras Vukics wrote:
> Hi Raimar,
>
> I have a few problems here. Upon
> git clone -b testing --recursive gi...@ge...:cppqed/complete.git
> I get the git error
> fatal: repository 'gi...@ge.../cppqed/cpypyqed.git' does not
> exist
>
> If, however, I do
> git clone --recursive gi...@ge...:cppqed/complete.git
> followed by
> cd complete; git checkout testing
> then it looks fine. However, upon trying to configure with cmake, it fails
> as it turns out that the folder cpypyqed doesn’t contain a CMakeLists.txt
> file.
>
> András
>
>
>
> Dr. Andras Vukics
> Institute for Theoretical Physics
> University of Innsbruck
>
> On Thu, Dec 19, 2013 at 8:06 PM, Andras Vukics <and...@ui...>wrote:
> > Hi, of course you can merge. Bests, András
> >
> > Dr. Andras Vukics
> > Institute for Theoretical Physics
> > University of Innsbruck
> >
> >
> > On Thu, Dec 19, 2013 at 7:13 PM, Raimar Sandner <rai...@ui...
> >
> > > wrote:
> >> Hi András,
> >>
> >> sure take your time, I hope you will also find it useful. For me it has
> >> already helped to discover some bugs which would otherwise have gone
> >> unnoticed.
> >>
> >> If you don't mind I will already merge it to Development (only affects
> >> the
> >> super project, anyway), so that I don't have to switch branches so often.
> >> This
> >> will then also introduce cpypyqed to the super repository.
> >>
> >> Best regards
> >> Raimar
> >>
> >> On Thursday, December 19, 2013 17:44:35 Andras Vukics wrote:
> >> > Hi Raimar,
> >> > Again, this looks like a great achievement. Please allow me a few days
> >>
> >> for
> >>
> >> > delving into it.
> >> > Just one note: instead of creating a separate project Testing, we could
> >> > consider leaving the testsuite in the meta-repository C++QED. In my
> >>
> >> mind,
> >>
> >> > this is similar to the overall pieces of documentation that I mentioned
> >> > earlier, which span over the whole project core-elements-scripts (or at
> >> > least the first two).
> >> > Best regards,
> >> > András
> >> >
> >> >
> >> >
> >> > On Thu, Dec 19, 2013 at 12:55 PM, Raimar Sandner
> >> >
> >> > <rai...@ui...>wrote:
> >> > > There was a commit not pushed to sourceforge in CCQEDcore, this is
> >>
> >> now
> >>
> >> > > fixed.
> >> > >
> >> > >
> >> > >
> >> > > Raimar
> >> > >
> >> > >
> >> > >
> >> > > On Thursday, December 19, 2013 03:40:42 you wrote:
> >> > >
> >> > > Hi András,
> >> > >
> >> > >
> >> > >
> >> > > I have integrated a new testsuite into cmake.
> >> > >
> >> > >
> >> > >
> >> > > Please clone the testing branch of the monolithic repository from the
> >> > > private repository:
> >> > >
> >> > >
> >> > >
> >> > > git clone -b testing --recursive gi...@ge...:
> >> > > cppqed/complete.git
> >> > >
> >> > >
> >> > >
> >> > > Then build everything with the monolithic build method (using the
> >>
> >> toplevel
> >>
> >> > > CMakeLists.txt file). Please make sure that no outside components are
> >> > > picked up by cmake, probably it is best to delete ~/.cmake.
> >>
> >> Afterwards, in
> >>
> >> > > the build directory run ctest -jN where N is the number of cores.
> >>
> >> Please
> >>
> >> > > let me know if this all works and if the tests pass.
> >> > >
> >> > >
> >> > >
> >> > > A few notes to the structure now, an I will try to write a complete
> >> > > documentation soon.
> >> > >
> >> > >
> >> > >
> >> > > The testsuite uses ctest from within cmake, which means the complete
> >> > > testsuite can be run by either 'make test' or the ctest command from
> >> > > above.
> >> > > The ctest command has the advantage of being able to run the tests in
> >> > > parallel with the -j switch. CTest itself is rather 'dumb', basically
> >>
> >> one
> >>
> >> > > only has to specify a test name and a test command including command
> >>
> >> line
> >>
> >> > > options in the CMakeLists.txt file.
> >> > >
> >> > >
> >> > >
> >> > > In our case, the command is either the executable
> >> > > target<http://bit.ly/1gHiTC0>named 'tester', which we have built
> >>
> >> with the
> >>
> >> > > boost unittest framework <http://bit.ly/1gHjFyW>, or a python
> >> > > script<http://bit.ly/1gHj2FA>which I wrote as test driver. The
> >>
> >> former is
> >>
> >> > > for testing code snippets, your boost tests can be imported that way.
> >>
> >> The
> >>
> >> > > latter is basically for running scripts. At the moment the
> >>
> >> testdriver.py
> >>
> >> > > is capable of:
> >> > >
> >> > >
> >> > >
> >> > > * running a C++QED script in all modes (single, ensemble, master)
> >> > >
> >> > > * continuing a script
> >> > >
> >> > > * comparing the outcome of a C++QED script to saved and version
> >>
> >> controlled
> >>
> >> > > output in Testing/expected
> >> > >
> >> > > * comparing the outcome of a C++QED script to the outcome of another
> >> > > script
> >> > >
> >> > > * check that the compilation of a cmake target fails in an expected
> >> > > way<http://bit.ly/1gHlPi4>
> >> > >
> >> > >
> >> > >
> >> > > and the functionality can be easily extended. The behavior of the
> >> > > testdriver is controlled by command line options and configuration
> >>
> >> files
> >>
> >> > > testdriver.conf in the subdirectories.
> >> > >
> >> > >
> >> > >
> >> > > Note that neither 'make test' nor 'ctest' will trigger a
> >>
> >> re-configuration
> >>
> >> > > or re-compilation in the case of changed CMakeLists.txt files or
> >>
> >> changed
> >>
> >> > > source files. To overcome this problem I have defined the target
> >>
> >> 'check'.
> >>
> >> > > This should depend on everything essential and therefore trigger
> >> > > re-configuration and compilation. Every subdirectory of the testsuite
> >>
> >> (at
> >>
> >> > > the moment boost, compilefail,continue and run) has its own
> >>
> >> 'check_subdir'
> >>
> >> > > target, and additionally every single test has its own target. This
> >> > > is
> >> > > very
> >> > > convenient when developing or debugging a feature, one does not have
> >>
> >> to
> >>
> >> > > run
> >> > > the whole testsuite all the time but can fine-tune which tests to run
> >>
> >> by
> >>
> >> > > adding them to the buildset in kdevelop. Additionally, all the check*
> >> > > targets are a lot more verbose, because they use ctest -v internally.
> >> > >
> >> > >
> >> > >
> >> > > The next steps:
> >> > >
> >> > >
> >> > >
> >> > > * documentation of testdriver.py, the testdriver.conf syntax and how
> >>
> >> to
> >>
> >> > > add new tests to cmake
> >> > >
> >> > > * making Testing a standalone project, at the moment the testsuite is
> >>
> >> only
> >>
> >> > > available in monolithic builds
> >> > >
> >> > > * import all the other boost unittests which exist
> >> > >
> >> > > * import the other CompositeError files into the compilefail
> >> > > submodule
> >> > > (and I think the CompositeError2 which I used so far gives additional
> >> > > compilation errors which should not exist, but I'm not sure. Please
> >>
> >> check
> >>
> >> > > the output of make CompositeError2.)
> >> > >
> >> > > * write more tests to cover a broader range of features and design
> >> > > promises
> >> > >
> >> > > * integrate the physics testsuite
> >> > >
> >> > > * anything else?
> >> > >
> >> > >
> >> > >
> >> > > Best regards
> >> > >
> >> > > Raimar
> >>
> >> -------------------------------------------------------------------------
> >> -
> >>
> >> > > ---- Rapidly troubleshoot problems before they affect your business.
> >>
> >> Most
> >>
> >> > > IT organizations don't have a clear picture of how application
> >> > > performance affects their revenue. With AppDynamics, you get 100%
> >> > > visibility into your Java,.NET, & PHP application. Start your 15-day
> >>
> >> FREE
> >>
> >> > > TRIAL of AppDynamics Pro!
> >>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clkt
> >> r
> >>
> >> > > k
> >> > > _______________________________________________
> >> > > Cppqed-support mailing list
> >> > > Cpp...@li...
> >> > > https://lists.sourceforge.net/lists/listinfo/cppqed-support
|
|
From: Andras V. <and...@ui...> - 2014-01-02 10:31:50
|
Hi Raimar, I have a few problems here. Upon git clone -b testing --recursive gi...@ge...:cppqed/complete.git I get the git error fatal: repository 'gi...@ge.../cppqed/cpypyqed.git' does not exist If, however, I do git clone --recursive gi...@ge...:cppqed/complete.git followed by cd complete; git checkout testing then it looks fine. However, upon trying to configure with cmake, it fails as it turns out that the folder cpypyqed doesn’t contain a CMakeLists.txt file. András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck On Thu, Dec 19, 2013 at 8:06 PM, Andras Vukics <and...@ui...>wrote: > Hi, of course you can merge. Bests, András > > Dr. Andras Vukics > Institute for Theoretical Physics > University of Innsbruck > > > On Thu, Dec 19, 2013 at 7:13 PM, Raimar Sandner <rai...@ui... > > wrote: > >> Hi András, >> >> sure take your time, I hope you will also find it useful. For me it has >> already helped to discover some bugs which would otherwise have gone >> unnoticed. >> >> If you don't mind I will already merge it to Development (only affects the >> super project, anyway), so that I don't have to switch branches so often. >> This >> will then also introduce cpypyqed to the super repository. >> >> Best regards >> Raimar >> >> On Thursday, December 19, 2013 17:44:35 Andras Vukics wrote: >> > Hi Raimar, >> > Again, this looks like a great achievement. Please allow me a few days >> for >> > delving into it. >> > Just one note: instead of creating a separate project Testing, we could >> > consider leaving the testsuite in the meta-repository C++QED. In my >> mind, >> > this is similar to the overall pieces of documentation that I mentioned >> > earlier, which span over the whole project core-elements-scripts (or at >> > least the first two). >> > Best regards, >> > András >> > >> > >> > >> > On Thu, Dec 19, 2013 at 12:55 PM, Raimar Sandner >> > >> > <rai...@ui...>wrote: >> > > There was a commit not pushed to sourceforge in CCQEDcore, this is >> now >> > > >> > > fixed. >> > > >> > > >> > > >> > > Raimar >> > > >> > > >> > > >> > > On Thursday, December 19, 2013 03:40:42 you wrote: >> > > >> > > Hi András, >> > > >> > > >> > > >> > > I have integrated a new testsuite into cmake. >> > > >> > > >> > > >> > > Please clone the testing branch of the monolithic repository from the >> > > private repository: >> > > >> > > >> > > >> > > git clone -b testing --recursive gi...@ge...: >> > > cppqed/complete.git >> > > >> > > >> > > >> > > Then build everything with the monolithic build method (using the >> toplevel >> > > CMakeLists.txt file). Please make sure that no outside components are >> > > picked up by cmake, probably it is best to delete ~/.cmake. >> Afterwards, in >> > > the build directory run ctest -jN where N is the number of cores. >> Please >> > > let me know if this all works and if the tests pass. >> > > >> > > >> > > >> > > A few notes to the structure now, an I will try to write a complete >> > > documentation soon. >> > > >> > > >> > > >> > > The testsuite uses ctest from within cmake, which means the complete >> > > testsuite can be run by either 'make test' or the ctest command from >> > > above. >> > > The ctest command has the advantage of being able to run the tests in >> > > parallel with the -j switch. CTest itself is rather 'dumb', basically >> one >> > > only has to specify a test name and a test command including command >> line >> > > options in the CMakeLists.txt file. >> > > >> > > >> > > >> > > In our case, the command is either the executable >> > > target<http://bit.ly/1gHiTC0>named 'tester', which we have built >> with the >> > > boost unittest framework <http://bit.ly/1gHjFyW>, or a python >> > > script<http://bit.ly/1gHj2FA>which I wrote as test driver. The >> former is >> > > for testing code snippets, your boost tests can be imported that way. >> The >> > > latter is basically for running scripts. At the moment the >> testdriver.py >> > > is capable of: >> > > >> > > >> > > >> > > * running a C++QED script in all modes (single, ensemble, master) >> > > >> > > * continuing a script >> > > >> > > * comparing the outcome of a C++QED script to saved and version >> controlled >> > > output in Testing/expected >> > > >> > > * comparing the outcome of a C++QED script to the outcome of another >> > > script >> > > >> > > * check that the compilation of a cmake target fails in an expected >> > > way<http://bit.ly/1gHlPi4> >> > > >> > > >> > > >> > > and the functionality can be easily extended. The behavior of the >> > > testdriver is controlled by command line options and configuration >> files >> > > testdriver.conf in the subdirectories. >> > > >> > > >> > > >> > > Note that neither 'make test' nor 'ctest' will trigger a >> re-configuration >> > > or re-compilation in the case of changed CMakeLists.txt files or >> changed >> > > source files. To overcome this problem I have defined the target >> 'check'. >> > > This should depend on everything essential and therefore trigger >> > > re-configuration and compilation. Every subdirectory of the testsuite >> (at >> > > the moment boost, compilefail,continue and run) has its own >> 'check_subdir' >> > > target, and additionally every single test has its own target. This is >> > > very >> > > convenient when developing or debugging a feature, one does not have >> to >> > > run >> > > the whole testsuite all the time but can fine-tune which tests to run >> by >> > > adding them to the buildset in kdevelop. Additionally, all the check* >> > > targets are a lot more verbose, because they use ctest -v internally. >> > > >> > > >> > > >> > > The next steps: >> > > >> > > >> > > >> > > * documentation of testdriver.py, the testdriver.conf syntax and how >> to >> > > add new tests to cmake >> > > >> > > * making Testing a standalone project, at the moment the testsuite is >> only >> > > available in monolithic builds >> > > >> > > * import all the other boost unittests which exist >> > > >> > > * import the other CompositeError files into the compilefail submodule >> > > (and I think the CompositeError2 which I used so far gives additional >> > > compilation errors which should not exist, but I'm not sure. Please >> check >> > > the output of make CompositeError2.) >> > > >> > > * write more tests to cover a broader range of features and design >> > > promises >> > > >> > > * integrate the physics testsuite >> > > >> > > * anything else? >> > > >> > > >> > > >> > > Best regards >> > > >> > > Raimar >> > > >> > > >> > > >> > > >> > > >> > > >> -------------------------------------------------------------------------- >> > > ---- Rapidly troubleshoot problems before they affect your business. >> Most >> > > IT organizations don't have a clear picture of how application >> > > performance affects their revenue. With AppDynamics, you get 100% >> > > visibility into your Java,.NET, & PHP application. Start your 15-day >> FREE >> > > TRIAL of AppDynamics Pro! >> > > >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktr >> > > k >> > > _______________________________________________ >> > > Cppqed-support mailing list >> > > Cpp...@li... >> > > https://lists.sourceforge.net/lists/listinfo/cppqed-support >> >> > |
|
From: Raimar S. <rai...@ui...> - 2013-12-23 12:31:55
|
Dear András, ok, that's fine. The only things which are in fact out of sync with the documentation are the Ubuntu Packages. I will at least rewrite this section in the sphinx documentation, because the package names have changed. Best regards Raimar On Sunday, December 22, 2013 11:45:10 you wrote: > Dear Raimar, > Your worries are justified, but at the moment, since the Bazaar repository > is still in place, I don’t see this as a crucial problem, as the present > documentation mostly still applies to the Bazaar master/Development > branches. Of course, it is not „supported”, in the sense that the bugs > since discovered will not be fixed there, but they are not very grave. (In > the group, we still use the Bazaar://Development branch for production, > without big problems.) > Once we are finished with the > > - new documentation > - the proof-of-principle version of the Python stuff > - all the other most pressing > issues<http://cppqed.sourceforge.net/doxygen/md__home_vukics_work_cppqed_iss > ues.html> , > > we will > > - replace the old documentation at SF > - shut down the Bazaar repository (migrating the yet necessary branches > to git) > - publish new tarballs > - publish a new-version announcement in Computer Physics Communications > - etc. > > This is how I see it, what do you think? > Of course, I would be very glad if you could provide (migrate) in doxygen > documentation that you think appropriate. (Especially concerning cmake and > the Python stuff.) > Best regards, > András > > > Dr. Andras Vukics > Institute for Theoretical Physics > University of Innsbruck > > > On Sat, Dec 21, 2013 at 3:00 PM, Raimar Sandner > > <rai...@ui...>wrote: > > Hi András, > > > > the installation documentation is now horribly outdated. It refers to bzr > > branches (some of them really old like the blitz cvs compatibility branch > > or > > also the BoostIntegratino branch) and still includes the bjam compilation > > method. Also the cmake method needs to be updated. > > > > I would rewrite the instruction to reflect the new git repository layout. > > At > > some time I will also try how it looks on Mac OS at the moment, although I > > don't have an up-to-date version. > > > > A few questions remain: Which of the old special bazaar branches should be > > ported to git? Does a BoostIntegration branch still make sense, without > > the > > ability to write state files? Actually I think the boost dependence is not > > so > > painful... Should we remove all references to bjam from the documentation, > > including profiling > > (http://cppqed.sourceforge.net/installation.html#profiling)? How about > > the tar > > ball people are pointed to on sourceforge? This is really old, and there > > are > > quite a few downloads per week. > > > > Best regards > > Raimar > > > > > > -------------------------------------------------------------------------- > > ---- Rapidly troubleshoot problems before they affect your business. Most > > IT organizations don't have a clear picture of how application > > performance affects their revenue. With AppDynamics, you get 100% > > visibility into your Java,.NET, & PHP application. Start your 15-day FREE > > TRIAL of AppDynamics Pro! > > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktr > > k > > _______________________________________________ > > Cppqed-support mailing list > > Cpp...@li... > > https://lists.sourceforge.net/lists/listinfo/cppqed-support |
|
From: Andras V. <and...@ui...> - 2013-12-22 10:45:39
|
Dear Raimar, Your worries are justified, but at the moment, since the Bazaar repository is still in place, I don’t see this as a crucial problem, as the present documentation mostly still applies to the Bazaar master/Development branches. Of course, it is not „supported”, in the sense that the bugs since discovered will not be fixed there, but they are not very grave. (In the group, we still use the Bazaar://Development branch for production, without big problems.) Once we are finished with the - new documentation - the proof-of-principle version of the Python stuff - all the other most pressing issues<http://cppqed.sourceforge.net/doxygen/md__home_vukics_work_cppqed_issues.html> , we will - replace the old documentation at SF - shut down the Bazaar repository (migrating the yet necessary branches to git) - publish new tarballs - publish a new-version announcement in Computer Physics Communications - etc. This is how I see it, what do you think? Of course, I would be very glad if you could provide (migrate) in doxygen documentation that you think appropriate. (Especially concerning cmake and the Python stuff.) Best regards, András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck On Sat, Dec 21, 2013 at 3:00 PM, Raimar Sandner <rai...@ui...>wrote: > Hi András, > > the installation documentation is now horribly outdated. It refers to bzr > branches (some of them really old like the blitz cvs compatibility branch > or > also the BoostIntegratino branch) and still includes the bjam compilation > method. Also the cmake method needs to be updated. > > I would rewrite the instruction to reflect the new git repository layout. > At > some time I will also try how it looks on Mac OS at the moment, although I > don't have an up-to-date version. > > A few questions remain: Which of the old special bazaar branches should be > ported to git? Does a BoostIntegration branch still make sense, without the > ability to write state files? Actually I think the boost dependence is not > so > painful... Should we remove all references to bjam from the documentation, > including profiling > (http://cppqed.sourceforge.net/installation.html#profiling)? How about > the tar > ball people are pointed to on sourceforge? This is really old, and there > are > quite a few downloads per week. > > Best regards > Raimar > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > |
|
From: Raimar S. <rai...@ui...> - 2013-12-21 13:59:52
|
Hi András, the installation documentation is now horribly outdated. It refers to bzr branches (some of them really old like the blitz cvs compatibility branch or also the BoostIntegratino branch) and still includes the bjam compilation method. Also the cmake method needs to be updated. I would rewrite the instruction to reflect the new git repository layout. At some time I will also try how it looks on Mac OS at the moment, although I don't have an up-to-date version. A few questions remain: Which of the old special bazaar branches should be ported to git? Does a BoostIntegration branch still make sense, without the ability to write state files? Actually I think the boost dependence is not so painful... Should we remove all references to bjam from the documentation, including profiling (http://cppqed.sourceforge.net/installation.html#profiling)? How about the tar ball people are pointed to on sourceforge? This is really old, and there are quite a few downloads per week. Best regards Raimar |
|
From: Raimar S. <rai...@ui...> - 2013-12-19 18:13:08
|
Hi András, sure take your time, I hope you will also find it useful. For me it has already helped to discover some bugs which would otherwise have gone unnoticed. If you don't mind I will already merge it to Development (only affects the super project, anyway), so that I don't have to switch branches so often. This will then also introduce cpypyqed to the super repository. Best regards Raimar On Thursday, December 19, 2013 17:44:35 Andras Vukics wrote: > Hi Raimar, > Again, this looks like a great achievement. Please allow me a few days for > delving into it. > Just one note: instead of creating a separate project Testing, we could > consider leaving the testsuite in the meta-repository C++QED. In my mind, > this is similar to the overall pieces of documentation that I mentioned > earlier, which span over the whole project core-elements-scripts (or at > least the first two). > Best regards, > András > > > > On Thu, Dec 19, 2013 at 12:55 PM, Raimar Sandner > > <rai...@ui...>wrote: > > There was a commit not pushed to sourceforge in CCQEDcore, this is now > > > > fixed. > > > > > > > > Raimar > > > > > > > > On Thursday, December 19, 2013 03:40:42 you wrote: > > > > Hi András, > > > > > > > > I have integrated a new testsuite into cmake. > > > > > > > > Please clone the testing branch of the monolithic repository from the > > private repository: > > > > > > > > git clone -b testing --recursive gi...@ge...: > > cppqed/complete.git > > > > > > > > Then build everything with the monolithic build method (using the toplevel > > CMakeLists.txt file). Please make sure that no outside components are > > picked up by cmake, probably it is best to delete ~/.cmake. Afterwards, in > > the build directory run ctest -jN where N is the number of cores. Please > > let me know if this all works and if the tests pass. > > > > > > > > A few notes to the structure now, an I will try to write a complete > > documentation soon. > > > > > > > > The testsuite uses ctest from within cmake, which means the complete > > testsuite can be run by either 'make test' or the ctest command from > > above. > > The ctest command has the advantage of being able to run the tests in > > parallel with the -j switch. CTest itself is rather 'dumb', basically one > > only has to specify a test name and a test command including command line > > options in the CMakeLists.txt file. > > > > > > > > In our case, the command is either the executable > > target<http://bit.ly/1gHiTC0>named 'tester', which we have built with the > > boost unittest framework <http://bit.ly/1gHjFyW>, or a python > > script<http://bit.ly/1gHj2FA>which I wrote as test driver. The former is > > for testing code snippets, your boost tests can be imported that way. The > > latter is basically for running scripts. At the moment the testdriver.py > > is capable of: > > > > > > > > * running a C++QED script in all modes (single, ensemble, master) > > > > * continuing a script > > > > * comparing the outcome of a C++QED script to saved and version controlled > > output in Testing/expected > > > > * comparing the outcome of a C++QED script to the outcome of another > > script > > > > * check that the compilation of a cmake target fails in an expected > > way<http://bit.ly/1gHlPi4> > > > > > > > > and the functionality can be easily extended. The behavior of the > > testdriver is controlled by command line options and configuration files > > testdriver.conf in the subdirectories. > > > > > > > > Note that neither 'make test' nor 'ctest' will trigger a re-configuration > > or re-compilation in the case of changed CMakeLists.txt files or changed > > source files. To overcome this problem I have defined the target 'check'. > > This should depend on everything essential and therefore trigger > > re-configuration and compilation. Every subdirectory of the testsuite (at > > the moment boost, compilefail,continue and run) has its own 'check_subdir' > > target, and additionally every single test has its own target. This is > > very > > convenient when developing or debugging a feature, one does not have to > > run > > the whole testsuite all the time but can fine-tune which tests to run by > > adding them to the buildset in kdevelop. Additionally, all the check* > > targets are a lot more verbose, because they use ctest -v internally. > > > > > > > > The next steps: > > > > > > > > * documentation of testdriver.py, the testdriver.conf syntax and how to > > add new tests to cmake > > > > * making Testing a standalone project, at the moment the testsuite is only > > available in monolithic builds > > > > * import all the other boost unittests which exist > > > > * import the other CompositeError files into the compilefail submodule > > (and I think the CompositeError2 which I used so far gives additional > > compilation errors which should not exist, but I'm not sure. Please check > > the output of make CompositeError2.) > > > > * write more tests to cover a broader range of features and design > > promises > > > > * integrate the physics testsuite > > > > * anything else? > > > > > > > > Best regards > > > > Raimar > > > > > > > > > > > > -------------------------------------------------------------------------- > > ---- Rapidly troubleshoot problems before they affect your business. Most > > IT organizations don't have a clear picture of how application > > performance affects their revenue. With AppDynamics, you get 100% > > visibility into your Java,.NET, & PHP application. Start your 15-day FREE > > TRIAL of AppDynamics Pro! > > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktr > > k > > _______________________________________________ > > Cppqed-support mailing list > > Cpp...@li... > > https://lists.sourceforge.net/lists/listinfo/cppqed-support |
|
From: Andras V. <and...@ui...> - 2013-12-19 16:45:04
|
Hi Raimar, Again, this looks like a great achievement. Please allow me a few days for delving into it. Just one note: instead of creating a separate project Testing, we could consider leaving the testsuite in the meta-repository C++QED. In my mind, this is similar to the overall pieces of documentation that I mentioned earlier, which span over the whole project core-elements-scripts (or at least the first two). Best regards, András On Thu, Dec 19, 2013 at 12:55 PM, Raimar Sandner <rai...@ui...>wrote: > There was a commit not pushed to sourceforge in CCQEDcore, this is now > fixed. > > > > Raimar > > > > On Thursday, December 19, 2013 03:40:42 you wrote: > > Hi András, > > > > I have integrated a new testsuite into cmake. > > > > Please clone the testing branch of the monolithic repository from the > private repository: > > > > git clone -b testing --recursive gi...@ge...: > cppqed/complete.git > > > > Then build everything with the monolithic build method (using the toplevel > CMakeLists.txt file). Please make sure that no outside components are > picked up by cmake, probably it is best to delete ~/.cmake. Afterwards, in > the build directory run ctest -jN where N is the number of cores. Please > let me know if this all works and if the tests pass. > > > > A few notes to the structure now, an I will try to write a complete > documentation soon. > > > > The testsuite uses ctest from within cmake, which means the complete > testsuite can be run by either 'make test' or the ctest command from above. > The ctest command has the advantage of being able to run the tests in > parallel with the -j switch. CTest itself is rather 'dumb', basically one > only has to specify a test name and a test command including command line > options in the CMakeLists.txt file. > > > > In our case, the command is either the executable target<http://bit.ly/1gHiTC0>named 'tester', which we have built with the boost > unittest framework <http://bit.ly/1gHjFyW>, or a python script<http://bit.ly/1gHj2FA>which I wrote as test driver. The former is for testing code snippets, your > boost tests can be imported that way. The latter is basically for running > scripts. At the moment the testdriver.py is capable of: > > > > * running a C++QED script in all modes (single, ensemble, master) > > * continuing a script > > * comparing the outcome of a C++QED script to saved and version controlled > output in Testing/expected > > * comparing the outcome of a C++QED script to the outcome of another script > > * check that the compilation of a cmake target fails in an expected way<http://bit.ly/1gHlPi4> > > > > and the functionality can be easily extended. The behavior of the > testdriver is controlled by command line options and configuration files > testdriver.conf in the subdirectories. > > > > Note that neither 'make test' nor 'ctest' will trigger a re-configuration > or re-compilation in the case of changed CMakeLists.txt files or changed > source files. To overcome this problem I have defined the target 'check'. > This should depend on everything essential and therefore trigger > re-configuration and compilation. Every subdirectory of the testsuite (at > the moment boost, compilefail,continue and run) has its own 'check_subdir' > target, and additionally every single test has its own target. This is very > convenient when developing or debugging a feature, one does not have to run > the whole testsuite all the time but can fine-tune which tests to run by > adding them to the buildset in kdevelop. Additionally, all the check* > targets are a lot more verbose, because they use ctest -v internally. > > > > The next steps: > > > > * documentation of testdriver.py, the testdriver.conf syntax and how to > add new tests to cmake > > * making Testing a standalone project, at the moment the testsuite is only > available in monolithic builds > > * import all the other boost unittests which exist > > * import the other CompositeError files into the compilefail submodule > (and I think the CompositeError2 which I used so far gives additional > compilation errors which should not exist, but I'm not sure. Please check > the output of make CompositeError2.) > > * write more tests to cover a broader range of features and design promises > > * integrate the physics testsuite > > * anything else? > > > > Best regards > > Raimar > > > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > > |
|
From: Raimar S. <rai...@ui...> - 2013-12-19 11:57:07
|
There was a commit not pushed to sourceforge in CCQEDcore, this is now fixed. Raimar On Thursday, December 19, 2013 03:40:42 you wrote: Hi András, I have integrated a new testsuite into cmake. Please clone the testing branch of the monolithic repository from the private repository: git clone -b testing --recursive gi...@ge...:cppqed/complete.git Then build everything with the monolithic build method (using the toplevel CMakeLists.txt file). Please make sure that no outside components are picked up by cmake, probably it is best to delete ~/.cmake. Afterwards, in the build directory run ctest -jN where N is the number of cores. Please let me know if this all works and if the tests pass. A few notes to the structure now, an I will try to write a complete documentation soon. The testsuite uses ctest from within cmake, which means the complete testsuite can be run by either 'make test' or the ctest command from above. The ctest command has the advantage of being able to run the tests in parallel with the -j switch. CTest itself is rather 'dumb', basically one only has to specify a test name and a test command including command line options in the CMakeLists.txt file. In our case, the command is either the executable target[1] named 'tester', which we have built with the boost unittest framework[2], or a python script[3] which I wrote as test driver. The former is for testing code snippets, your boost tests can be imported that way. The latter is basically for running scripts. At the moment the testdriver.py is capable of: * running a C++QED script in all modes (single, ensemble, master) * continuing a script * comparing the outcome of a C++QED script to saved and version controlled output in Testing/expected * comparing the outcome of a C++QED script to the outcome of another script * check that the compilation of a cmake target fails in an expected way[4] and the functionality can be easily extended. The behavior of the testdriver is controlled by command line options and configuration files testdriver.conf in the subdirectories. Note that neither 'make test' nor 'ctest' will trigger a re-configuration or re-compilation in the case of changed CMakeLists.txt files or changed source files. To overcome this problem I have defined the target 'check'. This should depend on everything essential and therefore trigger re-configuration and compilation. Every subdirectory of the testsuite (at the moment boost, compilefail,continue and run) has its own 'check_subdir' target, and additionally every single test has its own target. This is very convenient when developing or debugging a feature, one does not have to run the whole testsuite all the time but can fine-tune which tests to run by adding them to the buildset in kdevelop. Additionally, all the check* targets are a lot more verbose, because they use ctest -v internally. The next steps: * documentation of testdriver.py, the testdriver.conf syntax and how to add new tests to cmake * making Testing a standalone project, at the moment the testsuite is only available in monolithic builds * import all the other boost unittests which exist * import the other CompositeError files into the compilefail submodule (and I think the CompositeError2 which I used so far gives additional compilation errors which should not exist, but I'm not sure. Please check the output of make CompositeError2.) * write more tests to cover a broader range of features and design promises * integrate the physics testsuite * anything else? Best regards Raimar -------- [1] http://bit.ly/1gHiTC0 [2] http://bit.ly/1gHjFyW [3] http://bit.ly/1gHj2FA [4] http://bit.ly/1gHlPi4 |
|
From: Raimar S. <rai...@ui...> - 2013-12-19 02:40:17
|
Hi András, I have integrated a new testsuite into cmake. Please clone the testing branch of the monolithic repository from the private repository: git clone -b testing --recursive gi...@ge...:cppqed/complete.git Then build everything with the monolithic build method (using the toplevel CMakeLists.txt file). Please make sure that no outside components are picked up by cmake, probably it is best to delete ~/.cmake. Afterwards, in the build directory run ctest -jN where N is the number of cores. Please let me know if this all works and if the tests pass. A few notes to the structure now, an I will try to write a complete documentation soon. The testsuite uses ctest from within cmake, which means the complete testsuite can be run by either 'make test' or the ctest command from above. The ctest command has the advantage of being able to run the tests in parallel with the -j switch. CTest itself is rather 'dumb', basically one only has to specify a test name and a test command including command line options in the CMakeLists.txt file. In our case, the command is either the executable target[1] named 'tester', which we have built with the boost unittest framework[2], or a python script[3] which I wrote as test driver. The former is for testing code snippets, your boost tests can be imported that way. The latter is basically for running scripts. At the moment the testdriver.py is capable of: * running a C++QED script in all modes (single, ensemble, master) * continuing a script * comparing the outcome of a C++QED script to saved and version controlled output in Testing/expected * comparing the outcome of a C++QED script to the outcome of another script * check that the compilation of a cmake target fails in an expected way[4] and the functionality can be easily extended. The behavior of the testdriver is controlled by command line options and configuration files testdriver.conf in the subdirectories. Note that neither 'make test' nor 'ctest' will trigger a re-configuration or re-compilation in the case of changed CMakeLists.txt files or changed source files. To overcome this problem I have defined the target 'check'. This should depend on everything essential and therefore trigger re-configuration and compilation. Every subdirectory of the testsuite (at the moment boost, compilefail,continue and run) has its own 'check_subdir' target, and additionally every single test has its own target. This is very convenient when developing or debugging a feature, one does not have to run the whole testsuite all the time but can fine-tune which tests to run by adding them to the buildset in kdevelop. Additionally, all the check* targets are a lot more verbose, because they use ctest -v internally. The next steps: * documentation of testdriver.py, the testdriver.conf syntax and how to add new tests to cmake * making Testing a standalone project, at the moment the testsuite is only available in monolithic builds * import all the other boost unittests which exist * import the other CompositeError files into the compilefail submodule (and I think the CompositeError2 which I used so far gives additional compilation errors which should not exist, but I'm not sure. Please check the output of make CompositeError2.) * write more tests to cover a broader range of features and design promises * integrate the physics testsuite * anything else? Best regards Raimar -------- [1] http://bit.ly/1gHiTC0 [2] http://bit.ly/1gHjFyW [3] http://bit.ly/1gHj2FA [4] http://bit.ly/1gHlPi4 |
|
From: Vukics A. <an...@vu...> - 2013-12-12 13:51:09
|
Hi, Well, not really. This point was also criticized by one of the referees of the CPC paper. It should somehow be a shared pointer, but as far as I see, the problem is that it usually doesn’t come as such @ the time of construction. Perhaps, the Evolved constructor should be templated, and the function sharedPointerize applied on the argument, in order that it can be safely stored within Evolved as a shared pointer. I myself never encountered any problem with the current usage, did you? Anyway, it’s definitely a consistency issue, and I would be glad if you figured out a way to fix it. Best regards, András On Thu, Dec 12, 2013 at 2:35 PM, Raimar Sandner <rai...@ui...>wrote: > Hi András, > > is there any reason why Evolved (and therefore now EvolvedIO) is holding a > reference A& a_ instead of a shared pointer? > > Best regards > Raimar > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > |
|
From: Raimar S. <rai...@ui...> - 2013-12-12 13:35:37
|
Hi András, is there any reason why Evolved (and therefore now EvolvedIO) is holding a reference A& a_ instead of a shared pointer? Best regards Raimar |
|
From: Raimar S. <rai...@ui...> - 2013-11-19 15:18:22
|
Done. Best regards Raimar On Tuesday, November 19, 2013 03:06:30 PM Andras Vukics wrote: > Hi Raimar, > Thanks, that sounds straightforward indeed. > Please keep the feature branch, since there is one point left to take care > of: Eigen::Matrices can adopt previously allocated data through Eigen::Map > obejcts with the funny ’new’ syntax that you see exemplified in > GeneralDickeImaginaryEvolution. They will still try to free this chunk of > memory when they get destructed, so one has to make sure that they readopt > their original data before running out of scope … (That’s why you see two > pairs of ’new’ constructs in the script. At least, this is my present > understanding.) This worked for me in some tests, but now in > GeneralDickeImaginaryEvolution, when I do it for Eigen::Vector, it causes a > crash with segmentation fault. (For Eigen::Matrix it’s still fine.) > Best regards, > András > > > > On Tue, Nov 19, 2013 at 2:54 PM, Raimar Sandner > > <rai...@ui...>wrote: > > Dear András, > > > > wow, that was quick! > > > > #include <Eigen/Core> is definitely right. Eigen3 distributes a > > FindEigen3.cmake, therefore find_package(Eigen3) will set all the required > > variables and we only have to call > > include_directories(Eigen3_INCLUDE_DIRS) in > > order to have /usr/include/eigen3 in the include path (or whatever the > > right > > path is on the specific distribution). > > > > I will update the cmake build system accordingly. Should I then already > > merge > > it to Development or leave it in the feature branch for now? > > > > Raimar > > > > On Tuesday, November 19, 2013 02:25:04 PM Andras Vukics wrote: > > > Dear Raimar, > > > I have now completed migration to Eigen3, and it seems to work fine. I > > > > have > > > > > pushed the feature branch named Eigen to SourceForge (only core & > > > scripts > > > affected). > > > Could you please fetch the branch and update cmake such that it looks > > > for > > > Eigen3 instead of FLENS? If not found, DO_NOT_USE_EIGEN should be set. > > > Two points to note: > > > * EIGEN_NO_DEBUG should be set for release mode but the documentation of > > > Eigen states that it gets set if NDEBUG is set, so in principle we do > > > not > > > need to care about this. > > > * Under ARCH (and Ubuntu also, I think), Eigen3 gets installed under a > > > directory called eigen3, so that the main include files can be pulled in > > > > as > > > > > #include <eigen3/Eigen/Core> > > > for example. However, in the documentation they only use > > > #include <Eigen/Core> > > > It would be nice to have this latter, especially because this eigen3 > > > directory will not necessarily exist in all distributions. Hence, if > > > > Eigen3 > > > > > is found, this eigen3 directory should be put into the include path. > > > Thanks, with best regards, > > > András > > > > > > > > > Dr. Andras Vukics > > > Institute for Theoretical Physics > > > University of Innsbruck > > > > -------------------------------------------------------------------------- > > ---- Shape the Mobile Experience: Free Subscription > > Software experts and developers: Be at the forefront of tech innovation. > > Intel(R) Software Adrenaline delivers strategic insight and game-changing > > conversations that shape the rapidly evolving mobile landscape. Sign up > > now. > > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktr > > k > > _______________________________________________ > > Cppqed-support mailing list > > Cpp...@li... > > https://lists.sourceforge.net/lists/listinfo/cppqed-support |
|
From: Andras V. <and...@ui...> - 2013-11-19 14:06:59
|
Hi Raimar, Thanks, that sounds straightforward indeed. Please keep the feature branch, since there is one point left to take care of: Eigen::Matrices can adopt previously allocated data through Eigen::Map obejcts with the funny ’new’ syntax that you see exemplified in GeneralDickeImaginaryEvolution. They will still try to free this chunk of memory when they get destructed, so one has to make sure that they readopt their original data before running out of scope … (That’s why you see two pairs of ’new’ constructs in the script. At least, this is my present understanding.) This worked for me in some tests, but now in GeneralDickeImaginaryEvolution, when I do it for Eigen::Vector, it causes a crash with segmentation fault. (For Eigen::Matrix it’s still fine.) Best regards, András On Tue, Nov 19, 2013 at 2:54 PM, Raimar Sandner <rai...@ui...>wrote: > Dear András, > > wow, that was quick! > > #include <Eigen/Core> is definitely right. Eigen3 distributes a > FindEigen3.cmake, therefore find_package(Eigen3) will set all the required > variables and we only have to call > include_directories(Eigen3_INCLUDE_DIRS) in > order to have /usr/include/eigen3 in the include path (or whatever the > right > path is on the specific distribution). > > I will update the cmake build system accordingly. Should I then already > merge > it to Development or leave it in the feature branch for now? > > Raimar > > On Tuesday, November 19, 2013 02:25:04 PM Andras Vukics wrote: > > Dear Raimar, > > I have now completed migration to Eigen3, and it seems to work fine. I > have > > pushed the feature branch named Eigen to SourceForge (only core & scripts > > affected). > > Could you please fetch the branch and update cmake such that it looks for > > Eigen3 instead of FLENS? If not found, DO_NOT_USE_EIGEN should be set. > > Two points to note: > > * EIGEN_NO_DEBUG should be set for release mode but the documentation of > > Eigen states that it gets set if NDEBUG is set, so in principle we do not > > need to care about this. > > * Under ARCH (and Ubuntu also, I think), Eigen3 gets installed under a > > directory called eigen3, so that the main include files can be pulled in > as > > #include <eigen3/Eigen/Core> > > for example. However, in the documentation they only use > > #include <Eigen/Core> > > It would be nice to have this latter, especially because this eigen3 > > directory will not necessarily exist in all distributions. Hence, if > Eigen3 > > is found, this eigen3 directory should be put into the include path. > > Thanks, with best regards, > > András > > > > > > Dr. Andras Vukics > > Institute for Theoretical Physics > > University of Innsbruck > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > |
|
From: Raimar S. <rai...@ui...> - 2013-11-19 13:55:37
|
Dear András, wow, that was quick! #include <Eigen/Core> is definitely right. Eigen3 distributes a FindEigen3.cmake, therefore find_package(Eigen3) will set all the required variables and we only have to call include_directories(Eigen3_INCLUDE_DIRS) in order to have /usr/include/eigen3 in the include path (or whatever the right path is on the specific distribution). I will update the cmake build system accordingly. Should I then already merge it to Development or leave it in the feature branch for now? Raimar On Tuesday, November 19, 2013 02:25:04 PM Andras Vukics wrote: > Dear Raimar, > I have now completed migration to Eigen3, and it seems to work fine. I have > pushed the feature branch named Eigen to SourceForge (only core & scripts > affected). > Could you please fetch the branch and update cmake such that it looks for > Eigen3 instead of FLENS? If not found, DO_NOT_USE_EIGEN should be set. > Two points to note: > * EIGEN_NO_DEBUG should be set for release mode but the documentation of > Eigen states that it gets set if NDEBUG is set, so in principle we do not > need to care about this. > * Under ARCH (and Ubuntu also, I think), Eigen3 gets installed under a > directory called eigen3, so that the main include files can be pulled in as > #include <eigen3/Eigen/Core> > for example. However, in the documentation they only use > #include <Eigen/Core> > It would be nice to have this latter, especially because this eigen3 > directory will not necessarily exist in all distributions. Hence, if Eigen3 > is found, this eigen3 directory should be put into the include path. > Thanks, with best regards, > András > > > Dr. Andras Vukics > Institute for Theoretical Physics > University of Innsbruck |
|
From: Andras V. <and...@ui...> - 2013-11-19 13:25:32
|
Dear Raimar, I have now completed migration to Eigen3, and it seems to work fine. I have pushed the feature branch named Eigen to SourceForge (only core & scripts affected). Could you please fetch the branch and update cmake such that it looks for Eigen3 instead of FLENS? If not found, DO_NOT_USE_EIGEN should be set. Two points to note: * EIGEN_NO_DEBUG should be set for release mode but the documentation of Eigen states that it gets set if NDEBUG is set, so in principle we do not need to care about this. * Under ARCH (and Ubuntu also, I think), Eigen3 gets installed under a directory called eigen3, so that the main include files can be pulled in as #include <eigen3/Eigen/Core> for example. However, in the documentation they only use #include <Eigen/Core> It would be nice to have this latter, especially because this eigen3 directory will not necessarily exist in all distributions. Hence, if Eigen3 is found, this eigen3 directory should be put into the include path. Thanks, with best regards, András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck |
|
From: Raimar S. <rai...@ui...> - 2013-11-18 08:36:17
|
On Friday, November 15, 2013 08:35:49 PM you wrote: > > Finally, I am currently in the process of porting my python I/O branch to > > the > > current development branch. I have thought about splitting everything > > which is > > necessary and sufficient to define a trajectory state and the methods to > > read and > > write it into a new class (or new classes). The goal here is to create a > > minimal non-virtual base class that can be easily instantiated in the > > python > > code, not hijacking the Simulated class for this purpose. But I'm not yet > > sure > > how to do the split in practice, as it goes through both the Trajectory > > and > > Evolved, respectively. Do you think this is the right way to go? > > I agree to the split, but please make sure that it doesn’t seriously upset > the design (and usage) of the Trajectory bundle, which I like a lot. Are > you sure that Evolved should also be split? Because Evolved proper is a > template? Dear András, I might need a little bit of assistance here. I have pushed the current state to the cppqed/core repository on the group server (subject to rebasing at any time). git remote add private an...@ge...:git/cppqed/core git fetch private git checkout cpypyqed This is essentially the current state as we left it at my Budapest visit, only updated to the current Development branch. The problem which I am facing is that I need a class which I can instantiate in the python module io.cc, which cannot know anything about an actual system. We want to be able to take a numpy array and write it into a state file with the interface presented by Trajectory. For this we need a non-virtual class which inherits from Trajectory and has the Evolved as member. This is basically a wrapper class for the array which provides the functions for reading and writing. Up to now the DummyTrajectory class takes this role, inheriting from Simulated. Although this works it is of course not a nice design. One possibility would be to inherit from Adaptive and implement all the virtual functions with no-op functions. But I also don't like this solution: the wrapper dummy class is not intended to be evolved or used in simulations in any way. For the same reason using a full-blown Evolved member with the derivs and all other parameters which are not written to the state file feels like overkill. Having this in mind it would be reasonable to not even let it inherit from the full trajectory class and include a full Evolved, which is why I wanted to split the data from the logic to evolve it. But that would probably involve some major design changes, and I cannot and don't want to do this without further discussion. So maybe you have an idea how to approach this in an elegant way, or we could skype to resolve the issue? The lack of python I/O hinders me (and probably the others from my groups) from using the new Development branch in production, as all my postprocessing scripts depend on it. Best regards Raimar |
|
From: Raimar S. <rai...@ui...> - 2013-11-15 16:53:09
|
Hi András, as you might have noticed I integrated doxygen into cmake in the development branch. To build the documentation, just call make doc. You can edit the Doxyfile.in as you would edit the original Doxyfile. Only make sure that you prefix any path into the source directory with @CMAKE_CURRENT_SOURCE_DIR@, as I have done with the INPUT variable. The dependency cmake on doxygen is optional, if doxygen is not found the doc target will not be available. The documentation will also be installed with make install. These changes make it easier to package the documentation along with everything else. You can soon see this in action when the new Ubuntu packages are built, there will be a new package cppqed-doc-2.99. I have also created a new PPA "C++QED-daily-builds" (ppa:raimar- sandner/cppqed-daily). This PPA will from now on contain automated daily builds of the development branch, for precise and saucy. This is also a good test if everything compiles for both 64bit and 32bit, you might have noticed that I found a quite peculiar bug on 32 bit platforms. Finally, I am currently in the process of porting my python I/O branch to the current development branch. I have thought about splitting everything which is necessary and sufficient to define a trajectory state and the methods to read and write it into a new class (or new classes). The goal here is to create a minimal non-virtual base class that can be easily instantiated in the python code, not hijacking the Simulated class for this purpose. But I'm not yet sure how to do the split in practice, as it goes through both the Trajectory and Evolved, respectively. Do you think this is the right way to go? Regards Raimar |
|
From: Andras V. <and...@ui...> - 2013-11-15 10:20:31
|
The present version in the AUR doesn’t compile on my box. I think the failure is in the compilation of the texinfo part. I think this part is completely unnecessary since everyone will use the pdf documentation anyway. So I think we should do only a make lib Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck On Thu, Nov 14, 2013 at 11:08 PM, Andras Vukics <and...@ui...>wrote: > I also think it is best to only provide the patched version on AUR. Then we >> will have the official 0.10 release and our -hg version which adds the >> patches. >> But I don't know if it is polite to keep the name in this case. Maybe we >> should make it clear that this is essentially a fork? >> > > I suggest that we call it cppqed-blitz. > > By the way, the dependence on boost would only change from an optional one >> to >> a required one for the upstream project. >> > > That’s right, because it optionally depends on Boost.Serialization – this > I forgot. > > The switch to Boost.MultiArray would probably a lot of work, would it not? >> Even after re-implementing the traits, the blitz interface could be >> exposed to >> a lot of places via getArray. >> > > Yes, the blitz-dependence goes rather deep, and that’s why I haven’t > started migrating yet :) . But it’s worth thinking about. > > |
|
From: Andras V. <and...@ui...> - 2013-11-14 22:09:12
|
> > I also think it is best to only provide the patched version on AUR. Then we > will have the official 0.10 release and our -hg version which adds the > patches. > But I don't know if it is polite to keep the name in this case. Maybe we > should make it clear that this is essentially a fork? > I suggest that we call it cppqed-blitz. By the way, the dependence on boost would only change from an optional one > to > a required one for the upstream project. > That’s right, because it optionally depends on Boost.Serialization – this I forgot. The switch to Boost.MultiArray would probably a lot of work, would it not? > Even after re-implementing the traits, the blitz interface could be > exposed to > a lot of places via getArray. > Yes, the blitz-dependence goes rather deep, and that’s why I haven’t started migrating yet :) . But it’s worth thinking about. |
|
From: Raimar S. <rai...@ui...> - 2013-11-14 20:59:55
|
Editing the PKGBUILD was not thought to be a permanent solution :) I also think it is best to only provide the patched version on AUR. Then we will have the official 0.10 release and our -hg version which adds the patches. But I don't know if it is polite to keep the name in this case. Maybe we should make it clear that this is essentially a fork? By the way, the dependence on boost would only change from an optional one to a required one for the upstream project. The switch to Boost.MultiArray would probably a lot of work, would it not? Even after re-implementing the traits, the blitz interface could be exposed to a lot of places via getArray. Best regards Raimar On Thursday, November 14, 2013 06:34:52 PM Andras Vukics wrote: > Hi, > (I think Sebastian wanted to post the mail below on the list.) > I also don’t like the option of having to edit PKGBUILD. > The chances that our changes get back to the main repository are low > because I think they don’t want to get dependent on Boost. > I strongly suggest that we package only our version of Blitz. > By the way, I’m thinking a lot about deprecating Blitz as well, and > migrating to Boost.MultiArray as the basic data structure. Blitz has > several problems: > * It’s not well maintained. > * Its codebase is pretty outdated from the present C++ point of view. > * It has the major design problem that although it has reference-semantics, > it cannot represent all the four possibilites of const-ness for references. > Hence, with the use of Blitz, it is impossible to ensure const-correctness. > * It needs to be compiled, while Boost.MultiArray is header-only. > Best regards, > András > > > Dr. Andras Vukics > Institute for Theoretical Physics > University of Innsbruck > > > On Thu, Nov 14, 2013 at 6:05 PM, Sebastian Krämer < > > seb...@ui...> wrote: > > Hi all! > > > > What are the chances to get these changes back into the main blitz++ > > branch? That would by far be the cleanest option. Otherwise, it's no > > problem to provide a separate AUR-package. However, it might be confusing > > and inconvenient for users if they have to decide between three different > > blitz packages. But I like the option to manually change the URL even > > less. > > It's just too easy to forget this step when installing it as dependency of > > c++qed. > > > > Sebastian > > > > On 11/14/2013 05:40 PM, Andras Vukics wrote: > > Dear Raimar, > > > > Thanks a lot! > > > > It also occurs as an option that we distribute *only* our version of > > > > blitz (although it does depend on Boost.Preprocessor, while the original > > does not). > > > > The FLENS dependency is going to be deprecated in the new release. > > > > Currently, I’m working on replacing it with Eigen3 (cf. > > http://eigen.tuxfamily.org), which is a header-only library also featured > > in AUR. > > Best regards, > > András > > > > > > Dr. Andras Vukics > > Institute for Theoretical Physics > > University of Innsbruck > > > > > > On Thu, Nov 14, 2013 at 3:33 PM, Raimar Sandner <rai...@ui... > > > > > wrote: > >> Dear all, > >> > >> the C++QED dependencies can now be obtained from AUR for arch linux. > >> > >> Sebastian has updated the blitz-hg PKGBUILD and it works very well. To > >> obtain > >> the C++QED-patched version, just edit the PKGBUILD when it asks you and > >> replace the URL with > >> > >> hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz > >> > >> Maybe we should upload a separate package for this version, Sebastian > >> what do > >> you think? > >> > >> I have also overtaken the flens-cvs package and updated it, so that it > >> now > >> includes the same patches which are used in the Ubuntu package. This > >> version > >> is suitable for compiling C++QED, please test if it works for you :) > >> > >> Best regards > >> Raimar > >> > >> > >> ------------------------------------------------------------------------- > >> ----- DreamFactory - Open Source REST & JSON Services for HTML5 & Native > >> Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API > >> Access Free app hosting. Or install the open source package on any LAMP > >> server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and > >> Native! > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clkt > >> rk > >> _______________________________________________ > >> Cppqed-support mailing list > >> Cpp...@li... > >> https://lists.sourceforge.net/lists/listinfo/cppqed-support |
|
From: Andras V. <and...@ui...> - 2013-11-14 17:35:20
|
Hi, (I think Sebastian wanted to post the mail below on the list.) I also don’t like the option of having to edit PKGBUILD. The chances that our changes get back to the main repository are low because I think they don’t want to get dependent on Boost. I strongly suggest that we package only our version of Blitz. By the way, I’m thinking a lot about deprecating Blitz as well, and migrating to Boost.MultiArray as the basic data structure. Blitz has several problems: * It’s not well maintained. * Its codebase is pretty outdated from the present C++ point of view. * It has the major design problem that although it has reference-semantics, it cannot represent all the four possibilites of const-ness for references. Hence, with the use of Blitz, it is impossible to ensure const-correctness. * It needs to be compiled, while Boost.MultiArray is header-only. Best regards, András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck On Thu, Nov 14, 2013 at 6:05 PM, Sebastian Krämer < seb...@ui...> wrote: > Hi all! > > What are the chances to get these changes back into the main blitz++ > branch? That would by far be the cleanest option. Otherwise, it's no > problem to provide a separate AUR-package. However, it might be confusing > and inconvenient for users if they have to decide between three different > blitz packages. But I like the option to manually change the URL even less. > It's just too easy to forget this step when installing it as dependency of > c++qed. > > Sebastian > > On 11/14/2013 05:40 PM, Andras Vukics wrote: > > Dear Raimar, > Thanks a lot! > It also occurs as an option that we distribute *only* our version of > blitz (although it does depend on Boost.Preprocessor, while the original > does not). > The FLENS dependency is going to be deprecated in the new release. > Currently, I’m working on replacing it with Eigen3 (cf. > http://eigen.tuxfamily.org), which is a header-only library also featured > in AUR. > Best regards, > András > > > Dr. Andras Vukics > Institute for Theoretical Physics > University of Innsbruck > > > On Thu, Nov 14, 2013 at 3:33 PM, Raimar Sandner <rai...@ui... > > wrote: > >> Dear all, >> >> the C++QED dependencies can now be obtained from AUR for arch linux. >> >> Sebastian has updated the blitz-hg PKGBUILD and it works very well. To >> obtain >> the C++QED-patched version, just edit the PKGBUILD when it asks you and >> replace the URL with >> >> hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz >> >> Maybe we should upload a separate package for this version, Sebastian >> what do >> you think? >> >> I have also overtaken the flens-cvs package and updated it, so that it now >> includes the same patches which are used in the Ubuntu package. This >> version >> is suitable for compiling C++QED, please test if it works for you :) >> >> Best regards >> Raimar >> >> >> ------------------------------------------------------------------------------ >> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps >> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access >> Free app hosting. Or install the open source package on any LAMP server. >> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk >> _______________________________________________ >> Cppqed-support mailing list >> Cpp...@li... >> https://lists.sourceforge.net/lists/listinfo/cppqed-support >> > > > |
|
From: Andras V. <and...@ui...> - 2013-11-14 16:40:38
|
Dear Raimar, Thanks a lot! It also occurs as an option that we distribute *only* our version of blitz (although it does depend on Boost.Preprocessor, while the original does not). The FLENS dependency is going to be deprecated in the new release. Currently, I’m working on replacing it with Eigen3 (cf. http://eigen.tuxfamily.org), which is a header-only library also featured in AUR. Best regards, András Dr. Andras Vukics Institute for Theoretical Physics University of Innsbruck On Thu, Nov 14, 2013 at 3:33 PM, Raimar Sandner <rai...@ui...>wrote: > Dear all, > > the C++QED dependencies can now be obtained from AUR for arch linux. > > Sebastian has updated the blitz-hg PKGBUILD and it works very well. To > obtain > the C++QED-patched version, just edit the PKGBUILD when it asks you and > replace the URL with > > hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz > > Maybe we should upload a separate package for this version, Sebastian what > do > you think? > > I have also overtaken the flens-cvs package and updated it, so that it now > includes the same patches which are used in the Ubuntu package. This > version > is suitable for compiling C++QED, please test if it works for you :) > > Best regards > Raimar > > > ------------------------------------------------------------------------------ > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access > Free app hosting. Or install the open source package on any LAMP server. > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk > _______________________________________________ > Cppqed-support mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppqed-support > |
|
From: Raimar S. <rai...@ui...> - 2013-11-14 14:30:52
|
Dear all, the C++QED dependencies can now be obtained from AUR for arch linux. Sebastian has updated the blitz-hg PKGBUILD and it works very well. To obtain the C++QED-patched version, just edit the PKGBUILD when it asks you and replace the URL with hg+http://cppqed.hg.sourceforge.net:8000/hgroot/cppqed/blitz Maybe we should upload a separate package for this version, Sebastian what do you think? I have also overtaken the flens-cvs package and updated it, so that it now includes the same patches which are used in the Ubuntu package. This version is suitable for compiling C++QED, please test if it works for you :) Best regards Raimar |
2 messages has been excluded from this view by a project administrator.
