Daniel Vrátil's blog Daniel Vrátil's blog category feed

QCoro

0001-01-01T00:00:00+0000

QCoro is a C++ library that makes it possible to use C++20 coroutines with Qt. It provides the necessary tools to create coroutines as well as coroutine-friendly wrappers for native Qt types.

KDE

0001-01-01T00:00:00+0000

I have been contributing to KDE for over a decade. I was involved in KDE Telepathy, KScreen and most prominently in KDE PIM. I am Akonadi maintainer and author or Google integration.

cmake-package

0001-01-01T00:00:00+0000

A Rust crate for Cargo build scripts that provides a simple way to find and use CMake package installed on the system.

QCoro 0.13.0 Release Announcement

2026-02-13T00:00:00+0000

This release brings improvements to generators, better build system integration and several bugfixes.

As always, big thanks to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

Directly Awaiting Qt Types in AsyncGenerator Coroutines

The biggest improvement in this release is that QCoro::AsyncGenerator coroutines now support directly co_awaiting Qt types without the qCoro() wrapper, just like QCoro::Task coroutines already do (#292).

Previously, if you wanted to await a QNetworkReply inside an AsyncGenerator, you had to wrap it with qCoro():

QCoro::AsyncGenerator<QByteArray> fetchPages(QNetworkAccessManager &nam, QStringList urls) {
 for (const auto &url : urls) {
 auto *reply = co_await qCoro(nam.get(QNetworkRequest{QUrl{url}}));
 co_yield reply->readAll();
 }
}

Starting with QCoro 0.13.0, you can co_await directly, just like in QCoro::Task:

QCoro::AsyncGenerator<QByteArray> fetchPages(QNetworkAccessManager &nam, QStringList urls) {
 for (const auto &url : urls) {
 auto *reply = co_await nam.get(QNetworkRequest{QUrl{url}});
 co_yield reply->readAll();
 }
}

Other Features and Changes

Generator’s .end() method is now const (and constexpr), so it can be called on const generator objects (#294).
GeneratorIterator can now be constructed in an invalid state, allowing lazy initialization of iterators (#318).
qcoro.h now only includes QtNetwork and QtDBus headers when those features are actually enabled, resulting in cleaner builds when optional modules are disabled (#280).

Bugfixes

Fixed memory leak in QFuture coro wrapper when a task is destroyed while awaiting on a QFuture (#312, Daniel Vrátil)
Fixed include paths when using QCoro with CMake’s FetchContent (#282, Daniel Vrátil; #310, Nicolas Fella)
Fixed QCoroNetworkReply test on Qt 6.10 (#305, Daniel Vrátil)

Full changelog

See changelog on Github

Support

If you enjoy using QCoro, consider supporting its development on GitHub Sponsors or buy me a coffee on Ko-fi (after all, more coffee means more code, right?).

Rust: linking static C/C++ libraries with LTO

2025-12-16T23:00:00+0100

The Backstory

I wasted entire afternoon today trying to figure this out, so here’s a quick note for future reference - hopefully to save someone else’s afternoon.

Today, I was working on adding Rust bindings for an internal C++ library. The C++ library itself is built using CMake and produces a statically-linked library, let’s call it libfoo.a. I used the cxx crate to generate the glue code between Rust and the C++ library, wrote the higher-level Rust API and ran cargo build. The crate built just fine, so I moved on to integrating it into our larger Rust project. However, when I tried to build the project, I got a linker error:

note: rust-lld: error: undefined symbol: url_to_json[abi:cxx11](std::basic_string_view<char, std::char_traits<char>> const&)

I double-checked the build.rs script of the bindings crate to ensure that libfoo.a was being linked. It was. I then used nm to confirm that the symbol actually exists in libfoo.a. It did. So what now? I spent a lot of time googling around, trying different “hacks” in the build.rs script and other sorcery. I had a temporary success by adding complex build.rs into the consumer project, but that wasn’t really a scalable solution.

The most confusing part was that I used the exact same approach and code to create bindings for another our C++ library a while ago, and there it all just worked. No special linker flags, no magical cargo incantations, no build.rs in projects that used the bindings crate. What was different this time?

A Suspect is Identified

After literally hours of trial and error and out of desperation, I decided to objdump the libfoo.a to look at the disassembly of the problematic url_to_json function. I am far from an assembly expert, but the disassembled output looked very suspicious, even to my untrained eye.

0000000000000000 <.gnu.lto__Z11url_to_jsonB5cxx11RKSt17basic_string_viewIcSt11char_traitsIcEE.1350.d0d92fceb60052fc>:
0: 28 b5 2f fd 60 72 sub %dh,0x7260fd2f(%rbp)
6: 02 25 12 00 b6 a0 add -0x5f49ffee(%rip),%ah
c: 71 46 jno 54 <.gnu.lto__Z11url_to_jsonB5cxx11RKSt17basic_string_viewIcSt11char_traitsIcEE.1350.d0d92fceb60052fc+0x54>
e: e0 d0 loopne ffffffffffffffe0
10: 36 1d f8 c7 f0 69 ss sbb $0x69f0c7f8,%eax
16: 6c insb (%dx),%es:(%rdi)
17: 81 05 c4 c0 e0 96 61 addl $0x149c4e61,-0x691f3f3c(%rip)
1e: 4e 9c 14
21: a0 ad c0 3f f4 3e de movabs 0x102dde3ef43fc0ad,%al
28: 2d 10
2a: a4 movsb %ds:(%rsi),%es:(%rdi)
2b: 61 (bad)
(truncated)

Those instructions don’t look sensible at all, especially when compared to what the actual C++ code looks like. And what about the “bad” instruction? It’s not like I haven’t run into miscompilations before, but this was much more than that.

At this point, I consulted the situation with an AI, and the answer was clear:

When working with static libraries and Clang, issues with assembly output from tools like objdump can arise, particularly when Link-Time Optimization (LTO) is enabled.

Wait! Did it say LTO? The static library is definitely built with LTO (it’s even in the name of the symbol). Quick check into the library’s CMakeLists.txt and bingo: LTO is enabled by default. I disabled it and…the consumer project built and linked without a single error. Problem solved.

But…why?

My (shallow) understanding of LTO has always been that it’s just a special optimizer pass at link time, when the linker can see the final executable (or shared library) as a whole, and can perform optimizations across translation units and more efficiently eliminate unused code. A static library is just a collection of object files, so LTO should not really play any role here, right?

The reality is that with LTO enabled, compilers “cheat” (yes, compilers - GCC does this as well), and instead of producing object files with the final machine code, they produce object-like files that contain the intermediate representation (IR) of the code. IR (GCC calls it GIR) is a compiler-specific representation of the code during the compilation process. It’s no longer the original source code, but it’s not the final machine code either. Having access to the IR allows the linker to perform advanced optimizations that wouldn’t be possible if it only had access to the final machine code. The final codegen that emits the executable machine code happens after the optimization pass.

This entire process is actually described quite nicely in the LLVM documentation about LTO - which is an information that is useful only when you know that you need it :-)

However, if the libfoo.a contained LLVM IR, and rustc also uses LLVM (and supports LTO on its own), why didn’t it Just Work™? The problem is that Rust will only perform LTO between Rust crates by default.

Cross-language LTO with `cxx`

Luckily, it’s possible to coerce the Rust compiler to perform cross-language LTO, but if you are using the cxx crate, there’s an extra step involved.

This is what ultimately worked for me, and allowed me to build both without LTO in debug mode and with LTO in release mode.

In your build.rs, you must make sure that the generated bridge code is also compiled with LTO enabled (when needed):


let enable_lto = std::env::var("PROFILE").unwrap_or_default() == "release";

// Compile the C++ library
cmake::Config::new(".")
 .define("ENABLE_LTO", if enable_lto { "ON" } else { "OFF" })
 .build_target("all");

// Build the cxx bridge
let mut bridge = cxx_build::bridge("src/bridge.rs")
 .file("src/bridge.cpp")
 // ... additional includes paths, source files, flags, etc.
 ;
if enable_lto {
 // Enable LTO for the bridge compilation as well
 bridge.flag_if_supported("-flto");
}

bridge.compile("foo_bridge");

And to compile it. Just make sure you use Clang for building the C++ code as well (the cc crate inside cxx should pick this up automatically from the environment variables):

# Make sure to use clang!
export CXX=clang++
export CC=clang
# Enable LTO linker plugin
export RUSTFLAGS="-Clinker-plugin-lto"
# Let's gooooo
cargo build --release

An important requirement is that the C/C++ code must be compiled with a version of Clang that is compatible with the LLVM version used by rustc. The compatibility matrix is documented in the rustc book. In my case, I was using rustc 1.90 (LLVM 20.1.8) and Clang 20.1.8.

Conclusion

If you ever run into undefined reference linker errors when trying to link static C or C++ libraries with your Rust code, double check whether the static library was built with LTO enabled, and make sure to enable cross-language LTO in your Rust build as well.

Old New Blog

2024-12-20T16:55:18+0100

I started this blog back in 2010. Back then I used Wordpress and it worked reasonably well. In 2018 I decided to switch to a static generated site, mostly because the Wordpress blog felt slow to load and it was hassle to maintain. Back then the go-to static site generator was Jekyll, so I went with that. Lately I’ve been struggling with it though, because in order to keep all the plugins working, I needed to use older versions or Ruby, which meant I had to use Docker to build the blog locally. Overall, it felt like too much work and for the past few years I’ve been eyeing Hugo - more so since Carl and others migrated most of KDE websites to it. I mean, if it’s good enough for KDE, it’s good enough for me, right?

So this year I finally got around to do the switch. I migrated all the content from Jekyll. This time I actually went through every single post, converted it to proper Markdown, fixed formatting, images etc. It was a nice trip down the memory lane, reading all the old posts, remembering all the sprints and Akademies… I also took the opportunity to clean up the tags and categories, so that they are more consistent and useful.

Finally, I have rewritten the theme - I originally ported the template from Wordpress to Jekyll, but it was a bit of a mess, responsivity was “hacked” in via JavaScript. Web development (and my skills) has come a long way since then, so I was able to leverage more modern CSS and HTML features to make the site look the same, but be more responsive and accessible.

Comments

When I switched from Wordpress to Jekyll, I was looking for a way to preserve comments. I found Isso, which is basically a small CGI server backed with SQLite that you can run on the server and embed it into your static website through JavaScript. It could also natively import comments from Wordpress, so that’s the main reason why I went with it, I think. Isso was not perfect (although the development has picked up again in the past few years) and it kept breaking for me. I think it haven’t worked for the past few years on my blog and I just couldn’t be bothered to fix it. So, I decided to ditch it in favor of another solution…

I wanted to keep the comments for old posts by generating them as static HTML from the Isso’s SQLite database, alas the database file was empty. Looks like I lost all comments at some point in 2022. It sucks, but I guess it’s not the end of the world. Due to the nature of how Isso worked, not even the Wayback Machine was able to archive the comments, so I guess they are lost forever…

For this new blog, I decided to use Carl’s approach with embedding replies to a Mastodon. I think it’s a neat idea and it’s probably the most reliable solution for comments on a static blog (that I don’t have to pay for, host myself or deal with privacy concerns or advertising).

I have some more ideas regarding the comments system, but that’s for another post ;-) Hopefully I’ll get to blog more often now that I have a shiny new blog!

Happy Holidays 🎄

Enjoy the holidays and see you in 2025 🥳!

QCoro 0.11.0 Release Announcement

2024-10-04T12:00:00+0000

A long over-due release which has accumulated a bunch of bugfixes but also some fancy new features…read on!

As always, big thanks to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

`QCoro::LazyTask<T>`

The biggest new features in this release is the brand-new QCoro::LazyTask<T>. It’s a new return type that you can use for your coroutines. It differs from QCoro::Task<T> in that, as the name suggest, the coroutine is evaluated lazily. What that means is when you call a coroutine that returns LazyTask, it will return imediately without executing the body of the coroutine. The body will be executed only once you co_await on the returned LazyTask object.

This is different from the behavior of QCoro::Task<T>, which is eager, meaning that it will start executing the body immediately when called (like a regular function call).

QCoro::LazyTask<int> myWorker()
{
 qDebug() << "Starting worker";
 co_return 42;
}

QCoro::Task<> mainCoroutine()
{
 qDebug() << "Creating worker";
 const auto task = myWorker();
 qDebug() << "Awaiting on worker";
 const auto result = co_await task;
 // do something with the result
}

This will result in the following output:

mainCoroutine(): Creating worker
mainCoroutine(): Awaiting on worker
myWorker(): Starting worker

If myWorker() were a QCoro::Task<T> as we know it, the output would look like this:

mainCoroutine(): Creating worker
myWorker(): Starting worker
mainCoroutine(): Awaiting on worker

The fact that the body of a QCoro::LazyTask<T> coroutine is only executed when co_awaited has one very important implication: it must not be used for Qt slots, Q_INVOKABLEs or, in general, for any coroutine that may be executed directly by the Qt event loop. The reason is, that the Qt event loop is not aware of coroutines (or QCoro), so it will never co_await on the returned QCoro::LazyTask object - which means that the code inside the coroutine would never get executed. This is the reason why the good old QCoro::Task<T> is an eager coroutine - to ensure the body of the coroutine gets executed even when called from the Qt event loop and not co_awaited.

For more details, see the documentation of QCoro::LazyTask<T>.

Defined Semantics for Awaiting Default-Constructed and Moved-From Tasks

This is something that wasn’t clearely defined until now (both in the docs and in the code), which is what happens when you try to co_await on a default-constructed QCoro::Task<T> (or QCoro::LazyTask<T>):

co_await QCoro::Task<>(); // will hang indefinitely!

Previously this would trigger a Q_ASSERT in debug build and most likely a crash in production build. Starting with QCoro 0.11, awaiting such task will print a qWarning() and will hang indefinitely.

The same applies to awaiting a moved-from task, which is identical to a default-constructed task:

QCoro::LazyTask<int> task = myTask();
handleTask(std::move(task));

co_await task; // will hang indefinitely!`

Compiler Support

We have dropped official support for older compilers. Since QCoro 0.11, the officially supported compilers are:

GCC >= 11
Clang >= 15
MSVC >= 19.40 (Visual Studio 17 2022)
AppleClang >= 15 (Xcode 15.2)

QCoro might still compile or work with older versions of those compilers, but we no longer test it and do not guarantee that it will work correctly.

The reason is that coroutine implementation in older versions of GCC and clang were buggy and behaved differently than they do in newer versions, so making sure that QCoro behaves correctly across wide range of compilers was getting more difficult as we implemented more and more complex and advanced features.

Other Features and Changes

A coroutine-friendly version of QFuture::takeResult() is now available in the form of QCoroFuture::takeResult() when building QCoro against Qt 6 (#217).

QCoro::waitFor(QCoro::Task<T>) no longer requires that the task return type T is default-constructible (#223, Joey Richey)

Bugfixes

Suppress Clang error when building against Android NDK <= 25 (#204, Daniel Vrátil)
Fixed missing QtGui dependency in QCoroQuick module (#209, Andreas Sturmlechner)
Fixed QCoroIODevice::write() always returning 0 instead of bytes written (#211, Daniel Vrátil)
Fixed unchecked std::optional access in QCoroIODevice::write
Fixed awaiting on signal emission with qCoro() would resume the awaiter in the sender’s thread context (#213, Daniel Vrátil)
Fixed build wilth clang 18 due to missing #include <exception> (#220, Micah Terhaar)
Fixed crash when QNetworkAccessManager is destroyed from a coroutine awaiting on a network reply (#231, Daniel Vrátil)

Full changelog

See changelog on Github

Support

If you enjoy using QCoro, consider supporting its development on GitHub Sponsors or buy me a coffee on Ko-fi (after all, more coffee means more code, right?).

KDE PIM Sprint 2024 Report

2024-06-19T20:00:00+0000

In 2021 I decided to take a break from contributing to KDE, since I felt that I’ve been losing motivation and energy to contribute for a while… But I’ve been slowly getting back to hacking on KDE stuff for the past year, which ended in me going to Toulouse this year to attend the annual KDE PIM Sprint, my first in 5 years.

I’m very happy to say that we have /a lot/ going on in PIM, and even though not everything is in the best shape and the community is quite small (there were only four of us at the sprint), we have great plans for the future, and I’m happy to be part of it.

Day 0

The sprint was officially supposed to start on Saturday, but everyone arrived already on Friday, so why wait? We wrote down the topics to discuss, put them on a whiteboard and got to it.

We’ve managed to discuss some pretty important topics - how we want to proceed with deprecation and removal of some components, how to improve our test coverage or how to improve indexing and much much more.

I arrived to the sprint with two big topics to discuss: milestones and testing:

Milestones

The idea is to create milestones for all our bigger efforts that we work (or want to work) on. The milestones should be concrete goals that are achievable within a reasonable time frame and have clear definition of done. Each milestones should then be split to smaller tasks that can be tackled by individuals. We hope that this will help to make KDE PIM more attractive to new contributors, who can now clearly see what is being worked on and can find very concrete, bite-sized tasks to work on.

As a result, we took all the ongoing tasks and turned most of them into milestones in Gitlab. It’s still very much work in progress, we still need to break down many milestones to smaller tasks, but the general ideas are out there.

E2E Testing of Resources

Akonadi Resources provide “bridge” between Akonadi Server and individual services, like IMAP servers, DAV servers, Google Calendar etc. But we have no tests to verify that our Resources can talk to the services and vice versa. The plan is to create a testing framework (in Python) so that we can have automated nightly tests to verify that e.g. IMAP resource interfaces properly with common IMAP server implementations, including major proprietary ones like Gmail or Office365. We want to achieve decent coverage for all our resources. This is a big project, but I think it’s a very exciting one as it includes not just programming, but also figuring out and building some infrastructure to run e.g. Dovecot, NextCloud and others in a Docker to test against.

Day 1

On Saturday we started quite early, all the delicious french pastry is not going to eat itself, is it? After breakfast we continued with discussions, we dicussed tags support, how to improve our PR. But we also managed to produce some code. I implemented syncing of iCal categories with Akonadi tags, so the tags are becoming more useful. I also prepared Akonadi to be cleanly handle planned deprecation and retirement of KJots, KNotes and their acompanying resources, as well as planned removal of the Akonadi Kolab Resource (in favor of using IMAP+DAV).

One of the tasks I want to look into is improving how we do database transactions in the Akonadi Server. To get some data out of it, I shoved Prometheus exporter into Akonadi, hooked it up to a local Prometheus service, thrown together a Grafana dashboard, and here we are:

We decided to order some pizzas for dinner and stayed at the venue hacking until nearly 11 o’clock.

Day 2

On the last day of the sprint we wrapped up on the discussions and focused on actually implementing some of the ideas. I spent most of the time extending the Migration agent to extract tags from all existing events and todos already stored in Akonadi and helped to create some of the milestones on the Gitlab board. We also came up with a plan for KDE PIM BoF on this years Akademy, where we want to present out progress on the respective milestones and to give a chance to contributors to learn what are the biggest hurdles they are facing when trying to contribute to KDE PIM and how we can help make it easier for them to get involved.

Conclusion

I think it was a very productive sprint and I am really excited to be involved in PIM again. Can’t wait to meet up with everyone again on Akademy in September.

Go check out Kevin’s and Carl’s reports to see what else have they been up to during the sprint.

Did some of the milestones caught your eye, or do you have have any questions? Come talk to us in our matrix channel.

Finally, many thanks to Kevin for organizing the sprint, Étincelle Coworking for providing us with nice and spacious venue and KDE e.V. for supporting us on travel.

Finally, if you like such meetings to happen in the future so that we can push forward your favorite software, please consider making a tax-deductible donation to the KDE e.V. foundation.

QCoro 0.10.0 Release Announcement

2023-12-05T21:30:00+0000

Thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

Support for awaiting Qt signals with QPrivateSignal

Qt has a feature where signals can be made “private” (in the sense that only class that defines the signal can emit it) by appending QPrivateSignal argument to the signal method:

class MyObject : public QObject {
 Q_OBJECT
...
Q_SIGNALS:
 void error(int code, const QString &message, QPrivateSignal);
};

QPrivateSignal is a type that is defined inside the Q_OBJECT macro, so it’s private and as such only MyObject class can emit the signal, since only MyObject can instantiate QPrivateSignal:

void MyObject::handleError(int code, const QString &message)
{
 Q_EMIT error(code, message, QPrivateSignal{});
}

QCoro has a feature that makes it possible to co_await a signal emission and returns the signals arguments as a tuple:


MyObject myObject;
const auto [code, message] = co_await qCoro(&myObject, &MyObject::handleError);

While it was possible to co_await a “private” signal previously, it would get return the QPrivateSignal value as an additional value in the result tuple and on some occasions would not compile at all.

In QCoro 0.10, we can detect the QPrivateSignal argument and drop it inside QCoro so that it does not cause trouble and does not clutter the result type.

Achieving this wasn’t simple, as it’s not really possible to detect the type (because it’s private), e.g. code like this would fail to compile, because we are not allowed to refer to Obj::QPrivateSignal, since that type is private to Obj.

template<typename T, typename Obj>
constexpr bool is_qprivatesignal = std::same_as_v<T, typename Obj::QPrivateSignal>;

After many different attempts we ended up abusing __PRETTY_FUNCTION__ (and __FUNCSIG__ on MSVC) and checking whether the function’s name contains QPrivateSignal string in the expected location. It’s a whacky hack, but hey - if it works, it’s not stupid :). And thanks to improvements in compile-time evaluation in C++20, the check is evaluated completely at compile-time, so there’s no runtime overhead of obtaining current source location and doing string comparisons.

Source Code Reorganization (again!)

Big part of QCoro are template classes, so there’s a lot of code in headers. In my opinion, some of the files (especially qcorotask.h) were getting hard to read and navigate and it made it harder to just see the API of the class (like you get with non-template classes), which is what users of a library are usually most interested in.

Therefore I decided to move definitions into separated files, so that they don’t clutter the main include files.

This change is completely source- and binary-compatible, so QCoro users don’t have to make any changes to their code. The only difference is that the main QCoro headers are much prettier to look at now.

Bugfixes

QCoro::waitFor() now re-throws exceptions (#172, Daniel Vrátil)
Replaced deprecated QWebSocket::error with QWbSocket::errorOccured in QCoroWebSockets module (#174, Marius P)
Fix QCoro::connect() not working with lambdas (#179, Johan Brüchert)
Fix library name postfix for qmake compatibilty (#192, Shantanu Tushar)
Fix std::coroutine_traits isn't a class template error with LLVM 16 (#196, Rafael Sadowski)

Full changelog

See changelog on Github

QCoro 0.8.0 Release Announcement

2023-01-31T19:53:00+0000

This is a rather small release with only two new features and one small improvement.

Big thank you to Xstrahl Inc. who sponsored development of new features included in this release and of QCoro in general.

And as always, thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

The original release announcement on qcoro.dvratil.cz.

Improved `QCoro::waitFor()`

Up until this version, QCoro::waitFor() was only usable for QCoro::Task<T>. Starting with QCoro 0.8.0, it is possible to use it with any type that satisfies the Awaitable concept. The concept has also been fixed to satisfies not just types with the await_resume(), await_suspend() and await_ready() member functions, but also types with member operator co_await() and non-member operator co_await() functions.

`QCoro::sleepFor()` and `QCoro::sleepUntil()`

Working both on QCoro codebase as well as some third-party code bases using QCoro it’s clear that there’s a usecase for a simple coroutine that will sleep for specified amount of time (or until a specified timepoint). It is especially useful in tests, where simulating delays, especially in asynchronous code is common.

Previously I used to create small coroutines like this:

QCoro::Task<> timer(std::chrono::milliseconds timeout) {
 QTimer timer;
 timer.setSingleShot(true);
 timer.start(timeout);
 co_await timer;
}

Now we can do the same simply by using QCoro::sleepFor().

Read the documentation for QCoro::sleepFor() and QCoro::sleepUntil() for more details.

`QCoro::moveToThread()`

A small helper coroutine that allows a piece of function to be executed in the context of another thread.

void App::runSlowOperation(QThread *helperThread) {
 // Still on the main thread
 ui->statusLabel.setText(tr("Running"));

 const QString input = ui->userInput.text();

 co_await QCoro::moveToThread(helperThread);
 // Now we are running in the context of the helper thread, the main thread is not blocked

 // It is safe to use `input` which was created in another thread
 doSomeComplexCalculation(input);

 // Move the execution back to the main thread
 co_await QCoro::moveToThread(this->thread());
 // Runs on the main thread again
 ui->statusLabel.setText(tr("Done"));
}

Read the documentation for QCoro::moveToThread for more details.

Full changelog

See changelog on Github

Daniel Vrátil's blog Daniel Vrátil's blog category feed

QCoro

KDE

cmake-package

QCoro 0.13.0 Release Announcement

Directly Awaiting Qt Types in AsyncGenerator Coroutines

Other Features and Changes

Bugfixes

Full changelog

Support

Rust: linking static C/C++ libraries with LTO

The Backstory

A Suspect is Identified

But…why?

Cross-language LTO with cxx

Conclusion

Old New Blog

Comments

Happy Holidays 🎄

QCoro 0.11.0 Release Announcement

QCoro::LazyTask<T>

Defined Semantics for Awaiting Default-Constructed and Moved-From Tasks

Compiler Support

Other Features and Changes

Bugfixes

Full changelog

Support

KDE PIM Sprint 2024 Report

Day 0

Milestones

E2E Testing of Resources

Day 1

Day 2

Conclusion

QCoro 0.10.0 Release Announcement

Support for awaiting Qt signals with QPrivateSignal

Source Code Reorganization (again!)

Bugfixes

Full changelog

QCoro 0.8.0 Release Announcement

Improved QCoro::waitFor()

QCoro::sleepFor() and QCoro::sleepUntil()

QCoro::moveToThread()

Full changelog

Cross-language LTO with `cxx`

`QCoro::LazyTask<T>`

Improved `QCoro::waitFor()`

`QCoro::sleepFor()` and `QCoro::sleepUntil()`

`QCoro::moveToThread()`