Qt5 demo #17
Comments
|
Thanks Kelly! Which Qt version are you using? 5.4.1 here. But I forgot to push the module maps I used, which may be the cause, could you copy them into Qt5's include/ folder and give it another shot? I think I know what's happening with set.d, I'll push a fix asap. |
|
set.d compiles fine here, are you using a different version from the one you committed? |
|
Any difference with the latest commit? |
|
Hello Elie, Yes, the last commit fixed the set example here. I have expanded the example also and will push a PR soon. I will close this. Thanks for the quick fix. |
|
Woops, I'll reopen this as I didn't comment on the Qt5 questions you had. I am using Qt version 5.2.1 because that is what comes with Ubuntu14.04. My command line is slightly different also, with just a couple changes for the include/lib locations: ... -cpp-args -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -cpp-args -I/usr/include/qt5 ... -L-rpath=/usr/include/qt5 -L-rpath=/usr/lib/x86_64-linux-gnu/qt5/ ... I didn't need the modulemap files to get the demo compiled and running here :) Woohoo! Great stuff. I'll see about getting a small tutorial together at some point here. Thanks, |
|
Hello Elie, After this demo was changed to inherit from QtWidget, I now have to use the modulemap files to get it to compile. Just so you know. I am sure you are aware but it also takes a VERY long time to compile. Hopefully we can look at speeding things up once some other libs work. Also as an aside, if you fix a particular test case in the libstdc++ tests with a certain push, can you make note of it, please? That will make it easier to test here, as I have several large libs that could be tested further if I knew which push fixed which problem. Otherwise, I spend a lot of time going through at least a dozen libs re-testing after each new push. Thanks, |
|
Yes compilation times make testing big libs a pain. I'm looking into how to avoid running codegen over the already compiled C++ modules if the PCH hasn't changed in the meantime, that should help a bit.
Ok but currently I'm focusing on getting other libs to work, and only check if the working libstdc++ examples aren't getting broken by the new commits. |
|
Ok, sounds good on the compilation speed stuff. I remember you had said we may be able to use a previously compiled PCH file. Hopefully it helps a lot. If you are working on other libs and push a fix, it would still help to know which lib that helped with. Not a big thing, it would just make things a little more clear for me :) |
|
Hello Elie, A few things today. One: Some time in the last ten commits or so (before today) list.d has broken and is producing an LLVM codegen error. Two: The 'Improve the mapping of MaterializeTemporaryExpr.' commit has broken the qt5demo example here. I can pull the other fixes from today and they work, but this commit causes an error with QtDummyQString. A temp being generated when instantiating a new QString, I suppose. Three: Now for the long and fun part :) I have tried to convert the larger Qt5 demo project listed here: http://doc.qt.io/qt-4.8/qt-mainwindows-application-example.html This took a while to do, as I had to work around quite a few problems. Now here is the first interesting (and frustrating) part...I was able to get down to about 10 errors in the conversion and it somewhat worked, then I rebuilt Calypso with today's changes and rebuilt the demo...a bunch of 'undefined refs' showed up?!? These were problems I had previously run into and had fixed!! So it really seems like the caching mechanism was helping me along previously, and then when rebuilding from scratch it bit me in the backside. Then I went on and I commented out all the 'undefined ref' issues again and start randomly trying to fix them. I can see I am making a little headway, but I have to fix things in the exact right order to get past these errors. It is just quite strange and time consuming as I have to get this correct order again, it seems. Strange. As an example, originally QFile.isEmpty() was not being defined, but then I somehow managed to get it working yesterday (I don't know what I changed to make it work) and now it is back to an undefined ref on this one function. QFile.isNull() does work though, so I don't know why it is just this one function?? There are a bunch of other problems that we can get into later, but one main problem for the menubars and toolbars is that the QAction(QAction_) overload isn't being picked up by Calypso... ie. if I try to bulid a new QAction with a QAction_ then I get a list of ctors in the error message and QAction(QAction) is not in that list. Not sure why. (QAction(QAction_) is the last constructor in the source code, so maybe there is an off by one error somewhere??). I think I saw a similar error for a different lib before, but I could get around it by just using a different constructor, but that won't work in this case. Now to the biggest future problem (that I would suppose you ran into)...signals/slots require the MOC compiler! I can trick Qt into thinking that we used MOC for the signals, but the slots are definitely a problem. While looking into fixing this I ran into a project by the fellow that wrote the MOC compiler called moc-ng (https://github.com/woboq/moc-ng) that uses libclang in place of MOC. Looks interesting, and like it could be spliced into Calypso to fix this issue, but I didn't know if it was worth looking into further yet. I believe that being fully compatible with Qt would be a huge deal and really allow easy cross platform GUI development with D, so I wanted to at least point this out and get your thoughts on moc-ng and it's integration into Calypso. Thanks, |
|
Sorry about the breakage, I was aware of it but 3bcf445 fixes Druntime and Phobos, which have been broken since April 23rd! For your linking errors you shouldn't have to comment out anything, but the why some symbols are missing can be quite obscure. If your translation gets past codegen and only fails at linking make a PR and I'll investigate the linking errors. I'll have a look at QAction this evening.
Yes depending on what you import C++ modules .o files might be more or less big, and whenever you import more modules emitted symbols might be spread across more .o files. However if beforehand you were importing more C++ modules then there's a risk that a cached module object file depends on another object file that isn't being linked anymore. So the caching is fragile for the time being, I need to emit the functions differently to avoid this. When you get a doubt remove the calypso_cache.gen file.
Couldn't moc be replaced by D templates and mixins? I think QtD did something like that and here's an almost successful attempt to replace moc by C++11 features: http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html |
Right, I had fixed Druntime and Phobos a couple weeks back with a few edits and hadn't thought about it since. Then with that change I had to revert my fixes, so I figured that is what you trying to fix. With the newest commit today for temporaries, the qt5demo project builds again, thanks.
Ok, sounds good. I assumed it was a little fragile...but after looking into this a little more it doesn't seem to be the caching that is completely responsible for this. What appears to have happened is that I changed the build command to use optimization (-O3 specifically because it sped up builds even more than just caching) and that is when things broke. So it appears as though functions like QFile.isEmpty() are being optimized out, but since I hadn't rebuilt from scratch in a while, I didn't get the errors until a complete rebuild. I have rebuilt the entire project without any optimizations and everything works fine again (except the 10 or so errors I previously had).
Yes, I suppose we could look at something like what QtD is doing, but I think that is probably a few thousand lines of code (after a quick perusal), whereas I would think the moc-ng solution is probably more comprehensive and less fragile. There are a few thousand lines in moc-ng also, but there might be quite a bit of overlap with Calypso...I can take a look. I didn't mention the C++11 fix because our C++11 support is a little spotty and that solution wasn't completely successful...moc-ng is mentioned in the last line of that page, which is actuall how I found it :) Thanks, |
I don't see it in Qt 5.4.1, this is what I have: explicit QAction(QObject* parent);
QAction(const QString &text, QObject* parent);
QAction(const QIcon &icon, const QString &text, QObject* parent);
(...)
private:
Q_DISABLE_COPY(QAction) // expands to QAction (const QAction &) = delete ;Or did you mean the first one? Try an explicit cast: cast(QObject*) yourActionNo idea why DMD does implicit casting from a class reference to the same class pointer yet doesn't do implicit casting from a derived class reference to the base class pointer. |
|
Hello Elie, Sorry about that, I was looking at some old 4.x code online (I think it was 4.x) and didn't look at the 5.2.1 code. I have the same code as you above and I get past the error with the explicit cast (though I could have swore I tried that, as I have had to explicitly cast in other places)...thanks, though...now the problem is that I try to add the action to a menubar like this: I noticed that I needed to explicitly cast fileMenu to a QWidget (or I get a similar _ctor error as with QAction). That is fine ... the newAct action is properly set up in createActions() without problems, but when I run this I get: 0x00007ffff772804b in QWidget::setParent(QWidget_, QFlagsQt::WindowType) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 So I try to work around this by explicitly setting the parent with: but then I get this: 0x00007ffff7720f2c in QWidget::insertAction(QAction_, QAction_) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 Ugh. So I can't really see how to get past this part. Even if all this works the actions still need a signal/slot and connection, but I would like to at least be able to see the menubars being constucted and showing up in the example. I could post the entire bunch of code if you wanted to look at it. Thanks, |
|
Hi Kelly, I may have figured out the cause, which is also why the explicit casts were needed, this wasn't DMD's fault. I'm working on a fix but it's not a simple one. |
|
Hey Elie, Just wondering how this fix is coming as I haven't heard from you since last weekend? :) I was also wondering if you are going to the D Conference next week? I am not planning to at this point, just so you know. I have fixed a couple things here to get the GDAL example to work, and to see if I could get a Quantlib example to work. Small things like ParenListExpr returning a new NullExpr in fromExpression, just to get past a crash and backtrace...I also fleshed out MemberExpr, as it is needed to compile my Quantlib example. I can work out a PR for these things eventually, but they aren't critical and I didn't want to bother you too much ;) Thanks, |
|
Hi Kelly, I haven't had a moment for myself for 2/3 of the week, it's only now that I can come back to coding, in a pretty new environment :) And no, I wanted to come at DConf but there's been an unexpected incident at my work and I need to be there on Monday and Tuesday. About the fix the issue is that I thought D was like C++ and that « SomeClass* » is a pointer to the value, but in D it's a pointer to the reference. Albeit wrong this simplified things a great deal because it was easier to keep a 1-to-1 correspondance between DMD and Clang's types. Now DMD's TypeClass isn't enough and has to keep more info for C++ classes: pointer or reference? logical const? This part is fixed, but also broken was the template argument deduction e.g for default arguments, DMD's deduction is "incorrect" because the additional info for C++ classes is lost. So I'm currently telling Calypso to use Clang's argument deduction. But this will put a lot more on the shoulders of toExpression and toType which are still a bit primitive. Here's why it's taking some time.. |
|
Were we supposed to write a tutorial before the Conference tomorrow? I haven't started one yet because I was going to use the GDAL example, but it needs some of my local changes to work. We could just use the Qt example but it might seem a little feature incomplete without a signal/slot solution, as that is a major part of the gui really. |
|
Sorry, I couldn't get the time and also couldn't make the demo + the tour of Calypso workings I told Walter about. Starting from today I'm on vacations for 10 days, but work and moving to a new place made me miss the deadline. The GDAL example would make a great tutorial. I'll go back to your PR straight after finishing the fix (in a few hours hopefully) and try to understand why it's needed. |
|
I keep running into new errors.. |
|
Ugh, that's too bad, I thought we were pretty close on this one :( Do you still think it is manageable eventually, or is Qt a no-go for the foreseeable future? |
|
Finally, phew! Could you try the Qt example you were working on again? I think it should be fixed now, and no more explicit casts needed. |
|
Great stuff Elie. After just a quick download and test, things look good here for the expanded demo (no casts needed). I will continue to test here and try a few things in the demo that I had to work around in the past. I will also test GDAL some more and see how it goes. I'll let you know later tonight, probably. |
|
This is good now, several new things work in the expanded Qt5 example. I can actually add actions the the menubar and display icons (the menubar reacts to clicks to open and close the popup menu, but there is no action associated yet because of the signal/slot problem still). There was several other fixes, like no segfault on shutdown, being able to pring "File Loaded" in the statusbar on the bottom of the window and no segfault when trying to setModified(false) for the textEdit widget. Hopefully I can fully flesh this thing out by tomorrow, with all the menus and toolbars, etc. (everything except the signal/slots), then I'll push the demo. I will also look into expanding the GDAL demo since it seems to be working nicely now. |
|
Hey Elie, Things look like they are pretty much back to where they were a couple weeks back, except that I can't seem to coerce a parameter to a 'ref (const) QString', for example. So if I try to just construct a QMessageBox like this: QMessageBox.about(&parentWin, cast(const)QString("About Application"), cast(const)QString("The Application")); then I get the error: qt5demo.d(117): Error: function cpp.QMessageBox.QMessageBox.about (QWidget* parent, ref const(QString) title, ref const(QString) text) is not callable using argument types (QWidget*, const(QString), const(QString)) QMessageBox's signature is: QMessageBox(Icon icon, const QString & title, const QString & text, StandardButtons buttons = NoButton, QWidget * parent = 0, Qt::WindowFlags f = Qt::Dialog | Qt::MSWindowsFixedSizeDialogHint) This happens in quite a few places in my expanded example. So I guess the question is: can I coerce this somehow, or does Calypso have to do it for me? :) Thanks, |
|
Hey Kelly, That's because ref parameters still don't take rvalues in D (there seems to be an end in sight: http://forum.dlang.org/thread/mm81tt$bph$1@digitalmars.com, let's hope it gets somewhere) It's ugly but turning them into lvalues should work: auto aboutStr = QString("About Application");
auto appStr = QString("The Application");
QMessageBox.about(&parentWin, aboutStr, appStr); |
|
Did we cover the gist of it? |
|
Hmm, I am getting all kinds of errors for qtdemo now? (Dozens of other warnings and possibly a few errors before the output below also!!). This is with clang-3.6.1: |
|
Damn.. are you enabling C++11 by any chance? On my config the demo compiles fine with C++11 disabled, but I have libstdc++ 4.9 installed instead of 4.8. If you confirm that C++11 was disabled, then I'll investigate with libstdc++ 4.8. |
|
Oops I broke the Qt demo with the latest commits, should have tested before the push. Just to be clear to compile the demo one hour ago I checkout'd the last commit from two days ago. |
|
Fixed by 7ad2f8d. |
|
Ugh, we must be using different versions of libstdc++ and Qt or something??? I am not enabling c++11 support. I am just using the example qtdemo5.d from Calypso's github (not my modified version that I was testing months ago), and the same build script I have been using for months. I get hundreds of errors like this (and then the same errors I listed in my last comment) even after 7ad2f8d ... I didn't mention them above because I just thought they were warnings (I usually get a ton of warnings when compiling the demo): |
|
The "error:" lines are from Clang, it's noise when it fails to instantiate templates which are then just marked invalid and not used, I haven't looked yet into how to turn the diagnostics off. Most libs making big usage of templates have a lot of those errors. It's the "Error:" lines from DMD which are not good. If you're not enabling C++11 then I'll have to look into it tomorrow.. BTW I forced a push with b23a25b because a last-minute change was wrong and the fix was not working anymore, sorry about that. |
|
Hi Kelly, I finally got to test with libstdc++ 4.8 and it compiles fine. Does the "Error:" lines still happen to you? My environment is:
|
|
I'm using Qt 5.2.1, clang 3.6.1 and libstdc++3.4?? I guess. Not sure how I have that old of a std c++ lib with g++-4.8 installed? I get this set of errors: Followed by a seg fault with this partial stack trace: |
|
I've fixed these errors with Qt 5.2, but now I'm getting obscure errors once more with Clang modules. Trying to figure this out.. |
|
Fixed with the latest commit. |
|
Ugh, it looks like things changed but they aren't fixed for me darnit: |
|
I see what's happening, DeclReferencer assumes that all the specializations of a template are within the same module whereas they are scattered across QtCore, QtWidgets, etc. In this case it's also because the module map file from utils/ is tailored for Qt 5.4/5.5, so some template specs end up in "_". It worked for me after I adjusted the QtCore.modulemap_d file for Qt 5.2 with: Here's a working file: https://paste.kde.org/pummmw66h Still DeclReferencer needs fixing.. |
|
Woot, woot!! That worked. Builds and runs fine now, thanks Elie :) I will test my larger example also. |
|
The bigger example runs pretty well again. A few lines that used to need a work around are now running fine, also, so things are better now. Just the signal/slot problem, so hopefully I can flesh out a full example now soon. |
|
The build was broken again by enabling debug info, but it should still be working without "-g" though. I'll look into it this evening. |
|
Still trying to figure this out, plus another new error with QColor. One very ugly workaround for the first error is to add |
|
The QColor error is fixed, without |
|
Yep, it is working here again. Thx |
|
Hello Elie, I have a fully functional (except writing out settings??) demo of this example finally: http://doc.qt.io/qt-4.8/qt-mainwindows-application-example.html I have the signals and slots working and everything now...woohoo :) We need to use the moc compiler and have a minimal C++ 'DLangMainWindow' class inheriting from QtMainWindow, then inherit from DLangMainWindow in the D code, catch the Qt signals and translate them into D signals. A few hoops to jump through but not TOO arduous once there is a small framework set up. I will make up a PR for this and the fastflow example in the next couple days. Might try to flesh out the Makefile a little more, so that the moc compiling steps are easier (just three steps though, so easy enough). Just too tired to do it now. |
|
Hi Kelly, awesome news! And the workaround sounds minimal and elegant. As for me this week can be summed up by me getting bogged down trying to fix the debug info error, which is due to C++ relying on lazy instantiation whereas DMD instantiate everything, so I'm not even sure yet that it's possible to fix this without modifying Clang. |
|
Debug info generation was fixed about 10 days ago. |
Hello Elie,
Spectacular job on getting far enough to get a Qt demo to work. Unfortunately I can't quite get it to build here :(
I am also getting a couple new errors in the libstdc++ tests, and the pertinent one is when compiling the 'set' example. The reason this is pertinent is that I get the exact same error with the Qt5 demo, but the example is so simple with set.d that it might be easier to track down. When compiling set.d with "ldc2 -L-lstdc++ set.d" I get this error:
And I also see that 'trivial dtor' error above when compiling the Qt5 demo (right after Calypso tries to output the code for 'allocator').
So I am not sure if you were seeing this error for set.d or qt5demo.d or not, but I am seeing it here. I don't have any extra modulemap_d files anywhere or anything...everything is the same as a few days ago when set.d worked, so I don't know what is going on.
Have you run into this before? Any ideas on how to fix it?
Thanks,
Kelly
The text was updated successfully, but these errors were encountered: