Re: [Development] Bluetooth and NFC vs Reference Platforms
> -Original Message- > From: development-bounces+alexander.blasche=digia@qt-project.org > [mailto:development-bounces+alexander.blasche=digia@qt-project.org] > On Behalf Of Thiago Macieira > However, if there are major defects in the API, they need to be voiced now. > Like Lars said before, this API isn't new, so people have had the time to look > at it. > > If there are major problems, I expect that they are already known. Therefore, > post them. And for the record I am interested in all of those comments and patches. I have no interest in semi-finished things which could cause me headaches either. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
On Monday 30 September 2013 13:09:53 Thiago Macieira wrote: > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote: > > >As far as I know from my colleague, it misses some necessary API -- at > > >least the connection state changes notification and device disappearing > > >notification. > > >We could prepare some patches during the next week or two, though > > >QtBluetooth probably needs few more revisions and API changes/fixes...but > > >we can't do too much in case of API freeze, you know... > > > > A missing feature is for me not enough reason to delay the release of a > > module. There's always more features we could add to a module. It's also > > important to get something out and into the hands of people. > > > > Feature freeze doesn't imply a full API freeze. We have the alpha/beta > > period exactly for finding issues and fixing them. A missing signal is > > something we can fix if required. > > Right. > > However, if there are major defects in the API, they need to be voiced now. > Like Lars said before, this API isn't new, so people have had the time to > look at it. > > If there are major problems, I expect that they are already known. > Therefore, post them. After having worked quite a bit with the Bluetooth API I wouldn't say it has major defects any more. This wasn't the case with NFC last time I worked with. But afaik there were some change lately addressing the things I found troublesome. Br, Michael ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
On Tue, Oct 1, 2013 at 11:23 AM, Michael Zanetti < michael.zane...@canonical.com> wrote: > On Monday 30 September 2013 13:09:53 Thiago Macieira wrote: > > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote: > > > >As far as I know from my colleague, it misses some necessary API -- at > > > >least the connection state changes notification and device > disappearing > > > >notification. > > > >We could prepare some patches during the next week or two, though > > > >QtBluetooth probably needs few more revisions and API > changes/fixes...but > > > >we can't do too much in case of API freeze, you know... > > > > > > A missing feature is for me not enough reason to delay the release of a > > > module. There's always more features we could add to a module. It's > also > > > important to get something out and into the hands of people. > > > > > > Feature freeze doesn't imply a full API freeze. We have the alpha/beta > > > period exactly for finding issues and fixing them. A missing signal is > > > something we can fix if required. > > > > Right. > > > > However, if there are major defects in the API, they need to be voiced > now. > > Like Lars said before, this API isn't new, so people have had the time to > > look at it. > > > > If there are major problems, I expect that they are already known. > > Therefore, post them. > > After having worked quite a bit with the Bluetooth API I wouldn't say it > has > major defects any more. > > How about getting list of Bound ( and known) Devices from QBluetoothLocalDevice ( or from somewhere else) ? Normal use case is that you use device discovery only when you are pairing new device. After that you only ask locally that is there device already paired and directly connect to that one. I did not found any other practical way to do this that implement it using Dbus for "normal" Linux and JNI to Android. Kate > Br, > Michael > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
On Tuesday 01 October 2013 12:25:37 Kate Alhola wrote: > On Tue, Oct 1, 2013 at 11:23 AM, Michael Zanetti < > > michael.zane...@canonical.com> wrote: > > On Monday 30 September 2013 13:09:53 Thiago Macieira wrote: > > > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote: > > > > >As far as I know from my colleague, it misses some necessary API -- > > > > >at > > > > >least the connection state changes notification and device > > > > disappearing > > > > > > >notification. > > > > >We could prepare some patches during the next week or two, though > > > > >QtBluetooth probably needs few more revisions and API > > > > changes/fixes...but > > > > > > >we can't do too much in case of API freeze, you know... > > > > > > > > A missing feature is for me not enough reason to delay the release of > > > > a > > > > module. There's always more features we could add to a module. It's > > > > also > > > > > > important to get something out and into the hands of people. > > > > > > > > Feature freeze doesn't imply a full API freeze. We have the alpha/beta > > > > period exactly for finding issues and fixing them. A missing signal is > > > > something we can fix if required. > > > > > > Right. > > > > > > However, if there are major defects in the API, they need to be voiced > > > > now. > > > > > Like Lars said before, this API isn't new, so people have had the time > > > to > > > look at it. > > > > > > If there are major problems, I expect that they are already known. > > > Therefore, post them. > > > > After having worked quite a bit with the Bluetooth API I wouldn't say it > > has > > major defects any more. > > How about getting list of Bound ( and known) Devices from > QBluetoothLocalDevice ( or from somewhere else) ? > Normal use case is that you use device discovery only when you are pairing > new device. After that > you only ask locally that is there device already paired and directly > connect to that one. > > I did not found any other practical way to do this that implement it using > Dbus for "normal" Linux > and JNI to Android. Shouldn't QBluetoothLocalDevice::allDevices() give that information? Br, Michael > > Kate > > > Br, > > Michael > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
Manual page says that it returns all local devices QBluetoothHostInfo . In bluez it uses listAdapters to query list of local bluetooth Adapters. To get list of remote devices you should use GetProperties to certain localAdapter and then property named Devices. Kate On Tue, Oct 1, 2013 at 1:42 PM, Michael Zanetti wrote: > On Tuesday 01 October 2013 12:25:37 Kate Alhola wrote: >> On Tue, Oct 1, 2013 at 11:23 AM, Michael Zanetti < >> >> michael.zane...@canonical.com> wrote: >> > On Monday 30 September 2013 13:09:53 Thiago Macieira wrote: >> > > On segunda-feira, 30 de setembro de 2013 19:39:53, Knoll Lars wrote: >> > > > >As far as I know from my colleague, it misses some necessary API -- >> > > > >at >> > > > >least the connection state changes notification and device >> > >> > disappearing >> > >> > > > >notification. >> > > > >We could prepare some patches during the next week or two, though >> > > > >QtBluetooth probably needs few more revisions and API >> > >> > changes/fixes...but >> > >> > > > >we can't do too much in case of API freeze, you know... >> > > > >> > > > A missing feature is for me not enough reason to delay the release of >> > > > a >> > > > module. There's always more features we could add to a module. It's >> > >> > also >> > >> > > > important to get something out and into the hands of people. >> > > > >> > > > Feature freeze doesn't imply a full API freeze. We have the alpha/beta >> > > > period exactly for finding issues and fixing them. A missing signal is >> > > > something we can fix if required. >> > > >> > > Right. >> > > >> > > However, if there are major defects in the API, they need to be voiced >> > >> > now. >> > >> > > Like Lars said before, this API isn't new, so people have had the time >> > > to >> > > look at it. >> > > >> > > If there are major problems, I expect that they are already known. >> > > Therefore, post them. >> > >> > After having worked quite a bit with the Bluetooth API I wouldn't say it >> > has >> > major defects any more. >> >> How about getting list of Bound ( and known) Devices from >> QBluetoothLocalDevice ( or from somewhere else) ? >> Normal use case is that you use device discovery only when you are pairing >> new device. After that >> you only ask locally that is there device already paired and directly >> connect to that one. >> >> I did not found any other practical way to do this that implement it using >> Dbus for "normal" Linux >> and JNI to Android. > > Shouldn't QBluetoothLocalDevice::allDevices() give that information? > > Br, > Michael > >> >> Kate >> >> > Br, >> > Michael >> > ___ >> > Development mailing list >> > Development@qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
>From: development-bounces+alexander.blasche=digia@qt-project.org >[mailto:development-bounces+alexander.blasche=digia@qt-project.org] On >Behalf Of Kate Alhola >How about getting list of Bound ( and known) Devices from >QBluetoothLocalDevice ( or from somewhere else) ? >Normal use case is that you use device discovery only when you are pairing new >device. After that >you only ask locally that is there device already paired and directly connect >to that one. >I did not found any other practical way to do this that implement it using >Dbus for "normal" Linux >and JNI to Android. While you can get the pairing status for an arbitrary address you cannot get a list of a connected device. This requires additional API elements but certainly does not invalidate any API for 5.2 - it is a feature request. If you have a patch adding this please submit (to dev branch) . Otherwise please file a Jira item for it. LBNL I have a question. While it is technically possible to do this I am somewhat at a loss for what use case I might need this. That's why it didn't even occur to me to expose those API elements until about 1-2 weeks ago (when somebody else asked for it). At that point it was too late for 5.2. Any help on my use case question? -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QRawFont disabled on QWS/freetype (Qt 4.8)
Hi all, It seems to me this code from qglobal.h is not correct: #if !(defined(Q_WS_WIN) && !defined(Q_WS_WINCE)) \ && !(defined(Q_WS_MAC) && defined(QT_MAC_USE_COCOA)) \ && !(defined(Q_WS_X11) && !defined(QT_NO_FREETYPE)) \ && !(defined(Q_WS_QPA)) # define QT_NO_RAWFONT #endif It enables QRawFont's freetype backend only for X11, however it should also work on any other platform where freetype and fontconfig work, including QWS. Do I miss anything? -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bluetooth and NFC vs Reference Platforms
On Tue, Oct 1, 2013 at 2:54 PM, Blasche Alexander wrote: > >>From: development-bounces+alexander.blasche=digia@qt-project.org >>[mailto:development-bounces+alexander.blasche=digia@qt-project.org] On >>Behalf Of Kate Alhola > >>How about getting list of Bound ( and known) Devices from >>QBluetoothLocalDevice ( or from somewhere else) ? >>Normal use case is that you use device discovery only when you are pairing >>new device. After that >>you only ask locally that is there device already paired and directly connect >>to that one. >>I did not found any other practical way to do this that implement it using >>Dbus for "normal" Linux >>and JNI to Android. > > While you can get the pairing status for an arbitrary address you cannot get > a list of a connected device. This requires additional API elements but > certainly does not invalidate any API for 5.2 - it is a feature request. > > If you have a patch adding this please submit (to dev branch) . Otherwise > please file a Jira item for it. I have a code for Bluez and Android that could be integrated as a patch but currently it is separate just because i wanted my application to be compatible with standard library, least in Linux. I Android Bluetooth needed so many bugfixes that I needed to have own copy patched of library.I found that there is Linux/Bluez code in https://qt.gitorious.org/qt/qtconnectivity but no Android ? > > LBNL I have a question. While it is technically possible to do this I am > somewhat at a loss for what use case I might need this. That's why it didn't > even occur to me to expose those API elements until about 1-2 weeks ago (when > somebody else asked for it). At that point it was too late for 5.2. Any help > on my use case question? Very common use case, your application wants to use device X ( or device some compatible device ). If device is already paired,it could just ask list of known devices and use it. There is no sense that every time some application would like to sue some device, the device should put in discoverable mode application find it. I use it just so that I look is device X paired and if is, I use it. If not, then I ask user to put device discoverable pairing mode and pair it. Next time application find it automatically. Kate > > -- > Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: [graphics] Nov meeting and "2D Lite" scope
-- Forwarded message -- Subject: [graphics] Nov meeting and "2D Lite" scope Date: segunda-feira, 30 de setembro de 2013, 09:47:08 From: Herb Sutter Para: graph...@isocpp.org (updating subject) November meeting: The Seattle-area face-to-face meeting date is not yet set in stone yet but will very likely be on Nov 21-22. I hope to nail that down in the coming two weeks. We will try to include telecon access for those who cannot attend in person. Scope and goals: Note that the statement of goals was refined a bit at Saturday's meeting -- it's still basically the same direction as originally posted but with some refinements such as excluding things like buttons and similar UI elements. The consensus of the group so far is to stick with a "lite" bounded portable subset for the first version. We could name the first targeted TS as "2D Lite" (note emphasis on "lite" -- this is not intended to compete with a full-fledged professional graphics library): (a) immediate mode graphics/text canvas, plus (b) basic keyboard/mouse style input. That's a pretty portable subset that's already widely supported by many C and C++ libraries. We want to be example-driven, and so far people have proposed three specific examples we'd like to see a proposal demonstrate can be written easily and clearly (more examples are welcome): 1. The "Hello world" challenge: Drawing the text "hello world" and dragging it around the canvas. The code should be only slightly longer than a console "hello world" program. 2. The "sort visualizer" challenge: Visualizing a sort algorithm by drawing a bar with length proportional to each element at each stage. This ought to take <20 lines of code (not counting the sort algorithms themselves). 3. The "four-hour" challenge: Some who has never seen the library should be able to build something interesting from scratch in four hours or less. (We have multiple existence proofs including Cinder, OFX, and SFML; see these two 10-minute videos: http://tinyurl.com/m5kd7h4 and http://tinyurl.com/k8eg35m .) Herb > -Original Message- > From: Thiago Macieira [mailto:thi...@macieira.org] > Sent: Monday, September 30, 2013 8:49 AM > To: graph...@isocpp.org > Subject: Re: [graphics] Graphics experts in our midst? > > On segunda-feira, 30 de setembro de 2013 18:13:00, Ville Voutilainen wrote: > > On 29 September 2013 23:37, Herb Sutter > wrote: > > > Yes, the people currently on the list are predominantly that I > > > think, > > > > > > from Cinder, OFX, Nvidia, etc. -- first thing we did is reach out to them. > > > > I have colleagues who have worked on OpenGL(ES) and OpenVG > > implementations and graphics drivers. My employer (Symbio) is a > > Khronos member. > > Thanks Ville. Are those colleagues subscribed to this list? > > The only reason I ask is that I did consult with three graphical experts (one > current and two former contributors to Qt; those two have or are right now > working on GPU architectures) and they expressed qualms about the stated > goals of this group. I'm trying to get them to join and express clearly what > their issues are, maybe even join the November meeting. It might just be a > misunderstanding, though. > > PS: if the November meeting is Nov 9-10 or the days after, I might be able to > convince some of the Qt graphical experts to join too. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel Open Source Technology Center > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > > -- > You received this message because you are subscribed to the Google Groups > "Graphics" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to graphics+unsubscr...@isocpp.org. > To post to this group, send email to graph...@isocpp.org. > Visit this group at http://groups.google.com/a/isocpp.org/group/graphics/. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/graphics/1872240.2SPGCK > JjMu%40tjmaciei-mobl2. -- You received this message because you are subscribed to the Google Groups "Graphics" group. To unsubscribe from this group and stop receiving emails from it, send an email to graphics+unsubscr...@isocpp.org. To post to this group, send email to graph...@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/graphics/. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/graphics/010201cebdfc%24b54f89a0%241fee9ce0%24%40gmail.com. - -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ Development mailing list Development@qt-project.org http://lists.qt-pro
[Development] Disabling exception support in QtCore?
Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Hmm question - certainly worth it for sjlj platforms like 32-bit ios. One thing I'd love to see is the ability to throw exceptions through meta-call invocations (would be useful for qml, which uses exceptions) Simon Fra: Thiago Macieira Sendt: 21:20 tirsdag 1. oktober 2013 Til: development@qt-project.org Emne: [Development] Disabling exception support in QtCore? Since we decided to roll back support for exceptions in our container classes, the only thing that currently needs exception support is the mainloop allowing std::bad_alloc through. Is it worth it? Should we disable exceptions in QtCore? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Thiago wrote: > Since we decided to roll back support for exceptions in our container > classes, > the only thing that currently needs exception support is the mainloop > allowing > std::bad_alloc through. > > Is it worth it? > > Should we disable exceptions in QtCore? > No, and yes. ;-)) I vote "not worth it, I would disable exceptions in QtCore". --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
Yes, signal/slot connections between user code should IMO still be able to pass through exceptions. I am afraid removing that will break code that's out there. Cheers, Lars On 10/1/13 9:31 PM, "Hausmann Simon" wrote: > >Hmm question - certainly worth it for sjlj platforms like 32-bit ios. > > >One thing I'd love to see is the ability to throw exceptions through >meta-call invocations (would be useful for qml, which uses exceptions) > > >Simon > > > >Fra: Thiago Macieira >Sendt: 21:20 tirsdag 1. oktober 2013 >Til: development@qt-project.org >Emne: [Development] Disabling exception support in QtCore? > > > > >Since we decided to roll back support for exceptions in our container >classes, > >the only thing that currently needs exception support is the mainloop >allowing >std::bad_alloc through. > >Is it worth it? > >Should we disable exceptions in QtCore? > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > >___ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Tue, Oct 01, 2013 at 12:20:29PM -0700, Thiago Macieira wrote: > Since we decided to roll back support for exceptions in our container > classes, > the only thing that currently needs exception support is the mainloop > allowing > std::bad_alloc through. > > Is it worth it? Given that hoping that std::bad_alloc is thrown when expected and hoping that there's something that can be done about it when caught are rather futile exercises on common systems, keeping exception support only for that purpose does indeed not appear to be overly reasonable. So I am tempted to say "not worth it". > Should we disable exceptions in QtCore? Perhaps... do we have numbers how much the gain would actually be, say, for code size? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 19:31:05, Hausmann Simon wrote: > Hmm question - certainly worth it for sjlj platforms like 32-bit ios. > > One thing I'd love to see is the ability to throw exceptions through > meta-call invocations (would be useful for qml, which uses exceptions) The rule is: do not let exceptions propagate through Qt code. If you call qt_metacall directly (or, better, the static version), then the code is compiled with exceptions if they were enabled by the user code. In that case, it's safe to throw exceptions (provided that the class of the return type is also exception-safe). If you use the invokeMethod() machinery, it's not thread-safe today and not meant to be. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: > Yes, signal/slot connections between user code should IMO still be able to > pass through exceptions. I am afraid removing that will break code that's > out there. This is already forbidden since 5.0. You can throw from your slots, if you want. If you call them directly, you're responsible for catching the exception. However, it's undefined behaviour if you let the exception go back to QtCore code. The *best* you can hope for is that std::terminate is called. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 22:28:53, André Pönitz wrote: > Perhaps... do we have numbers how much the gain would actually be, say, > for code size? Give me an hour. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: > Since we decided to roll back support for exceptions in our > container classes, the only thing that currently needs exception > support is the mainloop allowing std::bad_alloc through. > > Is it worth it? > > Should we disable exceptions in QtCore? If it allows us to get a backtrace actually showing where the unhandled exception was thrown (instead of saying it was caused by the Qt event loop), I am all for disabling exception support in QtCore. -- Christoph Feck http://kdepepo.wordpress.com/ KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On terça-feira, 1 de outubro de 2013 22:28:53, André Pönitz wrote: > Perhaps... do we have numbers how much the gain would actually be, say, > for code size? All numbers are based on my own QtCore tree, which contains a lot of patches on top of current stable, including protected visibility. I will not test the pristine tree. All builds are in release mode and the libraries have been stripped of debugging symbols (strip --strip-debug --strip-unneeded). The non-standard flags used were: GCC 4.7.2: -march=corei7-avx -std=c++0x -O3 -maccumulate-outgoing-args -flto GCC 4.8:.2 (same) ICC 14.0: -march=corei7-avx -O3 -std=c++0x Clang 3.3: -march=corei7-avx -O3 -std=c++11 Linker flags (all compilers): -Wl,-O1 -Wl,-z,relro -Wl,--as-needed The -O3 flag is enables optimisations that increase code size, which means this is probably skewed. It's highly unlikely that the exceptional codepath increases in size as much as the regular code path, though. Findings: - the .gcc_except_table section disappears - the .eh_frame and .eh_frame_hdr sections remain present, with negligible shrinkage for .eh_frame_hdr (except for ICC) - the size of the .text section shrinks by 5.7% - the size of the read-execute ELF segment reduces by 6.5% (same as reported by the /usr/bin/size tool) - the overall file size also reduces by 6.5%, which is expected since the read- only portion of QtCore is roughly 99% of the file size. (interestingly, the actual .text segment is only 57%) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center except-clang: There are 33 section headers, starting at offset 0x4cc1e0: Section Headers: [Nr] Name Type Addr Off Size ES Flags Lk Inf Al [ 0] NULL 0 0 0 0 [ 1] .dynsym DYNSYM 0238 0238 000210a8 24 A 2 2 8 [ 2] .dynstr STRTAB 000212e0 000212e0 00032a79 0 A 0 0 1 [ 3] .hashHASH 00053d60 00053d60 9830 4 A 1 0 8 [ 4] .gnu.version GNU_versym 0005d590 0005d590 2c0e 2 A 1 0 2 [ 5] .gnu.version_d GNU_verdef 000601a0 000601a0 001c 0 A 2 1 4 [ 6] .gnu.version_r GNU_verneed 000601bc 000601bc 0160 0 A 2 7 4 [ 7] .rela.dynRELA 00060320 00060320 00019470 24 A 1 0 8 [ 8] .rela.pltRELA 00079790 00079790 19f8 24 A 1 10 8 [ 9] .initPROGBITS 0007b188 0007b188 000e 0 AX 0 0 4 [10] .plt PROGBITS 0007b1a0 0007b1a0 1160 16 AX 0 0 16 [11] .textPROGBITS 0007c300 0007c300 002b1a30 0 AX 0 0 16 [12] .finiPROGBITS 0032dd30 0032dd30 0009 0 AX 0 0 4 [13] .gcc_except_tablePROGBITS 0032dd3c 0032dd3c 0003c454 0 A 0 0 4 [14] .rodata PROGBITS 0036a1a0 0036a1a0 00103d63 0 A 0 0 32 [15] .interp PROGBITS 0046df10 0046df10 001c 0 A 0 0 16 [16] .eh_framePROGBITS 0046df30 0046df30 00042dac 0 A 0 0 8 [17] .eh_frame_hdrPROGBITS 004b0cdc 004b0cdc eb04 0 A 0 0 4 [18] .tbssNOBITS 004c17b0 004c07b0 0008 0 WAT0 0 8 [19] .data.rel.ro.local PROGBITS 004c17b0 004c07b0 38f8 0 WA 0 0 16 [20] .jcr PROGBITS 004c50a8 004c40a8 0008 0 WA 0 0 8 [21] .data.rel.ro PROGBITS 004c50b0 004c40b0 6ac8 0 WA 0 0 16 [22] .dynamic DYNAMIC 004cbb78 004cab78 02b0 16 WA 2 0 8 [23] .got PROGBITS 004cbe30 004cae30 01b8 0 WA 0 0 8 [24] .got.plt PROGBITS 004cbfe8 004cafe8 08c0 0 WA 0 0 8 [25] .dataPROGBITS 004cc8b0 004cb8b0 0770 0 WA 0 0 16 [26] .tm_clone_table PROGBITS 004cd020 004cc020 0 WA 0 0 8 [27] .fini_array FINI_ARRAY 004cd020 004cc020 0010 0 WA 0 0 8 [28] .init_array INIT_ARRAY 004cd030 004cc030 0020 0 WA 0 0 8 [29] .bss NOBITS 004cd050 004cc050 18a0 0 WA 0 0 16 [30] .comment PROGBITS 004cc050 002d 1 MS 0 0 1 [31] .note.gnu.gold-version NOTE 004cc080 001c 0 0 0 4 [32] .shstrtabSTRTAB 004cc09c 0141 0 0 0 1 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg A
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck wrote: > On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: > > Since we decided to roll back support for exceptions in our > > container classes, the only thing that currently needs exception > > support is the mainloop allowing std::bad_alloc through. > > > > Is it worth it? > > > > Should we disable exceptions in QtCore? > > If it allows us to get a backtrace actually showing where the > unhandled exception was thrown (instead of saying it was caused by the > Qt event loop), I am all for disabling exception support in QtCore. In order to properly do that, we should remove all try/catch blocks in QtCore and replace with scoped pointers and scoped values. We should let the destructors handle the cleanup. Turning exceptions off may or may not get you the backtrace. It may also get you a std::terminate or a crash. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On Wednesday 02 October 2013 00:41:56 Thiago Macieira wrote: > On quarta-feira, 2 de outubro de 2013 00:04:58, Christoph Feck wrote: > > On Tuesday 01 October 2013 21:20:29 Thiago Macieira wrote: > > > Should we disable exceptions in QtCore? > > > > If it allows us to get a backtrace actually showing where the > > unhandled exception was thrown (instead of saying it was caused > > by the Qt event loop), I am all for disabling exception support > > in QtCore. > > In order to properly do that, we should remove all try/catch blocks > in QtCore and replace with scoped pointers and scoped values. We > should let the destructors handle the cleanup. Sounds "a bit" more work than simply disabling exceptions, so might be something out of scope for 5.x. > Turning exceptions off may or may not get you the backtrace. It may > also get you a std::terminate or a crash. A crash is fine, as long as I see the origin, or are you implying that those crashes would record no backtrace at all? For example, https://bugs.kde.org/show_bug.cgi?id=325360 shows the backtrace of a re-thrown exception, but unless there are reproducible steps, the report is useless, because the trace originates from the event loop. We have hundreds of those reports, and the hope to find a reporter who can follow linked gdb instructions is next to zero. Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 01:03:19, Christoph Feck wrote: > > In order to properly do that, we should remove all try/catch blocks > > in QtCore and replace with scoped pointers and scoped values. We > > should let the destructors handle the cleanup. > > Sounds "a bit" more work than simply disabling exceptions, so might be > something out of scope for 5.x. Not really. It just takes some work to do it. > > Turning exceptions off may or may not get you the backtrace. It may > > also get you a std::terminate or a crash. > > A crash is fine, as long as I see the origin, or are you implying that > those crashes would record no backtrace at all? They may not record anything at all. You may see only ??? in the backtrace. This is *really* undefined behaviour territory. I can't even guess what the ABIs do if they face a frame with no exception information. Also note the discovery of the other email: the frame information is *still* present in the no-exception build. So it's quite likely that the IA-64 C++ ABI would at least manage to unwind the stack. However, after that, QtCore might be totally and utterly useless. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On 2013-10-01 21:20, Thiago Macieira wrote: > Since we decided to roll back support for exceptions in our container classes, > the only thing that currently needs exception support is the mainloop allowing > std::bad_alloc through. > > Is it worth it? > > Should we disable exceptions in QtCore? > As an outside voice, I'd like to point out that the rest of the world is using exceptions and removing whatever exception support there is in QtCore seems like a step in the wrong direction. Regards, Thomas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On 01.10.13 23:23, "Thiago Macieira" wrote: >On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: >> Yes, signal/slot connections between user code should IMO still be able >>to >> pass through exceptions. I am afraid removing that will break code >>that's >> out there. > >This is already forbidden since 5.0. Is there any good reason why we don't support this, as we did in Qt 4? My goal of still compiling Qt Core with exceptions enabled was to allow for exactly this use case. Lars > >You can throw from your slots, if you want. If you call them directly, >you're >responsible for catching the exception. > >However, it's undefined behaviour if you let the exception go back to >QtCore >code. The *best* you can hope for is that std::terminate is called. > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 05:42:24, Knoll Lars wrote: > On 01.10.13 23:23, "Thiago Macieira" wrote: > >On terça-feira, 1 de outubro de 2013 20:00:56, Knoll Lars wrote: > >> Yes, signal/slot connections between user code should IMO still be able > >>to > >> pass through exceptions. I am afraid removing that will break code > >>that's > >> out there. > > > >This is already forbidden since 5.0. > > Is there any good reason why we don't support this, as we did in Qt 4? My > goal of still compiling Qt Core with exceptions enabled was to allow for > exactly this use case. Because we don't test it, so there's no guarantee that it works. In fact, I'd be surprised if it works at all. What's more, our types aren't exception-safe, even the container types. It's entirely unknown what will happen during a stack unwind. Personally, I don't want to maintain that functionality. And then there's the question: is it worth the 7% increase in code size? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling exception support in QtCore?
On quarta-feira, 2 de outubro de 2013 06:57:01, Thomas Sondergaard wrote: > On 2013-10-01 21:20, Thiago Macieira wrote: > > Since we decided to roll back support for exceptions in our container > > classes, the only thing that currently needs exception support is the > > mainloop allowing std::bad_alloc through. > > > > Is it worth it? > > > > Should we disable exceptions in QtCore? > > As an outside voice, I'd like to point out that the rest of the world is > using exceptions and removing whatever exception support there is in > QtCore seems like a step in the wrong direction. That's because they use exceptions in their API. We don't use it in ours. Also, our containers don't support types that throw exceptions. That decision was made three months ago. The question I posed is: given that the only remaining support is in the event loop, that its current working status is unknown, and that it costs us an increase of 7% in size of QtCore, is it worth it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
