I think it is because your audience target. Maybe this helps?
Sign in to studio.youtube.com (Web studio only). On the left menu, click Settings. Click Channel. Click the Advanced Settings tab. Under Audience, select: “No, set this channel as not made for kids. I never upload content that’s made for kids.” Click Save.
Alfkil, from what little I saw, your work on Qt6 looked FANTASTIC! Very impressive.
Thank you very much for all your efforts! You're making it look easy!
...as for the stream. Well, to put it mildly. It was disappointing. It really demonstrated how the stellar the efforts of tekmage at Amiwest are. He makes it just work!
The stream started out playing with video/sound. But then it was restarted as "restricted content". That killed playing it on the Amiga. Meh.
The chat was on goggles? Geez. Why not do it on an IRC channel? It literally takes TWO WORDS to set up, can be joined on any machine and doesn't involve a peecee or bending over for goggles.
Alfkil, I hope you consider doing an Amiga friendly stream & chat next time.
Is there any reason why this YouTube video has a age restriction...? Not everyone is registered to YouTube. @alfkil Can you please remove that? Thanks!
Thanks to all who supported! And sorry for the sound issue!
I will spend the next weeks fixing up an SDK for release. Once I succeed, I will test everything thouroughly and then do a fresh stream. Sounds issue has been fixed.
The setting for age restriction has been changed, but sadly the on-stream chat has been lost. :(
I looked a bit through sources files named "*amiga*".
Timing code is buggy.
After AbortIO() you still need to call WaitIO() otherwise request does not get removed from reply port. Also you should not call AbortIO() on a request which was never SendIO()ed.
When receiving timer signal this does not necessarily mean that the request has completed. Check if request has arrived back at reply port. For example with GetMsg() which does the "remove from reply port", too, which is also missing here.
In "if (include_timers && caughtSignals | 1 << d->timerPort->mp_SigBit)" the | should be an &.
Not related to timer stuff, but if there's things like intuimessages where more than one message can end up at the MsgPort at the same time, then when receving the signal you must loop over and handle all messages on the msgport otherwise you create ~"laggy/delayed" response to events. The task's received-signal-mask gets the signal bit cleared after the Wait() call. It does *not* reflect the is_msgport_empty_or_not state.
Thanks for your thorough code review. I will do an update and brush over as soon as that seems timely. For the time being, I have just done the code as quickly as possible for things to function minimally. Of course I need to brush over things, when everything is up and running. Thanks! :)
@thread
Has there been a discussion on rpaths?? It seems to not do anything to the linking process, when stuff is added here, and it would be quite useful to have this feature for qt programs.
@trgswe
I have checked the specification, and you are absolutely right, that it doesn't specify anything along the lines of what I am suggesting. This doesn't mean, though, that there are not some kinds of interpretive discrepancies present in the actual implementations (the build/runtime linkers respectively). I will probably have to check the compiler sources themselves (dreadful...).
Just got a youtube video that might interest you (and the gcc guys too) the video is Quote:
Leon Matthes - Reimplementing Signals, Slots, Properties and Bindings from Qt in pure C++17 [url]https://m.youtube.com/watch?v=QvV3WMFCQMU&t=178s[/url]
look in the channel 'Meeting Cpp' and they have had a recent video about the 'C++23 Standard library Preview' for those really interested in C++. The library is at https://github.com/KDAB/KDBindings
In the meantime - this issue needs to be fixed, if we want a dynamic linking version of Qt6. The dynamic link version is a requirement for building qt-creator, so it is quite cruzial.
I will do that, if the next step fails. Thanks for mentioning!
@thread
Could someone please repeat the correct use of -fPIC when building shared libraries and applications that use them?? I want to be absolutely sure, that this is in fact the problem here, which would be wonderful.