The Qt 6.7 feature freeze is today, and we now start the process of further stabilizing the code. The actual release is still a few months off, but I thought I would look ahead at bit at what improvements are in store for font handling in Qt and Qt Quick. More specifically there are three things discussed: Variable font support, a brand new "large font" text renderer and font shaping feature support.
Let’s go for my web review for the week 2023-49.
Tags: tech, framasoft, privacy, social-media, foss
Another important software release. Let’s wish luck to the new maintainers!
https://framablog.org/2023/12/05/mobilisation-v4-the-maturity-stage/
Tags: tech, wikipedia, knowledge, programming
Interesting move, I’m wondering how far this will go. Reuse of those functions in other Wikimedia project will be critical to its success.
Tags: tech, wikipedia, knowledge, community, sociology
Very interesting study, shows how toxic comments impact contributions. Gives a good idea of the probability for people to leave. In the case of Wikipedia this highlights reasons which contribute to the lack of diversity in the contributors. This is a complex community issue in general, this studies does a good thing by shedding some light on the dynamics in the case of Wikipedia.
https://academic.oup.com/pnasnexus/article/2/12/pgad385/7457939?login=false
Tags: tech, python, community
The fact that they felt the need to write such a letter is troubling. What’s going on in the Python Software Foundation really? Something needs to be fixed it seems.
https://pythonafrica.blogspot.com/2023/12/an-open-letter-to-python-software_5.html
Tags: tech, web, mozilla, google
Let’s hope it won’t get there… I wish people would abandon Chrome en masse. I unfortunately don’t see it happening and it’ll just weaken the Web.
https://www.brycewray.com/posts/2023/11/firefox-brink/
Tags: tech, google, browser, attention-economy
Still using Chrome? What are you waiting for to change for another browser which doesn’t play against your interests.
Tags: tech, automotive, privacy
A senator is stepping up and rightfully pointing the finger at automakers. Let’s hope more will follow.
Tags: tech, DRM, copyright
If you can’t download it without DRMs you just don’t own it, you’re renting it. This is completely different.
https://www.theverge.com/2023/12/5/23989290/playstation-digital-ownership-sucks
Tags: tech, security, bios
Fascinating vulnerability. When the BIOS is at fault with a crappy image parser… you can’t do much to prevent problems from happening.
Tags: tech, ai, gpt, surveillance, spy
Definitely one of the worrying aspects of reducing human labor needs for analyzing texts. Surveillance is on the brink of being increased thanks to it.
https://www.schneier.com/blog/archives/2023/12/ai-and-mass-spying.html
Tags: tech, ai, machine-learning, gpt, copyright
A glimpse into how those generator models can present a real copyright problem… there should be more transparency on the training data sets.
https://www.404media.co/google-researchers-attack-convinces-chatgpt-to-reveal-its-training-data/
Tags: tech, ai, machine-learning, gpt, copyright, criticism
This is clearly an uphill battle. And yes, this is because it’s broken by design, it should be opt-in and not opt-out.
https://neil-clarke.com/block-the-bots-that-feed-ai-models-by-scraping-your-website/
Tags: tech, ai, machine-learning, gpt
The Large Language Model arm race is still going strong. Models are still mostly hidden behind APIs of course, and this is likely consuming lots of energy to run. Results seem interesting though, even though I suspect they’re over inflating the “safety” built in all this. Also be careful of the demo videos, they’ve been reported as heavily edited and misleading…
https://blog.google/technology/ai/google-gemini-ai/#availability
Tags: tech, linguistics, ai, machine-learning, gpt
LLMs training had a bias from the start… and now we got a feedback loop since people are posting generated content online which is then used for training again. Expect idiosyncrasies to increase with time.
https://blog.j11y.io/2023-11-22_multifaceted/
Tags: tech, ai, machine-learning, gpt, translation, speech
Now this is a very interesting use of generator models. I find this more exciting than the glorified chatbots.
https://ai.meta.com/research/seamless-communication/#our-approach
Tags: tech, ai, machine-learning, gpt, foss
Very interesting review, we can see some interesting strengths and weaknesses. Also gives a good idea of the different ways to evaluate such models.
https://arxiv.org/abs/2311.16989
Tags: tech, security, server, self-hosting
Could indeed turn into a nice alternative to fail2ban.
https://blog.ppom.me/en-reaction/
Tags: tech, web, services, webhooks
Interesting attempt at having webhooks implementation a bit more standardized. This is indeed needed, currently everyone does them in slightly different ways and sometimes the quality is debatable. If it gets adopted it’d give a good baseline.
https://www.standardwebhooks.com/
Tags: tech, date, time, unix, complexity
Good reminder that the raw UNIX timestamps have interesting properties and often are enough not necessarily needing to rely on something more complex. Also gives nice criteria for picking between said timestamps and higher level types.
https://scorpil.com/post/you-dont-need-datetime/
Tags: tech, web, html, css, frontend
Nice examples showing JavaScript use can be reduced in the browser. HTML and CSS are gaining nice features.
https://www.htmhell.dev/adventcalendar/2023/2/
Tags: tech, tests, documentation
Interesting approach to reduce the amount of undocumented features because we simply forgot to update the documentation. Shows a few inspiring tricks to get there.
https://simonwillison.net/2018/Jul/28/documentation-unit-tests/
Tags: tech, c++
Good walkthrough the finer points of members initialization in C++. Worth keeping in mind.
https://www.sandordargo.com/blog/2023/11/22/struct-initialization
Tags: tech, programming, type-systems
Somehow unsurprising, this is often the case: less validation code, but also less automated tests. With types you can write unwanted states out of existence.
https://evanhahn.com/when-static-types-make-your-code-shorter/
Tags: tech, rust, optimization, profiling
The Rust tooling makes it super easy to profile your programs. This is neat.
https://ntietz.com/blog/profiling-rust-programs-the-easy-way/
Tags: tech, graphics, 3d, learning
Very nice collection of tidbits of information for the main topics in computer graphics. A good way to get started or refresh the basics.
https://mrl.cs.nyu.edu/~perlin/graphics/
Tags: tech, web, game, 3d, simulation
Very cool simplified simulator. Gives a good idea of how this roughly works.
https://dalton-nrs.manchester.ac.uk/
Tags: tech, hacking, raspberry-pi, music, networking, usb
Alright, this is definitely a cool hack.
https://blog.rgsilva.com/smartifying-my-hi-fi-system/
Tags: tech, quality, project-management, programming
An interesting interpretation of what was behind the “move fast and break things” motto which is nowadays blindly followed by some. A bit of a long piece but does the job and propose a more complete view and an alternative approach.
https://blog.glyph.im/2023/12/safer-not-later.html
Tags: tech, tdd, design
Definitely this. Again TDD helps to work on the design, but it’s not a silver bullet which will give you the right design on a platter.
https://tidyfirst.substack.com/p/tdd-isnt-design
Tags: tech, culture, blameless, quality, trust
Shows why it’s important to go for a blameless culture, also outside of postmortem. This is definitely not easy but worth it.
https://www.gybe.ca/a-few-words-about-blameless-culture/
Tags: tech, organization, strategy, planning
Good blueprint for building up and following up (the most important part really) of a strategy in your organization.
https://www.lenareinhard.com/articles/annual-engineering-organization-strategy-planning
Tags: tech, remote-working
Looks like remote work is here to stay for good now.
https://www.cnbc.com/2023/11/30/return-to-office-is-dead-stanford-economist-says-heres-why.html
Tags: business, organization, decision-making
Good point on why you don’t want to drive your organization simply on RFCs. Yet another fad of “this worked for them, let’s do it as well”… per usual this fails to take into account the specificity of the context where it worked.
https://jacobian.org/2023/dec/1/against-rfcs/
Tags: tech, management, decision-making
Nice ideas for decision making in larger groups.
https://jacobian.org/2023/dec/5/how-to-decide/
Bye for now!
We bring you another 5.2 series bug fix release with Krita 5.2.2! Check out release notes for everything that was new in Krita 5.2.0.
Some of the highlights in this bug fix release is that we managed to track down a frequent crash on android, as well as fixing a bug where brush presets with masked brushes were not loaded correctly.
If you’re using the portable zip files, just open the zip file in Explorer and drag the folder somewhere convenient, then double-click on the Krita icon in the folder. This will not impact an installed version of Krita, though it will share your settings and custom resources with your regular installed version of Krita. For reporting crashes, also get the debug symbols folder.
Note that we are not making 32 bits Windows builds anymore.
The separate gmic-qt AppImage is no longer needed.
(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)
Note: if you use macOS Sierra or High Sierra, please check this video to learn how to enable starting developer-signed binaries, instead of just Apple Store binaries.
We consider Krita on ChromeOS as ready for production. Krita on Android is still beta. Krita is not available for Android phones, only for tablets, because the user interface requires a large screen.
For all downloads, visit https://download.kde.org/stable/krita/5.2.2/ and click on Details to get the hashes.
The Linux AppImage and the source .tar.gz and .tar.xz tarballs are signed. The signatures are here (filenames ending in .sig).
Please support Krita by making a donation or joining the development fund!
The post Krita 5.2.2 Released! appeared first on Krita.
For quite some time, I have been bothered by this thought: Individual programming languages (C++, Rust, Go, etc.) are traditionally viewed as walled gardens. If your main() function is written in C++, you had better find yourself C++ libraries like Qt to build the rest of your codebase with. Do you want to use Flutter to build your app’s user interface? Get ready to build the logic in Flutter, too. Do you really want to use that Rust library to make your application safer? You get to either rewrite the whole app in Rust or build an ugly extern "C" wrapper around it that won’t fit well in your object-oriented C++ code.
This has been the standard view on using multiple programming languages for many years. However, I’ve decided that this view is fundamentally flawed, because every compiled language uses the same set of concepts when it is compiled:
ervin
_Z3foov as the identifier for void foo(). This string is always reproducible; for example, both Clang and GCC on Linux follow the Itanium C++ ABI convention for mangling function names.call instruction or equivalent to move control to the function. For example, to call void foo() from earlier, the compiler converts a C++ statement foo(); into the assembly call _Z3foov. The assembler then replaces call with the appropriate opcode and replaces _Z3foov with the location of the first instruction identified by _Z3foov.ret instruction or equivalent.class Foo
{
void foo(int bar);
int baz;
};
your code actually compiles to something that is better represented this way:
class Foo
{
int baz;
};
void foo(Foo *this, int bar);
Since every compiled programming language uses the same concepts to compile, why can’t they just interact?
Before we go any further, I’d like to give an example of what we want to achieve:
// file: main.cpp
#include "rustmodule.h"
// or in an ideal C++ 20 world:
// import rustmodule;
int main()
{
foo();
return 0;
}
// file: rustmodule.h
#pragma once
// this is defined in Rust
void foo();
// file: rustmodule.rs
pub fn foo() {
println!("Hello from Rust");
}
We want to be able to compile those files and get an executable file that prints Hello from Rust to stdout.
Now let’s look at why this won’t just work out of the box.
The most obvious reason that compiled programming languages can’t just interact with each other is the most obvious one: syntax. C++ compilers don’t understand Rust, and Rust compilers don’t understand C++. Thus neither language can tell what functions or classes the other is making available.
Now, you might be saying “But if I use a C++ .h file to export functions and classes to other .cpp files, certainly I could make a .h file that tells C++ that there is a Rust function fn foo() out there!” If you did say (or at least think) that, congratulations! You are on the right track, but there are some other less obvious things we need to talk about.
The first major blocker to interoperability is name mangling. You can certainly make a .h file with a forward declaration of void foo();, but the C++ compiler will then look for a symbol called _Z3foov, while the Rust compiler will have mangled fn foo() into _ZN10rustmodule3foo17hdf3dc6f68b54be51E. Compiling the C++ code starts out OK, but once the linking stage is reached, the linker will not be able to find _Z3foov since it doesn’t exist.
Obviously, we need to change how the name mangling behaves on one side or the other. We’ll come back to this thought in a moment.
The second major blocker is data layout. Put simply, different compilers may treat the same struct declaration differently by putting its fields at different locations in memory.
The third and final blocker I want to look at here is standard libraries. If you have a C++ function that returns an std::string, Rust won’t be able to understand that. Instead, you need to implement some sort of converter that will convert C++ strings to Rust strings. Similarly, a Rust Vec object won’t be usable from C++ unless you convert it to something C++ understands.
Let’s investigate how we can fix the first problem, name mangling.
extern "C" and why it sucksThe easy way is to use the extern "C" feature that nearly every programming language has:
// file: main.cpp
#include "rustmodule.h"
// or in an ideal C++ 20 world:
// import rustmodule;
int main()
{
foo();
return 0;
}
// file: rustmodule.h
#pragma once
extern "C" void foo();
// file: rustmodule.rs
#[no_mangle]
pub extern "C" fn foo() {
println!("Hello from Rust");
}
This actually will compile and run (assuming you link all the proper standard libraries)! So why does extern "C" suck? Well, by using extern "C" you give up features like these:
It’s possible to create wrappers around the extern "C" functions to crudely emulate these features, but I don’t want complex wrappers that provide crude emulation. I want wrappers that directly plumb those features and are human readable! Furthermore, I don’t want to have to change the existing source, which means that the ugly #[no_mangle] pub extern "C" must go!
D is a programming language that has been around since 2001. Although it is not source compatible with C++, it is similar to C++. I personally like D for its intuitive syntax and great features, but for gluing Rust and C++ together, D stands out for two reasons: extern(C++) and pragma(mangle, "foo").
With extern(C++), you can tell D to use C++ name mangling for any symbol. Therefore, the following code will compile:
// file: foo.cpp
#include <iostream>
void bar();
void foo()
{
std::cout << "Hello from C++\n";
bar();
}
// file: main.d
import std.stdio;
extern(C++) void foo();
extern(C++) void bar()
{
writeln("Hello from D");
}
void main()
{
foo();
}
However, it gets better: we can use pragma(mangle, "foo") to manually override name mangling to anything we want! Therefore, the following code compiles:
// file: main.d
import std.stdio;
pragma(mangle, "_ZN10rustmodule3foo17h18576425cfc60609E") void foo();
pragma(mangle, "bar_d_function") void bar()
{
writeln("Hello from D");
}
void main()
{
foo();
}
// file: rustmodule.rs
pub fn foo() {
println!("Hello from Rust");
unsafe {
bar();
}
}
extern {
#[link_name = "bar_d_function"] fn bar();
}
With pragma(mangle, "foo") we can not only tell D how Rust mangled its function, but also create a function that Rust can see!
You might be wondering why we had to tell Rust to override mangling of bar(). It’s because Rust apparently won’t apply any name mangling to bar() for the sole reason that it is in an extern block; in my testing, not even marking it as extern "Rust" made any difference. Go figure.
You also might be wondering why we can’t use Rust’s name mangling overrides instead of D’s. Well, Rust only lets you override mangling on function forward declarations marked as extern, so you can’t make a function defined in Rust masquerade as a C++ function.
We can now use D to glue our basic example together:
// file: main.cpp
#include "rustmodule.h"
// or in an ideal C++ 20 world:
// import rustmodule;
int main()
{
foo();
return 0;
}
// file: rustmodule.h
#pragma once
// this is in Rust
void foo();
// file: rustmodule.rs
pub fn foo() {
println!("Hello from Rust");
}
// file: glue.d
@nogc:
// This is the Rust function.
pragma(mangle, "_ZN10rustmodule3foo17h18576425cfc60609E") void foo_from_rust();
// This is exposed to C++ and serves as nothing more than an alias.
extern(C++) void foo()
{
foo_from_rust();
}
In this example, when main() calls foo() from C++, it is actually calling a D function that can then call the Rust function. It’s a little ugly, but it’s possibly the best solution available that leaves both the C++ and Rust code in pristine condition.
Nobody wants to have to write a massive D file to glue together the C++ and Rust components, though. In fact, nobody even wants to write the C++ header files by hand. For that reason, I created a proof-of-concept tool called polyglot that can scan C++ code and generate wrappers for use from Rust and D. My eventual goal is to also wrap other languages, but as this is a personal project, I am not developing polyglot very quickly and it certainly is nowhere near the point of being ready for production use in serious projects. With that being said, it’s really amazing to compile and run the examples and know that you are looking at multiple languages working together.
I originally planned to write on this topic in one blog post, but there are a lot of interesting things to cover, so I will stop here for now. In the next installment of this series we will take a look at how we can overcome the other two major blockers to language interoperability.
If you like this article and want to read similar material, consider subscribing via our RSS feed.
Subscribe to KDAB TV for similar informative short video content.
KDAB provides market leading software consulting and development services and training in Qt, C++ and 3D/OpenGL. Contact us.
The post Mixing C++ and Rust for Fun and Profit: Part 1 appeared first on KDAB.
Over 120 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.
Today they all get new bugfix source releases with updated translations, including:
Distro and app store packagers should update their application packages.
Broken Rules, the Vienna-based game development studio known for their award-winning games Old Man’s Journey and Gibbon: Beyond the Trees, became a Krita sponsor earlier this year.
Known for their thoughful and candid approach to game making it comes as no surprise that their Co-Founder and Creative Director Clemens Scott has a strong stance on software projects:
“In a world full of subscription services, forced updates, feature bloat and vendor lock-ins, it’s refreshing to see that alternatives are cropping up. Projects such as Blender have proven that free, open-source software can reach industry-grade levels of quality and provide a viable alternative to the status quo. I’ve been using Krita on a regular basis for the past two years and I would love to see it become as ubiquituous as its corporate competitors.”
Old Man’s Journey was the Apple Design Award Winner 2017 and iPad Game of the Year 2017.
Gibbon: Beyond the tree won the Apple Design Award in 2022 in the category Social Impact.
Eloh won the Apple Design Award in 2019.
Clemens used Krita mainly for personal projects, such as various illustrations throughout his memex, but also for sketching out ideas on level designs for Gibbon: Beyond the Trees, which you can find on his personal page as well.
We appreciate their support and contribution to keeping Krita going strong!
Broken Rules was founded in 2009 and has a track record of creative left-field works. Their games focus on originality, simplicity, refined game mechanics and rich interactivity.
Broken Rules founding members regard video games as important cultural achievements and seek to make every game a new and meaningful experience that lingers in the players’ minds long after they powered down their computers.
The post Broken Rules Sponsors Krita! appeared first on Krita.
Thank you to everyone who reported issues and contributed to QCoro. Your help is much appreciated!
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.
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.
QCoro::waitFor() now re-throws exceptions (#172, Daniel Vrátil)QWebSocket::error with QWbSocket::errorOccured in QCoroWebSockets module (#174, Marius P)QCoro::connect() not working with lambdas (#179, Johan Brüchert)std::coroutine_traits isn't a class template error with LLVM 16 (#196, Rafael Sadowski)Tuesday, 5 December 2023. Today KDE releases a bugfix update to KDE Plasma 5, versioned 5.27.10.
Plasma 5.27 was released in February 2023 with many feature refinements and new modules to complete the desktop experience.
The bugfixes are typically small but important and include:
