mne_browse_raw_qt / mainwindow.cpp compile error

[mluessi]

I can't compile mne_browse_raw_qt /mainwindow.cpp. I get the following errors (only first shown)

 "mne-cpp/applications/mne_browse_raw_qt/mne_browse_raw_qt/mainwindow.cpp:315:    
 error: expected primary-expression before '[' token

It looks like these changes were introduced in f8b305bc70871fe7615424f429da85da57f84008, the offending code has the form

connect(doMarkChBad,&QAction::triggered, [=](){
             m_pRawModel->markChBad(selected,1);
});

My compiler (GCC 4.4.7, Linux 64 bit) doesn't like the [=] expression. Or given that it is inside a connect, is this a problem with the Qt moc? I'm using Qt 5.2.0.

[floschl]

The expression in the connect statement is a lambda expression and was introduced with c++11. I think if you'd update your gcc to >4.5 it should be fine. Am 24.02.2014 22:48 schrieb "Martin Luessi" notifications@github.com:

I can't compile mne_browse_raw_qt /mainwindow.cpp. I get the following errors (only first shown)

"mne-cpp/applications/mne_browse_raw_qt/mne_browse_raw_qt/mainwindow.cpp:315: error: expected primary-expression before '[' token

It looks like these changes were introduced in f8b305bhttps://github.com/mne-tools/mne-cpp/commit/f8b305bc70871fe7615424f429da85da57f84008, the offending code has the form

connect(doMarkChBad,&QAction::triggered, [=](){ m_pRawModel->markChBad(selected,1); });

My compiler (GCC 4.4.7, Linux 64 bit) doesn't like the [=] expression. Or given that it is inside a connect, is this a problem with the Qt moc? I'm using Qt 5.2.0.

Reply to this email directly or view it on GitHubhttps://github.com/mne-tools/mne-cpp/issues/77 .

[floschl]

Just looked up the support of lambda in different gcc versions (c++0x denotes the experimental C++11): http://gcc.gnu.org/projects/cxx0x.html

gcc 4.4 does not yet support lambda operators, whereas gcc>=4.5 does. So using >=4.5 would solve the compiler error.

[mluessi]

@floschl thanks. Is it necessary to use those C++11 lambda expressions? Many Linux distributions, e.g. CentOS 6.5 that we use, still use gcc 4.4, so requiring gcc >= 4.5 makes it difficult to compile mne-cpp for a lot of people (actually, potentially impossible depending on the distro if the ABI between gcc 4.4 and 4.5 changed, not sure if it did).

[floschl]

lambda operators are in this context pretty useful and dispensing them would result much more difficult code constructions (not only in this case but also using QtConcurrent::mapped). On the other hand, gcc 4.5 was released in April 2010, so we are not really talking about features that were just recently introduced. How about installing a more recent gcc version in parallel and making your QT creator using that version? Or you might try this guide: http://ask.xmodulo.com/upgrade-gcc-centos.html

2014-02-25 15:36 GMT+01:00 Martin Luessi notifications@github.com:

@floschl https://github.com/floschl thanks. Is it necessary to use those C++11 lambda expressions? Many Linux distributions, e.g. CentOS 6.5 that we use, still use gcc 4.4, so requiring gcc >= 4.5 makes it difficult to compile mne-cpp for a lot of people (actually, potentially impossible depending on the distro if the ABI between gcc 4.4 and 4.5 changed, not sure if it did).

Reply to this email directly or view it on GitHubhttps://github.com/mne-tools/mne-cpp/issues/77#issuecomment-36013020 .

[mluessi]

@floschl I understand that when writing software it is nice to use the latest and greatest features that the language has to offer. However, you also need to think how to get the software to users and how to get contributors. IMO, it is already quite difficult to get mne-cpp working (compiling Qt 5.2, Qt3d, etc.), so I don't think it is smart to make it even more difficult by forcing contributors to manually compile gcc, which can be difficult depending on the OS and version.

[floschl]

Understand your point, will talk to chdinh about that issue how we could possibly simplify the overall setting-up-the dev-environment process.

2014-02-25 16:05 GMT+01:00 Martin Luessi notifications@github.com:

@floschl https://github.com/floschl I understand that when writing software it is nice to use the latest and greatest features that the language has to offer. However, you also need to think how to get the software to users and how to get contributors. IMO, it is already quite difficult to get mne-cpp working (compiling Qt 5.2, Qt3d, etc.), so I don't think it is smart to make it even more difficult by forcing contributors to manually compile gcc, which can be difficult depending on the OS and version.

Reply to this email directly or view it on GitHubhttps://github.com/mne-tools/mne-cpp/issues/77#issuecomment-36016327 .

[mluessi]

Sounds good, thanks.

[floschl]

We just made some thoughts about how we could ease the dev-setup process. Regarding the gcc version in Linux, Qt has set the minimum version number to >=4.5 [1] With respect to CentOS, it also recommends to use the Redhat Devtools 1.1 package, which enables to use a more recent gcc version in CentOS. [2]

Well, that does not make things easier. You are totally right saying that it is a big hassle to compile everything (Qt,Qt3D) manually. However, it is planned that Qt3D will be integrated into Qt in the near future. The next release of Qt 5.3 will be end of April, where it might already be included. That is, there will be provided full binaries of Qt+Qt3D, which means that it won't be necessary to manually compile Qt and Qt3D in order to make mne-cpp run. So it seems, that things will get much easier in the near future.

[1] http://qt-project.org/doc/qt-5.0/qtdoc/platform-notes.html [2] http://qt-project.org/wiki/Building-Qt-5-from-Git#15e7b6ad3df43ff719f8388ab4afb1cc

2014-02-25 16:34 GMT+01:00 Martin Luessi notifications@github.com:

Sounds good, thanks.

Reply to this email directly or view it on GitHubhttps://github.com/mne-tools/mne-cpp/issues/77#issuecomment-36019830 .

[agramfort]

I share the concern of @mluessi about dev with bleeding edge dependencies. Do a simple experiment, take your friends laptop and see how hard it is to install your software (max, linux, windows). Clean code is great but a huge user base is even greater. Another thing you can try is to simulate a release process where you provide binaries for every OS and see for who it breaks. I've learnt my lesson with openmeeg http://openmeeg.github.io where I ended providing binaries for gcc 3 runtime in 2010... we also have issues with MNE-C quick regularly ... grumpy Alex

[floschl]

I am totally with you. However, I wouldn't consider a feature that has been introduced 4 years ago as bleeding edge. Somehow, one needs to agree on common minimum requirements. Agreeing on requirements that are set by Qt, a framework that is used by a huge mass of C++ developers, is not the worst thing, I guess. Regarding the big hassle with the manual qt and qt3d compilation, you're right. We should definitely ease that somehow. Am 25.02.2014 21:16 schrieb "Alexandre Gramfort" notifications@github.com:

I share the concern of @mluessi about dev with bleeding edge dependencies. Do a simple experiment, take your friends laptop and see how hard it is to install your software (max, linux, windows). Clean code is great but a huge user base is even greater. Another thing you can try is to simulate a release process where you provide binaries for every OS and see for who it breaks. I've learnt my lesson with openmeeg http://openmeeg.github.iowhere I ended providing binaries for gcc 3 runtime in 2010... we also have issues with MNE-C quick regularly ... grumpy Alex

Reply to this email directly or view it on GitHubhttps://github.com/mne-tools/mne-cpp/issues/77#issuecomment-36052779 .

[chdinh]

@mluessi I agree with you that this is a real issue for CentOS - actually I didn't expect that they still ship GCC 4.4 (release April 21, 2009). Anyhow as a solution for the CentOS issue I would suggest that I will compile and provide the newest gcc together with the Qt5.2.1 binaries.

@agramfort Talking about bleeding edge dependencies is not accurate. We are talking about a standard which is 4 years old (ages in the IT sector). And talking about dependencies: I don't think that having two dependencies Qt5 and qt3d is a lot - actual I don't know any kind of project which has such a few dependencies. Anyhow the qt3d thing is anoying me too: http://qt-project.org/forums/viewthread/37362 To not be outdated when MNE-CPP is released, the development of MNE-CPP was started based on Qt5 Alpha.... we are still not in the release track and Qt5.2.1 is already available. https://github.com/mne-tools/mne-cpp/wiki/MNE-1.0-release

Do a simple experiment, take your friends laptop and see how hard it is to install your software (max, linux, windows).

Here we almost only use Windows and Ubuntu and thats why we don't experience any problems. At this point I have to say its much harder to get mne-python running almost not possible and even with Canopy... some of the colleagues tried and surrendered.

Another thing you can try is to simulate a release process where you provide binaries for every OS and see for who it breaks.

One of our students will work on a continuous integration using TeamCity - we already setup a web space for that - will be ready soon. The plan is to provide Windows, CentOS and MacOSx binaries in a setup.

I've learnt my lesson with openmeeg http://openmeeg.github.io where I ended providing binaries for gcc 3 runtime in 2010...

Here we have the other way arround gcc 3 is way outdated (June 18, 2001). And I don't know which lesson that should be: Not using the most used languages in the world? (the 5 most used languages are C or C like -> Java http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) I think we are on a right track. E.g. we just finished the first MNE-X hardware a real-time TriggerBox/BCI connector which was very easy to realize using QSerialPort (introduced in Qt5.1) and an Atmel AVR32, or the touch gesture in mne_browse_raw_qt using a single line

QScroller::grabGesture(m_pTableView,QScroller::MiddleMouseButtonGesture);

(introduced in Qt5.0). If you want all those new features (Tablets are almost as new as C++11) you have to go with the time. I really recommend: http://qt-project.org/wiki/QtWhitepaper http://qt.digia.com/ to get an Impression how powerfull Qt is.

[agramfort]

@agramfort Talking about bleeding edge dependencies is not accurate. We are talking about a standard which is 4 years old (ages in the IT sector). And talking about dependencies: I don't think that having two dependencies Qt5 and qt3d is a lot - actual I don't know any kind of project which has such a few dependencies. Anyhow the qt3d thing is anoying me too: http://qt-project.org/forums/viewthread/37362

don't get me wrong. I am not trying to teach you a lesson but just to bring up these issues

Here we almost only use Windows and Ubuntu and thats why we don't experience any problems. At this point I have to say its much harder to get mne-python running almost not possible and even with Canopy... some of the colleagues tried and surrendered.

really? could you be more explicit so we can make people's life easier? open a bug o github?

on windows I would really advertise anaconda now.

One of our students will work on a continuous integration using TeamCity - we already setup a web space for that - will be ready soon. The plan is to provide Windows, CentOS and MacOSx binaries in a setup.

excellent. Maybe you can then offer this service for mne-c too :)

I've learnt my lesson with openmeeg http://openmeeg.github.io where I ended providing binaries for gcc 3 runtime in 2010...

Here we have the other way arround gcc 3 is way outdated (June 18, 2001).

no it's the same problem. I was working with gcc 4.2 and my users wanted gcc 3 because the machines of the center were still running gcc 3...

And I don't know which lesson that should be: Not using the most used languages in the world? (the 5 most used languages are C or C like -> Java http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

spending days to setup a build farm to make binaries for 6 differents OS with 32 and 64bits version compatible with stable and test distro. But maybe life would be easier these days.

I think we are on a right track. E.g. we just finished the first MNE-X hardware a real-time TriggerBox/BCI connector which was very easy to realize using QSerialPort (introduced in Qt5.1) and an Atmel AVR32, or the touch gesture in mne_browse_raw_qt using a single line

great

QScroller::grabGesture(m_pTableView,QScroller::MiddleMouseButtonGesture);

(introduced in Qt5.0). If you want all those new features (Tablets are almost as new as C++11) you have to go with the time. I really recommend: http://qt-project.org/wiki/QtWhitepaper http://qt.digia.com/ to get an Impression how powerfull Qt is.

maybe you need to come to Paris to get me started because I have no time to explore the full QT world :)

[mluessi]

@chdinh I know that Qt is great :). Anyways, I tried to use devtools to compile it, and it pretty much worked (except one error, see #80). However, I consulted with the sysadmin here at the center and he also strongly advised against needing devtools to compile mne-cpp. The problem is that normal users also will have to have devtools installed and to run any mne-cpp application they will need to set LD_LIBRARY_PATH.

As I see it, it seems that the C++11 lambda expressions in mainwindow.cpp are the ONLY code that prevents mne-cpp from being compiled with gcc 4.4.7 (even Qt 5.2 by itself compiles fine). So I recommend evaluating if using these lambda expressions is really necessary. It seems to me not using them would be an easy way to prevent the problems when creating binary packages for various operating systems.

[chdinh]

@mluessi great :-) fixed the error #80

The problem is that normal users also will have to have devtools installed and to run any mne-cpp application they will need to set LD_LIBRARY_PATH.

I hope that the next CentOS gen is shipped with a newer gcc. So far I think it remains an issue. And you're right the LD_LIBRARY_PATH is a trick which every developer has to set so far. Users who just want to use the applications as they are will not experience these problems As soon as we deliver the static linked bins.

As I see it, it seems that the C++11 lambda expressions in mainwindow.cpp are the ONLY code that prevents mne-cpp from being compiled with gcc 4.4.7 (even Qt 5.2 by itself compiles fine). So I recommend evaluating if using these lambda expressions is really necessary. It seems to me not using them would be an easy way to prevent the problems when creating binary packages for various operating systems.

Yes preventing the Lambdas is an option - this Lambda at QtConcurrent is a fast prototyping solution to not implement a new class. Since QtConcurrent::map (http://qt-project.org/doc/qt-5.0/qtconcurrent/qtconcurrent.html#map-2) can only automatic parallelize static functions or member functions of the sequence items itself. To ship member variables to the parallelized function a lambda or a new item class is necessary.