Re: C++/library requirements for Plasma 5.26
As for Homebrew-KDE we have a stock proprietary fork of Clang by Apple, upstream Clang 14.0.6 and GCC 11.3.0. We don’t ship Plasma, but as I understand this change may also impact Gear and Frameworks soon. > 7 лип. 2022 р. о 15:08 Nicolas Fella написав(ла): > > Hi, > > for Plasma 5.26 I would like to make use of some C++20 features, in > particular coroutines. > > In terms of compiler requirements this should translate to requiring GCC > 10 or Clang 11. > > In addition we would like to require the qcoro library > (https://github.com/danvratil/qcoro). As per > https://github.com/danvratil/qcoro/issues/85 the library can be > considered stable and is regularly released. > > Is there any distribution that plans to ship Plasma 5.26 that cannot > fulfill these requirements? > > To test whether your system provides the necessary bits you can try > building > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1023 or > https://invent.kde.org/plasma/plasma-nm/-/merge_requests/124 > > Let me know of there are any problems with this plan. > > Cheers > > Nico >
Plasma Not Showing Desktop Files
TLDR: Plasma (5.14.4 under Fedora 35) is not showing my /home/username/Desktop/*.desktop files on the desktop. Details: I recently upgraded two computers at my household to Fedora 35 (f35): mine and my wife’s. My machine was previously running mate DE; my wife’s machine was previously running Plasma DE. My wife’s machine upgraded just fine. Desktop files in /home/username/Desktop are being displayed just as under f34. My machine did not upgrade fine. When I right-click and switch to Desktop view, the desktop is blank, even though I have a couple of .desktop files in /home/uername/Desktop. I’ve checked the .desktop file permissions as well as the Desktop folder permissions and my /home/username folder permissions and they are just like my wife’s files/folders. It may also be noteworthy that I am getting this message in /var/log/messages: 2022-07-04T12:19:50.967859-04:00 localhost plasmashell[1787]: QDBusConnection: error: could not send signal to service "" path "/plasma-org.kde.plasma.desktop-appletsrc" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: /plasma-org.kde.plasma.desktop-appletsrc Please help if you can. Randy Yates ya...@digitalsignallabs.com 919-412-8994 (cell) 919-577-9882 (landline) Randy Yates ya...@digitalsignallabs.com 919-412-8994 (cell) 919-577-9882 (landline)
Plasma Not Showing Desktop Files
TLDR: Plasma (5.14.4 under Fedora 35) is not showing my /home/username/Desktop/*.desktop files on the desktop. Details: I recently upgraded two computers at my household to Fedora 35 (f35): mine and my wife’s. My machine was previously running mate DE; my wife’s machine was previously running Plasma DE. My wife’s machine upgraded just fine. Desktop files in /home/username/Desktop are being displayed just as under f34. My machine did not upgrade fine. When I right-click and switch to Desktop view, the desktop is blank, even though I have a couple of .desktop files in /home/uername/Desktop. I’ve checked the .desktop file permissions as well as the Desktop folder permissions and my /home/username folder permissions and they are just like my wife’s files/folders. It may also be noteworthy that I am getting this message in /var/log/messages: 2022-07-04T12:19:50.967859-04:00 localhost plasmashell[1787]: QDBusConnection: error: could not send signal to service "" path "/plasma-org.kde.plasma.desktop-appletsrc" interface "org.kde.kconfig.notify" member "ConfigChanged": Invalid object path: /plasma-org.kde.plasma.desktop-appletsrc Please help if you can. Randy Yates ya...@digitalsignallabs.com 919-412-8994 (cell) 919-577-9882 (landline) Randy Yates ya...@digitalsignallabs.com 919-412-8994 (cell) 919-577-9882 (landline)
Re: C++/library requirements for Plasma 5.26
> You might very well not be reading this correctly, as it's phrased very > ambiguously: Very likely. It is just that the ambiguous wording with the conclusion didn't give me the confidence of the quality of implementation. > However, C++20 also brought dozens of smaller language and library > improvements that have been working just fine in both Clang and GCC even Yes, many library features C++20 brought are nice gems. :) > Ok, building and possibly also *testing* ;-) Tests for async things are usually not that good/exhaustive even for normal code that doesn't deal with experimental compiler features. If we go for coroutines, I'd just advise a slower and well-planned adoption then - use it in a smaller, but often used part, and then go from there. (I hate advocating slow adoption of something this cool, but... :) ) Cheers, Ivan -- dr Ivan Čukić ivan.cu...@kde.org, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
Re: C++/library requirements for Plasma 5.26
On 07/07/2022 05.55, Ivan Čukić wrote: Hi Nicolas, While I've been known to request newer and newer compilers for everything, and while I do support this request for GCC 10 and Clang 11, I'm not sure I'd support requiring QCoro and coroutines. Not because of QCoro itself, but that clang doesn't yet officially support coroutines. According to [1] they have a partial support since version 8, and according to [2] they might lead to problems when coroutines might be resumed on a wrong thread (if I'm reading this correctly), with a comment 'This feature requires further analysis of the C++ Standard to determine what work is necessary for conformance.' You might very well not be reading this correctly, as it's phrased very ambiguously: The optimizer does not yet handle TLS with __attribute__((const)) attribute correctly. There can be issues where the coroutine may resume on a different thread. This feature requires further analysis of the C++ Standard to determine what work is necessary for conformance. These three sentences are not describing three unrelated issues. They should be interpreted as subordinates: 1. Coroutines may interact weirdly with thread-local storage (TLS). 2. The optimizer is normally allowed to cache the result of calls which are marked __attribute__((const)). 3. If a coroutine resumes from co_await on a different thread, the cached result of a const function which accesses a TLS variable will be based on the previous thread 4. "This feature" in the last sentence refers to this rather exotic interaction of coroutines, thread-local storage and const functions (which are a GNU extension, not part of the C++ standard). This bug has a real-world case where this could happen due to pthread_self() being a const function which accesses TLS to retrieve the current thread's ID: https://bugs.llvm.org/show_bug.cgi?id=47833 Clang development seems to have slowed down a bit so I'm not sure how viable is pushing C++20 to Plasma just yet. Modules, Concepts and Coroutines are huge new features that will take years to mature. However, C++20 also brought dozens of smaller language and library improvements that have been working just fine in both Clang and GCC even before the C++20 draft was finalized: https://android-review.googlesource.com/c/platform/system/netd/+/1161045 I don't remember encountering any Clang bugs in 2 years of usage in AOSP, and it's now enabled in more places: https://cs.android.com/search?q=cpp_std.*(experimental%7Cc%5C%2B%5C%2B2%5B03a%5D%7Cgnu%5C%2B%5C%2B2%5B03a%5D)%20file:Android.bp Especially since most of us compile with GCC - if we are able to overlook bugs that our patches introduce for dark-theme users because we use and test on the light one, I can't dare to imagine issues we can introduce to Clang-based distros. :) Would be good to have CI pipelines building all of KDE with the oldest officially supported versions of GCC and Clang. Ok, building and possibly also *testing* ;-) Cheers, Ivan p.s. From a personal standpoint, yes, I'd really like to be able to use QCoro in Vault... [1] https://en.cppreference.com/w/cpp/compiler_support/20 [2] https://clang.llvm.org/cxx_status.html -- _ // Bernie Innocenti \X/ https://codewiz.org/
Re: C++/library requirements for Plasma 5.26
On Thursday, 7 July 2022 14:55:03 CEST Ivan Čukić wrote: > Not because of QCoro itself, but that clang doesn't yet officially > support coroutines. According to [1] they have a partial support > since version 8, and according to [2] they might lead to problems > when coroutines might be resumed on a wrong thread (if I'm > reading this correctly), with a comment 'This feature requires > further analysis of the C++ Standard to determine what work is > necessary for conformance.' On the FreeBSD side, we're slowly giving up on FreeBSD 12, which means that we can count on FreeBSD 13, which uses this clang from the ground up: FreeBSD clang version 13.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) (I can't vouch for powerpc, though; that might be gcc). qcoro doesn't build on 12, but does on 13 and later. I don't know if it **works**, but it builds. It's possible to use other / newer clangs for package building, although it's a hassle. Heck, it would even be possible to build the entire Qt / KDE / stack on FreeBSD with gcc, though I'd call that a pretty miserable failure for clang as a project for modern C++. [ade] signature.asc Description: This is a digitally signed message part.
Re: C++/library requirements for Plasma 5.26
Hi Nicolas, While I've been known to request newer and newer compilers for everything, and while I do support this request for GCC 10 and Clang 11, I'm not sure I'd support requiring QCoro and coroutines. Not because of QCoro itself, but that clang doesn't yet officially support coroutines. According to [1] they have a partial support since version 8, and according to [2] they might lead to problems when coroutines might be resumed on a wrong thread (if I'm reading this correctly), with a comment 'This feature requires further analysis of the C++ Standard to determine what work is necessary for conformance.' Clang development seems to have slowed down a bit so I'm not sure how viable is pushing C++20 to Plasma just yet. Especially since most of us compile with GCC - if we are able to overlook bugs that our patches introduce for dark-theme users because we use and test on the light one, I can't dare to imagine issues we can introduce to Clang-based distros. :) Cheers, Ivan p.s. From a personal standpoint, yes, I'd really like to be able to use QCoro in Vault... [1] https://en.cppreference.com/w/cpp/compiler_support/20 [2] https://clang.llvm.org/cxx_status.html -- dr Ivan Čukić ivan.cu...@kde.org, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
C++/library requirements for Plasma 5.26
Hi, for Plasma 5.26 I would like to make use of some C++20 features, in particular coroutines. In terms of compiler requirements this should translate to requiring GCC 10 or Clang 11. In addition we would like to require the qcoro library (https://github.com/danvratil/qcoro). As per https://github.com/danvratil/qcoro/issues/85 the library can be considered stable and is regularly released. Is there any distribution that plans to ship Plasma 5.26 that cannot fulfill these requirements? To test whether your system provides the necessary bits you can try building https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1023 or https://invent.kde.org/plasma/plasma-nm/-/merge_requests/124 Let me know of there are any problems with this plan. Cheers Nico
