There is a warning in the OS X part of the build instructions (OS X builds with clang) not to do a parallel build (-J > 1) due to competing dependencies.
> On Nov 5, 2018, at 2:32 PM, interest-requ...@qt-project.org wrote: > > Send Interest mailing list submissions to > interest@qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/interest > or, via email, send a message with subject or body 'help' to > interest-requ...@qt-project.org > > You can reach the person managing the list at > interest-ow...@qt-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Interest digest..." > Today's Topics: > > 1. Re: Chasing a standard (rol...@logikalsolutions.com) > 2. Re: Chasing a standard (rol...@logikalsolutions.com) > 3. Re: Interest Digest, Vol 86, Issue 5 (rol...@logikalsolutions.com) > 4. Re: Chasing a standard (Jason H) > 5. Re: update on building Qt/Linux with clang? > (Allan Sandfeld Jensen) > 6. Re: update on building Qt/Linux with clang? > (Allan Sandfeld Jensen) > 7. Re: update on building Qt/Linux with clang? > (Jean-Micha?l Celerier) > 8. Re: Chasing a standard (rol...@logikalsolutions.com) > 9. Re: update on building Qt/Linux with clang? > (william.croc...@analog.com) > 10. Re: Chasing a standard (J?r?me Godbout) > 11. Re: Chasing a standard (rol...@logikalsolutions.com) > 12. Re: Chasing a standard (J?r?me Godbout) > 13. Re: Qt 5.12 Beta 3 slows down ext Javascript library (RSA > encrypt) (Thiago Macieira) > 14. Re: update on building Qt/Linux with clang? (Thiago Macieira) > 15. Re: Interest Digest, Vol 86, Issue 5 (Giuseppe D'Angelo) > 16. Re: update on building Qt/Linux with clang? (Ren? J.V. Bertin) > 17. Re: Qt 5.12 Beta 3 slows down ext Javascript library (RSA > encrypt) (ekke) > > From: rol...@logikalsolutions.com > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 9:39:38 AM EST > To: Tomasz Siekierda <sierd...@gmail.com> > Cc: lars.kn...@qt.io, interest@qt-project.org > > > > Quoting Tomasz Siekierda <sierd...@gmail.com>: > >> On Mon, 5 Nov 2018 at 13:35, Roland Hughes <rol...@logikalsolutions.com> >> wrote: >>> >>> >>> On 11/4/18 3:52 PM, Lars Knoll wrote: >>> >> On 4 Nov 2018, at 22:13, Roland Hughes <rol...@logikalsolutions.com> >>> >> wrote: >>> >> >>> >> >>> >> We already lose droves of Qt developers every year when Qt keeps moving >>> >> on but medical devices, border security systems like cargo x-ray, train >>> >> control systems, etc. have to fork their own version of Qt because Qt >>> >> keeps moving on without a 5-8 year LTS. >>> > Yes, the Open source and standard commercial versions come with a maximum >>> > of 3 years for LTS releases. But you can get longer support for Qt >>> > versions from The Qt Company though. >>> >>> Three years isn't a drop of water in Lake Michigan. A completely new >>> surgical robot will take a minimum of 4 years design and prototyping >>> followed by 1-3 years of development (which must also include the >>> _entire_ manufacturing process for certification.) Then it goes through >>> clinical trials which can last upwards of 7 years. Once released to the >>> field it will be in maintenance/minor enhancement mode for 10 years or >>> more. This entire time the tool set must be locked down. >> >> Since the tool is locked down, then it does not matter if Qt has moved >> on or not, right? You're not allowed to upgrade/ change it anyway, you >> have to stick to what you deployed. So there is no reason to complain >> about lack of support here. That's the reality of such big and long >> term projects. NASA also still keeps operational their computers from >> 1970 to handle Voyager missions. It does not mean that the >> manufacturers of these PC are somehow obligated to support them >> anymore. > > > This would be a gross missunderstanding of how the FDA "lockdown" is actually > applied. Minor bug fixes can have documentation generated via an FDA approved > process with dramatically reduced testing cycle since it is mostly negative > testing. (Negative testing being testing no changes to other existing > functionality.) The definition of "minor" is totally within the purview of > the FDA and argued case by case. > > As far as manufacturers and obligations, see below. > >> >>> Just this year a drug manufacturer in California fielded a job opening >>> looking for a PDP-11 systems manager familiar with hardware maintenance. >>> Some of you may recall that a PDP-11 was the machine C and UNIX were >>> developed on in the 1970s. It was _the_ midrange computer of its day but >>> hasn't been manufactured since the late 1980s. >> >> And you bring this up because PDP-11 is still supported by its >> (non-existing by since 20 years) manufacturer just like Qt should? > > There are quite a few places still providing support for the PDP-11 line. > Quite a few companies stock piled 11/24 and 11/44 machines as others moved to > VAX, ALPHA, and ITANIUM. Ownership of the line moved from DEC to Compaq to HP. > > Shortly after Compaq consumed Digital Equipment Corporation, Microsoft paid > them a bunch of money to announce the death of OpenVMS in a bid to get feeble > Windows servers running on Compaq PCs into data centers where they were > previously barred. Some corporations started to make the move. The NSA and > DOD paid Compaq a Microsoft a visit. They showed them the sales and support > contracts making cessation of the platform an act of treason and informed the > leaders of both companies just how lengthy their prison time would be. You > see, Bill Gates could bribe Bill and Hillary Clinton to make the Janet Reno > investigation go in a "don't put Bill in prison for wire and mail fraud" > direction, but the DOD and NSA weren't smiling and given their budgets, no > interested in any bribe either company could offer. > > Compaq then announced they weren't killing off OpenVMS and Bill Gates stepped > out of the go-to-prison hot seat as part of the apology. The other details I > do not know. I do know there was much more than that involved. > > NASA had, and probably still has similar contracts. > > These long term support contracts are why we have $12 wooden pencils and $800 > hammers. That __EXACT__ product has to remain available and replacable for > many many decades. Even if every tree of that type dies on the planet, the > vendor who signed the contract must still find a way to make that __EXACT__ > pencil with that __EXACT__ wood and other components. There is still a vendor > prodiving 8 inch floppies to the DOD because they are used to boot the > nuclear missile launch systems. Given the short life of floppies, they aren' > surviving on a eBay stockpile. They are actually making them every so often. > > If Qt wishes to play in the embedded world, it has to come to grips with this > reality. It's not a "chase the latest idiot phone trend" world. This is why > you are starting to see various companies who would otherwise consider each > other competitors banding together to maintain the now abandoned Qt releases. > Most every year or at least every other year I get emails and calls about > doing Qt 3 work on OS/2 from this Harman (sp?) consulting firm. Minor changes > to an existing medical device whose systems were built using those tools. > > One of my past clients had almost nothing to do with the DOD post WW-II, but, > they still have all of the equipment to make torpedos for said boats and > ships. They must keep it on site in good condition until the contract ends. > I've been told that contract doesn't end until the last vessel of war > capabile of firing said munitions is scuttled. I have not personally seen the > contract, nor do I wish to. You will find every major manufacturer which > existed during WW-II has a similar contract for something else. These > contracts don't expire until the DOD deems what they manufactured > non-strategic and disposes of it. > > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > > > > > From: rol...@logikalsolutions.com > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 9:42:36 AM EST > To: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> > Cc: Lars Knoll <lars.kn...@qt.io>, interest <interest@qt-project.org> > > > > Quoting Jean-Michaël Celerier <jeanmichael.celer...@gmail.com>: > >>> As I said a couple of times, we do not intend to break APIs in any major >> way when moving towards Qt 6. That also implies that our container API is >> there to stay. But where we can streamline/align with standard C++ in good >> ways, we probably should try to do that. >> >> It's not only about breaking APIs but also breaking current observable >> behaviour - i.e. performance. Currently if you're passing data across >> threads - e.g. compute something in a thread and pass the result to the >> main thread to display it - you generally pass a QVector / QList / >> QWhatever that does implicit sharing, because the signal-slot mechanism >> will do a copy of the object in any case across threads and doing two >> atomic operations for a QVector copy is cheaper than creating a new >> std::vector, calling malloc, and copying 500 ints however you look at it. >> What is the option if Qt opts out from this ? put everything in shared_ptr >> ? > > Very good catch. > > Battery powered embedded systems in the medical and industrial world have > wretched dynamic memory allocation. If the underlying implementation does > away with shallow/no-copy passing between threads for some std:: version > which requires giahugic (given 512 MEG total working RAM) data sets with > sluggish allocation (if enough memory exists at all) this is an extreme price. > > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > > > > > From: rol...@logikalsolutions.com > Subject: Re: [Interest] Interest Digest, Vol 86, Issue 5 > Date: November 5, 2018 at 10:07:04 AM EST > To: interest@qt-project.org > > > > Quoting Giuseppe D'Angelo: > > ==== > Hold on -- I don't think that anyone wants to make Qt containers NOT > implictly shared. In other words, Qt 6 containers will be implictly > shared just as today. It would be a gigantic break if we suddenly made > them not shared. > ==== > > Well, there have been others on this list making statements about Qt no > longer investing effort to do things std:: already does. I myself earlier > this year was involved with an exchange where someone was telling people to > use std::vector becase QVector was deprecated going forward. > > That definitely would be a gigantic break. > > Switching the containers to just be wrappers around std:: implementations > would also be a dramatic break. > > > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > > > > > From: "Jason H" <jh...@gmx.com> > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 10:13:00 AM EST > To: rol...@logikalsolutions.com > Cc: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>, interest > <interest@qt-project.org> > > > > >> Sent: Monday, November 05, 2018 at 9:42 AM >> From: rol...@logikalsolutions.com >> To: "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com> >> Cc: interest <interest@qt-project.org> >> Subject: Re: [Interest] Chasing a standard >> >> >> Quoting Jean-Michaël Celerier <jeanmichael.celer...@gmail.com>: >> >>>> As I said a couple of times, we do not intend to break APIs in any major >>> way when moving towards Qt 6. That also implies that our container API is >>> there to stay. But where we can streamline/align with standard C++ in good >>> ways, we probably should try to do that. >>> >>> It's not only about breaking APIs but also breaking current observable >>> behaviour - i.e. performance. Currently if you're passing data across >>> threads - e.g. compute something in a thread and pass the result to the >>> main thread to display it - you generally pass a QVector / QList / >>> QWhatever that does implicit sharing, because the signal-slot mechanism >>> will do a copy of the object in any case across threads and doing two >>> atomic operations for a QVector copy is cheaper than creating a new >>> std::vector, calling malloc, and copying 500 ints however you look at it. >>> What is the option if Qt opts out from this ? put everything in shared_ptr >>> ? >> >> Very good catch. >> >> Battery powered embedded systems in the medical and industrial world >> have wretched dynamic memory allocation. If the underlying >> implementation does away with shallow/no-copy passing between threads >> for some std:: version which requires giahugic (given 512 MEG total >> working RAM) data sets with sluggish allocation (if enough memory >> exists at all) this is an extreme price. > > Medical and Space-based systems should use the NASA (JPL) coding standard. > Chief of which is no dynamic memory after initialization. So all your > container arguments are moot. > ( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course > you're using mysmic memory after initialization in a medical device (But > then, WHY!?)) > > I've also attributed failures on long-running commodity hardware > (RaspberryPis) to the memory fragmentation issue of dynamic memory. > Interestingly, this is why other languages (C#, Java) have dynamic memory > consolidation capability (i.e. Mark & Sweep, "Handles" (^) in the .NET C++ > CLR). But as the JPL standard shows, you do not need to create > non-deterministic garbage collection in your language. While I attributed > this to failures on a Pi, I have actually researched and concluded that this > indeed was the case on an embedded application on a PPC 860. Removing dynamic > memory and reverting to fixed-arrays eliminated the crashes after months of > run-time. Unfortunately this is nearly impossible on a Pi with it's much > larger software ecosystem. > > > > > > > > From: Allan Sandfeld Jensen <k...@carewolf.com> > Subject: Re: [Interest] update on building Qt/Linux with clang? > Date: November 5, 2018 at 10:34:31 AM EST > To: interest@qt-project.org > Cc: René J.V. Bertin <rjvber...@gmail.com> > > > On Montag, 5. November 2018 12:03:31 CET René J.V. Bertin wrote: >> Hi, >> >> Last time I asked the advice was still not to bother with trying to build >> (all of) Qt with clang on Linux. Is that still the case or is it now safe >> to use clang (5 or 6)? >> >> In my experience clang generates significantly more compact binaries, which >> should reduce load times. Build time should be shorter too. >> > I build all of Qt regularly with clang to make sure qtwebengine works like > that, and I have never had any issues. You can even use clang-libc++ if you > make sure not to depend on any system C++ libraries. > > 'Allan > > > > > > > From: Allan Sandfeld Jensen <k...@carewolf.com> > Subject: Re: [Interest] update on building Qt/Linux with clang? > Date: November 5, 2018 at 10:38:04 AM EST > To: interest@qt-project.org > Cc: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com>, René J.V. > <rjvber...@gmail.com> > > > On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote: >> I tried building everything with clang 7 and libc++ last week but hit a >> qlalr segfault during build. I've been trying to debug it ever since to no >> avail. >> >> > clang sometimes segfaults while compiling, the crash usually goes if I try > again. It seems to just randomly crash once for every ~10 thousand files > compiled for no reason. The fact the crashes are random and not stable > doesn't > really raise my confidence in clang code quality though, but it is easy to > work around. Just keep calling make until it makes it. > > 'Allan > > > > > > > From: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> > Subject: Re: [Interest] update on building Qt/Linux with clang? > Date: November 5, 2018 at 10:50:10 AM EST > To: Allan Sandfeld Jensen <k...@carewolf.com> > Cc: interest <interest@qt-project.org>, René J.V. <rjvber...@gmail.com> > > > > clang sometimes segfaults while compiling, the crash usually goes if I try > again. > > in my case it's not clang which crashes but the qlalr that clang produces. > For some reason it works : > - when building in debug > - when building statically > > it's just the release / dynamic configuration that crashes, and I don't know > how to instruct Qt's configure to keep debug symbols for release builds of > the tools in order to get a proper stacktrace. > > > On Mon, Nov 5, 2018 at 4:38 PM Allan Sandfeld Jensen <k...@carewolf.com > <mailto:k...@carewolf.com>> wrote: > On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote: > > I tried building everything with clang 7 and libc++ last week but hit a > > qlalr segfault during build. I've been trying to debug it ever since to no > > avail. > > > > > clang sometimes segfaults while compiling, the crash usually goes if I try > again. It seems to just randomly crash once for every ~10 thousand files > compiled for no reason. The fact the crashes are random and not stable > doesn't > really raise my confidence in clang code quality though, but it is easy to > work around. Just keep calling make until it makes it. > > 'Allan > > > > > > From: rol...@logikalsolutions.com > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 10:54:36 AM EST > To: Jason H <jh...@gmx.com> > Cc: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com>, interest > <interest@qt-project.org> > > > > Quoting Jason H <jh...@gmx.com>: > >>> >>> Very good catch. >>> >>> Battery powered embedded systems in the medical and industrial world >>> have wretched dynamic memory allocation. If the underlying >>> implementation does away with shallow/no-copy passing between threads >>> for some std:: version which requires giahugic (given 512 MEG total >>> working RAM) data sets with sluggish allocation (if enough memory >>> exists at all) this is an extreme price. >> >> Medical and Space-based systems should use the NASA (JPL) coding standard. >> Chief of which is no dynamic memory after initialization. So all your >> container arguments are moot. >> ( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of >> course you're using mysmic memory after initialization in a medical device >> (But then, WHY!?)) >> > > I've never worked on a single medical device which utilized JPL. Not one. Not > saying there isn't one somewhere in the world, but, I've never seen it. One > could not use Qt in a medical device if strictly adhering to JPL. Something > simple like an error message to syslog being built with a QString would > violate such a standard. You couldn't fill in the values with .arg(). > > No, the container issue in medical device world isn't moot. It's a clear and > present danger. > > > > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > > > > > From: "william.croc...@analog.com" <william.croc...@analog.com> > Subject: Re: [Interest] update on building Qt/Linux with clang? > Date: November 5, 2018 at 10:58:14 AM EST > To: <interest@qt-project.org> > > > On 11/05/2018 10:38 AM, Allan Sandfeld Jensen wrote: >> On Montag, 5. November 2018 12:10:15 CET Jean-Michaël Celerier wrote: >>> I tried building everything with clang 7 and libc++ last week but hit a >>> qlalr segfault during build. I've been trying to debug it ever since to no >>> avail. >>> >>> >> clang sometimes segfaults while compiling, the crash usually goes if I try >> again. It seems to just randomly crash once for every ~10 thousand files >> compiled for no reason. > > Sounds like a job for valgrind. > >> The fact the crashes are random and not stable doesn't >> really raise my confidence in clang code quality though, but it is easy to >> work around. Just keep calling make until it makes it. >> >> 'Allan >> >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> >> >> > > > > > > From: Jérôme Godbout <godbo...@amotus.ca> > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 11:07:36 AM EST > To: "rol...@logikalsolutions.com" <rol...@logikalsolutions.com>, Jason H > <jh...@gmx.com> > Cc: interest <interest@qt-project.org> > > > I did a few medical application for orthopedic surgery, the coding standard > is not a requirement, but only a simplest way to validate your software. I > did used Qt into all of them and we manage to certify them for surgery room. > It always depend on the level or risk your software lies on. Also if you can > proof your software is robust enough (yeah it take a lot of testing and safe > guard everywhere) you can pass the certification. JPL only make it easier to > pass those since you proof in a easy way that it cannot goes wrong, that's > about it. > > JPL would be a good thing if you were to make a peacemaker for example. It's > more for embedded C software where dynamic alloc is not allowed (just like > car industries). If you plan on running C++ on a MCU with very limited > resource, you are looking for trouble (it's doable, but the tests time will > inflate more then what you will save from C to C++) and will need to take > very much great care of the object you create and destroy. In other word, > it's a bad idea, stick to C for embedded or critical component. > > -----Original Message----- > From: Interest <interest-bounces+godboutj=amotus...@qt-project.org> On Behalf > Of rol...@logikalsolutions.com > Sent: November 5, 2018 10:55 AM > To: Jason H <jh...@gmx.com> > Cc: interest <interest@qt-project.org> > Subject: Re: [Interest] Chasing a standard > > > Quoting Jason H <jh...@gmx.com>: > >>> >>> Very good catch. >>> >>> Battery powered embedded systems in the medical and industrial world >>> have wretched dynamic memory allocation. If the underlying >>> implementation does away with shallow/no-copy passing between threads >>> for some std:: version which requires giahugic (given 512 MEG total >>> working RAM) data sets with sluggish allocation (if enough memory >>> exists at all) this is an extreme price. >> >> Medical and Space-based systems should use the NASA (JPL) coding >> standard. Chief of which is no dynamic memory after initialization. >> So all your container arguments are moot. >> ( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of >> course you're using mysmic memory after initialization in a medical >> device (But then, WHY!?)) >> > > I've never worked on a single medical device which utilized JPL. Not one. Not > saying there isn't one somewhere in the world, but, I've never seen it. One > could not use Qt in a medical device if strictly adhering to JPL. Something > simple like an error message to syslog being built with a QString would > violate such a standard. You couldn't fill in the values with .arg(). > > No, the container issue in medical device world isn't moot. It's a clear and > present danger. > > > > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > > > > From: rol...@logikalsolutions.com > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 11:29:54 AM EST > To: Jérôme Godbout <godbo...@amotus.ca> > Cc: Jason H <jh...@gmx.com>, interest <interest@qt-project.org> > > > > Quoting Jérôme Godbout <godbo...@amotus.ca>: > >> JPL would be a good thing if you were to make a peacemaker for example. It's >> more for embedded C software where dynamic alloc is not allowed (just like >> car industries). If you plan on running C++ on a > > Stupid question, but if dynamic memory allocation is not allowed in the > automotive industry, how is it Ford is constantly looking for low wage Qt > developers? More a curiosity than anything else. Those contracts pay less > than 1/3 of my standard billing rate so the emails and phone calls about them > land in the virtual bit bucket. > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > > > > > From: Jérôme Godbout <godbo...@amotus.ca> > Subject: Re: [Interest] Chasing a standard > Date: November 5, 2018 at 11:43:44 AM EST > To: "rol...@logikalsolutions.com" <rol...@logikalsolutions.com> > Cc: Jason H <jh...@gmx.com>, interest <interest@qt-project.org> > > > Qt is probably only used into a part of the Dashboard or entertainment > system, the controller chip or embedded MCU and other safety controller are > probably not using Qt nor C++. They follow some MISRA, AUTOSAR, CERT > standard. They have a C++ standard, but seriously it prevent a good chunk of > the language usage. Like in the medical, it always on which system critical > part your software going to run, the radio with BLE phone that crash is one > thing, the wheel control is another matter. If you don't follow those > standard (which is possible), the burden of the proof of reliability false on > you and you have to prove how your software can NEVER be a life threat. > > > -----Original Message----- > From: rol...@logikalsolutions.com <rol...@logikalsolutions.com> > Sent: November 5, 2018 11:30 AM > To: Jérôme Godbout <godbo...@amotus.ca> > Cc: Jason H <jh...@gmx.com>; interest <interest@qt-project.org> > Subject: Re: [Interest] Chasing a standard > > > Quoting Jérôme Godbout <godbo...@amotus.ca>: > >> JPL would be a good thing if you were to make a peacemaker for >> example. It's more for embedded C software where dynamic alloc is >> not allowed (just like car industries). If you plan on running C++ >> on a > > Stupid question, but if dynamic memory allocation is not allowed in > the automotive industry, how is it Ford is constantly looking for low > wage Qt developers? More a curiosity than anything else. Those > contracts pay less than 1/3 of my standard billing rate so the emails > and phone calls about them land in the virtual bit bucket. > -- > Roland Hughes, President > Logikal Solutions > (630) 205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > http://lesedi.us > > > > > From: Thiago Macieira <thiago.macie...@intel.com> > Subject: Re: [Interest] Qt 5.12 Beta 3 slows down ext Javascript library (RSA > encrypt) > Date: November 5, 2018 at 11:59:46 AM EST > To: <interest@qt-project.org> > > > On Monday, 5 November 2018 05:49:33 PST ekke wrote: >> created a example app and now noticed, the app doesn't freeze, >> but the exection of encrypt() slows down from >> >> 5 sec (Qt 5.11.2) to >> 92 sec (Qt 5.12 Beta3) >> >> will open a bug report > > How about you encrypt using C++ instead? OpenSSL probably has the encryption > you need. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > > > > > From: Thiago Macieira <thiago.macie...@intel.com> > Subject: Re: [Interest] update on building Qt/Linux with clang? > Date: November 5, 2018 at 12:01:31 PM EST > To: <interest@qt-project.org> > > > On Monday, 5 November 2018 07:50:10 PST Jean-Michaël Celerier wrote: >> it's just the release / dynamic configuration that crashes, and I don't >> know how to instruct Qt's configure to keep debug symbols for release >> builds of the tools in order to get a proper stacktrace. > > Edit the Makefile after generation and add -g to the CXXFLAGS of the relevant > builds. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > > > > > From: Giuseppe D'Angelo <giuseppe.dang...@kdab.com> > Subject: Re: [Interest] Interest Digest, Vol 86, Issue 5 > Date: November 5, 2018 at 12:21:02 PM EST > To: interest@qt-project.org > > > Hi, > > Il 05/11/18 16:07, rol...@logikalsolutions.com ha scritto: >> Switching the containers to just be wrappers around std:: >> implementations would also be a dramatic break. > > Assuming by "wrappers" you mean "implicitly shared wrappers", why would it be > a break? > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > > > > From: René J.V. Bertin <rjvber...@gmail.com> > Subject: Re: [Interest] update on building Qt/Linux with clang? > Date: November 5, 2018 at 12:55:21 PM EST > To: Jean-Michaël Celerier <jeanmichael.celer...@gmail.com> > Cc: Allan Sandfeld Jensen <k...@carewolf.com>, interest > <interest@qt-project.org> > > > On Monday November 05 2018 16:50:10 Jean-Michaël Celerier wrote: > >> it's just the release / dynamic configuration that crashes, and I don't >> know how to instruct Qt's configure to keep debug symbols for release >> builds of the tools in order to get a proper stacktrace. > > I use these arguments to configure: -no-strip -no-separate-debug-info > --force-debug-info > > Or skip the last, and just run `qmake -config force_debug_info > /path/to/qtcomponent/qtcomponent.pro` in the build directory for the > component(s) you want to have debug info for (useful if you only want it in > qtbase). > Clang apparently also wants -fno-limit-debug-info if you really want to have > useful debug info (though I can't tell if it really makes a difference). > >>> clang sometimes segfaults while compiling, the crash usually goes if I try >>> again. It seems to just randomly crash once for every ~10 thousand files >>> compiled for no reason. The fact the crashes are random and not stable >>> doesn't >>> really raise my confidence in clang code quality though, but it is easy to >>> work around. Just keep calling make until it makes it. > > My build with clang just completed fine, of all components except qt3d, > qtwebengine and qtwebview. I've not seen clang crash when compiling Qt code > on Mac for a long time, but there it uses a fully native libc++ which may > make a difference. > > I'd expect your build machine is probably much more powerful than mine, but > what if those random crashes are due to some sort of resource depletion or > contention? That's really the only thing that makes some kind of sense... and > I'm almost certain I've already seen MacPorts ports that are built in > non-parallel fashion because clang crashes otherwise. > > R. > > > > > From: ekke <e...@ekkes-corner.org> > Subject: Re: [Interest] Qt 5.12 Beta 3 slows down ext Javascript library (RSA > encrypt) > Date: November 5, 2018 at 2:32:03 PM EST > To: interest@qt-project.org > > > Am 05.11.18 um 17:59 schrieb Thiago Macieira: >> On Monday, 5 November 2018 05:49:33 PST ekke wrote: >>> created a example app and now noticed, the app doesn't freeze, >>> but the exection of encrypt() slows down from >>> >>> 5 sec (Qt 5.11.2) to >>> 92 sec (Qt 5.12 Beta3) >>> >>> will open a bug report >> How about you encrypt using C++ instead? OpenSSL probably has the encryption >> you need. >> > Thanks, Thiago for the hint - that was the first thing I tried, but > couldn't figure out HowTo make it work on Android and iOS. > > It's only used when password has changed and must be entered: then > password must be RSA encrypted and base64 sent to server > > so I was happy to find a JS solution which was implemented easy for > Android / iOS: > > function doEncrypt() { > var rsa = new MyRsa.RSAKey(); > rsa.setPublic(dataServer.modulusHex(), "10001") > var res = rsa.encrypt(pwText.text) > if(res) { > return MyRsa.linebrk(res, 64) > } else { > return "" > } > } > > unfortunately now with 5.12 Beta it slows down by 20x. > > on Android per ex. from 80 ms to 1700 ms (acceptable for my customer) > > but iOS now is too slow > > ekke > > > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
