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

2018-01-18 Thread Samuel Gaist 

> 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 commit, too.
> 
> Now, how would I include this patch into my local git repo and how would I 
> commit it as a separate patch to the first?
> 
> How could I still work on the first patch, once more comments are coming in?
> 
> Would I create separate branches?
> 
> Sorry for my very basic level of git-foo.
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

Since the patch is unrelated, use a different topic branch for that one and 
submit it like the other one.

Depending on the impact of your change, you might want to look at 
https://git-scm.com/docs/git-worktree and have a separate build for it.

Cheers

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread Daniel Savi 

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 
I commit it as a separate patch to the first?


How could I still work on the first patch, once more comments are coming in?

Would I create separate branches?

Sorry for my very basic level of git-foo.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread Richard Moore 
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.
>
> Debugging out of memory conditions may be much harder.
>

​I suggested adding detection of QNetworkReplies that weren't delete after
a short time period (a few seconds perhaps) as an idea for gammaray to help
with this issue.

Cheers

Rich.
​
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QHash

2018-01-18 Thread Thiago Macieira 
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 the class is not designed to work with basic data types.

It works with basic data types just fine. It just doesn't decode raw pointers 
and compare pointed contents, like you expected.

-- 
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] API review request: CBOR Stream reader and writer

2018-01-18 Thread Thiago Macieira 
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 this one, I could use the stream reader and
> >> writer. This example is a perfect candidate to have a CoAP version in the
> >> future too.
> > 
> > I've done this then:
> > https://codereview.qt-project.org/217078
> > https://codereview.qt-project.org/217079
> 
> Why not keep the existing example and do a network-chat-cbor example
> which is more advanced ?

I can do that if people think it would be better. I hadn't thought of it, so I 
just modified the example.

> In the example you could also explain why someone wants to use CBOR.

The difference in the state machine for receiving incomplete data should be 
enough of a reason. Plus the fact that it no longer needs to parse strings for 
numbers.

-- 
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] QUIP 101: Contributing to Qt

2018-01-18 Thread Frederik Gladhorn 
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 :)

https://codereview.qt-project.org/#/c/217216/

Cheers,
Frederik

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QHash

2018-01-18 Thread Lars Knoll 


> 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 than in QHash, 
> because the class is not designed to work with basic data types.

It does work with basic data types. It just did something else than you maybe 
expected (hashing on the value of the char * pointer, not on the string behind 
it).
> 
> It could help though if a compiler error were raised in this kind of 
> situation, would that be possible?

No, because hashing on pointer values is a completely valid use case.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QHash

2018-01-18 Thread Konstantin Tokarev 


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, 
> because the class is not designed to work with basic data types.
>
> It could help though if a compiler error were raised in this kind of 
> situation, would that be possible?

Using pointer as key type is a valid, though may be not frequent, use case. All 
std containers behave the same way.

>
> thanks,
> R.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QHash

2018-01-18 Thread 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, because the class 
is not designed to work with basic data types.

It could help though if a compiler error were raised in this kind of situation, 
would that be possible?

thanks,
R.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread Konstantin Tokarev 


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 setter on the manager, for making 
>>> the replies self-delete if wanted? (it was mentioned on the > QtCS) That 
>>> had the advantage that can be added to QNAM as well, so both can end up 
>>> having a similar API.
>>>
>>>  Well it can surely solve the "forgot to delete reply" case, but as a 
>>> developer, if you're not aware of the change (not the one calling the 
>>> setter), the new behavior change will be far from obvious. Going from 
>>> "pseudo memory leak" to "dangling pointers & crashes" if they are not 
>>> careful enough.
>>
>>  On small device crashes are more favorable outcome than "pseudo" memory 
>> leaks, because the latter lead to delayed crashes and therefore are much 
>> harder to fix.
>
> Well if not tested, it might just as well corrupt part of the heap with no 
> further notice, so I'm not sure it is much better.

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.

Debugging out of memory conditions may be much harder.

> But the question probably boils down: should we keep QNAM API or not for 
> QtCoAP?
>
>>>  So it has the advantage to be applicable to QNAM, but doesn't really feel 
>>> like a user-proof solution to me.
>>>
>>>  Still it can be easily applied to QCoapClient, so if there is a consensus 
>>> around it, we can go that way.
>
> Adrien Leravat
> Software architect, Witekio
> http://witekio.com

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread 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 setter on the manager, for making the 
>> replies self-delete if wanted? (it was mentioned on the > QtCS) That had the 
>> advantage that can be added to QNAM as well, so both can end up having a 
>> similar API.
>>
>> Well it can surely solve the "forgot to delete reply" case, but as a 
>> developer, if you're not aware of the change (not the one calling the 
>> setter), the new behavior change will be far from obvious. Going from 
>> "pseudo memory leak" to "dangling pointers & crashes" if they are not 
>> careful enough.
>
> On small device crashes are more favorable outcome than "pseudo" memory 
> leaks, because the latter lead to delayed crashes and therefore are much 
> harder to fix.

Well if not tested, it might just as well corrupt part of the heap with no 
further notice, so I'm not sure it is much better.
But the question probably boils down: should we keep QNAM API or not for 
QtCoAP? 

>> So it has the advantage to be applicable to QNAM, but doesn't really feel 
>> like a user-proof solution to me.
>>
>> Still it can be easily applied to QCoapClient, so if there is a consensus 
>> around it, we can go that way.

Adrien Leravat
Software architect, Witekio
http://witekio.com


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Joni Poikelin for Approver status

2018-01-18 Thread Miikka Heikkinen 
+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 nominate Joni Poikelin for Approver status. He joined The Qt 
Company over 3 years ago and has consistently contributed to Qt across many 
modules, fixing a number of issues here and there. His Gerrit dashboard is here:

https://codereview.qt-project.org/#/q/owner:%22Joni+Poikelin+%253Cjoni.poikelin%2540qt.io%253E%22+status:merged,n,z

Disclaimer: We both work in the same team (support) inside The Qt Company.

Andy


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread Konstantin Tokarev 


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"));
>
> connect(reply, ::finished, this, ::onFinished);
>
> ...
>
> MyClass::onFinished(QCoapReply* reply)
>
> {
>
>     qWarning() << reply->readAll();
>
>     reply->deleteLater();
>
> }
>
> \endcode
>
> With the clear drawback of explicit memory management needed by users. We made
>
> some tests with a container/RAII object for the reply, and it seems fine, but 
> before
>
> moving forward in this limited timeframe, we wanted to have your feedback.
>
> Sample below:
>
> \code
>
> QCoapClient client;
>
> QCoapRequest request = client.get(QUrl("1.2.3.4:5683"));
>
> connect(request.reply(), ::finished, this, ::onFinished);
>
> ...
>
> MyClass::onFinished(const QCoapRequest )
>
> {
>
>     qWarning() << request.reply()->readAll();
>
> }
> \endcode
>
> 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?

I dislike idea of using external reference counting, making it 
QExplicitlySharedDataPointer would be better

>
> As it wasn't merged to master yet, you can access the repo from its current 
> submission:
>
> https://codereview.qt-project.org/#/c/201311/
>
> Thanks,
>
> Adrien Leravat
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread Konstantin Tokarev 


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
>>  > this approach?
>
>>  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 wanted? (it was mentioned on the > QtCS) That had the 
>> advantage that can be added to QNAM as well, so both can end up having a 
>> similar API.
>
> Well it can surely solve the "forgot to delete reply" case, but as a 
> developer, if you're not aware of the change (not the one calling the 
> setter), the new behavior change will be far from obvious. Going from "pseudo 
> memory leak" to "dangling pointers & crashes" if they are not careful enough.

On small device crashes are more favorable outcome than "pseudo" memory leaks, 
because the latter lead to delayed crashes and therefore are much harder to fix.

> So it has the advantage to be applicable to QNAM, but doesn't really feel 
> like a user-proof solution to me.
>
> Still it can be easily applied to QCoapClient, so if there is a consensus 
> around it, we can go that way.
>
> Adrien Leravat
> Software architect, Witekio
> http://witekio.com
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread 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 
> > this approach?

> 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 wanted? (it was mentioned on the > QtCS) That had the 
> advantage that can be added to QNAM as well, so both can end up having a 
> similar API.

Well it can surely solve the "forgot to delete reply" case, but as a developer, 
if you're not aware of the change (not the one calling the setter), the new 
behavior change will be far from obvious. Going from "pseudo memory leak" to 
"dangling pointers & crashes" if they are not careful enough. So it has the 
advantage to be applicable to QNAM, but doesn't really feel like a user-proof 
solution to me.

Still it can be easily applied to QCoapClient, so if there is a consensus 
around it, we can go that way. 

Adrien Leravat
Software architect, Witekio
http://witekio.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2018-01-18 Thread Dominik Holland 
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 a perfect candidate to have a CoAP version in the
>> future too.
> I've done this then:
> https://codereview.qt-project.org/217078
> https://codereview.qt-project.org/217079
>

Why not keep the existing example and do a network-chat-cbor example
which is more advanced ?

In the example you could also explain why someone wants to use CBOR.

Dominik
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development