Re: [Development] how to include further changes while previous commit is still under review?

> On 18 Jan 2018, at 22:42, Daniel Savi wrote: > > Hello qt devs > > I'm back with another newbie question. I have committed a patch that is still > under review on gerrit. > > Meanwhile, I've got a local and unrelated patch on the same file, that I > would like to

[Development] how to include further changes while previous commit is still under review?

Hello qt devs I'm back with another newbie question. I have committed a patch that is still under review on gerrit. Meanwhile, I've got a local and unrelated patch on the same file, that I would like to commit, too. Now, how would I include this patch into my local git repo and how would

Re: [Development] QtCoap: QNAM-like API or not

On 18 January 2018 at 10:07, Konstantin Tokarev wrote: > > > Heap corruption can be detected with lots of existing tools, e.g. ASAN. It > also won't be left unnoticed until it's too late, unlike memory leaks which > may suddenly pop up when amount of data increases. > >

Re: [Development] QHash

On Thursday, 18 January 2018 06:12:42 PST René J.V. Bertin wrote: > It took me a while to figure out why my QHash map of a const char* to > something else didn't work despite containing the expected key,value > combinations. I understand that the bug was in my code rather than in > QHash, because

Re: [Development] API review request: CBOR Stream reader and writer

On Thursday, 18 January 2018 00:51:18 PST Dominik Holland wrote: > Am 01/18/2018 um 04:22 AM schrieb Thiago Macieira: > > On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: > >> Another idea is to update the network-chat example to use CBOR instead of > >> its plaintext protocol. In

[Development] QUIP 101: Contributing to Qt

Hi all, I just pushed a QUIP that I hope captures some of our philosophy and ideas behind the Qt Project when it comes to contributing to Qt. I didn't discuss it with many people yet, so it may be controversial. I'd like to get feedback of course :)

Re: [Development] QHash

> On 18 Jan 2018, at 15:12, René J.V. Bertin wrote: > > Hi, > > It took me a while to figure out why my QHash map of a const char* to > something else didn't work despite containing the expected key,value > combinations. I understand that the bug was in my code rather

Re: [Development] QHash

18.01.2018, 17:13, "René J.V. Bertin" : > Hi, > > It took me a while to figure out why my QHash map of a const char* to > something else didn't work despite containing the expected key,value > combinations. I understand that the bug was in my code rather than in QHash, >

[Development] QHash

Hi, It took me a while to figure out why my QHash map of a const char* to something else didn't work despite containing the expected key,value combinations. I understand that the bug was in my code rather than in QHash, because the class is not designed to work with basic data types. It could

Re: [Development] QtCoap: QNAM-like API or not

18.01.2018, 12:58, "Adrien LERAVAT" : >>  From: Konstantin Tokarev [mailto:annu...@yandex.ru] >>  Sent: Thursday, January 18, 2018 10:42 AM >> >>>   The API sounds interesting, but it's a departure of what we are used in >>> QNAM. >>>   What happened to the idea of using a

Re: [Development] QtCoap: QNAM-like API or not

> From: Konstantin Tokarev [mailto:annu...@yandex.ru] > Sent: Thursday, January 18, 2018 10:42 AM > >> The API sounds interesting, but it's a departure of what we are used in >> QNAM. >> What happened to the idea of using a setter on the manager, for making the >> replies self-delete if

Re: [Development] Nominating Joni Poikelin for Approver status

+1 from me. -Miikka From: Development [mailto:development-bounces+miikka.heikkinen=qt...@qt-project.org] On Behalf Of Andy Shaw Sent: maanantai 15. tammikuuta 2018 12.10 To: development@qt-project.org Subject: [Development] Nominating Joni Poikelin for Approver status Hi, I would like to

Re: [Development] QtCoap: QNAM-like API or not

14.01.2018, 20:50, "Adrien LERAVAT" : > Hi all, > > Before feature freeze, we wanted to challenge the current API for the CoAP > module. > > It is currently similar to QNAM APIs: > > \code > > QCoapClient client; > > QCoapReply *reply = client.get(QUrl("1.2.3.4:5683")); >

Re: [Development] QtCoap: QNAM-like API or not

18.01.2018, 12:35, "Adrien LERAVAT" : > On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote: >>  > In that case, the QCoapReply life is managed with a >>  > QSharedPointer in the request. >>  > >>  > QCoapRequest does not inherit from QObject. Anyone sees a problem with

Re: [Development] QtCoap: QNAM-like API or not

On Sunday 14 January 2018 17:49:48 Adrien LERAVAT wrote: > > In that case, the QCoapReply life is managed with a > > QSharedPointer in the request. > > > > QCoapRequest does not inherit from QObject. Anyone sees a problem with > > this approach? > The API sounds interesting, but it's a

Re: [Development] API review request: CBOR Stream reader and writer

Am 01/18/2018 um 04:22 AM schrieb Thiago Macieira: > On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: >> Another idea is to update the network-chat example to use CBOR instead of >> its plaintext protocol. In this one, I could use the stream reader and >> writer. This example is