Alpha4 release status

Mon Jun 11 16:29:06 UTC 2012

On 06/11/2012 06:11 PM, BogDan wrote:
> Hi Harri,
>
>
>> Reading David Turner's mail from [1], it seems that Android atomics are
>> not SMP safe either, so in that sense using those is not any better than
>> Qt atomics?
>>
> Last time when I checked their code they were. Indeed armv5 is not SMP safe,
> but it doesn't need to be, as I said I know no SMP device which are using arm5
> android. The problem is that Qt "exports" the atomics as inline function, which
> means that their content will be "copied" into your application, meaning that
> your application will uses those atomics everywhere.
> My fifth proposal tries to fix this problem by removing the inline and your apps
> will use whatever qt comes on that platform.
>
>> In your solutions list you refer "fast atomics", but what are those? 
>> If I understood you correctly, there are 3 options, Qt, android and
>> gcc.   First two are fast but not SMP safe, last is slow but SMP safe.
>>
>> Are you saying that Qt armv7 is SMP safe and fast?
>>
> Yes, armv7 is (can be made) SMP safe and is much faster comparing 
> with gcc's implementation.
>
>> If so, I'd vote for dropping arm5 support.  It would also make the
>> development/testing cycle faster with one less architecture to
>> support.   Usually arm5 devices are so low end with memory/screen/speed
>> wise that they don't work well in any case.
>>
> I can't drop arm5 devices :) ! They are too many to be ignored.
is there a list somewhrere to know which devices are out there? and with 
which arm?
>
>> I'd rather have a Qt that is ready and working well for a subset of
>> devices than none at all.
>>
>> I don't care about backward compatibility for my Qt Android apps (yet).
>>     I can always recompile those, and if I don't, the deserve to die. 
>> While it is in Alpha this is expected.  Once in beta, backwards
>> compatibility is required.
>>
> If the ABI break can be avoided, I'll do it !
>
>> The way I see it, Qt/Necessitas can get lots of new developers
>> interested for new projects if basics and new stuff works well. So I'd
>> worry about new devices, Qt 5/QML, and try to trim down work required on
>> maintenance type activities.   So from my perspective QtWidgets, arm5,
>> backwards compatibility all can be dropped now.
>>
> After alpha4 and beta1 will be out I'll focus on Qt 5 and QML. For beta1 I 
> wanted a QML implementation which has the same look&feel as any 
> Android application, I hope somebody will step up and will do it.
>
>> Anyways, keep up the good work!
>>
> Thanks for your kind words.
>
>> Just my 2 cents,
>>
>> Harri
>>
>>
> Cheers,
> BogDan.
>
>>
>> On 06/10/2012 09:15 PM, BogDan Vatra wrote:
>>>   Hi,
>>>
>>>   Many thanks for kind words !
>>>
>>>   Sadly, the magic happened :). The good news is that it was my fault,
>>>   the bad news it that my worst nightmare happened ... :(
>>>   After I write my first mail I begin to cherry-pick all my changes from
>>>   alpha4 and put them on top of alpha3 branch, then I spot a patch which
>>>   caught my attention, and I really hoped it's not the cause of this
>>>   problem, but it was ...
>>>   Some time ago somebody complained on this mailing list about the fact
>>>   that he could not be able to compile necessitas anymore using ndk-r7,
>>>   soon I discovered that the atomics functions where not exported
>>>   anymore in ndk-r7, then my nightmare began, first I post the problem
>>>   on android-ndk mailing list[1], then Google suggest me that I should
>>>   switch to gcc's built in atomics which I did[2]. I knew that the gcc
>>>   built in atomics are not the fastest in the world, but I never thought
>>>   that they are that bad. Android atomics support on necessitas is a
>>>   long story, which began more than a year ago, I'll try to make it
>>>   shorter for you :)
>>>   For the very first android atomics implementation, I used Qt's arm
>>>   atomics, but I had to switch to gcc built-in atomics (yes, the second
>>>   implementation was based on gcc atomics) because Qt's arm5 atomics
>>>   where useless for Android, I'll try to explain why: The problem is
>>>   that Qt's arm5 atomics are not SMP safe, so, is probable that your app
>>>   will crash on a dual-core device. arm5 is very important because it is
>>>   supported by all arm android devices, so it must be SMP safe. I
>>>   address this problem last year at QCS[3], and somebody offer to help,
>>>   but sadly nothing happened. So, I had to find a solution myself, GCC's
>>>   implementation is using a sort of memory barrier (a mutext or
>>>   something) to make it SMP safe, that why is so slow, then I discover
>>>   that google is providing atomics in libc, which they should be SMP
>>>   safe, so I switched to android atomics, then google change their mind
>>>   and now they are dropping the support, so I had to switch back to gcc.
>>>
>>>   To "fix" this problem I see the following "solutions":
>>>   1. Ignore Google warning and keep using android atomics.
>>>   2. Stay with gcc atomics, but is too slow.
>>>   3. Build Qt libs with fast atomics, but find a way to have safe
>>>   atomics for arm5.
>>>   4. Build Qt libs with fast atomics, but use GCC atomics for apps.
>>>   5. Build Qt libs with fast atomics, but don't make qt atomics inline
>>>   anymore, this way your apps will use what qt provides for that
>>>   platform. They will be a little by slower but they should be safe.
>>>   This is my favorite solution, but I afraid that it will break the ABI
>>>   ...
>>>
>>>   It is safe to build Qt libs with fast atomics for arm5 because arm5
>>>   libs will be downloaded Ministro *only* on arm5 devices and AFAIK
>>>   there is no SMP arm5 device. The problem is that your apps are not
>>>   downloaded by Ministro :) and if they are built only using armv5 they
>>>   will be loaded by a SMP device and they will have problems, so arm5
>>>   atomics must be SMP safe.
>>>
>>>   Anyway we have to address the problem once and for all !
>>>
>>>   If any of you has any other Ideas please don't hesitate to share them
>> with us.
>>>   Also any comments/feedback will be very appreciated.
>>>
>>>   Cheers,
>>>   BogDan.
>>>
>>>
>>>   [1]
>> https://groups.google.com/group/android-ndk/browse_thread/thread/a792d8392b01f389/ecbad8bb4981ed8d
>>>   [2]
>> http://commits.kde.org/android-qt/aa14a65fd29f20adb7aa22b354c975d76266bed1
>>>   [3] http://community.kde.org/Necessitas/Meetings/QtCS2011
>>>
>>>
>>>   2012/6/10 Bruno Zerbo<bruno.zerbo at gmail.com>:
>>>>   Thanks BogDan for your work.
>>>>   cheers,
>>>>   Bruno
>>>>
>>>>
>>>>   2012/6/10 BogDan Vatra<taipanromania at gmail.com>
>>>>>   Hello folks,
>>>>>
>>>>>     Unfortunately I have more bad news regarding alpha4 release, I
>>>>>   manage to fix the OpenGL problem, but I discover another one. The
>>>>>   startup of all applications has slowdown a lot (2-4 times), the
>>>>>   problem is the difference between alpha3 and alpha4 is huge (1000+
>>>>>   patches). Alpha3 is based on Qt 4.8.0-rc and alpha4 is based on Qt
>>>>>   4.8.2, to be sure the problem is not caused by me, I have to
>>>>>   cherry-pick all my changes and put them on top of alpha3, them, if
>> is
>>>>>   not my fault the pain begins, I'll have to merge Qt 4.8.0,
>> check, then
>>>>>   Qt 4.8.1, then Qt 4.8.2. This is going to be a very slow and
>> painful
>>>>>   process which will take days (even weeks) so, I don't believe
>> alpha4
>>>>>   will be out before QCS, unless a miracle happens and I'll found
>> the
>>>>>   issue in the next days.
>>>>>
>>>>>   Sorry for the bad news ...
>>>>>
>>>>>   Cheers,
>>>>>   BogDan.
>>>>>
>>>>>
>>>>>   2012/6/4 BogDan<taipanromania at gmail.com>:
>>>>>>   This
>> http://files.kde.org/necessitas/installer/MinistroActivity.apk is
>>>>>>   the link to Ministro.
>>>>>>
>>>>>>   BogDan.
>>>>>>
>>>>>>
>>>>>>   On Jun 4, 2:02 pm, BogDan Vatra<taipanroma... at gmail.com>
>> wrote:
>>>>>>>   Hi everyone,
>>>>>>>
>>>>>>>     As you may know the alpha4 release is approaching, the
>> plan is to
>>>>>>>   have it ready before Qt Contributors Summit. It is almost
>> completed, I
>>>>>>>   need a few days to polish the style plugin and Minitro and
>> another few
>>>>>>>   to add support for context menus.
>>>>>>>
>>>>>>>      A few days ago I pushed to Minnistro's
>> "unstable" repository the
>>>>>>>   current alpha4 branch in order to check if the existing
>> released apps
>>>>>>>   are still working. Even we've made some heavy changes
>> and even if I
>>>>>>>   warn you that it may break the compatibility with older
>> versions, I
>>>>>>>   wanted alpha4 to be backward compatible with alpha3, it is
>> also a test
>>>>>>>   for Necessitas developers to see if we can keep our
>> promise: to ship
>>>>>>>   releases which are backward compatible!
>>>>>>>
>>>>>>>   If you want to try it yourself please follow the next two
>> steps:
>>>>>>>     - uninstall official Ministro and use this
>>>>>>>   onehttp://files.kde.org/necessitas/MinistroActivity.apk.
>>>>>>>     - install and run Ministro configuration tool (from
>> market) and
>>>>>>>   choose unstable repository.
>>>>>>>
>>>>>>>   Don't forget that Ministro is not stable and it may
>> crash/hang, if you
>>>>>>>   encounter any problems please reply on this thread.
>>>>>>>
>>>>>>>   Shorty after the repository was ready, I tried a few apps
>> from market
>>>>>>>   and two major problems pop up:
>>>>>>>   - The first problem was related to some missing symbols and
>> was caused
>>>>>>>   by compilation/linking flags.
>>>>>>>   - The second one is related to OpenGL and it seems to be
>> caused by the
>>>>>>>   merge with Qt 4.8.2.
>>>>>>>
>>>>>>>   1. Missing symbols problem: Android comes with almost no
>> support for
>>>>>>>   C++, so to compile Qt we used (static) gnu-libstdc++.
>>>>>>>   Then I discovered that this was a big mistake (for more
>> information
>>>>>>>   check Android NDK docs/CPLUSPLUS-SUPPORT.html "II.3.
>> Static runtimes:"
>>>>>>>   section).
>>>>>>>   We can not use link libstdc++ statically if we are using
>> more than one
>>>>>>>   shared libraries in a project. To fix this problem I had
>> two choices:
>>>>>>>     - to use the shared libstdc++ implementation and to
>> change all the
>>>>>>>   scripts in order to add it to ministro (1.2M).
>>>>>>>     - to "embed" the whole library into QtCore
>> library (it adds and extra
>>>>>>>   600K) but this change requires no additional changes.
>>>>>>>
>>>>>>>   I choose the second one [1],[2] because it was safe and
>> easy and
>>>>>>>   mostly because it didn't needed any other changes.
>>>>>>>   If anybody has something against this change speak now or
>> forever hold
>>>>>>>   your peace !
>>>>>>>
>>>>>>>   I'd like to add exceptions and RTTI by default, if the
>> size and speed
>>>>>>>   will not be affected.
>>>>>>>
>>>>>>>   2. OpenGL problem: After I merged alpha4 branch with
>> upstream Qt
>>>>>>>   4.8.2, most of the OpenGL apps are not working anymore, I
>> tried to fix
>>>>>>>   it my self but I end up with a very ugly workarround. It
>> seems that
>>>>>>>
>> "boolQGLContext::areSharing(constQGLContext*context1,constQGLContext*contex
>>>>>>>   t2)"
>>>>>>>   always returns false. I tried to trace the problem but with
>> no luck
>>>>>>>   and I end up adding a super dirty workarround: on android,
>>>>>>>   "QGLContext::areSharing", will always returns
>> true. I really don't
>>>>>>>   like it, so until we'll figure out what is wrong the
>> release process
>>>>>>>   will stop ...
>>>>>>>
>>>>>>>   Any help will on this matter be very appreciated !
>>>>>>>
>>>>>>>   I've spot another minor problem with old assets support
>> it was caused
>>>>>>>   by "QString
>> QDeclarativeTypeLoader::absoluteFilePath(const QString
>>>>>>>   &path)" I fixed it locally but I didn't had
>> time to push the fix to
>>>>>>>   Minsitro's repository yet.
>>>>>>>   I'll keep you post with the progress and with any
>> Ministro repository
>>>>>>>   changes.
>>>>>>>
>>>>>>>   Cheers,
>>>>>>>   BogDan.
>>>>>>>
>>>>>>>
>>>>>>>
>> [1]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=8c4c862...
>>>>>>>
>> [2]http://quickgit.kde.org/index.php?p=android-qt.git&a=commit&h=abe85f4...
>>>   _______________________________________________
>>>   Necessitas-devel mailing list
>>>   Necessitas-devel at kde.org
>>>   https://mail.kde.org/mailman/listinfo/necessitas-devel
>> _______________________________________________
>> Necessitas-devel mailing list
>> Necessitas-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/necessitas-devel
>>
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel