From rjvbertin at gmail.com Mon Jul 3 14:29:18 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 03 Jul 2017 14:29:18 +0200 Subject: [Development] font dialog behaviour on Mac Message-ID: <3684137.SJWg1cfF14@bola> Hi, Somewhere along the line the Qt5 native Mac font selection dialog lost the Ok & Cancel buttons it had under Qt4. Real native font dialogs (tend to) have immediate effect and thus don't need a dedicated accepting (or cancelling) buttons. By contrast you need to hit enter to apply the selected new font (style, size, etc). I only realised this very recently (most Qt-based software I work with uses Qt's own font dialogs) and my first impression was that I had broken something in my install. I only discovered the "hit enter to proceed" trick by accident. Dialog buttons are unusual on Mac font selection dialogs but so is having to confirm changes. I wouldn't be surprised if Qt's architecture requires the latter but in that case the former would be more intuitive. Is the current behaviour 100% intentional? Thanks, René From philippeb8 at gmail.com Wed Jul 5 06:03:14 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 5 Jul 2017 00:03:14 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr Message-ID: Hi, I read Qt 5.9 is using a new garbage collector that is more predictable. First good job and second I was wondering if there is any documentation on that garbage collector in question. I guess if there is any interests to make the garbage collector perfectly deterministic then root_ptr could be relatively easily integrated at this stage. Regards, -Phil From thiago.macieira at intel.com Wed Jul 5 08:29:04 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 04 Jul 2017 23:29:04 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <3461972.FJP1i033ff@tjmaciei-mobl1> On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote: > Hi, > > I read Qt 5.9 is using a new garbage collector that is more predictable. > First good job and second I was wondering if there is any > documentation on that garbage collector in question. That might be in the QML engine VM. The rest of Qt does not use garbage collectors. > I guess if there is any interests to make the garbage collector > perfectly deterministic then root_ptr could be relatively easily > integrated at this stage. How does root_ptr work with JavaScript semantics? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Maurice.Kalinowski at qt.io Wed Jul 5 14:18:27 2017 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 5 Jul 2017 12:18:27 +0000 Subject: [Development] Examples and Demos in qtdoc In-Reply-To: <6EC67B94-1E41-4EE5-9C06-E47EDCBFC315@qt.io> References: <2011814.yAGkPeLK5y@frederik-thinkcentre-m93p> <1762291.Xer14TdUsM@cartman> <716D3B51-BEDE-4C7C-8CA3-368764908B91@qt.io> <6EC67B94-1E41-4EE5-9C06-E47EDCBFC315@qt.io> Message-ID: So, is this in place now? Just wondering because of some changes getting into the qtdoc repo recently… Maurice From: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of Lars Knoll Sent: Friday, June 16, 2017 11:31 AM To: Mitch Curtis Cc: Qt development mailing list Subject: Re: [Development] Examples and Demos in qtdoc On 15 Jun 2017, at 15:23, Mitch Curtis > wrote: -----Original Message----- From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt- project.org] On Behalf Of Joerg Bornemann Sent: Thursday, 15 June 2017 9:54 AM To: Pasi Keränen >; development at qt-project.org Subject: Re: [Development] Examples and Demos in qtdoc On 14/06/2017 14:59, Pasi Keränen wrote: I’m not 100% sure about qtdoc as the repo though. But I can live with it if that is what is seen as best option by others. There are two kinds of examples: 1. Simple examples demonstrating the use of a certain technique. Those usually come with detailed source code documentation. 2. Complex examples demonstrating much of the bling that's possible. Those are not source-documented, because writing the docs would be too laborious, and who would want to read them anyway. I believe that examples of category 1 should live in the qdoc repository / in their respective module repository. Examples of category 2 deserve a separate space. The "bigger examples" from Frederik's original mail are category 2. In Qt4 those were called "demos". There could be a "qtdemos" repo with git- lfs. In qtwebengine there's this question bobbing up every once in a while what to do with the demobrowser example. As an example, it actually needs source documentation. But it's too big. There are voices that want to remove it. Instead it could live on in such a qtdemos repo. +1 That sounds like a good idea. So documented examples in qtdoc, larger demos (that can also contain lots of image data) in a separate qtdemos repo. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.volkov at rusbitech.ru Wed Jul 5 14:24:54 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Wed, 5 Jul 2017 15:24:54 +0300 Subject: [Development] Loading translations for QML modules Message-ID: Hi, Currently translations for QML modules should be loaded manually. It would be much more convenient if Qt Quick could load them automatically. Are there any plans about it? BR, Alexander. From philippeb8 at gmail.com Thu Jul 6 00:31:28 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 5 Jul 2017 18:31:28 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <3461972.FJP1i033ff@tjmaciei-mobl1> References: <3461972.FJP1i033ff@tjmaciei-mobl1> Message-ID: On 07/05/2017 02:29 AM, Thiago Macieira wrote: > On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote: >> Hi, >> >> I read Qt 5.9 is using a new garbage collector that is more predictable. >> First good job and second I was wondering if there is any >> documentation on that garbage collector in question. > > That might be in the QML engine VM. The rest of Qt does not use garbage > collectors. > >> I guess if there is any interests to make the garbage collector >> perfectly deterministic then root_ptr could be relatively easily >> integrated at this stage. > > How does root_ptr work with JavaScript semantics? (So as you can see in the file attached I have revamped my Javascript skills. And so with the QML.) But first of all root_ptr is as you know a "set" of reference counted pointers, where the "set" vanished from existence when the destructor of the associated root_ptr is called. For example in HTML we could have 1 root_ptr for each HTML page and when this page is destroyed then the root_ptr guarantees all associated nodes will be destructed as well. When I refer to a node I mean the representation of an atomic variable or a function in Javascript which is pointed to by a reference counted pointer. So you can have all the mess you want in Javascript, when the page is destroyed then all memory associated to that page is freed. It's the same thing with QML and its windows. When a window is destroyed then all associated variables will vanish as well, cyclic or not. From my experience, the only way a window can return a value is either by sending a signal with its parameters passed by value or by storing them in some local database. But the parent shouldn't have any pointer connection of QML / Javascript type with its child window (downstream) otherwise it's bad programming. Ex.: Window 1 --------- | | Window 2 | | --- | root_ptr2->| | | | --- root_ptr1->| | | | Window 3 | | --- | root_ptr3->| | | | --- --------- Here when root_ptr2 gets deleted from the list of Window 1's childs then everything inside Window 2 will get destroyed. The same for root_ptr3 / Window 3. If root_ptr1 gets destroyed then the whole app is guaranteed to vanish. Regards, -Phil https://github.com/philippeb8/root_ptr -------------- next part -------------- A non-text attachment was scrubbed... Name: entersite.php Type: application/x-php Size: 8890 bytes Desc: not available URL: From ewleaver at comcast.net Thu Jul 6 01:49:56 2017 From: ewleaver at comcast.net (Ed Leaver) Date: Wed, 5 Jul 2017 19:49:56 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <3461972.FJP1i033ff@tjmaciei-mobl1> Message-ID: <3b2dba0b-e55d-6663-d425-fa5d5cf97631@comcast.net> On 07/05/2017 06:31 PM, Phil Bouchard wrote: > On 07/05/2017 02:29 AM, Thiago Macieira wrote: >> On Tuesday, 4 July 2017 21:03:14 PDT Phil Bouchard wrote: >>> Hi, >>> >>> I read Qt 5.9 is using a new garbage collector that is more >>> predictable. >>> First good job and second I was wondering if there is any >>> documentation on that garbage collector in question. >> >> That might be in the QML engine VM. The rest of Qt does not use garbage >> collectors. >> >>> I guess if there is any interests to make the garbage collector >>> perfectly deterministic then root_ptr could be relatively easily >>> integrated at this stage. >> >> How does root_ptr work with JavaScript semantics? > > (So as you can see in the file attached I have revamped my Javascript > skills. And so with the QML.) > > But first of all root_ptr is as you know a "set" of reference counted > pointers, where the "set" vanished from existence when the destructor > of the associated root_ptr is called. > > For example in HTML we could have 1 root_ptr for each HTML page and > when this page is destroyed then the root_ptr guarantees all > associated nodes will be destructed as well. When I refer to a node I > mean the representation of an atomic variable or a function in > Javascript which is pointed to by a reference counted pointer. So you > can have all the mess you want in Javascript, when the page is > destroyed then all memory associated to that page is freed. > > It's the same thing with QML and its windows. When a window is > destroyed then all associated variables will vanish as well, cyclic or > not. From my experience, the only way a window can return a value is > either by sending a signal with its parameters passed by value or by > storing them in some local database. But the parent shouldn't have > any pointer connection of QML / Javascript type with its child window > (downstream) otherwise it's bad programming. Ex.: > > Window 1 > --------- > | | Window 2 > | | --- > | root_ptr2->| | > | | --- > root_ptr1->| | > | | Window 3 > | | --- > | root_ptr3->| | > | | --- > --------- > > Here when root_ptr2 gets deleted from the list of Window 1's childs > then everything inside Window 2 will get destroyed. The same for > root_ptr3 / Window 3. If root_ptr1 gets destroyed then the whole app > is guaranteed to vanish. > > > Regards, > -Phil > https://github.com/philippeb8/root_ptr > It may be just a matter of semantics. What you describe is pretty much how C++ QtWidgets work. One doesn't ordinarily think of convenient but informed use of smart pointers to be garbage collection. One doesn't ordinarily think of QtWidgets themselves as being particularly "smart" pointers, either. (But they've been enough to fool me!) C++ QObjects do support "real" smart pointers in guise of QScopedPointer, QSharedPointer, and QWeakPointer, plus a few others. So Qt certainly knows how to do what you describe without Java-style garbage collection. That's the C++ side, which I understand to underlie much of QML. I hope Thiago can correct my own mis-perceptions, and elaborate more. Regards, Ed Leaver > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jul 6 02:25:33 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 05 Jul 2017 17:25:33 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <3461972.FJP1i033ff@tjmaciei-mobl1> Message-ID: <3580671.XrQ1rVerLK@tjmaciei-mobl1> On quarta-feira, 5 de julho de 2017 15:31:28 PDT Phil Bouchard wrote: > For example in HTML we could have 1 root_ptr for each HTML page and when > this page is destroyed then the root_ptr guarantees all associated nodes > will be destructed as well. When I refer to a node I mean the > representation of an atomic variable or a function in Javascript which > is pointed to by a reference counted pointer. So you can have all the > mess you want in Javascript, when the page is destroyed then all memory > associated to that page is freed. > > It's the same thing with QML and its windows. When a window is > destroyed then all associated variables will vanish as well, cyclic or > not. From my experience, the only way a window can return a value is > either by sending a signal with its parameters passed by value or by > storing them in some local database. But the parent shouldn't have any > pointer connection of QML / Javascript type with its child window > (downstream) otherwise it's bad programming. Ex.: What's the advantage compared to the current model where the GC runs periodically and frees unused objects before the window is closed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Thu Jul 6 04:32:35 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 5 Jul 2017 22:32:35 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <3580671.XrQ1rVerLK@tjmaciei-mobl1> References: <3461972.FJP1i033ff@tjmaciei-mobl1> <3580671.XrQ1rVerLK@tjmaciei-mobl1> Message-ID: On 07/05/2017 08:25 PM, Thiago Macieira wrote: > On quarta-feira, 5 de julho de 2017 15:31:28 PDT Phil Bouchard wrote: >> For example in HTML we could have 1 root_ptr for each HTML page and when >> this page is destroyed then the root_ptr guarantees all associated nodes >> will be destructed as well. When I refer to a node I mean the >> representation of an atomic variable or a function in Javascript which >> is pointed to by a reference counted pointer. So you can have all the >> mess you want in Javascript, when the page is destroyed then all memory >> associated to that page is freed. >> >> It's the same thing with QML and its windows. When a window is >> destroyed then all associated variables will vanish as well, cyclic or >> not. From my experience, the only way a window can return a value is >> either by sending a signal with its parameters passed by value or by >> storing them in some local database. But the parent shouldn't have any >> pointer connection of QML / Javascript type with its child window >> (downstream) otherwise it's bad programming. Ex.: > > What's the advantage compared to the current model where the GC runs > periodically and frees unused objects before the window is closed? - Well with root_ptr the behavior is 100% predictable thus you won't have these rendering lags at random times. It happened to me before when I had relatively complex listitems using shadows and a nested list of pictures for each item; the scrolling speed wasn't constant and I think that's a good way to measure this problem. With root_ptr the complexity will remain linear O(n). - The code of Qt will be much simpler. - You won't need a separate thread reserved for the garbage collector if that is already the case. - The objects are destroyed is the exact reverse order they were constructed thus this will help debugging. -Phil From thiago.macieira at intel.com Thu Jul 6 07:01:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 05 Jul 2017 22:01:08 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <3580671.XrQ1rVerLK@tjmaciei-mobl1> Message-ID: <4373575.LjxagK0boG@tjmaciei-mobl1> On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote: > - Well with root_ptr the behavior is 100% predictable thus you won't > have these rendering lags at random times. So explain to me how the QML engine should collect JS items that have gone unused and unreferenced during the exection. Predictable execution isn't good enough if it involves never garbage collecting and thus using a lot more memory. > - The code of Qt will be much simpler. We can make it even simpler by never free()ing or deleting. That doesn't mean it's correct. > - You won't need a separate thread reserved for the garbage collector if > that is already the case. It's not. > - The objects are destroyed is the exact reverse order they were > constructed thus this will help debugging. But unnecessary, since the order they are constructed is irrelevant. The JS order matters. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre.hartmann at iseg-hv.de Thu Jul 6 08:36:27 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 6 Jul 2017 08:36:27 +0200 Subject: [Development] Nominating Denis Shienkov for Approver status Message-ID: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> I'd like to propose the nomination of Denis Shienkov for Approver status. Denis has been the maintainer of QtSerialPort for a long time now. He also formed the architecture of QtSerialBus and provided several CAN plugins there. He further contributes to other parts of Qt and QtCreator and is actively reviewing other changes (for example he has constructively improved a lot of my changes to QtSerialBus). This is his own Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z And these are his reviews: https://codereview.qt-project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z Best regards, André From alexander.blasche at qt.io Thu Jul 6 09:34:15 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 6 Jul 2017 07:34:15 +0000 Subject: [Development] Nominating Denis Shienkov for Approver status In-Reply-To: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> Message-ID: +1 from me. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of André > Hartmann > Sent: Thursday, 6 July 2017 08:36 > To: development at qt-project.org; qt-creator at qt-project.org > Subject: [Development] Nominating Denis Shienkov for Approver status > > I'd like to propose the nomination of Denis Shienkov for Approver status. > > Denis has been the maintainer of QtSerialPort for a long time now. > He also formed the architecture of QtSerialBus and provided several CAN plugins > there. He further contributes to other parts of Qt and QtCreator and is actively > reviewing other changes (for example he has constructively improved a lot of > my changes to QtSerialBus). > > This is his own Gerrit dashboard: > > https://codereview.qt- > project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.c > om%253E%22,n,z > > And these are his reviews: > > https://codereview.qt- > project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmai > l.com%253E%22,n,z > > Best regards, > André > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rafael.roquetto at kdab.com Thu Jul 6 13:44:26 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Thu, 6 Jul 2017 08:44:26 -0300 Subject: [Development] Nominating Denis Shienkov for Approver status In-Reply-To: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> Message-ID: <20170706114425.GA5167@orion> +1 On Thu, Jul 06, 2017 at 08:36:27AM +0200, André Hartmann wrote: > I'd like to propose the nomination of Denis Shienkov for Approver > status. > > Denis has been the maintainer of QtSerialPort for a long time now. > He also formed the architecture of QtSerialBus and provided several CAN > plugins there. He further contributes to other parts of Qt and QtCreator > and is actively reviewing other changes (for example he has > constructively improved a lot of my changes to QtSerialBus). > > This is his own Gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z > > And these are his reviews: > > https://codereview.qt-project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z > > Best regards, > André > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From orgads at gmail.com Thu Jul 6 13:45:46 2017 From: orgads at gmail.com (Orgad Shaneh) Date: Thu, 6 Jul 2017 14:45:46 +0300 Subject: [Development] [Qt-creator] Nominating Denis Shienkov for Approver status In-Reply-To: <20170706114425.GA5167@orion> References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> <20170706114425.GA5167@orion> Message-ID: On Thu, Jul 6, 2017 at 2:44 PM, Rafael Roquetto wrote: > +1 > > On Thu, Jul 06, 2017 at 08:36:27AM +0200, André Hartmann wrote: >> I'd like to propose the nomination of Denis Shienkov for Approver >> status. >> >> Denis has been the maintainer of QtSerialPort for a long time now. >> He also formed the architecture of QtSerialBus and provided several CAN >> plugins there. He further contributes to other parts of Qt and QtCreator >> and is actively reviewing other changes (for example he has >> constructively improved a lot of my changes to QtSerialBus). >> >> This is his own Gerrit dashboard: >> >> https://codereview.qt-project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z >> >> And these are his reviews: >> >> https://codereview.qt-project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z >> >> Best regards, >> André +1 - Orgad From philippeb8 at gmail.com Thu Jul 6 13:53:16 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 6 Jul 2017 07:53:16 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <4373575.LjxagK0boG@tjmaciei-mobl1> References: <3580671.XrQ1rVerLK@tjmaciei-mobl1> <4373575.LjxagK0boG@tjmaciei-mobl1> Message-ID: On 07/06/2017 01:01 AM, Thiago Macieira wrote: > On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote: >> - Well with root_ptr the behavior is 100% predictable thus you won't >> have these rendering lags at random times. > > So explain to me how the QML engine should collect JS items that have gone > unused and unreferenced during the exection. Predictable execution isn't good > enough if it involves never garbage collecting and thus using a lot more > memory. It's all memory usage and bad programming habits vs execution speed. Why would you want to add objects that are never used? A minimum programming skills set is required here. You're saying the actual garbage collector should compensate for programming errors when I'm saying that's the programmer's responsibility. We want the fastest executable in the end given an extensible level of complexity of the executable. If the garbage collector stops you from doing that then there's is no light at the end of the tunnel. Or perhaps it should be a choice on whether the user wants to use the garbage collector or root_ptr and he can decide by himself what is more convenient for him according to his context. >> - The objects are destroyed is the exact reverse order they were >> constructed thus this will help debugging. > > But unnecessary, since the order they are constructed is irrelevant. The JS > order matters. It's a plus. -Phil From rjvbertin at gmail.com Thu Jul 6 13:53:35 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 06 Jul 2017 13:53:35 +0200 Subject: [Development] QTabBarPrivate::hoveredTabIndex() visibility Message-ID: <1605748.ZF04cpKCqA@portia.local> Hi, Is QTabBarPrivate::hoveredTabIndex() supposed to be visible for software having "QT += widgets-private" in their .pro file? I'm seeing this when I try to link my standalone version of the QMacStyle style against Qt 5.9.0 and 5.9.1 : /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -stdlib=libc++ -headerpad_max_install_names -arch x86_64 -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.10 -Wl,-rpath, at executable_path/Frameworks -Wl,-rpath,/Volumes/VMs/Qt/5/5.9.1/clang_64/lib -single_module -dynamiclib -o libqaltmacstyle.dylib qcombobox.o qcommonstyle.o qstyleanimation.o qstylehelper.o qoperatingsystemversion.o qoperatingsystemversion_darwin.o main.o qmacstyle_mac.o moc_qmacstyle_mac_p.o -F/Volumes/VMs/Qt/5/5.9.1/clang_64/lib -framework QtWidgets -framework QtGui -framework QtCore -framework DiskArbitration -framework IOKit -framework OpenGL -framework AGL -framework AppKit -framework Carbon Undefined symbols for architecture x86_64: "QTabBarPrivate::hoveredTabIndex() const", referenced from: QMacStyle::drawPrimitive(QStyle::PrimitiveElement, QStyleOption const*, QPainter*, QWidget const*) const in qmacstyle_mac.o ld: symbol(s) not found for architecture x86_64 Thanks, René From olivier at woboq.com Thu Jul 6 15:35:59 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 06 Jul 2017 15:35:59 +0200 Subject: [Development] QTabBarPrivate::hoveredTabIndex() visibility In-Reply-To: <1605748.ZF04cpKCqA@portia.local> References: <1605748.ZF04cpKCqA@portia.local> Message-ID: <53551100.HXivjFhBXp@maurice> Am Donnerstag, 6. Juli 2017, 13:53:35 CEST schrieb René J.V. Bertin: > Hi, > > Is QTabBarPrivate::hoveredTabIndex() supposed to be visible for software > having "QT += widgets-private" in their .pro file? Only from Qt 5.10 (since commit 4f3249f32dbe5c20aabbfd9b4f9c558aaf449e48 in the dev branch) > I'm seeing this when I try to link my standalone version of the QMacStyle > style against Qt 5.9.0 and 5.9.1 : The class was not exported in 5.9.x -- Olivier From szehowe.koh at gmail.com Thu Jul 6 15:40:30 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Thu, 6 Jul 2017 21:40:30 +0800 Subject: [Development] Nominating Denis Shienkov for Approver status In-Reply-To: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> References: <239acd2f-188f-b018-1b68-245e04c1e9b6@iseg-hv.de> Message-ID: On 6 July 2017 at 14:36, André Hartmann wrote: > > I'd like to propose the nomination of Denis Shienkov for Approver > status. > > Denis has been the maintainer of QtSerialPort for a long time now. > He also formed the architecture of QtSerialBus and provided several CAN plugins there. He further contributes to other parts of Qt and QtCreator and is actively reviewing other changes (for example he has constructively improved a lot of my changes to QtSerialBus). > > This is his own Gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z > > And these are his reviews: > > https://codereview.qt-project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z > > Best regards, > André +1 Regards, Sze-Howe From thiago.macieira at intel.com Thu Jul 6 17:10:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 06 Jul 2017 08:10:42 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <4373575.LjxagK0boG@tjmaciei-mobl1> Message-ID: <2891316.49BQzlKupU@tjmaciei-mobl1> On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote: > On 07/06/2017 01:01 AM, Thiago Macieira wrote: > > On quarta-feira, 5 de julho de 2017 19:32:35 PDT Phil Bouchard wrote: > >> - Well with root_ptr the behavior is 100% predictable thus you won't > >> have these rendering lags at random times. > > > > So explain to me how the QML engine should collect JS items that have gone > > unused and unreferenced during the exection. Predictable execution isn't > > good enough if it involves never garbage collecting and thus using a lot > > more memory. > > It's all memory usage and bad programming habits vs execution speed. > Why would you want to add objects that are never used? A minimum > programming skills set is required here. You're saying the actual > garbage collector should compensate for programming errors when I'm > saying that's the programmer's responsibility. I'm saying that the garbage collector has to compensate for language requirements. Do you even know JavaScript? Temporary variables are created all the time in the process of any algorithm; global state variables could be cleared depending on usage; etc. The point is that the *language* requires us to have a garbage collector to operate like that. So explain to me how root_ptr will work in that context. > We want the fastest executable in the end given an extensible level of > complexity of the executable. If the garbage collector stops you from > doing that then there's is no light at the end of the tunnel. Agreed. People should stop using *languages* that require this type of garbage collector. But until that happens, we'll be forced to have GCs. > Or perhaps it should be a choice on whether the user wants to use the > garbage collector or root_ptr and he can decide by himself what is more > convenient for him according to his context. Sure. A choice of different engines, completely different APIs. If the user wants root_ptr, they can write their application using something other than QtQml. Nothing is stopping them from it. > > >> - The objects are destroyed is the exact reverse order they were > >> constructed thus this will help debugging. > > > > But unnecessary, since the order they are constructed is irrelevant. The > > JS > > order matters. > > It's a plus. No, it isn't. The JS order is the important order. If you do it outsiide of the order that the language requires, then it's just plain wrong. Please explain to me how root_ptr works for a garbage-collected language interpreter. Particularly if you have any studies on a JS interpreter. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu Jul 6 17:19:02 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 06 Jul 2017 17:19:02 +0200 Subject: [Development] QTabBarPrivate::hoveredTabIndex() visibility In-Reply-To: <53551100.HXivjFhBXp@maurice> References: <1605748.ZF04cpKCqA@portia.local> <53551100.HXivjFhBXp@maurice> Message-ID: <3870268.4zEpAGI4cS@portia.local> On Thursday July 06 2017 15:35:59 Olivier Goffart wrote: > > I'm seeing this when I try to link my standalone version of the QMacStyle > > style against Qt 5.9.0 and 5.9.1 : > > The class was not exported in 5.9.x Thanks for confirming. I guess that also explains why providing just my local private copy of the hoveredTabIndex() method doesn't work (= always returns -1). Well, 5.10.0+ it is then :) R. From philippeb8 at gmail.com Fri Jul 7 04:15:02 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 6 Jul 2017 22:15:02 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <2891316.49BQzlKupU@tjmaciei-mobl1> References: <4373575.LjxagK0boG@tjmaciei-mobl1> <2891316.49BQzlKupU@tjmaciei-mobl1> Message-ID: On 07/06/2017 11:10 AM, Thiago Macieira wrote: > On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote: >> >> It's all memory usage and bad programming habits vs execution speed. >> Why would you want to add objects that are never used? A minimum >> programming skills set is required here. You're saying the actual >> garbage collector should compensate for programming errors when I'm >> saying that's the programmer's responsibility. > > I'm saying that the garbage collector has to compensate for language > requirements. Do you even know JavaScript? Temporary variables are created all > the time in the process of any algorithm; global state variables could be > cleared depending on usage; etc. > > The point is that the *language* requires us to have a garbage collector to > operate like that. So explain to me how root_ptr will work in that context. As you know in Javascript temporary unnamed variables from a primitive type are no different than local variables and even if global variables are not encouraged then they will be destroyed when the HTML page or QML window is killed. All root_ptr requires is to draw the line and isolate "entities" which have a birth and a certain death. That is the case with HTML pages and QML windows and we can take advantage of that. Anything that goes in that HTML page or QML window we don't care. The reference counted property of root_ptr (node_ptr) will handle it and the associated root_ptr will clean up the mess when it is destroyed. >> Or perhaps it should be a choice on whether the user wants to use the >> garbage collector or root_ptr and he can decide by himself what is more >> convenient for him according to his context. > > Sure. A choice of different engines, completely different APIs. If the user > wants root_ptr, they can write their application using something other than > QtQml. Nothing is stopping them from it. Well I'm here to help Qt because I know quite well that WebKit for Wayland is the number 1 rendering engine and Javascript processor. The problem with WebKit is that their garbage collector is inlaid with the code of WebKit, making it impossible to throw away the garbage collector. And WebKit is an engineering product which means they are not interested into innovative theoretical libraries that just came out of the oven. On the other hand it seems quite possible to upgrade or change the garbage collector in the Qt library and if we analyze the integration of root_ptr carefully then it should be done quickly. >>>> - The objects are destroyed is the exact reverse order they were >>>> constructed thus this will help debugging. >>> >>> But unnecessary, since the order they are constructed is irrelevant. The >>> JS >>> order matters. >> >> It's a plus. > > No, it isn't. The JS order is the important order. If you do it outsiide of > the order that the language requires, then it's just plain wrong. What do you mean exactly by the JS order? If you have a function: function() { var objA = { prop: "foo", next: null }; var objB = { prop: "foo", prev: null }; objA.next = objB; objB.prev = objA; // cycle } Then the order of destruction of var objA and objB is undefined in Javascript whereas root_ptr guarantees that objB will get destroyed before objA. But there is rule regarding the order of destruction in Javascript already so we can't break anything. > Please explain to me how root_ptr works for a garbage-collected language > interpreter. Particularly if you have any studies on a JS interpreter. Javacript is not very complicated to understand for people who wrote interpreters. I happen to write a parser for mathematical equations in my scientific calculator using my good old friendly mutable_ptr: http://www.fornux.com And it's the same for Javascript except that they have more advanced standards. Regarding root_ptr and Javascript then all we have to do is to define exactly where isolated entities are given birth and die. In other words we just need to know where root_ptr will be put. Do you agree that an HTML page and a QML window represent exactly this? In the latter the only way a QML window can communicate with the outside world is by sending a signal (if you write directly in a parent window then that is bad programming and it shouldn't be allowed). All that is required here is to analyze the situation carefully and we'll have a faster Javascript engine instead of just trying to patch the existing GC. And the GC should be an abstraction we can replace and it shouldn't be part of the definition of Javascript. Thanks, -Phil From thiago.macieira at intel.com Fri Jul 7 04:57:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 06 Jul 2017 19:57:01 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2891316.49BQzlKupU@tjmaciei-mobl1> Message-ID: <8927420.fapz5S2oZy@tjmaciei-mobl1> On quinta-feira, 6 de julho de 2017 19:15:02 PDT Phil Bouchard wrote: > > The point is that the *language* requires us to have a garbage collector > > to > > operate like that. So explain to me how root_ptr will work in that > > context. > > As you know in Javascript temporary unnamed variables from a primitive > type are no different than local variables and even if global variables > are not encouraged then they will be destroyed when the HTML page or QML > window is killed. That is too late. QML pages are meant to be open for a long time, like the application's main screen. There are even web pages that operate like that today -- I certainly have a few always-interacting and always-on webpages open on my Chrome. If the garbage collector did not run, I'm sure the memory use would be higher. > All root_ptr requires is to draw the line and isolate "entities" which > have a birth and a certain death. That is the case with HTML pages and > QML windows and we can take advantage of that. Sorry, not workable. > Anything that goes in that HTML page or QML window we don't care. The > reference counted property of root_ptr (node_ptr) will handle it and the > associated root_ptr will clean up the mess when it is destroyed. How well does root_ptr operate when there are cyclic references? JavaScript objects can refer to each other, so how do you propose the engine handle that case? > > Sure. A choice of different engines, completely different APIs. If the > > user > > wants root_ptr, they can write their application using something other > > than > > QtQml. Nothing is stopping them from it. > > Well I'm here to help Qt because I know quite well that WebKit for > Wayland is the number 1 rendering engine and Javascript processor. Your motivation is at odds with your objective. We don't maintain WebKit. There's barely any participation from us at all. And the QML engine is neither WebKit's (JSC) nor Blink's (V8). It's our own. > The > problem with WebKit is that their garbage collector is inlaid with the > code of WebKit, making it impossible to throw away the garbage > collector. And WebKit is an engineering product which means they are > not interested into innovative theoretical libraries that just came out > of the oven. Nor are we. Show us that it working and we'll take a chance. A theoretical solution with no real-life implementation is not for us. Have you impemented any engine for garbage collected languages using root_ptr? How well does root_ptr work with the Python engine? Or a Java VM? Lua? Ruby? Any scripting language VMs implemented using it? > On the other hand it seems quite possible to upgrade or change the > garbage collector in the Qt library and if we analyze the integration of > root_ptr carefully then it should be done quickly. Again, QtQml engine is really tied to JavaScript. I don't think you can get out of having a garbage collector at all. > > No, it isn't. The JS order is the important order. If you do it outsiide > > of > > the order that the language requires, then it's just plain wrong. > > What do you mean exactly by the JS order? If you have a function: > > function() > { > var objA = > { > prop: "foo", > next: null > }; > > var objB = > { > prop: "foo", > prev: null > }; > > objA.next = objB; > objB.prev = objA; // cycle > } > > Then the order of destruction of var objA and objB is undefined in > Javascript whereas root_ptr guarantees that objB will get destroyed > before objA. But there is rule regarding the order of destruction in > Javascript already so we can't break anything. If the order of destruction according to the language is undefined, then the order in which root_ptr destroys it is not relevant and it can't be considered a plus. In fact, having it deterministic could be a negative asset, since someone writing this code will never be exposed to undefinedness of their code. By the way, how does it break the cycle? > Regarding root_ptr and Javascript then all we have to do is to define > exactly where isolated entities are given birth and die. In other words > we just need to know where root_ptr will be put. Do you agree that an > HTML page and a QML window represent exactly this? I do not. See above. > In the latter the > only way a QML window can communicate with the outside world is by > sending a signal (if you write directly in a parent window then that is > bad programming and it shouldn't be allowed). > > All that is required here is to analyze the situation carefully and > we'll have a faster Javascript engine instead of just trying to patch > the existing GC. And the GC should be an abstraction we can replace and > it shouldn't be part of the definition of Javascript. No, all that is required is that someone actually write the code. Are you volunteering or do you have anyone who understands root_ptr that is? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Fri Jul 7 05:48:27 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 6 Jul 2017 23:48:27 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <8927420.fapz5S2oZy@tjmaciei-mobl1> References: <2891316.49BQzlKupU@tjmaciei-mobl1> <8927420.fapz5S2oZy@tjmaciei-mobl1> Message-ID: On 07/06/2017 10:57 PM, Thiago Macieira wrote: > On quinta-feira, 6 de julho de 2017 19:15:02 PDT Phil Bouchard wrote: >> >> As you know in Javascript temporary unnamed variables from a primitive >> type are no different than local variables and even if global variables >> are not encouraged then they will be destroyed when the HTML page or QML >> window is killed. > > That is too late. QML pages are meant to be open for a long time, like the > application's main screen. There are even web pages that operate like that > today -- I certainly have a few always-interacting and always-on webpages open > on my Chrome. If the garbage collector did not run, I'm sure the memory use > would be higher. Well then you scale down the usage of root_ptr to containers like a listview which is constantly refreshed for most applications. It's the same with a Gmail webpage which has a listview that is constantly refreshed because you keep pressing on the Inbox button to refresh it. >> Anything that goes in that HTML page or QML window we don't care. The >> reference counted property of root_ptr (node_ptr) will handle it and the >> associated root_ptr will clean up the mess when it is destroyed. > > How well does root_ptr operate when there are cyclic references? JavaScript > objects can refer to each other, so how do you propose the engine handle that > case? It's very easy. Every time a node_ptr is created, it enlists the pointee object to its associated root_ptr. When the root_ptr is destroyed then all associated objects in that list are destroyed as well. This is how cyclic references are guaranteed to be destroyed deterministically. >> Well I'm here to help Qt because I know quite well that WebKit for >> Wayland is the number 1 rendering engine and Javascript processor. > > Your motivation is at odds with your objective. We don't maintain WebKit. > There's barely any participation from us at all. > > And the QML engine is neither WebKit's (JSC) nor Blink's (V8). It's our own. Sorry I meant that I'm here to help Qt to have a better product than the competition. >> The >> problem with WebKit is that their garbage collector is inlaid with the >> code of WebKit, making it impossible to throw away the garbage >> collector. And WebKit is an engineering product which means they are >> not interested into innovative theoretical libraries that just came out >> of the oven. > > Nor are we. Show us that it working and we'll take a chance. A theoretical > solution with no real-life implementation is not for us. > > Have you impemented any engine for garbage collected languages using root_ptr? > How well does root_ptr work with the Python engine? Or a Java VM? Lua? Ruby? > Any scripting language VMs implemented using it? No but it works well with neural networks which I think is a good example of a worse case situation: https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp >> On the other hand it seems quite possible to upgrade or change the >> garbage collector in the Qt library and if we analyze the integration of >> root_ptr carefully then it should be done quickly. > > Again, QtQml engine is really tied to JavaScript. I don't think you can get > out of having a garbage collector at all. I guess we could ask Qt's garbage collector experts. > If the order of destruction according to the language is undefined, then the > order in which root_ptr destroys it is not relevant and it can't be considered > a plus. In fact, having it deterministic could be a negative asset, since > someone writing this code will never be exposed to undefinedness of their code. I certainly think it's a plus for debugging purposes. And I fail to understand the advantage of the undefinedness of the code. > By the way, how does it break the cycle? Like I was saying before, node_ptr enlists each pointee object to the associated root_ptr and when the root_ptr is destroyed then everything gets wiped out. >> All that is required here is to analyze the situation carefully and >> we'll have a faster Javascript engine instead of just trying to patch >> the existing GC. And the GC should be an abstraction we can replace and >> it shouldn't be part of the definition of Javascript. > > No, all that is required is that someone actually write the code. Are you > volunteering or do you have anyone who understands root_ptr that is? Nobody really understands root_ptr despite all the documentation I wrote. I think the only one most familiar with it is Peter Dimov; the author of shared_ptr. Fortunately I am almost done with the following projects: http://www.finitetheory.com https://www.actatabula.com So I am volunteering but I can't compile the whole Qt library on my laptop so I'll need stripped out packages and some Q&A so that I can first understand what is so special with the GC. Thanks, -Phil From thiago.macieira at intel.com Fri Jul 7 08:07:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 06 Jul 2017 23:07:02 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <8927420.fapz5S2oZy@tjmaciei-mobl1> Message-ID: <1860445.O5TG8iGG5J@tjmaciei-mobl1> On quinta-feira, 6 de julho de 2017 20:48:27 PDT Phil Bouchard wrote: > > How well does root_ptr operate when there are cyclic references? > > JavaScript > > objects can refer to each other, so how do you propose the engine handle > > that case? > > It's very easy. Every time a node_ptr is created, it enlists the > pointee object to its associated root_ptr. When the root_ptr is > destroyed then all associated objects in that list are destroyed as > well. This is how cyclic references are guaranteed to be destroyed > deterministically. In other words, "it doesn"t". In the JS world, if those two objects refer to each other and nothing else refers to them, then they both can be garbage-collected. > > Nor are we. Show us that it working and we'll take a chance. A theoretical > > solution with no real-life implementation is not for us. > > > > Have you impemented any engine for garbage collected languages using > > root_ptr? How well does root_ptr work with the Python engine? Or a Java > > VM? Lua? Ruby? Any scripting language VMs implemented using it? > > No but it works well with neural networks which I think is a good > example of a worse case situation: > https://github.com/philippeb8/root_ptr/blob/master/example/t100_test1.cpp No, I don't think it's a good analogy. I'dl ike to see it in the engine of a scripted language. > > If the order of destruction according to the language is undefined, then > > the order in which root_ptr destroys it is not relevant and it can't be > > considered a plus. In fact, having it deterministic could be a negative > > asset, since someone writing this code will never be exposed to > > undefinedness of their code. > I certainly think it's a plus for debugging purposes. And I fail to > understand the advantage of the undefinedness of the code. The other engines are the problem. Granted, that won't happen for QML, since there's only one engine. But for JS, developers have to cope with the differences in behaviour. > > By the way, how does it break the cycle? > > Like I was saying before, node_ptr enlists each pointee object to the > associated root_ptr and when the root_ptr is destroyed then everything > gets wiped out. See above. Your answer is "it doesn't break the cycle". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Fri Jul 7 10:39:32 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 7 Jul 2017 08:39:32 +0000 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <4373575.LjxagK0boG@tjmaciei-mobl1> <2891316.49BQzlKupU@tjmaciei-mobl1>, Message-ID: On quinta-feira, 6 de julho de 2017 04:53:16 PDT Phil Bouchard wrote: >>> It's all memory usage and bad programming habits vs execution speed. >>> Why would you want to add objects that are never used? A minimum >>> programming skills set is required here. You're saying the actual >>> garbage collector should compensate for programming errors when I'm >>> saying that's the programmer's responsibility. That's not what garbage collection is about. It's about objects that are used transiently (e.g. in evaluating expressions) by some long-lived entity (whose root_ptr thus won't go away any time soon). After they've been used, the garbage collector notices they're no longer in use and tidies them away, well within the life-time of the entity that used them. Memory is thus released significantly earlier than it would be if you rely on a root_ptr associated with that long-lived entity. On 07/06/2017 11:10 AM, Thiago Macieira wrote: >> I'm saying that the garbage collector has to compensate for language >> requirements. Do you even know JavaScript? Temporary variables are >> created all the time in the process of any algorithm; global state >> variables could be cleared depending on usage; etc. >> >> The point is that the *language* requires us to have a garbage >> collector to operate like that. So explain to me how root_ptr will >> work in that context. Phil Bouchard (7 July 2017 04:15) > As you know in Javascript temporary unnamed variables from a primitive > type are no different than local variables and even if global > variables are not encouraged then they will be destroyed when the HTML > page or QML window is killed. This is far too late; the garbage collector gets much sooner after they drop out of use, particularly when the HTML page or QML window *is* the application, that's going to run for days. > All root_ptr requires is to draw the line and isolate "entities" which > have a birth and a certain death. That is the case with HTML pages > and QML windows and we can take advantage of that. > > Anything that goes in that HTML page or QML window we don't care. The > reference counted property of root_ptr (node_ptr) will handle it and > the associated root_ptr will clean up the mess when it is destroyed. You'd need to apply root_ptr on a finer granularity than the top-level HTML page or QML window. For example, when a function gets called in an interpreted language, there's something like a "stack frame" created, within the context of which the function executes, finally returning some value to the caller. To complicate life, that frame may survive the return as a closure (e.g. if the return values is a function object that references locals of the frame). In C++, exiting a scope (which corresponds to such a frame) calls destructors on all the objects declared in the scope; but that doesn't happen in JavaScript, which relies on the garbage-collector to catch those objects after they've passed out of scope. If you can convincingly exhibit an interpreted language using root_ptr for each of those frames, without causing breakage (you'll need to make sure the returned value can't end up holding any references to values owned by that frame; and you'll need to interact correctly with closures), you'll have a more convincing case for your innovation. As long as you pitch your idea in terms of the top-level HTML page or QML window, you aren't convincing - because we *know* that'll leave huge amounts of transiently-used memory that doesn't get released until the page or window is closed, which is *far* too late. Show that you can make it work at the level where it would actually reclaim memory sooner than a garbage collector would. Then folk might listen. Eddy. From porten at froglogic.com Fri Jul 7 11:01:03 2017 From: porten at froglogic.com (Harri Porten) Date: Fri, 7 Jul 2017 11:01:03 +0200 (CEST) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <1860445.O5TG8iGG5J@tjmaciei-mobl1> References: <8927420.fapz5S2oZy@tjmaciei-mobl1> <1860445.O5TG8iGG5J@tjmaciei-mobl1> Message-ID: On Thu, 6 Jul 2017, Thiago Macieira wrote: >>> By the way, how does it break the cycle? >> >> Like I was saying before, node_ptr enlists each pointee object to the >> associated root_ptr and when the root_ptr is destroyed then everything >> gets wiped out. > > See above. Your answer is "it doesn't break the cycle". Right. And from first hand experience I can report: I've tried hard to make a deterministic and quick deletion work in a JS engine (through reference counting, etc.) but always ended up with leaks. The scope of JS objects is sometimes also not limited to a single container like a HTML page. Often data can be passed/accessed to/from other containers. Thus breaking the concept of a isolated roots. Harri. From marc.mutz at kdab.com Fri Jul 7 12:20:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 07 Jul 2017 12:20:19 +0200 Subject: [Development] Stepping down as widgets maintainers Message-ID: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> Hi all, KDAB is handing back widgets maintenance, which means that I'm stepping down as widgets maintainer. The focus of KDAB contributions to Qt is clearly elsewhere these days (Qt3D, Core, tooling), and the module deserves more focus than it has seen lately. To this end, Lars has assembled a team(!) of proposed widgets (sub)maintainers that we as KDAB and I personally fully support as successors. In Lars' absence, I'll leave it to Frederik to introduce them to you in detail (as if introduction was needed...). Thanks, Marc From frederik.gladhorn at qt.io Fri Jul 7 13:03:49 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Fri, 07 Jul 2017 13:03:49 +0200 Subject: [Development] Widgets maintainers In-Reply-To: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> References: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> Message-ID: <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> Hello all, hello Marc, First of all, thank you very much for taking care of the widgets module and working to get bugs under control. We've been talking inside The Qt Company about the widgets module a lot lately, since we do see it as a very important part of Qt, which doesn't receive as much marketing and highlighting as it deserves. For traditional UIs, widgets are certainly a viable and good building block. While we don't anticipate huge changes in the module, we will keep on updating the styles where it makes sense and take bugs serious. Since it's also a big chunk of a module, we'd like to propse a team of maintainers, to make it easier on everyone. Our proposal is: Richard Gustavsen as overall maintainer Gabriel de Dietrich for styles Jan-Arve Sæther for layouts Eskil Abrahamsen-Blomfeldt for all text related things Andreas Aardal Hanssen for graphicsview Item Views is open and would fall to Richard for now, but if someone is interested in helping out more with it, that's certainly appreciated. Cheers, Frederik On fredag 7. juli 2017 12.20.19 CEST Marc Mutz wrote: > Hi all, > > KDAB is handing back widgets maintenance, which means that I'm stepping > down as widgets maintainer. The focus of KDAB contributions to Qt is > clearly elsewhere these days (Qt3D, Core, tooling), and the module > deserves more focus than it has seen lately. > > To this end, Lars has assembled a team(!) of proposed widgets > (sub)maintainers that we as KDAB and I personally fully support as > successors. > > In Lars' absence, I'll leave it to Frederik to introduce them to you in > detail (as if introduction was needed...). > > Thanks, > Marc > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From philippeb8 at gmail.com Fri Jul 7 13:32:38 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 7 Jul 2017 07:32:38 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <4373575.LjxagK0boG@tjmaciei-mobl1> <2891316.49BQzlKupU@tjmaciei-mobl1> Message-ID: On 07/07/2017 04:39 AM, Edward Welbourne wrote: > Phil Bouchard (7 July 2017 04:15) >> >> Anything that goes in that HTML page or QML window we don't care. The >> reference counted property of root_ptr (node_ptr) will handle it and >> the associated root_ptr will clean up the mess when it is destroyed. > > You'd need to apply root_ptr on a finer granularity than the top-level > HTML page or QML window. For example, when a function gets called in an > interpreted language, there's something like a "stack frame" created, > within the context of which the function executes, finally returning > some value to the caller. To complicate life, that frame may survive > the return as a closure (e.g. if the return values is a function object > that references locals of the frame). In C++, exiting a scope (which > corresponds to such a frame) calls destructors on all the objects > declared in the scope; but that doesn't happen in JavaScript, which > relies on the garbage-collector to catch those objects after they've > passed out of scope. If you can convincingly exhibit an interpreted > language using root_ptr for each of those frames, without causing > breakage (you'll need to make sure the returned value can't end up > holding any references to values owned by that frame; and you'll need to > interact correctly with closures), you'll have a more convincing case > for your innovation. > > As long as you pitch your idea in terms of the top-level HTML page or > QML window, you aren't convincing - because we *know* that'll leave huge > amounts of transiently-used memory that doesn't get released until the > page or window is closed, which is *far* too late. Show that you can > make it work at the level where it would actually reclaim memory sooner > than a garbage collector would. Then folk might listen. Ok thanks for the detailed analysis. If there is one root_ptr per Javascript function then all local variables are guaranteed to be destroyed. And closures aren't too big of a deal either because child objects can easily refer to their parent. But returning local variables might need some work on root_ptr such as "unlisting" the variable from one set in order to "enlist" it to the parent set. I also will need to remove the ability from root_ptr to "unify" sets when one of its node_ptr refers to an object from another set. If I can do that then there is no need to create a new language. Thanks, -Phil From tim at klingt.org Fri Jul 7 14:14:46 2017 From: tim at klingt.org (Tim Blechmann) Date: Fri, 7 Jul 2017 14:14:46 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <4373575.LjxagK0boG@tjmaciei-mobl1> <2891316.49BQzlKupU@tjmaciei-mobl1> Message-ID: > If there is one root_ptr per > Javascript function then all local variables are guaranteed to be > destroyed. And closures aren't too big of a deal either because child > objects can easily refer to their parent. > > But returning local variables might need some work on root_ptr such as > "unlisting" the variable from one set in order to "enlist" it to the > parent set. how do you solve the situation that an object might be referenced by multiple roots? From philippeb8 at gmail.com Fri Jul 7 15:09:05 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 7 Jul 2017 13:09:05 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <4373575.LjxagK0boG@tjmaciei-mobl1> <2891316.49BQzlKupU@tjmaciei-mobl1> Message-ID: Phil Bouchard wrote: > On 07/07/2017 04:39 AM, Edward Welbourne wrote: >> Phil Bouchard (7 July 2017 04:15) >>> >>> Anything that goes in that HTML page or QML window we don't care. The >>> reference counted property of root_ptr (node_ptr) will handle it and >>> the associated root_ptr will clean up the mess when it is destroyed. >> >> You'd need to apply root_ptr on a finer granularity than the top-level >> HTML page or QML window. For example, when a function gets called in an >> interpreted language, there's something like a "stack frame" created, >> within the context of which the function executes, finally returning >> some value to the caller. To complicate life, that frame may survive >> the return as a closure (e.g. if the return values is a function object >> that references locals of the frame). In C++, exiting a scope (which >> corresponds to such a frame) calls destructors on all the objects >> declared in the scope; but that doesn't happen in JavaScript, which >> relies on the garbage-collector to catch those objects after they've >> passed out of scope. If you can convincingly exhibit an interpreted >> language using root_ptr for each of those frames, without causing >> breakage (you'll need to make sure the returned value can't end up >> holding any references to values owned by that frame; and you'll need to >> interact correctly with closures), you'll have a more convincing case >> for your innovation. >> >> As long as you pitch your idea in terms of the top-level HTML page or >> QML window, you aren't convincing - because we *know* that'll leave huge >> amounts of transiently-used memory that doesn't get released until the >> page or window is closed, which is *far* too late. Show that you can >> make it work at the level where it would actually reclaim memory sooner >> than a garbage collector would. Then folk might listen. > > Ok thanks for the detailed analysis. If there is one root_ptr per > Javascript function then all local variables are guaranteed to be > destroyed. And closures aren't too big of a deal either because child > objects can easily refer to their parent. > > But returning local variables might need some work on root_ptr such as > "unlisting" the variable from one set in order to "enlist" it to the > parent set. I also will need to remove the ability from root_ptr to > "unify" sets when one of its node_ptr refers to an object from another set. > > If I can do that then there is no need to create a new language. > > > Thanks, > -Phil > Actually all that is needed to be done for that return value is to threat that return value like an implicit parameter. Ex.: var res; function foo(res) { res = 1; } alert((foo(res), res)); // outputs 1 Which is the same as: function foo() { return 1; } alert(foo()); // outputs 1 -Phil From philippeb8 at gmail.com Fri Jul 7 15:30:22 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 7 Jul 2017 13:30:22 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <4373575.LjxagK0boG@tjmaciei-mobl1> <2891316.49BQzlKupU@tjmaciei-mobl1> Message-ID: Tim Blechmann wrote: >> If there is one root_ptr per >> Javascript function then all local variables are guaranteed to be >> destroyed. And closures aren't too big of a deal either because child >> objects can easily refer to their parent. >> >> But returning local variables might need some work on root_ptr such as >> "unlisting" the variable from one set in order to "enlist" it to the >> parent set. > > how do you solve the situation that an object might be referenced by > multiple roots? > Please elaborate because as far as I know variables in Javascript have a function scope and functions can be nested (waterfall parent-child hierarchy). So child functions can access the parent variables because the root_ptr of the child will be deleted before its parent. Thus all I need to do is: - add some implicit parameter to functions which will represent return variables - remove the ability of root_ptr from unifying with other sets Thanks, -Phil From Richard.Gustavsen at qt.io Fri Jul 7 15:43:42 2017 From: Richard.Gustavsen at qt.io (Richard Gustavsen) Date: Fri, 7 Jul 2017 13:43:42 +0000 Subject: [Development] Widgets maintainers In-Reply-To: <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> References: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com>, <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> Message-ID: Thanks Frederik! A short introduction to myself: My name is Richard, I started at Trolltech in 2006, which means that I've been working with Qt for more than ten years. Most of that time I've been looking into issues on macOS, but after the Nokia era, I became a part of the team implementing and maintaining the iOS port. Either way, fixing and maintaining widgets has always been a reoccurring exercise, and I look forward to taking over the responsibility as the maintainer. -Richard ________________________________ Fra: Frederik Gladhorn Sendt: 7. juli 2017 13:03:49 Til: development at qt-project.org Kopi: Marc Mutz; Richard Gustavsen; Gabriel de Dietrich; andreas.aardal.hanssen at gmail.com; Jan-Arve Sæther; Eskil Abrahamsen Blomfeldt Emne: Re: [Development] Widgets maintainers Hello all, hello Marc, First of all, thank you very much for taking care of the widgets module and working to get bugs under control. We've been talking inside The Qt Company about the widgets module a lot lately, since we do see it as a very important part of Qt, which doesn't receive as much marketing and highlighting as it deserves. For traditional UIs, widgets are certainly a viable and good building block. While we don't anticipate huge changes in the module, we will keep on updating the styles where it makes sense and take bugs serious. Since it's also a big chunk of a module, we'd like to propse a team of maintainers, to make it easier on everyone. Our proposal is: Richard Gustavsen as overall maintainer Gabriel de Dietrich for styles Jan-Arve Sæther for layouts Eskil Abrahamsen-Blomfeldt for all text related things Andreas Aardal Hanssen for graphicsview Item Views is open and would fall to Richard for now, but if someone is interested in helping out more with it, that's certainly appreciated. Cheers, Frederik On fredag 7. juli 2017 12.20.19 CEST Marc Mutz wrote: > Hi all, > > KDAB is handing back widgets maintenance, which means that I'm stepping > down as widgets maintainer. The focus of KDAB contributions to Qt is > clearly elsewhere these days (Qt3D, Core, tooling), and the module > deserves more focus than it has seen lately. > > To this end, Lars has assembled a team(!) of proposed widgets > (sub)maintainers that we as KDAB and I personally fully support as > successors. > > In Lars' absence, I'll leave it to Frederik to introduce them to you in > detail (as if introduction was needed...). > > Thanks, > Marc > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.aardal.hanssen at gmail.com Fri Jul 7 17:03:59 2017 From: andreas.aardal.hanssen at gmail.com (Andreas Aardal Hanssen) Date: Fri, 7 Jul 2017 17:03:59 +0200 Subject: [Development] Widgets maintainers In-Reply-To: <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> References: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> Message-ID: <66533D16-DEFA-4523-A414-2270C437473C@gmail.com> > 7. jul. 2017 kl. 13.03 skrev Frederik Gladhorn : > Hello all, hello Marc, ... > Our proposal is: > Richard Gustavsen as overall maintainer > Gabriel de Dietrich for styles > Jan-Arve Sæther for layouts > Eskil Abrahamsen-Blomfeldt for all text related things > Andreas Aardal Hanssen for graphicsview Go widget team? ;-) Andreas From thiago.macieira at intel.com Fri Jul 7 18:29:12 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Jul 2017 09:29:12 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <3589631.DTHfid47jX@tjmaciei-mobl1> On sexta-feira, 7 de julho de 2017 06:30:22 PDT Phil Bouchard wrote: > > how do you solve the situation that an object might be referenced by > > multiple roots? > > Please elaborate because as far as I know variables in Javascript have a > function scope and functions can be nested (waterfall parent-child > hierarchy). So child functions can access the parent variables because the > root_ptr of the child will be deleted before its parent. Both in HTML and in QML, JS objects may be used to interchange data between multiple pages. That means the object belongs to both pages and should not be freed until both of them stop referencing it. > Thus all I need to do is: > - add some implicit parameter to functions which will represent return > variables > - remove the ability of root_ptr from unifying with other sets You're speaking in abstract terms. We actually need code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jul 7 18:34:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Jul 2017 09:34:01 -0700 Subject: [Development] Stepping down as widgets maintainers In-Reply-To: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> References: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> Message-ID: <1714138.kXay1iSZ6k@tjmaciei-mobl1> On sexta-feira, 7 de julho de 2017 03:20:19 PDT Marc Mutz wrote: > KDAB is handing back widgets maintenance, which means that I'm stepping > down as widgets maintainer. The focus of KDAB contributions to Qt is > clearly elsewhere these days (Qt3D, Core, tooling), and the module > deserves more focus than it has seen lately. Hello Marc Let me thank you for the effort on the module so far and for the work you've been doing in the core. It's much appreciated. Frederik wrote: > Richard Gustavsen as overall maintainer > Gabriel de Dietrich for styles > Jan-Arve Sæther for layouts > Eskil Abrahamsen-Blomfeldt for all text related things > Andreas Aardal Hanssen for graphicsview Many thanks for Richard for stepping up for the overall maintainership. +1 for him as maintainer. Then it's Richard's job to ACK the sub-maintainers, though it looks to me that all of them would be "duh, of course". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Fri Jul 7 18:44:50 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 7 Jul 2017 16:44:50 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <3589631.DTHfid47jX@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On sexta-feira, 7 de julho de 2017 06:30:22 PDT Phil Bouchard wrote: >>> how do you solve the situation that an object might be referenced by >>> multiple roots? >> >> Please elaborate because as far as I know variables in Javascript have a >> function scope and functions can be nested (waterfall parent-child >> hierarchy). So child functions can access the parent variables because the >> root_ptr of the child will be deleted before its parent. > > Both in HTML and in QML, JS objects may be used to interchange data between > multiple pages. That means the object belongs to both pages and should not be > freed until both of them stop referencing it. > >> Thus all I need to do is: >> - add some implicit parameter to functions which will represent return >> variables >> - remove the ability of root_ptr from unifying with other sets > > You're speaking in abstract terms. We actually need code. > Ok I can reuse my Fornux Calculator parser and mimic a function call in Javascript. From Jake.Petroules at qt.io Fri Jul 7 20:09:37 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 7 Jul 2017 18:09:37 +0000 Subject: [Development] Widgets maintainers In-Reply-To: <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> References: <97a1d14fbd1f7e45ed3f42772b32fd46@kdab.com> <1808908.4lPqMS3G2L@frederik-thinkcentre-m93p> Message-ID: <02ACBD51-5265-40EF-9BB7-6B2232732F28@qt.io> A big +1 to Gabriel for styles maintenance. The poor man has been doing a great job keeping his sanity while suffering through all those QMacStyle fixes lately... :) > On Jul 7, 2017, at 4:03 AM, Frederik Gladhorn wrote: > > Hello all, hello Marc, > > First of all, thank you very much for taking care of the widgets module and > working to get bugs under control. > > We've been talking inside The Qt Company about the widgets module a lot > lately, since we do see it as a very important part of Qt, which doesn't > receive as much marketing and highlighting as it deserves. For traditional > UIs, widgets are certainly a viable and good building block. > > While we don't anticipate huge changes in the module, we will keep on updating > the styles where it makes sense and take bugs serious. Since it's also a big > chunk of a module, we'd like to propse a team of maintainers, to make it > easier on everyone. > > Our proposal is: > Richard Gustavsen as overall maintainer > Gabriel de Dietrich for styles > Jan-Arve Sæther for layouts > Eskil Abrahamsen-Blomfeldt for all text related things > Andreas Aardal Hanssen for graphicsview > > Item Views is open and would fall to Richard for now, but if someone is > interested in helping out more with it, that's certainly appreciated. > > Cheers, > Frederik > > > On fredag 7. juli 2017 12.20.19 CEST Marc Mutz wrote: >> Hi all, >> >> KDAB is handing back widgets maintenance, which means that I'm stepping >> down as widgets maintainer. The focus of KDAB contributions to Qt is >> clearly elsewhere these days (Qt3D, Core, tooling), and the module >> deserves more focus than it has seen lately. >> >> To this end, Lars has assembled a team(!) of proposed widgets >> (sub)maintainers that we as KDAB and I personally fully support as >> successors. >> >> In Lars' absence, I'll leave it to Frederik to introduce them to you in >> detail (as if introduction was needed...). >> >> Thanks, >> Marc >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From rjvbertin at gmail.com Fri Jul 7 22:29:05 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 07 Jul 2017 22:29:05 +0200 Subject: [Development] WA_MacBrushedMetal Message-ID: <4010210.5Sogz5zMNV@portia.local> Hi, Has "brushed metal" mode been maintained in recent history? I haven't seen applications that use it for a long time so I tried WA_MacBrushedMetal out of nostalgia, and was rewarded with what looks most like cast iron (= black on black). Am I doing something wrong or can this attribute be retired? R. From Gabriel.deDietrich at qt.io Fri Jul 7 22:55:34 2017 From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich) Date: Fri, 7 Jul 2017 20:55:34 +0000 Subject: [Development] WA_MacBrushedMetal In-Reply-To: <4010210.5Sogz5zMNV@portia.local> References: <4010210.5Sogz5zMNV@portia.local> Message-ID: <3D7A6D38-F9F4-4430-AF98-D83622EF5637@qt.io> On Jul 7, 2017, at 1:29 PM, René J.V. Bertin > wrote: Has "brushed metal" mode been maintained in recent history? I haven't seen applications that use it for a long time so I tried WA_MacBrushedMetal out of nostalgia, and was rewarded with what looks most like cast iron (= black on black). Am I doing something wrong or can this attribute be retired? Hi René, QMacStyle is no longer using this attribute in 5.10. See https://codereview.qt-project.org/194383. We can’t remove it until Qt 6, but it should be documented as deprecated and effectively useless. Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company R. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.brichese at gmail.com Sat Jul 8 00:39:57 2017 From: matteo.brichese at gmail.com (Matteo) Date: Fri, 7 Jul 2017 15:39:57 -0700 Subject: [Development] Qt-AES - Looking for comments Message-ID: Hi all, I just finished the first preview of my QAESEncryption class and I would like to have some opinions on possible improvements, issues etc. https://github.com/bricke/Qt-AES This is still a work in progress but I feel it's good enough to be shared and I am ready to take the heat! Thank you Best Regards -- Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sat Jul 8 03:25:19 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 7 Jul 2017 21:25:19 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <3589631.DTHfid47jX@tjmaciei-mobl1> Message-ID: On 07/07/2017 12:44 PM, Phil Bouchard wrote: > Thiago Macieira wrote: >> >> You're speaking in abstract terms. We actually need code. > > Ok I can reuse my Fornux Calculator parser and mimic a function call in > Javascript. Actually I can predict what is going to happen if I was to integrate the actual root_ptr with the ability to unify sets implicitly, removed. So if for each function there is 1 root_ptr pointing to a list of local variables then: - the parameters of the function will remain unaffected if they are used as r-values - the parameters of the function will require a deep copy of the expression if they are used as l-values - closures of the function will remain unaffected if they are used as r-values - closures of the function will require a deep copy of the expression if they are used as l-values - return values will be deep copies. Example 1) function foo(source) { var image = new Image(); image.height = 100; image.title = file.name; image.src = source; // parameter used as an r-value will remain unaffected return image; // return value will require 'image' to be a deep copy }, Example 2) function previewFiles() { var preview = document.querySelector('#preview'); var files = document.querySelector('input[type=file]').files; function readAndPreview(file) { var reader1 = new FileReader(); reader1.addEventListener ( "load", function () { var image = new Image(); image.height = 100; image.title = file.name; image.src = this.result; preview.appendChild(image); // closure used as an l-value will require its parameter 'image' to be a deep copy }, false ); reader1.readAsDataURL(file); } if (files) { [].forEach.call(files, readAndPreview); } } In these examples I am using an image because that is a worse case scenario but 99% of the time parameters and closures will be simple integers and strings. This way there can be no cyclic reference left alone. See? We're getting somewhere. Thank you all for your input BTW; it helped me came to the aforementioned conclusion. Regards, -Phil From thiago.macieira at intel.com Sat Jul 8 03:55:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 07 Jul 2017 18:55:23 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <4311222.iUOT7ggqfG@tjmaciei-mobl1> On sexta-feira, 7 de julho de 2017 18:25:19 PDT Phil Bouchard wrote: > So if for each function there is 1 root_ptr pointing to a list of local > variables then: > - the parameters of the function will remain unaffected if they are used > as r-values > - the parameters of the function will require a deep copy of the > expression if they are used as l-values > - closures of the function will remain unaffected if they are used as > r-values > - closures of the function will require a deep copy of the expression if > they are used as l-values > - return values will be deep copies. JavaScript has no such thing as l or rvalues. Please define use proper terms for the language in question. I don't see a problem with variables being modified. But I do see a problem if a parameter is copied to a global variable. Requiring a deep copy is wasteful when the current code requires no such thing. So now you have to prove that htis extra waste is offset by the benefits of using root_ptr elsewhere. > function foo(source) > { > var image = new Image(); > image.height = 100; > image.title = file.name; > image.src = source; // parameter used as an r-value will remain > unaffected > return image; // return value will require 'image' to be a deep copy > }, So if this Image object opened a 4K image @ 3840x2160 (= just under 32 MB), you're suggesting that all 32 MB be copied? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Sat Jul 8 04:14:06 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 7 Jul 2017 22:14:06 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <4311222.iUOT7ggqfG@tjmaciei-mobl1> References: <4311222.iUOT7ggqfG@tjmaciei-mobl1> Message-ID: On 07/07/2017 09:55 PM, Thiago Macieira wrote: > On sexta-feira, 7 de julho de 2017 18:25:19 PDT Phil Bouchard wrote: > > JavaScript has no such thing as l or rvalues. Please define use proper terms > for the language in question. I get your point but those are just shortcuts to the following definitions: l-value: write variable r-value: read-only variable > I don't see a problem with variables being modified. But I do see a problem if > a parameter is copied to a global variable. Requiring a deep copy is wasteful > when the current code requires no such thing. So now you have to prove that > htis extra waste is offset by the benefits of using root_ptr elsewhere. > >> function foo(source) >> { >> var image = new Image(); >> image.height = 100; >> image.title = file.name; >> image.src = source; // parameter used as an r-value will remain >> unaffected >> return image; // return value will require 'image' to be a deep copy >> }, > > So if this Image object opened a 4K image @ 3840x2160 (= just under 32 MB), > you're suggesting that all 32 MB be copied? For this proposal, yes. But if I can do a deep copy then I can certainly "re-set" the variable (change the set the variable is owned by). If I can do that then we won't need any deep copy. I just need to think a little bit... thanks for your patience. From philippeb8 at gmail.com Sat Jul 8 06:42:59 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 8 Jul 2017 00:42:59 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <4311222.iUOT7ggqfG@tjmaciei-mobl1> Message-ID: On 07/07/2017 10:14 PM, Phil Bouchard wrote: > > But if I can do a deep copy then I can certainly "re-set" the variable > (change the set the variable is owned by). If I can do that then we > won't need any deep copy. > > I just need to think a little bit... thanks for your patience. Yes of course: I just need to add some metadata so the re-setting can propagate in a specific variable. I'll work on an engine to demonstrate its validity. -Phil From rjvbertin at gmail.com Sat Jul 8 10:12:06 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 08 Jul 2017 10:12:06 +0200 Subject: [Development] WA_MacBrushedMetal In-Reply-To: <3D7A6D38-F9F4-4430-AF98-D83622EF5637@qt.io> References: <4010210.5Sogz5zMNV@portia.local> <3D7A6D38-F9F4-4430-AF98-D83622EF5637@qt.io> Message-ID: <4308105.SrHK0PxJG8@bola> On Friday July 07 2017 20:55:34 Gabriel de Dietrich wrote: Hi Gabriel, >QMacStyle is no longer using this attribute in 5.10. See https://codereview.qt-project.org/194383. >We can’t remove it until Qt 6, but it should be documented as deprecated and effectively useless. That's more or less what I had in mind. I haven't checked if the corresponding attribute still has any effect in Xcode's InterfaceBuilder but as I said it seems that WA_MacBrushedMetal has only adverse effects in recent Qt versions. If that's not because of something I'm doing wrong that would argue for removing all related code from QMacStyle, leaving only the attribute definition. Better that it has the same lack of effect across all styles (possibly just a qWarning()) than maintaining code that no one would use anyway, no? R. From tim at klingt.org Sat Jul 8 12:11:26 2017 From: tim at klingt.org (Tim Blechmann) Date: Sat, 8 Jul 2017 12:11:26 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <3589631.DTHfid47jX@tjmaciei-mobl1> Message-ID: > - the parameters of the function will remain unaffected if they are used as r-values > - the parameters of the function will require a deep copy of the expression if they are used as l-values https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing function foo( arg ) { var img = readImage( arg.source ); arg.result = img; return img; } required semantics: arg.result and the return value refer to the same object. -- btw, it may be interesting for you to read a bit about escape analysis. From massimocallegari at yahoo.it Sat Jul 8 13:24:56 2017 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 8 Jul 2017 11:24:56 +0000 (UTC) Subject: [Development] How is Quick Controls 2 deployment meant to be ? References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> Message-ID: <2123058726.1546356.1499513096391@mail.yahoo.com> Hello Qt devs, the Quick Controls 2 initiative is great, but I'm struggling to understand how deployment is meant to be done. So for "fun" I did an experiment on Windows (but this is the same also on other platforms): - open Qt Creator - create a new Quick Controls 2 default template (1 text field, 1 button, 1 swipeview) - select "Default" as the only style - build and deploy with windeployqt For a 21Kb executable, you'll get a marvellous 61MB bundle, with a total of 235 files in it. Now, I see two major issues here: 1) *deployqt is basically a useless tool. It doesn't consider the real dependencies needed and copy everything every time. In the bundle I found the network bearer plugins, when the application clearly doesn't use any QtNetwork feature. Same for iconengines and imageformats plugins. In QtQuick/Controls.2 I found Material and Universal styles (106 files total) when I clearly told Qt Creator I didn't want them. In the same folder there are 56 files, when the app probably requires less than 10. 2) Security ? There is none. If you deploy an application using a TextField control with echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a password. In general, an end user can seriously mess up an application by changing a few text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and compromise my system. Now, I'm stuck in deciding what to do with all the above. Manually building a list of QML files needed is a nightmare. Using *deployqt and then removing the files not needed is a nightmare as well. In my opinion the optimal solution would be to have an inspection tool that identifies the exact files needed by an application that outputs a QRC file that can be easily added to the application .pro file. A sort of pre-building step. No idea how this copes with the recent QML caching system and what is more efficient between qmlc files and QRC-bundled QMLs. I am open to ideas and comments. Maybe I'm really missing something obvious that I couldn't find in the online documentation. Cheers, Massimo From cfeck at kde.org Sat Jul 8 13:46:47 2017 From: cfeck at kde.org (Christoph Feck) Date: Sat, 8 Jul 2017 13:46:47 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <2123058726.1546356.1499513096391@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> Message-ID: <95848c74-3749-82ec-823e-4f0065b3d602@kde.org> On 08.07.2017 13:24, Massimo Callegari via Development wrote: > 2) Security ? There is none. > If you deploy an application using a TextField control with echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a password. > In general, an end user can seriously mess up an application by changing a few text files. > I'm also wondering how Linux distributions can accept this. In my KDE Neon distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and compromise my system. If you have root access. From filippocucchetto at gmail.com Sat Jul 8 14:30:08 2017 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Sat, 8 Jul 2017 14:30:08 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <2123058726.1546356.1499513096391@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> Message-ID: * I think that Universal and material styles are bundled because the user can change the current style used from the command line * For the QtNetwork stuff you need to keep in mind that a lost of stuff works with URLs. For example you can specify and "http://.." url for an Image source. If i'm not wrong this implies that QtNetwork is a strong dependency of QtQuick. * Security is a big topic, but for files you use the filesystem user/group permissions 2017-07-08 13:24 GMT+02:00 Massimo Callegari via Development < development at qt-project.org>: > Hello Qt devs, > > the Quick Controls 2 initiative is great, but I'm struggling to understand > how deployment is meant to be done. > > So for "fun" I did an experiment on Windows (but this is the same also on > other platforms): > - open Qt Creator > - create a new Quick Controls 2 default template (1 text field, 1 button, > 1 swipeview) > - select "Default" as the only style > - build and deploy with windeployqt > > For a 21Kb executable, you'll get a marvellous 61MB bundle, with a total > of 235 files in it. > > Now, I see two major issues here: > > 1) *deployqt is basically a useless tool. It doesn't consider the real > dependencies needed and copy everything every time. > In the bundle I found the network bearer plugins, when the application > clearly doesn't use any QtNetwork feature. > Same for iconengines and imageformats plugins. > In QtQuick/Controls.2 I found Material and Universal styles (106 files > total) when I clearly told Qt Creator I didn't want them. > In the same folder there are 56 files, when the app probably requires less > than 10. > > 2) Security ? There is none. > If you deploy an application using a TextField control with echoMode: > TextInput.Password, one can easily add some trivial JavaScript code to the > comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow > display/log a password. > In general, an end user can seriously mess up an application by changing a > few text files. > I'm also wondering how Linux distributions can accept this. In my KDE Neon > distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that > I can edit and compromise my system. > > Now, I'm stuck in deciding what to do with all the above. Manually > building a list of QML files needed is a nightmare. Using *deployqt and > then removing the files not needed is a nightmare as well. > > In my opinion the optimal solution would be to have an inspection tool > that identifies the exact files needed by an application that outputs a QRC > file that can be easily added to the application .pro file. A sort of > pre-building step. > No idea how this copes with the recent QML caching system and what is more > efficient between qmlc files and QRC-bundled QMLs. > > I am open to ideas and comments. Maybe I'm really missing something > obvious that I couldn't find in the online documentation. > > Cheers, > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimocallegari at yahoo.it Sat Jul 8 15:33:54 2017 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 8 Jul 2017 13:33:54 +0000 (UTC) Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> Message-ID: <1418494418.1637392.1499520834261@mail.yahoo.com> > * I think that Universal and material styles are bundled because the user can change the current style used from the command line I know that, but it should be up to the developer to pick what goes in the bundle, not a tool. In my case, I use Quick Controls 2 just as templates and I override what I need to create my custom look & feel. So I don't need any style at all. > * For the QtNetwork stuff you need to keep in mind that a lost of stuff works with URLs. For example you can specify and "http://.." url for an Image source. If i'm not wrong this implies that QtNetwork is a strong dependency of QtQuick. I am aware of this as well, but the basic Quick Controls 2 template created by Qt Creator doesn't make any use of network URLs. In other words, *deployqt should analyze the code in deep to find whether a component is really needed or not. In case, again, the developer might adjust the final dependencies if they really need to. > * Security is a big topic, but for files you use the filesystem user/group permissions As far as I know, there's no such thing in Windows when you install an application at user level. I use NSIS to provide a self-installing bundle and I'm not even sure if I can configure it to restrict to the system administrator the access of just some files. In any case, home PC Windows users are normally system administrators too. Same story for Linux. If I'm not mistaken, even in a macOS bundle you can edit files without root privileges. In every case though, QML files can at least be read, and believe me when I say I've got users that are capable of telling me "why don't you change Button.qml padding from 6 to 10 ?". Or even worse, they change stuff, and then come up with ridiculous issues and I need to waste my (limited) time to find out what's going on. To be honest I don't want them to peek their noses in the code, unless they are developers who know what they're saying. Mine is an open source application, but the less they can change, the less they are tempted to become developers in one day... ________________________________ Da: Filippo Cucchetto A: Massimo Callegari Cc: Qt Development ML Inviato: Sabato 8 Luglio 2017 14:30 Oggetto: Re: [Development] How is Quick Controls 2 deployment meant to be ? * I think that Universal and material styles are bundled because the user can change the current style used from the command line * For the QtNetwork stuff you need to keep in mind that a lost of stuff works with URLs. For example you can specify and "http://.." url for an Image source. If i'm not wrong this implies that QtNetwork is a strong dependency of QtQuick. * Security is a big topic, but for files you use the filesystem user/group permissions 2017-07-08 13:24 GMT+02:00 Massimo Callegari via Development : Hello Qt devs, > >the Quick Controls 2 initiative is great, but I'm struggling to understand how deployment is meant to be done. > >So for "fun" I did an experiment on Windows (but this is the same also on other platforms): >- open Qt Creator >- create a new Quick Controls 2 default template (1 text field, 1 button, 1 swipeview) >- select "Default" as the only style >- build and deploy with windeployqt > >For a 21Kb executable, you'll get a marvellous 61MB bundle, with a total of 235 files in it. > >Now, I see two major issues here: > >1) *deployqt is basically a useless tool. It doesn't consider the real dependencies needed and copy everything every time. >In the bundle I found the network bearer plugins, when the application clearly doesn't use any QtNetwork feature. >Same for iconengines and imageformats plugins. >In QtQuick/Controls.2 I found Material and Universal styles (106 files total) when I clearly told Qt Creator I didn't want them. >In the same folder there are 56 files, when the app probably requires less than 10. > >2) Security ? There is none. >If you deploy an application using a TextField control with echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the comfortably reachable QtQuick/Controls.2/TextField. qml file and somehow display/log a password. >In general, an end user can seriously mess up an application by changing a few text files. >I'm also wondering how Linux distributions can accept this. In my KDE Neon distro I've got /usr/lib/x86_64-linux-gnu/qt5/ qml/ full of QML files that I can edit and compromise my system. > >Now, I'm stuck in deciding what to do with all the above. Manually building a list of QML files needed is a nightmare. Using *deployqt and then removing the files not needed is a nightmare as well. > >In my opinion the optimal solution would be to have an inspection tool that identifies the exact files needed by an application that outputs a QRC file that can be easily added to the application .pro file. A sort of pre-building step. >No idea how this copes with the recent QML caching system and what is more efficient between qmlc files and QRC-bundled QMLs. > >I am open to ideas and comments. Maybe I'm really missing something obvious that I couldn't find in the online documentation. > >Cheers, >Massimo >______________________________ _________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/ mailman/listinfo/development > -- Filippo Cucchetto From apoenitz at t-online.de Sat Jul 8 17:02:08 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 8 Jul 2017 17:02:08 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <1418494418.1637392.1499520834261@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> <1418494418.1637392.1499520834261@mail.yahoo.com> Message-ID: <20170708150207.GA4953@klara.mpi.htwm.de> On Sat, Jul 08, 2017 at 01:33:54PM +0000, Massimo Callegari via Development wrote: > > * Security is a big topic, but for files you use the filesystem user/group permissions > > As far as I know, there's no such thing in Windows when you install an application at user > level. I use NSIS to provide a self-installing bundle and I'm not even sure if I can > configure it to restrict to the system administrator the access of just some files. In any > case, home PC Windows users are normally system administrators too. Same story for Linux. What's the conceptual difference between a binary and a text file in this context? That your users are less skilled to edit a binary then some text? Andre' From apoenitz at t-online.de Sat Jul 8 17:07:32 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 8 Jul 2017 17:07:32 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <2123058726.1546356.1499513096391@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> Message-ID: <20170708150732.GA4998@klara.mpi.htwm.de> On Sat, Jul 08, 2017 at 11:24:56AM +0000, Massimo Callegari via Development wrote: > 2) Security ? There is none. If you deploy an application using a TextField control with > echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the > comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a > password. In general, an end user can seriously mess up an application by changing a few > text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon > distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and > compromise my system. I'll not argue about the others, but this here is nonsense. Anyone who can edit /lib normally can also edit /etc etc. Andre' From massimocallegari at yahoo.it Sat Jul 8 20:00:23 2017 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 8 Jul 2017 18:00:23 +0000 (UTC) Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <20170708150732.GA4998@klara.mpi.htwm.de> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> <20170708150732.GA4998@klara.mpi.htwm.de> Message-ID: <2032424431.1724052.1499536823535@mail.yahoo.com> On Sat, Jul 08, 2017 at 11:24:56AM +0000, Massimo Callegari via Development wrote: >> 2) Security ? There is none. If you deploy an application using a TextField control with >> echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the >> comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a >> password. In general, an end user can seriously mess up an application by changing a few >> text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon >> distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and >> compromise my system. > I'll not argue about the others, but this here is nonsense. Anyone who can edit > /lib normally can also edit /etc etc. I disagree. The nonsense, instead, is comparing configuration files with source files. Config files are usually parsed by an application, which (hopefully) filters malicious intentions. QML files instead, are executed by the application no matter what. As long as "edited" QML files have a correct syntax, the QML engine executes them. Massimo From apoenitz at t-online.de Sat Jul 8 19:24:46 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 8 Jul 2017 19:24:46 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <2032424431.1724052.1499536823535@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> <20170708150732.GA4998@klara.mpi.htwm.de> <2032424431.1724052.1499536823535@mail.yahoo.com> Message-ID: <20170708172446.GA5339@klara.mpi.htwm.de> On Sat, Jul 08, 2017 at 06:00:23PM +0000, Massimo Callegari wrote: > > > On Sat, Jul 08, 2017 at 11:24:56AM +0000, Massimo Callegari via Development wrote: > > >> 2) Security ? There is none. If you deploy an application using a TextField control with > >> echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the > >> comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a > >> password. In general, an end user can seriously mess up an application by changing a few > >> text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon > >> distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and > >> compromise my system. > > > I'll not argue about the others, but this here is nonsense. Anyone who can edit > > /lib normally can also edit /etc etc. > > > I disagree. The nonsense, instead, is comparing configuration files with source files. > Config files are usually parsed by an application, which (hopefully) filters malicious intentions. Like a text editor that is used to edit /etc/passwd or /etc/group will "filter" malicious intentions when saving the file? > QML files instead, are executed by the application no matter what. > As long as "edited" QML files have a correct syntax, the QML engine executes them. And if I 'edit' /bin/ls to do the equivalent of 'rm -rf /' it will happily do that. The fact that something is a 'text' file does not make it different, permissions make a difference. Andre' From annulen at yandex.ru Sat Jul 8 20:37:05 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 08 Jul 2017 21:37:05 +0300 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <2032424431.1724052.1499536823535@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> <20170708150732.GA4998@klara.mpi.htwm.de> <2032424431.1724052.1499536823535@mail.yahoo.com> Message-ID: <2062501499539025@web23m.yandex.ru> 08.07.2017, 21:01, "Massimo Callegari via Development" : > On Sat, Jul 08, 2017 at 11:24:56AM +0000, Massimo Callegari via Development wrote: > >>>  2) Security ? There is none. If you deploy an application using a TextField control with >>>  echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the >>>  comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a >>>  password. In general, an end user can seriously mess up an application by changing a few >>>  text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon >>>  distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and >>>  compromise my system. > >>  I'll not argue about the others, but this here is nonsense. Anyone who can edit >>  /lib normally can also edit /etc etc. > > I disagree. The nonsense, instead, is comparing configuration files with source files. > Config files are usually parsed by an application, which (hopefully) filters malicious intentions. > QML files instead, are executed by the application no matter what. > As long as "edited" QML files have a correct syntax, the QML engine executes them. Exactly the same situation exists with binary plugins of Qt. Anyone with write access to plugins directory can put malicious code in plugin at it will be executed by Qt. > > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From massimocallegari at yahoo.it Sat Jul 8 21:16:33 2017 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 8 Jul 2017 19:16:33 +0000 (UTC) Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <20170708172446.GA5339@klara.mpi.htwm.de> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> <20170708150732.GA4998@klara.mpi.htwm.de> <2032424431.1724052.1499536823535@mail.yahoo.com> <20170708172446.GA5339@klara.mpi.htwm.de> Message-ID: <26163951.1838753.1499541393707@mail.yahoo.com> @André > Like a text editor that is used to edit /etc/passwd or /etc/group will "filter" malicious intentions when saving the file? How you edit the files is irrelevant. /etc/passwd is interpreted by openssl. That is relevant. You clearly didn't get the point. > And if I 'edit' /bin/ls to do the equivalent of 'rm -rf /' it will happily do that. That's another story. You were comparing the content of /etc with QML files in /lib, and I replied to that. > The fact that something is a 'text' file does not make it different, permissions make a difference. True, but this discussion moved specifically to Linux, while what I mentioned in the first place was Windows, which is sadly still the most used platform in the world. @Konstantin > Exactly the same situation exists with binary plugins of Qt. Anyone with write access to plugins directory can put malicious code in plugin at it will be executed by Qt. As if writing a shared library is the same thing of editing a text file with minimal JSON/JavaScript knowledge... ________________________________ Da: André Pönitz A: Massimo Callegari Cc: Qt Development ML Inviato: Sabato 8 Luglio 2017 20:22 Oggetto: Re: [Development] How is Quick Controls 2 deployment meant to be ? On Sat, Jul 08, 2017 at 06:00:23PM +0000, Massimo Callegari wrote: > > > On Sat, Jul 08, 2017 at 11:24:56AM +0000, Massimo Callegari via Development wrote: > > >> 2) Security ? There is none. If you deploy an application using a TextField control with > >> echoMode: TextInput.Password, one can easily add some trivial JavaScript code to the > >> comfortably reachable QtQuick/Controls.2/TextField.qml file and somehow display/log a > >> password. In general, an end user can seriously mess up an application by changing a few > >> text files. I'm also wondering how Linux distributions can accept this. In my KDE Neon > >> distro I've got /usr/lib/x86_64-linux-gnu/qt5/qml/ full of QML files that I can edit and > >> compromise my system. > > > I'll not argue about the others, but this here is nonsense. Anyone who can edit > > /lib normally can also edit /etc etc. > > > I disagree. The nonsense, instead, is comparing configuration files with source files. > Config files are usually parsed by an application, which (hopefully) filters malicious intentions. Like a text editor that is used to edit /etc/passwd or /etc/group will "filter" malicious intentions when saving the file? > QML files instead, are executed by the application no matter what. > As long as "edited" QML files have a correct syntax, the QML engine executes them. And if I 'edit' /bin/ls to do the equivalent of 'rm -rf /' it will happily do that. The fact that something is a 'text' file does not make it different, permissions make a difference. Andre' From philippeb8 at gmail.com Sun Jul 9 00:57:50 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 8 Jul 2017 18:57:50 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <4311222.iUOT7ggqfG@tjmaciei-mobl1> Message-ID: On 07/08/2017 12:42 AM, Phil Bouchard wrote: > On 07/07/2017 10:14 PM, Phil Bouchard wrote: >> >> But if I can do a deep copy then I can certainly "re-set" the variable >> (change the set the variable is owned by). If I can do that then we >> won't need any deep copy. >> >> I just need to think a little bit... thanks for your patience. > > Yes of course: I just need to add some metadata so the re-setting can > propagate in a specific variable. > > I'll work on an engine to demonstrate its validity. Alright I already got something. If we mimic the Javascript function scope in C++ then we'll have the following: https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_example1.cpp The application outputs: Scope 0: BEGIN Scope 1: BEGIN A::A(const boost::node_proxy&) A::A(const boost::node_proxy&) A::~A() Scope 1: END A::~A() Scope 0: END Which is exactly what we want. Note that I didn't stress tested it yet. If you don't mind I will start a new thread with the Boost mailing list to see their opinion. Thanks, -Phil From thiago.macieira at intel.com Sun Jul 9 23:40:04 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 09 Jul 2017 14:40:04 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <2390331.PqD4UjZk38@tjmaciei-mobl1> On sábado, 8 de julho de 2017 15:57:50 PDT Phil Bouchard wrote: > https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_examp > le1.cpp > > The application outputs: > Scope 0: BEGIN > Scope 1: BEGIN > A::A(const boost::node_proxy&) > A::A(const boost::node_proxy&) > A::~A() > Scope 1: END > A::~A() > Scope 0: END Why are there two A::A and two A::~A in the output if the source has four objects created? > Which is exactly what we want. Note that I didn't stress tested it yet. > If you don't mind I will start a new thread with the Boost mailing > list to see their opinion. You'll also need to disentangle it from Boost before it can be used in Qt. Move it to independent headers depending only on the C++98 standard library ( C++11 core language features are ok). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Mon Jul 10 00:35:43 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 9 Jul 2017 18:35:43 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <2390331.PqD4UjZk38@tjmaciei-mobl1> References: <2390331.PqD4UjZk38@tjmaciei-mobl1> Message-ID: On 07/09/2017 05:40 PM, Thiago Macieira wrote: > On sábado, 8 de julho de 2017 15:57:50 PDT Phil Bouchard wrote: >> https://github.com/philippeb8/root_ptr/blob/develop/example/javascript_examp >> le1.cpp >> >> The application outputs: >> Scope 0: BEGIN >> Scope 1: BEGIN >> A::A(const boost::node_proxy&) >> A::A(const boost::node_proxy&) >> A::~A() >> Scope 1: END >> A::~A() >> Scope 0: END > > Why are there two A::A and two A::~A in the output if the source has four > objects created? I updated javascript_example1.cpp so the aforementioned output is out of sync with the source file. I should have copied and pasted the source. Please see the last thread [root_ptr]... for today's updates regarding it. >> Which is exactly what we want. Note that I didn't stress tested it yet. >> If you don't mind I will start a new thread with the Boost mailing >> list to see their opinion. > > You'll also need to disentangle it from Boost before it can be used in Qt. > Move it to independent headers depending only on the C++98 standard library ( > C++11 core language features are ok). The licenses are incompatible? I think I was relying heavily on because Peter Dimov wrote a portable atomic reference counter. I'm sure there is an equivalent in Qt but I'll need some pointers to speed things up. But thanks again, I really appreciate. Regards, -Phil From philippeb8 at gmail.com Mon Jul 10 04:22:30 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 9 Jul 2017 22:22:30 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2390331.PqD4UjZk38@tjmaciei-mobl1> Message-ID: On 07/09/2017 06:35 PM, Phil Bouchard wrote: > > I'm sure there is an equivalent in > Qt but I'll need some pointers to speed things up. I think QAtomicInt is the perfect replacement: http://doc.qt.io/qt-4.8/qatomicint.html#details -Phil From philippeb8 at gmail.com Mon Jul 10 06:13:33 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 10 Jul 2017 00:13:33 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2390331.PqD4UjZk38@tjmaciei-mobl1> Message-ID: On 07/09/2017 10:22 PM, Phil Bouchard wrote: > On 07/09/2017 06:35 PM, Phil Bouchard wrote: >> >> I'm sure there is an equivalent in >> Qt but I'll need some pointers to speed things up. > > I think QAtomicInt is the perfect replacement: > http://doc.qt.io/qt-4.8/qatomicint.html#details I started another branch reserved for Qt here: https://github.com/philippeb8/root_ptr/tree/qt Thanks, -Phil From christian.kandeler at qt.io Mon Jul 10 10:11:34 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 10 Jul 2017 10:11:34 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> Message-ID: <20170710101135.5499feaa@ckandeler-archlinux> On Sat, 8 Jul 2017 14:30:08 +0200 Filippo Cucchetto wrote: > * For the QtNetwork stuff you need to keep in mind that a lost of stuff > works with URLs. For example you can specify and "http://.." url for an > Image source. If i'm not wrong this implies that QtNetwork is a strong > dependency of QtQuick. As far as I can tell, you can disable the network dependency using the qml-network feature when building your own Qt. Of course that won't help you much when working with a pre-built Qt. Christian From thiago.macieira at intel.com Mon Jul 10 19:33:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 10 Jul 2017 10:33:50 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2390331.PqD4UjZk38@tjmaciei-mobl1> Message-ID: <1835758.0ZHP1PgSol@tjmaciei-mobl1> On domingo, 9 de julho de 2017 15:35:43 PDT Phil Bouchard wrote: > > You'll also need to disentangle it from Boost before it can be used in Qt. > > Move it to independent headers depending only on the C++98 standard > > library ( C++11 core language features are ok). > > The licenses are incompatible? I think I was relying heavily on > because Peter Dimov wrote a > portable atomic reference counter. I'm sure there is an equivalent in > Qt but I'll need some pointers to speed things up. No, it's not a licensing problem, just that of dependency. We will not depend on a prior Boost installation. If you're looking for a reference counter, we have QRefCount, not to mention QAtomicInt. We've had those for longer than they existed in the C++ standard. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 10 19:34:20 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 10 Jul 2017 10:34:20 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <1804908.vqGIHUMFJM@tjmaciei-mobl1> On domingo, 9 de julho de 2017 21:13:33 PDT Phil Bouchard wrote: > On 07/09/2017 10:22 PM, Phil Bouchard wrote: > > On 07/09/2017 06:35 PM, Phil Bouchard wrote: > >> I'm sure there is an equivalent in > >> Qt but I'll need some pointers to speed things up. > > > > I think QAtomicInt is the perfect replacement: > > http://doc.qt.io/qt-4.8/qatomicint.html#details > > I started another branch reserved for Qt here: > https://github.com/philippeb8/root_ptr/tree/qt Just to be clear: writing the pointer class is not enough. Someone has to port the JS engine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 10 19:35:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 10 Jul 2017 10:35:00 -0700 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <20170710101135.5499feaa@ckandeler-archlinux> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <20170710101135.5499feaa@ckandeler-archlinux> Message-ID: <749856425.8bcXgaECZa@tjmaciei-mobl1> On segunda-feira, 10 de julho de 2017 01:11:34 PDT Christian Kandeler wrote: > On Sat, 8 Jul 2017 14:30:08 +0200 > > Filippo Cucchetto wrote: > > * For the QtNetwork stuff you need to keep in mind that a lost of stuff > > works with URLs. For example you can specify and "http://.." url for an > > Image source. If i'm not wrong this implies that QtNetwork is a strong > > dependency of QtQuick. > > As far as I can tell, you can disable the network dependency using the > qml-network feature when building your own Qt. Of course that won't help you > much when working with a pre-built Qt. This should be togglable on a per-engine or per-view basis. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Mon Jul 10 20:05:07 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 10 Jul 2017 18:05:07 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On domingo, 9 de julho de 2017 21:13:33 PDT Phil Bouchard wrote: >> On 07/09/2017 10:22 PM, Phil Bouchard wrote: >>> On 07/09/2017 06:35 PM, Phil Bouchard wrote: >>>> I'm sure there is an equivalent in >>>> Qt but I'll need some pointers to speed things up. >>> >>> I think QAtomicInt is the perfect replacement: >>> http://doc.qt.io/qt-4.8/qatomicint.html#details >> >> I started another branch reserved for Qt here: >> https://github.com/philippeb8/root_ptr/tree/qt > > Just to be clear: writing the pointer class is not enough. Someone has to port > the JS engine. BTW converting Javascript into C++ seems very easy to do; but I'll need to analyze the JS engine first with some help from some expert if I want to integrate it, thanks. Also I will revert the change I made which "upscales the scope of a variable". That change was wrong and the manager will be like it was before (better). Regards, -Phil From philippeb8 at gmail.com Mon Jul 10 20:56:07 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 10 Jul 2017 18:56:07 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> Message-ID: Phil Bouchard wrote: > > BTW converting Javascript into C++ seems very easy to do In fact, is it me or it would seem that: - converting the Javascript code into C++ on-the-fly - compiling the resulting C++ code Would be a more efficient alternative than all these JIT tools? My 2 cents, -Phil From iamsergio at gmail.com Mon Jul 10 21:44:02 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 10 Jul 2017 20:44:02 +0100 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: On Wed, Jul 5, 2017 at 5:03 AM, Phil Bouchard wrote: > Hi, > > I read Qt 5.9 is using a new garbage collector that is more predictable. > First good job and second I was wondering if there is any documentation on > that garbage collector in question. The documentation is probably this: https://codereview.qt-project.org/#/c/180739/, git log is also good, setting breakpoints and looking at the stack trace is also useful to learn complicated code bases. > I guess if there is any interests to make the garbage collector perfectly > deterministic then root_ptr could be relatively easily integrated at this > stage. Interest will only come when people see a QML app running on it. The maintainer(s) won't invest much time helping if he doesn't believe in the idea. If you try and fail, at least you'll learn a lot about QML and V4 and probably find other types of improvements. Regards, Sergio Martins From thiago.macieira at intel.com Mon Jul 10 23:08:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 10 Jul 2017 14:08:47 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <23075004.L1XjGcIccQ@tjmaciei-mobl1> On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote: > Phil Bouchard wrote: > > BTW converting Javascript into C++ seems very easy to do > > In fact, is it me or it would seem that: > - converting the Javascript code into C++ on-the-fly > - compiling the resulting C++ code > > Would be a more efficient alternative than all these JIT tools? No. That would require having a C++ compiler with all the dependent libraries on every user's device. You must run the JS as provided and interact with the plugins as they exist today. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Jul 11 06:51:39 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 11 Jul 2017 00:51:39 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <23075004.L1XjGcIccQ@tjmaciei-mobl1> References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: On 07/10/2017 05:08 PM, Thiago Macieira wrote: > On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote: >> Phil Bouchard wrote: >>> BTW converting Javascript into C++ seems very easy to do >> >> In fact, is it me or it would seem that: >> - converting the Javascript code into C++ on-the-fly >> - compiling the resulting C++ code >> >> Would be a more efficient alternative than all these JIT tools? > > No. That would require having a C++ compiler with all the dependent libraries > on every user's device. > > You must run the JS as provided and interact with the plugins as they exist > today. Indeed Javascript is not made to run heavy CPU algorithms anyways. On the other hand, I have good news as I think I have found a way to simulate functions that return a function. I know a Javascript to C++ converter is not what we're looking for but it helps me understand these cases better. -Phil From tim at klingt.org Tue Jul 11 10:02:33 2017 From: tim at klingt.org (Tim Blechmann) Date: Tue, 11 Jul 2017 10:02:33 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: > On the other hand, I have good news as I think I have found a way to > simulate functions that return a function. how to you cope with structures like: function foo( outObject ) { var object = {} outObject.object = object outObject.result = function() { return object } return function() { return bar( object ) } } From b.terrier at gmail.com Tue Jul 11 11:08:18 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Tue, 11 Jul 2017 11:08:18 +0200 Subject: [Development] How is Quick Controls 2 deployment meant to be ? In-Reply-To: <26163951.1838753.1499541393707@mail.yahoo.com> References: <2123058726.1546356.1499513096391.ref@mail.yahoo.com> <2123058726.1546356.1499513096391@mail.yahoo.com> <20170708150732.GA4998@klara.mpi.htwm.de> <2032424431.1724052.1499536823535@mail.yahoo.com> <20170708172446.GA5339@klara.mpi.htwm.de> <26163951.1838753.1499541393707@mail.yahoo.com> Message-ID: 2017-07-08 21:16 GMT+02:00 Massimo Callegari via Development : > > > The fact that something is a 'text' file does not make it different, permissions make a difference. > > True, but this discussion moved specifically to Linux, while what I mentioned in the first place was Windows, which is sadly still the most used platform in the world. The same applies to Windows (since Vista I think). Standard users do not have write access in system critical folders including "Program Files" and Admins will only have access after a UAC prompt. That's why some software install themselves in user's AppData when the user does not have admin rights. Benjamin Terrier From kevin.kofler at chello.at Tue Jul 11 11:24:40 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 11 Jul 2017 11:24:40 +0200 Subject: [Development] Timeframe for 5.6.3? Message-ID: Hi, Is there a timeframe for the Qt 5.6.3 LTS release? Or is everyone expected to move to 5.9 now? The last 5.6.x release was in October 2016, and especially QtWebEngine has accumulated a lot of security fixes since then. If it is still going to take a while, could we please at least have snapshot tarballs built with the release scripts (syncqt etc.)? I am asking in particular because I would like to issue a QtWebEngine security update to Fedora 24 before it reaches its end of life a month from now. Just backporting patches to 5.6.2 is not going to be practical because Chromium was upgraded from 45 to 49 between 5.6.2 and 5.6.3. Unfortunately, an LTS branch loses a lot of its value when security updates are not provided in a timely manner. Kind regards, Kevin Kofler From Simon.Hausmann at qt.io Tue Jul 11 11:29:37 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Jul 2017 09:29:37 +0000 Subject: [Development] Timeframe for 5.6.3? In-Reply-To: References: Message-ID: Hi, https://wiki.qt.io/Qt_5.6_Release talks about August as a potential time frame. Simon ________________________________ From: Development on behalf of Kevin Kofler Sent: Tuesday, July 11, 2017 11:24:40 AM To: development at qt-project.org Subject: [Development] Timeframe for 5.6.3? Hi, Is there a timeframe for the Qt 5.6.3 LTS release? Or is everyone expected to move to 5.9 now? The last 5.6.x release was in October 2016, and especially QtWebEngine has accumulated a lot of security fixes since then. If it is still going to take a while, could we please at least have snapshot tarballs built with the release scripts (syncqt etc.)? I am asking in particular because I would like to issue a QtWebEngine security update to Fedora 24 before it reaches its end of life a month from now. Just backporting patches to 5.6.2 is not going to be practical because Chromium was upgraded from 45 to 49 between 5.6.2 and 5.6.3. Unfortunately, an LTS branch loses a lot of its value when security updates are not provided in a timely manner. Kind regards, Kevin Kofler _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Jul 11 12:33:34 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 11 Jul 2017 13:33:34 +0300 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: <2343501499769214@web4g.yandex.ru> 11.07.2017, 07:52, "Phil Bouchard" : > On 07/10/2017 05:08 PM, Thiago Macieira wrote: >>  On segunda-feira, 10 de julho de 2017 11:56:07 PDT Phil Bouchard wrote: >>>  Phil Bouchard wrote: >>>>  BTW converting Javascript into C++ seems very easy to do >>> >>>  In fact, is it me or it would seem that: >>>  - converting the Javascript code into C++ on-the-fly >>>  - compiling the resulting C++ code >>> >>>  Would be a more efficient alternative than all these JIT tools? >> >>  No. That would require having a C++ compiler with all the dependent libraries >>  on every user's device. >> >>  You must run the JS as provided and interact with the plugins as they exist >>  today. > > Indeed Javascript is not made to run heavy CPU algorithms anyways. Really? http://browserbench.org/JetStream/ > > On the other hand, I have good news as I think I have found a way to > simulate functions that return a function. I know a Javascript to C++ > converter is not what we're looking for but it helps me understand these > cases better. > > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Tue Jul 11 12:36:02 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 11 Jul 2017 13:36:02 +0300 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> Message-ID: <2357411499769362@web4g.yandex.ru> 10.07.2017, 21:56, "Phil Bouchard" : > Phil Bouchard wrote: >>  BTW converting Javascript into C++ seems very easy to do > > In fact, is it me or it would seem that: > - converting the Javascript code into C++ on-the-fly > - compiling the resulting C++ code This approach would have abysmal performance > > Would be a more efficient alternative than all these JIT tools? Not at all > > My 2 cents, > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From Simon.Hausmann at qt.io Tue Jul 11 13:25:21 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Jul 2017 11:25:21 +0000 Subject: [Development] Nominating Viktor Engelmann for Approver Status Message-ID: Hi, I'd like to propose Viktor for approver status. Since August last year he's been contributing to QtWebEngine full-time. Based on my experience talking to him and working with him, I trust him to review changes thoroughly and approve or reject changes responsively. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Tue Jul 11 13:27:47 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 11 Jul 2017 12:27:47 +0100 Subject: [Development] Nominating Viktor Engelmann for Approver Status In-Reply-To: References: Message-ID: <0aea22aae16a7af573755fe6b424c4a3@kdab.com> On 2017-07-11 12:25, Simon Hausmann wrote: > Hi, > > I'd like to propose Viktor for approver status. Since August last year > he's been contributing to QtWebEngine full-time. Based on my > experience talking to him and working with him, I trust him to review > changes thoroughly and approve or reject changes responsively. Thought he was already +1 Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From philippeb8 at gmail.com Tue Jul 11 13:49:05 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 11 Jul 2017 07:49:05 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: On 07/11/2017 04:02 AM, Tim Blechmann wrote: >> On the other hand, I have good news as I think I have found a way to >> simulate functions that return a function. > > how to you cope with structures like: > > function foo( outObject ) > { > var object = {} > outObject.object = object > outObject.result = function() { return object } > return function() { return bar( object ) } > } I'm looking into stuff like that so I am mimicking a run-time stack in my example: https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp Meanwhile please define bar(); Thanks, -Phil From Simon.Hausmann at qt.io Tue Jul 11 13:58:20 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 11 Jul 2017 11:58:20 +0000 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> , Message-ID: bar shall be a global variable that is callable (i.e. somebody initialized it with a function closure). When invoked it shall return either a primitive value or a JavaScript object and takes one arbitrary parameter. It is an implementation detail whether it returns the parameter provided, or "42" (either as string or number :) and the behavior may change at run-time. So at the compilation time of this snippet, all we basically know is var bar; It could be that bar was initialized to "100", in which case I think an exception would be thrown at the attempt of calling it. Simon ________________________________ From: Development on behalf of Phil Bouchard Sent: Tuesday, July 11, 2017 1:49:05 PM To: development at qt-project.org Subject: Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr On 07/11/2017 04:02 AM, Tim Blechmann wrote: >> On the other hand, I have good news as I think I have found a way to >> simulate functions that return a function. > > how to you cope with structures like: > > function foo( outObject ) > { > var object = {} > outObject.object = object > outObject.result = function() { return object } > return function() { return bar( object ) } > } I'm looking into stuff like that so I am mimicking a run-time stack in my example: https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp Meanwhile please define bar(); Thanks, -Phil _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Tue Jul 11 14:00:19 2017 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 11 Jul 2017 14:00:19 +0200 Subject: [Development] Nominating Viktor Engelmann for Approver Status In-Reply-To: References: Message-ID: <20170711120016.czbki3ep2fring3v@hooch.localdomain> On Tue, Jul 11, 2017 at 11:25:21AM +0000, Simon Hausmann wrote: > I'd like to propose Viktor for approver status. Since August last year he's been contributing to QtWebEngine full-time. Based on my experience talking to him and working with him, I trust him to review changes thoroughly and approve or reject changes responsively. I'm "just" an occasional outside contributor, but a big +1 from me too :) Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From timur.pocheptsov at qt.io Tue Jul 11 14:06:46 2017 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Tue, 11 Jul 2017 12:06:46 +0000 Subject: [Development] Nominating Jesus Fernandez for Approver status Message-ID: I'd like to nominate Jesus Fernandez for Approver status. Among other things Jesus is the author and the maintainer of qtnetworkauth module, he is actively contributing to qtcore, qtnetwork, qtwebsockets, qsql, etc. He is also participating in the development of the WebGL QPA plugin. This is his Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22+status:merged,n,z Best regards, Timur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Jul 11 14:11:47 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 11 Jul 2017 12:11:47 +0000 Subject: [Development] Nominating Jesus Fernandez for Approver status In-Reply-To: References: Message-ID: Timur Pocheptsov (11 July 2017 14:06) > I'd like to nominate Jesus Fernandez for Approver status. +1 Full disclosure: Timur, Jesus and I are all in TQtC's Core & Network team. Eddy. From philippeb8 at gmail.com Tue Jul 11 14:44:34 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 11 Jul 2017 12:44:34 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> , Message-ID: Simon Hausmann wrote: > > bar shall be a global variable that is callable (i.e. somebody > initialized it with a function closure). When invoked it shall return > either a primitive value or a JavaScript object and takes one arbitrary parameter. > > > It is an implementation detail whether it returns the parameter provided, > or "42" (either as string or number :) and the behavior may change at run-time. > > > So at the compilation time of this snippet, all we basically know is > > > var bar; > > > It could be that bar was initialized to "100", in which case I think an > exception would be thrown at the attempt of calling it. > > > Simon > > ________________________________ > From: Development > on behalf of Phil Bouchard > > Sent: Tuesday, July 11, 2017 1:49:05 PM > To: development at qt-project.org > Subject: Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr > > On 07/11/2017 04:02 AM, Tim Blechmann wrote: >>> On the other hand, I have good news as I think I have found a way to >>> simulate functions that return a function. >> >> how to you cope with structures like: >> >> function foo( outObject ) >> { >> var object = {} >> outObject.object = object >> outObject.result = function() { return object } >> return function() { return bar( object ) } >> } > > I'm looking into stuff like that so I am mimicking a run-time stack in > my example: > https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp > > Meanwhile please define bar(); > > > Thanks, > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > --_000_VI1PR02MB10065F354A27556625565A498CAE0VI1PR02MB1006eurp_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > > > > > > >
>
>


>

>

bar shall be a global variable that is callable (i.e. somebody > initialized it with a function closure). When invoked it shall > return either a > primitive value or a JavaScript > object and takes one arbitrary > parameter.

>


>

>

It is an implementation detail whether it returns the parameter > provided, or "42" (either as string or number :) and the > behavior may change at run-time.

>


>

>

So at the compilation time of this snippet, all we basically know is

>


>

>

    var bar;

>


>

>

It could be that bar was initialized to "100", in which case > I think an exception would be thrown at the attempt of calling it.

>


>

>

Simon

>
>
>
color="#000000" style="font-size:11pt">From: Development > <development-bounces+simon.hausmann=qt.io at qt-project.org> on > behalf of Phil Bouchard <philippeb8 at gmail.com>
> Sent: Tuesday, July 11, 2017 1:49:05 PM
> To: development at qt-project.org
> Subject: Re: [Development] Qt 5.9's new garbage collector > documentation? + root_ptr
>
 
>
>
> >
On 07/11/2017 04:02 AM, Tim Blechmann wrote:
> >> On the other hand, I have good news as I think I have found a way to
> >> simulate functions that return a function.
> >
> > how to you cope with structures like:
> >
> > function foo( outObject )
> > {
> >     var object = {}
> >     outObject.object = object
> >     outObject.result = function() { return object }
> >     return function() { return bar( object ) }
> > }
>
> I'm looking into stuff like that so I am mimicking a run-time stack in
> my example:
> href="https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp">https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp
>
> Meanwhile please define bar();
>
>
> Thanks,
> -Phil
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> href="http://lists.qt-project.org/mailman/listinfo/development">http://lists.qt-project.org/mailman/listinfo/development
>
>
> > > > --_000_VI1PR02MB10065F354A27556625565A498CAE0VI1PR02MB1006eurp_-- Ok thanks. I'm confident it'll work. -Phil From paolo.angelelli at qt.io Tue Jul 11 16:35:04 2017 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Tue, 11 Jul 2017 16:35:04 +0200 Subject: [Development] Nominating Jesus Fernandez for Approver status In-Reply-To: References: Message-ID: <20170711163504.0077c959@qdesktop> +1 Awesome work on OAuth and WebGL! On Tue, 11 Jul 2017 12:06:46 +0000 Timur Pocheptsov wrote: > I'd like to nominate Jesus Fernandez for Approver status. Among other things Jesus is the author and the maintainer > > of qtnetworkauth module, he is actively contributing to qtcore, qtnetwork, qtwebsockets, qsql, etc. He is also > > participating in the development of the WebGL QPA plugin. > > > This is his Gerrit dashboard: > > > https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22+status:merged,n,z > > > Best regards, > > Timur. > From nils.jeisecke at saltation.com Tue Jul 11 17:20:23 2017 From: nils.jeisecke at saltation.com (Nils Jeisecke) Date: Tue, 11 Jul 2017 17:20:23 +0200 Subject: [Development] QtQuick transparent toplevel window broken in dev? Message-ID: <20170711152023.yma5cxspbptyjdzx@saltation.com> Hi list, while playing around with a recent build of dev (82bdc55bc36f8a785e2637b01cb91d361b01fc29), I've noticed that toplevel window transparency for QQuickWindow seems to have stopped working (at least on macOS, haven't tried Windows so far). Any "ApplicationWindow" with color: "transparent" should illustrate the problem but I simply tried the "pure qml" example from this stackoverflow entry: https://stackoverflow.com/questions/22554796/qtquick-2-transparent-window-background Window is transparent with 5.9 but opaque with dev. Setting QQuickWindow::setDefaultAlphaBuffer(true) before creating any window does not help and is not necessary on 5.9 anyway. Did some regression creep in? Nils From tor.arne.vestbo at qt.io Tue Jul 11 18:00:08 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Tue, 11 Jul 2017 18:00:08 +0200 Subject: [Development] QtQuick transparent toplevel window broken in dev? In-Reply-To: <20170711152023.yma5cxspbptyjdzx@saltation.com> References: <20170711152023.yma5cxspbptyjdzx@saltation.com> Message-ID: <030e3193-3fb3-c52b-70c0-6cbecccf5102@qt.io> Please file a bug report, thanks On 11/07/2017 17:20, Nils Jeisecke via Development wrote: > Hi list, > > while playing around with a recent build of dev > (82bdc55bc36f8a785e2637b01cb91d361b01fc29), I've noticed that toplevel > window transparency for QQuickWindow seems to have stopped working (at > least on macOS, haven't tried Windows so far). > > Any "ApplicationWindow" with color: "transparent" should illustrate the > problem but I simply tried the "pure qml" example from this > stackoverflow entry: > > https://stackoverflow.com/questions/22554796/qtquick-2-transparent-window-background > > Window is transparent with 5.9 but opaque with dev. > > Setting QQuickWindow::setDefaultAlphaBuffer(true) before creating any > window does not help and is not necessary on 5.9 anyway. > > Did some regression creep in? > > Nils > From sahumada at texla.cl Tue Jul 11 20:17:21 2017 From: sahumada at texla.cl (Sergio Ahumada) Date: Tue, 11 Jul 2017 20:17:21 +0200 Subject: [Development] Nominating Jesus Fernandez for Approver status In-Reply-To: References: Message-ID: <86ff5dff-130c-0a41-f4c0-c0c1ec1dcb60@texla.cl> On 11.07.2017 14:06, Timur Pocheptsov wrote: > I'd like to nominate Jesus Fernandez for Approver status. Among other > things Jesus is the author and the maintainer > > of qtnetworkauth module, he is actively contributing to qtcore, > qtnetwork, qtwebsockets, qsql, etc. He is also > > participating in the development of the WebGL QPA plugin. > > > This is his Gerrit dashboard: > > > https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22+status:merged,n,z > > > Best regards, > > Timur. Seems like somebody just forgot to add him to https://codereview.qt-project.org/#/admin/groups/13,members since he is a (sub?)maintainer already I don't think he has to go through this process, does he? http://lists.qt-project.org/pipermail/development/2016-October/027521.html https://wiki.qt.io/Maintainers -- Sergio Ahumada sahumada at texla.cl From marc.mutz at kdab.com Tue Jul 11 23:13:16 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 11 Jul 2017 23:13:16 +0200 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: Message-ID: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> On 2017-07-08 00:39, Matteo wrote: > Hi all, > > I just finished the first preview of my QAESEncryption class and I > would like to have some opinions on possible improvements, issues etc. > > https://github.com/bricke/Qt-AES [1] > > This is still a work in progress but I feel it's good enough to be > shared and I am ready to take the heat! Don't implement the cipher yourself. Wrap an existing, widely-used and audited crypto library instead. Thanks, Marc From rich at kde.org Tue Jul 11 23:37:14 2017 From: rich at kde.org (Richard Moore) Date: Tue, 11 Jul 2017 22:37:14 +0100 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> References: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> Message-ID: On 11 July 2017 at 22:13, Marc Mutz wrote: > On 2017-07-08 00:39, Matteo wrote: > >> Hi all, >> >> I just finished the first preview of my QAESEncryption class and I >> would like to have some opinions on possible improvements, issues etc. >> >> https://github.com/bricke/Qt-AES [1] >> >> This is still a work in progress but I feel it's good enough to be >> shared and I am ready to take the heat! >> > > Don't implement the cipher yourself. Wrap an existing, widely-used and > audited crypto library instead. > ​I'm with Marc. I'd also add that anything that uses crypto and directly references a specific cipher is designed wrong. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.brichese at gmail.com Wed Jul 12 00:05:39 2017 From: matteo.brichese at gmail.com (Matteo) Date: Tue, 11 Jul 2017 22:05:39 +0000 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> References: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> Message-ID: Noted. My point was not to use openssl or external libs, i understand the security issue of something that is not certified and audited. Thank you On Tue, Jul 11, 2017 at 14:19 Marc Mutz wrote: > On 2017-07-08 00:39, Matteo wrote: > > Hi all, > > > > I just finished the first preview of my QAESEncryption class and I > > would like to have some opinions on possible improvements, issues etc. > > > > https://github.com/bricke/Qt-AES [1] > > > > This is still a work in progress but I feel it's good enough to be > > shared and I am ready to take the heat! > > Don't implement the cipher yourself. Wrap an existing, widely-used and > audited crypto library instead. > > Thanks, > Marc > > -- Sent from iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Wed Jul 12 04:49:41 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 11 Jul 2017 22:49:41 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: On 07/11/2017 04:02 AM, Tim Blechmann wrote: >> On the other hand, I have good news as I think I have found a way to >> simulate functions that return a function. > > how to you cope with structures like: > > function foo( outObject ) > { > var object = {} > outObject.object = object > outObject.result = function() { return object } > return function() { return bar( object ) } > } I just manually wrote an emulation of Javascript code in C++ here: https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp And I have the following output: int main(): BEGIN main()::__lambda1 main()::__lambda1::__lambda3 main()::__lambda0 int main(): END Note that I just realized it's impossible the variable lookups in Javascript are instantaneous and it must be done the way it's done in my example because it's all run-time in the Javascript engine. Thanks, -Phil From philippeb8 at gmail.com Wed Jul 12 04:59:57 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 11 Jul 2017 22:59:57 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <2357411499769362@web4g.yandex.ru> References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> Message-ID: On 07/11/2017 06:36 AM, Konstantin Tokarev wrote: > > > 10.07.2017, 21:56, "Phil Bouchard" : >> Phil Bouchard wrote: >>> BTW converting Javascript into C++ seems very easy to do >> >> In fact, is it me or it would seem that: >> - converting the Javascript code into C++ on-the-fly >> - compiling the resulting C++ code > > This approach would have abysmal performance > >> >> Would be a more efficient alternative than all these JIT tools? > > Not at all Maybe we can benchmark all this stuff once I'm done... just out of curiosity. -Phil From devel at g76r.eu Wed Jul 12 11:24:02 2017 From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=) Date: Wed, 12 Jul 2017 11:24:02 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: Le 11/07/2017 à 13:49, Phil Bouchard a écrit : > On 07/11/2017 04:02 AM, Tim Blechmann wrote: >>> On the other hand, I have good news as I think I have found a way to >>> simulate functions that return a function. >> >> how to you cope with structures like: >> >> function foo( outObject ) >> { >> var object = {} >> outObject.object = object >> outObject.result = function() { return object } >> return function() { return bar( object ) } >> } > > I'm looking into stuff like that so I am mimicking a run-time stack in > my example: > https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp > > > Meanwhile please define bar(); IMHO it become especially interesting in terms of root_ptr if bar is a function which: - stores object in a global variable, - or affect it as property values to several different QML items with different lifecycles, - or even send it to C++ through a signal the slot being able of calling QQmlEngine::setObjectOwnership() if it wants, or add the object as a global variable from C++ using, for instance QJSEngine::globalObject().setProperty(). Regards. -- Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49 From Sudhir.Sharma at mindtree.com Wed Jul 12 12:17:38 2017 From: Sudhir.Sharma at mindtree.com (Sudhir Sharma) Date: Wed, 12 Jul 2017 10:17:38 +0000 Subject: [Development] QT 5.9. Issues with QWebEngine Message-ID: HI, QWebEngine does not take exact proxy settings from System (as done in internet browsers like Chrome) Internet client is configured to use proxy for internet addresses and bypass it for local addresses. But it does not happen. QWebEngine fails to bypass proxy for local urls. Scenarios: - Remove proxy in Browser. -> webengine is able to load local urls but NOT internet URLs - Add proxy in browser -> webengine is able to load internet URLs but NOT local URLs - If I set the proxy in browser and check to ignore local addresses, browser works fine for both local and internet addresses. I am expecting same functionality from QWebEngine. Please suggest if it is possible. Regarsds, Sudhir ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Wed Jul 12 13:07:20 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 12 Jul 2017 11:07:20 +0000 Subject: [Development] QT 5.9. Issues with QWebEngine In-Reply-To: References: Message-ID: Hi Sudhir, This is best discussed on bugreports.qt.io, in a bug report for component "WebEngine" in project "Qt". Please include on how you want to set a (non-local) proxy: - through the system settings or - through QNetworkProxy::applicationProxy Regards Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Sudhir Sharma > Sent: Mittwoch, 12. Juli 2017 12:18 > To: development at qt-project.org > Subject: [Development] QT 5.9. Issues with QWebEngine > > HI, > > > > QWebEngine does not take exact proxy settings from System (as done in > internet browsers like Chrome) > > Internet client is configured to use proxy for internet addresses and bypass it > for local addresses. > > > > But it does not happen. QWebEngine fails to bypass proxy for local urls. > > > > Scenarios: > > > > - Remove proxy in Browser. -> webengine is able to load local urls but > NOT internet URLs > > - Add proxy in browser -> webengine is able to load internet URLs but > NOT local URLs > > - If I set the proxy in browser and check to ignore local addresses, > browser works fine for both local and internet addresses. I am expecting > same functionality from QWebEngine. > > > > Please suggest if it is possible. > > > > Regarsds, > > Sudhir > > > > > > > ________________________________ > > > http://www.mindtree.com/email/disclaimer.html From Sudhir.Sharma at mindtree.com Wed Jul 12 13:26:43 2017 From: Sudhir.Sharma at mindtree.com (Sudhir Sharma) Date: Wed, 12 Jul 2017 11:26:43 +0000 Subject: [Development] QT 5.9. Issues with QWebEngine In-Reply-To: References: Message-ID: Hi Kai, Thanks for your prompt response. Before loading any URL In QWebEngine, I am making it use System Proxy Configuration by following code; QNetworkProxyFactory::setUseSystemConfiguration(true); After this if I query the proxy, I get correct proxy address which is configured in Web Browser. But with this setting I cannot load local URLs in QWebEngine. Regards, Sudhir -----Original Message----- From: Kai Koehne [mailto:Kai.Koehne at qt.io] Sent: Wednesday, July 12, 2017 4:37 PM To: Sudhir Sharma ; development at qt-project.org Subject: RE: QT 5.9. Issues with QWebEngine * You are receiving this mail from an external source * Hi Sudhir, This is best discussed on bugreports.qt.io, in a bug report for component "WebEngine" in project "Qt". Please include on how you want to set a (non-local) proxy: - through the system settings or - through QNetworkProxy::applicationProxy Regards Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Sudhir Sharma > Sent: Mittwoch, 12. Juli 2017 12:18 > To: development at qt-project.org > Subject: [Development] QT 5.9. Issues with QWebEngine > > HI, > > > > QWebEngine does not take exact proxy settings from System (as done in > internet browsers like Chrome) > > Internet client is configured to use proxy for internet addresses and > bypass it for local addresses. > > > > But it does not happen. QWebEngine fails to bypass proxy for local urls. > > > > Scenarios: > > > > - Remove proxy in Browser. -> webengine is able to load local urls but > NOT internet URLs > > - Add proxy in browser -> webengine is able to load internet URLs but > NOT local URLs > > - If I set the proxy in browser and check to ignore local addresses, > browser works fine for both local and internet addresses. I am > expecting same functionality from QWebEngine. > > > > Please suggest if it is possible. > > > > Regarsds, > > Sudhir > > > > > > > ________________________________ > > > http://www.mindtree.com/email/disclaimer.html From marc.mutz at kdab.com Wed Jul 12 13:43:48 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 12 Jul 2017 13:43:48 +0200 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> Message-ID: On 2017-07-12 00:05, Matteo wrote: [...] > My point was not to use openssl or external libs, i understand the > security issue of something that is not certified and audited. [...] Good to know. Now you "just" need to make sure *all* your potential users understand this, too. Which brings me to the question: who, exactly, is the target audience for a non-proven, non-audited, non-certified, AES-only, Qt-using implementation? Thanks, Marc From thiago.macieira at intel.com Wed Jul 12 16:48:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 07:48:44 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: Message-ID: <2588382.aj2fVTiQsP@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 04:43:48 PDT Marc Mutz wrote: > On 2017-07-12 00:05, Matteo wrote: > [...] > > > My point was not to use openssl or external libs, i understand the > > security issue of something that is not certified and audited. > > [...] > > Good to know. Now you "just" need to make sure *all* your potential > users understand this, too. Which brings me to the question: who, > exactly, is the target audience for a non-proven, non-audited, > non-certified, AES-only, Qt-using implementation? And when are you going to add support for hardware-accelerated AES? And after you do, what value does your library have on top of the 4 processor instructions? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From matteo.brichese at gmail.com Wed Jul 12 16:52:20 2017 From: matteo.brichese at gmail.com (Matteo) Date: Wed, 12 Jul 2017 07:52:20 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> Message-ID: At the beginning this was for my own personal use as I was in need of some sort of encryption for a work project without using openssl, then I just released the code for the class on github, it's more a code exercise than a real usable class for the issues you pointed out. On Wed, Jul 12, 2017 at 4:43 AM, Marc Mutz wrote: > On 2017-07-12 00:05, Matteo wrote: > [...] > >> My point was not to use openssl or external libs, i understand the >> security issue of something that is not certified and audited. >> > [...] > > Good to know. Now you "just" need to make sure *all* your potential users > understand this, too. Which brings me to the question: who, exactly, is the > target audience for a non-proven, non-audited, non-certified, AES-only, > Qt-using implementation? > > Thanks, > Marc > > -- Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Wed Jul 12 16:58:52 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 14:58:52 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: Phil Bouchard wrote: > On 07/11/2017 04:02 AM, Tim Blechmann wrote: >>> On the other hand, I have good news as I think I have found a way to >>> simulate functions that return a function. >> >> how to you cope with structures like: >> >> function foo( outObject ) >> { >> var object = {} >> outObject.object = object >> outObject.result = function() { return object } >> return function() { return bar( object ) } >> } > > I just manually wrote an emulation of Javascript code in C++ here: > https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp I'll do some code cleanup tonight; it'll be much more readable regarding return values. From prashantpurohit025 at gmail.com Wed Jul 12 18:15:15 2017 From: prashantpurohit025 at gmail.com (Prashant Purohit) Date: Wed, 12 Jul 2017 21:45:15 +0530 Subject: [Development] Drag and Drop Issue in Qt-5.3.2 with QML on QNX Platform only. Message-ID: Hi All, We have created one application where there are multiple icons present in a GridView. Each delegate of the grid is a composite control with an icon and text. (This is similar to phone apps screen on Android/iOS devices). Similar to apps screen on mobile devices, user can drag and drop icons across multiple pages of the gridview. Also, there are navigation buttons on the right and left side of the icons grid, when an icon is dragged on top of the navigation buttons, the page scrolls left OR right to display the corresponding grid view. The issue which we are facing is that while dragging an icon across multiple pages(most of the times), the icon being dragged gets stuck and does not get dropped or user sees a screen freeze for dragged icon but rest of the functionality like mouse click or page change works fine. Initially, we could duplicate this issue almost always and found one solution by increasing the cacheBuffer for GridView. Current value for cacheBuffer is 100000. Above fix has reduced the occurrence of this issue but still issue is reproducing after couple of repeated trials. Hence, this issue is not completely fixed. We are using QT 5.3.2 with QML on QNX. The point to note here is that when we tried same code on Linux machine with QT-5.3.2, this issue does not occur. Is there any fix done for QT-QML-QNX related to this issue? We would really appreciate any inputs on this. Thanks, Prashant From thiago.macieira at intel.com Wed Jul 12 18:20:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 09:20:26 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: Message-ID: <2759523.9pgjLKbk9F@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote: > At the beginning this was for my own personal use as I was in need of some > sort of encryption for a work project without using openssl, then I just > released the code for the class on github, it's more a code exercise than a > real usable class for the issues you pointed out. Try this instead: https://github.com/01org/tinycrypt -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jul 12 18:22:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 09:22:26 -0700 Subject: [Development] Drag and Drop Issue in Qt-5.3.2 with QML on QNX Platform only. In-Reply-To: References: Message-ID: <1940222.KfrGyDWhb6@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 09:15:15 PDT Prashant Purohit wrote: > We are using QT 5.3.2 with QML on QNX. > > The point to note here is that when we tried same code on Linux > machine with QT-5.3.2, this issue does not occur. > > Is there any fix done for QT-QML-QNX related to this issue? This is the development mailing (for development *of* Qt). Please install Qt 5.9 and try again. If it's fixed, then check 5.6. If both are fixed, case closed, nothing for us to do. If 5.9 is fixed and 5.6 isn't, then there may be a backport in order. If neither is fixed, then we need a testcase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Jul 12 18:26:52 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 12 Jul 2017 19:26:52 +0300 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: <2759523.9pgjLKbk9F@tjmaciei-mobl1> References: <2759523.9pgjLKbk9F@tjmaciei-mobl1> Message-ID: <1750551499876812@web15j.yandex.ru> 12.07.2017, 19:21, "Thiago Macieira" : > On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote: >>  At the beginning this was for my own personal use as I was in need of some >>  sort of encryption for a work project without using openssl, then I just >>  released the code for the class on github, it's more a code exercise than a >>  real usable class for the issues you pointed out. > > Try this instead: https://github.com/01org/tinycrypt Or https://github.com/libtom/libtomcrypt > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Jul 12 18:35:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 09:35:38 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: <1750551499876812@web15j.yandex.ru> References: <2759523.9pgjLKbk9F@tjmaciei-mobl1> <1750551499876812@web15j.yandex.ru> Message-ID: <4825154.sa8xa4iDqy@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 09:26:52 PDT Konstantin Tokarev wrote: > 12.07.2017, 19:21, "Thiago Macieira" : > > On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote: > >> At the beginning this was for my own personal use as I was in need of > >> some > >> sort of encryption for a work project without using openssl, then I just > >> released the code for the class on github, it's more a code exercise > >> than a real usable class for the issues you pointed out. > > > > Try this instead: https://github.com/01org/tinycrypt > > Or https://github.com/libtom/libtomcrypt How certified is it? The Intel implementation above is audited. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From matteo.brichese at gmail.com Wed Jul 12 18:40:17 2017 From: matteo.brichese at gmail.com (Matteo) Date: Wed, 12 Jul 2017 09:40:17 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> Message-ID: >From: Thiago Macieira >To: development at qt-project.org >Date: Wed, 12 Jul 2017 09:20:26 -0700 >Subject: Re: [Development] Qt-AES - Looking for comments >On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote: >> At the beginning this was for my own personal use as I was in need of some >> sort of encryption for a work project without using openssl, then I just >> released the code for the class on github, it's more a code exercise than a >> real usable class for the issues you pointed out. > >Try this instead: https://github.com/01org/tinycrypt Thank you, I am watching it. >>And when are you going to add support for hardware-accelerated AES? And after >>you do, what value does your library have on top of the 4 processor >>instructions? You mean using the AES-NI instructions? The tinycrypt project you show me does not look like they are using any special instructions to be hardware accelerated, or am I missing something? Thank you -- Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Jul 12 18:49:08 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 12 Jul 2017 19:49:08 +0300 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: <4825154.sa8xa4iDqy@tjmaciei-mobl1> References: <2759523.9pgjLKbk9F@tjmaciei-mobl1> <1750551499876812@web15j.yandex.ru> <4825154.sa8xa4iDqy@tjmaciei-mobl1> Message-ID: <1791541499878148@web15j.yandex.ru> 12.07.2017, 19:36, "Thiago Macieira" : > On quarta-feira, 12 de julho de 2017 09:26:52 PDT Konstantin Tokarev wrote: >>  12.07.2017, 19:21, "Thiago Macieira" : >>  > On quarta-feira, 12 de julho de 2017 07:52:20 PDT Matteo wrote: >>  >> At the beginning this was for my own personal use as I was in need of >>  >> some >>  >> sort of encryption for a work project without using openssl, then I just >>  >> released the code for the class on github, it's more a code exercise >>  >> than a real usable class for the issues you pointed out. >>  > >>  > Try this instead: https://github.com/01org/tinycrypt >> >>  Or https://github.com/libtom/libtomcrypt > > How certified is it? > > The Intel implementation above is audited. I don't know, but it's widely used as a part of Dropbear, which is the most popular SSH client and server implementation for embedded systems. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Jul 12 19:59:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 10:59:30 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: Message-ID: <3678580.uP22cZt59p@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 09:40:17 PDT Matteo wrote: > >>you do, what value does your library have on top of the 4 processor > >>instructions? > > You mean using the AES-NI instructions? Yes, for x86. I think ARM has them too. > The tinycrypt project you show me does not look like they are using any > special instructions to be hardware accelerated, or am I missing something? You're not. TinyCrypt was designed for Intel MCUs. Those don't have SSE registers, so they can't have AES-NI. So no one felt the need to add support. Could be as simple as a pull request, though. The maintainer sits a couple of rows from me, if necessary. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Wed Jul 12 21:34:35 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 19:34:35 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> Message-ID: Phil Bouchard wrote: > On 07/11/2017 06:36 AM, Konstantin Tokarev wrote: >> >> >> 10.07.2017, 21:56, "Phil Bouchard" : >>> Phil Bouchard wrote: >>>> BTW converting Javascript into C++ seems very easy to do >>> >>> In fact, is it me or it would seem that: >>> - converting the Javascript code into C++ on-the-fly >>> - compiling the resulting C++ code >> >> This approach would have abysmal performance >> >>> >>> Would be a more efficient alternative than all these JIT tools? >> >> Not at all > > Maybe we can benchmark all this stuff once I'm done... just out of > curiosity. Actually I just did a benchmark of my "js2cpp" tool and interpreting the code using Node.JS and js2cpp generates an executable that is 34 times faster! I don't know about you but a minimalist version of g++ embedded inside the browser could be beneficial big time. -Phil From annulen at yandex.ru Wed Jul 12 22:56:55 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 12 Jul 2017 23:56:55 +0300 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> Message-ID: <2015401499893015@web18o.yandex.ru> 12.07.2017, 22:35, "Phil Bouchard" : > Phil Bouchard wrote: >>  On 07/11/2017 06:36 AM, Konstantin Tokarev wrote: >>>  10.07.2017, 21:56, "Phil Bouchard" : >>>>  Phil Bouchard wrote: >>>>>  BTW converting Javascript into C++ seems very easy to do >>>> >>>>  In fact, is it me or it would seem that: >>>>  - converting the Javascript code into C++ on-the-fly >>>>  - compiling the resulting C++ code >>> >>>  This approach would have abysmal performance >>> >>>>  Would be a more efficient alternative than all these JIT tools? >>> >>>  Not at all >> >>  Maybe we can benchmark all this stuff once I'm done... just out of >>  curiosity. > > Actually I just did a benchmark of my "js2cpp" tool and interpreting the > code using Node.JS and js2cpp generates an executable that is 34 times > faster! Now add time of compilation to the sum > > I don't know about you but a minimalist version of g++ embedded inside the > browser could be beneficial big time. > > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From matteo.brichese at gmail.com Wed Jul 12 23:02:24 2017 From: matteo.brichese at gmail.com (Matteo) Date: Wed, 12 Jul 2017 14:02:24 -0700 Subject: [Development] Qt-AES - Looking for comments In-Reply-To: References: <1a41cb6cc9d96aa6b90d8d2aeee1b857@kdab.com> Message-ID: >From: Thiago Macieira >Date: Wed, 12 Jul 2017 10:59:30 -0700 >Subject: Re: [Development] Qt-AES - Looking for comments >On quarta-feira, 12 de julho de 2017 09:40:17 PDT Matteo wrote: >> >>you do, what value does your library have on top of the 4 processor >> >>instructions? >> >> You mean using the AES-NI instructions? > >Yes, for x86. I think ARM has them too. > >> The tinycrypt project you show me does not look like they are using any >> special instructions to be hardware accelerated, or am I missing something? > >You're not. TinyCrypt was designed for Intel MCUs. Those don't have SSE >registers, so they can't have AES-NI. So no one felt the need to add support. > >Could be as simple as a pull request, though. The maintainer sits a couple of >rows from me, if necessary. I'll definitely take a look at AES-NI. Thank you! -- Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Thu Jul 13 01:25:08 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 19:25:08 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <2015401499893015@web18o.yandex.ru> References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> <2015401499893015@web18o.yandex.ru> Message-ID: On 07/12/2017 04:56 PM, Konstantin Tokarev wrote: > > > 12.07.2017, 22:35, "Phil Bouchard" : >> Phil Bouchard wrote: >>> On 07/11/2017 06:36 AM, Konstantin Tokarev wrote: >>>> 10.07.2017, 21:56, "Phil Bouchard" : >>>>> Phil Bouchard wrote: >>>>>> BTW converting Javascript into C++ seems very easy to do >>>>> >>>>> In fact, is it me or it would seem that: >>>>> - converting the Javascript code into C++ on-the-fly >>>>> - compiling the resulting C++ code >>>> >>>> This approach would have abysmal performance >>>> >>>>> Would be a more efficient alternative than all these JIT tools? >>>> >>>> Not at all >>> >>> Maybe we can benchmark all this stuff once I'm done... just out of >>> curiosity. >> >> Actually I just did a benchmark of my "js2cpp" tool and interpreting the >> code using Node.JS and js2cpp generates an executable that is 34 times >> faster! > > Now add time of compilation to the sum So I just did benchmark the following C++ file featuring a loop within the code (the loop was at the bash shell level previously): https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp With the exact equivalent in Javascript: https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js And the executable generated by g++ is still 1.7 times faster than by using Node.JS. For small Javascript perhaps the net speed are the same but the more complex the code is then the generated binary by g++ simply is faster when compared to the Node.JS interpreter. Thanks, -Phil From philippeb8 at gmail.com Thu Jul 13 01:28:34 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 19:28:34 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <23075004.L1XjGcIccQ@tjmaciei-mobl1> Message-ID: On 07/12/2017 10:58 AM, Phil Bouchard wrote: > Phil Bouchard wrote: >> On 07/11/2017 04:02 AM, Tim Blechmann wrote: >>>> On the other hand, I have good news as I think I have found a way to >>>> simulate functions that return a function. >>> >>> how to you cope with structures like: >>> >>> function foo( outObject ) >>> { >>> var object = {} >>> outObject.object = object >>> outObject.result = function() { return object } >>> return function() { return bar( object ) } >>> } >> >> I just manually wrote an emulation of Javascript code in C++ here: >> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp > > I'll do some code cleanup tonight; it'll be much more readable regarding > return values. The code is much more readable now: https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp From philippeb8 at gmail.com Thu Jul 13 01:38:30 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 19:38:30 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> <2015401499893015@web18o.yandex.ru> Message-ID: On 07/12/2017 07:25 PM, Phil Bouchard wrote: > On 07/12/2017 04:56 PM, Konstantin Tokarev wrote: >> >> Now add time of compilation to the sum > > So I just did benchmark the following C++ file featuring a loop within > the code (the loop was at the bash shell level previously): > https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp > > > With the exact equivalent in Javascript: > https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js > > > And the executable generated by g++ is still 1.7 times faster than by > using Node.JS. For small Javascript perhaps the net speed are the same > but the more complex the code is then the generated binary by g++ simply > is faster when compared to the Node.JS interpreter. The browser should "cache" these temporary executables anyway. From fromqt at tungware.se Thu Jul 13 03:08:14 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Thu, 13 Jul 2017 03:08:14 +0200 Subject: [Development] A taste of the future: declaring QLists without <> Message-ID: <13e6c7e8-a3a5-c0fb-ae83-e8774ba1e999@tungware.se> Hi, reading about the new C++17 standard, I decided to test some Qt code: ... QList li = {7,8,4,2,5,4,3}; QList ll = {5,3,34,5,44}; qDebug() << li; qDebug() << ll; ... The normal g++ 5.4 on vanilla Qt 5.9.1 on my Ubuntu 16.04 returns: "home/henry/test/mainwindow.cpp:13: error: missing template arguments before ‘ll’ QList ll = {5,3,34,5,44}; ^ Upgraded gcc to g++ 6. Same error. But finding this ppa: https://launchpad.net/~jonathonf/+archive/ubuntu/gcc-7.1 I've managed to upgrade to the spanking new g++ 7.1, and voila, no sour grapes from the compiler (i.e the 2 qDebug() statements above returned both their proper lists). Nice! Rgrds Henry From thiago.macieira at intel.com Thu Jul 13 04:28:18 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 19:28:18 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: Message-ID: <2978415.3vsTAvGbRd@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote: > I don't know about you but a minimalist version of g++ embedded inside the > browser could be beneficial big time. Such a thing exists, it's called JIT. There's also a tool to precompile a QML file. You should compare to that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Thu Jul 13 05:32:56 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 23:32:56 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> <2015401499893015@web18o.yandex.ru> Message-ID: On 07/12/2017 07:25 PM, Phil Bouchard wrote: > > And the executable generated by g++ is still 1.7 times faster than by > using Node.JS. Make that 1.8 times faster when using a main precompiled header. From philippeb8 at gmail.com Thu Jul 13 05:54:54 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 12 Jul 2017 23:54:54 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <2978415.3vsTAvGbRd@tjmaciei-mobl1> References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: On 07/12/2017 10:28 PM, Thiago Macieira wrote: > On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote: >> I don't know about you but a minimalist version of g++ embedded inside the >> browser could be beneficial big time. > > Such a thing exists, it's called JIT. I was reading the Wiki page: https://en.wikipedia.org/wiki/Just-in-time_compilation And it says: "thus in theory JIT compilation can yield faster execution than static compilation" But in practice a g++ compilation sequence followed by execution still is 1.8 times faster in the aforementioned test. Maybe if you have pieces of code that are never executed then JIT would have a lead but serious/game engines for example stresses 100% of the code as far as I know. The problem with JIT is its support also. You need an army of coders to support the conversion from bytecode to assembly language, updates, etc. Anyway I'm deviating from QNodePtr but I just don't understand the hype about JIT when it doesn't seem it has been compared to a Javascript compiler because none exists up to now. > There's also a tool to precompile a QML file. You should compare to that. I know QML files can be compiled but I think the Qt Quick Compiler is being replaced by something else right now. I'll have to investigate. -Phil From thiago.macieira at intel.com Thu Jul 13 06:13:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Jul 2017 21:13:38 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: <1618690.ERr686ZSZa@tjmaciei-mobl1> On quarta-feira, 12 de julho de 2017 20:54:54 PDT Phil Bouchard wrote: > On 07/12/2017 10:28 PM, Thiago Macieira wrote: > > On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote: > >> I don't know about you but a minimalist version of g++ embedded inside > >> the > >> browser could be beneficial big time. > > > > Such a thing exists, it's called JIT. > > I was reading the Wiki page: > https://en.wikipedia.org/wiki/Just-in-time_compilation > > And it says: > "thus in theory JIT compilation can yield faster execution than static > compilation" > > But in practice a g++ compilation sequence followed by execution still > is 1.8 times faster in the aforementioned test. Maybe if you have > pieces of code that are never executed then JIT would have a lead but > serious/game engines for example stresses 100% of the code as far as I know. That's not a fair comparison. First of all, the quote from Wikipedia is saying "in theory". That's because the JIT can actually optimise based on actual execution, the same way that PGO can do it. Second, you're comparing one case. Third, only 1.8 times faster? That's actually a very impressive JIT. I'd have expected a much worse number. > The problem with JIT is its support also. You need an army of coders to > support the conversion from bytecode to assembly language, updates, etc. The same can be said about the compiler. In the past year, there have been 7700 commis by 164 different people in the GCC repository. This does not include binutils. > Anyway I'm deviating from QNodePtr but I just don't understand the hype > about JIT when it doesn't seem it has been compared to a Javascript > compiler because none exists up to now. JavaScript can't be entirely compiled since the types and behaviours of variables can change at runtime. And then there's the "eval" command. > > There's also a tool to precompile a QML file. You should compare to that. > > I know QML files can be compiled but I think the Qt Quick Compiler is > being replaced by something else right now. I'll have to investigate. It's not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Thu Jul 13 06:25:49 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 00:25:49 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <1618690.ERr686ZSZa@tjmaciei-mobl1> References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> <1618690.ERr686ZSZa@tjmaciei-mobl1> Message-ID: On 07/13/2017 12:13 AM, Thiago Macieira wrote: > > Third, only 1.8 times faster? That's actually a very impressive JIT. I'd have > expected a much worse number. Yes but the longer the loop lasts in the example, the greater the difference is between the executable and Node.JS. The "speed slope" is more inclined in the case of the executable. But if my browser is always 1.8 faster (2.2 faster when using cache) I personally would take it. -Phil From annulen at yandex.ru Thu Jul 13 10:09:18 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Jul 2017 11:09:18 +0300 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> <2015401499893015@web18o.yandex.ru> Message-ID: <3263561499933358@web47g.yandex.ru> 13.07.2017, 02:39, "Phil Bouchard" : > On 07/12/2017 07:25 PM, Phil Bouchard wrote: >>  On 07/12/2017 04:56 PM, Konstantin Tokarev wrote: >>>  Now add time of compilation to the sum >> >>  So I just did benchmark the following C++ file featuring a loop within >>  the code (the loop was at the bash shell level previously): >>  https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp >> >>  With the exact equivalent in Javascript: >>  https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js >> >>  And the executable generated by g++ is still 1.7 times faster than by >>  using Node.JS. For small Javascript perhaps the net speed are the same >>  but the more complex the code is then the generated binary by g++ simply >>  is faster when compared to the Node.JS interpreter. > > The browser should "cache" these temporary executables anyway. A you were following development of WebKit and JavaScriptCore, you should be aware of story of using LLVM (i.e. "real" compiler) as a final JIT tier, and how did it end up. https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From philippeb8 at gmail.com Thu Jul 13 13:44:08 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 07:44:08 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <3263561499933358@web47g.yandex.ru> References: <1804908.vqGIHUMFJM@tjmaciei-mobl1> <2357411499769362@web4g.yandex.ru> <2015401499893015@web18o.yandex.ru> <3263561499933358@web47g.yandex.ru> Message-ID: On 07/13/2017 04:09 AM, Konstantin Tokarev wrote: > > > 13.07.2017, 02:39, "Phil Bouchard" : >> On 07/12/2017 07:25 PM, Phil Bouchard wrote: >>> On 07/12/2017 04:56 PM, Konstantin Tokarev wrote: >>>> Now add time of compilation to the sum >>> >>> So I just did benchmark the following C++ file featuring a loop within >>> the code (the loop was at the bash shell level previously): >>> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.cpp >>> >>> With the exact equivalent in Javascript: >>> https://github.com/philippeb8/root_ptr/blob/qt/example/javascript_example1.js >>> >>> And the executable generated by g++ is still 1.7 times faster than by >>> using Node.JS. For small Javascript perhaps the net speed are the same >>> but the more complex the code is then the generated binary by g++ simply >>> is faster when compared to the Node.JS interpreter. >> >> The browser should "cache" these temporary executables anyway. > > A you were following development of WebKit and JavaScriptCore, you should be > aware of story of using LLVM (i.e. "real" compiler) as a final JIT tier, and how did it > end up. > > https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ Thanks I'll read that today but also I forgot to mention "if" we were using a converter followed by a compiler then we could mix the two languages which in turns could take advantage of high performance when necessary (C++) and higher level algorithms (Javascript). -Phil From iamsergio at gmail.com Thu Jul 13 14:11:34 2017 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Thu, 13 Jul 2017 13:11:34 +0100 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard wrote: > Anyway I'm deviating from QNodePtr but I just don't understand the hype > about JIT when it doesn't seem it has been compared to a Javascript compiler > because none exists up to now. That's precisely the biggest advantage of JIT: It exists, while js2cpp doesn't (or at least in a usable form for us). The problem is that JavaScript is a "do whatever you want" type of language, which doesn't translate well to C++. Regards, Sergio Martins From philippeb8 at gmail.com Thu Jul 13 14:33:47 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 12:33:47 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: Sérgio Martins wrote: > On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard wrote: >> Anyway I'm deviating from QNodePtr but I just don't understand the hype >> about JIT when it doesn't seem it has been compared to a Javascript compiler >> because none exists up to now. > > That's precisely the biggest advantage of JIT: It exists, while js2cpp > doesn't (or at least in a usable form for us). I'm working on it; it shouldn't take too long. > The problem is that JavaScript is a "do whatever you want" type of > language, which doesn't translate well to C++. The net speed makes all the difference between who gets chosen amongst Qt / Blink / WebKit / WPE. From devel at g76r.eu Thu Jul 13 16:32:19 2017 From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=) Date: Thu, 13 Jul 2017 16:32:19 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: Le 13/07/2017 à 14:33, Phil Bouchard a écrit : > Sérgio Martins wrote: >> On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard wrote: >>> Anyway I'm deviating from QNodePtr but I just don't understand the hype >>> about JIT when it doesn't seem it has been compared to a Javascript compiler >>> because none exists up to now. >> >> That's precisely the biggest advantage of JIT: It exists, while js2cpp >> doesn't (or at least in a usable form for us). > > I'm working on it; it shouldn't take too long. <3 « I have discovered a truly marvelous proof of this, which this margin is too narrow to contain. » Pierre de Fermat, 1637 A.D. Took 356 years to be proven actually. Anyway compiling JS to C++ was not your first goal if I undestand well. Maybe getting rid of GC is possible without compiling JS. And it may be interesting for compiled languages that do use a GC to, like C# or Java. Regards. -- Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49 From kde at carewolf.com Thu Jul 13 17:07:47 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 13 Jul 2017 17:07:47 +0200 Subject: [Development] Nominating Viktor Engelmann for Approver Status In-Reply-To: References: Message-ID: <2303742.bGZYL5T7kA@twilight> On Dienstag, 11. Juli 2017 13:25:21 CEST Simon Hausmann wrote: > Hi, > > > I'd like to propose Viktor for approver status. Since August last year he's > been contributing to QtWebEngine full-time. Based on my experience talking > to him and working with him, I trust him to review changes thoroughly and > approve or reject changes responsively. > +1 :) ' Allan From philippeb8 at gmail.com Thu Jul 13 17:22:55 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 15:22:55 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: Grégoire Barbier wrote: > Le 13/07/2017 à 14:33, Phil Bouchard a écrit : > Sérgio Martins wrote: >> On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard wrote: >>> Anyway I'm deviating from QNodePtr but I just don't understand the hype >>> about JIT when it doesn't seem it has been compared to a Javascript compiler >>> because none exists up to now. >> >> That's precisely the biggest advantage of JIT: It exists, while js2cpp >> doesn't (or at least in a usable form for us). > > I'm working on it; it shouldn't take too long. <3 « I have discovered a truly marvelous proof of this, which this margin is too narrow to contain. » Pierre de Fermat, 1637 A.D. Took 356 years to be proven actually. Anyway compiling JS to C++ was not your first goal if I undestand well. Maybe getting rid of GC is possible without compiling JS. And it may be interesting for compiled languages that do use a GC to, like C# or Java. Regards. -- Grégoire Barbier :: g à g76r.eu :: +33 6 21 35 73 49 _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Thu Jul 13 19:20:51 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 13 Jul 2017 19:20:51 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: <20170713172051.GA1580@klara.mpi.htwm.de> On Wed, Jul 12, 2017 at 11:54:54PM -0400, Phil Bouchard wrote: > On 07/12/2017 10:28 PM, Thiago Macieira wrote: > >On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote: > >>I don't know about you but a minimalist version of g++ embedded inside the > >>browser could be beneficial big time. > > > >Such a thing exists, it's called JIT. > > I was reading the Wiki page: > https://en.wikipedia.org/wiki/Just-in-time_compilation > > And it says: > "thus in theory JIT compilation can yield faster execution than static > compilation" Right, and in practice there's a reason why some people pronounce it with [ʃ] There's no sensible reason to postpone "compilation" to run-time on a million feeble devices if there's any sensible way to do it ahead of time once on a beefy developer machine. Andre' From philippeb8 at gmail.com Thu Jul 13 21:06:32 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 19:06:32 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> <20170713172051.GA1580@klara.mpi.htwm.de> Message-ID: André Pönitz wrote: > On Wed, Jul 12, 2017 at 11:54:54PM -0400, Phil Bouchard wrote: > On 07/12/2017 10:28 PM, Thiago Macieira wrote: > >On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote: > >>I don't know about you but a minimalist version of g++ embedded inside the > >>browser could be beneficial big time. > > > >Such a thing exists, it's called JIT. > > I was reading the Wiki page: > https://en.wikipedia.org/wiki/Just-in-time_compilation > > And it says: > "thus in theory JIT compilation can yield faster execution than static > compilation" Right, and in practice there's a reason why some people pronounce it with [ʃ] There's no sensible reason to postpone "compilation" to run-time on a million feeble devices if there's any sensible way to do it ahead of time once on a beefy developer machine. Andre' _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From philippeb8 at gmail.com Fri Jul 14 02:32:58 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 20:32:58 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <20170713172051.GA1580@klara.mpi.htwm.de> References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> <20170713172051.GA1580@klara.mpi.htwm.de> Message-ID: On 07/13/2017 01:20 PM, André Pönitz wrote: > On Wed, Jul 12, 2017 at 11:54:54PM -0400, Phil Bouchard wrote: >> On 07/12/2017 10:28 PM, Thiago Macieira wrote: >>> On quarta-feira, 12 de julho de 2017 12:34:35 PDT Phil Bouchard wrote: >>>> I don't know about you but a minimalist version of g++ embedded inside the >>>> browser could be beneficial big time. >>> >>> Such a thing exists, it's called JIT. >> >> I was reading the Wiki page: >> https://en.wikipedia.org/wiki/Just-in-time_compilation >> >> And it says: >> "thus in theory JIT compilation can yield faster execution than static >> compilation" > > Right, and in practice there's a reason why some people pronounce > it with [ʃ] > > There's no sensible reason to postpone "compilation" to run-time > on a million feeble devices if there's any sensible way to do it > ahead of time once on a beefy developer machine. You just helped me figure something out: people want speed, right? - You offer a service which converts and compiles all Javascript files for most popular architectures (i386, x86_64, ARM, MIPS, ...) - You cache these executables on the webserver in question - The client just downloads and caches the respective executable and executes it in the browser You can't have anything faster than that. And once again we would be able to mix Javascript with C++ so you could import real OpenGL code in the executable and play let's say: "Unreal Tournament" in your own browser. Because let's face it: WebGL is not going anywhere. It had the slowest progress I have ever seen! My 2 cents, -Phil From philippeb8 at gmail.com Fri Jul 14 03:14:31 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 13 Jul 2017 21:14:31 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: On 07/13/2017 10:32 AM, Grégoire Barbier wrote: > Le 13/07/2017 à 14:33, Phil Bouchard a écrit : >> >> I'm working on it; it shouldn't take too long. > > <3 > > « I have discovered a truly marvelous proof of this, which this margin > is too narrow to contain. » > Pierre de Fermat, 1637 A.D. > > Took 356 years to be proven actually. > > Anyway compiling JS to C++ was not your first goal if I undestand well. I'm just killing two birds with one stone here. > Maybe getting rid of GC is possible without compiling JS. And it may be > interesting for compiled languages that do use a GC to, like C# or Java. Swift, C# or Java are all proprietary languages now and they just embrace and extend whatever you do without giving you credit. They already embraced and extended my Fornux PowerCalc with their Microsoft PowerToys after I had presented it to them using some web submission tool: https://en.wikipedia.org/wiki/Microsoft_PowerToys#Included_applications -Phil From philippeb8 at gmail.com Fri Jul 14 06:58:01 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 14 Jul 2017 00:58:01 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: On 07/13/2017 10:32 AM, Grégoire Barbier wrote: > Le 13/07/2017 à 14:33, Phil Bouchard a écrit : >> Sérgio Martins wrote: >>> On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard >>> wrote: >>>> Anyway I'm deviating from QNodePtr but I just don't understand the hype >>>> about JIT when it doesn't seem it has been compared to a Javascript >>>> compiler >>>> because none exists up to now. >>> >>> That's precisely the biggest advantage of JIT: It exists, while js2cpp >>> doesn't (or at least in a usable form for us). >> >> I'm working on it; it shouldn't take too long. > > <3 Here's a preliminary parser that doesn't even compile yet but it's moving forward and fast: https://github.com/philippeb8/root_ptr/tree/qt/example/js2cpp -Phil From Sudhir.Sharma at mindtree.com Fri Jul 14 07:29:23 2017 From: Sudhir.Sharma at mindtree.com (Sudhir Sharma) Date: Fri, 14 Jul 2017 05:29:23 +0000 Subject: [Development] QWebEngineView Print Message-ID: Hi, How can we print html loaded in QWebEngineView in QT 5.7? Regards, Sudhir ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jul 14 09:18:08 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Jul 2017 00:18:08 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <20170713172051.GA1580@klara.mpi.htwm.de> Message-ID: <6581487.7tvJSTq4st@tjmaciei-mobl1> On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote: > You just helped me figure something out: people want speed, right? > > - You offer a service which converts and compiles all Javascript files > for most popular architectures (i386, x86_64, ARM, MIPS, ...) > - You cache these executables on the webserver in question > - The client just downloads and caches the respective executable and > executes it in the browser Except for the fact that no browser would ever download and execute untrusted binaries like that. The closest is Native Client (NaCl). > Because let's face it: WebGL is not going anywhere. It had the slowest > progress I have ever seen! What progress does it need? It needs to implement the OpenGL ES API. Once that is done, they don't need to do anything. All the work is in the GL drivers and GPUs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Fri Jul 14 09:32:05 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 14 Jul 2017 10:32:05 +0300 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <6581487.7tvJSTq4st@tjmaciei-mobl1> References: <20170713172051.GA1580@klara.mpi.htwm.de> <6581487.7tvJSTq4st@tjmaciei-mobl1> Message-ID: <1226021500017525@web5m.yandex.ru> 14.07.2017, 10:18, "Thiago Macieira" : > On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote: >>  You just helped me figure something out: people want speed, right? >> >>  - You offer a service which converts and compiles all Javascript files >>  for most popular architectures (i386, x86_64, ARM, MIPS, ...) >>  - You cache these executables on the webserver in question >>  - The client just downloads and caches the respective executable and >>  executes it in the browser > > Except for the fact that no browser would ever download and execute untrusted > binaries like that. > > The closest is Native Client (NaCl). Which is being phased out in favor of WebAssembly (JIT-based) > >>  Because let's face it: WebGL is not going anywhere. It had the slowest >>  progress I have ever seen! > > What progress does it need? It needs to implement the OpenGL ES API. Once that > is done, they don't need to do anything. All the work is in the GL drivers and > GPUs. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From edward.welbourne at qt.io Fri Jul 14 10:37:50 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 14 Jul 2017 08:37:50 +0000 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <20170713172051.GA1580@klara.mpi.htwm.de> References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> , <20170713172051.GA1580@klara.mpi.htwm.de> Message-ID: André Pönitz (13 July 2017 19:20) > There's no sensible reason to postpone "compilation" to run-time > on a million feeble devices if there's any sensible way to do it > ahead of time once on a beefy developer machine. On the other hand, doing run-time optimisation (which is one of the benefits a JIT is meant to give you) *does* have value; having the engine capable of spotting which paths through the code actually do get taken in real live use (rather than guessing during compilation; no matter how good your heuristics, or how much the developer annotates the code to help, real-world run-time will do things differently than you thought) lets the run-time engine optimise those paths at the expense of others. Then of course there's the issue of trust: the user trusts the browser to run code sand-boxed; neither the browser nor the user should trust a binary downloaded from the internet; so the benefits you can gain by pre-compiling incur the cost of running untrusted code. Java deals with that by running the compiled code in a VM that's sand-boxed; modern ECMAScript (a.k.a. javascript) deals with running native code by only doing so when the native code in question is what it generated, within constraints that keep it inside the interpreter's sand-box. (Which is still somewhat scary, as JITs are software and software has bugs, that attackers shall exploit; in this case, to trick a JIT into doing something that breaks the sand-box. So modern browsers are aggressive about updating themselves.) Oh, and many of our hand-held devices are far from feeble - but perhaps my standards are a bit odd. My first job involved sending code to run on a Cray 1 at £1000 per hour; we're all now wasting cycles on more powerful computers whose non-wasted cycles are mostly used to alleviate boredom, Eddy. From kevin.kofler at chello.at Fri Jul 14 12:50:45 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 14 Jul 2017 12:50:45 +0200 Subject: [Development] QWebEngineView Print References: Message-ID: Sudhir Sharma wrote: > How can we print html loaded in QWebEngineView in QT 5.7? In 5.7, you can only print by first printing to PDF and then invoking something external to actually send the PDF to a printer. See the code (submitted by me) in QupZilla 2.1.x (and currently also in master/2.2, but since that requires Qt 5.8, it may be ported to the direct print method soon, I've been wanting to look into that for a while). But that code assumes the lpr executable is available on *nix, and there is an implementation for Windows that is rather suboptimal (invokes the configured PDF viewer and asks it to print). You may want to upgrade to 5.8 or 5.9, where you just have to invoke the print method. It is also possible to upgrade QtWebEngine to 5.8 or 5.9 while keeping Qt 5.7, you will just need this one-line fix: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/plain/qtwebengine-opensource-src-5.8.0-qt57.patch and you may want to explicitly enable spellchecking, which is disabled by default when building against Qt 5.7: WEBENGINE_CONFIG+=use_spellchecker and if you are using CMake, you will likely also need this tweak on the installed QtWebEngineConfig*.cmake files: sed -i -e "s|%{version} \${_Qt5WebEngine|%{_qt5_version} \${_Qt5WebEngine|" \ %{buildroot}%{_qt5_libdir}/cmake/Qt5WebEngine*/Qt5WebEngine*Config.cmake QtWebEngine is the only part that of Qt you need to upgrade to get the print method. Kevin Kofler From philippeb8 at gmail.com Fri Jul 14 14:06:14 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 14 Jul 2017 08:06:14 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <6581487.7tvJSTq4st@tjmaciei-mobl1> References: <20170713172051.GA1580@klara.mpi.htwm.de> <6581487.7tvJSTq4st@tjmaciei-mobl1> Message-ID: On 07/14/2017 03:18 AM, Thiago Macieira wrote: > On quinta-feira, 13 de julho de 2017 17:32:58 PDT Phil Bouchard wrote: >> You just helped me figure something out: people want speed, right? >> >> - You offer a service which converts and compiles all Javascript files >> for most popular architectures (i386, x86_64, ARM, MIPS, ...) >> - You cache these executables on the webserver in question >> - The client just downloads and caches the respective executable and >> executes it in the browser > > Except for the fact that no browser would ever download and execute untrusted > binaries like that. > > The closest is Native Client (NaCl). You force that Javascript executable (".jex" file) to run inside some embedded virtual machine with restricted access to the system. >> Because let's face it: WebGL is not going anywhere. It had the slowest >> progress I have ever seen! > > What progress does it need? It needs to implement the OpenGL ES API. Once that > is done, they don't need to do anything. All the work is in the GL drivers and > GPUs. Where are the WebGL games then? We don't need OpenGL ES on x86. From thiago.macieira at intel.com Fri Jul 14 17:38:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Jul 2017 08:38:22 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <6581487.7tvJSTq4st@tjmaciei-mobl1> Message-ID: <1803243.PlLPvU3NvO@tjmaciei-mobl1> On sexta-feira, 14 de julho de 2017 05:06:14 PDT Phil Bouchard wrote: > > Except for the fact that no browser would ever download and execute > > untrusted binaries like that. > > > > The closest is Native Client (NaCl). > > You force that Javascript executable (".jex" file) to run inside some > embedded virtual machine with restricted access to the system. Virtual Machines (protected by hardware) run operating system kernels, not simple executables. And it has a non-negligible memory overhead, since it needs to do its own virtual paging table management. Please read up a little on a subject before you make such an outlandish suggestion. > >> Because let's face it: WebGL is not going anywhere. It had the slowest > >> progress I have ever seen! > > > > What progress does it need? It needs to implement the OpenGL ES API. Once > > that is done, they don't need to do anything. All the work is in the GL > > drivers and GPUs. > > Where are the WebGL games then? We don't need OpenGL ES on x86. First, some exist. The difficult part in making games with JS is probably not the GL part, but all the rest, including the code that manages the visible screen area. I never said that JS isn't slow -- it is. And second, standardising on one API (OpenGL ES) has benefits for game makers and other application deveopers, since they can use the very same on both desktop and mobile. It's probably of less value for gamek developers since the interaction is going to be very different from a desktop and a mobile phone or tablet, but other applications can benefit a lot from OpenGL ES. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Fri Jul 14 19:08:13 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 14 Jul 2017 17:08:13 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <6581487.7tvJSTq4st@tjmaciei-mobl1> <1803243.PlLPvU3NvO@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On sexta-feira, 14 de julho de 2017 05:06:14 PDT Phil Bouchard wrote: >>> Except for the fact that no browser would ever download and execute >>> untrusted binaries like that. >>> >>> The closest is Native Client (NaCl). >> >> You force that Javascript executable (".jex" file) to run inside some >> embedded virtual machine with restricted access to the system. > > Virtual Machines (protected by hardware) run operating system kernels, not > simple executables. And it has a non-negligible memory overhead, since it > needs to do its own virtual paging table management. > > Please read up a little on a subject before you make such an outlandish > suggestion. Yes sorry that was just a quick guess but in Linux you can run Linux containers which do the same but with minimal overhead. >>>> Because let's face it: WebGL is not going anywhere. It had the slowest >>>> progress I have ever seen! >>> >>> What progress does it need? It needs to implement the OpenGL ES API. Once >>> that is done, they don't need to do anything. All the work is in the GL >>> drivers and GPUs. >> >> Where are the WebGL games then? We don't need OpenGL ES on x86. > > First, some exist. The difficult part in making games with JS is probably not > the GL part, but all the rest, including the code that manages the visible > screen area. > > I never said that JS isn't slow -- it is. > > And second, standardising on one API (OpenGL ES) has benefits for game makers > and other application deveopers, since they can use the very same on both > desktop and mobile. It's probably of less value for gamek developers since the > interaction is going to be very different from a desktop and a mobile phone or > tablet, but other applications can benefit a lot from OpenGL ES. I definitely agree OpenGL ES needs to be standardized. Anyway I'm just trying to help here. But Microsoft probably already embraced and is extending this strategy as we speak now ;) From thiago.macieira at intel.com Fri Jul 14 20:29:26 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Jul 2017 11:29:26 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> Message-ID: <8723728.gbDMUSnghe@tjmaciei-mobl1> On sexta-feira, 14 de julho de 2017 10:08:13 PDT Phil Bouchard wrote: > > Please read up a little on a subject before you make such an outlandish > > suggestion. > > Yes sorry that was just a quick guess but in Linux you can run Linux > containers which do the same but with minimal overhead. A container is not the same as a virtual machine. There is such a thing as virtualised containers (see [1]), but they don't boot as fast as a regular container. We've got it down to less than 200 milliseconds. Browsers already use process separation and other things to avoid escalation from JS. I do believe they also use the same technique as containers for namespace separations. But that's for running a JS VM, not for running direct native code that can make system calls and trigger hardware errata. [1] https://clearlinux.org/features/intel%C2%AE-clear-containers > > And second, standardising on one API (OpenGL ES) has benefits for game > > makers and other application deveopers, since they can use the very same > > on both desktop and mobile. It's probably of less value for gamek > > developers since the interaction is going to be very different from a > > desktop and a mobile phone or tablet, but other applications can benefit > > a lot from OpenGL ES. > > I definitely agree OpenGL ES needs to be standardized. It has always been a standard! That's what the Khronos Group is for in the first place. > Anyway I'm just trying to help here. But Microsoft probably already > embraced and is extending this strategy as we speak now ;) No, they went their own route and designed DirectX, though TBH Khronos was dysfunctional at the time. WebGL is actually the best thing that happened to the standard route because it forced Microsoft to implement OpenGL ES support in their browsers in the form of WebGL. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Fri Jul 14 21:13:52 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 14 Jul 2017 19:13:52 +0000 (UTC) Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On sexta-feira, 14 de julho de 2017 10:08:13 PDT Phil Bouchard wrote: >>> Please read up a little on a subject before you make such an outlandish >>> suggestion. >> >> Yes sorry that was just a quick guess but in Linux you can run Linux >> containers which do the same but with minimal overhead. > > A container is not the same as a virtual machine. There is such a thing as > virtualised containers (see [1]), but they don't boot as fast as a regular > container. We've got it down to less than 200 milliseconds. > > Browsers already use process separation and other things to avoid escalation > from JS. I do believe they also use the same technique as containers for > namespace separations. But that's for running a JS VM, not for running direct > native code that can make system calls and trigger hardware errata. > > [1] https://clearlinux.org/features/intel%C2%AE-clear-containers I understand but what's the problem with containers? I think Linux containers are also supported under Windows. Obviously some efforts will have to be done to strip out some access to the hardware >>> And second, standardising on one API (OpenGL ES) has benefits for game >>> makers and other application deveopers, since they can use the very same >>> on both desktop and mobile. It's probably of less value for gamek >>> developers since the interaction is going to be very different from a >>> desktop and a mobile phone or tablet, but other applications can benefit >>> a lot from OpenGL ES. >> >> I definitely agree OpenGL ES needs to be standardized. > > It has always been a standard! That's what the Khronos Group is for in the > first place. I meant Open GL and Open GL ES will have to be unified one day. >> Anyway I'm just trying to help here. But Microsoft probably already >> embraced and is extending this strategy as we speak now ;) > > No, they went their own route and designed DirectX, though TBH Khronos was > dysfunctional at the time. WebGL is actually the best thing that happened to > the standard route because it forced Microsoft to implement OpenGL ES support > in their browsers in the form of WebGL. BTW what did Microsoft really invent anyways? - they extended the IBM OS 9 - they extended WordPerfect and Lotus - they invested into Corel so that they get rid of Corel Linux when I was there - they copied my calculator - they copied Google with their Bing - they tried to copy iPhone with the Windows Phone - DirectX never was better than OpenGL Oh sorry they did invent Minesweeper and Basic, I give them that... Sorry I had to spit it out. But let's see what happens with WebGL. From philippeb8 at gmail.com Sat Jul 15 05:43:12 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 14 Jul 2017 23:43:12 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <2978415.3vsTAvGbRd@tjmaciei-mobl1> Message-ID: On 07/14/2017 12:58 AM, Phil Bouchard wrote: > On 07/13/2017 10:32 AM, Grégoire Barbier wrote: >> Le 13/07/2017 à 14:33, Phil Bouchard a écrit : >>> Sérgio Martins wrote: >>>> On Thu, Jul 13, 2017 at 4:54 AM, Phil Bouchard >>>> wrote: >>>>> Anyway I'm deviating from QNodePtr but I just don't understand the >>>>> hype >>>>> about JIT when it doesn't seem it has been compared to a Javascript >>>>> compiler >>>>> because none exists up to now. >>>> >>>> That's precisely the biggest advantage of JIT: It exists, while js2cpp >>>> doesn't (or at least in a usable form for us). >>> >>> I'm working on it; it shouldn't take too long. >> >> <3 > > Here's a preliminary parser that doesn't even compile yet but it's > moving forward and fast: > https://github.com/philippeb8/root_ptr/tree/qt/example/js2cpp Now it compiles, links and parses correctly. I just need to fix the output and make it all work. From thiago.macieira at intel.com Sat Jul 15 08:56:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Jul 2017 23:56:47 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: <7428713.mBTnblziLo@tjmaciei-mobl1> On sexta-feira, 14 de julho de 2017 12:13:52 PDT Phil Bouchard wrote: > > [1] https://clearlinux.org/features/intel%C2%AE-clear-containers > > I understand but what's the problem with containers? I think Linux > containers are also supported under Windows. Obviously some efforts will > have to be done to strip out some access to the hardware Windows and macOS run Linux containers by starting a virtual machine that runs Linux. The time those take to start is in the order of seconds, not tenths of seconds like Clear Containers or tenths of milliseconds like regular containers. Clear Containers on Linux takes advantage that the *host* is Linux to bypass a lot of things. It doesn't run a BIOS, for instance, and simply executes a specially-prepared vmlinux binary inside the VM. There's no disk I/O -- everything is Direct Access (DAX) just like on tiny microcontrolers. Making that run on macOS or Windows requires changes to the host OS itself. > > It has always been a standard! That's what the Khronos Group is for in the > > first place. > > I meant Open GL and Open GL ES will have to be unified one day. And then we added Vulkan. So, unlikely, though I think OpenGL 4 is a complete superset of OpenGL ES 2. Maybe of ES3 too? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Sat Jul 15 18:39:20 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 12:39:20 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <7428713.mBTnblziLo@tjmaciei-mobl1> References: <8723728.gbDMUSnghe@tjmaciei-mobl1> <7428713.mBTnblziLo@tjmaciei-mobl1> Message-ID: On 07/15/2017 02:56 AM, Thiago Macieira wrote: > On sexta-feira, 14 de julho de 2017 12:13:52 PDT Phil Bouchard wrote: >>> [1] https://clearlinux.org/features/intel%C2%AE-clear-containers >> >> I understand but what's the problem with containers? I think Linux >> containers are also supported under Windows. Obviously some efforts will >> have to be done to strip out some access to the hardware > > Windows and macOS run Linux containers by starting a virtual machine that runs > Linux. The time those take to start is in the order of seconds, not tenths of > seconds like Clear Containers or tenths of milliseconds like regular > containers. > > Clear Containers on Linux takes advantage that the *host* is Linux to bypass a > lot of things. It doesn't run a BIOS, for instance, and simply executes a > specially-prepared vmlinux binary inside the VM. There's no disk I/O -- > everything is Direct Access (DAX) just like on tiny microcontrolers. > > Making that run on macOS or Windows requires changes to the host OS itself. Yes of course, I should have anticipated that. So one option left would be to: - compile the Javascript file for each architecture / platform - link that "jex" to a portable dynamic library API - run native containers (Hyper-V on Windows I think) - run the "jex" executable in that native container -Phil From thiago.macieira at intel.com Sat Jul 15 18:59:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 15 Jul 2017 09:59:21 -0700 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <7428713.mBTnblziLo@tjmaciei-mobl1> Message-ID: <1724783.xoUuPT3H5q@tjmaciei-mobl1> On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote: > Yes of course, I should have anticipated that. So one option left would > be to: > - compile the Javascript file for each architecture / platform > - link that "jex" to a portable dynamic library API > - run native containers (Hyper-V on Windows I think) > - run the "jex" executable in that native container Hyper-V is not a container. Containers are not completely secure. That's why we spent the engineering effort of making the Clear Containers, so that the processor's virtual machine protections kick in. And you could investigate NaCl. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Sat Jul 15 19:18:37 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 13:18:37 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: <1724783.xoUuPT3H5q@tjmaciei-mobl1> References: <7428713.mBTnblziLo@tjmaciei-mobl1> <1724783.xoUuPT3H5q@tjmaciei-mobl1> Message-ID: On 07/15/2017 12:59 PM, Thiago Macieira wrote: > On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote: >> Yes of course, I should have anticipated that. So one option left would >> be to: >> - compile the Javascript file for each architecture / platform >> - link that "jex" to a portable dynamic library API >> - run native containers (Hyper-V on Windows I think) >> - run the "jex" executable in that native container > > Hyper-V is not a container. > > Containers are not completely secure. That's why we spent the engineering > effort of making the Clear Containers, so that the processor's virtual machine > protections kick in. > > And you could investigate NaCl. I will but you get the idea. From tim at klingt.org Sat Jul 15 19:34:12 2017 From: tim at klingt.org (Tim Blechmann) Date: Sat, 15 Jul 2017 19:34:12 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: > Oh sorry they did invent Minesweeper and Basic, I give them that... https://en.wikipedia.org/wiki/Dartmouth_BASIC -- fwiw, to get this thread back to the main topic, i still fail to see how root_ptr deals with objects which are reachable from multiple roots, which have independent lifetime From philippeb8 at gmail.com Sat Jul 15 19:54:36 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 13:54:36 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 01:34 PM, Tim Blechmann wrote: >> Oh sorry they did invent Minesweeper and Basic, I give them that... > > https://en.wikipedia.org/wiki/Dartmouth_BASIC Lol. > fwiw, to get this thread back to the main topic, i still fail to see how > root_ptr deals with objects which are reachable from multiple roots, > which have independent lifetime Please provide an example. From tim at klingt.org Sat Jul 15 20:17:54 2017 From: tim at klingt.org (Tim Blechmann) Date: Sat, 15 Jul 2017 20:17:54 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: >> fwiw, to get this thread back to the main topic, i still fail to see how >> root_ptr deals with objects which are reachable from multiple roots, >> which have independent lifetime > > Please provide an example. i've posted some already From philippeb8 at gmail.com Sat Jul 15 20:26:02 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 14:26:02 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 02:17 PM, Tim Blechmann wrote: >>> fwiw, to get this thread back to the main topic, i still fail to see how >>> root_ptr deals with objects which are reachable from multiple roots, >>> which have independent lifetime >> >> Please provide an example. > > i've posted some already I'm working on the parser right now but I thought I proved my point with the following code: var temporary = 0; var bar = function (object) { return 10; }; var foo = function () { var object; var result = function() { return object; }; return function() { return bar( object ); }; }; for (var i = 0; i < 1000000; ++ i) console_log((foo())(temporary)); From philippeb8 at gmail.com Sat Jul 15 22:58:08 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 16:58:08 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 02:26 PM, Phil Bouchard wrote: > On 07/15/2017 02:17 PM, Tim Blechmann wrote: >>>> fwiw, to get this thread back to the main topic, i still fail to see >>>> how >>>> root_ptr deals with objects which are reachable from multiple roots, >>>> which have independent lifetime >>> >>> Please provide an example. >> >> i've posted some already > > I'm working on the parser right now but I thought I proved my point with > the following code: > > var temporary = 0; > > var bar = function (object) > { > return 10; > }; > > var foo = function () > { > var object; > var result = function() { return object; }; > return function() { return bar( object ); }; > }; > > for (var i = 0; i < 1000000; ++ i) > console_log((foo())(temporary)); Alright I got good news: the parser already generates code that compiles and works! I still need to fix minor issues but I am on the right path. From tim at klingt.org Sun Jul 16 01:21:06 2017 From: tim at klingt.org (Tim Blechmann) Date: Sun, 16 Jul 2017 01:21:06 +0200 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: >>>> fwiw, to get this thread back to the main topic, i still fail to see >>>> how >>>> root_ptr deals with objects which are reachable from multiple roots, >>>> which have independent lifetime >>> >>> Please provide an example. >> >> i've posted some already > > I'm working on the parser right now but I thought I proved my point with > the following code: > > var temporary = 0; > > var bar = function (object) > { > return 10; > }; > > var foo = function () > { > var object; > var result = function() { return object; }; > return function() { return bar( object ); }; > }; > > for (var i = 0; i < 1000000; ++ i) > console_log((foo())(temporary)); after `foo` returns, you only have one root, as neither `result` nor `object` will escape `foo` and `object` will only be referenced by the closure returned by `foo`. `result` is a perfect target for escape analysis. maybe even `object`. you have read about escape analysis, right? From philippeb8 at gmail.com Sun Jul 16 01:32:28 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 19:32:28 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 04:58 PM, Phil Bouchard wrote: > On 07/15/2017 02:26 PM, Phil Bouchard wrote: >> On 07/15/2017 02:17 PM, Tim Blechmann wrote: >>>>> fwiw, to get this thread back to the main topic, i still fail to see >>>>> how >>>>> root_ptr deals with objects which are reachable from multiple roots, >>>>> which have independent lifetime >>>> >>>> Please provide an example. >>> >>> i've posted some already >> >> I'm working on the parser right now but I thought I proved my point with >> the following code: >> >> var temporary = 0; >> >> var bar = function (object) >> { >> return 10; >> }; >> >> var foo = function () >> { >> var object; >> var result = function() { return object; }; >> return function() { return bar( object ); }; >> }; >> >> for (var i = 0; i < 1000000; ++ i) >> console_log((foo())(temporary)); > > Alright I got good news: the parser already generates code that compiles > and works! > > I still need to fix minor issues but I am on the right path. Alright... it's good enough now so you try it out yourselves (BTW I added the keyword: "extern" so you can already mix C++ code with Javascript). Instructions (you'll need: Boost, Flex, Bison, Qt): 1) Get the following code: https://github.com/philippeb8/root_ptr/tree/qt 2) In "example/js2cpp", type: $ qmake $ make $ ./js2cpp < tests/input1.js > tmp.cpp $ g++ -std=c++11 -O2 -Iinclude -I../../include tmp.cpp -otmp -lboost_system $ time ./tmp int main() real 0m1.581s user 0m1.581s sys 0m0.000s TODO: 1) Finish removing all dependencies from Boost 2) Figure a way to have variadic number of arguments for functions 3) Create local variables linked to the function arguments 4) Fix a -DBOOST_DISABLE_THREADS that is not working for some reason 5) ... Thanks for your patience! -Phil From philippeb8 at gmail.com Sun Jul 16 01:49:15 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 19:49:15 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 07:21 PM, Tim Blechmann wrote: >>>>> fwiw, to get this thread back to the main topic, i still fail to see >>>>> how >>>>> root_ptr deals with objects which are reachable from multiple roots, >>>>> which have independent lifetime >>>> >>>> Please provide an example. >>> >>> i've posted some already >> >> I'm working on the parser right now but I thought I proved my point with >> the following code: >> >> var temporary = 0; >> >> var bar = function (object) >> { >> return 10; >> }; >> >> var foo = function () >> { >> var object; >> var result = function() { return object; }; >> return function() { return bar( object ); }; >> }; >> >> for (var i = 0; i < 1000000; ++ i) >> console_log((foo())(temporary)); > > after `foo` returns, you only have one root, as neither `result` nor > `object` will escape `foo` and `object` will only be referenced by the > closure returned by `foo`. > > `result` is a perfect target for escape analysis. maybe even `object`. > you have read about escape analysis, right? Yes I understand escape analysis and that's exactly why I had to add a run-time stack. From philippeb8 at gmail.com Sun Jul 16 03:46:42 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 21:46:42 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 07:32 PM, Phil Bouchard wrote: > On 07/15/2017 04:58 PM, Phil Bouchard wrote: >> On 07/15/2017 02:26 PM, Phil Bouchard wrote: >>> On 07/15/2017 02:17 PM, Tim Blechmann wrote: >>>>>> fwiw, to get this thread back to the main topic, i still fail to see >>>>>> how >>>>>> root_ptr deals with objects which are reachable from multiple roots, >>>>>> which have independent lifetime >>>>> >>>>> Please provide an example. >>>> >>>> i've posted some already >>> >>> I'm working on the parser right now but I thought I proved my point with >>> the following code: >>> >>> var temporary = 0; >>> >>> var bar = function (object) >>> { >>> return 10; >>> }; >>> >>> var foo = function () >>> { >>> var object; >>> var result = function() { return object; }; >>> return function() { return bar( object ); }; >>> }; >>> >>> for (var i = 0; i < 1000000; ++ i) >>> console_log((foo())(temporary)); >> >> Alright I got good news: the parser already generates code that compiles >> and works! >> >> I still need to fix minor issues but I am on the right path. > > Alright... it's good enough now so you try it out yourselves (BTW I > added the keyword: "extern" so you can already mix C++ code with > Javascript). > > > Instructions (you'll need: Boost, Flex, Bison, Qt): > > 1) Get the following code: https://github.com/philippeb8/root_ptr/tree/qt > > 2) In "example/js2cpp", type: > $ qmake > $ make > $ ./js2cpp < tests/input1.js > tmp.cpp > $ g++ -std=c++11 -O2 -Iinclude -I../../include tmp.cpp -otmp -lboost_system > $ time ./tmp > int main() > > real 0m1.581s > user 0m1.581s > sys 0m0.000s > > > TODO: > > 1) Finish removing all dependencies from Boost > > 2) Figure a way to have variadic number of arguments for functions > > 3) Create local variables linked to the function arguments > > 4) Fix a -DBOOST_DISABLE_THREADS that is not working for some reason > > 5) ... Actually there seem to have a bug in g++-4.8 so please use g++-4.9 as follows: g++-4.9 -DBOOST_DISABLE_THREADS -std=c++11 -O2 -I./include -I../../include tmp.cpp -otmp -lboost_system Thanks, -Phil From philippeb8 at gmail.com Sun Jul 16 04:10:26 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 22:10:26 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 09:46 PM, Phil Bouchard wrote: > On 07/15/2017 07:32 PM, Phil Bouchard wrote: >> On 07/15/2017 04:58 PM, Phil Bouchard wrote: >>> On 07/15/2017 02:26 PM, Phil Bouchard wrote: >>>> On 07/15/2017 02:17 PM, Tim Blechmann wrote: >>>>>>> fwiw, to get this thread back to the main topic, i still fail to see >>>>>>> how >>>>>>> root_ptr deals with objects which are reachable from multiple roots, >>>>>>> which have independent lifetime >>>>>> >>>>>> Please provide an example. >>>>> >>>>> i've posted some already >>>> >>>> I'm working on the parser right now but I thought I proved my point >>>> with >>>> the following code: >>>> >>>> var temporary = 0; >>>> >>>> var bar = function (object) >>>> { >>>> return 10; >>>> }; >>>> >>>> var foo = function () >>>> { >>>> var object; >>>> var result = function() { return object; }; >>>> return function() { return bar( object ); }; >>>> }; >>>> >>>> for (var i = 0; i < 1000000; ++ i) >>>> console_log((foo())(temporary)); >>> >>> Alright I got good news: the parser already generates code that compiles >>> and works! >>> >>> I still need to fix minor issues but I am on the right path. >> >> Alright... it's good enough now so you try it out yourselves (BTW I >> added the keyword: "extern" so you can already mix C++ code with >> Javascript). >> >> >> Instructions (you'll need: Boost, Flex, Bison, Qt): >> >> 1) Get the following code: https://github.com/philippeb8/root_ptr/tree/qt >> >> 2) In "example/js2cpp", type: >> $ qmake >> $ make >> $ ./js2cpp < tests/input1.js > tmp.cpp >> $ g++ -std=c++11 -O2 -Iinclude -I../../include tmp.cpp -otmp >> -lboost_system >> $ time ./tmp >> int main() >> >> real 0m1.581s >> user 0m1.581s >> sys 0m0.000s >> >> >> TODO: >> >> 1) Finish removing all dependencies from Boost >> >> 2) Figure a way to have variadic number of arguments for functions >> >> 3) Create local variables linked to the function arguments >> >> 4) Fix a -DBOOST_DISABLE_THREADS that is not working for some reason >> >> 5) ... > > Actually there seem to have a bug in g++-4.8 so please use g++-4.9 as > follows: > > g++-4.9 -DBOOST_DISABLE_THREADS -std=c++11 -O2 -I./include > -I../../include tmp.cpp -otmp -lboost_system ... and it's still exactly twice as fast as Node.JS. From philippeb8 at gmail.com Sun Jul 16 05:01:40 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 23:01:40 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <1803243.PlLPvU3NvO@tjmaciei-mobl1> <8723728.gbDMUSnghe@tjmaciei-mobl1> Message-ID: On 07/15/2017 07:49 PM, Phil Bouchard wrote: > On 07/15/2017 07:21 PM, Tim Blechmann wrote: >>>>>> fwiw, to get this thread back to the main topic, i still fail to see >>>>>> how >>>>>> root_ptr deals with objects which are reachable from multiple roots, >>>>>> which have independent lifetime >>>>> >>>>> Please provide an example. >>>> >>>> i've posted some already >>> >>> I'm working on the parser right now but I thought I proved my point with >>> the following code: >>> >>> var temporary = 0; >>> >>> var bar = function (object) >>> { >>> return 10; >>> }; >>> >>> var foo = function () >>> { >>> var object; >>> var result = function() { return object; }; >>> return function() { return bar( object ); }; >>> }; >>> >>> for (var i = 0; i < 1000000; ++ i) >>> console_log((foo())(temporary)); >> >> after `foo` returns, you only have one root, as neither `result` nor >> `object` will escape `foo` and `object` will only be referenced by the >> closure returned by `foo`. >> >> `result` is a perfect target for escape analysis. maybe even `object`. >> you have read about escape analysis, right? > > Yes I understand escape analysis and that's exactly why I had to add a > run-time stack. I apologize but there was a bug in my code which I just fixed (about missing variables). And perhaps you and Thiago were right that it's impossible for Javascript to run without a GC because variables indeed go out of scope and only the GC can tell whether to keep it or not. Perhaps I should go back to the C++ world with my root_ptr, now that I have a better understanding of it all. But I will double check all of this beforehand. Thanks again! -Phil From philippeb8 at gmail.com Sun Jul 16 05:35:39 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 15 Jul 2017 23:35:39 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <7428713.mBTnblziLo@tjmaciei-mobl1> <1724783.xoUuPT3H5q@tjmaciei-mobl1> Message-ID: On 07/15/2017 01:18 PM, Phil Bouchard wrote: > On 07/15/2017 12:59 PM, Thiago Macieira wrote: >> On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote: >>> Yes of course, I should have anticipated that. So one option left would >>> be to: >>> - compile the Javascript file for each architecture / platform >>> - link that "jex" to a portable dynamic library API >>> - run native containers (Hyper-V on Windows I think) >>> - run the "jex" executable in that native container >> >> Hyper-V is not a container. >> >> Containers are not completely secure. That's why we spent the engineering >> effort of making the Clear Containers, so that the processor's virtual >> machine >> protections kick in. >> >> And you could investigate NaCl. > > I will but you get the idea. Like I was saying, there was a bug in my code and perhaps it's impossible for Javascript to run without a GC indeed. But that doesn't mean that we couldn't run executables in one of those specialized containers. And although I like the concept of these quick function callbacks in Javascript, I do not like the 'escape analysis' thing and I think this should be trashed because the ratio costs / benefits isn't profitable enough. Perhaps we could derive a new language from Javascript and C++ which could be run inside these specialized containers. I already have a parser and only minor changes are necessary. If people want speed then there is no other way. -Phil From philippeb8 at gmail.com Sun Jul 16 13:51:03 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 16 Jul 2017 07:51:03 -0400 Subject: [Development] Qt 5.9's new garbage collector documentation? + root_ptr In-Reply-To: References: <7428713.mBTnblziLo@tjmaciei-mobl1> <1724783.xoUuPT3H5q@tjmaciei-mobl1> Message-ID: On 07/15/2017 11:35 PM, Phil Bouchard wrote: > On 07/15/2017 01:18 PM, Phil Bouchard wrote: >> On 07/15/2017 12:59 PM, Thiago Macieira wrote: >>> On sábado, 15 de julho de 2017 09:39:20 PDT Phil Bouchard wrote: >>>> Yes of course, I should have anticipated that. So one option left would >>>> be to: >>>> - compile the Javascript file for each architecture / platform >>>> - link that "jex" to a portable dynamic library API >>>> - run native containers (Hyper-V on Windows I think) >>>> - run the "jex" executable in that native container >>> >>> Hyper-V is not a container. >>> >>> Containers are not completely secure. That's why we spent the >>> engineering >>> effort of making the Clear Containers, so that the processor's virtual >>> machine >>> protections kick in. >>> >>> And you could investigate NaCl. >> >> I will but you get the idea. > > Like I was saying, there was a bug in my code and perhaps it's > impossible for Javascript to run without a GC indeed. > > But that doesn't mean that we couldn't run executables in one of those > specialized containers. And although I like the concept of these quick > function callbacks in Javascript, I do not like the 'escape analysis' > thing and I think this should be trashed because the ratio costs / > benefits isn't profitable enough. > > Perhaps we could derive a new language from Javascript and C++ which > could be run inside these specialized containers. I already have a > parser and only minor changes are necessary. If people want speed then > there is no other way. And if I remove that run-time stack thing then the generated code will be even more efficient. -Phil From Sudhir.Sharma at mindtree.com Mon Jul 17 06:33:19 2017 From: Sudhir.Sharma at mindtree.com (Sudhir Sharma) Date: Mon, 17 Jul 2017 04:33:19 +0000 Subject: [Development] QWebEngineView Print In-Reply-To: References: Message-ID: Kevin, Thanks very much for your response. Just upgrading QtWebEngine to 5.8 or 5.9 will suffice my requirement. Exploring how can I do that as I have not built QT but using QT installer in Visual Studio 2013. Do you have any idea if it can be done in my scenario? Regards, Sudhir -----Original Message----- From: Development [mailto:development-bounces+sudhir.sharma=mindtree.com at qt-project.org] On Behalf Of Kevin Kofler Sent: Friday, July 14, 2017 4:21 PM To: development at qt-project.org Subject: Re: [Development] QWebEngineView Print * You are receiving this mail from an external source * Sudhir Sharma wrote: > How can we print html loaded in QWebEngineView in QT 5.7? In 5.7, you can only print by first printing to PDF and then invoking something external to actually send the PDF to a printer. See the code (submitted by me) in QupZilla 2.1.x (and currently also in master/2.2, but since that requires Qt 5.8, it may be ported to the direct print method soon, I've been wanting to look into that for a while). But that code assumes the lpr executable is available on *nix, and there is an implementation for Windows that is rather suboptimal (invokes the configured PDF viewer and asks it to print). You may want to upgrade to 5.8 or 5.9, where you just have to invoke the print method. It is also possible to upgrade QtWebEngine to 5.8 or 5.9 while keeping Qt 5.7, you will just need this one-line fix: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/plain/qtwebengine-opensource-src-5.8.0-qt57.patch and you may want to explicitly enable spellchecking, which is disabled by default when building against Qt 5.7: WEBENGINE_CONFIG+=use_spellchecker and if you are using CMake, you will likely also need this tweak on the installed QtWebEngineConfig*.cmake files: sed -i -e "s|%{version} \${_Qt5WebEngine|%{_qt5_version} \${_Qt5WebEngine|" \ %{buildroot}%{_qt5_libdir}/cmake/Qt5WebEngine*/Qt5WebEngine*Config.cmake QtWebEngine is the only part that of Qt you need to upgrade to get the print method. Kevin Kofler _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development ________________________________ http://www.mindtree.com/email/disclaimer.html From thiago.macieira at intel.com Mon Jul 17 07:19:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Jul 2017 22:19:58 -0700 Subject: [Development] QWebEngineView Print In-Reply-To: References: Message-ID: <65231545.jv7fgfHJlc@tjmaciei-mobl1> On domingo, 16 de julho de 2017 21:33:19 PDT Sudhir Sharma wrote: > Kevin, > > Thanks very much for your response. Just upgrading QtWebEngine to 5.8 or 5.9 > will suffice my requirement. Exploring how can I do that as I have not > built QT but using QT installer in Visual Studio 2013. > > Do you have any idea if it can be done in my scenario? It cannot. Upgrade to VS2015 if you want QtWebEngine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From vincenthk007 at gmail.com Tue Jul 18 17:09:15 2017 From: vincenthk007 at gmail.com (Vincent Hui) Date: Tue, 18 Jul 2017 23:09:15 +0800 Subject: [Development] When will Qt Remote Objects become an official Qt module? Message-ID: Hi, I plan to use Qt Remote Objects in my project. Therefore, I would like to know when Qt Remote Objects will become an official Qt module. Will it be an office module of Qt 5.10 ? Best regards, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jul 18 17:41:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 18 Jul 2017 08:41:34 -0700 Subject: [Development] When will Qt Remote Objects become an official Qt module? In-Reply-To: References: Message-ID: <1719155.s11q9mV4z3@tjmaciei-mobl1> On terça-feira, 18 de julho de 2017 08:09:15 PDT Vincent Hui wrote: > Hi, > > I plan to use Qt Remote Objects in my project. Therefore, I would like to > know when Qt Remote Objects will become an official Qt module. Will it be > an office module of Qt 5.10 ? $ grep qtrepotools .gitmodules [submodule "qtrepotools"] path = qtrepotools url = ../qtrepotools.git That's official for me. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bstottle at ford.com Tue Jul 18 17:48:49 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Tue, 18 Jul 2017 15:48:49 +0000 Subject: [Development] When will Qt Remote Objects become an official Qt module? In-Reply-To: References: Message-ID: <6A206E82-EB7A-47A5-861F-E961053C76E8@ford.com> On 7/18/17, 11:09 AM, "Development on behalf of Vincent Hui" wrote: > I plan to use Qt Remote Objects in my project. Therefore, I would like to know when Qt Remote Objects will become an official Qt module. Will it be an office module of Qt 5.10 ? Hi Vincent, No, Qt Remote Objects will continue as a Tech Preview in 5.10. The reason isn’t stability, but a) I have some additions I’d still like to make and I’d like to protect incompatible API changes and b) the documentation still needs updating. Regards, Brett From vincenthk007 at gmail.com Tue Jul 18 17:58:43 2017 From: vincenthk007 at gmail.com (Vincent Hui) Date: Tue, 18 Jul 2017 23:58:43 +0800 Subject: [Development] When will Qt Remote Objects become an official Qt module? In-Reply-To: <6A206E82-EB7A-47A5-861F-E961053C76E8@ford.com> References: <6A206E82-EB7A-47A5-861F-E961053C76E8@ford.com> Message-ID: Hi Brett, Thanks for your quick reply. Will you make additions to Qt Remote Objects in Qt 5.10? If yes, can I expect API will not be changed probably after Qt 5.10 is released? Regards, Vincent On 18 July 2017 at 23:48, Stottlemyer, Brett (B.S.) wrote: > On 7/18/17, 11:09 AM, "Development on behalf of Vincent Hui" > vincenthk007 at gmail.com> wrote: > > > I plan to use Qt Remote Objects in my project. Therefore, I would like > to know when Qt Remote Objects will become an official Qt module. Will it > be an office module of Qt 5.10 ? > > Hi Vincent, > > No, Qt Remote Objects will continue as a Tech Preview in 5.10. The reason > isn’t stability, but a) I have some additions I’d still like to make and > I’d like to protect incompatible API changes and b) the documentation still > needs updating. > > Regards, > Brett > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jul 18 20:55:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 18 Jul 2017 11:55:02 -0700 Subject: [Development] When will Qt Remote Objects become an official Qt module? In-Reply-To: <1719155.s11q9mV4z3@tjmaciei-mobl1> References: <1719155.s11q9mV4z3@tjmaciei-mobl1> Message-ID: <9151264.sNBcu5OGCq@tjmaciei-mobl1> On terça-feira, 18 de julho de 2017 08:41:34 PDT Thiago Macieira wrote: > On terça-feira, 18 de julho de 2017 08:09:15 PDT Vincent Hui wrote: > > Hi, > > > > I plan to use Qt Remote Objects in my project. Therefore, I would like to > > know when Qt Remote Objects will become an official Qt module. Will it be > > an office module of Qt 5.10 ? > > $ grep qtrepotools .gitmodules > [submodule "qtrepotools"] > path = qtrepotools > url = ../qtrepotools.git > > That's official for me. As pointed out that I had typed the wrong repo name: $ grep qtremoteobjects .gitmodules [submodule "qtremoteobjects"] path = qtremoteobjects url = ../qtremoteobjects.git -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Tue Jul 18 21:20:14 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 18 Jul 2017 19:20:14 +0000 Subject: [Development] When will Qt Remote Objects become an official Qt module? In-Reply-To: <9151264.sNBcu5OGCq@tjmaciei-mobl1> References: <1719155.s11q9mV4z3@tjmaciei-mobl1>, <9151264.sNBcu5OGCq@tjmaciei-mobl1> Message-ID: Thiago Macieira (18 July 2017 20:55) > $ grep qtremoteobjects .gitmodules ... and, to squeeze a little more information out of .gitmodules: $ grep -A 5 'submodule "qtremoteobjects"' .gitmodules [submodule "qtremoteobjects"] depends = qtbase path = qtremoteobjects url = ../qtremoteobjects branch = dev status = preview So it remains a preview (this is in dev, which shall presumably branch 5.10 reasonably soon), Eddy. From Sudhir.Sharma at mindtree.com Thu Jul 20 11:56:25 2017 From: Sudhir.Sharma at mindtree.com (Sudhir Sharma) Date: Thu, 20 Jul 2017 09:56:25 +0000 Subject: [Development] QTWebEngine Compilation failure Message-ID: Hi, I am not able to compile QtWebEngine. Upon compilation of entite source I notice the QtWebEngine has not been builit. If I try to compile it separately, I get following error. C:\Qt\Qt5\5.9.1\Src\qtwebengine>qmake Running configure tests Checking for alsa... no Checking for khr... no Checking for libvpx... no Checking for snappy... no Checking for srtp... no Checking for winversion... no Configurable features: Proprietary codecs (H264, MP3) ..... Not enabled (Default, enable with -proprietary-codecs) Geolocation ........................ Enabled Needs VS 2015 Update 3 with Cumulative Servicing Release or higher QtWebEngine will not be built. Looking at bugreports.qt, it appears to have been resolved. But no idea about the solution. My Environment Details: Qt 5.9.1 Platform: windows 2012 server Microsoft Visual Studio Community 2015 Version 14.0.25431.01 Update 3 Regards, Sudhir ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.klocek at qt.io Thu Jul 20 12:28:27 2017 From: michal.klocek at qt.io (Michal Klocek) Date: Thu, 20 Jul 2017 12:28:27 +0200 Subject: [Development] QTWebEngine Compilation failure In-Reply-To: References: Message-ID: Hi What is the output of "cl -Bv" ? Br Michal On 07/20/2017 11:56 AM, Sudhir Sharma wrote: > Hi, > > > > I am not able to compile QtWebEngine. > > Upon compilation of entite source I notice the QtWebEngine has not been > builit. > > > > If I try to compile it separately, I get following error. > > > > C:\Qt\Qt5\5.9.1\Src\qtwebengine>qmake > > Running configure tests > > Checking for alsa... no > > Checking for khr... no > > Checking for libvpx... no > > Checking for snappy... no > > Checking for srtp... no > > Checking for winversion... no > > Configurable features: > > Proprietary codecs (H264, MP3) ..... Not enabled (Default, > enable with -proprietary-codecs) > > Geolocation ........................ Enabled > > > > Needs VS 2015 Update 3 with Cumulative Servicing Release or higher > > QtWebEngine will not be built. > > > > Looking at bugreports.qt, it appears to have been resolved. But no idea > about the solution. > > > > My Environment Details: > > > > Qt 5.9.1 > > Platform: windows 2012 server > > Microsoft Visual Studio Community 2015 > > Version 14.0.25431.01 Update 3 > > > > > > Regards, > > Sudhir > > > ------------------------------------------------------------------------ > > http://www.mindtree.com/email/disclaimer.html > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From michal.klocek at qt.io Thu Jul 20 12:35:41 2017 From: michal.klocek at qt.io (Michal Klocek) Date: Thu, 20 Jul 2017 12:35:41 +0200 Subject: [Development] Nominating Viktor Engelmann for Approver Status In-Reply-To: <2303742.bGZYL5T7kA@twilight> References: <2303742.bGZYL5T7kA@twilight> Message-ID: <2c144947-9201-a120-41fa-39bad66aece4@qt.io> +1 Br Michal On 07/13/2017 05:07 PM, Allan Sandfeld Jensen wrote: > On Dienstag, 11. Juli 2017 13:25:21 CEST Simon Hausmann wrote: >> Hi, >> >> >> I'd like to propose Viktor for approver status. Since August last year he's >> been contributing to QtWebEngine full-time. Based on my experience talking >> to him and working with him, I trust him to review changes thoroughly and >> approve or reject changes responsively. >> > +1 :) > > ' Allan > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From ari.salmi at snowgrains.com Thu Jul 20 13:22:05 2017 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Thu, 20 Jul 2017 14:22:05 +0300 Subject: [Development] Qt Cloud Messaging API code pushed into gerrit - comments and reviewers needed Message-ID: Hi all, Its in! :) Finally got all gerrit flags right and QtCloudMessaging API code pushed in to the codereview! I’m looking for comments and reviewers for it in order to proceed for final contribution and blog post to Qt technical blog. You can find best info about usage from the main level README.ME file. Latest commit can be found from: git fetch https://codereview.qt-project.org/qt/qtcloudmessaging refs/changes/48/200348/3 && git checkout FETCH_HEAD About examples: I moved examples into GitHub due those mobile examples include compiled ssl and crypto libs (for https communications) and therefore example file sizes coming too big for sanity bot: https://github.com/snowgrains/qtcloudmessaging-examples Thank you for all help! Br, Ari Salmi ps. There is already clients interested to integrate this to their client code, so looks good so far :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Thu Jul 20 13:51:30 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 20 Jul 2017 11:51:30 +0000 Subject: [Development] [Announce] Qt Creator 4.4 Beta released Message-ID: We are happy to announce the release of Qt Creator 4.4 Beta! http://blog.qt.io/blog/2017/07/20/qt-creator-4-4-beta-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From philippeb8 at gmail.com Fri Jul 21 06:22:36 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 21 Jul 2017 00:22:36 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS Message-ID: Greetings, I am now using C++14 standards, the error reporting is all compile-time now and I get a test that is 3.5 faster than Node.JS! You can see it by yourselves here: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp Furthermore there is no need for 'operator ->' anymore because the access operator is deduced at compile-time. Here is a code sample: int main() { int temporary = 1; auto foo = function () { return function (int argument) { return argument; }; }; for (int i = 0; i < 1000000; ++ i) cout << foo()(temporary) << endl; } Note that it's also possible to dynamically allocate function pointers like this: int main() { int temporary = 1; auto foo = new function () { return new function (int argument) { return argument; }; }; for (int i = 0; i < 1000000; ++ i) cout << foo()(temporary) << endl; } I will show you a clear example of cyclic references handling soon. So I would like to know if Qt thinks what I am proposing (BB++ -> C++ -> WebAssembly) is a good plan. Regards, -Phil http://bbplusplus.com/ From lorn.potter at gmail.com Fri Jul 21 08:10:04 2017 From: lorn.potter at gmail.com (Lorn Potter) Date: Fri, 21 Jul 2017 16:10:04 +1000 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: > On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote: > > > So I would like to know if Qt thinks what I am proposing (BB++ -> C++ -> WebAssembly) is a good plan. What does this have to do with Qt? From roland.m.winklmeier at gmail.com Fri Jul 21 12:15:54 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Fri, 21 Jul 2017 12:15:54 +0200 Subject: [Development] Behavior change for QMake install targets since 5.9 Message-ID: Dear Qt developers, since 5.9 some of my projects install targets are failing. Investigation has shown that the generated Makefiles reference now a different INSTALL executable. Before it was 'install' from GNU coreutils and now it is calling 'qmake -install qinstall'. Apart from the fact that I could not find anything in the changelog about this bigger change (only a few references that make install will no longer modify the timestamp etc), there are several behavior changes affecting existing install targets. * Installing a symbol link was deep copying the link target under the link name. Example: libfoo.so -> libfoo1.0.0.so Installing libfoo.so installed the binary libfoo.so without creating a symbol link. * Using wildcards to copy several targets is broken. Example: libfoo.so -> libfoo1.0.0.so Installing libfoo*.so fails now. Before it was copying the link and the binary. Maybe the above use cases are not the perfect solution for a specific problem, but they were working. Also there might be other features (or even bugs), users of coreutils install were relying on and are no longer available. Is this considered acceptable since the usage of coreutils install was a private configuration and developers should never rely on its behavior? Cheers R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Fri Jul 21 14:17:41 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 21 Jul 2017 12:17:41 +0000 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: References: Message-ID: Hi, Yes, it's true that "make install" used to call the GNU install for some files on Unixy platforms, sometimes cp and always copy on Windows. We've changed that in 5.9 to a new built-in command in qmake that should give consistent behavior on all platforms, including the ability to preserve the time stamps. (as you can see, with a mixture of cp, copy and install that was not a given). You should not see any difference when using "make install", but if you do, please file bug reports. Since Qt itself has installs libraries alongside with .so symlinks and those are installed as symlinks, I wonder what the difference is between Qt and your application. Can you compare the command lines generated in the Makefiles? It's true that the internal install command does not support wild-cards. We decided that it is the responsibility of the caller to resolve those (qmake). Or would you like to use this built-in internal command of qmake yourself by calling it directly? Simon ________________________________ From: Development on behalf of Roland Winklmeier Sent: Friday, July 21, 2017 12:15:54 PM To: development at qt-project.org Subject: [Development] Behavior change for QMake install targets since 5.9 Dear Qt developers, since 5.9 some of my projects install targets are failing. Investigation has shown that the generated Makefiles reference now a different INSTALL executable. Before it was 'install' from GNU coreutils and now it is calling 'qmake -install qinstall'. Apart from the fact that I could not find anything in the changelog about this bigger change (only a few references that make install will no longer modify the timestamp etc), there are several behavior changes affecting existing install targets. * Installing a symbol link was deep copying the link target under the link name. Example: libfoo.so -> libfoo1.0.0.so Installing libfoo.so installed the binary libfoo.so without creating a symbol link. * Using wildcards to copy several targets is broken. Example: libfoo.so -> libfoo1.0.0.so Installing libfoo*.so fails now. Before it was copying the link and the binary. Maybe the above use cases are not the perfect solution for a specific problem, but they were working. Also there might be other features (or even bugs), users of coreutils install were relying on and are no longer available. Is this considered acceptable since the usage of coreutils install was a private configuration and developers should never rely on its behavior? Cheers R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Fri Jul 21 14:49:03 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 21 Jul 2017 14:49:03 +0200 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: References: Message-ID: <20170721124903.GH18408@troll08> On Fri, Jul 21, 2017 at 12:17:41PM +0000, Simon Hausmann wrote: > It's true that the internal install command does not support wild-cards. > We decided that it is the responsibility of the caller to resolve those > (qmake). > we did? :} as much as i despise wildcards in source file lists, this behavior is actually documented for INSTALLS. compare https://bugreports.qt.io/browse/QTCREATORBUG-17935 (on the upside, qmake is now consistent with qtc :D). From Simon.Hausmann at qt.io Fri Jul 21 14:55:26 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 21 Jul 2017 12:55:26 +0000 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: <20170721124903.GH18408@troll08> References: , <20170721124903.GH18408@troll08> Message-ID: I was under the impression that http://code.qt.io/cgit/qt/qtbase.git/tree/qmake/generators/makefile.cpp#n1304 was the code path hit if the entry in foo.files is not a "//real file or target" (as per the comment a little above). Simon ________________________________ From: Development on behalf of Oswald Buddenhagen Sent: Friday, July 21, 2017 2:49:03 PM To: development at qt-project.org Subject: Re: [Development] Behavior change for QMake install targets since 5.9 On Fri, Jul 21, 2017 at 12:17:41PM +0000, Simon Hausmann wrote: > It's true that the internal install command does not support wild-cards. > We decided that it is the responsibility of the caller to resolve those > (qmake). > we did? :} as much as i despise wildcards in source file lists, this behavior is actually documented for INSTALLS. compare https://bugreports.qt.io/browse/QTCREATORBUG-17935 (on the upside, qmake is now consistent with qtc :D). _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.m.winklmeier at gmail.com Fri Jul 21 17:39:15 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Fri, 21 Jul 2017 17:39:15 +0200 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: References: Message-ID: Hi Simon, Preamble: The problem I was trying to solve with wildcards was to install a shared library target into two different directories. The first directory is installed with a simple 'INSTALLS += target' line. The other path is installed manually by a second INSTALLS definition and the files are selected with a wild card. This was the easiest solution at the time and the documentation said it was fine to do so. > Since Qt itself has installs libraries alongside with .so symlinks and > those are installed as symlinks, I wonder what the difference is between Qt > and your application. Can you compare the command lines generated in the > Makefiles? > I've checked the Makefiles. The only difference is that -$(INSTALL_FILE) is replaced by -$(QINSTALL). The problem here is that make install used to be able to handle wildcards during install time. QMake isn't. The difference between Qt and my application is explained in the preamble (install to second directory). > It's true that the internal install command does not support wild-cards. > We decided that it is the responsibility of the caller to resolve those > (qmake). > The problem I have is that the build products are not yet available when qmake is running. Qmake *is* able to resolve wild cards if the files are available when qmake is running. But the products aren't existing yet. With Qt 5.8 the install command line was something like -$(INSTALL) /path/to/libfoo* $(INSTALL_ROOT)/path/to/install/libfoo* which was perfectly ok on most OS's. I think only MacOS didn't like it. But now its -$(QINSTALL) /path/to/libfoo* $(INSTALL_ROOT)/path/to/install/libfoo* and I get the error "Error: usage: [-exe] source target. I can completely understand that the installation behavior needed to be aligned across all operating systems. If we could revise the decision to no allow wild cards, I would be very happy about it. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jul 21 17:41:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 21 Jul 2017 08:41:41 -0700 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: References: Message-ID: <2364370.WM3EK9zHKH@tjmaciei-mobl1> On Friday, 21 July 2017 05:17:41 PDT Simon Hausmann wrote: > Since Qt itself has installs libraries alongside with .so symlinks and those > are installed as symlinks, I wonder what the difference is between Qt and > your application. Can you compare the command lines generated in the > Makefiles? It doesn't use $(INSTALL) for those: install_target: first FORCE @test -d $(INSTALL_ROOT)/home/tjmaciei/obj/qt/installed/lib64 || mkdir -p $(INSTALL_ROOT)/home/tjmaciei/obj/qt/installed/lib64 -$(QINSTALL_PROGRAM) ../../lib/$(TARGET) $(INSTALL_ROOT)/home/ tjmaciei/obj/qt/installed/lib64/$(TARGET) -$(STRIP) --strip-unneeded $(INSTALL_ROOT)/home/tjmaciei/obj/qt/ installed/lib64/$(TARGET) -$(SYMLINK) $(TARGET) $(INSTALL_ROOT)/home/tjmaciei/obj/qt/installed/ lib64/$(TARGET0) Noe that this creates a new symlink on the destination. It doesn't try to copy the existing symlink over to the destination. Top of the Makefile has: INSTALL_FILE = install -m 644 -p INSTALL_PROGRAM = install -m 755 -p INSTALL_DIR = cp -f -R QINSTALL = /home/tjmaciei/obj/qt/qt5-release/qtbase/bin/qmake -install qinstall QINSTALL_PROGRAM = /home/tjmaciei/obj/qt/qt5-release/qtbase/bin/qmake -install qinstall -exe DEL_FILE = rm -f SYMLINK = ln -f -s So any rules that have commands using $(INSTALL_FILE) will continue to work. If the rule is now using QINSTALL, that means its commands were generated by qmake. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Fri Jul 21 17:48:01 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 21 Jul 2017 11:48:01 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On 07/21/2017 02:10 AM, Lorn Potter wrote: > >> On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote: >> >> >> So I would like to know if Qt thinks what I am proposing (BB++ -> C++ -> WebAssembly) is a good plan. > > What does this have to do with Qt? For a web engine I don't think it's possible to swap the Javascript engine entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly sequence. For the QML / Javascript dual then it could be replaced by with the QML / BB++ dual and, which harness the power of C++14 and Root.Ptr and we can just let the compiler do the hard work. Thanks, -Phil From cristian.adam at gmail.com Fri Jul 21 18:00:30 2017 From: cristian.adam at gmail.com (Cristian Adam) Date: Fri, 21 Jul 2017 18:00:30 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On Fri, Jul 21, 2017 at 5:48 PM, Phil Bouchard wrote: > On 07/21/2017 02:10 AM, Lorn Potter wrote: > >> >> On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote: >>> >>> >>> So I would like to know if Qt thinks what I am proposing (BB++ -> C++ -> >>> WebAssembly) is a good plan. >>> >> >> What does this have to do with Qt? >> > > For a web engine I don't think it's possible to swap the Javascript engine > entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly > sequence. > > For the QML / Javascript dual then it could be replaced by with the QML / > BB++ dual and, which harness the power of C++14 and Root.Ptr and we can > just let the compiler do the hard work. > Does this mean that you can turn QML to C++ code and compile just C++ code? If so, wouldn't this render Qt Quick Compiler obsolete? Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Fri Jul 21 18:16:31 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 21 Jul 2017 16:16:31 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: Message-ID: Cristian Adam wrote: > On Fri, Jul 21, 2017 at 5:48 PM, Phil Bouchard wrote: > >> On 07/21/2017 02:10 AM, Lorn Potter wrote: >> >>> >>> On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote: >>>> >>>> >>>> So I would like to know if Qt thinks what I am proposing (BB++ -> C++ -> >>>> WebAssembly) is a good plan. >>>> >>> >>> What does this have to do with Qt? >>> >> >> For a web engine I don't think it's possible to swap the Javascript engine >> entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly >> sequence. >> >> For the QML / Javascript dual then it could be replaced by with the QML / >> BB++ dual and, which harness the power of C++14 and Root.Ptr and we can >> just let the compiler do the hard work. >> > > Does this mean that you can turn QML to C++ code and compile just C++ code? > If so, wouldn't this render Qt Quick Compiler > obsolete? Yes basically on one hand but you will benefit from getting the garbage collector away on the other hand. From kevin.kofler at chello.at Sat Jul 22 05:40:44 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 22 Jul 2017 05:40:44 +0200 Subject: [Development] Behavior change for QMake install targets since 5.9 References: Message-ID: Roland Winklmeier wrote: > since 5.9 some of my projects install targets are failing. Investigation > has shown that the generated Makefiles reference now a different INSTALL > executable. Before it was 'install' from GNU coreutils and now it is > calling 'qmake -install qinstall'. Would this: unix { QINSTALL=$(INSTALL_FILE) QINSTALL_PROGRAM=$(INSTALL_PROGRAM) } (in your .pro file) work around it? Kevin Kofler From thiago.macieira at intel.com Sat Jul 22 06:14:56 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 21 Jul 2017 21:14:56 -0700 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: References: Message-ID: <1653213.mB9dJ1Oqmc@tjmaciei-mobl1> On Friday, 21 July 2017 20:40:44 PDT Kevin Kofler wrote: > Roland Winklmeier wrote: > > since 5.9 some of my projects install targets are failing. Investigation > > has shown that the generated Makefiles reference now a different INSTALL > > executable. Before it was 'install' from GNU coreutils and now it is > > calling 'qmake -install qinstall'. > > Would this: > unix { > QINSTALL=$(INSTALL_FILE) > QINSTALL_PROGRAM=$(INSTALL_PROGRAM) > } > (in your .pro file) work around it? No, those are Makefile variables, not qmake ones. qmake writes them unconditionally: t << "QINSTALL = " << var("QMAKE_QMAKE") << " -install qinstall" << endl; t << "QINSTALL_PROGRAM = " << var("QMAKE_QMAKE") << " -install qinstall - exe" << endl; The only way to override them is to trick qmake into adding something to the Makefile that it doesn't expect to. Needless to say, brittle and unsupported. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Sat Jul 22 06:17:09 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 00:17:09 -0400 Subject: [Development] [BB++] Now fixes all of your memory leak nightmares Message-ID: Greetings, Now I have an example showing off the cyclic reference handling. Please see: https://github.com/philippeb8/root_ptr/blob/bb++/bbpp2cpp/tests/input2.bb This program correctly outputs: Document::Document(const boost::node_proxy&) auto __0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) Document::~Document() 2 Document::~Document() So I just came to realize we could use this tool to parse entire projects to generate the right C++ code, after having disabled the 'operator delete', and then run the executable, which still is 3.5x faster than Node.JS. For the newcomer please see: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I am going to present this to NASA and company. Meanwhile anybody is welcome to let me know about my original plan. Regards, -Phil http://bbplusplus.com/ From vladstelmahovsky at gmail.com Sat Jul 22 11:52:09 2017 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Sat, 22 Jul 2017 11:52:09 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: Phil, Can you please explain benefits of having C++ -> WebAssembly ? thanks On Fri, Jul 21, 2017 at 5:48 PM, Phil Bouchard wrote: > On 07/21/2017 02:10 AM, Lorn Potter wrote: > >> >> On 21 Jul 2017, at 2:22 pm, Phil Bouchard wrote: >>> >>> >>> So I would like to know if Qt thinks what I am proposing (BB++ -> C++ -> >>> WebAssembly) is a good plan. >>> >> >> What does this have to do with Qt? >> > > For a web engine I don't think it's possible to swap the Javascript engine > entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly > sequence. > > For the QML / Javascript dual then it could be replaced by with the QML / > BB++ dual and, which harness the power of C++14 and Root.Ptr and we can > just let the compiler do the hard work. > > > Thanks, > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sat Jul 22 17:43:42 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 11:43:42 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote: > Phil, > Can you please explain benefits of having C++ -> WebAssembly ? Assembling speed (about 20% faster) and execution speed (about 3.5x faster): http://webassembly.org/docs/faq/ Regards, -Phil From dangelog at gmail.com Sat Jul 22 18:01:37 2017 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sat, 22 Jul 2017 18:01:37 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On 21 July 2017 at 17:48, Phil Bouchard wrote: > For a web engine I don't think it's possible to swap the Javascript engine > entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly > sequence. > > For the QML / Javascript dual then it could be replaced by with the QML / > BB++ dual and, which harness the power of C++14 and Root.Ptr and we can just > let the compiler do the hard work. But do you have such a QML/BB++ engine? Or is it just a random proposition? -- Giuseppe D'Angelo From philippeb8 at gmail.com Sat Jul 22 18:22:38 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 12:22:38 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On 07/22/2017 12:01 PM, Giuseppe D'Angelo wrote: > On 21 July 2017 at 17:48, Phil Bouchard wrote: >> For a web engine I don't think it's possible to swap the Javascript engine >> entirely but it is possible to introduce the BB++ -> C++ -> WebAssembly >> sequence. >> >> For the QML / Javascript dual then it could be replaced by with the QML / >> BB++ dual and, which harness the power of C++14 and Root.Ptr and we can just >> let the compiler do the hard work. > > But do you have such a QML/BB++ engine? Or is it just a random proposition? No not yet but honestly I don't think it would be very complicated because all you have to do is: - Replace all pointer or gc types with the 'auto' keyword in the QML parser - Use standard 'operator new' - Make sure the embedded Javascript code is replaced with BB++ - Run the BBPP2CPP parser - Compile the generated code using the C++14 standards - Execute That's it. Once again I'm here to help Qt because I've been using Qt for a long time and I think QML/BB++ is a perfect combination. Thanks, -Phil From vladstelmahovsky at gmail.com Sat Jul 22 19:02:35 2017 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Sat, 22 Jul 2017 19:02:35 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: over C++ ?? On Sat, Jul 22, 2017 at 5:43 PM, Phil Bouchard wrote: > On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote: > >> Phil, >> Can you please explain benefits of having C++ -> WebAssembly ? >> > > Assembling speed (about 20% faster) and execution speed (about 3.5x > faster): > http://webassembly.org/docs/faq/ > > > Regards, > > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sat Jul 22 19:43:43 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 17:43:43 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: Message-ID: Vlad Stelmahovsky wrote: > over C++ ?? No it's much faster than the Javascript -> JIT flow. > On Sat, Jul 22, 2017 at 5:43 PM, Phil Bouchard wrote: > >> On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote: >> >>> Phil, >>> Can you please explain benefits of having C++ -> WebAssembly ? >>> >> >> Assembling speed (about 20% faster) and execution speed (about 3.5x >> faster): >> http://webassembly.org/docs/faq/ From thiago.macieira at intel.com Sat Jul 22 19:45:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 22 Jul 2017 10:45:00 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: <4949560.5iyCDMOWl1@tjmaciei-mobl1> On Saturday, 22 July 2017 09:22:38 PDT Phil Bouchard wrote: > - Replace all pointer or gc types with the 'auto' keyword in the QML parser > - Use standard 'operator new' You have no idea how difficult this may be. It just looks easy because you haven't tried. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From o.khotskin at gmail.com Sat Jul 22 20:06:05 2017 From: o.khotskin at gmail.com (Oleg Khotskin) Date: Sun, 23 Jul 2017 01:06:05 +0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: Does anyone take this dumbass seriously? -- Best regards, Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmcdonnell at blackberry.com Sat Jul 22 20:27:23 2017 From: jmcdonnell at blackberry.com (James McDonnell) Date: Sat, 22 Jul 2017 18:27:23 +0000 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: , Message-ID: That's the sort of comment that drives new people away from open source projects. Please refrain from making such comments. Sent from my BlackBerry - the most secure mobile device - via the Rogers Network From: o.khotskin at gmail.com Sent: July 22, 2017 2:06 PM To: philippeb8 at gmail.com Cc: development at qt-project.org Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS Does anyone take this dumbass seriously? -- Best regards, Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sat Jul 22 21:37:58 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 19:37:58 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: Message-ID: Oleg Khotskin wrote: > Does anyone take this dumbass seriously? > I bet you have a better solution From philippeb8 at gmail.com Sat Jul 22 21:45:50 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 19:45:50 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <4949560.5iyCDMOWl1@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On Saturday, 22 July 2017 09:22:38 PDT Phil Bouchard wrote: >> - Replace all pointer or gc types with the 'auto' keyword in the QML parser >> - Use standard 'operator new' > > You have no idea how difficult this may be. It just looks easy because you > haven't tried. > True but I can start with a small piece of the parser and extrapolate from there. From Jake.Petroules at qt.io Sat Jul 22 23:09:13 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sat, 22 Jul 2017 21:09:13 +0000 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: , , Message-ID: Regardless, he has a point: in more diplomatic terms, this thread and those preceding it are not promoting useful discourse, so I'd encourage others to refrain from posting further replies, and let this thread die out. Sent from my iPhone - the most secure mobile device - via the Verizon network -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io _____________________________ From: James McDonnell > Sent: Saturday, July 22, 2017 11:27 AM Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS To: Oleg Khotskin >, Phil Bouchard > Cc: development > That's the sort of comment that drives new people away from open source projects. Please refrain from making such comments. Sent from my BlackBerry - the most secure mobile device - via the Rogers Network From: o.khotskin at gmail.com Sent: July 22, 2017 2:06 PM To: philippeb8 at gmail.com Cc: development at qt-project.org Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS Does anyone take this dumbass seriously? -- Best regards, Oleg -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sun Jul 23 00:51:28 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 22 Jul 2017 18:51:28 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: You're probably making a living off memory leaks so it's obvious you get offended but I don't think being a counterproductive manager is good for the Qt company. In fact it's the first time ever I hear about a manager complaining about new technologies that is better and... free. On 07/22/2017 05:09 PM, Jake Petroules wrote: > Regardless, he has a point: in more diplomatic terms, this thread and > those preceding it are not promoting useful discourse, so I'd encourage > others to refrain from posting further replies, and let this thread die out. > > Sent from my iPhone - the most secure mobile device - via the Verizon > network > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > _____________________________ > From: James McDonnell > > Sent: Saturday, July 22, 2017 11:27 AM > Subject: Re: [Development] [BB++] Now is 3.5x faster than Node.JS > To: Oleg Khotskin >, > Phil Bouchard > > Cc: development > > > > That's the sort of comment that drives new people away from open source > projects. Please refrain from making such comments. > > Sent from my BlackBerry - the most secure mobile device - via the Rogers > Network > *From:* o.khotskin at gmail.com > *Sent:* July 22, 2017 2:06 PM > *To:* philippeb8 at gmail.com > *Cc:* development at qt-project.org > *Subject:* Re: [Development] [BB++] Now is 3.5x faster than Node.JS > > > Does anyone take this dumbass seriously? > > -- > Best regards, > Oleg > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From suy at badopi.org Sun Jul 23 08:50:36 2017 From: suy at badopi.org (Alejandro Exojo) Date: Sun, 23 Jul 2017 08:50:36 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: <1957233.1JhQXqskBK@walt> On Saturday 22 July 2017 18:51:28 Phil Bouchard wrote: > You're probably making a living off memory leaks so it's obvious you get > offended but I don't think being a counterproductive manager is good for > the Qt company. In fact it's the first time ever I hear about a manager > complaining about new technologies that is better and... free. * You still did not provide evidence that the problems in your QML application where due to the garbage collection. * You did not realize it was impossible to avoid garbage collection in JavaScript, and you had to change your plan from improving the engine performance, to add a just invented new language to the design to replace a (like it or not) well stablished, popular language. * You claimed about Objective C's ARC "This means the Apple OS leaks", again without proof, and when the technology is very very similar to the state of the art in C++ with weak and shared pointers. * You only have brought to the table an implementation that gives nothing that QObject already has. So, sorry, but if you feel rejected by the members of this list is because of dubious technical quality, not because one is "making a living off memory leaks". -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From kollix at aon.at Sun Jul 23 10:50:10 2017 From: kollix at aon.at (Martin Koller) Date: Sun, 23 Jul 2017 10:50:10 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia Message-ID: <3041679.poHKR03cbZ@lapi.koller> Hi, trying to build 5.9.1 (from downloaded qt-everywhere-opensource-src-5.9.1.tar.xz) on openSuse 42.2, I get linker errors in the qtmultimedia module, e.g. .obj/qgstreameraudiodecodersession.o: In function `WinCC_OA::QGstreamerAudioDecoderSession::configureAppSrcElement(_GObject*, _GObject*, _GParamSpec*, WinCC_OA::QGstreamerAudioDecoderSession*)': /home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtmultimedia/src/plugins/gstreamer/audiodecoder/qgstreameraudiodecodersession.cpp:154: undefined reference to `WinCC_OA::QGstAppSrc::setup(_GstElement*)' I found this symbol to be in the qgsttools_p lib but I fear the linker takes the lib from a wrong path. Looking into the qtmultimedia/src/plugins/gstreamer/audiodecoder/Makefile, I find the LIBS definition which I don't understand (Note that I'm building Qt with a namespace/libinfix): LIBS = $(SUBLIBS) -lqgsttools_p -L/usr/lib64 -L/home/abuild/rpmbuild/BUILD/qtmultimedia-opensource-src-5.9.1/lib -lQt5MultimediaWidgets -lQt5Multimedia -lQt5Widgets -lQt5Gui -lQt5Network -lQt5Core -lasound -L/home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtmultimedia/lib -lQt5MultimediaWidgetsWinCC_OA -L/home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtbase/lib -lQt5MultimediaWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA -lQt5NetworkWinCC_OA -lQt5CoreWinCC_OA -lGL -lpthread -lgstaudio-1.0 -lgstvideo-1.0 -lgstpbutils-1.0 -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lpulse-mainloop-glib -lpulse -lglib-2.0 A couple of questions: -) -lqgsttools_p as first argument BEFORE any -L would search for it in my system dirs, which is wrong. -) why is -L/usr/lib64 there (should be a std. path, no?) -) From where the heck comes this path "/home/abuild/rpmbuild/BUILD/qtmultimedia-opensource-src-5.9.1/lib" ? I don't have a /home/abuild directory on my system. This is the ONLY Makefile in the whole Qt tree which contains this path -) -lQt5MultimediaWidgets and others: why are they used here instead of the namespaced/infixed versions, which are also given but later in the line ? I just removed manually all the wrong entries in that line, being now LIBS = $(SUBLIBS) -lasound -L/home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtmultimedia/lib -lqgsttools_p -lQt5MultimediaWidgetsWinCC_OA -L/home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtbase/lib -lQt5MultimediaWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA -lQt5NetworkWinCC_OA -lQt5CoreWinCC_OA -lGL -lpthread -lgstaudio-1.0 -lgstvideo-1.0 -lgstpbutils-1.0 -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lpulse-mainloop-glib -lpulse -lglib-2.0 and with that line it links without errors. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From philippeb8 at gmail.com Sun Jul 23 16:48:48 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 10:48:48 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <1957233.1JhQXqskBK@walt> References: <1957233.1JhQXqskBK@walt> Message-ID: On 07/23/2017 02:50 AM, Alejandro Exojo wrote: > On Saturday 22 July 2017 18:51:28 Phil Bouchard wrote: >> You're probably making a living off memory leaks so it's obvious you get >> offended but I don't think being a counterproductive manager is good for >> the Qt company. In fact it's the first time ever I hear about a manager >> complaining about new technologies that is better and... free. > > * You still did not provide evidence that the problems in your QML application > where due to the garbage collection. All you have to do is create a ListView with images in the ListView Items, scroll the ListView and then you will see the ListView's scrolling speed not being uniform in an unpredictable way. Whatever's unpredictable is caused by the GC. > * You did not realize it was impossible to avoid garbage collection in > JavaScript, and you had to change your plan from improving the engine > performance, to add a just invented new language to the design to replace a > (like it or not) well stablished, popular language. "Popular" doesn't mean it's better. Have you seen how spaghetti inheritance is in Javascript? It's like Google's choice of using Java for the Android just because it's popular. But the Android hangs constantly because of the GC that runs in the background. > * You claimed about Objective C's ARC "This means the Apple OS leaks", again > without proof, and when the technology is very very similar to the state of > the art in C++ with weak and shared pointers. "ARC differs from garbage collection in that there is no background process that deallocates the objects asynchronously at runtime. Unlike garbage collection, ARC does not handle reference cycles automatically. This means that as long as there are "strong" references to an object, it will not be deallocated. Strong cross-references can accordingly create deadlocks and memory leaks. It is up to the developer to break cycles by using weak references." https://en.wikipedia.org/wiki/Automatic_Reference_Counting It's obvious developers aren't perfect either and the more complex the app is then the more likely there will be a leak. With Root.Ptr it's all handled implicitly. > * You only have brought to the table an implementation that gives nothing that > QObject already has. We're comparing BB++ with Javascript here and Javascript was chosen by Qt to glue the QML code altogether. Given the similarities of BB++ with Javascript I am just saying to favorize the former and you will get a 3.5x speed boost. > So, sorry, but if you feel rejected by the members of this list is because of > dubious technical quality, not because one is "making a living off memory > leaks". It's probably a "if it's not broken don't fix it mentality" but that doesn't fit with science and R&D. I just wanted to help Qt but I can go back to the WebKit world because WebAssembly should be mature enough now. Thanks to everybody except Jake and Oleg (tough guys here). From thiago.macieira at intel.com Sun Jul 23 18:53:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 09:53:34 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <1957233.1JhQXqskBK@walt> Message-ID: <3235982.zGXZ67aqfO@tjmaciei-mobl1> On Sunday, 23 July 2017 07:48:48 PDT Phil Bouchard wrote: > > * You still did not provide evidence that the problems in your QML > > application where due to the garbage collection. > > All you have to do is create a ListView with images in the ListView > Items, scroll the ListView and then you will see the ListView's > scrolling speed not being uniform in an unpredictable way. Whatever's > unpredictable is caused by the GC. Are you running this on a multitasking system with other processes and threads running? Maybe on a CPU and GPU that can increase and decrease the clock speed? Maybe even a CPU that has thermal-limited turbo-boost that periodically overclocks the CPU? If you are, then I think you should consider other sources of unpredictability. My experience with benchmarking very controlled and deterministic C++ code (deterministic implies no memory allocation or deallocation) is that the results vary on a system like that. > It's like Google's choice of using Java for the Android just because > it's popular. But the Android hangs constantly because of the GC that > runs in the background. That's another example of assigning blame without proof. You may be completely right and you're very likely partially right. But you need to stop blaming GC for everything. We don't know how much it's at fault for, not without evidence. > "ARC differs from garbage collection in that there is no background > process that deallocates the objects asynchronously at runtime. Unlike > garbage collection, ARC does not handle reference cycles automatically. > This means that as long as there are "strong" references to an object, > it will not be deallocated. Strong cross-references can accordingly > create deadlocks and memory leaks. It is up to the developer to break > cycles by using weak references." > > https://en.wikipedia.org/wiki/Automatic_Reference_Counting > > It's obvious developers aren't perfect either and the more complex the > app is then the more likely there will be a leak. With Root.Ptr it's all > handled implicitly. Except for the part that developers need to use root.ptr properly. As you've just written, developers aren't perfect either, so they will make mistakes. So maybe it's better to have a slightly inferior solution performance-wise that works in many more cases where the developers are making mistakes than a perfect solution that requires perfect developers. In fact, I do believe we are working on a framework that positions itself exactly like that... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 18:54:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 09:54:41 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <3041679.poHKR03cbZ@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> Message-ID: <6699433.6F6KGhILKh@tjmaciei-mobl1> On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote: > I found this symbol to be in the qgsttools_p lib but I fear the linker takes > the lib from a wrong path. If you already have Qt installed system-wide, please remove the development files. You said you're on OpenSUSE, so just remove the Qt -devel packages. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Sun Jul 23 20:01:00 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 14:01:00 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <3235982.zGXZ67aqfO@tjmaciei-mobl1> References: <1957233.1JhQXqskBK@walt> <3235982.zGXZ67aqfO@tjmaciei-mobl1> Message-ID: On 07/23/2017 12:53 PM, Thiago Macieira wrote: > On Sunday, 23 July 2017 07:48:48 PDT Phil Bouchard wrote: >>> * You still did not provide evidence that the problems in your QML >>> application where due to the garbage collection. >> >> All you have to do is create a ListView with images in the ListView >> Items, scroll the ListView and then you will see the ListView's >> scrolling speed not being uniform in an unpredictable way. Whatever's >> unpredictable is caused by the GC. > > Are you running this on a multitasking system with other processes and threads > running? Maybe on a CPU and GPU that can increase and decrease the clock > speed? Maybe even a CPU that has thermal-limited turbo-boost that periodically > overclocks the CPU? > > If you are, then I think you should consider other sources of > unpredictability. > > My experience with benchmarking very controlled and deterministic C++ code > (deterministic implies no memory allocation or deallocation) is that the > results vary on a system like that. I am running it on an Intel Core i7 laptop with an ASUS motherboard and no I stop processes like the music player before running it. >> It's like Google's choice of using Java for the Android just because >> it's popular. But the Android hangs constantly because of the GC that >> runs in the background. > > That's another example of assigning blame without proof. You may be completely > right and you're very likely partially right. But you need to stop blaming GC > for everything. We don't know how much it's at fault for, not without > evidence. You can find documentation on this all over the place: https://www.quora.com/Why-is-the-iPhones-1-GB-RAM-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202 >> "ARC differs from garbage collection in that there is no background >> process that deallocates the objects asynchronously at runtime. Unlike >> garbage collection, ARC does not handle reference cycles automatically. >> This means that as long as there are "strong" references to an object, >> it will not be deallocated. Strong cross-references can accordingly >> create deadlocks and memory leaks. It is up to the developer to break >> cycles by using weak references." >> >> https://en.wikipedia.org/wiki/Automatic_Reference_Counting >> >> It's obvious developers aren't perfect either and the more complex the >> app is then the more likely there will be a leak. With Root.Ptr it's all >> handled implicitly. > > Except for the part that developers need to use root.ptr properly. As you've > just written, developers aren't perfect either, so they will make mistakes. So > maybe it's better to have a slightly inferior solution performance-wise that > works in many more cases where the developers are making mistakes than a > perfect solution that requires perfect developers. Developer won't need to bother about Root.Ptr because I already wrote a parser to add the necessary node_proxies and metadata. And did I say errors are reported at compile-time? In QML/Javascript everything is reported at run-time; sometimes in the widget itself, sometimes on the console and sometimes none is reported and it just doesn't work! From thiago.macieira at intel.com Sun Jul 23 20:48:13 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 11:48:13 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <3235982.zGXZ67aqfO@tjmaciei-mobl1> Message-ID: <2320435.POxMKdv9nq@tjmaciei-mobl1> On Sunday, 23 July 2017 11:01:00 PDT Phil Bouchard wrote: > > My experience with benchmarking very controlled and deterministic C++ code > > (deterministic implies no memory allocation or deallocation) is that the > > results vary on a system like that. > > I am running it on an Intel Core i7 laptop with an ASUS motherboard and > no I stop processes like the music player before running it. Did you stop the email client? Did you close the browser? Maybe stopped the window manager too? You should also disconnect from the network, in case some packets arrive at the wrong time, disable turbo boost, lock the CPU into performance mode and disable all but one CPU. > > That's another example of assigning blame without proof. You may be > > completely right and you're very likely partially right. But you need to > > stop blaming GC for everything. We don't know how much it's at fault for, > > not without evidence. > > You can find documentation on this all over the place: > https://www.quora.com/Why-is-the-iPhones-1-GB-RAM-touted-to-be-able-to-compe > te-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202 That's not "documentation". It's not comparing apples to apples: it's comparing two different applications, written for two different OSes, with two different frameworks and in two different languages. There's more than just the GC at work here. And did you read the link you posted? It's saying that with enough RAM, the impact of GC is small enough to be ignored. > >> It's obvious developers aren't perfect either and the more complex the > >> app is then the more likely there will be a leak. With Root.Ptr it's all > >> handled implicitly. > > > > Except for the part that developers need to use root.ptr properly. As > > you've just written, developers aren't perfect either, so they will make > > mistakes. So maybe it's better to have a slightly inferior solution > > performance-wise that works in many more cases where the developers are > > making mistakes than a perfect solution that requires perfect developers. > > Developer won't need to bother about Root.Ptr because I already wrote a > parser to add the necessary node_proxies and metadata. The developers in question here are not the application writers, but the framework developers. You're assuming they/you won't make mistakes and that is not a valid assumption to make. > And did I say errors are reported at compile-time? In QML/Javascript > everything is reported at run-time; sometimes in the widget itself, > sometimes on the console and sometimes none is reported and it just > doesn't work! Are you comparing that to the precompiled QML? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robin.burchell at crimson.no Sun Jul 23 21:26:05 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Sun, 23 Jul 2017 21:26:05 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <1957233.1JhQXqskBK@walt> Message-ID: <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> Hi Phil, On Sun, Jul 23, 2017, at 04:48 PM, Phil Bouchard wrote: > All you have to do is create a ListView with images in the ListView > Items, scroll the ListView and then you will see the ListView's > scrolling speed not being uniform in an unpredictable way. Whatever's > unpredictable is caused by the GC. You didn't give any details about how you measured, or what you were measuring on, so I gave it a shot -- I'm sorry, but I can't replicate these results, and even with a highly artificial test case[1] that scrolls a ListView constantly, I only see one GC run every so often, and it does not delay for any sort of significant amount of time (on a 2013 mbp, running a slightly old Qt 5.9 snapshot, on OS X): [D] default: QV4::MemoryManager::runGC:987 - Marked object in 0 ms. [D] default: QV4::MemoryManager::runGC:988 - Sweeped object in 1 ms. [D] default: QV4::MemoryManager::runGC:989 - Used memory before GC: 1095008 [D] default: QV4::MemoryManager::runGC:990 - Used memory after GC: 106784 [D] default: QV4::MemoryManager::runGC:991 - Freed up bytes: 988224 [D] default: QV4::MemoryManager::runGC:992 - Freed up chunks: 14 Running with QV4_MM_STATS=1 with a newer Qt (dev branch) should also show you a more precise time (in us, rather than ms), as well as information about what object types were GC'd. In my experience, GC is not often the root cause of "janky" interaction in QML, simply because most of the allocations don't originate from there, unless you are writing a really high amount of JavaScript, or very complex bindings. The image content of the Image element for instance is not allocated through garbage collection. Much more common sources of performance problems: * doing too much (overly complex delegates, or bindings) -- creating objects, and evaluating bindings is expensive * blocking the main thread elsewhere in the application * problems with the platform or graphics stack (or their integration with QtQuick) Of course, even more often, you get some kind of a combination of the above... Anyway: my experience doesn't rule out the possibility of there being a problem, but so far I am lacking evidence that there is one (a test case), and I am lacking evidence that garbage collection is the cause of that problem (investigating that test case with QV4_MM_STATS, and other tooling). Please create a bug with a test case (simple enough that it can be run standalone like mine below) where you see more details on the performance problem you see, with information about your platform, and full details about how you measured the results (if you did any such measurements). [1]: https://gist.github.com/rburchell/3026d3229d4211f71b947e3f9eee6d9f -- run with qmlscene, setting QV4_MM_STATS=1 in the environment, to get information about when the GC runs and what the impact is. Uncomment the animation & onCompleted hook to scroll automatically (and a lot faster). -- Robin Burchell robin at crimson.no From philippeb8 at gmail.com Sun Jul 23 21:27:44 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 15:27:44 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <2320435.POxMKdv9nq@tjmaciei-mobl1> References: <3235982.zGXZ67aqfO@tjmaciei-mobl1> <2320435.POxMKdv9nq@tjmaciei-mobl1> Message-ID: On 07/23/2017 02:48 PM, Thiago Macieira wrote: > On Sunday, 23 July 2017 11:01:00 PDT Phil Bouchard wrote: >>> My experience with benchmarking very controlled and deterministic C++ code >>> (deterministic implies no memory allocation or deallocation) is that the >>> results vary on a system like that. >> >> I am running it on an Intel Core i7 laptop with an ASUS motherboard and >> no I stop processes like the music player before running it. > > Did you stop the email client? Did you close the browser? Maybe stopped the > window manager too? You should also disconnect from the network, in case some > packets arrive at the wrong time, disable turbo boost, lock the CPU into > performance mode and disable all but one CPU. Or 'renice' the process to a higher priority after having killed the browser at least. I can try later but Linux is pretty good at optimizing processes that are run multiple times so I don't think it'll make a huge difference. >>> That's another example of assigning blame without proof. You may be >>> completely right and you're very likely partially right. But you need to >>> stop blaming GC for everything. We don't know how much it's at fault for, >>> not without evidence. >> >> You can find documentation on this all over the place: >> https://www.quora.com/Why-is-the-iPhones-1-GB-RAM-touted-to-be-able-to-compe >> te-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202 > > That's not "documentation". It's not comparing apples to apples: it's > comparing two different applications, written for two different OSes, with two > different frameworks and in two different languages. There's more than just > the GC at work here. > > And did you read the link you posted? It's saying that with enough RAM, the > impact of GC is small enough to be ignored. Yes but when you have more simultaneous apps running then they will consume more RAM thus the exact same problem will occur. >>>> It's obvious developers aren't perfect either and the more complex the >>>> app is then the more likely there will be a leak. With Root.Ptr it's all >>>> handled implicitly. >>> >>> Except for the part that developers need to use root.ptr properly. As >>> you've just written, developers aren't perfect either, so they will make >>> mistakes. So maybe it's better to have a slightly inferior solution >>> performance-wise that works in many more cases where the developers are >>> making mistakes than a perfect solution that requires perfect developers. >> >> Developer won't need to bother about Root.Ptr because I already wrote a >> parser to add the necessary node_proxies and metadata. > > The developers in question here are not the application writers, but the > framework developers. You're assuming they/you won't make mistakes and that is > not a valid assumption to make. What matters is what is presented to the client and if they can use something less error-prone then the faster the apps are going to get created so it's a win-win situation. >> And did I say errors are reported at compile-time? In QML/Javascript >> everything is reported at run-time; sometimes in the widget itself, >> sometimes on the console and sometimes none is reported and it just >> doesn't work! > > Are you comparing that to the precompiled QML? Yes. From t.artikov at gmail.com Sun Jul 23 21:54:01 2017 From: t.artikov at gmail.com (=?UTF-8?B?0KLQuNC80YPRgCDQkNGA0YLQuNC60L7Qsg==?=) Date: Mon, 24 Jul 2017 02:54:01 +0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <3235982.zGXZ67aqfO@tjmaciei-mobl1> <2320435.POxMKdv9nq@tjmaciei-mobl1> Message-ID: Hi there, The reason why the ListView with images test is not performed smoothly, may be the lack of asynchronous images loading (Image.asynchronous property). -- Timur Artikov -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sun Jul 23 22:02:59 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 16:02:59 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> References: <1957233.1JhQXqskBK@walt> <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> Message-ID: On 07/23/2017 03:26 PM, Robin Burchell wrote: > > Please create a bug with a test case (simple enough that it can be run > standalone like mine below) where you see more details on the > performance problem you see, with information about your platform, and > full details about how you measured the results (if you did any such > measurements). I will later this week because I need to focus on the parser tonight to fix the access operator (dot) with expressions and initializers. But I don't understand why we have to debate that much switching a LADA for a Ferrari. BB++ is just 2 weeks old but it's already pretty dang powerful. From o.khotskin at gmail.com Sun Jul 23 22:07:40 2017 From: o.khotskin at gmail.com (Oleg Khotskin) Date: Mon, 24 Jul 2017 03:07:40 +0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <1957233.1JhQXqskBK@walt> <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> Message-ID: Dunning-Kruger effect in action. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sun Jul 23 22:19:26 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 16:19:26 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <1957233.1JhQXqskBK@walt> <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> Message-ID: On 07/23/2017 04:07 PM, Oleg Khotskin wrote: > Dunning-Kruger effect in action. It's called: "let productive people handle it and move out of the way" effect. From lorn.potter at gmail.com Sun Jul 23 22:34:48 2017 From: lorn.potter at gmail.com (Lorn Potter) Date: Mon, 24 Jul 2017 06:34:48 +1000 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: <0a9e6500-cad9-f999-0f44-ed923dd23c7b@gmail.com> On 23/7/17 3:43 am, Phil Bouchard wrote: > Vlad Stelmahovsky wrote: >> over C++ ?? > > No it's much faster than the Javascript -> JIT flow. > >> On Sat, Jul 22, 2017 at 5:43 PM, Phil Bouchard wrote: >> >>> On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote: >>> >>>> Phil, >>>> Can you please explain benefits of having C++ -> WebAssembly ? >>>> >>> >>> Assembling speed (about 20% faster) and execution speed (about 3.5x >>> faster): >>> http://webassembly.org/docs/faq/ Is this the same thing as emscripten? -- Lorn 'ljp' Potter Software Engineer, llornkcor technologies Qt Sensors / connectivity From kollix at aon.at Sun Jul 23 22:49:18 2017 From: kollix at aon.at (Martin Koller) Date: Sun, 23 Jul 2017 22:49:18 +0200 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1985491493823830@web21o.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <1985491493823830@web21o.yandex.ru> Message-ID: <1576000.qR13dCIJmj@lapi.koller> On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote: > I'm not sure it would be acceptable, because updated QtWebKit requires full > C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some > features, or with code changes, which were not done yet). I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the installed gcc compiler (4.8.5) and I get: The WebKit build was disabled for the following reasons: * Using gcc version 4.8, but at least gcc version 4.9 is required to build QtWebKit. So which features can I disable and how ? Note that gcc 4.8.5 is the std. compiler on the latest official version of openSuse and still I can not compile ... :-( I will have the same issue when I want to compile it for SLES-12-SP2 or RHEL or CentOS-7 all with gcc 4.8 It would be really nice if the current release branch would compile at least on these major distros -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From kollix at aon.at Sun Jul 23 22:49:11 2017 From: kollix at aon.at (Martin Koller) Date: Sun, 23 Jul 2017 22:49:11 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <6699433.6F6KGhILKh@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <6699433.6F6KGhILKh@tjmaciei-mobl1> Message-ID: <3426879.2rGXCDaUt2@lapi.koller> On Sonntag, 23. Juli 2017 18:54:41 CEST Thiago Macieira wrote: > On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote: > > I found this symbol to be in the qgsttools_p lib but I fear the linker takes > > the lib from a wrong path. > > If you already have Qt installed system-wide, please remove the development > files. You said you're on OpenSUSE, so just remove the Qt -devel packages. Ouch. I assume this is just a workaround, and not "the solution", right ? (I need Qt devel system files when compiling KDE, but I need to build my own Qt for company project) I can compile/link all parts of Qt, just the gstreamer plugins are a problem. Can this be solved in a clean way ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From thiago.macieira at intel.com Sun Jul 23 23:22:03 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 14:22:03 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <3426879.2rGXCDaUt2@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> <6699433.6F6KGhILKh@tjmaciei-mobl1> <3426879.2rGXCDaUt2@lapi.koller> Message-ID: <1696688.5FS0zsyFNv@tjmaciei-mobl1> On Sunday, 23 July 2017 13:49:11 PDT Martin Koller wrote: > On Sonntag, 23. Juli 2017 18:54:41 CEST Thiago Macieira wrote: > > On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote: > > > I found this symbol to be in the qgsttools_p lib but I fear the linker > > > takes the lib from a wrong path. > > > > If you already have Qt installed system-wide, please remove the > > development > > files. You said you're on OpenSUSE, so just remove the Qt -devel packages. > > Ouch. > I assume this is just a workaround, and not "the solution", right ? No, this is the solution, unless you want to build in a chroot'ed build root. In the environment where you're going to build a given software, you must not have the development packages of that software already installed. That's also why I highly recommend against using any Linux distribution that lacks the concept of development package. > (I need Qt devel system files when compiling KDE, but I need to build my own > Qt for company project) You must install and uninstall the development packages as needed then. Or set up a build root for building one or the other software. Or for both. > I can compile/link all parts of Qt, just the gstreamer plugins are a > problem. Can this be solved in a clean way ? You probably have either -L/usr/lib or -L/usr/lib64 added to your linker line. Find the source of that option (probably a pkg-config file for GStreamer) and fix there. If the issue is not a system path, then you've got the corner I mentioned. Unsolvable short of removing files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 23:15:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 14:15:54 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> Message-ID: <2006480.cy7u5sIEx1@tjmaciei-mobl1> On Sunday, 23 July 2017 13:02:59 PDT Phil Bouchard wrote: > On 07/23/2017 03:26 PM, Robin Burchell wrote: > > Please create a bug with a test case (simple enough that it can be run > > standalone like mine below) where you see more details on the > > performance problem you see, with information about your platform, and > > full details about how you measured the results (if you did any such > > measurements). > > I will later this week because I need to focus on the parser tonight to > fix the access operator (dot) with expressions and initializers. > > But I don't understand why we have to debate that much switching a LADA > for a Ferrari. BB++ is just 2 weeks old but it's already pretty dang > powerful. For two reasons: 1) your analogy is not correct 2) you're basing the entire case on an assumption that is not proven You could be building a great new language. Or a house of cards. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 21:54:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 12:54:02 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2320435.POxMKdv9nq@tjmaciei-mobl1> Message-ID: <20588530.iiNL5ocTaB@tjmaciei-mobl1> On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote: > Or 'renice' the process to a higher priority after having killed the > browser at least. Not enough. > I can try later but Linux is pretty good at optimizing > processes that are run multiple times so I don't think it'll make a huge > difference. Also not relevant. But you should avoid the disk I/O by moving all the code that is loaded into a tmpfs and use LD_BIND_NOW=1. > > That's not "documentation". It's not comparing apples to apples: it's > > comparing two different applications, written for two different OSes, with > > two different frameworks and in two different languages. There's more > > than just the GC at work here. > > > > And did you read the link you posted? It's saying that with enough RAM, > > the > > impact of GC is small enough to be ignored. > > Yes but when you have more simultaneous apps running then they will > consume more RAM thus the exact same problem will occur. A problem that can again be mitigated by adding more RAM. Sometimes it's easier/cheaper to just throw hardware at the problem than to rework the software to be more efficient. You should always design your hardware based on what you expect to run or design your software to run on the hardware that you have. If you mis-design, then you'll have problems, clearly (and that's the bane of a lot of embedded products). > > The developers in question here are not the application writers, but the > > framework developers. You're assuming they/you won't make mistakes and > > that is not a valid assumption to make. > > What matters is what is presented to the client and if they can use > something less error-prone then the faster the apps are going to get > created so it's a win-win situation. This is resting on the assumption of a less error-prone framework, which is not a given as you're using a more complex system than what is known to the developers. You're also comparing apples to apples: clients may not want this new framework, if they already used to JS. They don't want to relearn and retrain. Note the last argument can also be applied to QML vs widgets. > >> And did I say errors are reported at compile-time? In QML/Javascript > >> everything is reported at run-time; sometimes in the widget itself, > >> sometimes on the console and sometimes none is reported and it just > >> doesn't work! > > > > Are you comparing that to the precompiled QML? > > Yes. So your tool can detect errors in the same application that the QML compiler cannot? Can you give us an example? How does your tool deal with runtime code generation via eval() ? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 23:40:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 14:40:30 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <3041679.poHKR03cbZ@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> Message-ID: <1571576.QjEIOlbKPA@tjmaciei-mobl1> On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote: > -) why is -L/usr/lib64 there (should be a std. path, no?) This is the root of your problem. Something that this plugin or qgsttools_p needs to link to said that its libraries are in /usr/lib64. qmake has some code to remove system paths, but it that won't work if the path being requested is both: a) not system b) where Qt libraries are Hence: uninstall the development packages. > -) From where the heck comes this path > "/home/abuild/rpmbuild/BUILD/qtmultimedia-opensource-src-5.9.1/lib" ? > I don't have a /home/abuild directory on my system. > This is the ONLY Makefile in the whole Qt tree which contains this path The "rpmbuild" part indicates that it comes from an RPM build. So most likely this is because qmake found the qgsttools_p.prl file in /usr/lib64 and that file has bogus information. You may get away with this problem by just removing that file, as nothing outside of qtmultimedia itself should be linking against qgsttools_p. > -) -lQt5MultimediaWidgets and others: why are they used here instead of the > namespaced/infixed versions, which are also given> > but later in the line ? Same reason: the system-wide qgsttools_p.prl file was found. Even with the turning of qgsttools_p into a real Qt module (albeit internal) in commit ab6ebd360eb27a0d502839fca07ae0e6e107cec6, the infix won't help you because the infix is not stored in the .prl file. Look at my case: $ find `qmake -query QT_INSTALL_LIBS` -name \*Qt5MultimediaGstTools\* /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so.5.10 /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so.5 /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.prl /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.la /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so.5.10.0 The .prl and .la files don't have the ".t" infix. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 23:31:35 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 14:31:35 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <1696688.5FS0zsyFNv@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <3426879.2rGXCDaUt2@lapi.koller> <1696688.5FS0zsyFNv@tjmaciei-mobl1> Message-ID: <3284713.TDFyynSXK1@tjmaciei-mobl1> On Sunday, 23 July 2017 14:22:03 PDT Thiago Macieira wrote: > > (I need Qt devel system files when compiling KDE, but I need to build my > > own Qt for company project) > > You must install and uninstall the development packages as needed then. Or > set up a build root for building one or the other software. Or for both. There's another trick I use to make completely separate self-built Qt for development from the system Qt that KDE & Plasma use: I use a lib infix. That's the -qtlibinfix parameter to configure. It probably went unnoticed in several pastes I made, but it's sometimes there: text data bss dec hex filename 250649 10192 164 261005 3fb8d libQt5MultimediaGstTools.t.so.5.10.0 See that ".t" between the library name and the ".so"? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 23:29:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 14:29:19 -0700 Subject: [Development] Can QtMultimediaGstTools be static? (was: can not build 5.9.1 qtmultimedia) In-Reply-To: <3041679.poHKR03cbZ@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> Message-ID: <3511322.EEZ6cFUJkp@tjmaciei-mobl1> On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote: [cut] QtMultimediaGstTools (formerly qgsttools_p) is a shared library marked "internal_module". Does it need to be a shared library? It's linked into several plugins: src/plugins/gstreamer/audiodecoder/audiodecoder.pro:include(../common.pri) src/plugins/gstreamer/camerabin/camerabin.pro:include(../common.pri) src/plugins/gstreamer/mediacapture/mediacapture.pro:include(../common.pri) src/plugins/gstreamer/mediaplayer/mediaplayer.pro:include(../common.pri) But it's a fairly small ibrary: text data bss dec hex filename 250649 10192 164 261005 3fb8d libQt5MultimediaGstTools.t.so.5.10.0 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jul 23 23:42:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 14:42:34 -0700 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1576000.qR13dCIJmj@lapi.koller> References: <1711331493820157@web18j.yandex.ru> <1985491493823830@web21o.yandex.ru> <1576000.qR13dCIJmj@lapi.koller> Message-ID: <3819098.2ZlCcxyMun@tjmaciei-mobl1> On Sunday, 23 July 2017 13:49:18 PDT Martin Koller wrote: > It would be really nice if the current release branch would compile at least > on these major distros Sorry, it's out of our hands. The source code upstream has moved on and is using C++ features not available in GCC 4.8. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sun Jul 23 23:45:30 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 24 Jul 2017 00:45:30 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <1576000.qR13dCIJmj@lapi.koller> References: <1711331493820157@web18j.yandex.ru> <1985491493823830@web21o.yandex.ru> <1576000.qR13dCIJmj@lapi.koller> Message-ID: <3501051500846330@web26g.yandex.ru> 23.07.2017, 23:49, "Martin Koller" : > On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote: > >>  I'm not sure it would be acceptable, because updated QtWebKit requires full >>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some >>  features, or with code changes, which were not done yet). > > I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the installed > gcc compiler (4.8.5) and I get: > > The WebKit build was disabled for the following reasons: >     * Using gcc version 4.8, but at least gcc version 4.9 is required to build QtWebKit. > > So which features can I disable and how ? > > Note that gcc 4.8.5 is the std. compiler on the latest official version of openSuse and still > I can not compile ... :-( You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However this brings a degradation of user experience, especially in case of IndexedDB which was supported in previous versions. Therefore you have 3 options: 1) Disable these features and build limited version using GCC 4.8; 2) Provide patches that fix compilation with GCC 4.8 and these features enabled (it's broken now because GCC 4.8 fails to compile legal C++11 construction, namely expansion of vararg template parameter pack inside lambda expression; 3) Use a different compiler to build QtWebKit package which still can be binary compatible with the rest of the system. GCC >= 4.9 or Clang is fine > > I will have the same issue when I want to compile it for SLES-12-SP2 or RHEL or CentOS-7 > all with gcc 4.8 > > It would be really nice if the current release branch would compile at least on these major distros > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\ - against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at -- Regards, Konstantin From philippeb8 at gmail.com Mon Jul 24 00:13:50 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 18:13:50 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <20588530.iiNL5ocTaB@tjmaciei-mobl1> References: <2320435.POxMKdv9nq@tjmaciei-mobl1> <20588530.iiNL5ocTaB@tjmaciei-mobl1> Message-ID: On 07/23/2017 03:54 PM, Thiago Macieira wrote: > On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote: >> >> Yes but when you have more simultaneous apps running then they will >> consume more RAM thus the exact same problem will occur. > > A problem that can again be mitigated by adding more RAM. Sometimes it's > easier/cheaper to just throw hardware at the problem than to rework the > software to be more efficient. Well if you use more memory then you're clogging the bus. Regardless with a GC you're just postponing the problem and sooner or later the GC will have to kick-in. When that happens the OS is unusable. > You should always design your hardware based on what you expect to run or > design your software to run on the hardware that you have. If you mis-design, > then you'll have problems, clearly (and that's the bane of a lot of embedded > products). True but BB++ apps are always going to be 3.5x faster than Javascript. So if you improve the memory chips, the bus and the CPU then BB++ apps still will be 3.5x faster. >>> The developers in question here are not the application writers, but the >>> framework developers. You're assuming they/you won't make mistakes and >>> that is not a valid assumption to make. >> >> What matters is what is presented to the client and if they can use >> something less error-prone then the faster the apps are going to get >> created so it's a win-win situation. > > This is resting on the assumption of a less error-prone framework, which is > not a given as you're using a more complex system than what is known to the > developers. You're also comparing apples to apples: clients may not want this > new framework, if they already used to JS. They don't want to relearn and > retrain. There's not much to learn: - replace 'var' with 'auto' - function parameters need to be stated explicitly - closures must use global variables And honestly to write an app you already need to know: - C++ - QML - Javascript I am not sure why Javascript was chosen in the first place in QML apps because all that is really useful is the XMLHttpRequest but all that stuff could be mimicked with BB++ with a minor learning curve. But if you were to write professional apps then you need to learn the Facebook Graph API, Push Notifications, AdMobs, etc. so you can't be that stupid. > Note the last argument can also be applied to QML vs widgets. > >>>> And did I say errors are reported at compile-time? In QML/Javascript >>>> everything is reported at run-time; sometimes in the widget itself, >>>> sometimes on the console and sometimes none is reported and it just >>>> doesn't work! >>> >>> Are you comparing that to the precompiled QML? >> >> Yes. > > So your tool can detect errors in the same application that the QML compiler > cannot? Can you give us an example? Yes and I will give you an example later. > How does your tool deal with runtime code generation via eval() ? First you need to ask yourself if that function is really used a lot because I never used it but if it is then you'll have to use it like a C printf to pass the parameters, embed a compiler and compile it on-demand. From philippeb8 at gmail.com Mon Jul 24 00:20:21 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 18:20:21 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <2006480.cy7u5sIEx1@tjmaciei-mobl1> References: <1500837965.3588044.1049970640.0553E608@webmail.messagingengine.com> <2006480.cy7u5sIEx1@tjmaciei-mobl1> Message-ID: On 07/23/2017 05:15 PM, Thiago Macieira wrote: > On Sunday, 23 July 2017 13:02:59 PDT Phil Bouchard wrote: >> On 07/23/2017 03:26 PM, Robin Burchell wrote: >>> Please create a bug with a test case (simple enough that it can be run >>> standalone like mine below) where you see more details on the >>> performance problem you see, with information about your platform, and >>> full details about how you measured the results (if you did any such >>> measurements). >> >> I will later this week because I need to focus on the parser tonight to >> fix the access operator (dot) with expressions and initializers. >> >> But I don't understand why we have to debate that much switching a LADA >> for a Ferrari. BB++ is just 2 weeks old but it's already pretty dang >> powerful. > > For two reasons: > 1) your analogy is not correct > 2) you're basing the entire case on an assumption that is not proven > > You could be building a great new language. Or a house of cards. It's based on the brand new C++14 standards so the roots are strong but it removes its complexity as you can see in the generated C++ code. Also Javascript is hopeless in regards to inheritance so I'm using C++ conventions there. From fromqt at tungware.se Mon Jul 24 01:12:54 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 24 Jul 2017 01:12:54 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2320435.POxMKdv9nq@tjmaciei-mobl1> <20588530.iiNL5ocTaB@tjmaciei-mobl1> Message-ID: <06559a85-c49e-26bb-454d-01552defe581@tungware.se> On 2017-07-24 00:13, Phil Bouchard wrote: > On 07/23/2017 03:54 PM, Thiago Macieira wrote: >> On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote: .. .. .. >> How does your tool deal with runtime code generation via eval() ? > > First you need to ask yourself if that function is really used a lot > because I never used it but if it is then you'll have to use it like a C > printf to pass the parameters, embed a compiler and compile it on-demand. > But what about Qt.include? I'm helping in on a QML project that reloads QML code from db using Qt.include. They won't like having to ship different c++ compilers for their different runtimes :-( From philippeb8 at gmail.com Mon Jul 24 02:28:09 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 20:28:09 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <06559a85-c49e-26bb-454d-01552defe581@tungware.se> References: <2320435.POxMKdv9nq@tjmaciei-mobl1> <20588530.iiNL5ocTaB@tjmaciei-mobl1> <06559a85-c49e-26bb-454d-01552defe581@tungware.se> Message-ID: On 07/23/2017 07:12 PM, Henry Skoglund wrote: > On 2017-07-24 00:13, Phil Bouchard wrote: >> On 07/23/2017 03:54 PM, Thiago Macieira wrote: >>> On Sunday, 23 July 2017 12:27:44 PDT Phil Bouchard wrote: > .. > .. > .. >>> How does your tool deal with runtime code generation via eval() ? >> >> First you need to ask yourself if that function is really used a lot >> because I never used it but if it is then you'll have to use it like a >> C printf to pass the parameters, embed a compiler and compile it >> on-demand. >> > > But what about Qt.include? I'm helping in on a QML project that reloads > QML code from db using Qt.include. They won't like having to ship > different c++ compilers for their different runtimes :-( It's impossible to get rid of Javascript entirely if you want backward compatibility unfortunately so you include both the BB++ converter, the C++ compiler for new apps and Javascript interpreter to maintain old apps. From philippeb8 at gmail.com Mon Jul 24 02:30:21 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 20:30:21 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <0a9e6500-cad9-f999-0f44-ed923dd23c7b@gmail.com> References: <0a9e6500-cad9-f999-0f44-ed923dd23c7b@gmail.com> Message-ID: On 07/23/2017 04:34 PM, Lorn Potter wrote: > On 23/7/17 3:43 am, Phil Bouchard wrote: >> Vlad Stelmahovsky wrote: >>> over C++ ?? >> >> No it's much faster than the Javascript -> JIT flow. >> >>> On Sat, Jul 22, 2017 at 5:43 PM, Phil Bouchard >>> wrote: >>> >>>> On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote: >>>> >>>>> Phil, >>>>> Can you please explain benefits of having C++ -> WebAssembly ? >>>>> >>>> >>>> Assembling speed (about 20% faster) and execution speed (about 3.5x >>>> faster): >>>> http://webassembly.org/docs/faq/ > > Is this the same thing as emscripten? Yes. From philippeb8 at gmail.com Mon Jul 24 02:50:19 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 20:50:19 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <0a9e6500-cad9-f999-0f44-ed923dd23c7b@gmail.com> Message-ID: On 07/23/2017 08:30 PM, Phil Bouchard wrote: > On 07/23/2017 04:34 PM, Lorn Potter wrote: >> On 23/7/17 3:43 am, Phil Bouchard wrote: >>> Vlad Stelmahovsky wrote: >>>> over C++ ?? >>> >>> No it's much faster than the Javascript -> JIT flow. >>> >>>> On Sat, Jul 22, 2017 at 5:43 PM, Phil Bouchard >>>> wrote: >>>> >>>>> On 07/22/2017 05:52 AM, Vlad Stelmahovsky wrote: >>>>> >>>>>> Phil, >>>>>> Can you please explain benefits of having C++ -> WebAssembly ? >>>>>> >>>>> >>>>> Assembling speed (about 20% faster) and execution speed (about 3.5x >>>>> faster): >>>>> http://webassembly.org/docs/faq/ >> >> Is this the same thing as emscripten? > > Yes. No sorry. Emscripten converts C++ to Javascript. WebAssembly converts C++ to precompiled assembly language. From philippeb8 at gmail.com Mon Jul 24 05:41:26 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 23 Jul 2017 23:41:26 -0400 Subject: [Development] [BB++] Now fixes all of your memory leak nightmares In-Reply-To: References: Message-ID: On 07/22/2017 12:17 AM, Phil Bouchard wrote: > Greetings, > > Now I have an example showing off the cyclic reference handling. Please > see: > https://github.com/philippeb8/root_ptr/blob/bb++/bbpp2cpp/tests/input2.bb > > > This program correctly outputs: > > Document::Document(const boost::node_proxy&) > auto __0(boost::node_proxy&, int) > 1 > Document::Document(const boost::node_proxy&) > Document::~Document() > 2 > Document::~Document() I just fixed an important bug where the node_proxies were passed by value because of the variadic template arguments misuse; now they are passed by reference in the 'make_*' factory. Furthermore you can see by yourselves the following code example works perfectly fine now: class Document { auto head = nullptr(); auto tail = nullptr(); Document() { cout << __PRETTY_FUNCTION__ << endl; } ~Document() { cout << __PRETTY_FUNCTION__ << endl; } auto foo = function (int argument) { cout << __PRETTY_FUNCTION__ << endl; return argument; }; }; int main() { auto temporary = 1; auto document = new Document(); document.foo(temporary); auto bar = function () { auto document = new Document(); // cycle document.head = document; return document; }; cout << 1 << endl; auto result = bar().foo(temporary); cout << 2 << endl; } Correctly outputs: Document::Document(const boost::node_proxy&) auto __lambda0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) auto __lambda0(boost::node_proxy&, int) 2 Document::~Document() Document::~Document() Thank you, -Phil From thiago.macieira at intel.com Mon Jul 24 06:03:19 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 21:03:19 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <20588530.iiNL5ocTaB@tjmaciei-mobl1> Message-ID: <19270993.ORNzu0Ibcc@tjmaciei-mobl1> On Sunday, 23 July 2017 15:13:50 PDT Phil Bouchard wrote: > On 07/23/2017 03:54 PM, Thiago Macieira wrote: > > A problem that can again be mitigated by adding more RAM. Sometimes it's > > easier/cheaper to just throw hardware at the problem than to rework the > > software to be more efficient. > > Well if you use more memory then you're clogging the bus. Regardless > with a GC you're just postponing the problem and sooner or later the GC > will have to kick-in. When that happens the OS is unusable. But that's just it: the GC doesn't happen as often if you're not under memory pressure. You can postpone the GC to later and run it less often, when you're less busy. Your code can focus on being as fast as it can while the user is paying attention. Cleanup can be left undone until the user isn't paying attention. > > You should always design your hardware based on what you expect to run or > > design your software to run on the hardware that you have. If you > > mis-design, then you'll have problems, clearly (and that's the bane of a > > lot of embedded products). > > True but BB++ apps are always going to be 3.5x faster than Javascript. > So if you improve the memory chips, the bus and the CPU then BB++ apps > still will be 3.5x faster. But will they be 3.5x harder to write? 3.5x more error prone? There's a reason people use interpreted languages. There's a reason why Python is so popular for even complex applications. Mind you: I am a C++ developer. > There's not much to learn: > - replace 'var' with 'auto' > - function parameters need to be stated explicitly > - closures must use global variables That's enough to relearn. And I'm not convinced you realise how much different it will be. Finally, there's also the lack of an ecosystem. > And honestly to write an app you already need to know: > - C++ > - QML > - Javascript > > I am not sure why Javascript was chosen in the first place in QML apps > because all that is really useful is the XMLHttpRequest but all that Because we had a JS interpreter already, in QtScript. > > How does your tool deal with runtime code generation via eval() ? > > First you need to ask yourself if that function is really used a lot > because I never used it but if it is then you'll have to use it like a C > printf to pass the parameters, embed a compiler and compile it on-demand. I don't care if it is used a lot. It's used and that's enough. But this answers the fact that you did not write a complete replacement of QML. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 06:05:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 21:05:28 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> Message-ID: <2616788.yb33KDTaIH@tjmaciei-mobl1> On Sunday, 23 July 2017 15:20:21 PDT Phil Bouchard wrote: > > For two reasons: > > 1) your analogy is not correct > > 2) you're basing the entire case on an assumption that is not proven > > > > You could be building a great new language. Or a house of cards. > > It's based on the brand new C++14 standards so the roots are strong but > it removes its complexity as you can see in the generated C++ code. That proves nothing. You can write really crappy applications and frameworks on a good foundation. And you can write really good applications despite bad foundations, working around them. > Also Javascript is hopeless in regards to inheritance so I'm using C++ > conventions there. I'm not disputing the ickiness of the language. I am disputing your unproven assertions. And in one case, *disproven* assertions (see Robin's email). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From fromqt at tungware.se Mon Jul 24 06:32:12 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 24 Jul 2017 06:32:12 +0200 Subject: [Development] How to make a fancy QMap c++17 initializer_list Message-ID: Hello, I've been testing more C++17 class template auto deduction awith gcc-7, and got stuck on QMap, consider this simple test program: ------------------------------------------------------------- #include "qapplication.h" #include "qmap.h" #include "qdebug.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); QMap m = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, {5,"years"}, {3,"and"}, {6,"ago"}}; for (auto v : m) qDebug() << v; } ------------------------------------------------------------- I really would like to just write a {{Key,T}..} list but it will not compile. As a kludge/compromise it works if I write "std::pair" around the first {} pair, to force the compiler to see it my way. Then the speech of Mr. Lincoln comes out fine. In C++17 you should be able to fix this through a "User-defined deduction guide" to help the compiler. I've been trying various template one-liners but alas, I think my brain is too small. Anyone got a clue? Rgrds Henry From kollix at aon.at Mon Jul 24 07:33:07 2017 From: kollix at aon.at (Martin Koller) Date: Mon, 24 Jul 2017 07:33:07 +0200 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <3501051500846330@web26g.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <1576000.qR13dCIJmj@lapi.koller> <3501051500846330@web26g.yandex.ru> Message-ID: <38499831.a4FOfzihxK@lapi.koller> On Sonntag, 23. Juli 2017 23:45:30 CEST Konstantin Tokarev wrote: > > 23.07.2017, 23:49, "Martin Koller" : > > On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote: > > > >> I'm not sure it would be acceptable, because updated QtWebKit requires full > >> C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some > >> features, or with code changes, which were not done yet). > > > > I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the installed > > gcc compiler (4.8.5) and I get: > > > > The WebKit build was disabled for the following reasons: > > * Using gcc version 4.8, but at least gcc version 4.9 is required to build QtWebKit. > > > > So which features can I disable and how ? > > > > Note that gcc 4.8.5 is the std. compiler on the latest official version of openSuse and still > > I can not compile ... :-( > > You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However this brings a > degradation of user experience, especially in case of IndexedDB which was supported > in previous versions. Therefore you have 3 options: > > 1) Disable these features and build limited version using GCC 4.8; that brings us to the second part of my question which was not answered: how ? Is there any qmake or env var I can set ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From thiago.macieira at intel.com Mon Jul 24 07:42:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 22:42:10 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <19270993.ORNzu0Ibcc@tjmaciei-mobl1> References: <19270993.ORNzu0Ibcc@tjmaciei-mobl1> Message-ID: <7176106.xtAJeFEgCv@tjmaciei-mobl1> On Sunday, 23 July 2017 21:03:19 PDT Thiago Macieira wrote: > But that's just it: the GC doesn't happen as often if you're not under > memory pressure. You can postpone the GC to later and run it less often, > when you're less busy. Your code can focus on being as fast as it can while > the user is paying attention. Cleanup can be left undone until the user > isn't paying attention. By the way, let me point out that the first I heard the piece of wisdom above wasn't about JavaScript, but it was from a colleague who is a well-respected Linux kernel developer talking about containers. He was talking about how you need to start your containers fast, execute the task the user requested really fast and send the reply. After all of that, you're free to clean up. Latency matters too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kollix at aon.at Mon Jul 24 07:58:02 2017 From: kollix at aon.at (Martin Koller) Date: Mon, 24 Jul 2017 07:58:02 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <1571576.QjEIOlbKPA@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <1571576.QjEIOlbKPA@tjmaciei-mobl1> Message-ID: <1676133.2sVSyFRbdd@lapi.koller> On Sonntag, 23. Juli 2017 23:40:30 CEST Thiago Macieira wrote: > > -) -lQt5MultimediaWidgets and others: why are they used here instead of the > > namespaced/infixed versions, which are also given> > > but later in the line ? > > Same reason: the system-wide qgsttools_p.prl file was found. > > Even with the turning of qgsttools_p into a real Qt module (albeit internal) > in commit ab6ebd360eb27a0d502839fca07ae0e6e107cec6, the infix won't help you > because the infix is not stored in the .prl file. Look at my case: > > $ find `qmake -query QT_INSTALL_LIBS` -name \*Qt5MultimediaGstTools\* > /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so.5.10 > /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so > /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so.5 > /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.prl > /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.la > /home/tjmaciei/obj/qt/qt5/qtbase/lib/libQt5MultimediaGstTools.t.so.5.10.0 > > The .prl and .la files don't have the ".t" infix. So the bug in fact is that qt does not give a correct name for libQt5MultimediaGstTools.prl ? In fact it does use the infix for the other libs here (5.9.1), e.g. I find ./qtmultimedia/lib/libQt5MultimediaWidgetsWinCC_OA.prl -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From kevin.kofler at chello.at Mon Jul 24 07:58:30 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Jul 2017 07:58:30 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia References: <3041679.poHKR03cbZ@lapi.koller> <6699433.6F6KGhILKh@tjmaciei-mobl1> <3426879.2rGXCDaUt2@lapi.koller> <1696688.5FS0zsyFNv@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > No, this is the solution, unless you want to build in a chroot'ed build > root. In the environment where you're going to build a given software, you > must not have the development packages of that software already installed. That is utter nonsense. Any package that picks up headers or library symlinks from the old installed version instead of from the one you are currently building is buggy. Kevin Kofler From kevin.kofler at chello.at Mon Jul 24 08:01:28 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Jul 2017 08:01:28 +0200 Subject: [Development] Can QtMultimediaGstTools be static? (was: can not build 5.9.1 qtmultimedia) References: <3041679.poHKR03cbZ@lapi.koller> <3511322.EEZ6cFUJkp@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > QtMultimediaGstTools (formerly qgsttools_p) is a shared library marked > "internal_module". Does it need to be a shared library? That cannot be the solution either. Distributions really don't like static- only libraries. There are already too many of them in Qt. (Each one is one too many.) Kevin Kofler From kevin.kofler at chello.at Mon Jul 24 08:03:04 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Jul 2017 08:03:04 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia References: <3041679.poHKR03cbZ@lapi.koller> <1571576.QjEIOlbKPA@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > This is the root of your problem. Something that this plugin or > qgsttools_p needs to link to said that its libraries are in /usr/lib64. > qmake has some code to remove system paths, but it that won't work if the > path being requested is both: > a) not system > b) where Qt libraries are /usr/lib64 is most definitely a system path. This is where 64-bit libraries belong to according to the FHS. Kevin Kofler From kevin.kofler at chello.at Mon Jul 24 08:12:43 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 24 Jul 2017 08:12:43 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia References: <3041679.poHKR03cbZ@lapi.koller> <1571576.QjEIOlbKPA@tjmaciei-mobl1> <1676133.2sVSyFRbdd@lapi.koller> Message-ID: Martin Koller wrote: > So the bug in fact is that qt does not give a correct name for > libQt5MultimediaGstTools.prl ? The bug is that something tries to use -L/usr/lib64. That directory is in the default linker search path, it makes no sense to -L it, and doing it anyway messes up the search order. Kevin Kofler From thiago.macieira at intel.com Mon Jul 24 08:29:48 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 23:29:48 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: References: <3041679.poHKR03cbZ@lapi.koller> <1696688.5FS0zsyFNv@tjmaciei-mobl1> Message-ID: <6105511.X5z1u9aGXz@tjmaciei-mobl1> On Sunday, 23 July 2017 22:58:30 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > No, this is the solution, unless you want to build in a chroot'ed build > > root. In the environment where you're going to build a given software, you > > must not have the development packages of that software already installed. > > That is utter nonsense. Any package that picks up headers or library > symlinks from the old installed version instead of from the one you are > currently building is buggy. You're thinking only of a 1-software problem. This is complex when you have more than one. Take this as an example: you want to build software for your professional project but not pollute your system, so you build Qt and GStreamer 1.0 but tell it to install in /opt/myproject. That means /opt/myproject/lib/pkgconfig/gstreamer-1.0.pc file has: prefix=/opt/myproject exec_prefix=/opt/myproject libdir=/opt/myproject/lib So when Qt asks pkg-config for the path to the GStreamer library, it will print: -L/opt/myproject/lib -lgstreamer-1.0 That -L switch will make the linker find Qt libraries too. Before you say, "well, list Qt libraries first", let me add another complication: the plugin has this in the linker line: -lQt5MultimediaGstTools.t -lQt5MultimediaWidgets.t -lQt5Multimedia.t -lQt5Widgets.t -lQt5Gui.t -lQt5Network.t -lQt5Core.t but if you ldd it after compiling, you find it loaded one more library (Qt5OpenGL) because of an indirect dependency. So even if qmake listed the Qt's own -L and its libraries first (and it does), we may still have a problem due to the indirect dependency and how it's found by the linker. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 08:30:58 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 23:30:58 -0700 Subject: [Development] Can QtMultimediaGstTools be static? (was: can not build 5.9.1 qtmultimedia) In-Reply-To: References: <3041679.poHKR03cbZ@lapi.koller> <3511322.EEZ6cFUJkp@tjmaciei-mobl1> Message-ID: <2564349.tyJ0VhPlxM@tjmaciei-mobl1> On Sunday, 23 July 2017 23:01:28 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > QtMultimediaGstTools (formerly qgsttools_p) is a shared library marked > > "internal_module". Does it need to be a shared library? > > That cannot be the solution either. Distributions really don't like static- > only libraries. There are already too many of them in Qt. (Each one is one > too many.) Distributions won't care because it won't be installed. That library is only a helper for the four plugins. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 08:32:23 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 23:32:23 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <1676133.2sVSyFRbdd@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> <1571576.QjEIOlbKPA@tjmaciei-mobl1> <1676133.2sVSyFRbdd@lapi.koller> Message-ID: <3577257.FUBtETzfu3@tjmaciei-mobl1> On Sunday, 23 July 2017 22:58:02 PDT Martin Koller wrote: > So the bug in fact is that qt does not give a correct name for > libQt5MultimediaGstTools.prl ? I don't know if that's a bug. I've never felt a problem with the .prl being named like that. > In fact it does use the infix for the other libs here (5.9.1), e.g. I find > ./qtmultimedia/lib/libQt5MultimediaWidgetsWinCC_OA.prl How about qgsttools_p ? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 08:34:56 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 23 Jul 2017 23:34:56 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: References: <3041679.poHKR03cbZ@lapi.koller> <1571576.QjEIOlbKPA@tjmaciei-mobl1> Message-ID: <10102090.YhNSR2mURB@tjmaciei-mobl1> On Sunday, 23 July 2017 23:03:04 PDT Kevin Kofler wrote: > Thiago Macieira wrote: > > This is the root of your problem. Something that this plugin or > > qgsttools_p needs to link to said that its libraries are in /usr/lib64. > > qmake has some code to remove system paths, but it that won't work if the > > > > path being requested is both: > > a) not system > > b) where Qt libraries are > > /usr/lib64 is most definitely a system path. This is where 64-bit libraries > belong to according to the FHS. Agreed. You have a double (or even triple) failure causing your problem. qmake should have removed /usr/lib64 but didn't. That means the configure detection of what the system linker paths are failed. See any of the .qmake.stash files to see what it did detect, if anything. Then there's the second issue that something did add /usr/lib64. It shouldn't have. But it might be from a .prl file, which is much stupider than pkg-config. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Jul 24 09:00:36 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 24 Jul 2017 09:00:36 +0200 Subject: [Development] =?utf-8?q?How_to_make_a_fancy_QMap_c++17_initializ?= =?utf-8?q?er=5Flist?= In-Reply-To: References: Message-ID: Hi, We haven't added deduction guides to any Qt class, yet. If you want to use bleeding-edge C++, use C++, iow: std::map. Patches welcome, bug reports accepted. Thanks, Marc On 2017-07-24 06:32, Henry Skoglund wrote: > Hello, I've been testing more C++17 class template auto deduction > awith gcc-7, and got stuck on QMap, consider this simple test program: > > ------------------------------------------------------------- > #include "qapplication.h" > #include "qmap.h" > #include "qdebug.h" > > int main(int argc, char *argv[]) > { > QApplication a(argc, argv); > > QMap m = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, > {5,"years"}, {3,"and"}, {6,"ago"}}; > > for (auto v : m) > qDebug() << v; > } > ------------------------------------------------------------- > > I really would like to just write a {{Key,T}..} list but it will not > compile. As a kludge/compromise it works if I write "std::pair" around > the first {} pair, to force the compiler to see it my way. Then the > speech of Mr. Lincoln comes out fine. > > In C++17 you should be able to fix this through a "User-defined > deduction guide" to help the compiler. I've been trying various > template one-liners but alas, I think my brain is too small. Anyone > got a clue? > > Rgrds Henry > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From fromqt at tungware.se Mon Jul 24 09:23:38 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 24 Jul 2017 09:23:38 +0200 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: References: Message-ID: <81d35e39-c4da-10bd-9a51-37a8acaa87d9@tungware.se> Hi, I think there are almost no need for deduction guides, for example a similar program using QVector compiles fine on gcc-7: -------------------------------------------------------------- #include "qapplication.h" #include "qvector.h" #include "qdebug.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); QVector vec = {"Now", "is", "the", "time", "for", "all"}; for (auto v : vec) qDebug() << v; } -------------------------------------------------------------- It's just QMap that I got stuck on, but as you say, it's very bleeding edge, mostly for showing off :-) /Henry On 2017-07-24 09:00, Marc Mutz wrote: > Hi, > > We haven't added deduction guides to any Qt class, yet. If you want to > use bleeding-edge C++, use C++, iow: std::map. > > Patches welcome, bug reports accepted. > > Thanks, > Marc > > On 2017-07-24 06:32, Henry Skoglund wrote: >> Hello, I've been testing more C++17 class template auto deduction >> awith gcc-7, and got stuck on QMap, consider this simple test program: >> >> ------------------------------------------------------------- >> #include "qapplication.h" >> #include "qmap.h" >> #include "qdebug.h" >> >> int main(int argc, char *argv[]) >> { >> QApplication a(argc, argv); >> >> QMap m = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, >> {5,"years"}, {3,"and"}, {6,"ago"}}; >> >> for (auto v : m) >> qDebug() << v; >> } >> ------------------------------------------------------------- >> >> I really would like to just write a {{Key,T}..} list but it will not >> compile. As a kludge/compromise it works if I write "std::pair" around >> the first {} pair, to force the compiler to see it my way. Then the >> speech of Mr. Lincoln comes out fine. >> >> In C++17 you should be able to fix this through a "User-defined >> deduction guide" to help the compiler. I've been trying various >> template one-liners but alas, I think my brain is too small. Anyone >> got a clue? >> >> Rgrds Henry >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > From oswald.buddenhagen at qt.io Mon Jul 24 11:15:12 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 24 Jul 2017 11:15:12 +0200 Subject: [Development] Behavior change for QMake install targets since 5.9 In-Reply-To: References: <20170721124903.GH18408@troll08> Message-ID: <20170724091512.GI18408@troll08> On Fri, Jul 21, 2017 at 02:55:26PM +0200, Simon Hausmann wrote: > I was under the impression that > > > [1]http://code.qt.io/cgit/qt/qtbase.git/tree/qmake/generators/makefile.cpp#n1304 > > was the code path hit if the entry in foo.files is not a "//real file or > target" (as per the comment a little above). > that won't work for make-time generated files, which is precisely the case for the .so.* files. of course, the root cause here is that files with known file names are referred to by wildcard, but we still can't break that "just so". From oswald.buddenhagen at qt.io Mon Jul 24 12:48:55 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 24 Jul 2017 12:48:55 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: References: <3041679.poHKR03cbZ@lapi.koller> <6699433.6F6KGhILKh@tjmaciei-mobl1> <3426879.2rGXCDaUt2@lapi.koller> <1696688.5FS0zsyFNv@tjmaciei-mobl1> Message-ID: <20170724104855.GJ18408@troll08> On Mon, Jul 24, 2017 at 07:58:30AM +0200, Kevin Kofler wrote: > Thiago Macieira wrote: > > No, this is the solution, unless you want to build in a chroot'ed build > > root. In the environment where you're going to build a given software, you > > must not have the development packages of that software already installed. > > That is utter nonsense. > yes, it's one of thiago's pet peeves. ;) > Any package that picks up headers or library symlinks from the old > installed version instead of from the one you are currently building > is buggy. > https://bugreports.qt.io/browse/QTBUG-50921 From kollix at aon.at Mon Jul 24 13:21:07 2017 From: kollix at aon.at (Martin Koller) Date: Mon, 24 Jul 2017 13:21:07 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <3577257.FUBtETzfu3@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <1676133.2sVSyFRbdd@lapi.koller> <3577257.FUBtETzfu3@tjmaciei-mobl1> Message-ID: <11133615.bEGQvS4KSj@lapi.koller> On Montag, 24. Juli 2017 08:32:23 CEST Thiago Macieira wrote: > On Sunday, 23 July 2017 22:58:02 PDT Martin Koller wrote: > > So the bug in fact is that qt does not give a correct name for > > libQt5MultimediaGstTools.prl ? > > I don't know if that's a bug. I've never felt a problem with the .prl being > named like that. > > > In fact it does use the infix for the other libs here (5.9.1), e.g. I find > > ./qtmultimedia/lib/libQt5MultimediaWidgetsWinCC_OA.prl > > How about qgsttools_p ? > I have the following files under qtmultimedia ./lib/libQt5MultimediaWidgetsWinCC_OA.prl ./lib/libqgsttools_p.prl ./lib/libQt5MultimediaWinCC_OA.prl -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From kollix at aon.at Mon Jul 24 13:26:55 2017 From: kollix at aon.at (Martin Koller) Date: Mon, 24 Jul 2017 13:26:55 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <10102090.YhNSR2mURB@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <10102090.YhNSR2mURB@tjmaciei-mobl1> Message-ID: <17071504.XVlvsLW2Yx@lapi.koller> On Montag, 24. Juli 2017 08:34:56 CEST Thiago Macieira wrote: > On Sunday, 23 July 2017 23:03:04 PDT Kevin Kofler wrote: > > Thiago Macieira wrote: > > > This is the root of your problem. Something that this plugin or > > > qgsttools_p needs to link to said that its libraries are in /usr/lib64. > > > qmake has some code to remove system paths, but it that won't work if the > > > > > > path being requested is both: > > > a) not system > > > b) where Qt libraries are > > > > /usr/lib64 is most definitely a system path. This is where 64-bit libraries > > belong to according to the FHS. > > Agreed. You have a double (or even triple) failure causing your problem. > > qmake should have removed /usr/lib64 but didn't. That means the configure > detection of what the system linker paths are failed. See any of the > .qmake.stash files to see what it did detect, if anything. QMAKE_CXX.LIBDIRS = \ /usr/lib64/gcc/x86_64-suse-linux/4.8 \ /usr/lib64 \ /lib64 \ /usr/x86_64-suse-linux/lib \ /lib \ /usr/lib > Then there's the second issue that something did add /usr/lib64. It shouldn't > have. But it might be from a .prl file, which is much stupider than pkg-config. That comes from the system installed /usr/lib64/libqgsttools_p.prl which was installed by the openSuse rpm libqt5-qtmultimedia-devel-5.9.1 it contains: QMAKE_PRO_INPUT = gsttools.pro QMAKE_PRL_TARGET = libqgsttools_p.so.1.0.0 QMAKE_PRL_CONFIG = lex yacc depend_includepath testcase_targets import_plugins import_qpa_plugin qt_build_extra file_copies qmake_use qt warn_on release link_prl incremental shared release linux unix posix gcc sse2 sse3 ssse3 sse4_1 sse4_2 avx avx2 compile_examples enable_new_dtags f16c largefile nostrip prefix_build force_independent utf8_source create_prl link_prl prepare_docs qt_docs_targets no_private_qt_headers_warning QTDIR_build qt_example_installs exceptions_off testcase_exceptions explicitlib have_target dll c++11 thread uic opengl moc resources QMAKE_PRL_VERSION = 1.0.0 QMAKE_PRL_LIBS = -L/usr/lib64 -L/home/abuild/rpmbuild/BUILD/qtmultimedia-opensource-src-5.9.1/lib -lQt5MultimediaWidgets -lQt5Multimedia -lQt5Widgets -lQt5Gui -lQt5Network -lQt5Core -lGL -lpthread -lasound -lgstaudio-1.0 -lgstvideo-1.0 -lgstpbutils-1.0 -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lpulse-mainloop-glib -lpulse -lglib-2.0 Why does my Qt build use the system installed /usr/lib64/libqgsttools_p.prl file and not the one from the build dir /home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtmultimedia/lib/libqgsttools_p.prl which contains QMAKE_PRL_BUILD_DIR = /home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtmultimedia/src/gsttools QMAKE_PRO_INPUT = gsttools.pro QMAKE_PRL_TARGET = libqgsttools_p.so.1.0.0 QMAKE_PRL_CONFIG = lex yacc debug depend_includepath testcase_targets import_plugins import_qpa_plugin qt_build_extra file_copies qmake_use qt warn_on link_prl incremental shared debug linux unix posix gcc sse2 sse3 ssse3 sse4_1 sse4_2 avx avx2 compile_examples enable_new_dtags f16c largefile optimize_debug precompile_header prefix_build force_independent utf8_source create_prl link_prl prepare_docs qt_docs_targets no_private_qt_headers_warning QTDIR_build qt_example_installs exceptions_off testcase_exceptions explicitlib have_target dll debug_info c++11 thread uic opengl moc resources QMAKE_PRL_VERSION = 1.0.0 QMAKE_PRL_LIBS = -L/home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtmultimedia/lib -lQt5MultimediaWidgetsWinCC_OA -L/home/PACKAGES/qt/5.9.1/qt-everywhere-opensource-src-5.9.1/qtbase/lib -lQt5MultimediaWinCC_OA -lQt5WidgetsWinCC_OA -lQt5GuiWinCC_OA -lQt5NetworkWinCC_OA -lQt5CoreWinCC_OA -lGL -lpthread -lasound -lgstaudio-1.0 -lgstvideo-1.0 -lgstpbutils-1.0 -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lpulse-mainloop-glib -lpulse -lglib-2.0 -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From philippeb8 at gmail.com Mon Jul 24 14:47:34 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 24 Jul 2017 12:47:34 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <20588530.iiNL5ocTaB@tjmaciei-mobl1> <19270993.ORNzu0Ibcc@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On Sunday, 23 July 2017 15:13:50 PDT Phil Bouchard wrote: >> On 07/23/2017 03:54 PM, Thiago Macieira wrote: >>> A problem that can again be mitigated by adding more RAM. Sometimes it's >>> easier/cheaper to just throw hardware at the problem than to rework the >>> software to be more efficient. >> >> Well if you use more memory then you're clogging the bus. Regardless >> with a GC you're just postponing the problem and sooner or later the GC >> will have to kick-in. When that happens the OS is unusable. > > But that's just it: the GC doesn't happen as often if you're not under memory > pressure. You can postpone the GC to later and run it less often, when you're > less busy. Your code can focus on being as fast as it can while the user is > paying attention. Cleanup can be left undone until the user isn't paying > attention. Well I had a Samsung (Android) before and the damn garbage collector was kicking in everytime I had a phone call so it obviously failed to predict when to kick in or not. >>> You should always design your hardware based on what you expect to run or >>> design your software to run on the hardware that you have. If you >>> mis-design, then you'll have problems, clearly (and that's the bane of a >>> lot of embedded products). >> >> True but BB++ apps are always going to be 3.5x faster than Javascript. >> So if you improve the memory chips, the bus and the CPU then BB++ apps >> still will be 3.5x faster. > > But will they be 3.5x harder to write? 3.5x more error prone? No. Like I was saying the errors are reported at compile time so you'll spend less time trying to reproduce a bug at run-time. > There's a reason people use interpreted languages. There's a reason why Python > is so popular for even complex applications It depends what you are doing. But these days people are not playing Unreal Tournament all night long in Javascript because no such process exists! But if you make it possible to build one and play all night long without any lag then people will use it. > Mind you: I am a C++ developer. > >> There's not much to learn: >> - replace 'var' with 'auto' >> - function parameters need to be stated explicitly >> - closures must use global variables > > That's enough to relearn. And I'm not convinced you realise how much different > it will be. I think for somebody coming from a C++ background then he will be able to find similarities fast enough. Somebody coming from a Javascript background might have more problems indeed. > Finally, there's also the lack of an ecosystem. True but whatever's powerful people will buy into it quite fast. >> And honestly to write an app you already need to know: >> - C++ >> - QML >> - Javascript >> >> I am not sure why Javascript was chosen in the first place in QML apps >> because all that is really useful is the XMLHttpRequest but all that > > Because we had a JS interpreter already, in QtScript. > >>> How does your tool deal with runtime code generation via eval() ? >> >> First you need to ask yourself if that function is really used a lot >> because I never used it but if it is then you'll have to use it like a C >> printf to pass the parameters, embed a compiler and compile it on-demand. > > I don't care if it is used a lot. It's used and that's enough. > > But this answers the fact that you did not write a complete replacement of > QML. No not yet obviously. I will try to write a Youtube presentation tonight. From philippeb8 at gmail.com Mon Jul 24 15:58:26 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 24 Jul 2017 13:58:26 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <20588530.iiNL5ocTaB@tjmaciei-mobl1> <19270993.ORNzu0Ibcc@tjmaciei-mobl1> Message-ID: Phil Bouchard wrote: > Thiago Macieira wrote: >> But this answers the fact that you did not write a complete replacement of >> QML. > > No not yet obviously. I will try to write a Youtube presentation tonight. Actually all you have to do is include all of: - BB++ converter - C++ conpiler - Javascript interpreter And people can choose what they want to use so you can't go wrong. BTW I just tried the benchmark on that 3.40 GHz and BB++ is 4x faster! From thiago.macieira at intel.com Mon Jul 24 16:52:05 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 07:52:05 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <17071504.XVlvsLW2Yx@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> <10102090.YhNSR2mURB@tjmaciei-mobl1> <17071504.XVlvsLW2Yx@lapi.koller> Message-ID: <1549759.J1FM22Qq0N@tjmaciei-mobl1> On Monday, 24 July 2017 04:26:55 PDT Martin Koller wrote: > Why does my Qt build use the system installed /usr/lib64/libqgsttools_p.prl > file and not the one from the build dir "Because it was found". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 16:53:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 07:53:47 -0700 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: References: Message-ID: <3136553.FkXH006DZQ@tjmaciei-mobl1> On Monday, 24 July 2017 00:00:36 PDT Marc Mutz wrote: > Hi, > > We haven't added deduction guides to any Qt class, yet. If you want to > use bleeding-edge C++, use C++, iow: std::map. std::map currently (GCC 7.1.1) works less well than QMap, since you can't even trick it. The std::pair that std::map uses requires a const Key, which you can't get with a primitive prvalue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 16:58:28 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 07:58:28 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <19270993.ORNzu0Ibcc@tjmaciei-mobl1> Message-ID: <9237109.oVap2OoSs3@tjmaciei-mobl1> On Monday, 24 July 2017 05:47:34 PDT Phil Bouchard wrote: > Thiago Macieira wrote: > > On Sunday, 23 July 2017 15:13:50 PDT Phil Bouchard wrote: > > But that's just it: the GC doesn't happen as often if you're not under > > memory pressure. You can postpone the GC to later and run it less often, > > when you're less busy. Your code can focus on being as fast as it can > > while the user is paying attention. Cleanup can be left undone until the > > user isn't paying attention. > > Well I had a Samsung (Android) before and the damn garbage collector was > kicking in everytime I had a phone call so it obviously failed to predict > when to kick in or not. How do you know it was the GC? What did you do to extract the evidence that it was the ART (Android Runtime) garbage collector kicking in? How do you know it wasn't some other background process waking up and doing something? Like getting the device's location and sending to the cloud? Or the voice command parser? > > But will they be 3.5x harder to write? 3.5x more error prone? > > No. Like I was saying the errors are reported at compile time so you'll > spend less time trying to reproduce a bug at run-time. Have you ever talked to developers who prefer interpreted languages? "At compile time" does not mean "easier". On the contrary, for them it usually means "harder". The timing of the report may make identifying issues easier, but it doesn't help if there are more issues due to a stricter language. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Mon Jul 24 17:15:58 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 24 Jul 2017 15:15:58 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <19270993.ORNzu0Ibcc@tjmaciei-mobl1> <9237109.oVap2OoSs3@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On Monday, 24 July 2017 05:47:34 PDT Phil Bouchard wrote: >> Thiago Macieira wrote: >>> On Sunday, 23 July 2017 15:13:50 PDT Phil Bouchard wrote: >>> But that's just it: the GC doesn't happen as often if you're not under >>> memory pressure. You can postpone the GC to later and run it less often, >>> when you're less busy. Your code can focus on being as fast as it can >>> while the user is paying attention. Cleanup can be left undone until the >>> user isn't paying attention. >> >> Well I had a Samsung (Android) before and the damn garbage collector was >> kicking in everytime I had a phone call so it obviously failed to predict >> when to kick in or not. > > How do you know it was the GC? What did you do to extract the evidence that it > was the ART (Android Runtime) garbage collector kicking in? > > How do you know it wasn't some other background process waking up and doing > something? Like getting the device's location and sending to the cloud? Or the > voice command parser? Because at that time they didn't have voice commands and I didn't install anything on my cell. When a phone freezes it means the OS is problematic and only the GC has enough control over the OS to make it freeze. >>> But will they be 3.5x harder to write? 3.5x more error prone? >> >> No. Like I was saying the errors are reported at compile time so you'll >> spend less time trying to reproduce a bug at run-time. > > Have you ever talked to developers who prefer interpreted languages? "At > compile time" does not mean "easier". On the contrary, for them it usually > means "harder". Ah... People are afraid but like I was saying before you can't target idiots because they'll never be able to finalize a professional app anyways. > The timing of the report may make identifying issues easier, but it doesn't > help if there are more issues due to a stricter language. Well you want a final product that works with the less time spent developing it. I'll try to show you an example tonight. From fromqt at tungware.se Mon Jul 24 18:45:40 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 24 Jul 2017 18:45:40 +0200 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: <3136553.FkXH006DZQ@tjmaciei-mobl1> References: <3136553.FkXH006DZQ@tjmaciei-mobl1> Message-ID: <85613ac1-11df-8450-278c-4572a3cadd14@tungware.se> On 2017-07-24 16:53, Thiago Macieira wrote: > On Monday, 24 July 2017 00:00:36 PDT Marc Mutz wrote: >> Hi, >> >> We haven't added deduction guides to any Qt class, yet. If you want to >> use bleeding-edge C++, use C++, iow: std::map. > > std::map currently (GCC 7.1.1) works less well than QMap, since you can't even > trick it. The std::pair that std::map uses requires a const Key, which you > can't get with a primitive prvalue. > Tested a bit more, here's the current best effort for both maps (yielding 12 words from Pres. Lincoln) and indeed Qt is ahead in this game (std::map requires more handholding): --------------------------------------------------------------------------------- #include "qapplication.h" #include "qmap.h" #include "map" #include "qdebug.h" int main(int argc, char *argv[]) { QApplication a(argc, argv); QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, {5,"years"}, {3,"and"}, {6,"ago"}}; std::map m2 = {std::pair{8,"fathers"}, {10,"forth"}, {7,"our"}, {11,"on"}, {9,"brought"}, {12,"this"}}; for (auto v : m1) qDebug() << v; for (auto v : m2) qDebug() << v.second; } --------------------------------------------------------------------------------- From devel at g76r.eu Mon Jul 24 21:32:48 2017 From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=) Date: Mon, 24 Jul 2017 21:32:48 +0200 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: <85613ac1-11df-8450-278c-4572a3cadd14@tungware.se> References: <3136553.FkXH006DZQ@tjmaciei-mobl1> <85613ac1-11df-8450-278c-4572a3cadd14@tungware.se> Message-ID: <23e0c369-bb22-4f07-30ba-0451771deece@g76r.eu> Le 24/07/2017 à 18:45, Henry Skoglund a écrit : > QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, > {5,"years"}, {3,"and"}, {6,"ago"}}; Or even this: QMap m1 { {2, "score"}, {4, "seven"}, }; -- Grégoire Barbier :: g à g76r.eu From fromqt at tungware.se Mon Jul 24 21:44:12 2017 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 24 Jul 2017 21:44:12 +0200 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: <23e0c369-bb22-4f07-30ba-0451771deece@g76r.eu> References: <3136553.FkXH006DZQ@tjmaciei-mobl1> <85613ac1-11df-8450-278c-4572a3cadd14@tungware.se> <23e0c369-bb22-4f07-30ba-0451771deece@g76r.eu> Message-ID: On 2017-07-24 21:32, Grégoire Barbier wrote: > Le 24/07/2017 à 18:45, Henry Skoglund a écrit : >> QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, >> {5,"years"}, {3,"and"}, {6,"ago"}}; > > Or even this: > > QMap m1 { {2, "score"}, {4, "seven"}, }; > Yes that works nicely too but it's not bleeding edge/c++17 :-) This post was just to show that in c++17 it's possible to declare a QMap without any trailing <> i.e. letting the compiler figure out the types (less visual clutter) More here: http://en.cppreference.com/w/cpp/language/class_template_argument_deduction Rgrds Henry From kollix at aon.at Mon Jul 24 22:30:24 2017 From: kollix at aon.at (Martin Koller) Date: Mon, 24 Jul 2017 22:30:24 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <1549759.J1FM22Qq0N@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <17071504.XVlvsLW2Yx@lapi.koller> <1549759.J1FM22Qq0N@tjmaciei-mobl1> Message-ID: <1909274.Az0PmgBK3s@lapi.koller> On Montag, 24. Juli 2017 16:52:05 CEST Thiago Macieira wrote: > On Monday, 24 July 2017 04:26:55 PDT Martin Koller wrote: > > Why does my Qt build use the system installed /usr/lib64/libqgsttools_p.prl > > file and not the one from the build dir > > "Because it was found". Then the solution is to make whatever found it, to find my Qt-build's version first, right ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From thiago.macieira at intel.com Mon Jul 24 22:59:24 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 13:59:24 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <1909274.Az0PmgBK3s@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> <1549759.J1FM22Qq0N@tjmaciei-mobl1> <1909274.Az0PmgBK3s@lapi.koller> Message-ID: <100091080.LZsJzhbMrB@tjmaciei-mobl1> On Monday, 24 July 2017 13:30:24 PDT Martin Koller wrote: > On Montag, 24. Juli 2017 16:52:05 CEST Thiago Macieira wrote: > > On Monday, 24 July 2017 04:26:55 PDT Martin Koller wrote: > > > Why does my Qt build use the system installed > > > /usr/lib64/libqgsttools_p.prl > > > file and not the one from the build dir > > > > "Because it was found". > > Then the solution is to make whatever found it, to find my Qt-build's > version first, right ? Easier said than done. Hence my recommendation to remove the file in the first place (if possible, the entire package that installed it). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jul 24 23:01:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 14:01:11 -0700 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <9237109.oVap2OoSs3@tjmaciei-mobl1> Message-ID: <6526615.3mFf5IdGJZ@tjmaciei-mobl1> On Monday, 24 July 2017 08:15:58 PDT Phil Bouchard wrote: > > How do you know it wasn't some other background process waking up and > > doing > > something? Like getting the device's location and sending to the cloud? Or > > the voice command parser? > > Because at that time they didn't have voice commands and I didn't install > anything on my cell. When a phone freezes it means the OS is problematic > and only the GC has enough control over the OS to make it freeze. That's a wildly incorrect assumption. I'm not disputing that you're doing good work. But your foundation is not proven. You may be building a house of cards. > > Have you ever talked to developers who prefer interpreted languages? "At > > compile time" does not mean "easier". On the contrary, for them it usually > > means "harder". > > Ah... People are afraid but like I was saying before you can't target > idiots because they'll never be able to finalize a professional app > anyways. Aaaand now I'm ignoring you and your arguments. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Mon Jul 24 23:32:30 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 24 Jul 2017 21:32:30 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <9237109.oVap2OoSs3@tjmaciei-mobl1> <6526615.3mFf5IdGJZ@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On Monday, 24 July 2017 08:15:58 PDT Phil Bouchard wrote: >>> How do you know it wasn't some other background process waking up and >>> doing >>> something? Like getting the device's location and sending to the cloud? Or >>> the voice command parser? >> >> Because at that time they didn't have voice commands and I didn't install >> anything on my cell. When a phone freezes it means the OS is problematic >> and only the GC has enough control over the OS to make it freeze. > > That's a wildly incorrect assumption. > > I'm not disputing that you're doing good work. But your foundation is not > proven. You may be building a house of cards. That's why you have to put chances on your side. Regarding the GC all you have to do is look at the logs: http://www.war-worlds.com/blog/2012/06/on-android-garbage-collection-can-kill-you >>> Have you ever talked to developers who prefer interpreted languages? "At >>> compile time" does not mean "easier". On the contrary, for them it usually >>> means "harder". >> >> Ah... People are afraid but like I was saying before you can't target >> idiots because they'll never be able to finalize a professional app >> anyways. > > Aaaand now I'm ignoring you and your arguments. I apologize; I was tired because I worked all weekend long on this. But if Qt can have more apps in the Apps Store or Google Play that performs 4x faster than other apps then this means I made my point. From kde at carewolf.com Tue Jul 25 00:20:07 2017 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 25 Jul 2017 00:20:07 +0200 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <3426879.2rGXCDaUt2@lapi.koller> References: <3041679.poHKR03cbZ@lapi.koller> <6699433.6F6KGhILKh@tjmaciei-mobl1> <3426879.2rGXCDaUt2@lapi.koller> Message-ID: <5110742.GPHsodqESM@twilight> On Sonntag, 23. Juli 2017 22:49:11 CEST Martin Koller wrote: > On Sonntag, 23. Juli 2017 18:54:41 CEST Thiago Macieira wrote: > > On Sunday, 23 July 2017 01:50:10 PDT Martin Koller wrote: > > > I found this symbol to be in the qgsttools_p lib but I fear the linker > > > takes the lib from a wrong path. > > > > If you already have Qt installed system-wide, please remove the > > development > > files. You said you're on OpenSUSE, so just remove the Qt -devel packages. > > Ouch. > I assume this is just a workaround, and not "the solution", right ? > It is a work-around, but it is an issue that pops up frequently and can take a while until solved. I do have development files of the system Qt installed, and it usually works just fine. When it does pop up it is however quite tricky to solve because if any pkg-config files add a system include directory to the compile command line, things break. Getting the correct order of includes on and gcc command line is impossible, so the only way of not getting a system header sneak in before the right Qt header is to make sure system include paths are never be explicitly specified, and that requires well-maintained bug-free devel packages. So the issue might not even be Qt, but your distros. 'Allan From thiago.macieira at intel.com Tue Jul 25 01:26:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 16:26:10 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <5110742.GPHsodqESM@twilight> References: <3041679.poHKR03cbZ@lapi.koller> <3426879.2rGXCDaUt2@lapi.koller> <5110742.GPHsodqESM@twilight> Message-ID: <28893290.JBqDnm4Dis@tjmaciei-mobl1> On Monday, 24 July 2017 15:20:07 PDT Allan Sandfeld Jensen wrote: > It is a work-around, but it is an issue that pops up frequently and can take > a while until solved. I do have development files of the system Qt > installed, and it usually works just fine. When it does pop up it is > however quite tricky to solve because if any pkg-config files add a system > include directory to the compile command line, things break. Getting the > correct order of includes on and gcc command line is impossible, so the > only way of not getting a system header sneak in before the right Qt header > is to make sure system include paths are never be explicitly specified, and > that requires well-maintained bug-free devel packages. That doesn't work when we're talking about another set of include paths that are not the system's. This can also happen intra-Qt too, if you're doing split builds. Suppose you're building qtmultimedia again but it's already installed. You need to link to qtbase libraries, so the -L for the install dir is provided. That means the old set of libraries may be found. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jul 25 01:43:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 24 Jul 2017 16:43:44 -0700 Subject: [Development] can not build 5.9.1 qtmultimedia In-Reply-To: <28893290.JBqDnm4Dis@tjmaciei-mobl1> References: <3041679.poHKR03cbZ@lapi.koller> <5110742.GPHsodqESM@twilight> <28893290.JBqDnm4Dis@tjmaciei-mobl1> Message-ID: <13311736.crtzv7RZ70@tjmaciei-mobl1> On Monday, 24 July 2017 16:26:10 PDT Thiago Macieira wrote: > This can also happen intra-Qt too, if you're doing split builds. Suppose > you're building qtmultimedia again but it's already installed. You need to > link to qtbase libraries, so the -L for the install dir is provided. That > means the old set of libraries may be found. And note how the search order for libraries used indirectly is different from those of libraries used directly. I've given up on this problem. Martin and Kevin are welcome to work with Ossi on adding even more code to address even more corner cases. I won't lift a finger, I don't think it's good use of my time. PS: I suspect it's already solved for dev branch because qgsttools_p is now a regular module, so there's nothing to be done there and an invasive change to 5.9 won't be accepted. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Jul 25 03:09:39 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 24 Jul 2017 21:09:39 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: <2616788.yb33KDTaIH@tjmaciei-mobl1> References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: On 07/24/2017 12:05 AM, Thiago Macieira wrote: > >> Also Javascript is hopeless in regards to inheritance so I'm using C++ >> conventions there. > > I'm not disputing the ickiness of the language. I am disputing your unproven > assertions. > > And in one case, *disproven* assertions (see Robin's email). I just tried the following example on the Linux desktop and the iPhone: http://bbplusplus.com/files/ListViewBug.tar.gz It is mimicking images fetched by HTTP and although the animation of the ListView wasn't smooth before then it is now with a recent Qt. Good thing. But resizing the window of QtCreator itself when in Design mode could use a makeover. That's an example of a more complex application in action and this is what I was predicting. From sierdzio at gmail.com Tue Jul 25 08:50:44 2017 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Tue, 25 Jul 2017 08:50:44 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: On 25 July 2017 at 03:09, Phil Bouchard wrote: > That's why you have to put chances on your side. Regarding the GC all you > have to do is look at the logs: > http://www.war-worlds.com/blog/2012/06/on-android-garbage-collection-can-kill-you What killed the performance in this case was not GC but bad design, unfit for the platform. Read the article through, and the comments. In the end, the author got comparable performance on Android and desktop (while Android was still using GC). Additionally, the post is from 5 years ago, a lot could have been improved in that period. Mind you, the bb++ idea seems tempting. JS is not the nicest language around, it would be cool to have an alternative, esp. if the learning curve is small and benefits large. I'd just prefer it to be compiled at compile time (at the same time when C++ part is compiled), cause shipping the compiler with an app seems wasteful at best. From devel at g76r.eu Tue Jul 25 10:10:34 2017 From: devel at g76r.eu (=?UTF-8?Q?Gr=c3=a9goire_Barbier?=) Date: Tue, 25 Jul 2017 10:10:34 +0200 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: References: <3136553.FkXH006DZQ@tjmaciei-mobl1> <85613ac1-11df-8450-278c-4572a3cadd14@tungware.se> <23e0c369-bb22-4f07-30ba-0451771deece@g76r.eu> Message-ID: <506ed7bf-87b5-4bcf-0480-186a69ed38a1@g76r.eu> Le 24/07/2017 à 21:44, Henry Skoglund a écrit : > On 2017-07-24 21:32, Grégoire Barbier wrote: >> Le 24/07/2017 à 18:45, Henry Skoglund a écrit : >>> QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, >>> {5,"years"}, {3,"and"}, {6,"ago"}}; >> >> Or even this: >> >> QMap m1 { {2, "score"}, {4, "seven"}, }; >> > > Yes that works nicely too but it's not bleeding edge/c++17 :-) > > This post was just to show that in c++17 it's possible to declare a QMap > without any trailing <> i.e. letting the compiler figure out the types > (less visual clutter) More here: > http://en.cppreference.com/w/cpp/language/class_template_argument_deduction > > Rgrds Henry Sorry I missed your point, by far. Anyway it's not easy: I played a little bit on godbolt.org and locally on my computer and it seems that gcc 7.1 only deduces templates argument with a depth of 1 (never with templates of templates), ICC 17 and MSVC 15.2 being worst on this point (not deducing at all, if I did not miss something). Even when addind deduction guides like I tried here: https://godbolt.org/g/pC8SaV So, I'll wait and keep my explicit template arguments if needed a few more years, and keep being thankful to all pioneers like you who use it now and will make compilers better... :-) -- Grégoire Barbier :: g à g76r.eu From philippeb8 at gmail.com Tue Jul 25 14:11:10 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 25 Jul 2017 08:11:10 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: On 07/25/2017 02:50 AM, Tomasz Siekierda wrote: > On 25 July 2017 at 03:09, Phil Bouchard wrote: >> That's why you have to put chances on your side. Regarding the GC all you >> have to do is look at the logs: >> http://www.war-worlds.com/blog/2012/06/on-android-garbage-collection-can-kill-you > > What killed the performance in this case was not GC but bad design, > unfit for the platform. Read the article through, and the comments. In > the end, the author got comparable performance on Android and desktop > (while Android was still using GC). Additionally, the post is from 5 > years ago, a lot could have been improved in that period. Here's another article that is 2 years old only and laggy performance still seems to be a problem: https://code.tutsplus.com/tutorials/detect-and-resolve-performance-problems-on-android--cms-24058 You need to understand that: "No matter how innovative and useful your Android app is, if it’s laggy, prone to freezing, or hogs memory, no one is going to want to use it." > Mind you, the bb++ idea seems tempting. JS is not the nicest language > around, it would be cool to have an alternative, esp. if the learning > curve is small and benefits large. I'd just prefer it to be compiled > at compile time (at the same time when C++ part is compiled), cause > shipping the compiler with an app seems wasteful at best. I'm here to help and hopefully Qt can take a lead against world renowned web engines at the same time. As far as the compiler is concerned then, worse case, I know there are better alternatives than G++ in compilation speed and the overall size it takes. I didn't have a chance to create documentation yesterday but I will this week. From annulen at yandex.ru Tue Jul 25 14:20:28 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 25 Jul 2017 15:20:28 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <38499831.a4FOfzihxK@lapi.koller> References: <1711331493820157@web18j.yandex.ru> <1576000.qR13dCIJmj@lapi.koller> <3501051500846330@web26g.yandex.ru> <38499831.a4FOfzihxK@lapi.koller> Message-ID: <2194131500985228@web48o.yandex.ru> 24.07.2017, 08:33, "Martin Koller" : > On Sonntag, 23. Juli 2017 23:45:30 CEST Konstantin Tokarev wrote: >>  23.07.2017, 23:49, "Martin Koller" : >>  > On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote: >>  > >>  >> I'm not sure it would be acceptable, because updated QtWebKit requires full >>  >> C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some >>  >> features, or with code changes, which were not done yet). >>  > >>  > I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the installed >>  > gcc compiler (4.8.5) and I get: >>  > >>  > The WebKit build was disabled for the following reasons: >>  > * Using gcc version 4.8, but at least gcc version 4.9 is required to build QtWebKit. >>  > >>  > So which features can I disable and how ? >>  > >>  > Note that gcc 4.8.5 is the std. compiler on the latest official version of openSuse and still >>  > I can not compile ... :-( >> >>  You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However this brings a >>  degradation of user experience, especially in case of IndexedDB which was supported >>  in previous versions. Therefore you have 3 options: >> >>  1) Disable these features and build limited version using GCC 4.8; > > that brings us to the second part of my question which was not answered: how ? > Is there any qmake or env var I can set ? Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF -DENABLE_DATABASE_PROCESS=OFF to cmake arguments You should not use qmake in your package, look at [1] for example. [1] http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\ - against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at -- Regards, Konstantin From schluchti at gmail.com Tue Jul 25 15:20:08 2017 From: schluchti at gmail.com (Bernhard B) Date: Tue, 25 Jul 2017 15:20:08 +0200 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: I am just a user of Qt, so please take the following please with a grain of salt: I haven't started debugging my application yet, but for some reason my application laggs on Android, but works fine on iOs. It's a listview with a pretty complex delegate. On Android you can see clearly that it laggs, but on iOs it's smooth. But again, I haven't profiled it yet, so it most probably could be related to the complex bindings in the delegate and not due to the GC. Bernhard Am Dienstag, 25. Juli 2017 schrieb Phil Bouchard : > On 07/25/2017 02:50 AM, Tomasz Siekierda wrote: > >> On 25 July 2017 at 03:09, Phil Bouchard wrote: >> >>> That's why you have to put chances on your side. Regarding the GC all you >>> have to do is look at the logs: >>> http://www.war-worlds.com/blog/2012/06/on-android-garbage- >>> collection-can-kill-you >>> >> >> What killed the performance in this case was not GC but bad design, >> unfit for the platform. Read the article through, and the comments. In >> the end, the author got comparable performance on Android and desktop >> (while Android was still using GC). Additionally, the post is from 5 >> years ago, a lot could have been improved in that period. >> > > Here's another article that is 2 years old only and laggy performance > still seems to be a problem: > https://code.tutsplus.com/tutorials/detect-and-resolve-perfo > rmance-problems-on-android--cms-24058 > > You need to understand that: "No matter how innovative and useful your > Android app is, if it’s laggy, prone to freezing, or hogs memory, no one is > going to want to use it." > > Mind you, the bb++ idea seems tempting. JS is not the nicest language >> around, it would be cool to have an alternative, esp. if the learning >> curve is small and benefits large. I'd just prefer it to be compiled >> at compile time (at the same time when C++ part is compiled), cause >> shipping the compiler with an app seems wasteful at best. >> > > I'm here to help and hopefully Qt can take a lead against world renowned > web engines at the same time. As far as the compiler is concerned then, > worse case, I know there are better alternatives than G++ in compilation > speed and the overall size it takes. > > I didn't have a chance to create documentation yesterday but I will this > week. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Tue Jul 25 21:39:44 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 25 Jul 2017 19:39:44 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: I'll try my example on the Android as well tonight. But it sounds like we have the same issue. Bernhard B wrote: > I am just a user of Qt, so please take the following please with a grain of > salt: > > I haven't started debugging my application yet, but for some reason my > application laggs on Android, but works fine on iOs. It's a listview with a > pretty complex delegate. On Android you can see clearly that it laggs, but > on iOs it's smooth. But again, I haven't profiled it yet, so it most > probably could be related to the complex bindings in the delegate and not > due to the GC. > > Bernhard > > Am Dienstag, 25. Juli 2017 schrieb Phil Bouchard : > >> On 07/25/2017 02:50 AM, Tomasz Siekierda wrote: >> >>> On 25 July 2017 at 03:09, Phil Bouchard wrote: >>> >>>> That's why you have to put chances on your side. Regarding the GC all you >>>> have to do is look at the logs: >>>> http://www.war-worlds.com/blog/2012/06/on-android-garbage- >>>> collection-can-kill-you >>>> >>> >>> What killed the performance in this case was not GC but bad design, >>> unfit for the platform. Read the article through, and the comments. In >>> the end, the author got comparable performance on Android and desktop >>> (while Android was still using GC). Additionally, the post is from 5 >>> years ago, a lot could have been improved in that period. >>> >> >> Here's another article that is 2 years old only and laggy performance >> still seems to be a problem: >> https://code.tutsplus.com/tutorials/detect-and-resolve-perfo >> rmance-problems-on-android--cms-24058 >> >> You need to understand that: "No matter how innovative and useful your >> Android app is, if it’s laggy, prone to freezing, or hogs memory, no one is >> going to want to use it." >> >> Mind you, the bb++ idea seems tempting. JS is not the nicest language >>> around, it would be cool to have an alternative, esp. if the learning >>> curve is small and benefits large. I'd just prefer it to be compiled >>> at compile time (at the same time when C++ part is compiled), cause >>> shipping the compiler with an app seems wasteful at best. >>> >> >> I'm here to help and hopefully Qt can take a lead against world renowned >> web engines at the same time. As far as the compiler is concerned then, >> worse case, I know there are better alternatives than G++ in compilation >> speed and the overall size it takes. >> >> I didn't have a chance to create documentation yesterday but I will this >> week. >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > From marc.mutz at kdab.com Wed Jul 26 00:03:17 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 26 Jul 2017 00:03:17 +0200 Subject: [Development] =?utf-8?q?How_to_make_a_fancy_QMap_c++17_initializ?= =?utf-8?q?er=5Flist?= In-Reply-To: <506ed7bf-87b5-4bcf-0480-186a69ed38a1@g76r.eu> References: <3136553.FkXH006DZQ@tjmaciei-mobl1> <85613ac1-11df-8450-278c-4572a3cadd14@tungware.se> <23e0c369-bb22-4f07-30ba-0451771deece@g76r.eu> <506ed7bf-87b5-4bcf-0480-186a69ed38a1@g76r.eu> Message-ID: <2b9d149615c9f8aa953aed1a84164c90@kdab.com> On 2017-07-25 10:10, Grégoire Barbier wrote: > Le 24/07/2017 à 21:44, Henry Skoglund a écrit : >> On 2017-07-24 21:32, Grégoire Barbier wrote: >>> Le 24/07/2017 à 18:45, Henry Skoglund a écrit : >>>> QMap m1 = {std::pair{2,"score"}, {4,"seven"}, {1,"Four"}, >>>> {5,"years"}, {3,"and"}, {6,"ago"}}; >>> >>> Or even this: >>> >>> QMap m1 { {2, "score"}, {4, "seven"}, }; >>> >> >> Yes that works nicely too but it's not bleeding edge/c++17 :-) >> >> This post was just to show that in c++17 it's possible to declare a >> QMap without any trailing <> i.e. letting the compiler figure out the >> types (less visual clutter) More here: >> http://en.cppreference.com/w/cpp/language/class_template_argument_deduction >> >> Rgrds Henry > > Sorry I missed your point, by far. > > Anyway it's not easy: I played a little bit on godbolt.org and locally > on my computer and it seems that gcc 7.1 only deduces templates > argument with a depth of 1 (never with templates of templates), ICC 17 > and MSVC 15.2 being worst on this point (not deducing at all, if I did > not miss something). > > Even when addind deduction guides like I tried here: > https://godbolt.org/g/pC8SaV > > So, I'll wait and keep my explicit template arguments if needed a few > more years, and keep being thankful to all pioneers like you who use > it now and will make compilers better... :-) A nested brace initializer does not have a type, if the types used in the inner braces are distinct, so std::map m = {{k1, v1}, {k2, v2}}; will not work, even if the compiler implements the DR that you find referenced from the cppreference link Henry posted. AFAIU, this would need more language support than what we find in C++17. Ville can probably tell if there are proposals on the table to enable this. Thanks, Marc From thiago.macieira at intel.com Wed Jul 26 00:33:42 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Jul 2017 15:33:42 -0700 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: <2b9d149615c9f8aa953aed1a84164c90@kdab.com> References: <506ed7bf-87b5-4bcf-0480-186a69ed38a1@g76r.eu> <2b9d149615c9f8aa953aed1a84164c90@kdab.com> Message-ID: <41698005.s1UG3baTaF@tjmaciei-mobl1> On terça-feira, 25 de julho de 2017 15:03:17 PDT Marc Mutz wrote: > A nested brace initializer does not have a type, if the types used in > the inner braces are distinct, so > > std::map m = {{k1, v1}, {k2, v2}}; > > will not work, even if the compiler implements the DR that you find > referenced from the cppreference link Henry posted. AFAIU, this would > need more language support than what we find in C++17. Ville can > probably tell if there are proposals on the table to enable this. Even with the deduction guide? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Jul 26 01:19:24 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 26 Jul 2017 01:19:24 +0200 Subject: [Development] QWebEngineView Print References: Message-ID: Just a correction: I wrote: > In 5.7, you can only print by first printing to PDF and then invoking > something external to actually send the PDF to a printer. See the code > (submitted by me) in QupZilla 2.1.x (and currently also in master/2.2, but > since that requires Qt 5.8, it may be ported to the direct print method > soon, I've been wanting to look into that for a while). The 5.7 printing code is only in the QupZilla 2.1 branch: https://github.com/QupZilla/qupzilla/commit/b9bd2338e4e3ab89cee6bb82e8957747420d4d88 QupZilla master was ported to the 5.8 API in February by: https://github.com/QupZilla/qupzilla/commit/8fa9db9f652196b027f32f3074681bb011c15bc8 Kevin Kofler From philippeb8 at gmail.com Wed Jul 26 04:27:20 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 25 Jul 2017 22:27:20 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: I just tried on my old Android (version 4.1.2) and the animation of the ListView is indeed pretty bad. There is no need to try it on a recent one since you already did. On 07/25/2017 03:39 PM, Phil Bouchard wrote: > I'll try my example on the Android as well tonight. But it sounds like we > have the same issue. > > Bernhard B wrote: >> I am just a user of Qt, so please take the following please with a grain of >> salt: >> >> I haven't started debugging my application yet, but for some reason my >> application laggs on Android, but works fine on iOs. It's a listview with a >> pretty complex delegate. On Android you can see clearly that it laggs, but >> on iOs it's smooth. But again, I haven't profiled it yet, so it most >> probably could be related to the complex bindings in the delegate and not >> due to the GC. From ville.voutilainen at gmail.com Wed Jul 26 07:36:42 2017 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Wed, 26 Jul 2017 08:36:42 +0300 Subject: [Development] How to make a fancy QMap c++17 initializer_list In-Reply-To: <41698005.s1UG3baTaF@tjmaciei-mobl1> References: <506ed7bf-87b5-4bcf-0480-186a69ed38a1@g76r.eu> <2b9d149615c9f8aa953aed1a84164c90@kdab.com> <41698005.s1UG3baTaF@tjmaciei-mobl1> Message-ID: On 26 July 2017 at 01:33, Thiago Macieira wrote: > On terça-feira, 25 de julho de 2017 15:03:17 PDT Marc Mutz wrote: >> A nested brace initializer does not have a type, if the types used in >> the inner braces are distinct, so >> >> std::map m = {{k1, v1}, {k2, v2}}; >> >> will not work, even if the compiler implements the DR that you find >> referenced from the cppreference link Henry posted. AFAIU, this would >> need more language support than what we find in C++17. Ville can >> probably tell if there are proposals on the table to enable this. > > Even with the deduction guide? Even with the guide. See https://wandbox.org/permlink/qH4LrE4EfEQ5C6hU and experiment with what happens when the mention of pair is removed. The end result is not very nice, and I am not aware of any proposals to fix it. From jan.marker at kdab.com Wed Jul 26 12:03:51 2017 From: jan.marker at kdab.com (Jan Marker) Date: Wed, 26 Jul 2017 18:03:51 +0800 Subject: [Development] [Qt3D] RFC: API for back-end callbacks Message-ID: <5caae38a-5cc3-db8f-70a1-0b4f4aeb5314@kdab.com> Hi, This mail is somewhat lengthy in order to provide background - if you know Qt 3D already you can skip to "Problem Statement". # Background: Qt 3D has a front-end/back-end architecture: - front-end: developer sets up the scene with objects, input handlers, ... (runs on the main thread) - Qt 3D copies this information over to back-end data structures - back-end: executes algorithms and rendering on a thread pool on the back-end's data structures (not the front-end's) (e.g. animations that change positions of objects) - Qt 3D notifies the front-end of changes (e.g. of position changes due to animations) The developer is not aware of the back-end, the back-end is private API. Given two cubes CubeA and CubeB. CubeA is animated to move vertically on the screen and be mirrored by the y axis. CubeB should follow CubeA's movement without being animated itself. (see https://imagebin.ca/v/3UgjoVpAmXME, right is animated, left follows) Currently, this is solved by QFrameAction: A QFrameAction is executed every frame (e.g. 60 times per second) and can access *front-end* data structures both to read and write, for example (dt is the time between this frame and the previous frame): Qt3DLogic::QFrameAction *frameAction = new Qt3DLogic::QFrameAction(rootEntity); QObject::connect(frameAction, &Qt3DLogic::QFrameAction::triggered, frameAction, [cubeA, cubeB](float dt) { Q_UNUSED(dt); const auto t = cubeA->translation(); cubeB->setTranslation({-t.x(), t.y(), t.z()}); }); In general, QFrameAction is a function with a context (dt) that takes parameters and outputs a result. # Problem statement: QFrameAction operates on the *front-end*, therefore it does not run on the thread-pool and is not parallelized. If the main thread is heavily loaded or blocked this will delay or block the back-end, too, which might slow or block rendering. It also makes it impossible to have the result of the QFrameAction available in the current frame because of front-end/back-end synchronization. The idea now is to provide a replacement for QFrameAction that can run on the back-end. Because the back-end API is private, there needs to be some kind of API contract on how the replacement takes parameters and provides a result. We call this "QNodeBinding". We have created multiple drafts of API contracts and are seeking your feedback with regard to: - usability - maintainability - general concerns The drafts are (table of contents): structs |QVariantMap |positional arguments --------------------------|------------------------|-------------------------- (with QNodeBindingContext)|with QNodeBindingContext|(with QNodeBindingContext) QNodeBindingContext can be combined with any other solution, the examples I provide do not contain the solutions "structs with QNodeBindingContext" and "positional arguments with QNodeBindingContext". ## structs struct Input { QVector3D translation; } struct Output { QVector3D translation; } auto *action= new Qt3DLogic::QNodeBinding(rootEntity); action->addInput(cubeA, "translation", &Input::translation); action->addOutput(&Output::translation, cubeB, "translation"); action->setAction([](float dt, Input *input, Output *output) { Q_UNUSED(dt) const auto &t = input->translation; output->translation = QVector3D{-t.x(), t.y(), t.z()}; }); proof-of-concept: https://codereview.qt-project.org/#/c/200263/ + no unmarshalling of parameters + named input parameters + less chance for typos - Input and Output structs need to be declared - implementation relies heavily on templates ## QVariantMap auto *action = new Qt3DLogic::QNodeBinding(rootEntity); action->addInput(cubeA, "translation", "translationIn"); action->addOutput("translationOut", cubeB, "translation"); action->setAction([](float dt, const QVariantMap &inputs, QVariantMap *outputs) { Q_UNUSED(dt) const auto &t = inputs[QLatin1String("translationIn")].value(); outputs->insert(QLatin1String("translationOut"), QVector3D{-t.x(), t.y(), t.z()}); }); proof-of-concept: https://codereview.qt-project.org/#/c/200834/ - unmarshalling of parameters - easy to make typos + no need to define input and output structs ## positional arguments auto *action = new Qt3DLogic::QNodeBinding(rootEntity); action->addInput(cubeA, "translation"); action.->addInput(cubeA, "scale"); // for demonstration action->addOutput(cubeB, "translation"); action->setAction( [](float dt, const QVector3D& translation, double s) -> QVector { Q_UNUSED(dt) const auto &t = translation; return {QVector3D{-t.x(), t.y(), t.z()}}; } ); proof-of-concept: https://codereview.qt-project.org/#/c/200833/ - possibly bugs due to wrong positioning (if parameters translation and s would be swapped) - implementation relies on templates + no unmarshalling of parameters + named parameters ## QVariantMap with QNodeBindingContext auto *action = new Qt3DLogic::QNodeBinding(rootEntity); action->addInput(cubeA, "translation", "translationIn"); action->addOutput("translationOut", cubeB, "translation"); action->setAction([](Qt3DLogic::QNodeBindingContext &context, const QVariantMap &inputs) { const auto dt = context.dt(); const auto &t = inputs[QLatin1String("translationIn")].value(); context.emitChange(QLatin1String("translationOut"), QVector3D(-t.x(), t.y(), t.z())); }); proof-of-concept: https://codereview.qt-project.org/#/c/200835/ + context can have new properties without hurting ABI compatibility + only output values that have changed need to be emitted (would require branching in the lambda) - higher chance of typos Any kind of feedback is highly appreciated. If something is unclear or information is missing I'll be happy to elaborate. Thanks for reading :-) Jan -- Jan Marker | jan.marker at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3988 bytes Desc: S/MIME Cryptographic Signature URL: From philippeb8 at gmail.com Thu Jul 27 03:15:30 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 26 Jul 2017 21:15:30 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: On 07/25/2017 08:11 AM, Phil Bouchard wrote: > > I didn't have a chance to create documentation yesterday but I will this > week. I just created a more complex example and it seems to be running perfectly fine: class Document { auto head = nullptr(); auto tail = nullptr(); Document() { cout << __PRETTY_FUNCTION__ << endl; } ~Document() { cout << __PRETTY_FUNCTION__ << endl; } auto foo = function (int argument) { cout << __PRETTY_FUNCTION__ << endl; return argument; }; }; int main() { auto temporary = 1; auto document = new Document(); document.foo(temporary); auto bar = function () { auto document = new Document(); // cycle document.head = new Document(); document.head.head = new Document(); document.head.head.head = document; return document; }; cout << 1 << endl; auto result = bar().foo(temporary); cout << 2 << endl; } Outputs: Document::Document(const boost::node_proxy&) auto __lambda0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) Document::Document(const boost::node_proxy&) Document::Document(const boost::node_proxy&) Document::~Document() Document::~Document() auto __lambda0(boost::node_proxy&, int) 2 Document::~Document() Document::~Document() -Phil From philippeb8 at gmail.com Thu Jul 27 04:28:22 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 26 Jul 2017 22:28:22 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: <2006480.cy7u5sIEx1@tjmaciei-mobl1> <2616788.yb33KDTaIH@tjmaciei-mobl1> Message-ID: On 07/26/2017 09:15 PM, Phil Bouchard wrote: > On 07/25/2017 08:11 AM, Phil Bouchard wrote: >> >> I didn't have a chance to create documentation yesterday but I will this >> week. > > I just created a more complex example and it seems to be running > perfectly fine: > > class Document > { > auto head = nullptr(); > auto tail = nullptr(); > > Document() { cout << __PRETTY_FUNCTION__ << endl; } > ~Document() { cout << __PRETTY_FUNCTION__ << endl; } > > auto foo = function (int argument) { cout << __PRETTY_FUNCTION__ << > endl; return argument; }; > }; > > int main() > { > auto temporary = 1; > > auto document = new Document(); > document.foo(temporary); > > auto bar = function () > { > auto document = new Document(); > > // cycle > document.head = new Document(); > document.head.head = new Document(); > document.head.head.head = document; > > return document; > }; > > cout << 1 << endl; > auto result = bar().foo(temporary); > cout << 2 << endl; > } > > > Outputs: > > Document::Document(const boost::node_proxy&) > auto __lambda0(boost::node_proxy&, int) > 1 > Document::Document(const boost::node_proxy&) > Document::Document(const boost::node_proxy&) > Document::Document(const boost::node_proxy&) > Document::~Document() > Document::~Document() > auto __lambda0(boost::node_proxy&, int) > 2 > Document::~Document() > Document::~Document() Sorry I just fixed the last bug there can be and now the output correctly shows the following: Document::Document(const boost::node_proxy&) auto __lambda0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) Document::Document(const boost::node_proxy&) Document::Document(const boost::node_proxy&) auto __lambda0(boost::node_proxy&, int) 2 Document::~Document() Document::~Document() Document::~Document() Document::~Document() This is because all the elements in a certain "branch" get upscaled to a higher scope and therefore will all get deleted in that specific scope. Thanks, -Phil From ari.salmi at snowgrains.com Thu Jul 27 07:57:53 2017 From: ari.salmi at snowgrains.com (Ari Salmi) Date: Thu, 27 Jul 2017 08:57:53 +0300 Subject: [Development] QtCloudMessaging repository request to Qt In-Reply-To: References: Message-ID: Hi, Continuing the same thread for looking for reviewers and commenters :) Its in! :) I got QtCloudMessaging API code pushed in to the codereview! I’m looking for comments and reviewers for it in order to proceed for final contribution and blog post to Qt technical blog. You can find best info about usage from the main level README.ME file. Repository is: https://codereview.qt-project.org/qt/qtcloudmessaging About examples: I moved examples into GitHub due those mobile examples include compiled ssl and crypto libs (for https communications) and therefore example file sizes coming too big for sanity bot: https://github.com/snowgrains/qtcloudmessaging-examples On examples: Embedded is working nicely on all platforms provided by Kaltiot backend. Firebase is working for Android, iOS and on desktop (stub functionality) on Mac. Thank you for all help! Br, Ari Salmi > On 21 Jun 2017, at 14.24, Jesus Fernandez wrote: > > With QtNetworkAuth + QNetworkAccessManager the Firebase C++ API is not needed. So it will remove this dependency and support more platforms than the platforms supported by the Firebase libs. > > Thank you for the explanation :) > > -- > Best regards, > Jesús > > On 2017-06-21 13:19:24+02:00 Ari Salmi wrote: > > Hi Jesús, > Thanks for question and reaction! > Qt Cloud Messaging API itself is not dependent on QtNetworkAuth, but it can be backend-solution dependent. > e.g: > Google firebase backend solution for Android and iOS are using firebase's c++ binaries (which app developer should give env, path when compiling) and real communication goes through those elements. > Also in addition developer can create the cloud messaging server elements also with this same API, so I've included REST API interfaces (QtNetwork) to firebase and to Kaltiot.com backends. Those needs (after Qt5.6) libssl and libcrypto libraries included in to the applications (included in the example). > Thanks, > Ari > > br, Ari > Ari Salmi > SnowGrains > 2017-06-21 14:07 GMT+03:00 Jesus Fernandez >: > Hi Ari, > > Is your project dependent on QtNetworkAuth for dealing with Google API? > > Best regards, > Jesús > -- > Best regards, > Jesús > > On 2017-06-21 12:59:05+02:00 Ari Salmi wrote: > > Hi there, > > I am developing a Qt API to wrap cloud push services to mobile apps and embedded devices. > This includes examples for using Google Firebase (firebase.google.com ) for mobile app development and similar a solution for embedded space as well (which has increasing demand). > > For contribution to Qt the new repository is needed. > > Name of the project: > Qt Cloud Messaging > > Responsible person: > Ari Salmi / SnowGrains > gerrit username: snowgrains > gerrit email: snowgrains at snowgrains.com > > desired repository name: > qtcloudmessaging > Some background: > The closest match is the Qt Mobility's QMessaging service, which more or less concentrated to SMS, mms and email services inside a (nokia) phones taking care of the contacts etc. Unfortunately that API is not expandable to other platforms and cannot be used. One aim on this is to create Qt API that wraps (and developers can do more wrappers with same API) e.g. Google firebase, or onesignal type of push messaging services - for mobile and desktop apps. > > More important aim is to provide similar messaging to/from iot and other embedded devices, like cars. This is the place where we are lacking the offering from the Qt point of view. One embedded backend solution that has scale able offering is Kaltiot.com. I've included it as one backend for embedded story. > Thank you and best regards, > Ari > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Thu Jul 27 14:51:04 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 27 Jul 2017 12:51:04 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: <9237109.oVap2OoSs3@tjmaciei-mobl1> <6526615.3mFf5IdGJZ@tjmaciei-mobl1> Message-ID: Phil Bouchard wrote: > Thiago Macieira wrote: >> >> Aaaand now I'm ignoring you and your arguments. > > I apologize; I was tired because I worked all weekend long on this. But if > Qt can have more apps in the Apps Store or Google Play that performs 4x > faster than other apps then this means I made my point. Not getting over it is totalitarianism. From kollix at aon.at Thu Jul 27 15:40:43 2017 From: kollix at aon.at (Martin Koller) Date: Thu, 27 Jul 2017 15:40:43 +0200 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <2194131500985228@web48o.yandex.ru> References: <1711331493820157@web18j.yandex.ru> <38499831.a4FOfzihxK@lapi.koller> <2194131500985228@web48o.yandex.ru> Message-ID: <2010398.DY9frqm9AW@lapi.koller> On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote: > >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However this brings a > >> degradation of user experience, especially in case of IndexedDB which was supported > >> in previous versions. Therefore you have 3 options: > >> > >> 1) Disable these features and build limited version using GCC 4.8; > > > > that brings us to the second part of my question which was not answered: how ? > > Is there any qmake or env var I can set ? > > Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF > -DENABLE_DATABASE_PROCESS=OFF to cmake arguments > > You should not use qmake in your package, look at [1] for example. > > [1] http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec thanks. I'm just trying this but I get a link failure (error below). Questions: - Does QtWebKit allow to disable Qt-Quick alltogether ? I don't need that. (I had Qt 5.9.1 configured without qtdeclarative, but then the cmake call for QtWebKit already failed) - Does QtWebKit allow to be compiled as a namespaced/infixed library, as was possible in e.g. Qt 5.5 so that the result is a libQt5WebKitWinCC_OA.so (Qt 5.9.1 is compiled with -qtnamespace WinCC_OA -qtlibinfix WinCC_OA) ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o: In function `QQuickWebViewExperimental::QQuickWebViewExperimental(QQuickWebView*, QQuickWebViewPrivate*)': qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xb6): undefined reference to `WinCC_OA::QQmlWebChannel::QQmlWebChannel(WinCC_OA::QObject*)' qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xfd): undefined reference to `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)' ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o: In function `QQuickWebViewExperimental::setWebChannel(WinCC_OA::QQmlWebChannel*)': qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x44): undefined reference to `WinCC_OA::QQmlWebChannel::disconnectFrom(WinCC_OA::QObject*)' qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x78): undefined reference to `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)' collect2: error: ld returned 1 exit status Source/WebKit/CMakeFiles/WebKit.dir/build.make:2647: recipe for target 'lib/libQt5WebKit.so.5.212.0' failed -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From annulen at yandex.ru Thu Jul 27 16:13:05 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 27 Jul 2017 17:13:05 +0300 Subject: [Development] QtWebKit is coming back (part 2) In-Reply-To: <2010398.DY9frqm9AW@lapi.koller> References: <1711331493820157@web18j.yandex.ru> <38499831.a4FOfzihxK@lapi.koller> <2194131500985228@web48o.yandex.ru> <2010398.DY9frqm9AW@lapi.koller> Message-ID: <278911501164785@web24o.yandex.ru> 27.07.2017, 16:41, "Martin Koller" : > On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote: > >>  >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However this brings a >>  >> degradation of user experience, especially in case of IndexedDB which was supported >>  >> in previous versions. Therefore you have 3 options: >>  >> >>  >> 1) Disable these features and build limited version using GCC 4.8; >>  > >>  > that brings us to the second part of my question which was not answered: how ? >>  > Is there any qmake or env var I can set ? >> >>  Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF >>  -DENABLE_DATABASE_PROCESS=OFF to cmake arguments >> >>  You should not use qmake in your package, look at [1] for example. >> >>  [1] http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec > > thanks. I'm just trying this but I get a link failure (error below). > > Questions: > - Does QtWebKit allow to disable Qt-Quick alltogether ? I don't need that. -DENABLE_WEBKIT2=OFF >   (I had Qt 5.9.1 configured without qtdeclarative, but then the cmake call for QtWebKit already failed) > - Does QtWebKit allow to be compiled as a namespaced/infixed library, as was possible in e.g. Qt 5.5 QtWebKit has never allowed compilation as namespaced library, but it supports compilation against namespaced Qt As for infix, it is not supported with new build system and this is is indeed a regression, patches are welcome >   so that the result is a libQt5WebKitWinCC_OA.so (Qt 5.9.1 is compiled with -qtnamespace WinCC_OA -qtlibinfix WinCC_OA) > > ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o: In function `QQuickWebViewExperimental::QQuickWebViewExperimental(QQuickWebView*, QQuickWebViewPrivate*)': > qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xb6): undefined reference to `WinCC_OA::QQmlWebChannel::QQmlWebChannel(WinCC_OA::QObject*)' > qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xfd): undefined reference to `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)' > ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o: In function `QQuickWebViewExperimental::setWebChannel(WinCC_OA::QQmlWebChannel*)': > qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x44): undefined reference to `WinCC_OA::QQmlWebChannel::disconnectFrom(WinCC_OA::QObject*)' > qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x78): undefined reference to `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)' > collect2: error: ld returned 1 exit status > Source/WebKit/CMakeFiles/WebKit.dir/build.make:2647: recipe for target 'lib/libQt5WebKit.so.5.212.0' failed > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\ - against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at -- Regards, Konstantin From philippeb8 at gmail.com Sun Jul 30 19:23:14 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 30 Jul 2017 13:23:14 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On 07/21/2017 12:22 AM, Phil Bouchard wrote: > Greetings, > > I am now using C++14 standards, the error reporting is all compile-time > now and I get a test that is 3.5 faster than Node.JS! You can see it by > yourselves here: > https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I just tried it on Windows 8.1 and the standard deviation is even greater: 4.2x faster on Windows when it is 3.5x faster on Linux (2.40 GHz). This must be because Visual C++ generates slightly better code than G++. I'll generate documentation for your convenience soon. -Phil From sylvain.pointeau at gmail.com Sun Jul 30 20:04:30 2017 From: sylvain.pointeau at gmail.com (Sylvain Pointeau) Date: Sun, 30 Jul 2017 18:04:30 +0000 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: I would suggest you to make your language feature complete before making any benchmark. For your information, lambda and variable capture cannot be discussed, it is absolutely needed. in my opinion, you totally under estimate the design of a language, please read on Stroustrup / c++ etc. as a first language design attempt, I would personnaly implement an existing language that would fit the purpose. (kotlin, pascal?, etc) as a scripting language, it will be very hard to propose anything else than javascript, you can try of course but without a backing company, there is very little chance to succeed. Best regards, Sylvain Le dim. 30 juil. 2017 à 19:23, Phil Bouchard a écrit : > On 07/21/2017 12:22 AM, Phil Bouchard wrote: > > Greetings, > > > > I am now using C++14 standards, the error reporting is all compile-time > > now and I get a test that is 3.5 faster than Node.JS! You can see it by > > yourselves here: > > https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp > > I just tried it on Windows 8.1 and the standard deviation is even > greater: 4.2x faster on Windows when it is 3.5x faster on Linux (2.40 > GHz). This must be because Visual C++ generates slightly better code > than G++. > > I'll generate documentation for your convenience soon. > > > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Sun Jul 30 20:20:12 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 30 Jul 2017 18:20:12 +0000 (UTC) Subject: [Development] [BB++] Now is 3.5x faster than Node.JS References: Message-ID: Thanks for the information; I already sent this information to Google, Uber and NASA. I'm about to tell WebKit as well. We'll see what they have to say. As far as closures are concerned, there is a way to convert closures with parameters and return values so I personally don't think it's worth paying the price of a GC just for these features. My 2 cents, -Phil Sylvain Pointeau wrote: > I would suggest you to make your language feature complete before making > any benchmark. > For your information, lambda and variable capture cannot be discussed, it > is absolutely needed. > > in my opinion, you totally under estimate the design of a language, please > read on Stroustrup / c++ etc. > > as a first language design attempt, I would personnaly implement an > existing language that would fit the purpose. (kotlin, pascal?, etc) > as a scripting language, it will be very hard to propose anything else than > javascript, you can try of course but without a backing company, there is > very little chance to succeed. > > Best regards, > Sylvain > > Le dim. 30 juil. 2017 à 19:23, Phil Bouchard a > écrit : > >> On 07/21/2017 12:22 AM, Phil Bouchard wrote: >>> Greetings, >>> >>> I am now using C++14 standards, the error reporting is all compile-time >>> now and I get a test that is 3.5 faster than Node.JS! You can see it by >>> yourselves here: >>> https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp >> >> I just tried it on Windows 8.1 and the standard deviation is even >> greater: 4.2x faster on Windows when it is 3.5x faster on Linux (2.40 >> GHz). This must be because Visual C++ generates slightly better code >> than G++. >> >> I'll generate documentation for your convenience soon. >> >> >> -Phil >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > From philippeb8 at gmail.com Sun Jul 30 22:52:41 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 30 Jul 2017 16:52:41 -0400 Subject: [Development] [BB++] Now is 3.5x faster than Node.JS In-Reply-To: References: Message-ID: On 07/30/2017 01:23 PM, Phil Bouchard wrote: > > I'll generate documentation for your convenience soon. Like I promised, here's a 5 minutes long documentary: https://youtu.be/vXmddU_FS30 Regards, -Phil From philippeb8 at gmail.com Sun Jul 30 22:54:05 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 30 Jul 2017 16:54:05 -0400 Subject: [Development] [BB++] 5 minutes long documentary Message-ID: Like I promised, here's a 5 minutes long documentary on BB++: https://youtu.be/vXmddU_FS30 Regards, -Phil From mandeepsandhu.chd at gmail.com Mon Jul 31 06:15:33 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Sun, 30 Jul 2017 21:15:33 -0700 Subject: [Development] implicit sharing and iterators in qt containers Message-ID: Hi All, I recently stumbled upon an issue where using iterators of a QLinkedList, altered the "copy" of another QLinkedList. On reading the iterator docs, I came across this limitation of Qt containers with implicit sharing: http://doc.qt.io/qt-5/containers.html#implicit-sharing-iterator-problem Basically this article advises against making copies of containers which have active iterators on them. I've written a Qt based "ordered map" which uses a QLinkedList for maintaining order of keys (https://github.com/mandeepsandhu/qt-ordered-map). However, due to the issue with implicit sharing & iterators, it's not possible for a trivial assignment operator & copy c'tor. Is there any way around it other than making a item-by-item copy of the linked list? Thanks, -mandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at qt.io Mon Jul 31 09:07:35 2017 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Mon, 31 Jul 2017 09:07:35 +0200 Subject: [Development] ChangeLog entries and reverted commits Message-ID: Suppose you create a new feature in commit A for Qt 5.x. The commit message has a change log entry. After a while A has to be reverted. You won't have time to fix the issue properly for 5.x. The git history for 5.x still contains the change log entry - now erronously. Is the script that creates change logs from git commit history aware of reverts and filters out such entries? BR, Joerg From edward.welbourne at qt.io Mon Jul 31 10:52:43 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 31 Jul 2017 08:52:43 +0000 Subject: [Development] ChangeLog entries and reverted commits In-Reply-To: References: Message-ID: Joerg Bornemann (31 July 2017 09:07) > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be > reverted. You won't have time to fix the issue properly for 5.x. The > git history for 5.x still contains the change log entry - now > erronously. > > Is the script that creates change logs from git commit history aware > of reverts and filters out such entries? Good question. I don't actually know how we generate our change-logs, but qtqa/src/createchangelog/main.go looks suspiciously likely to be it. Its extractChangeLog() appears to be parsing out the ChangeLog; its caller, appMain(), appears to be taking the full list of commits and scanning each; and the word "revert" never appears. So I consider it likely that the script doesn't take reverts into account. Talk to Simon Hausmann, he's the author, Eddy. From kevin.kofler at chello.at Mon Jul 31 11:01:41 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 31 Jul 2017 11:01:41 +0200 Subject: [Development] implicit sharing and iterators in qt containers References: Message-ID: Mandeep Sandhu wrote: > However, due to the issue with implicit sharing & iterators, it's not > possible for a trivial assignment operator & copy c'tor. Is there any way > around it other than making a item-by-item copy of the linked list? Your OrderedMap should itself be implicitly shared and clone the linked list on detach. Kevin Kofler From Friedemann.Kleint at qt.io Mon Jul 31 11:11:41 2017 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Mon, 31 Jul 2017 11:11:41 +0200 Subject: [Development] ChangeLog entries and reverted commits In-Reply-To: References: Message-ID: <4b6555a1-5234-fd83-8942-cf169c2bd572@qt.io> Hi, have a look at https://codereview.qt-project.org/#/c/201164/ for the Perl script. Friedemann -- Friedemann Kleint The Qt Company GmbH From christian.kandeler at qt.io Mon Jul 31 11:25:52 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 31 Jul 2017 11:25:52 +0200 Subject: [Development] ChangeLog entries and reverted commits In-Reply-To: <4b6555a1-5234-fd83-8942-cf169c2bd572@qt.io> References: <4b6555a1-5234-fd83-8942-cf169c2bd572@qt.io> Message-ID: <20170731112552.0b27c74a@ckandeler-archlinux> On Mon, 31 Jul 2017 11:11:41 +0200 Friedemann Kleint wrote: > have a look at https://codereview.qt-project.org/#/c/201164/ for the > Perl script. Are the two scripts competing or do they complement each other in some way? Christian From philippeb8 at gmail.com Mon Jul 31 13:39:29 2017 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 31 Jul 2017 07:39:29 -0400 Subject: [Development] [BB++] 5 minutes long documentary In-Reply-To: References: Message-ID: On 07/31/2017 07:12 AM, Phil Bouchard via Boost wrote: > On 07/30/2017 04:54 PM, Phil Bouchard via Boost wrote: >> Like I promised, here's a 5 minutes long documentary on BB++: >> https://youtu.be/vXmddU_FS30 > > FAQ: > > "I will create a better and longer presentation this week but the goal > of the language is to solve all possible memory leaks by grouping all > pointers into sets which get destroyed at the end of a scope. Thus at > the end of a scope, all pointers are guaranteed to be destroyed, cyclic > or not. > > Furthermore It replaces Node.JS but uses the power of C++ for > inheritance (multiple inheritance, virtual inheritance, etc.). > > Lastly I am not sure how the memory consumption can be increased by > 2500% [in the Microsoft tests] because sizeof(boost::shared_ptr) == > sizeof(void *) * 2 and so is sizeof(boost::node_ptr) == sizeof(void *) * > 2." 3...2...1... Ok I'm outta here. From frederik.gladhorn at qt.io Mon Jul 31 15:19:00 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 31 Jul 2017 15:19:00 +0200 Subject: [Development] Coin infrastructure changes Message-ID: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p> Hi all, this is mostly for your information. On Wednesday this week (most likely) we're making changes to Coin, potentially leading to some interruptions in integrations. The longer version: We've been working towards replacing the underlying virtualization layer in our Continuous Integration infrastructure and have now reached a point where we're ready (as ready as we'll get at least) to switch over from VSphere to OpenNebula. There are a bunch of advantages (not least that we can actually debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin easier, ...). This will also be the point at which we start to use some of the new hardware that The Qt Company has been purchasing and getting ready, so things will initially be at the same speed and eventually much faster. We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some merges, hopefully we'll get it working really soon now. Hopefully the process is: stop the system; change branch; restart and things will work. I would expect some hickups when we scale up and run in production mode, so bear with us and report issues, we'll eventually be better off, once things are in shape. Cheers, Frederik From laszlo.agocs at qt.io Mon Jul 31 15:24:57 2017 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Mon, 31 Jul 2017 13:24:57 +0000 Subject: [Development] Coin infrastructure changes In-Reply-To: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p> References: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p> Message-ID: Hi, Are we sure that the week before the 5.10 feature freeze date is really the best time to do this? Cheers, Laszlo -----Original Message----- From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Frederik Gladhorn Sent: mandag 31. juli 2017 15.19 To: development at qt-project.org Subject: [Development] Coin infrastructure changes Hi all, this is mostly for your information. On Wednesday this week (most likely) we're making changes to Coin, potentially leading to some interruptions in integrations. The longer version: We've been working towards replacing the underlying virtualization layer in our Continuous Integration infrastructure and have now reached a point where we're ready (as ready as we'll get at least) to switch over from VSphere to OpenNebula. There are a bunch of advantages (not least that we can actually debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin easier, ...). This will also be the point at which we start to use some of the new hardware that The Qt Company has been purchasing and getting ready, so things will initially be at the same speed and eventually much faster. We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some merges, hopefully we'll get it working really soon now. Hopefully the process is: stop the system; change branch; restart and things will work. I would expect some hickups when we scale up and run in production mode, so bear with us and report issues, we'll eventually be better off, once things are in shape. Cheers, Frederik _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Mon Jul 31 16:04:00 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 31 Jul 2017 16:04:00 +0200 Subject: [Development] ChangeLog entries and reverted commits In-Reply-To: References: Message-ID: <20170731140400.GS18408@troll08> On Mon, Jul 31, 2017 at 09:07:35AM +0200, Jörg Bornemann wrote: > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be reverted. You > won't have time to fix the issue properly for 5.x. The git history for > 5.x still contains the change log entry - now erronously. > good revert commit messages add a retraction changelog entry. consequently, the re-application should then mention that fact as well, to not confuse the editor (just like the summary should mention that it's a re-application, to not confuse the readers of the log). > Is the script that creates change logs from git commit history aware of > reverts and filters out such entries? > we could do that, but that needs to happen atomically with a change of actual practice (cf. your change where neither the revert nor the re-application have a changelog). From jedrzej.nowacki at qt.io Mon Jul 31 16:17:15 2017 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 31 Jul 2017 16:17:15 +0200 Subject: [Development] Coin infrastructure changes In-Reply-To: References: <1795351.MzuLWtvgav@frederik-thinkcentre-m93p> Message-ID: <1645231.0LUt6qZNeO@42> On mandag 31. juli 2017 13.24.57 CEST Laszlo Agocs wrote: > Hi, > > Are we sure that the week before the 5.10 feature freeze date is really the > best time to do this? > > Cheers, > Laszlo > Hi, Well, it is not the worst either. Currently, the integration count is quite low, but the most important thing is that it will be easy to rollback, in case of a major problem. So please report if you encounter such. For the first few hours or maybe even days we can switch between different systems in few minutes, without any additional costs. Our stress tests show that the new system is slightly more powerful and stable then existing one, so it should be easier to get changes in. Of course there is a risk, switching hardware and virtualization layer may cause some problems, but we hope that it will be transparent for you. Cheers, Jędrek From thiago.macieira at intel.com Mon Jul 31 17:37:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 31 Jul 2017 08:37:41 -0700 Subject: [Development] ChangeLog entries and reverted commits In-Reply-To: References: Message-ID: <2966520.3KYL24x3r8@tjmaciei-mobl1> On Monday, 31 July 2017 00:07:35 PDT Joerg Bornemann wrote: > Suppose you create a new feature in commit A for Qt 5.x. The commit > message has a change log entry. After a while A has to be reverted. You > won't have time to fix the issue properly for 5.x. The git history for > 5.x still contains the change log entry - now erronously. > > Is the script that creates change logs from git commit history aware of > reverts and filters out such entries? The human editor of the changelog is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mandeepsandhu.chd at gmail.com Mon Jul 31 19:11:02 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 31 Jul 2017 10:11:02 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: Message-ID: > > > Your OrderedMap should itself be implicitly shared and clone the linked > list > on detach. > Right now, I'm detaching the linked list during copy-construction (and assignment). Detaching here means re-populating the LL with same entries and then storing the new LL iterator's in the hash. For implicit sharing, I'll have to this instead when a non-const function is called for the first time on the copy. This will cause a penalty when calling such a function as the hash has to be repopulated with all entries (eg: calling remove on the copy will take linear time instead of constant, although subsequent calls will have no penalty). Still thinking about it. Thanks for your input. -mandeep > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Mon Jul 31 20:20:43 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 31 Jul 2017 14:20:43 -0400 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: Message-ID: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> On 2017-07-31 13:11, Mandeep Sandhu wrote: > Right now, I'm detaching the linked list during copy-construction (and > assignment). Detaching here means re-populating the LL with same entries > and then storing the new LL iterator's in the hash. > > For implicit sharing, I'll have to this instead when a non-const function > is called for the first time on the copy. This will cause a penalty when > calling such a function as the hash has to be repopulated with all entries > (eg: calling remove on the copy will take linear time instead of constant, > although subsequent calls will have no penalty). Still thinking about it. So... right now your copy ctor is O(N) and remove is O(1), correct? Implicit sharing makes your copy ctor O(1) and detach() O(N). IOW, you've just deferred the copy cost until a non-const method is called. That's basically what COW does... (p.s. This thread should probably be on interest at qt-project.org...) -- Matthew From mwoehlke.floss at gmail.com Mon Jul 31 20:20:43 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 31 Jul 2017 14:20:43 -0400 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: Message-ID: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> On 2017-07-31 13:11, Mandeep Sandhu wrote: > Right now, I'm detaching the linked list during copy-construction (and > assignment). Detaching here means re-populating the LL with same entries > and then storing the new LL iterator's in the hash. > > For implicit sharing, I'll have to this instead when a non-const function > is called for the first time on the copy. This will cause a penalty when > calling such a function as the hash has to be repopulated with all entries > (eg: calling remove on the copy will take linear time instead of constant, > although subsequent calls will have no penalty). Still thinking about it. So... right now your copy ctor is O(N) and remove is O(1), correct? Implicit sharing makes your copy ctor O(1) and detach() O(N). IOW, you've just deferred the copy cost until a non-const method is called. That's basically what COW does... (p.s. This thread should probably be on interest at qt-project.org...) -- Matthew From thiago.macieira at intel.com Mon Jul 31 20:23:15 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 31 Jul 2017 11:23:15 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> References: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> Message-ID: <3882745.fJSbcaUhA8@tjmaciei-mobl1> On segunda-feira, 31 de julho de 2017 11:20:43 PDT Matthew Woehlke wrote: > (p.s. This thread should probably be on interest at qt-project.org...) Unless you're planning to submit this code to Qt itself, in which case you have to implement the implicit sharing as Qt requires. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mandeepsandhu.chd at gmail.com Mon Jul 31 20:57:07 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 31 Jul 2017 11:57:07 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> References: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> Message-ID: > > > So... right now your copy ctor is O(N) and remove is O(1), correct? > Yes. > Implicit sharing makes your copy ctor O(1) and detach() O(N). IOW, > you've just deferred the copy cost until a non-const method is called. > That's basically what COW does... > Yes I understand that. And people will probably be expecting that (COW) since my container is based on other Qt containers. Thanks for your input. -mandeep > (p.s. This thread should probably be on interest at qt-project.org...) > > -- > Matthew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandeepsandhu.chd at gmail.com Mon Jul 31 20:59:54 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 31 Jul 2017 11:59:54 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: <3882745.fJSbcaUhA8@tjmaciei-mobl1> References: <1347a26e-fb37-cfa9-9146-c163335c3d14@gmail.com> <3882745.fJSbcaUhA8@tjmaciei-mobl1> Message-ID: On Mon, Jul 31, 2017 at 11:23 AM, Thiago Macieira wrote: > On segunda-feira, 31 de julho de 2017 11:20:43 PDT Matthew Woehlke wrote: > > (p.s. This thread should probably be on interest at qt-project.org...) > > Unless you're planning to submit this code to Qt itself, in which case you > have to implement the implicit sharing as Qt requires. > Would there be any interest in incorporating such functionality in the existing container classes - i.e a map which maintains keys in insertion (and access) order? This container is similar to Python's "OrderedDict". -mandeep > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jul 31 21:37:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 31 Jul 2017 12:37:10 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: <3882745.fJSbcaUhA8@tjmaciei-mobl1> Message-ID: <1932821.jQ6KmOpCoi@tjmaciei-mobl1> On segunda-feira, 31 de julho de 2017 11:59:54 PDT Mandeep Sandhu wrote: > On Mon, Jul 31, 2017 at 11:23 AM, Thiago Macieira > wrote: > > > > On segunda-feira, 31 de julho de 2017 11:20:43 PDT Matthew Woehlke wrote: > > > (p.s. This thread should probably be on interest at qt-project.org...) > > > > Unless you're planning to submit this code to Qt itself, in which case you > > have to implement the implicit sharing as Qt requires. > > Would there be any interest in incorporating such functionality in the > existing container classes - i.e a map which maintains keys in insertion > (and access) order? Maybe. I don't know how many would use it and whether it's worth spending our development time on it, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mandeepsandhu.chd at gmail.com Mon Jul 31 22:36:49 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 31 Jul 2017 13:36:49 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: <1932821.jQ6KmOpCoi@tjmaciei-mobl1> References: <3882745.fJSbcaUhA8@tjmaciei-mobl1> <1932821.jQ6KmOpCoi@tjmaciei-mobl1> Message-ID: > > > Maybe. I don't know how many would use it and whether it's worth spending > our > development time on it, though. > It might be useful to a lazy programmer though, who doesn't want to implement it on his/her own :) It's not really a fundamental container itself, but rather uses a QHash & QLinkedList to do the job. So it's not something that people can't implement on their own. It's just that a a proper Qt container will have have some of the more useful bells & whistles like a lean and consistent API, iterators & implicit sharing (again something that the lazy programmer wouldn't be too inclined to do). I'll tidy things up in my private repo and make it as complete-as-possible for inclusion. I'll start a separate thread after I'm done, to discuss here if such a container is warranted for inclusion or not. Thanks, -mandeep > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jul 31 22:55:07 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 31 Jul 2017 13:55:07 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: <1932821.jQ6KmOpCoi@tjmaciei-mobl1> Message-ID: <4432140.ttfqaDjMO5@tjmaciei-mobl1> On segunda-feira, 31 de julho de 2017 13:36:49 PDT Mandeep Sandhu wrote: > > Maybe. I don't know how many would use it and whether it's worth spending > > our > > development time on it, though. > > It might be useful to a lazy programmer though, who doesn't want to > implement it on his/her own :) > It's not really a fundamental container itself, but rather uses a QHash & > QLinkedList to do the job. So it's not something that people can't The fact that you're using QHash makes it uninteresting. I'd expect to be able to use keys that do not define qHash or qLess. Search would be O(n). So be it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Mon Jul 31 23:26:49 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 31 Jul 2017 23:26:49 +0200 Subject: [Development] implicit sharing and iterators in qt containers References: Message-ID: Mandeep Sandhu wrote: > For implicit sharing, I'll have to this instead when a non-const function > is called for the first time on the copy. This will cause a penalty when > calling such a function as the hash has to be repopulated with all entries > (eg: calling remove on the copy will take linear time instead of constant, > although subsequent calls will have no penalty). Still thinking about it. Well, that's the Qt way: to avoid copying until you really have to. The unshared container you currently have is not very idiomatic Qt. Kevin Kofler From mandeepsandhu.chd at gmail.com Mon Jul 31 23:36:59 2017 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 31 Jul 2017 14:36:59 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: <4432140.ttfqaDjMO5@tjmaciei-mobl1> References: <1932821.jQ6KmOpCoi@tjmaciei-mobl1> <4432140.ttfqaDjMO5@tjmaciei-mobl1> Message-ID: > > > I'd expect to be able to use keys that do not define qHash or qLess. > Why? > > Search would be O(n). So be it. > Well it wouldn't be much of a "map" then, would it? I see OrderedMap similar to a QMap, just with a different key ordering scheme. So in that way, constant time lookups would be _must_ I would say (although QMap lookups log(n) time). It is after all a key-value store. -mandeep > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jul 31 23:57:54 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 31 Jul 2017 14:57:54 -0700 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: <4432140.ttfqaDjMO5@tjmaciei-mobl1> Message-ID: <1920508.xjn6X5LUKW@tjmaciei-mobl1> On segunda-feira, 31 de julho de 2017 14:36:59 PDT Mandeep Sandhu wrote: > > I'd expect to be able to use keys that do not define qHash or qLess. > > Why? My type key type may be or contain an opaque non-orderable type, which would make implementing both qHash and qLess impossible. Right now, if you have such a key type, you can't use QMap or QHash. Example type: QVariant. Therefore, for this new container to add something we currently do not have, it MUST NOT require either function. > > Search would be O(n). So be it. > > Well it wouldn't be much of a "map" then, would it? Sure it would. There's nothing that requires associative containers to have search times better than O(n). It just happens that both std::map and QMap implements them at O(log n). > I see OrderedMap > similar to a QMap, just with a different key ordering scheme. So in that > way, constant time lookups would be _must_ I would say (although QMap > lookups log(n) time). It is after all a key-value store. No, sorry, I won't accept that container in Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Mon Jul 31 23:58:21 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 31 Jul 2017 17:58:21 -0400 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: <1932821.jQ6KmOpCoi@tjmaciei-mobl1> <4432140.ttfqaDjMO5@tjmaciei-mobl1> Message-ID: <68429c0d-6d44-9bff-9642-26bf9c96e685@gmail.com> On 2017-07-31 17:36, Mandeep Sandhu wrote: >> I'd expect to be able to use keys that do not define qHash or qLess. > > Why? Why not? >> Search would be O(n). So be it. > > Well it wouldn't be much of a "map" then, would it? It's still a key-value store in which items are retrieved by key, which is sort of the definition of a "map". It just has inefficient look-up. -- Matthew From mwoehlke.floss at gmail.com Mon Jul 31 23:58:21 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 31 Jul 2017 17:58:21 -0400 Subject: [Development] implicit sharing and iterators in qt containers In-Reply-To: References: <1932821.jQ6KmOpCoi@tjmaciei-mobl1> <4432140.ttfqaDjMO5@tjmaciei-mobl1> Message-ID: <68429c0d-6d44-9bff-9642-26bf9c96e685@gmail.com> On 2017-07-31 17:36, Mandeep Sandhu wrote: >> I'd expect to be able to use keys that do not define qHash or qLess. > > Why? Why not? >> Search would be O(n). So be it. > > Well it wouldn't be much of a "map" then, would it? It's still a key-value store in which items are retrieved by key, which is sort of the definition of a "map". It just has inefficient look-up. -- Matthew