Re: [Development] Nominating Jüri Valdmann for Approver status
+1 from me. He does a very good job. On 27.04.2018 10:58, Michal Klocek wrote: > Hi > > I would like to nominate Jüri Valdmann for Approver. > > He joined The Qt Company more than one year ago and he's been doing most > of his excellent work for QtWebEngine. > > You can see his contributions here: > > https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z > > Br > > Michal > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fornux C++ Superset
On 25.04.2018 14:02, Phil Bouchard wrote: > You need to see the big picture; memory leaks are the most difficult > problems to solve. You have clearly never solved a cycle-lock. -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for WebAssembly
I am personally quite excited about having a common standard for binaries on the web, that can be generated from C++ and I think there is a lot of potential and I am happy to see Qt going in that direction. Regarding the load-times: WebAssembly supports dynamic linking, so browsers might cache Qt libraries, so they would only have to download them once. If the pages loaded the libs from a common location (say download.qt.io), they would even only have to load them once for all pages that use them. (I do have to say that I've had bad experiences with the caching of wasm files - sometimes they aren't even reloaded after new versions are on the server... but that should only be a temporary problem). About the threading: there are Web Workers in the HTML5 standard. These basically are threads, but they are harder to use (for example because of /*strict*/ ownership of objects), so it might not be feasible to map threads to Web Workers... Just throwing it into the discussion. -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Code of Conduct (was: Speeding up the review process)
oops - what I wanted to say about code of conduct: this is precisely why I opposed a code of conduct in the QtCS discussion. A code of conduct would pretty much lead to a situation where it doesn't matter if a message is understood correctly - the one who wrote it is to blame by default. Some people will misuse such a "My response is always right" free-pass to silence every topic they don't like and (in the long run) that would lead to a situation where you will respond to mails/bugreports/... only with AutoText. On 16.10.2017 08:34, Viktor Engelmann wrote: > On 13.10.2017 15:33, Christian Kandeler wrote: >>> Sure - but let's think about this in a different context: imagine >>> someone applies at your company. You invite them to a job interview and >>> have one of your engineers do a technical interview with them. >>> >>> Do you afterwards go to the applicant and ask them if they thought your >>> engineer was competent and fire your engineer if the applicant says "no"? >> This is an incredibly arrogant stance to take. No contributor is above >> others because of their employer. > I said nothing that could reasonably be interpreted this way. > And I will not respond to personal insults. > -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)
I am thinking about the scenario when I read a 300 line commit and I am unsure about some of the lines. Say it removes one include and adds another include. If that commit comes from someone whom I talk to every day - someone whom I know to be very concerned about security and privacy - and someone I know is competent and has approver rights - I might ignore these 2 lines and assume that the compiler will fail on the CI in case the removed header was still needed. When the commit comes from someone whom I have never heard of - I will look into whether there is a symbol that will now be resolved differently - and if there is, I assume that this "differently" opens a backdoor. On 13.10.2017 14:52, Marc Mutz wrote: > On 2017-10-13 13:04, Viktor Engelmann wrote: >> * I don't think we need to be as paranoid towards contributions >> from >> our own employees as we need to be towards external contributions. > > I believe you got that the wrong way around :) > > Thanks, > Marc > -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)
On 13.10.2017 14:22, André Hartmann wrote: > Hi Victor, > > just my 2 cent to one part: > >> 4. I don't think we need to be as paranoid towards contributions >> from > our own employees as we need to be towards external >> contributions. > Anyone with approver rights should be aware of his powers and use them > carefully, no matter if he is employed at The Qt Company or an > external contributor. Sure - but let's think about this in a different context: imagine someone applies at your company. You invite them to a job interview and have one of your engineers do a technical interview with them. Do you afterwards go to the applicant and ask them if they thought your engineer was competent and fire your engineer if the applicant says "no"? > As it was stated on this mailing list some weeks ago: Only approve if > you can take the blame on breaking something. We shouldn't blame in the first place. We are all trying to make Qt better. I only wish I could spend more time doing actual WORK on Qt. > Best regards, > André -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)
On the [Interest] mailing list there was a discussion about the review-process taking to long and we also had multiple discussions about that at the world summit. I have complained about this myself, so I would like to start a new thread and collect your thoughts and ideas on how to improve the situation. My suggestions would be 1. Allow approving your own commits under certain circumstances. examples: 1. when you only changed minor things like a variable name (except in public API), a string, a comment or qdoc entry 2. when you already had a +2 and only changed minor things like a variable name, a string, a comment or qdoc entry (or more generally: when you already had a +2 and only did something that is also on this list :-D ) 3. when you only increased a timeout in an autotest. Increasing timeouts is a safe change - it can only solve false negatives and false positives, but not create false positives or false negatives. 4. or more general: when you only made an autotest harder to pass - like adding a Q_VERIFY, Q_COMPARE, etc. 5. when the change is something auto-generated - like you just updated plugins.qmltypes using qmlplugindump 6. when you only changed something in accordance to the guidelines - like Q_DECL_OVERRIDE -> override 7. when you have a certain count of +1's from people who have approver rights 2. Towards that last point: I think many of us are afraid to get blamed for +2'ing something that causes problems later (introduces a new bug or so), but as far as I have seen, nobody gets blamed for such problems, so we should not be THAT afraid of approving something. Also, don't forget that there is still the CI to get past! 3. Remember that brain-cycles are far more expensive than CPU cycles - so when in doubt, rather test-run something on the CI than make a human think about whether the CI "would" accept it. If that causes CI outages, we need to buy more CI machines. It is just a naive fallacy to "save" CI expenses by assigning the CI's work to employees who are much more expensive. 4. I don't think we need to be as paranoid towards contributions from our own employees as we need to be towards external contributions. 5. Set a deadline for criticism on the general approach to a change. Too often I have had the situation that I uploaded a patch, then we debated the qdoc entries, variable names, method names, etc FOR MONTHS - and when I thought we were finally wrapping up and I could soon submit it, someone else chimes in and says "this should be done completely differently". Even if the person is right - they should have said that months earlier - before I wasted all that valuable time on variable names, compliance with qdoc guidelines, etc. In earlier discussions I have been told that such a deadline would have to be long, because someone who might have an opinion might be on vacation. IMHO, this doesn't count, because a) you can still make an exception to the rule in such a situation and b) by that logic you should never approve anything, because we also might hire a new employee in 10 years who might have an opinion. -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using private API for qt-based library
On 25.09.2017 10:29, iman ahmadvand wrote: > Hi every one. > I'm developing a set of specialized opensource widgets in c++ (called > MaterialWidgets which is google material design implementation) > Now i want to use private API for this library to prevent re > implementing a bunch of logics behind those widgets. > > What is your suggestion ? don't > As this lib depends on Qt, is it a bad idea to use private parts ? > Do you have other good design practice for me ? > > For a showcase > <https://github.com/qt/qtbase/blob/dev/src/widgets/widgets/qabstractscrollarea_p.h#L76> > i > need to access QAbstractScrollAreaPrivate::scrollBarContainers->layout > and remove scrollbars fromQAbstractScrollArea::viewport in my > implementation. > Regards. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Containers member functions for algorithm
I agree, but Marc actually just said that creator could suggest functions with signature f(T) when one presses . after an object o of type T. That's not the same as allowing the syntax o.f() to call f(o). On 23.03.2017 11:51, Konrad Rosenbaum wrote: > On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote: >> There're >> proposals floating around for years to make o.f() fall back to f(o) for std >> C++. > Those are a lot more pain than you'd think! This construct already exists in > C# (static extension classes/methods) and it is causing major headaches there > - depending on your using statements (equiv. of #include) what looks like a > simple method call can mean totally different things or not work at all! A > change in a different section of the class that necessitates an additional > using directive may cause all kinds of mayhem. It is a nightmare if you have > to diagnose problems. > > In short: the recommendation in the C# world is: "do not use them unless you > absolutely positively have no other choice." We should take that as a warning. > > > Konrad > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of std::function in Qt API
On 17.03.2017 06:39, Thiago Macieira wrote: > Em quinta-feira, 16 de março de 2017, às 16:26:20 PDT, André Pönitz escreveu: >> On Thu, Mar 16, 2017 at 01:23:55PM -0400, Matthew Woehlke wrote: >>> On 2017-03-14 13:33, André Pönitz wrote: >>>> In general, I am not overly sold on ABI compatibility promises. I >>>> personally could live without and find SC of more practical value. The >>>> most important "feature" of ABI compatibility guarantee for me is that >>>> it limits people from doing overly excessive source-incompatible >>>> changes. >>> Distros are likely to care; a Qt BC break requires a mass rebuild of >>> everything that uses Qt (which translates into lots of users needing to >>> update lots of packages when Qt changes). ... >> nor, in case the distro *and* the user >> consciously decided to upgrade, why that would be a problem. > Because if there's a BC break, then all the packages linking to that library > would need to be upgraded, all at the same time. If every library did this, > at > uncontrolled points in their releases, every single bugfix would require > building everything that changed downstream from it and thus downloading it > all and installing. >> That was the starting point here. Not Qt breaking BC by itself, but allowing >> C++ BC breakages to affect otherwise "pure Qt" applications. > Distros did shield from rebuilding after the libstdc++ breakages. But I am > with others now saying that we shouldn't have to go out or our way to do > that. > If libstdc++ does it, it's for a good reason. I see some valid concerns here, but I think in practice, André is right. We are talking about BC breakages that happen because of libstdc++ BC breakages. If distros switch from one libstdc++ to a binary incompatible libstdc++ *between releases*, then it's their own fault they have to rebuild and redeliver everything. And if they don't, then qt libs don't break BC either, so there is no problem in that case. I think it might be wisest to allow BC breakage under the premise that the major version number must change whenever BC is broken. That would tell people loud and clear that they have to rebuild (also the library names are likely to change then, so old versions of a program can't accidentally load the binary incompatible library) -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?
Am 30.01.2017 um 12:23 schrieb Simon, Hausmann: > > > Making a warning go away for compilers that we know support utf-8 may > not come at the price of your life :) > > > I for one am all in favor of requiring just the Qt source code (not > talking about customer code) to be encoded in a 24 year > > old standard and add all the necessary flags to the compilers to make > them understand it instead of producing a warning. > > > We practically support three different front-ends: GCC, clang and > MSVC. All three - MSVC with the help of an option - can > > grok UTF-8. Let's use it at least inside Qt :) > > > Simon > personally, I want - every file in the world converted to UTF8 - every software made compatible to UTF8 - compatibility to any other encoding removed from every software - everyone burned at stake for heresy who says that any other encoding has ever existed -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?
Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo: > Il 30/01/2017 11:35, Viktor Engelmann ha scritto: >> As far as I can see, all our codes *are* UTF-8 encoded (a least they >> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in >> 2017!) instead of just telling the compiler the encoding we are using? > So *all* of our compilers happily support UTF-8 encoded sources? I wouldn't bet my life on that (especially not for windows!) -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?
Am 30.01.2017 um 02:21 schrieb Thiago Macieira: > That's usually one of the problematic ones. > > Not on this file, though: > > qCDebug(lcTuioSet) << "Processing SET for token " << classId << id << " @ > " << x << y << "∡" << angle << > > That's easy to fix by using "\342\210\241" instead. But that's just cheating - the UTF8 is still there, you only hide it... Also, this way the UTF8 codes are hard-coded - if UTF8 is ever deprecated or you want to write non-ASCII to a shell that doesn't support UTF8, you'd have to change all these codes *manually*. As far as I can see, all our codes *are* UTF-8 encoded (a least they should be, IMHO), so why would we sneak our UTF8 in behind it's back (in 2017!) instead of just telling the compiler the encoding we are using? -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?
I have a unit test for webengine that sends an HTTP Post request which includes several unicode characters (outside of ä,ö,ü or other Latin1 characters). I deliberately did that to make the test harder to pass. Am 29.01.2017 um 10:33 schrieb André Pönitz: > On Sun, Jan 29, 2017 at 12:13:48PM +0800, Liang Jian wrote: >> Start from qt-5.8 I can't build qt anymore under Windows(simplified >> chinese locale). Since there is a file >> src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain non-latin-1 >> character, msvc2015 assume the source code's character set should be CP936 >> which make the complilation fail. >> I can only build qt by comment the line which contain the specical >> character in src/plugins/generic/tuiotouch/qtuiohandler.cpp. >> But if I turn on -developer-build in configuration step, thing will get >> worse than before, since -developer-build means treat warning as error, and >> again I can't build qt anymore since there are other files contain >> non-latin1 character (such as qstring.cpp), the build will fail due to the >> character set warning. >> I am working on a Windows 10 x64 simplifed chinese machine, msvc2015 >> update3 >> For more detail please refer to >> https://bugreports.qt.io/browse/QTBUG-58161 >> >> As a workaround, I have to modify the file >> qtbase/mkspecs/common/msvc-desktop.conf >> QMAKE_CFLAGS= -nologo -Zc:wchar_t /utf-8 >> After I add /utf-8 compiler option the build goes well. >> Shall we turn on this compiler option by default? > We should remove non-ASCII characters from the sources if they cause problems. > > If some non-ASCII is unproblematic (like the 'ä' in some copyright lines) > on all supported compilers, that's fine to have, but mining log messages > or comments with characters that are known to cause issues in the processing > are a mindless waste of resources. > > Andre' > > _______ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using semicolons in JS (QML)
Am 30.09.2016 um 17:43 schrieb Shawn Rutledge: > Back in Nokia times it was said that we shouldn't use semicolons, > because it would speed up the parsing [...] As someone who has written countless parsers, I *highly* doubt that this is actually true. Indenting with tabs was also believed to be *much* slower than indenting with spaces (which makes absolutely no sense), and that measurement result turned out to be caused by a bug in firebird. I bet this is also just an urban legend. Someone probably thought "hey - one less character to read - must be faster to load", but as André pointed out, the error recovery will most likely cost more than what you save. Unless if the behavior is baked into the LR(1) state-graph maybe. Also I don't think it is good style to write code that doesn't conform to the actual language, just because *most* parsers correctly *guess* what you meant *most* of the time (except in those pathological cases...). I think that you should *always* tell parsers *precisely* what you mean and don't rely on it's guessing ability. For reference: The Mariner 1 crash (which cost $80 million) was supposedly caused by an error that could have been caught by static analysis at compile time, but was just "guessed away" wrongly. Anyhow, I believe that we have spent more time on this debate than will ever be saved by omitting semicolons. Viktor -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B <http://qt.io> <http://www.facebook.com/Qt><http://www.twitter.com/qtproject> <https://www.linkedin.com/company/the-qt-company/> <https://plus.google.com/104580575722059274792> <https://www.youtube.com/QtStudios> Qt World Summit 2016 <http://qtworldsummit.com/> Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com <http://www.qtworldsummit.com> <>___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
I don't think the joke is racist or sexist. The protagonists happen to be female, but the gender has nothing to do with the punchline (at least I don't think so). I have read the same joke with blond men and with clerks. You could take anyone - and that is what makes the joke in-offensive for anyone (IMO). I find it more excluding and off-putting to be called racist/sexist /*publicly*/ for posting such a harmless joke. If you have any problem, you could come and talk to me personally first, before pointing fingers. Am 06.09.2016 um 16:29 schrieb Ulf Hermann: >> It kind of reminds me of this joke: >> http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ > > Do we have a policy about inappropriate content posted to mailing > lists and similar communication channels? If not, I think we should > agree on banning at least some basic things like racism or sexism. We > should be inclusive after all, and not scare off any potential > contributors. > > regards, > Ulf -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B <http://qt.io> <http://www.facebook.com/Qt><http://www.twitter.com/qtproject> <https://www.linkedin.com/company/the-qt-company/> <https://plus.google.com/104580575722059274792> <https://www.youtube.com/QtStudios> Qt World Summit 2016 <http://qtworldsummit.com/> Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com <http://www.qtworldsummit.com> <>___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using platform-native APIs for terminating QThreads
It is just a (more extreme) example of my point: If the user bypasses our security measures and shoots himself in the foot - why should we take any responsibility for that? Am 06.09.2016 um 01:44 schrieb Thiago Macieira: > Em segunda-feira, 5 de setembro de 2016, às 16:08:41 PDT, Viktor Engelmann > escreveu: >> So what if the user adds an asm statement that changes a register and >> doesn't declare that register to be changed? That would also cause his >> "Qt" application to misbehave... or what if he links the object files to >> a custom loader that doesn't call the constructors for global objects? > If you insert an asm statement that changes a register and you don't inform > GCC that you changed it, then your application is buggy and it deserves to > crash. In fact, you should HOPE it crashes cleanly, before it corrupts any > user data. > > Still, what does that have to do with the problem at hand? > -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B <http://qt.io> <http://www.facebook.com/Qt><http://www.twitter.com/qtproject> <https://www.linkedin.com/company/the-qt-company/> <https://plus.google.com/104580575722059274792> <https://www.youtube.com/QtStudios> Qt World Summit 2016 <http://qtworldsummit.com/> Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com <http://www.qtworldsummit.com> <>___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016
Am 06.09.2016 um 06:52 schrieb Ch'Gans: > On 6 September 2016 at 16:20, Thiago Macieira <thiago.macie...@intel.com> > wrote: >> Which is, in itself, an argument: why learn yet another buildsystem? > ... > > Why learn yet another programming language? > > ... > > An average software developer knows about, says 10 to 20 programming > languages, maybe even more depending on the definition of "language". > Why should he/she knows just one build system? > > Chris My 2 cents: I want to spend my time on programming = being productive - Not waste my time fighting against an incredibly stupid build system... In my opinion, build systems in general haven't matured the way compilers have. Using classes and polymorphism, you can easily explain arbitrarily complex situations to compilers. I have yet to see a build system that understands more complex situations than "FILE1 IS OLDER THAN FILE2". They don't even have the slightest understanding of the commands they execute - they just slap some raw strings together (which YOU have to provide) and pass them to a shell. Oh, these raw strings were for a different OS? Or even just a different version of the same compiler on the same OS? well too bad... It kind of reminds me of this joke: http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ Viktor -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin viktor.engelm...@qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B <http://qt.io> <http://www.facebook.com/Qt><http://www.twitter.com/qtproject> <https://www.linkedin.com/company/the-qt-company/> <https://plus.google.com/104580575722059274792> <https://www.youtube.com/QtStudios> Qt World Summit 2016 <http://qtworldsummit.com/> Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com <http://www.qtworldsummit.com> <>___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using platform-native APIs for terminating QThreads
So what if the user adds an asm statement that changes a register and
doesn't declare that register to be changed? That would also cause his
"Qt" application to misbehave... or what if he links the object files to
a custom loader that doesn't call the constructors for global objects?
We can lock away OUR guns so the user can't shoot himself in the foot
with them, but if he goes out and buys his own gun, there is nothing we
can (or should) do about it.
Just my 2 cents.
Viktor
Am 03.09.2016 um 09:03 schrieb Thiago Macieira:
> Em sexta-feira, 2 de setembro de 2016, às 23:45:26 CEST, Marc Mutz escreveu:
>> On Friday 02 September 2016 22:35:59 Thiago Macieira wrote:
>>> However, the documentation from the ABI says that forced unwinds cannot be
>>> stopped, so you can't swallow the exception even if you wanted to. Are you
>>> sure that the application crashes when you pthread_exit() when
>>> QThreadPrivate::start() is noexcept?
>> Can't swallow doesn't mean can't catch. You can catch it, but you can't not
>> rethrow. But if you call std::terminate(), the rethrow will never be
>> reached.
> But that doesn't do what we want. We want to rethrow the __forced_unwind
> exception so that it terminates the thread, but not the entire application.
>
> But anyway, what I asked didn't work. Test app:
>
> #include
>
> void do_exit() noexcept
> {
> pthread_exit(nullptr);
> }
>
> int dummy;
> void *thread_function(void *)
> {
> do_exit();
> return
> }
>
> int main()
> {
> pthread_t thr;
> void *retval;
> pthread_create(, nullptr, thread_function, nullptr);
> pthread_join(thr, );
> return retval == nullptr ? 0 : 1;
> }
>
> Crash backtrace:
> #0 0x76fa9975 in raise () from /lib64/libc.so.6
> #1 0x76faad8a in abort () from /lib64/libc.so.6
> #2 0x778ca6bd in __gnu_cxx::__verbose_terminate_handler() () from /
> usr/lib64/libstdc++.so.6
> #3 0x778c8696 in ?? () from /usr/lib64/libstdc++.so.6
> #4 0x778c86e1 in std::terminate() () from /usr/lib64/libstdc++.so.6
> #5 0x778c8314 in __gxx_personality_v0 () from /usr/lib64/libstdc+
> +.so.6
> #6 0x773275a9 in ?? () from /lib64/libgcc_s.so.1
> #7 0x77327904 in _Unwind_ForcedUnwind () from /lib64/libgcc_s.so.1
> #8 0x77bcacb0 in __pthread_unwind () from /lib64/libpthread.so.0
> #9 0x77bc3595 in pthread_exit () from /lib64/libpthread.so.0
> #10 0x00400794 in do_exit() ()
> #11 0x004007a5 in thread_function(void*) ()
> #12 0x77bc2474 in start_thread () from /lib64/libpthread.so.0
> #13 0x7705d3ed in clone () from /lib64/libc.so.6
>
> I'll post to cxxabi and ask that __forced_unwind be made public API.
--
Viktor Engelmann
Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
viktor.engelm...@qt.io
+49 151 26784521
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
<http://qt.io>
<http://www.facebook.com/Qt><http://www.twitter.com/qtproject>
<https://www.linkedin.com/company/the-qt-company/>
<https://plus.google.com/104580575722059274792>
<https://www.youtube.com/QtStudios>
Qt World Summit 2016 <http://qtworldsummit.com/>
Qt World Summit 2016 | Pier 27, San Francisco, CA
Experience Exponential Potential on October 18-20
www.qtworldsummit.com <http://www.qtworldsummit.com>
<>___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
