Re: [Development] Exceptions
On Thursday 23 May 2024 09:50:15 GMT-3 Martin Storsjö wrote: > On Windows (on platforms that use SEH) this is also the case, as SEH > unwind info is needed for handling various SEH exceptions, that may be > used even if C++ exceptions aren't. > > But on aarch64 darwin, unwind tables don't seem to be enabled by default. And because of this, it's highly likely you can unwind through Win32 frames in our stack but cannot through Cocoa frames. So even if we did add unwind info to QtWidgets, there's a good chance it wouldn't make a difference. But if someone does check that you can throw through Cocoa frames, then it would be worth having the unwind info, if nothing else to support the case of "emergency save in main()". -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Exceptions
On Thursday 23 May 2024 04:07:20 GMT-3 Volker Hilsheimer via Development
wrote:
> From what I see, the problem is bigger than “don’t let exceptions run
> through the event loop” though. In my example, even a try/catch around
> calling the parent class implementation of QWidget::event will not work,
> because QWidget::event doesn’t have the unwind information.
>
> bool event(QEvent *e) override {
> try {
> return QWidget::event(e);
> }
> catch (const std::runtime_error& e) {
> qDebug() << "Exception in event()!" << e.what();
> }
> return false;
> }
>
>
> In practice, that means that you cannot meaningfully use exceptions in a Qt
> application (or library with possible binary compatibility commitments)
> unless you catch them on the lowest stack frame that is not Qt. Which is
> perhaps not terribly useful.
That's what I said: you should treat all event handlers and slots as noexcept
and catch your exceptions there.
There's NO reason why clicking a button in a UI should generate
std::runtime_error. That's always an application bug if it happens, so it
should be treated as a bug. Crashing with the full throw-point stack frame is
a good idea.
The contract between signal emitter and slots also has no room for exceptions.
The connection is N:M and the emitter doesn't care if the slot failed to do
its work. Therefore, yes, slots should also be noexcept.
In both cases, that assumes when being called from the Qt machinery. If you're
calling those functions directly, feel free to throw. How you determine the
situation is left as an exercise to the reader.
I agree on questioning whether this is useful or not. But I also think it's
besides the point: we are not going to change because of the reasons above.
> So the question is what we want to do about
> https://doc.qt.io/qt-6/exceptionsafety.html. It starts with the disclaimer
> that this is not feature complete, but that’s been the case since the dawn
> of time, and on ARM, even common cases won’t work as advertised here.
> Perhaps a good start would be to add a warning that none of this will work
> on ARM architecture, unless Qt is compiled explicitly with exception
> handling enabled? Which then might ideally be something we support in the
> build system through a toggle.
That definitely needs fixing. At a minimum, the #recovering-from-exceptions
section is wrong, because we know the exception can't propagate through the
event loop.
The #signals-and-slots section is what I said above.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Exceptions
On Wednesday 22 May 2024 06:38:28 GMT-3 Volker Hilsheimer via Development wrote: > As long as Qt is built with exception support We don't support toggling that on and off any more and haven't for a while. QtCore and QtGui are compiled with exceptions enabled; all the other modules are not. In paticular, QtWidgets is not and that therefore applies to QApplication::notify(). That means you MUST NOT let exceptions run through the event loop of a Widgets application. You shouldn't let it happen for any application because Bad Things Will Happen™ because we don't test what happens if you do. Your very best bet is that you end up back in main() where you can do an emergency save using non-Qt code and terminate the application. But since we don't test, we can't guarantee that even the exceptions-enabled code in QtCore and QtGui won't just crash because of some unsuspected condition being violated. > There might be code paths (esp on macOS) that go into the native functions > and back into Qt, and perhaps some of those native stack frames eat the > exception or don’t pass it on otherwise. As far as I understand, the problem is that on ARM, there *is* no native stack frame, unlike on x86. Stack unwinding on x86 is very frequently possible because the architecture saves the return address on the stack and most code is compiled with frame pointers, even when exceptions are disabled. On ARM and other RISC architectures, the return address is saved in a register and it's the responsibility of the prologue of the called function to save it somewhere in the stack if it is not a leaf function. The problem is answering: where? This requires reading the unwind information. Which isn't present in QtWidgets. That explains why Dennis reports being able to throw through QApplication::notify() on Intel Macs but not on ARM Macs. Plus, yes, we often have frames from third party libraries in our stack that aren't capable of unwinding the stack either. Therefore, the Qt recommendation is that you treat all event handlers and all slot invocations as noexcept and catch your own exceptions before they go back to Qt code. This is the reason why we decided it was ok to disable exceptions in QtWidgets itself, because we didn't think we could guarantee survivability in the first place. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Thursday 16 May 2024 09:55:39 GMT-7 Ilya Fedin wrote: > Dimitris seem to have a problem writing to the list right now but what > he found is that running the tests under gdb makes them not hang. > Perhaps this means that it's not X server who haven't replied but Xlib > (or libc/kernel?) who fails to notice the reply? Yes, it could be a race condition inside libX11. I know libxcb is designed to not have globals, but I am not so sure about libX11. libxcb's .data + .bss is a mere 0xa8 bytes, while libX11's is 0x38e8. That's a lot of global data. So it's entirely possible that GDK isn't getting the reply it needs because that reply was sent to our Display and connection and thus handled by our thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Thursday 16 May 2024 06:06:50 GMT-7 Ilya Fedin wrote: > After discussion with Thiago, it seems that the most interesting part > is getting a backtrace from X server while a test is in hanged state, as > tests hang waiting an answer from X server which seem to be busy by > some other thing (backtrace from it should answer what it is doing). The X server is NOT hung. The backtrace will not tell you anything. I've told you before: when the next application runs, it doesn't hang connecting to the X server, so the X server can't be hung. All we know is the reply to the XInternAtom didn't arrive. You need to deduce a reason why the X server would fail to send that. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Wednesday 15 May 2024 13:22:01 GMT-7 Ilya Fedin wrote: > Didn't help. I clicked this time on the details link and noticed that > every job using GNOME (RHEL 8.8, RHEL 9.2, SLES 15 SP5, Ubuntu 22.04) > hangs the same way while openSUSE 15.5 using KDE is OK (which shouldn't > use the gtk platformtheme, though). Which is surprising given that not > me nor the person from QTBUG-124303 which uses popOS 22.04 seem to have > those hangs. Perhaps the CI has something specific to its setup that > makes it consistenly have the problem... Then maybe just detect whether the Gtk3 theme is loaded (which means GDK is in use in the main thread) and don't use your new technique. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Wednesday 15 May 2024 03:12:26 GMT-7 Ilya Fedin wrote: > > But I still can't explain why XInternAtom would block. You'd need to > > get a backtrace of the X.org process to see if it is blocked. What > > does it mean to intern an atom? Does it send something to the root > > window to register it? > > As far as I understand it just registers a string as an integer ID > referred to as atom. So it's apparently just some string-integer map > inside X server. Also note that other tests ran fine after these deadlocked. So if the X server had had a major bug, we should be seeing everything after this test failing. It's possible the bug does exist, just causing the reply to get dropped for this connection. But as it's that simple an implementation as you say, it isn't likely. > Yeah. Given that the event loop is in GTK code, it means it either > successfully handled the event in Qt code or haven't got to it yet. > None of which really explain the hang (other than a possibility of > triggering some bug inside X server). You said that GDK is using a different libxcb and libX11 connection from Qt. That means the Qt XCB code could not handle event sent to GDK nor vice-versa. > By the way, high DPI works ok for me on Plasma 6 with both X11 and > Wayland. I forgot to mention: add a second, high-DPI monitor to the right. I had patched Qt 5 to hack around the positions in second monitor, but the patch doesn't apply in Qt 6. So things fail there, with positions for sub-menus or windows not to correct. Beyond that, both for kwin- and plasmashell-provided components (titlebar, status bar), the icons were wrong because they were not scaled up. I think those two override the scale factor somehow. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 13:24:12 GMT-7 Ilya Fedin wrote: > On Tue, 14 May 2024 12:59:29 -0700 > > Thiago Macieira wrote: > > Assuming that Canonical did not patch libgdk, > > Well, that is a very optimistic assumption: > http://archive.ubuntu.com/ubuntu/pool/main/g/gtk+3.0/gtk+3.0_3.24.33-1ubuntu > 2.1.debian.tar.xz > > I see 24 pathes in there. Do any of them affect gdkeventsource.c? I don't see any. > > this is stuck trying to > > XInternAtom for "_GTK_EDGE_CONSTRAINTS", reacting to an xevent of > > type PropertyNotify. > > https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/x11/gdkdisplay-x11. > > c#L1068 > > > > I can't tell you why it's stuck. Why would the X server not send a > > reply to that? > > I don't know any reason for _GTK_EDGE_CONSTRAINTS exactly but generally > I saw reports X11 deliberately not answering to clients using GLX when > on another tty. Yes, I remember that and have experienced the symptom. AFAIU, you're slightly mistaken in the actual root cause: it's not the X11 server deliberately not answering. The X.org server is frozen too, because the KMS driver in the kernel refuses to answer. > I'm doubt that's the case here though given that it > doesn't hang with other patches. The only theory I can wrap my head of > is that querying RESOURCE_MANAGER property momentally after it changes > breaks X server somehow. I tried to queue reading the property in event > loop to delay it a bit in earlier versions of the patch, I also tried > replacing blocking wait for more bytes with event loop based approach, > none of which helped. I doubt it's the X server. More likely, it's GNOME itself. Is the X root window provided by a specific process in the desktop, or does it just exist? If it's the former, it might be GNOME's fault. It would be worth checking if Gtk-4 has the same issue. But I still can't explain why XInternAtom would block. You'd need to get a backtrace of the X.org process to see if it is blocked. What does it mean to intern an atom? Does it send something to the root window to register it? Also... X.org isn't being actively developed any more. KDE Plasma Workspace 6 has made it nigh impossible to use X with High DPI (it might be Qt's fault), which is again something that your patch affects and is affected by. Is it still worth trying to patch X11 for more High DPI? Or just throw the towel and use Wayland? > Although I remember that Liang Qi once reproduced it only with > `-sanitize address` (while it was ok without it for him, too). So > perhaps there's a chance ASAN breaks poll() in some way? And I guess > it's possible nothing will help then... Unlikely. The most likely scenario is that XInternAtom() didn't get a reply because no reply was sent. So under what conditions would there be no reply to that operation? Looking at your patch again, you've added code that reacts to an XCB_PROPERTY_NOTIFY, which is the the same thing that GDK is getting stuck on. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 12:30:42 GMT-7 Thiago Macieira wrote: > Those may be inlines. If I try addr2line, then the frames are: Using gdb instead of addr2line: frame 6: Line 116 of "x11/../../../../../gdk/x11/gdkproperty-x11.c" starts at address 0x773d8 and ends at 0x773eb . frame 7: Line 1068 of "x11/../../../../../gdk/x11/gdkdisplay-x11.c" starts at address 0x6bc29 and ends at 0x6bc32 . frame 8: Line 51 of "x11/../../../../../gdk/x11/gdkeventtranslator.c" starts at address 0x6d191 <_gdk_x11_event_translator_translate+209> and ends at 0x6d195 <_gdk_x11_event_translator_translate+213>. frame 9: Line 243 of "x11/../../../../../gdk/x11/gdkeventsource.c" starts at address 0x70d28 <_gdk_x11_display_queue_events+728> and ends at 0x70d2b <_gdk_x11_display_queue_events+731>. Assuming that Canonical did not patch libgdk, this is stuck trying to XInternAtom for "_GTK_EDGE_CONSTRAINTS", reacting to an xevent of type PropertyNotify. https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/x11/gdkdisplay-x11.c#L1068 I can't tell you why it's stuck. Why would the X server not send a reply to that? -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 12:30:42 GMT-7 Thiago Macieira wrote: > Those may be inlines. If I try addr2line, then the frames are: > gdk_x11_atom_to_xatom_for_display at ??:? > gdk_x11_lookup_xdisplay at ??:? > gdk_x11_display_broadcast_startup_message at ??:? > gdk_x11_drag_context_get_type at ??:? > gdk_display_get_event at ??:? Take those with a large grain of salt. I don't think they are correct. I don't see any path from gdk_x11_lookup_xdisplay() to gdk_x11_atom_to_xatom_for_display() in https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/x11/gdkdisplay-x11.c#L2142 I do see how gdk_x11_display_broadcast_startup_message() could require atoms (see inlined broadcast_xmessage from https://gitlab.gnome.org/GNOME/gtk/-/ blob/gtk-3-24/gdk/x11/gdkdisplay-x11.c#L2245). But I don't see gdk_x11_drag_context_get_type() at all in GNOME's GitLab server. If it were right, this function is declared but not defined anywhere. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 12:13:29 GMT-7 Thiago Macieira wrote: > #6 0x7fe3fc6e93d8 in gdk_x11_atom_to_xatom_for_display () at > /lib/x86_64- linux-gnu/libgdk-3.so.0 773d3: e8 58 7f fb ff call 2f330 773d8: 4c 89 e6mov%r12,%rsi That would mean libgdk was loaded at base 0x7fe3fc672000 > #10 0x7fe3fc6a8a99 in gdk_display_get_event () at /lib/x86_64-linux-gnu/ > libgdk-3.so.0 Doing the reverse math would say this is 0x36a99, which is: 36a93: ff 95 c0 00 00 00 call *0xc0(%rbp) 36a99: 8b 73 30mov0x30(%rbx),%esi and is inside gdk_display_get_event, so we're correct. Therefore, the unknown frames: > #7 0x7fe3fc6ddc29 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 gdk_x11_display_translate_event+4185 > #8 0x7fe3fc6df191 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 _gdk_x11_event_translator_translate+209 > #9 0x7fe3fc6e2d28 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 _gdk_x11_display_queue_events+728 Those may be inlines. If I try addr2line, then the frames are: gdk_x11_atom_to_xatom_for_display at ??:? gdk_x11_lookup_xdisplay at ??:? gdk_x11_display_broadcast_startup_message at ??:? gdk_x11_drag_context_get_type at ??:? gdk_display_get_event at ??:? File names and line numbers are missing in the Ubuntu packages. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 11:44:24 GMT-7 Thiago Macieira wrote: > Think in terms of side-effects. It doesn't care how Qt does it, but the > side- effect of what we are doing could be important, since we're sharing > libxcb internal state, the xcb_connection (I think), and the X11 server > itself. Backtrack from what you know: It's stuck inside XInternAtom waiting for a reply from the server. That means it's trying to get some information about an atom. It's stuck, meaning this must be a deadlock, which must be happening because the event is looping back to this application and that isn't responding. You don't have debugging symbols in the CI VMs, but you can get them locally. Get a VM or container using Ubuntu 22.04 and, with a little bit effort you can undo the address space randomisation and find out the unknown frame addresses based on the known ones: #6 0x7fe3fc6e93d8 in gdk_x11_atom_to_xatom_for_display () at /lib/x86_64- linux-gnu/libgdk-3.so.0 #7 0x7fe3fc6ddc29 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #8 0x7fe3fc6df191 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #9 0x7fe3fc6e2d28 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #10 0x7fe3fc6a8a99 in gdk_display_get_event () at /lib/x86_64-linux-gnu/ libgdk-3.so.0 You know 0x7fe3fc6a8a99 is in gdk_display_get_event(), so you should be able to deduce the base address libgdk got loaded at, and therefore recalculate which functions those three middle ones are. You can ask one of the Qt Company developers "acquire a VM" and get a core dump for this test's hang. You can then load the core dump in your VM/ container and see what the state of GDK was. Searching GDK 3.x sources, the most likely reason for that is information about the clipboard/selection status. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 09:23:50 GMT-7 Ilya Fedin wrote: > I fail to imagine how that could be... gtk shouldn't care how Qt gets > DPI and especially it shouldn't make it hang on XInternAtom (which > makes X server either to get an integer from its internal string-integer > map or increment the internal counter and add it to the aforementioned > map with the supplied string, as far as I understand, no > client-to-client messaging here). Think in terms of side-effects. It doesn't care how Qt does it, but the side- effect of what we are doing could be important, since we're sharing libxcb internal state, the xcb_connection (I think), and the X11 server itself. Have you tried running a simple test like tst_qguichronotimer in a loop to see if it is indeed a race condition? In any case, if all else fails, declare it an undiagnosed GDK bug and detect whether our dispatcher is QXcbGlibEventDispatcher. If it is, then don't use the new feature. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 08:25:14 GMT-7 Ilya Fedin wrote: > No, they don't, they only adding re-reading RESOURCE_MANAGER property > on the X11 root window once they update. > > The only thing I can assume is that the order of Qt+gtk requests is > triggering some bug in X server and it hangs... But I'm unable to > reproduce that myself to debug. Maybe the issue is something that you've stopped doing because you're now doing this. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
[Re-adding the list] On Tuesday 14 May 2024 08:02:05 GMT-7 Ilya Fedin wrote: > The thing is that I need debug symbols for those system libraries to > understand what is going on... Is there no way to get them on the CI? I don't think you do. I think you have enough information there: it's trying to get an atom and you must assume it's related to your changes. > As far as I understand, the code I changed is called only from the main > thread (the event thread is only reading the events but doesn't > handle them)... But that somehow affects gtk and I don't understand how > as the CI doesn't print the relevant gtk frames in the trace to examine > its code. Please confirm that your changes require that you reply to something requested from other applications. If so, make sure you can reply from the XCB event thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to do if tests hang on the CI and I can't reproduce that locally?
On Tuesday 14 May 2024 07:30:01 GMT-7 Ilya Fedin wrote: > I have a long standing (1.5 years) problem with > https://codereview.qt-project.org/c/qt/qtbase/+/427313 that the CI > hangs on so-called "cmptest". Previously the CI just reported that > timeout has happened and I had no idea what exactly happened. > Asking reviewers to get a backtrace to see where it hangs led to radio > silence. Good news is that the CI became better on this in those 1.5 > years and gives the following backtrace at least: > Thread 1 (Thread 0x7fe3fe4e78c0 (LWP 12267) "tst_qsettings"): #0 0x7fe4015d8bcf in __GI___poll (fds=0x7ffe5b94bdc8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fe4004f07e2 in () at /lib/x86_64-linux-gnu/libxcb.so.1 #2 0x7fe4004f0eb1 in () at /lib/x86_64-linux-gnu/libxcb.so.1 #3 0x7fe4004f1ea6 in xcb_wait_for_reply64 () at /lib/x86_64-linux-gnu/ libxcb.so.1 #4 0x7fe40136931c in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6 #5 0x7fe40134e888 in XInternAtom () at /lib/x86_64-linux-gnu/libX11.so.6 #6 0x7fe3fc6e93d8 in gdk_x11_atom_to_xatom_for_display () at /lib/x86_64- linux-gnu/libgdk-3.so.0 #7 0x7fe3fc6ddc29 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #8 0x7fe3fc6df191 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #9 0x7fe3fc6e2d28 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #10 0x7fe3fc6a8a99 in gdk_display_get_event () at /lib/x86_64-linux-gnu/ libgdk-3.so.0 #11 0x7fe3fc6e2f46 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0 #12 0x7fe40123ed3b in g_main_context_dispatch () at /lib/x86_64-linux-gnu/ libglib-2.0.so.0 #13 0x7fe401294258 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x7fe40123c3e3 in g_main_context_iteration () at /lib/x86_64-linux- gnu/libglib-2.0.so.0 #15 0x7fe401fd2bd0 in TestNamespace::QEventDispatcherGlib::processEvents(TestNamespace::QFlags) (this=0x55b7c0350c90, flags=...) at /home/qt/work/qt/qtbase/src/corelib/kernel/ qeventdispatcher_glib.cpp:395 #16 0x7fe3fd38b9aa in TestNamespace::QXcbGlibEventDispatcher::processEvents(TestNamespace::QFlags) (this=0x55b7c0350c90, flags=...) at /home/qt/work/qt/qtbase/src/plugins/ platforms/xcb/qxcbeventdispatcher.cpp:96 #17 0x7fe401b5436c in TestNamespace::QCoreApplication::processEvents(TestNamespace::QFlags, TestNamespace::QDeadlineTimer) (flags=..., deadline=...) at /home/qt/work/qt/ qtbase/src/corelib/kernel/qcoreapplication.cpp:1435 #18 0x7fe401c17e09 in TestNamespace::QTest::qWait(std::chrono::duration >) (msecs=...) at /home/qt/work/qt/qtbase/src/corelib/kernel/ qtestsupport_core.cpp:127 #19 0x7fe401c17d6d in TestNamespace::QTest::qWait(int) (msecs=50) at / home/qt/work/qt/qtbase/src/corelib/kernel/qtestsupport_core.cpp:94 > Still, this backtrace doesn't have debug symbols and doesn't really > help. Can I get a better backtrace from the CI somehow, with debug > symbols for glib, gtk3, Xlib and xcb? Who and how should I contact for > that? It *does* have debug symbols... for Qt. The problem is that it's getting stuck inside of libxcb and gdk (glib), which come from the OS. I don't know what gdk is doing, but it's stalled at gdk_x11_atom_to_xatom_for_display trying to XInternAtom. If I were to make a wild guess, it's trying to get something from a process, but that process is itself and because it's on a blocking call, it can't reply. I do note the XCB event handler thread is free, so you should check if your changes are allowing whichever reply this is to come from that separate thread. The above isn't cmptest. It's tst_qsettings. But you can see other tests having the same problem too, like tst_qguichronotimer. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Tuesday 7 May 2024 22:32:47 GMT-7 Marc Mutz via Development wrote: > b) that QtNetworkAuth gets the undesired QtGui dependency, which becomes > stale once new Core API is merged, but then has to be carried along for > BC reasons. Why does it need that dependency? QtNetworkAuth should never open a window and start the browser on its own *anyway* without the application or library developer telling it to do so. And if they want it to do so, why can't that be the connect() line to QDesktopServices? > c) that the user has to connect the pieces of the flow together > manually. The whole point of the code there is to _implement_ the flow, > though. That involves not only calling openUrl(), but also installing > URL handlers. If the user has to connect all the dots manually, because > parts of it are in QtGui, then a large percentage of the value of the > implementation is lost. I disagree. It needs to be a policy decision to do that, because the application may have reasons why it wants to do things differently. Though it needs to be easy too. > Plus, we'd set up the user for failure once we > come up with a new API to replace QDS: he will need to rewrite his > connect-the-dots code, against a very-probably changed QtNetworkAuth > API, too. If we continue to keep the flow implementation internal to > QtNetworkAuth as much as possible (and make more possible), then the > user of QtNetworkAuth falls into the pit of success. That assumes we will have something. I am not convinced yet that any application exists where the three conditions I mentioned in another email are met. And besides, you've just said that the replacement may have a different API. That implies we haven't finished designing it yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QToolButton::checkStateSet missing in Linux source build of Qt5.15.13-gpl?
On Tuesday 7 May 2024 12:20:26 GMT-7 Dennis Lühring wrote: > then something is strange > > 1. according to https://doc.qt.io/qt-5/qtoolbutton.html: QToolButton is > derived from QAbstractButton which contains checkStateSet [Re-adding the list, but I think dev is the wrong list] QAbstractButton is irrelevant here. Your error message was QToolButton::checkStateSet() *specifically* wasn't defined. It's not expected to because it wasn't added until 6.3. The only explanation I can come up with is that the headers don't match the library. > 2. my standard > SUSE-Tumbleweed Qt5 Package widgets lib contains the Method > /usr/lib64/libQt5Widgets.so.5.15.13 Indeed, so does it in mine: $ nm -DC /usr/lib64/libQt5Widgets.so.5.15.13 | grep QToolButton::checkState 0038eb40 T QToolButton::checkStateSet() That's a non-standard patch. It doesn't exist in the official 5.15.13 version. Someone backported an extra patch onto that release (it's https:// invent.kde.org/qt/qt/qtbase/-/commit/f74d263ff7de636e00094040a795b0763af41772). I don't know why they did that, but that's not important. The diagnosis is the same: your headers don't match the library you have. You have to match. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Tuesday 7 May 2024 10:50:09 GMT-7 Lars Knoll via Development wrote: > There could also be use cases where you have split your app into two parts, > a UI running in one process and a backend running in another one. The > backend doesn’t link against any GUI libraries, but might need to launch an > OAuth flow in response to something that’s been triggered by the UI. And > there could be many reasons why you’d want a process separation, security > being one of them. > > So I do believe there are valid use cases for opening a browser window from > a process that does not link against a GUI library. Given that the > implementation doesn’t require anything UI specific neither I don’t see why > we shouldn’t have it in Qt Core. I agree with the conclusion. But your premise is talking about it being a tightly-coupled UI and non-UI process components. So the non-UI component doesn't want to use QCoreDesktopServices::openUrl in the first place: it wants to communicate with its UI component through whichever communication mechanism it has established. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Tuesday 7 May 2024 10:03:21 GMT-7 Thiago Macieira wrote: > So I want to know of a use-case where all of the following are true: > * application is GUI-less (i.e., is a background service) > * application has no GUI counterpart > * application is definitely running in a GUI environment Rethinking a little here, if we drill d own one level it may make sense. Replace "application" with "library": One may want to make a library that has no GUI dependency and implements some network service. Therefore, they don't want to link to QtGui for QDesktopServices. If the functionality is in QtCore, then they could request the browser if the application is GUI. The problem is that said library needs a fallback if the application is *not* GUI. Moreover, I'd question the automatic launching of a browser as part of this library's behaviour. A better design would be for it to emit a signal indicating it requires something to happen and then to let the application or a wrapping library to make a policy decision on what to do. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QToolButton::checkStateSet missing in Linux source build of Qt5.15.13-gpl?
On Tuesday 7 May 2024 08:40:01 GMT-7 Dennis Luehring via Development wrote: > using that build im getting a linker error that > QToolButton::checkStateSet is not defined > > > > > mold: error: undefined symbol: QToolButton::checkStateSet() > > >>> referenced by mocs_compilation.cpp > >>> > >>> ../bin/libgui.a(mocs_compilation.cpp.o) QToolButton::checkStateSet() was added for Qt 6.2 by commit c9830c2fb902f26dc8b2df61dfadc2d7a7d2b30e. That is not a Pick-to: 5.15 and indeed it is not there in https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qtoolbutton.h? h=v5.15.13-lts-lgpl Therefore, your issue is that you've compiled something against the Qt 6 headers. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Tuesday 7 May 2024 08:51:03 GMT-7 Marc Mutz via Development wrote: > > I'd like to see some GUI-less Qt applications perform those services, but > > then they are highly limited on how to start the browser in the first > > place. Anything beyond "print URL to stdout" may not be acceptable at > > all, as they may be running *in* a GUI-less environment, such as my > > emailproxy case. > Given that std C++ still has no network classes, and Boost.Async is ... > an acquired taste, let's leave it at that ... I'd like to think that > QtCore+QtNetwork programs still have their place. At least I wouldn't > want to be the one ruling them out for our users. I agree with you there. But my point stands: GUI-less Qt applications may have no way of launching the browser in the first place because there is no GUI. If this is running as a service in the background, it needs communicate with its GUI front-end to perform the necessary actions. So I want to know of a use-case where all of the following are true: * application is GUI-less (i.e., is a background service) * application has no GUI counterpart * application is definitely running in a GUI environment An example of GUI-less, networking Qt applications are the Akonadi agents. Those end up linking to everything and the kitchen sink, so even QtMultimedia is loaded, but they are effectively GUI-less. Despite being a background service, Akonadi is actually only launched in GUI environments. However, Akonadi has built-in GUI counterpart mechanisms, so there is no need for background services to attempt to launch browsers or open windows. > > It doesn't change the technical roadblock: you *cannot* *move* > > QDesktopServices. The best you can do for API is add a new one. > > I'm pretty sure REMOVED_SINCE + an inline namespace around the Core > version would enable actual moving, but since I had read and understood > this argument before, I've implemented it under a different name now: The rules for macOS are simple: * keep the symbols that are in QtGui right now in QtGui * do not add the same symbols to any other library If you can find a way such that we are source-compatible but with different symbols, then we can effectively move them. > > And I'd like an argument > > why the API should be in QtCore, as opposed to QtNetwork (it's a browser > > after all). > > QtGui would gain a dependency on QtNetwork, or we'd need to duplicate > the implementation. QtCore is the common ancestor of both QtNetworkAuth > and QtGui. That's the technical argument. Not necessarily. We can have a private hook like the one you implemented, such that the dependency isn't there. My request was about front-end API. > The logical argument is that a) QUrl itself and b) QMimeTypeDatabase, > which co-determines which program to run on openUrl(), are both in > QtCore, so it makes sense that openUrl() would be, too. But the same can be said about fetching data from the network: it's all in QtNetwork. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Tuesday 7 May 2024 08:32:35 GMT-7 Marc Mutz via Development wrote: > If and when intents/activities replace openUrl(), QtNetworkAuth will > have to be ported, QtCore move or not, public API or not. Would that leave an API in QtCore that isn't necessary or is duplicated? Please design an API now that will work with intents/activities. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Monday 6 May 2024 23:08:07 GMT-7 Marc Mutz via Development wrote:
> Such applications wouldn't use QNetworkAuth, though, because returning
> access codes by cookie isn't one of the standardized mechanisms, and
> therefore not implemented in QNetworkAuth. I can see this bahviour every
> week when Thunderbird or the Linux "native" Teams client have kicked me
> out and ask for the password again. Both don't spin the system browser,
> and so I need to copy my password from Firefox to their own shitty
> dialogs manually each time. Very annoying, but that's precisely _not_
> what the spec asks for, either.
BTW, the other need I have is Microsoft's email service. And for that, I
highly recommend https://github.com/simonrob/email-oauth2-proxy. I've attached
my GUIless .service file. Whenever I need to re-authenticate, I look up the
journal logs and click the link that shows up there.
I agree this is not the best UX for most people. It works for me and I may
guess some of you here.
> I'm currently fighting an older version of openfortifyvpn (CLI on Linux)
> which cannot, yet, spin up the browser. Newer versions are reported to
> be able to, so there you have your use case. Plus mail fetchers, backup
> clients, basically everything that needs to authenticate with a web
> service of any kind needs OAuth support these days, and we can't ask all
> of them to embed QtWebEngine. Speaking with my security hat on, even the
> QtGui dependency would be a complete no-no for such applications: One
> should never, ever, link to libraries one doesn't need, as that does
> nothing but increase the amount of potentially exploitable code in the
> process' address space.
That's a fair argument.
I don't think those are going to be GUI-less Qt applications, though. That
number I still believe to be zero. They may be GUI Qt applications, such as
system tray services. A good example would be the VPN: you need a way to turn
it on and off (on Linux ,that's already implemented and is called
NetworkManager).
I'd like to see some GUI-less Qt applications perform those services, but then
they are highly limited on how to start the browser in the first place.
Anything beyond "print URL to stdout" may not be acceptable at all, as they
may be running *in* a GUI-less environment, such as my emailproxy case.
> > I suggest having a background hook that QPA registers with QtCore so that
> > QtNetwork can use to launch the browser if QPA has been loaded, but shall
> > fail if not.
>
> That doesn't solve the openfortifypn use-case, though. We can debate
> whether it's a valid one, but I think I just did.
It doesn't change the technical roadblock: you *cannot* *move*
QDesktopServices. The best you can do for API is add a new one.
So I'd like an argument why it needs to be separate from QDesktopServices when
we already have that and cannot remove it until Qt 7. And I'd like an argument
why the API should be in QtCore, as opposed to QtNetwork (it's a browser after
all).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
# -*- conf -*-
[Unit]
Description=Service for the Microsoft365 OAuth2 proxying
ConditionPathExists=/etc/emailproxy/emailproxy.config
[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectProc=noaccess
ProtectSystem=strict
RestrictAddressFamilies=AF_UNIX AF_INET
UMask=077
ConfigurationDirectory=emailproxy
CacheDirectory=emailproxy
CacheDirectoryMode=0700
ExecStart=python3 /usr/local/bin/emailproxy.py --no-gui --local-server-auth --config-file ${CONFIGURATION_DIRECTORY}/emailproxy.config --cache-store ${CACHE_DIRECTORY}/auth-cache
Group=emailproxy
User=emailproxy
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Monday 6 May 2024 11:48:31 GMT-7 Allan Sandfeld Jensen wrote: > Out of purely academic interest, how would I go about searching for those > problems? Would I be lucky enough they would all be conviently gathered in a > JIRA ticket? Unfortunately, no. But if you search JIRA for Qt 4.x-time QXmlStream problems, you may find some of them. The issue is that there are two platforms where symbol resolution at runtime is tied to the library they were found in at link time (so-called "two-level symbol resolution"). Therefore, for those two platforms, whatever we do, to keep BC, we must retain QDesktopServices in QtGui. On one of those two platforms, duplicating the symbols in the libraries is not a problem; but for the other one it is, therefore we must rename them when importing to QtCore. That's why we had this: https://github.com/qt/qt/blob/4.8/src/corelib/xml/qxmlstream.h#L100-L114 For QXmlStream classes, this was a big problem because one had objects of the types being renamed, so this caused cascading mangling changes in user code wherever they used our classes. This is the same BC break as libstdc++ did with std::__cxx11::basic_string. For QDesktopServices, at least there is no object and therefore no one is expecting to have functions with it as part of the mangled name. Those two platforms are: - Darwin (macOS, iOS, etc.) - Windows So not insignificant. And moreover, the two platforms where no one EVER runs without a GUI. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Monday 6 May 2024 03:31:46 GMT-7 Allan Sandfeld Jensen wrote: > Is there any problem in moving the class all the way if we preserve the > headers under both QtGui and QtCore? Yes. The last time we did that (moving the XML stream classes from QtXml to QtCore), we found a lot of problems and promised not to do it again. So QDesktopServices can't be moved. You can add a new class to QtCore. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving QDesktopServices from Gui to Core?
On Monday 6 May 2024 00:02:58 GMT-7 Marc Mutz via Development wrote: > Juha is currently improving the OAuth implementation in QtNetworkAuth. > The protocol involves launching the system browser to get an access > code, in turn used to get access tokens with which services can then be > accessed. > > OAuth therefore requires a UI to run the browser in, but not necessarily > a _G_UI (the system browser could be lynx). Even if a CLI tool like a > mail fetcher, backup program, or VPN client will eventually launch > Firefox or Chrome, I think it's too much to ask to link to QtGui just to > do the equivalent of exec xdf-open . That's true, but for such a restricted context that it's a negligible case. The chance that anyone who is using Qt has lynx or links as a web browser is indistinguishable from zero. And the chance that the non-GUI browser they're using is useful to perform an OAuth authentication is smaller than even that. Further, my experience with OAuth is that sometimes not even an external browser suffices. Of the two cases I have a need for so far, one of them (Palo Alto Networks' VPN product called "GlobalProtect") requires a full web engine because the information that is required is stored in a cookie that is only available in the response header. So, no, I don't think this should move. I don't think there's any situation where *any* user is going to benefit from this in a non-GUI environment. A class called QDesktopServices is really just about GUI desktops. Further, QPlatformIntegration *IS* QPA. You can't move that class to QtCore. I suggest having a background hook that QPA registers with QtCore so that QtNetwork can use to launch the browser if QPA has been loaded, but shall fail if not. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Trouble getting reviews in months and years
On Tuesday 9 April 2024 10:12:48 PDT Ilya Fedin wrote: > Oh, sorry, I was answering in quite a sleepy state but now I checked the > change you quoted and it seems I did almost everything as you said? The > change is supplied at Nov 23, 2022 which is long before Christmas, with > only a rebase and a minor commit message change during Christmas, > then I pinged at Jan 14 which is exactly a day before the second week of > January? The only thing I haven't done is adding Volker as I didn't > know (is this written anywhere?) that's something should be done... I missed that the initial upload was in November.. In any case, that was only one of many changes and the others don't fall on holidays. So that portion of the message wouldn't apply to them. Just take the procedure as I outlined, to send ping and re-pings, then adding maintainers and then asking this list. Don't wait months and years: you're entitled to getting a review within one month. The worst that can happen are that someone decides to make a permanent rejection because they can't justify accepting. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Trouble getting reviews in months and years
On Monday 8 April 2024 17:17:04 CDT Ilya Fedin wrote: > 2. https://codereview.qt-project.org/c/qt/qtbase/+/444859 which is 1.5 > years old and no review Submitted during Christmas break and no changes since New Years. No wonder it was missed. You should have sent a "ping" during the second week of January. That's the rule of thumb: after a week with no reviews, send "ping> . One week later, "re-ping". If you reach the third week, explicitly add the maintainer of the module in question and say, "maintainer, do your duty and review". And if that maintainer is unavailable for some reason, add Volker. If all else fails, there's this mailing list. You can send an email with your pending reviews and request that they be reviewed. But advice: include the topic of the review, not just the link and how long it's been. I have absolutely no clue on reviewing XCB stuff, but I had to click every link to make sure none of them was a QtCore issue I might have missed. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [EXTERNAL EMAIL] Re: Removing Qt 3D from release configuration in dev branch
On Monday 8 April 2024 09:57:55 CDT Volker Hilsheimer via Development wrote: > - follow up on submodule updates and make necessary adjustments to Qt 3D to > follow up on changes in other modules > - decide if/how to “release” Qt 3D; > branching and tagging and making it easy to build from source might be good > enough I think the second bullet follows from the first: if nothing changed since the last release, then no new release is required, because it means the old version compiles and works. As soon as there's a change, then we bump the version number to match the next Qt minor release and include in the next release set. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Fwd: Removing Qt 3D from release configuration in dev branch
On Thursday, 28 March 2024 01:06:37 PDT Björn Strömberg wrote: > example on spectrum on the support on modules: [unmaintained, deprecated, > life-support, full-maintenance, feature-development] The .gitmodules file for qt5.git is that. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Friday, 15 March 2024 11:03:19 PDT Thiago Macieira wrote: > On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote: > > I like simple rules. "Overrides should have the same access level as the > > initial virtual function." is a simple rule. > > Amend that to "... unless there's an explicit reason not to". With that, I'm > ok. As you can still access by casting to a base, that had better be a good > reason. Which actually points to a reason why you'd do it: to make it *more* accessible (make public, or make a private become protected). -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote: > I like simple rules. "Overrides should have the same access level as the > initial virtual function." is a simple rule. Amend that to "... unless there's an explicit reason not to". With that, I'm ok. As you can still access by casting to a base, that had better be a good reason. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Let's drop MSVC 2019 for dev (6.8)
On Monday, 5 February 2024 01:44:29 PDT Allan Sandfeld Jensen wrote: > I was trying to drop support for it in qtwebengine in 6.7, but the problem > was it was still used for qt packaging. But if we could at least switch > packing to vs2022, it would mean we could drop it in QWE. Can we commit to this ASAP after the 6.7 release? We'll revisit later in the cycle whether we still need 2019. Do note that Microsoft is preparing the next release after 2022, as seen by their shipping 17.0 Tech Previews. Jörg accidentally broke the C++ language level set up in dev, meaning we didn't test C++20 mode with 2019 for a day or so, and some changes that trigger 2019's broken C++20 support went in. If we don't drop 2019 by 6.8 release, we should force it to only compile in C++17 mode. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Jøger Hansegård for approver rights
On Thursday, 14 March 2024 02:06:23 PDT Tor Arne Vestbø via Development wrote: > Jøger joined The Qt Company 10 months ago and has since then been getting > his hands dirty in Qt Multimedia, and lately focusing on color management. > > Jøger is a thorough and responsible engineer and I trust that he will make a > good approver for the Qt project. +1 -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Decrease amount of qt releases in online installer
On Wednesday, 21 February 2024 13:13:33 PST Tuukka Turunen via Development wrote: > In general we should be always guiding users towards the latest releases and > to large extent users are doing that. We should also be even faster that > currently transferring the unmaintained releases to the archive, which in > turn likely causes more that today use of the archive (of the online > installer), so removing very old ones from the online installer is > beneficial. There are a couple of reasons why one may want to install a non-latest release. Usually, that's because they have a project that has stopped updating Qt at some point in the past (hopefully not for long) and now they need to install Qt for a new environment (new developer, reinstalled machine, whatever). I'd argue in this case that their CI should have the crystallised version, but developers should be able to install later versions. The CI must have an archived installation that they can recreate 5 years from today, independent of whether qt.io still offers the binary or not (knock on wood, but the website may have disappeared!). But developers will probably be satisfied if they can get the latest patch of a given minor series. And even then I'd say only for the latest couple minor series; there's no reason why we still need to offer 6.1.x today. The only other case that comes to mind for needing access to other-than-last patch or very old things is to bisect a bug either in Qt or in their software, to find out when the problem started occurring. Unfortunately, the number of developers who will spend the time for this is very small, and I'm also skeptical that there are any that would do this and don't build from source anyway. In any case, the sources won't be removed. One can always rebuild the binaries if needed. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wednesday, 21 February 2024 10:56:49 PST Edward Welbourne via Development wrote: > (Incidentally, the ways I can think of to say "has no name" tend to > suffer from some degree of precedent as "has a name but it has not been > disclosed" - the anonymous author of a pamphlet, the unnamed person who > reported a problem. I'm currently unable to think of such a precedent > for "nameless", but I suspect that's only that I can't currently think > of it. Then again, if a namespace with no name actually does have a > secret name, I guess that just matches the linguistic baggage.) It's an unnamed namespace, not anonymous namespace. There's such a thing as anonymous union, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wednesday, 21 February 2024 10:56:41 PST Jøger Hansegård via Development wrote: >Use unnamed namespaces for all internal/non-exported entities. Functions > can alternatively be marked `static` in the global namespace. Marking > functions `static` also in the unnamed namespace can help readability, > particularly in reviews. +1 -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wednesday, 21 February 2024 09:19:19 PST Mathias Hasselmann via Development wrote: > How that? > > https://wiki.qt.io/Coding_Conventions#Things_to_avoid says: > > "Avoid the use of anonymous namespaces in favor of the static keyword if > possible." Back in the day, this was a better suggestion. Now, it's equivalent so it's distinction without a difference. > While > https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-unnamed2 > says: > > "Consider putting every definition in an implementation source file in > an unnamed namespace [...]" > > Either I am missunderstanding something, or Qt Coding Conventions and > C++ Core Guidelines strongly disagree on whether to use anonymous > namespaces. Fair. But I disagree with SF22 and will continue to use statics. There's nothing wrong with them. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wednesday, 21 February 2024 08:26:52 PST Jøger Hansegård via Development wrote: > Our Qt coding conventions (https://wiki.qt.io/Coding_Conventions) has a > statement on the use of unnamed (anonymous) namespaces. As far as I > understand, this statement is now outdated. Can we delete this statement > and lean on Cpp Core Guidelines Cpp Core Guidelines SF.22 instead > https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-unnamed2? > Or do we need a Qt specific guideline on this topic? There doesn't seem to be a semantic difference. Are you proposing we simply replace our wording to point to SF22 or am I missing something? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Friday, 9 February 2024 23:04:20 PST Thiago Macieira wrote: > I added a fallback to C++17. I make no promises that it has the same level > of compatibility as the C++20 official concept. In fact, I know it doesn't. > It will reject some types and accept others that it shouldn't. > > That's QHash. That means we need to be sure we won't cause problems for > existing users. I have absolutely no problem in making this feature only > accessible in C++20, if need be. Done. I had more problems keeping q20::equality_comparable_with working when I made some more changes, so I just deleted it. That means the front-end QHash feature depends on C++20. No old code will be affected, but you can only use the new feature if you enable C++20 in your code. I someone wants to ressurrect q20::equality_comparable_with, be my guest. But as Marc said about a decade ago, "[C++ old version] costs more" (he was talking about C++98(. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Friday, 9 February 2024 06:45:30 PST Volker Hilsheimer via Development wrote: > The 3 big C++20 features people ask us about are modules, co-routines, and > concepts. We have no compelling answers here. You can’t build Qt into a set > of modules; we have no APIs using co-routines; none of our template > constraints are expressed, or at least documented, as concepts, and there > is no draft of a concept library for things that might be interesting for > Qt users. This change requires one concept: https://codereview.qt-project.org/c/qt/qtbase/+/536993/7 I added a fallback to C++17. I make no promises that it has the same level of compatibility as the C++20 official concept. In fact, I know it doesn't. It will reject some types and accept others that it shouldn't. That's QHash. That means we need to be sure we won't cause problems for existing users. I have absolutely no problem in making this feature only accessible in C++20, if need be. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
On Tuesday, 6 February 2024 22:02:11 PST Marc Mutz via Development wrote:
> As someone who argues that qHash("Hello"_L1) be restored to
> qHash(u"Hello"_s) after this relation was broken somewhere in Qt 5, how
> could I argue against it? :)
It was commit ea8e48a6799cf742ea23f4a30dcfc38a4988fe56 in 5.3.0.
commit ea8e48a6799cf742ea23f4a30dcfc38a4988fe56
Author: Thiago Macieira
Date: Thu Dec 19 23:32:04 2013 -0800
Update the qHash function for strings to use the CRC32 instruction
According to my profiling of Qt Creator, qHash and the SHA-1 calculation
are the hottest spots remaining in QtCore. The current qHash function is
not really vectorizable. We could come up with a different algorithm
that is more SIMD-friendly, but since we have the CRC32 instruction that
can read 32- and 64-bit entities, we're set.
This commit also updates the benchmark for QHash and benchmarks both
the hashing function itself and the QHash class. The updated
benchmarks for the CRC32 on my machine shows that the hashing function
is *always* improved, but the hashing isn't always. In particular, the
current algorithm is better for the "numbers" case, for which the data
sample differs in very few bits. The new code is 33% slower for that
particular case.
On average, the improvement (including the "numbers" case) is:
compared to qHash only QHash
Qt 5.0 function 2.54x1.06x
Qt 4.x function 4.34x1.34x
Java function2.71x1.11x
Now (current = siphash & murmurhash; nonzero_curent = aeshash; we don't have
the CRC32 algorithm any more):
RESULT : tst_QHash::hashing_qt4():"numbers":
126,800.35305 CPU cycles per iteration, 4.66 GHz
470,120.00894 instructions per iteration, 3.708 instr/cycle
RESULT : tst_QHash::hashing_qt50():"numbers":
83,198.10215 CPU cycles per iteration, 4.64 GHz
365,099.00604 instructions per iteration, 4.388 instr/cycle
RESULT : tst_QHash::hashing_current():"numbers":
151,220.07727 CPU cycles per iteration, 4.66 GHz
615,149.01052 instructions per iteration, 4.068 instr/cycle
RESULT : tst_QHash::hashing_nonzero_current():"numbers":
65,224.59934 CPU cycles per iteration, 4.45 GHz
235,073.00508 instructions per iteration, 3.604 instr/cycle
So even the pathological "numbers" case is now faster by about 27%.
With "typical" data ("paths-small"):
qt4:23,848.939476 CPU cycles per iteration
qt50: 11,681.268231 CPU cycles per iteration
current:10,623.703491 CPU cycles per iteration
aeshash:2,870.472204 CPU cycles per iteration
The siphash/murmurhash implementation is slightly faster than the Qt 5.0
implementation and both are over twice as fast as the 4.x implementation. The
aeshash is on average 3.7x faster than even those two.
And with very long data ("longstrings-list"):
qt4:397,145.21743 CPU cycles per iteration
qt50: 225,105.45316 CPU cycles per iteration
siphash:102,900.78968 CPU cycles per iteration
aeshash:10,249.00974 CPU cycles per iteration
That's 10x faster on my laptop, which has 256-bit AES. With just 128-bit AES,
my Skylake workstation is doing about 3.5x better than siphash for this case.
See more numbers in
https://codereview.qt-project.org/c/qt/qtbase/+/537009
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
On Monday, 5 February 2024 01:36:39 PST Marc Mutz via Development wrote: > I've always understood it such that we as Qt must preserve the property > that the hash for equal elements is equal within _one_ run of _one_ > process. This means you can use the hash in I/O in any way. That's why > we have qt_hash, which you _can_ (and do) use in I/O (but is private > API, AFAIK). I never thought that a hash seed of zero would change that, > but of course users may have come to depend on this (Hyrum's Law), so a > [ChangeLog] would be in order. In commit e3f05981cbeb0b7721f960ef88effa77be2af5ce, I added this comment to qHashBits: // mix in the length as a secondary seed. For seed == 0, seed2 must be // size, to match what we used to do prior to Qt 6.2. Which is why I am asking now, because making this change would go against that comment. But there was no discussion in the change about whether this was correct or not. It seems I just write it like that. However, that was qHashBits(). The change I'm talking about is qHash(QLatin1StringView), specifically so it won't call qHashBits(). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Let's drop MSVC 2019 for dev (6.8)
On Monday, 5 February 2024 01:39:47 PST Marc Mutz via Development wrote: > I think we don't drop supported compilers, except in LTS+1 releases (6.9 > being the next). I would advise you drop it before the LTS, so you don't have to keep supporting it for however long your LTS cycle is. How about instead we drop at an LTS+2 release? The next one is actually 6.7. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?
On Sunday, 4 February 2024 06:12:18 PST Giuseppe D'Angelo via Development wrote: > Il 03/02/24 22:08, Thiago Macieira ha scritto: > > But what about a zero seed? It's what we call a "deterministic hashing". > > We > > have changed the algorithms on .0 releases (in both 5.0 and 6.0 for > > QString). > > I don't think it means "deterministic" in the sense that the output will > never change across Qt versions. It just means deterministic across > multiple runs of the very same application using the very same Qt version. Indeed but how would it know that it is the same Qt version? It might be running with a system Qt that got upgraded in the background, so a new start would change it. For that matter, it's far more likely that it's an application and its helper at the same time, but even then they can't guarantee they're using the same Qt. > When you disable QHash seeding, the choice of making the seed equal to 0 > is just "a choice"; we could make it 42 or 0xF0CACC1A, for what is > worth. qHash can still change its output at any time across Qt versions > and software should never ever rely on that. I'm not sure. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] What's our policy on changing the result of qHash(T, 0) between major releases?
Requirement: the qHash function in question is and has always been out-of- line. We obviously can't change the hashing function of inline code, because it may have been inlined. When the seed is non-zero, we make no guarantees on what the result will be. The result is allowed to change between Qt versions and between machines, even for the same seed. Strictly speaking, you're not supposed to pass replay a seed, because some hash functions have a hidden seed you can't get or set. But what about a zero seed? It's what we call a "deterministic hashing". We have changed the algorithms on .0 releases (in both 5.0 and 6.0 for QString). The reason I'm asking is that right now qHash(QLatin1StringView(str)) == qHash(QByteArrayView(str)) but it would be far more useful to have qHash(QLatin1StringView(str)) == qHash(QString(str)) I've made the change for the non-zero seeds, but one couldn't rely on the above unless it applied for every seed.f -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote: > I don't have access to QNX and INTEGRITY toolchain information, so I'd like > to request that they simply match the feature list above, with minimal > workarounds. What's the current state for those, for supporting Qt 6.8 or 6.9? We have VxWorks coming in and I'd like it to meet a higher minimum bar than "legacy". That is, I'd like VxWorks to require a C++20-compliant compiler before being enabled in our CI, but that's only fair if we have a line-of- sight to bringing everyone to C++20. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] About the timeline and phases to support C++20 with and in Qt
On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development wrote: > We got four user stories on Qt Bug Reports: > > 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360 > 2. C++20 is required for the development of Qt itself - > https://bugreports.qt.io/browse/QTBUG-109361 > 3. C++20 is mandatory for users of Qt - > https://bugreports.qt.io/browse/QTBUG-109362 Those tasks haven't got any updates recently. What's the status? I'd like to ask that we go to #3 for 6.8 or 6.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Let's drop MSVC 2019 for dev (6.8)
The compiler is pretty buggy and has several, unfixed conformance issues with C++. One year ago I asked on the interest mailing list about using a non-latest MSVC: https://lists.qt-project.org/pipermail/interest/2023-January/038859.html The reasons reported for not going to the next were: * regression in a newer version that MS hadn't fixed * cost: they may have bought version X but not Y (yet) * cost: re-certifying the entire tool environment * because the associated tools (IDE) have other problems (UX) * inertia * because our builds are labelled "msvc2019" My conclusion then was that we could drop the older one, but our policy should be to support an X-1 version of MSVC for as long as practicable, a minimum of a few years. Well, in April this year, MSVC 2019 will be 5 years old, though fortunately it's still getting updates. Considering MSVC 2022 will be 3.5 at that time, I think it's time to drop. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] static constexpr in exported classes needs out-of-line definitions
On Wednesday, 17 January 2024 19:35:17 PST Thiago Macieira wrote: > Alternatives: > * move to a class that is not exported >trick: add an empty base with the variable > * change to enum (if primitive) * change to an static (inline) constexpr function Then there's always a copy, because GCC either inlines or emits a copy for functions. https://mingw.godbolt.org/z/bh95q8PKf MSVC sucks at inlining dllimported functions, but there's no problem because it exported on the other side. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] static constexpr in exported classes needs out-of-line definitions
On Wednesday, 17 January 2024 19:35:17 PST Thiago Macieira wrote: > This appears to be a GCC bug/shortcoming. Clang and MSVC apparently > automatically emit and export the variable for you: > https://mingw.godbolt.org/z/q4dYdosjh Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113465 -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] static constexpr in exported classes needs out-of-line definitions
See http://bugreports.qt.io/browse/QTBUG-121135 for the issue and
https://codereview.qt-project.org/c/qt/qtbase/+/531251 for the solution.
TL;DR: if you define a static constexpr (which is implicitly inline) member
variable in a class with export macro, you MUST add the definition of tha
variable to the .cpp.
Alternatives:
* move to a class that is not exported
trick: add an empty base with the variable
* change to enum (if primitive)
But this happens even for plain int variables. For example:
#include
#include
void f(std::vector )
{
v.push_back(QLocale::FirstTwoDigitYear);
}
This produced: with GCC 13 at -O2 optimisations:
_Z1fRSt6vectorIiSaIiEE:
movq8(%rcx), %rdx
cmpq16(%rcx), %rdx
je .L29
movl$1900, (%rdx)
addq$4, %rdx
movq%rdx, 8(%rcx)
ret
.L29:
movq__imp__ZN7QLocale17FirstTwoDigitYearE(%rip), %r8
jmp
_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJRKiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_
Interpretation: if the vector has enough pre-allocated space, it simply moves
1900 to the end of te array and adjusts the end. But if not, it calls
std::vector_M_realloc_insert(), which takes the integer by reference, so
the compiler emits an import from the DLL.
This appears to be a GCC bug/shortcoming. Clang and MSVC apparently
automatically emit and export the variable for you:
https://mingw.godbolt.org/z/q4dYdosjh
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Buddy group to help new contributors
On Friday, 5 January 2024 12:28:04 -03 Christian Tismer-Sperling wrote: > If the PySide group allows it, I'd be happy to port some perl > scripts to python Sorry, why is Python better than Perl? Eddy's argument is that he doesn't want to maintain Perl, but if others are, he doesn't have to. The question of maintenance is simply of maintenance. The question in this thread is that of barrier of entry to developers with bare-bones environments. Hence my question: why would Python be better than Perl? Last I checked, it doesn't come with Windows either. Maybe some VS environments have it, but I wouldn't know. The only scripting language we're guaranteed our users will have is CMake. Not even shell scripting falls into that category, because, as we've discussed the standard Git configuration does not put sh.exe in PATH (except for scripts that Git itself runs, which happens to include the Gerrit Change-Id one). So if there are any tools that are considered "should provide"[1] to beginners, please port them to CMake. [1] Gradation: "must provide", "should provide", "would be nice to provide" -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Buddy group to help new contributors
On Friday, 5 January 2024 12:28:04 -03 Christian Tismer-Sperling wrote: > > If someone wants to take over and write in CMake or in C++, be my guest. > > That's what Alexey did for the syncqt.pl script that predated even me. As > > far as I know, that removed the dependency on Perl to compile Qt or to > > contribute. What's left that you're seeing? > > If the PySide group allows it, I'd be happy to port some perl > scripts to python But what scripts need porting? I don't see anything that is required to build Qt or contribute to the Project. There are some helper but entirely optional scripts that were written in Perl, others in Python; some shell scripts in Zsh or requiring Bash specifically instead of being Bourne Shell-compatible. Because none are required, I don't see them as a showstopper or even a barrier to entry. Maybe an annoyance. I have no problem with rewrites, so long as the offers to rewrite include an offer to maintain said scripts for a couple of years. That means I'd be wary of accepting an offer from someone who isn't an established Qt contributor... but then again, those scripts are entirely optional so their falling into bitrot is not a problem either. So if anyone wants to port anything, get busy. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Buddy group to help new contributors
On Friday, 5 January 2024 06:00:12 -03 Elias Steurer via Development wrote: > but let's go back to the discussion about why we need perl in the first > place and why wikis are bad Because we need a more powerful scripting language than shell or batch files for many things. Many of the scripts in question were started by me and I use Perl. I will not write in another language. Some others are so old that they predate Python's very existence. If someone wants to take over and write in CMake or in C++, be my guest. That's what Alexey did for the syncqt.pl script that predated even me. As far as I know, that removed the dependency on Perl to compile Qt or to contribute. What's left that you're seeing? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
On Monday, 18 December 2023 07:54:07 -03 Giuseppe D'Angelo via Development wrote: > If anything I think this discussion ties up with the one about the > future of moc, and whether it should become a compiler plugin. In > principle this would bypass the problem of parsing the binary module > formats -- leave it to the compiler infra, and just get the info you > need out of the `import`s. Either that or use reflection. > > Qt should make the commitment that will support at most one module format. > > Any compiler that doesn't operate on those will not have their modules > > supported. > > > > I don't know if this is the same content that CMake had to support. It's > > possible it isn't because CMake doesn't need to know about the classes, > > enums, variables, functions, and all other entities declared, which are > > part of the translation unit. Moc does need that. > > ... which is really, what info does moc exactly need out of a #include / > import? Since 4.0 or 5.0 (too long ago) we actually parse everything included for extra information. I don't know exactly what we need from included files, but we do need something. In particular, we do need macros themselves, so we can perform proper expansion in the classes we're trying to generate meta objects for. If this is something that will never come from imports, great, it's a major barrier removed. The question is what else. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
On Friday, 15 December 2023 11:07:44 -03 Fabian Kosmale via Development wrote: > 1. moc's parsing logic needs to learn about the relevant new keywords. moc > needs to know at the very least the module (partition)'s name. Please forgive my lack of knowledge on this and asking of very basic questions. That's why I asked Ville during QtCS two weeks ago for someone to investigate module support and explain to the rest of us what it would mean to support them. Is the file format for the imported modules already standardised? Is it in the C++ standard? I don't remember seeing it there. If it's not a standard (ISO C++ standard or otherwise), we'd need to write format parsers for each compiler, which raises the cost for supporting modules considerably, especially if the compilers aren't committing to a stable format in the first place. Qt should make the commitment that will support at most one module format. Any compiler that doesn't operate on those will not have their modules supported. I don't know if this is the same content that CMake had to support. It's possible it isn't because CMake doesn't need to know about the classes, enums, variables, functions, and all other entities declared, which are part of the translation unit. Moc does need that. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
On Wednesday, 13 December 2023 08:46:57 -03 Marc Mutz via Development wrote: > The question I have, therefore, is the following: is converting more > classes to the new framework considered a feature as in "affected by FF"? I'd say simple changes should be fine. There should be no behaviour change at all, anywhere. If that turns out to be a large change, we may want to postpone; if it breaks something, then we've likely found a bug. So, +1 for me on going ahead. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Houston, qint128 has a problem
On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote: > I think we need to mandate that if you want qint128 support, then you > must compile with gnu++NN, which is actually the default on both GCC and > Clang. We seem to switch that off (-ansi on). Now answering the point you actually raised: I agree. If you want to use our qint128 API, you should use a standard C++ library that knows about it too. You can mismatch at your own risk. That only brings the problem that QtCore and QtTest must support int128 if the library *can* support it. We must either switch to non-strict mode in compiling those two libraries or we must ignore our own flag in them. Neither option is appetising. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Houston, qint128 has a problem
On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote: > After spending countless hours between Ivan and myself fighting GCC's > mysteriously-vanishing support for __int128_t (= qint128), > it turns out that with -ansi/-std=c++NN, not even the most basic of > work: std::is_signed_v is _false_! I repeat: _FALSE_. The issue here is that GCC devs' reading of the standard, as worded, was that they weren't allowed to make an extended integer type return true for those traits because they weren't in the list of types that the standard said it should. Specifically, the question was whether std::is_integral is true. I thought C++23 had clarified that they can, indeed, be integral. But I can't find the change and I can't reproduce it. In fact, it the code seems to still be there, so I must be mis-remembering the conclusion. libstdc++ reacts to the compiler defining __GLIBCXX_TYPE_INT_N_0 to say this is a supported type That macro is defined in c-cppbuiltin.cc[1], which has a !flag_iso check. It's a little difficult to do more investigation right now because Qt Creator keeps crashing as soon as I open type_traits[2]. There's something wrong with the build I made yesterday. [1] https://codebrowser.dev/gcc/gcc/c-family/c-cppbuiltin.cc.html#1224 [2] https://bugreports.qt.io/browse/QTCREATORBUG-30044 -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
On Friday, 8 December 2023 07:22:30 PST Dominik Holland via Development wrote: > Although not part of qt5.git the interface framework is part of Qt DCE > for quite some time already and also used by customers. From a > qt-project standpoint that module doesn't exist and is not part of > source/binary compatibility promises, but what's our standpoint for qt > commercial customers ? I think that question, as asked, is irrelevant. Why does anyone care what a module is called? We can freely move libraries between modules. They are just a packaging artefact. At worst, changing them breaks some build scripts. Should be a 10-minute job to fix it, assuming everyone isn't simply getting the fix from the Yocto Project. API and library names, on the other hand, are more important. Any code imported into the Qt Project needs to b reviewed, though the fact it may come with existing users may inform us in how much breakage we/they are willing to accept. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
On Thursday, 7 December 2023 08:02:15 PST Tuukka Turunen via Development wrote: > So the question is what should this module be called, if it would be > renamed? I would indeed want to know what these are interfaces of or for. Like I said, they are not network interfaces, which is the first thing that comes to mind (to me). The second one that comes to mind is C++ "interfaces" (abstract virtual base classes), but we still need a domain to know what this is about. We have abstract virtual bases elsewhere in Qt, so what's special about this module? Knowing now that this used to be "GENIVI Extras" does not help yet. "GENIVI Extras" meant something; "interfaces" or even just "automotive interfaces" do not. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On Thursday, 7 December 2023 04:55:48 PST Kevin Kofler via Development wrote: > Qt should just use whatever OpenSSL is installed on the system and be done > with it. Chances are that any OpenSSL 1 it finds will be from some LTS > distro with backported security fixes anyway. I only agree partially with this statement, based on the previous paragraph. The problem is that OpenSSL 1 and 3 have differing APIs, so supporting both means extra work for us. It's not a matter of just washing our hands, even if OpenSSL were "just another third-party dependency" -- it isn't, it's the single most security-relevant one. In fact, this is closer to support for Windows 9x/Me back in the day, where keeping this added to the maintenance of the other, more recent and more relevant configurations. So here's what I propose as a compromise: * we keep the code alive in the repository, for now * we set a deadline for re-review, based on cost of maintenance and relevance * we make it clear to users we do not test this, not even that it compiles * but we advise we will take care of security issues stemming from our own code as we've always done That would put OpenSSL 1 support in the same bucket as FreeBSD or HaikuOS or Sparc processor support: whoever is using this[1] must supply patches. I propose we re-review once a year. [1] that may include the Qt Company if their commercial interests call for it. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_WARNING_MSG/QT_DEPRECATED_HEADER
On Wednesday, 6 December 2023 23:58:10 PST Marc Mutz via Development wrote: > Hi, > > I've developed these to deprecate qspan_p.h in favour of qspan.h, but > we'll now just remove the old header instead. I can see us apply it to > qglobal.h, but not for 6.7. > > But if you have a use for a cross-platform #warning or the deprecation > of a whole header, restore and stage > https://codereview.qt-project.org/c/qt/qtbase/+/523363, it's already > approved and just waits for a user. QT_WARNING_MSG is useful in other contexts too, for example for deprecating macros. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Future of java-style iterators?
On Tuesday, 5 December 2023 14:02:36 PST Giuseppe D'Angelo via Development wrote: > QDirIterator, QRegularExpressionMatchIterator, (private) QStringIterator > and similar don't have replacements yet. > > Yes, one can wrap a Java iterator back into a range API (as I've done > for QREMI, so you can use do `for (auto match : re.globalMatch(subj)`), > but then one really wants C++20 for the algorithms. QDirIterator could be rewritten either as an input or a forward Standard Library iterator. It wouldn't be a bad idea because its implementation is broken: while you're trying to get the information about the current item, it's stat()ing the next. It's also hard to guess which element you're getting and whether you're accidentally skipping the first entry, or missing the last one. All of which are caused by the fact that it *is* a Java-style iterator. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote: > Then why are you asking for a repository if it's already there? When was > that module approved by the Qt Project? I can't find anything in the email > archives. > > The first commit in this repository is "First version of the QtGeniviExtras > module". When was it renamed and who approved it? This module was requested at https://lists.qt-project.org/pipermail/development/2015-August/022859.html There were no objections. Tuukka said it's a good idea to have the modules even if they aren't part of the released packages: > I think it is fine to create the requested repo for new module. Depending on > the need it can then either be included or not be included in the release > packages. That would explain why this isn't in the qt5.git/.gitmodules. But I said: > I am, however, questioning the design of the API that Dominik presented. There have been zero other discussions of "genivi" since then https://www.google.com/search?q=genivi+site%253Ahttps%253A%252F%252Flists.qt-project.org%252Fpipermail%252Fdevelopment%252F I don't know what kind of API reviews have been done since. But there has been no discussion about renaming this module. Therefore, the name it is currently using is unauthorised and does not imply a precedent. -1 on this new module with this name. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
On Tuesday, 5 December 2023 07:54:51 PST Dominik Holland via Development wrote: > It's not a question to import something, the module literally already > exist here: https://code.qt.io/cgit/qt/qtinterfaceframework.git for > quite some time and for that there is a source and binary compatibility. Then why are you asking for a repository if it's already there? When was that module approved by the Qt Project? I can't find anything in the email archives. The first commit in this repository is "First version of the QtGeniviExtras module". When was it renamed and who approved it? That module is not in qt5.git/.gitmodules so it's *not* a Qt module right now. Source- and binary-compatibility do not apply. That Git repository is also not sync'ed to GitHub. Anyway, I am exercising my right to vote to vote -1 on this repository request so long as it is using this name. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
On Tuesday, 5 December 2023 04:17:08 PST Dominik Holland via Development wrote: > Right, but at the same time we cannot change of the module and all it's > classes afterwards. Yes, you can. Any code imported into the Qt Project is subject to API reviews and may therefore be different than when originally imported. There is no source- or binary-compatibility guarantee offered against pre-Qt Project or Labs implementations. I insist: find a more precise name for the module. "Interface" is too generic, you need one more word, at a minimum. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
On Monday, 4 December 2023 02:10:43 PST Dominik Holland via Development wrote: > the qtinterfaceframework module currently also hosts two reference APIs > (qtifmedia and qtifvehiclefunctions). Both are very much automotive > specific. In order to make the module also available for other industries > we would like to move those two modules to a new qt-labs repository. > > Name of the repository: qt-labs/qtif-reference-apis.git > Description: Reference modules based on the Qt Interface Framework Can we have a more descriptive name than "interface"? Neither QNetworkInterface nor QDBusInterface belong there, therefore there must be a constraint of some sort. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt v6.6.0 and v6.6.1 from online installer differences?
On Thursday, 30 November 2023 20:36:03 CET Fabian Kosmale via Development wrote: > this change (https://codereview.qt-project.org/c/qt/qtbase/+/512774) was > intentional and aimed to resolve > https://bugreports.qt.io/browse/QTBUG-117514. However, given the lack of a > changelog, I don't believe the BIC break between 6.6.0 and 6.6.1 was > intentional. It was intentional. We have to choose one of the two ELF versions so we chose the one that restored compatibility with older 6.x. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating QSharedMemory and QSystemSemaphore
On Monday, 20 November 2023 10:39:54 PST Fabian Kosmale via Development wrote: > I am however a bit concerned about the timeline for the deprecation, and the > migration path we want to offer. There needs to be at least documentation > on how to properly port away form QSharedMemory, and maybe even a "new" > QSingleApplication (but one that doesn't use QSM in its implementation). QtSingleApplication should use D-Bus where available. In fact, it should implement the KUniqueApplication API. Where not available, well, I actually don't know what its requirements are so I can't offer a suggestion. That said, deprecation should not be delayed. The bugs are there, right now. It shouldn't matter if we've fixed the code that is affected or not. As you can see from my change, I'm actually requesting it be backported to 6.6.1. > My suggestion would be that we > - discuss current QSM patterns, and how to move away from them > - based on that, create documentation and if necessary implement new classes > to help with the use cases - and only then deprecate QSharedMemory. I think we can delay the deprecation until we've had a chance to talk next week about whether we're going to have a replacement at all or not. If we're not, if the replacement is simply QFile, then there's nothing stopping us from deprecating. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Deprecating QSharedMemory and QSystemSemaphore
or now, I don't want to touch it. What should I do? A: Add #define QT_NO_DEPRECATED_IPC and the deprecation warnings will be silenced. Q: Should we use the new API in Qt 6.6? A: No, they're dead on arrival. Q: Will you work on a replacement API? A: No. QFile suffices for my needs and I've lost interest / motivation in this functionality. Q: Will you accept if someone else works in fixing these classes or providing a replacement? A: Sure. I'll be happy to review your code and offer my insight. I just won't do the coding myself. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 15 November 2023 08:32:40 PST Marc Mutz via Development wrote: > All other std::regular Qt classes will be using the new types (or, if > helper functions are inline and we compile in C++20 mode, the std types > directly). Please remember you must not change the return type of any exported function. So I advise we just use the Qt types and come Qt 7 they become a typedef. There's no need to use the Standard types right now. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 14 November 2023 08:25:34 PST Ivan Solovev via Development wrote: > > The ABI functions can return one of these other types: > > bool (for equality comparisons) > > int (for non-partial ordering) > > QPartialOrdering (for partial ordering) > > IIUC, returning QPartialOrdering is exactly what we want to avoid, due to > the std::partial_ordering -> QPartialOrdering (and reverse) conversions. That boat sailed in 6.1 because QPartialOrdering is already used in QMetaType and QVariant API/ABI. Ideally for new out-of-line APIs, we could return a type that is ABI- compatible with std::partial_order. But how many of those are we going to get? > As we figured out earlier in this discussion, by making Qt::partial_ordering > binary compatible with std::partial_ordering, we will allow the compiler to > optimize the code and avoid the conversions (specially if we use > std::bit_cast). Yes, but the impact only applies to when it needs to translate from out-of- line to out-of-line. If either side is inline, it'll do the right thing on its own. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 14 November 2023 04:17:18 PST Marc Mutz via Development wrote: > It's dangerously close to q20, yes, but q20 types switch at compile-time > between std and fall-back types, which means they cannot be used in the > ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a > `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC > constraints). Actually, how about we do exactly that: we DO NOT use them in the ABI and thus we DO use std:: types when compiling in C++20 mode. We can only use them in inline-only functions. The ABI functions can return one of these other types: bool (for equality comparisons) int (for non-partial ordering) QPartialOrdering (for partial ordering) -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 14 November 2023 04:17:18 PST Marc Mutz via Development wrote: > It's dangerously close to q20, yes, but q20 types switch at compile-time > between std and fall-back types, which means they cannot be used in the > ABI (yes, I used qxp::function_ref in QTestLib, but that doesn't have a > `using std::...`, yet, so we're still ok, and QTestLib doesn't have BC > constraints). > > The Qt::*ordering types, OTOH, are specifically _for_ use in the ABI. This does mean those types won't be documented, right? We forward to the C++ Standard Library documentation. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 13 November 2023 09:38:43 PST Ivan Solovev via Development wrote: > I really do not want to miss yet another FF. Given that this is an API that is going to stay with us for at least a decade, I'd rather get it right than getting it soon. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 13 November 2023 09:15:10 PST Marc Mutz via Development wrote: > On 13.11.23 17:15, Thiago Macieira wrote: > > On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote: > > I don't think this minor thing is worth the hassle. It uglifies our API > > for > > little gain. > > What, specifically, is ugly? That we have two Qt partial_ordering types? Yes. > Anyway, that's subjective. Objectively, it breaks the impasse between > full efficiency in future-looking C++20 builds and Qt BC guarantees. We're not losing anything either because the only case where this would be necessary is if we needed to return a std::partial_order result from a non- inline function that is, in turn, calling the non-inline QMetaType and/or QVariant functions. We have zero of those today and aren't likely to get any of them, probably ever. Some user code might, but I find it unlikely too. It could happen if the user decided to wrap a QVariant in a larger type that did have a three-way out-of- line comparison function. Everywhere else, the optimiser will do the right thing. > Given that Qt 7.0 is many years away, I don't think it's too much to ask > to go the extra mile and remove the overhead. We seem to agree how to do > it technically, and it won't be on you to implement all this, but on > Ivan and me. I think I speak for Ivan, too, if I say that we'd rather > today than tomorrow see this stuff merged. The next FF is already > approaching again. It could be done, but I just don't see the value. If we do it, please come up with proper Qt-style class names for it. No snake_case. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote:
> Thiago wrote:
> > The problem is that QPartialOrdering::Unordered has been in our ABI since
> > 6.1 and we can't change that any more.
>
> Well, Marc already suggested a solution for this problem.
> Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
> QPartialOrdering in favor of the new types.
>
> We need to provide conversion between QPartialOrdering and
> Qt::partial_ordering, but the new types can be fully BC with std.
I don't think this minor thing is worth the hassle. It uglifies our API for
little gain.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Friday, 10 November 2023 00:11:11 PST Marc Mutz via Development wrote: > On 09.11.23 16:28, Thiago Macieira wrote: > > But if the symbols are globally visible (ELF visibility STV_DEFAULT) > > That counts as "exported", doesn't it? Yes. > Which leaves us with: > - MSVC doesn't export anything by default; inline functions are, > however, exported when the surrounding class is wholly exported > - on all other platforms, all functions are by default "exported", but > we emulate MSVC on those platforms by changing the default visibility to > hidden, incl. for inline functions > > And my previous questions: > > - do our BC guarantees exist at all in the absence of > `-fvisibility=hidden -fvisibility-inlines-hidden`? Yes, we have to, because we don't control how the user's library is being compiled. > - does making the Qt and std::ordering types BC with each other not > solve the problem in this case, too? It does. We should really do that for Qt 7.0. The problem is that QPartialOrdering::Unordered has been in our ABI since 6.1 and we can't change that any more. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Thursday, 9 November 2023 01:29:32 PST Ivan Solovev via Development wrote: > Thiago wrote: > > We can also just be evil and use bit_cast > > Why is that evil? Reading about std::bit_cast, this can be an option, if we > guarantee that sizeof(Qt::*_ordering) == sizeof(std::*_ordering). > Which is, probably, already true. Because the types in the libraries seem to be made so it's very difficult to get the actual values into and out of them. But bit_cast throws that away and allows us to see behind the scenes. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 8 November 2023 23:17:45 PST Marc Mutz via Development wrote: > std::string is a type, but we're talking about function return types. > Oranges and apples. Naturally the impact of the former is orders of > magnitude larger than that of the latter. std::string and std::__cxx11::string are different types, but someone changed which one got selected. > > But why take the risk? The performance impact is minimal, because it only > > applies to partial ordering, while the vast majority of types are fully > > ordered. > > Why do you say it only applies to partial ordering? Do we already match > the values, other than that of std::partial_ordering::unordered? Yes. It's always -1, 0 and 1 for all three Standard Libraries. https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.2.0/libstdc%2B%2B-v3/ libsupc%2B%2B/compare#L51-L53 https://github.com/llvm/llvm-project/blob/llvmorg-17.0.4/libcxx/include/ __compare/ordering.h#L25-L33 https://github.com/microsoft/STL/blob/main/stl/inc/compare#L43-L45 > I do note that you didn't attempt to poke holes into my documentation of > my understanding of the "merge of inline functions from different > libraries" issue. You didn't ask anything. > To TL;DR: it: I believe there is no way that an (application or) library > can call another (dynamic) library's implementation of a non-exported inline > function. It will always contain (and call) its own copy of the > non-exported inline function. That's only partially correct. All libraries will contain out-of-line copies of any inline functions they didn't inline. This portion of your assertion was correct. But if the symbols are globally visible (ELF visibility STV_DEFAULT), the dynamic linker will resolve all calls to the same symbol in one of the libraries, whichever one got loaded first by the depth-first library search and load order. > Independent of the resolution of the C++20 comparison return types, I > think it's vital to come to a common understanding of whether there is > an actual issue with non-exported inline functions in ABIs (and then > document it in the KDE BC wiki). The documentation there is correct: you can change inline functions and uninline them so long as the old copy can keep on being called. That says nothing about changing the function's return type or the layout of the type it does return. But yes we should add to it. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 8 November 2023 10:05:38 PST Ivan Solovev via Development wrote: > > I think it's acceptable for us to change the return type of a function so > > long as it's getting a new mangling. > > Well, it would be easily achievable for the template methods, but not for > the inline hidden friend helper methods. > As immediate solution that comes to my mind is to add a third argument to > these methods when compiled in C++20 mode. And we could probably use > yet another macro for that. But this will just overcomplicate the things, so > I'm not a big fan of this idea. Neither am I. If we do this, the third, dummy, disambiguating parameter should simply be the return type itself. It's the clearest solution and makes macro definition simpler. > So, you say that the compiler is smart enough to optimize away conversions > like `std::strong_ordering -> QStrongOrdering -> std::strong_ordering` > because the underlying integral values are the same? Yes. Since everything is idempotent, it should just do nothing. In practice, it looks like one of the conversions is getting clamped: https://gcc.godbolt.org/z/n7ohc9Wo4 It might be possible to massage the code in such a way that the compiler realises that it is always idempotent. I haven't managed yet. We can also just be evil and use bit_cast: https://gcc.godbolt.org/z/e5zefKevP -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 8 November 2023 00:38:32 PST Marc Mutz via Development wrote:
> Let's not mix up topics here...
>
> 1/ We're not responsible for the ABI of third-party libraries. As long as
> we document that the return type of a non-exported inline functions
> changes, then it's SEP if someone else writes code that ties their ABI
> to the result type of such functions.
Fair, but we are responsible if we make it difficult for them to do this, or
make it trivial for them to have the problem without knowing that they have
it. That was the issue with std::string in libstdc++: it kept libstdc++ BC,
but broke everyone downstream of it.
> That leaves 2/ the mythical "merge of inline functions from different
> libraries" and 3/ "mixing of C++ versions within the same executable"
> situations.
>
> I agree that the latter is a problem; I stated as much in my previous
> email, and gave (1) and (3) as solutions.
>
> But I still don't see how the former is a problem, or, if it is, why (3)
> (BC between {std,Qt}::_ordering) doesn't fix it, too.
I think it's acceptable for us to change the return type of a function so long
as it's getting a new mangling. That means it can apply to any regular
function, but not operators. Then again, all of the latter return bool except
for operator<=> so there's no problem there either.
But why take the risk? The performance impact is minimal, because it only
applies to partial ordering, while the vast majority of types are fully
ordered. The impact of QAnyStringView in any API is greater.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers
On Monday, 6 November 2023 06:55:25 PST Alex Blasche via Development wrote: > I'd like to nominate Tatiana Borisova as maintainer for Qt Protobuf and > Alexey Edelev as maintainer for Qt GRPC. In fact, both have been working on > this code base even before they officially became part of Qt. I am glad > they agreed to continue this work going forward in the context of Qt > Development. And I need no disclaimer because I don't have them as colleagues in any fashion. I'm going to throw in my statement of support of both as capable developers who have helped maintain and improve Qt in several aspects, so I have no doubt that they will do a great job with grpc as maintainers. I've worked with Alexey more than with Tatiana, but this statement goes for both. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 7 November 2023 13:34:04 PST Marc Mutz via Development wrote:
> > Yes. Remember that "one binary" is the process as loaded into memory,
> > including all the libraries. Depending on compilation modes, inline
> > functions may be merged from multiple independent libraries at runtime.
>
> Sorry, but [citation needed]. This goes against _everything_ I know and,
> more importantly, everything we've been doing the last decades, incl.
> your own https://codereview.qt-project.org/c/qt/qtbase/+/389682
Any debug build that isn't using -fvisibility-inlines-hidden. Or release
builds for any inline function that didn't get inlined.
Changing of int to qsizetype or qint64 "works" so long as the data actually
fits the int, which for QVersionNumber is 100% of the cases (I'm not even going
to say it's "indistinguishable from 100%" because *no one* uses 2.1 billion
version segments). This problem also only applies to QVersionNumber::size()
and QVersionNumber::SegmentStorage::size(), because only those two would have
the same mangling. All the other functions changed by that commit are new
overloads.
Trying to do the same for QTimer[1] is similar, ignoring the Q_PROPERTY /
QProperty issues. Because it's exported, we'd need to add a new overload, but
that just moves the problem one step further. Imagine:
auto intervalFor(QTimer ) { return t.interval(); }
If recompiled, this code would start returning qint64 instead of int, but
would have the same mangling under the IA-64 ABI, which is bad but mostly
acceptable because it is data-compatible for any timer of less than 24.85 days
(which is ALL of them today).
This above is inline so it goes back to the original problem of non-inlined
inline functions. In the case of our comparison types, someone may see that it
returns auto and decides to write an out-of-line version as:
class MYLIB_EXPORT Foo
{
static decltype(Qt::compareThreeWay(0, 0)) compareThreeWay(Foo, Foo);
};
We'd have to document for them not to do this.
This has also just made me realise a different problem: with MSVC, the mangling
of the function would change. And it's easy to get that problem just by
exporting one's class, because it always exports inline functions and calls
that out-of-line copy imported inline function for anything non-trivial:
class MYLIB_EXPORT Foo
{
int x;
public:
auto compare(Foo a, Foo b) { return Qt::compareThreeWay(a.x, b.x); }
};
So if this user's library is recompiled with a different setting, the ABI
changes. If the user's user's code mismatches the library, it will fail to
link.
Therefore, "Almost Never Auto" applies and especially so for return types
(when used for deducing a type, not for syntactic brevity).
[1] https://codereview.qt-project.org/c/qt/qtbase/+/491119
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 7 November 2023 09:07:10 PST Marc Mutz via Development wrote: > To be clear: This is not about Qt compiled with C++17 used in projects > compiled with C++20. This is about one .cpp file being compiled with > C++17 and another .cpp file from, broadly speaking, the same cmake > target, in C++20 (static builds are different; there, the whole > application incl. all "statically-linked libraries", is one executable). No, it's not. See my reply. Your answer still applies, just that it gets bigger so: > 1. Ban mixing different C++ versions in the same executable (= cmake > target). > > This is probably the safest. If we allowed this instead, we'd need to > review all of our APIs to see whether we have a similar issue already. You must remove "cmake target" portion. This applies to the executable as loaded into memory. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 7 November 2023 06:28:51 PST Ivan Solovev via Development wrote: > Hi, > > I'd like to discuss one more topic regarding the C++20 comparison. > > Can we allow an `auto` return type in helper functions and the three-way > comparison implementation for the built-in types? Answering the question as asked: yes. So long it always resolves to the same thing. > The idea is that these methods can return `Q*Ordering` types in C++17 mode, > and `std::*_ordering` types in C++20 mode. No. They must return the same thing. Choose one and stick to it until Qt 7. > The main reason to use `auto` is that it will allow us to avoid unnecessary > `std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20 > case, which will hopefully be the common case going forward. > > The main argument agains it is the possible ODR violation when mixing C++17 > and C++20 in one binary. > > So, my question is - shoud we support mixing C++17 and C++20 in one binary? Yes. Remember that "one binary" is the process as loaded into memory, including all the libraries. Depending on compilation modes, inline functions may be merged from multiple independent libraries at runtime. So don't violate ODR. At worst, you can make them overload each other by having different parameters. So the Qt functions can switch between the two return type families. But you can't overload operators, so operators must return one family only. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Memory leak in libQt5Core.so.5.15.7
On Tuesday, 31 October 2023 02:35:43 PDT Edward Welbourne via Development wrote: > Khande, Chandrakant Gulab (31 October 2023 09:48) wrote: > > Found the memory leak in libQt5Core.so.5.15.7 > > Following is the valgrind stack, can Qt help to resolve this, any fix > > version available for Rocky 8 > Please file a ticket in the bug tracker [0] - you may need to create an > account to do so. Attach the valgrind log and provide a test program > that reproduces the issue, or at least give some clue to how to > reproduce it. (I see Rocky is yet another Linux [1].) Do not file without a reproducer, because the only new in QEventLoop's constructor is the QEventLoopPrivate, so that issue makes it look like the whole QEventLoop got leaked, which can't happen because it is a stack variable. The most likely scenario is that the application exited without waiting for all its threads to exit. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?
On Saturday, 14 October 2023 12:45:20 PDT مهدي شينون wrote: > As I said in another message, cmake is picking some libraries from MSYS > environment (Which is a fork of CygWin) which is no compatible with > MinGW-w64. So you did, but you hadn't said which one, so the detail escaped me. I looked at the CMake output and didn't see anything wrong. The error was in the linker command-line and I accidentally edited it out when pasting it into the email. Now that you pointed out, yes, the path to librt.a was wrong. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?
On Saturday, 14 October 2023 08:59:01 PDT مهدي شينون wrote: > Hi Haowei Hsu, > > > According the log posted by you, cmake is picking libraries outside of > MINGW64 environment i.e. from MSYS environment and `C:\Program Files\` > which are both not compatible with MinGW-w64. Why wouldn't they be? The only one cmake says it found in Program Files is PostgreSQL: -- [QtBase] Found PostgreSQL: C:/Program Files/PostgreSQL/14/lib/libpq.lib (found version "14.5") libpq is a C API, so it is ABI-compatible with MinGW provided it's the same CRT of course. This is a .lib, so it's impossible to know if it's a static library or a DLL import (because Windows is stupid this way and Visual Studio makes it even worse), and it's likely trying to link the plugin will fail, but the problem happened before that point, so it can't be the root cause. That said, it's a good idea to install the mingw64-postgresql package instead and not depend on C:/Program Files. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?
On Saturday, 14 October 2023 10:53:02 PDT Cristian Adam via Development wrote: > You are trying to compile Qt on a configuration that Qt is not officially > supporting, namely MSYS2. MSYS2's MINGW64 works just fine. I was building using it up until yesterday (now I'm using UCRT64). Anyway, the problem here is not Qt, but the environment, somehow. The symbol "sem_wait" is defined in two libraries: libpthread.dll.a(libwinpthread_1_dll_d000137.o):(.text+0x0): multiple definition of `sem_wait librt.a(t-msys_2_0_dll_d001304.o):(.text+0x0): first defined here Both appear to be import libraries, so I don't know why the linker thinks there's a conflict. I repeat that it works for me, but for Haowei it doesn't. I don't know why. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?
On Thursday, 24 August 2023 23:49:26 PDT Haowei Hsu wrote: > Hello, Qt Development Team. > > I tried to run configure.bat on *6.2.4* branch of qt/qt5 > <https://github.com/qt/qt5> repository. > The following commands are what I run: > >1. *export LC_ALL=en_US.UTF8* >2. *cd /d/Repo/tmp/qt-6.2.4* >3. *git status* >4. *mkdir build && cd build* >5. *mkdir mingw-release && cd mingw-release* >6. *../../configure -release -developer-build -nomake examples -nomake >tests* Do note here you didn't run "configure.bat" as your email subject said. You ran the configure shell script. I don't know if that makes a difference, as I haven't run either for 3 years. If you want to run configure.bat, you must type: cmd \ /c ../../configure -release [...] -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Changes needing review (for over 2 weeks)
Hello I have again a bunch of changes not getting reviewed. Without even a +1, I can't do a Maintainer-approval. So here they are Pending for 3 weeks: https://codereview.qt-project.org/c/qt/qtbase/+/505406 tst_QProcess::startStopStartStopBuffers: depend less on OS configuration Pending for 6 weeks: https://codereview.qt-project.org/c/qt/qtbase/+/498804 QLogging: simplify qDefaultMessageHandler() with a global constant https://codereview.qt-project.org/c/qt/qtbase/+/498805 QLogging: deduplicate the calls to qFormatLogMessage() https://codereview.qt-project.org/c/qt/qtbase/+/498454 QLogging: change the sink functions to take raw 8-bit content https://codereview.qt-project.org/c/qt/qtbase/+/498806 QLogging: use stderr_message_handler() if we fail to grab the handler https://codereview.qt-project.org/c/qt/qtbase/+/498807 QMessagePattern: use the system message sinks for parsing errors https://codereview.qt-project.org/c/qt/qtbase/+/498810 QLogging: call a non-exported message-formatting function https://codereview.qt-project.org/c/qt/qtbase/+/498811 QLogging: disable the message pattern functionality for bootstrap There are also half a dozen 2-week pings I sent over Gerrit; they'll be here next week if they aren't reviewed. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to run configure.bat in qt/qt5 on MINGW64/MSYS2 shell?
On Saturday, 7 October 2023 10:10:05 PDT Haowei Hsu wrote: > Hello, Qt Development Team. > > It's been a while since the last time we discuss this issue. > And recently, I re-tried to configure qt-6.2.4 with msys2/mingw64 shell. > However, it still failed with the same error again: As we've advised before: 1) Build 6.6, not any older version 2) Build in shared mode, not static 3) Build each module separately, not the top-level Once all of the above are working for the modules you're interested in, you can try 6.5. And once 6.5 builds in shared mode, you can try static. I don't think it's a valid request to try 6.2 in static right now. The only reason to build 6.2 in static is if you've already got an existing project building with 6.2 in static right now and want to continue releasing it. That's obviously not the case. Since you're clearly starting a new project, you must start with the latest stable or latest LTS. And if the modules build independently, then you're done. The top-level build is a convenience. That means if it works, great; if it doesn't, then you already had a solution. > > -- CMAKE_BUILD_TYPE was set to: 'Release' > > -- Performing Test HAVE_FFI_CALL > > -- Performing Test HAVE_FFI_CALL - Success > > -- Found FFI: C:/msys64/mingw64/lib/libffi.dll.a > > -- Found ZLIB: C:/msys64/mingw64/lib/libz.dll.a (found version > > "1.3.#define ZLIB_VERSION "1.3"") > > CMake Error at C:/msys64/mingw64/lib/cmake/zstd/zstdTargets.cmake:42 > > > > (message): > > Some (but not all) targets in this export set were already defined. > > > > Targets Defined: zstd::libzstd_static > > Targets not yet defined: zstd::libzstd_shared Looks lik the CMake-provided zstdTargets doesn't support static mode on Windows. Maybe it doesn't support static modes at all or just on Windows. I don't know whether those files come from CMake itself or from Zstandard -- I am guessing the latter. Therefore, you can submit your bug reports here: https://github.com/facebook/zstd If you don't care about the library sizes and decompression performance, you can turn zstd support off in Qt, by passing -DFEATURE_zstd=OFF. > After reading the log, I think it is because the configure process called > find_package(zstd) twice: > >1. The 1st time happens when configuring 'qtbase' >2. The 2nd time happens when configuring 'qttools' > > Let's why the 2nd time thinks the 'zstd::libzstd_static' target is already > defined. > If so, I wondered whether you have any solution to the cause of this > zstd-relared error? Yes: don't build from the top-level. I told you that months ago. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Friday, 22 September 2023 05:46:27 PDT Marc Mutz via Development wrote:
> Where do you draw the line between "Allowing class developers to
> implement the three-way comparison such that Qt can make use of it is
> fine." and "Providing an API for three-way comparison in C++17 does not
> need to happen."?
At our maintenance cost. If it costs us more to create something they can use,
then it needs to be long-term justified. A short-term requirement for people
who can't upgrade requires a very high justification.
> How is said Qt class author supposed to implement his cmp(lhs, rhs) if
> there is no "API" for doing this on his data members? As a concrete
> example, how is the author of a `struct QFoo { int; QString; }` supposed
> to implement his cmp() if all he gets is op<=>, a C++20-only API?
How they implement their three-way comparison for their internals is their
problem. So long as they somehow provide the method that our macros require,
they can use the macros.
But we don't have to help them there. We can't help them with types from
third-party libraries we don't know about in the first place; they have to
implement the three-way comparison themselves anyway. Having a (4) that allows
them to compare Qt types and compose solves 99% of the problems. For the rest,
they can figure out on their own or just use the spaceship operator.
And this is even assuming that we document the macros for public use in the
first place.
> I don't see how we can manage without an API for doing three-way
> comparisons in C++17.
>
> We can try without (4), but (1)-(3) must needs be "semi-public" API (not
> in _p.h's).
I'm ok with semi-public. That means I can change them or remove them.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Thursday, 21 September 2023 02:10:22 PDT Ivan Solovev via Development wrote: > But I'd say that if someone wants to implement three-way comparison for > their classes in C++17, then a bit better understanding of the language > features is a reasonable expectation. Allowing class developers to implement the three-way comparison such that Qt can make use of it is fine. That's basically allowing them to use the same technique we will be using to make our classes three-way comparable. Providing an API for three-way comparison in C++17 does not need to happen. People can upgrade to C++20 or complain to their vendors. We are talking about adding this to a Qt release to happen in 2024, nearly 4 years after the C++ edition was published. I won't oppose it if it is simple, without imposing undue constraints. But it need not be part of the initial design. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 20 September 2023 02:53:37 PDT Volker Hilsheimer via Development wrote: > If we can have (1), i.e. > > using Qt::equals; > equals(a, b); > > why do we need qEquals? See my other email: the (1) is not discoverable, teachable, or particularly understandable by average C++ developers. It is not a good corner of C++. (4) (the convenience function) is what users expect. Except that we don't need it to be called qEquals, because we have an even better name for it: operator== -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Thursday, 14 September 2023 03:47:05 PDT Marc Mutz via Development wrote: > Whenever you want to add an operation to _all_ types in the C++, > built-in, as well as user-defined one, you obviously cannot use > something that only works in classes: member functions don't work and > neither do class-static functions. Simply because you can add neither to > the type `int`, or the type `int[10]`. Right, but the number of primitive types is limited, so we can exhaustively cover them with our implementation. That only leaves non-primitives, which can use member functions (whether static or not). But I have nothing against friend or hidden friend functions found by ADL. > The gold standard, crystallized from 30 years of C++ experience _and_ 30 > years of Qt experience, requires four things: > > 1. an ADL-able calling convention: `using std::swap; swap(lhs, rhs);` > 2. an implementation for built-in types: `std::swap` > 3. an implementation for user-defined types: ADL `swap` > 4. (optionally) a convenience wrapper: `std::ranges::swap()`, `qSwap` That gold standard is horrible API. I'm not disputing it's the gold standard, I'm simply saying it's horrible API because people don't write "using std::swap; swap". That necessary trick is not discoverable until you've seen yourself, leads to pitfalls, and is must always be explained when taught, because it's not obvious why it's necessary. ADL is not the simplest portion of the language. Therefore, > In addition, experience tells us that we cannot afford to use the > convenience wrapper outside generic code, because it's too slow to > compile (cf. https://codereview.qt-project.org/q/topic:qSwap). teachability, readability, and discoverability trump compilation speed. Compilation speed is important, but it's not more important than designing a good API. If it takes CPU time to compile good code, then so be it. Exhibit A: ranges. Ivan wrote: > One more question here - do we want our users to be able to do (1), or > is it enough to expose only (4) to them? > The reason for my question is (again) naming, see below. We can go with (4) only for now, to have good API. If we need to because it's unacceptably slow, we can then make (1) public, though we'd have to have chosen an acceptable API for it or we'd have to go and change it so it could be made public. There's no conclusion in what direction to take in your email. I don't see anything that would refute my conclusions. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
