> On Wednesday, 6 March 2019 20:16:59 PST Lorn Potter wrote:
> > Compiler isn't broken, emscripten removed x86intrin.h when they
> > removed their faked simd support (preparing for better simd support in
> > the future). We had Q_PROCESSOR_X86 defined to make it compile with
> > their faked simd
On Wednesday, 6 March 2019 20:16:59 PST Lorn Potter wrote:
> Compiler isn't broken, emscripten removed x86intrin.h when they removed
> their faked simd support (preparing for better simd support in the
> future). We had Q_PROCESSOR_X86 defined to make it compile with their
> faked simd support.
On 2/3/19 2:12 am, Thiago Macieira wrote:
On Friday, 1 March 2019 01:52:00 PST Alexander Rössler wrote:
However, for some reason the build fails at:
qsimd_p.h:196:14: fatal error: 'x86intrin.h' file not found
#include
^
Your compiler is broken. You have
On Wednesday, 6 March 2019 08:40:20 PST Jason H wrote:
> you'll need at most parse 5 bytes:
>
> 1A 00752228 # unsigned(7676456)
> 19 1938 # unsigned(6456)
> 18 38 # unsigned(56)
>
> So thanks for the suggestion. I will be implementing it!
Strictly speaking, 9 bytes. You don't want to begin a
On Wednesday, 6 March 2019 08:44:31 PST Jason H wrote:
> > > So the protocol it expects to work with assumes a message-based upper
> > > bound, and of trivial size. This is not good. In light of this, I
> > > would suggest a QCborDataStream class that implements efficient
> > > parsing.
> >
> >
> On Mar 6, 2019, at 2:14 PM, Kai Köhne wrote:
>
> Hi Steve,
>
> I agree with you that the current console.log behavior in Qt WebEngine is
> pretty basic. Anyhow, looking at the code the problem can be traced back to
> v8, Chromium's JavaScript engine:
>
>
Not sure this will help but I was thinking a Progressive Web App was the way to go. Maybe that is relevant to this, maybe not. But they are "installable". I haven't tried but maybe a PWA with WebAssembly is the way to go?
Hello Qt WA devs,
I have noticed that Qt WA needs to load and recompile every time I start
the browse to the location of the application.
On the other hand, the WebAssembly Tanks demo seems to be cached and
doesn't need to reload https://webassembly.org/demo/Tanks/.
I've also found a blog post
> > So the protocol it expects to work with assumes a message-based upper bound,
> > and of trivial size. This is not good. In light of this, I would suggest a
> > QCborDataStream class that implements efficient parsing.
>
> No needed. You simply misunderstood the CoAP spec.
In what way? The
> If you know the size of the payload prior to sending it, you can simply send
> it using CBOR itself. That is, you'll send pairs of unsigned numbers and
> maps.
> And both QCborValue and QCborStreamReader need the entire number to have
> arrived to parse anything: it's always all or nothing.
How would you layout correctly ~10 labels with their TextFields?
Regards
Roman
> Am 01.02.2019 um 12:39 schrieb Federico Ferri :
>
>
>> On 1 February 2019 at 11:14:01, Roman Wüger (roman.wue...@gmx.at) wrote:
>> Hello,
>>
>> i noticed this in every ui file I „design“ in Qt Creator.
>>
>>
On Wednesday, 6 March 2019 07:41:28 PST Jason H wrote:
> So the protocol it expects to work with assumes a message-based upper bound,
> and of trivial size. This is not good. In light of this, I would suggest a
> QCborDataStream class that implements efficient parsing.
No needed. You simply
On Wednesday, 6 March 2019 06:50:28 PST Jason H wrote:
> > - if it's QCborError::EndOfFile, wait for more data
> > - if it's QCborError::NoError, remove "offset" bytes from the beginning
> > of
> >
> >the buffer and process the loaded map
> >
> > - if it's anything else, give up
>
>
Perhaps you are correct, but this is an issue with the deserialization, and
since these objects exist to be transferred (via CoAP, or other means) failing
to include features that support the typical use cases is a failure of the
format. We don't have infinite reads on disk because they are
I think the CBOR is the (de)serialization, the length and CRC or any other
features like that is part of your transport protocol and not the CBOR itself.
You need to transfer the whole data first and then pass it to CBOR
deserialization when all data is received, you could also split with start
> Sent: Tuesday, March 05, 2019 at 11:42 PM
> From: "Thiago Macieira"
> To: interest@qt-project.org
> Subject: Re: [Interest] CBOR Questions
>
> On Tuesday, 5 March 2019 11:09:52 PST Jason H wrote:
> > It seems the simplest, most reliable way to implement complete reads is to
> > serialize the
Hi Steve,
I agree with you that the current console.log behavior in Qt WebEngine is
pretty basic. Anyhow, looking at the code the problem can be traced back to v8,
Chromium's JavaScript engine:
https://bugs.chromium.org/p/v8/issues/detail?id=5579
17 matches
Mail list logo
