Re: [Interest] Operator QMap[] is casting to int?
Hi all, I'm really sorry I brought this up. I have been working with smaller things thanks size_t. I was wrong in the general case. You can do a data structure of 16gB using the range of signed indexes for doubles. That should plenty. I do still miss the python negative syntax though. [-1] and [-2] in particular. Though I done expect slices to be a thing? Maybe? Eventually? > Sent: Friday, May 10, 2019 at 6:36 PM > From: "Thiago Macieira" > To: interest@qt-project.org > Subject: Re: [Interest] Operator QMap[] is casting to int? > > On Friday, 10 May 2019 04:17:03 PDT Roland Hughes wrote: > > > Data is different. std::byte is unsigned and "unsigned char" is the actual > > > definition of byte. QByteArray should actually get an API to treat its > > > contents as bytes, not just chars. > > > > > > But we weren't talking about data, we were talking about metadata: sizes, > > > indices, offsets. > > > > I was talking about the devices needing the sizes sent in unsigned > > octates. Sorry if there was any confusion. The static casts most often > > occur here. > > Only if we're talking about sizes between 0 to 255. That's what a single > unsigned octet can represent. Doesn't strike me as very useful. > > If you meant transmitting sizes as unsigned values over the network or medium, > that's fine, since negative counts are physically meaningless. The bit pattern > of any size in signed and unsigned is the same, so the choice between them is > irrelevant. You may as well treat the protocol field as signed. > > > > Then you use a 64-bit signed integer for that. That's why Qt uses qint64 > > > for file sizes, regardless of architecture. > [cut] > > Or the size incoming and outgoing is required to be unsigned and it is > > to/from a device where one does not control the firmware. > > Which, just like the above, you can treat as *signed* 64-bit, since your item > count will not likely be more than 9223372036854775807. If it is, then you > should use signed 128-bit, not unsigned 64-bit. > > I understand your argument that the other side may have specified that the > field is unsigned. That's fine. But my argument is that all values between 0 > and 9223372036854775807 have the exact same bit pattern in both signed and > unsigned 64-bit. > > However, I can now think of one particular case where unsigned math may be > useful: dealing with untrusted data (and network definitely is untrusted). > Until you confirm that all values are in the expected range, you should keep > it unsigned. > > > We really really really need those things which cannot be negative to be > > unsigned. I understand there is great resistance to this for reasons > > which make no sense when viewed from the place of one who actually has > > to interface with this stuff. > > No, we do not "really really" need that. > > Just because one field can't be negative does not mean that others can't. Take > the example of a string / vector / bytearray size. As I said above, sizes > cannot meaningfully be negative. But functions like indexOf() take an offset > position that can be negative and the function can return a negative value > indicating that the search failed. Using unsigned for size() is much more > likely to cause you to need casts, for no appreciable gain since you cannot > have more items in that vector or string than the maximum signed value. > > > As a compromise, every container should have a usize() method which > > returns the value as an unsigned datatype. To make things even more > > bullet proof it could be something like > > > > usize( bool * wasNegative = nullptr) > > > > ulength(bool * wasNegative = nullptr) > > Sorry, not convinced. This is as much an ugly band-aid as std::ssize() > function. > > > Then we only have to jump through hoops for things like DICOM. > > > > https://www.dicomstandard.org/faq/ > > > > > > > > Following the (group number, data element number) pair is a length field > > that is a 32 bit unsigned even integer that describes the number of > > bytes from the end of the length field to the beginning of the next data > > element. > > > > > > This is fine, but since you can't operate on this much data on a 32-bit system > without implementing windowed access through the data in your own code, I > don't see as in impediment. You will code your application to deal with a > possible 4 GB distance by seeking in the file -- and remember off_t is signed! > > If you only allow your application on 64-bit systems, then qsizetype can > represent all 32-bit unsigned values without loss of information. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
On Friday, 10 May 2019 13:49:58 PDT Richard Weickelt wrote: > On 10.05.2019 21:13, Thiago Macieira wrote: > > On Thursday, 9 May 2019 16:58:47 PDT Hamish Moffatt wrote: > >> For my use I rebuilt the Qt packages from https://launchpad.net/~beineri > >> for stretch; they install into /opt rather than replacing the system > >> packages, so you don't have the issues with Qt and other > >> reverse-dependencies. I think the Qt project could supply packages along > >> these lines, rather than trying to replace the system Qt. > > > > Why can't you install the binaries published by the Qt Project in /opt? > > You mean https://www.qt.io/offline-installers ? > You may want to try to install them: > - in a headless environment in a script > - to another location than /opt/Qt/xxx > - with only some components included Assuming that the first problem (headless) is solved, I don't see what the problem is with the rest. The installer should be able to install anywhere, since it performs the necessary hex-editing to modify the installation paths in the files it needs to. As for the components, just install all of them. If you don't want something, erase after installation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
On 10.05.2019 21:13, Thiago Macieira wrote: > On Thursday, 9 May 2019 16:58:47 PDT Hamish Moffatt wrote: >> For my use I rebuilt the Qt packages from https://launchpad.net/~beineri >> for stretch; they install into /opt rather than replacing the system >> packages, so you don't have the issues with Qt and other >> reverse-dependencies. I think the Qt project could supply packages along >> these lines, rather than trying to replace the system Qt. > > Why can't you install the binaries published by the Qt Project in /opt? You mean https://www.qt.io/offline-installers ? You may want to try to install them: - in a headless environment in a script - to another location than /opt/Qt/xxx - with only some components included ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
On Thursday, 9 May 2019 16:58:47 PDT Hamish Moffatt wrote: > For my use I rebuilt the Qt packages from https://launchpad.net/~beineri > for stretch; they install into /opt rather than replacing the system > packages, so you don't have the issues with Qt and other > reverse-dependencies. I think the Qt project could supply packages along > these lines, rather than trying to replace the system Qt. Why can't you install the binaries published by the Qt Project in /opt? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
On Thursday, 9 May 2019 16:20:41 PDT Hamish Moffatt wrote: > On 9/5/19 6:04 pm, Shawn Rutledge wrote: > > Of course on Linux there are usually distro packages so it’s already > > easy (as long as you don’t mind them often being a bit outdated: shame > > on distros who still didn’t upgrade to 5.12 yet). And macOS has brew. > > Actually, I'd turn this around and say shame on the Qt project for not > publishing packages, at least for the major distributions. That would be WAY too much work. Even with the help of OBS, it's just too much to take care of, especially when distros already publish packages of their own, according to their rules, on their desired cadence. And there's the one-size-fits-all binary. It's not a package, it's a convenience. And there's source. It's not like you can't build for a distro where the single binary failed, for some reason. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
On Friday, 10 May 2019 04:17:03 PDT Roland Hughes wrote: > > Data is different. std::byte is unsigned and "unsigned char" is the actual > > definition of byte. QByteArray should actually get an API to treat its > > contents as bytes, not just chars. > > > > But we weren't talking about data, we were talking about metadata: sizes, > > indices, offsets. > > I was talking about the devices needing the sizes sent in unsigned > octates. Sorry if there was any confusion. The static casts most often > occur here. Only if we're talking about sizes between 0 to 255. That's what a single unsigned octet can represent. Doesn't strike me as very useful. If you meant transmitting sizes as unsigned values over the network or medium, that's fine, since negative counts are physically meaningless. The bit pattern of any size in signed and unsigned is the same, so the choice between them is irrelevant. You may as well treat the protocol field as signed. > > Then you use a 64-bit signed integer for that. That's why Qt uses qint64 > > for file sizes, regardless of architecture. [cut] > Or the size incoming and outgoing is required to be unsigned and it is > to/from a device where one does not control the firmware. Which, just like the above, you can treat as *signed* 64-bit, since your item count will not likely be more than 9223372036854775807. If it is, then you should use signed 128-bit, not unsigned 64-bit. I understand your argument that the other side may have specified that the field is unsigned. That's fine. But my argument is that all values between 0 and 9223372036854775807 have the exact same bit pattern in both signed and unsigned 64-bit. However, I can now think of one particular case where unsigned math may be useful: dealing with untrusted data (and network definitely is untrusted). Until you confirm that all values are in the expected range, you should keep it unsigned. > We really really really need those things which cannot be negative to be > unsigned. I understand there is great resistance to this for reasons > which make no sense when viewed from the place of one who actually has > to interface with this stuff. No, we do not "really really" need that. Just because one field can't be negative does not mean that others can't. Take the example of a string / vector / bytearray size. As I said above, sizes cannot meaningfully be negative. But functions like indexOf() take an offset position that can be negative and the function can return a negative value indicating that the search failed. Using unsigned for size() is much more likely to cause you to need casts, for no appreciable gain since you cannot have more items in that vector or string than the maximum signed value. > As a compromise, every container should have a usize() method which > returns the value as an unsigned datatype. To make things even more > bullet proof it could be something like > > usize( bool * wasNegative = nullptr) > > ulength(bool * wasNegative = nullptr) Sorry, not convinced. This is as much an ugly band-aid as std::ssize() function. > Then we only have to jump through hoops for things like DICOM. > > https://www.dicomstandard.org/faq/ > > > > Following the (group number, data element number) pair is a length field > that is a 32 bit unsigned even integer that describes the number of > bytes from the end of the length field to the beginning of the next data > element. > > This is fine, but since you can't operate on this much data on a 32-bit system without implementing windowed access through the data in your own code, I don't see as in impediment. You will code your application to deal with a possible 4 GB distance by seeking in the file -- and remember off_t is signed! If you only allow your application on 64-bit systems, then qsizetype can represent all 32-bit unsigned values without loss of information. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
On Fri, May 10, 2019 at 4:07 PM Shawn Rutledge wrote: > So “stable” just means old in practice, and thus uninteresting for > developers. Old AND stable. There are specific criteria the debian project uses to mark a package as stable. Old may not mean stable, but usually stable means old (although not always). > “Guix follows a so-called 'rolling release' model, so you can run guix > pull at any time to get the latest and greatest bits of free software.” Debian does that with the testing flavour. If you want the latest and greatest without making much of a compromise on the stability that's the one. (This is what I use, there are also "unstable" and "experimental"). An argument for both approaches can be made either way, but the fact of the matter is that the testing flavor gets Qt (re)packaged pretty quickly after its release. > But Qt 5.11.3 … ugh. https://www.gnu.org/software/guix/packages/Q/ One > would think if their goal is a rolling release that they probably have > tried to automate building newer stuff and trying to upgrade continuously. That's also the version I have on the debian testing I run. It may be that 5.12 is considered to buggy to (re)package from experimental to unstable to testing, but there may be other (significant) contributing factors. Here's what I get from the repository (some architectures and versions cut): stretch (stable) (libs): Qt 5 core module 5.7.1+dfsg-3+deb9u1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x buster (testing) (libs): Qt 5 core module 5.11.3+dfsg1-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x sid (unstable) (libs): Qt 5 core module 5.11.3+dfsg1-1: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-i386 m68k mips mips64el mipsel powerpcspe ppc64 ppc64el riscv64 s390x sh4 sparc64 x32 experimental (libs): Qt 5 core module 5.12.3+dfsg-1: amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-i386 m68k mips mips64el mipsel powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
> On 10 May 2019, at 01:20, Hamish Moffatt wrote: > > Actually, I'd turn this around and say shame on the Qt project for not > publishing packages, at least for the major distributions. > > It's Debian's policy to publish stable releases which don't change except for > security and other essential updates. There is no argument for updating Qt in > a stable release. So “stable” just means old in practice, and thus uninteresting for developers. Same thing with Ubuntu and Raspbian and others that have been influenced by this belief that older software has fewer bugs by definition, or that known bugs with known workarounds are better than fewer bugs. But Qt 5.12 is LTS, so I think every contemporary LTS distro ought to be using it, because it will still be getting fixes for about as long as the distro is supported. What reminded me again most recently was the announcement that brand-new Gnu GUIX 1.0 was just released a few days ago: https://www.gnu.org/software/guix/blog/2019/gnu-guix-1.0.0-released/ “Guix follows a so-called 'rolling release' model, so you can run guix pull at any time to get the latest and greatest bits of free software.” But Qt 5.11.3 … ugh. https://www.gnu.org/software/guix/packages/Q/ One would think if their goal is a rolling release that they probably have tried to automate building newer stuff and trying to upgrade continuously. (Maybe it will get ramped up soon?) For Arch on the other hand it just doesn’t seem to be a big deal: Qt gets released almost simultaneously with our releases, the applications that depend on it are getting rebuilt pretty often too, and it almost always just works. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
On 5/9/19 3:22 AM, Thiago Macieira wrote: On Tuesday, 7 May 2019 14:25:05 PDT Roland Hughes wrote: If there's ever an STL2 (std2 namespace), it'll use signed. It's not just mixing C++ APIs. It is interfacing with devices which use unsigned octates in groups for the size followed by a contiguous block of octates for the data. When they accept text input it has to be sent this way and when they communicate text responses it comes back this way. Data is different. std::byte is unsigned and "unsigned char" is the actual definition of byte. QByteArray should actually get an API to treat its contents as bytes, not just chars. But we weren't talking about data, we were talking about metadata: sizes, indices, offsets. I was talking about the devices needing the sizes sent in unsigned octates. Sorry if there was any confusion. The static casts most often occur here. There are also the big data blocks like X-RAY/MRI images and such which need to be loaded into larger than signed int containers for manipulation. Then you use a 64-bit signed integer for that. That's why Qt uses qint64 for file sizes, regardless of architecture. I can't think of a single use-case that would require the use of all 64 bits for the number, instead of 63 and leaving one for the sign. And if you really needed to represent numbers over 2^63, it's quite likely you need more than 2^64 soon, so you had better come up with your own BigInt class for storing the information. Quite frankly, the only reason to use 64-bit unsigned is to use the type as a bit pattern storage, such as what QRandomGenerator64::generate() returns. Or the size incoming and outgoing is required to be unsigned and it is to/from a device where one does not control the firmware. Some shops won't or cannot let you use an int. If they are changing from int to q-whatever defined type there will probably be some compilation cleanup anyway so unsigned wouldn't be bad unless someone is cheating somewhere and initializing size to -1 qsizetype is signed and will remain so. We want to transition Qt containers to support more than 2 GB on 64-bit systems, so we want to use qsizetype. What's missing is implementing this and finding all the wrong casts. PS: would you please reply with the correct subject? Sorry about that. I get the list in digest form and have been significantly time restricted. Putting in a lot of effort on current medical device and documenting static casts in a manner which will pass scrutiny during FDA formal review. (Not as simple as it sounds.) I don't know where the "limit" for these is. Thankfully, knock knock knock on wood, I've never had the rejection. Perhaps another here with experience on a project that didn't pass review can shed light on where the threshold lies? We really really really need those things which cannot be negative to be unsigned. I understand there is great resistance to this for reasons which make no sense when viewed from the place of one who actually has to interface with this stuff. As a compromise, every container should have a usize() method which returns the value as an unsigned datatype. To make things even more bullet proof it could be something like usize( bool * wasNegative = nullptr) ulength(bool * wasNegative = nullptr) just in case someone has been playing games with -1 somewhere that would give us the ability to trap. Such a method would remove a mass quantity of static casts in the device code itself thus removing all of the documentation and pain associated with getting such code through the formal review process. Then we only have to jump through hoops for things like DICOM. https://www.dicomstandard.org/faq/ Following the (group number, data element number) pair is a length field that is a 32 bit unsigned even integer that describes the number of bytes from the end of the length field to the beginning of the next data element. -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
