Re: [Development] NSURLConnection backend in 5.6.2

[Jake Petroules]

> On Sep 13, 2016, at 1:15 PM, Thiago Macieira  
> wrote:
> 
> On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote:
>> On Sep 13, 2016, at 12:55 PM, Thiago Macieira
>> > wrote:
> 
>> On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote:
>> I'd be blown away if they did and I can't see how there would be a
>> dependency. Also using deprecated APIs is a bad idea for app store
>> compliance. I believe there have been rejections for that in the past.
>> 
>> But did it work on macOS too? Or was it exclusively for the Apple embedded
>> platforms?
>> 
>> NSURLConnection was only ever used on iOS, not any of the other platforms.
> 
> Ok, then that's less of a problem. If it could only be used on a platform 
> where no one will ever want to use it again, we can reasonably conclude no 
> one 
> will be using it.

Testing again that quoting is fixed?

> 
>> PS: can you configure your mail client to quote text properly in the
>> plain-text format?
>> 
>> Tell me how to do that in Apple Mail and I'm happy to. I think I heard a
>> couple complaints after upgrading to Apple Mail 10 (Sierra). There's a
>> checkbox under responding, "Use the same message format as the original
>> message", maybe that will help.
> 
> I don't know how. Check with other Mac users. This is not a new thing, you've 
> been doing it for months or more.
> 
> If you can't configure your MUA to quote properly for a mailing list, don't 
> use 
> it for mailing lists.
> 
> 
> -- 
> 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

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] NSURLConnection backend in 5.6.2

[Jake Petroules]

On Sep 13, 2016, at 1:15 PM, Thiago Macieira 
> wrote:

On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote:
On Sep 13, 2016, at 12:55 PM, Thiago Macieira
>
 wrote:

On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote:
I'd be blown away if they did and I can't see how there would be a
dependency. Also using deprecated APIs is a bad idea for app store
compliance. I believe there have been rejections for that in the past.

But did it work on macOS too? Or was it exclusively for the Apple embedded
platforms?

NSURLConnection was only ever used on iOS, not any of the other platforms.

Ok, then that's less of a problem. If it could only be used on a platform
where no one will ever want to use it again, we can reasonably conclude no one
will be using it.

PS: can you configure your mail client to quote text properly in the
plain-text format?

Tell me how to do that in Apple Mail and I'm happy to. I think I heard a
couple complaints after upgrading to Apple Mail 10 (Sierra). There's a
checkbox under responding, "Use the same message format as the original
message", maybe that will help.

I don't know how. Check with other Mac users. This is not a new thing, you've
been doing it for months or more.

Testing that quoting hopefully works properly.


If you can't configure your MUA to quote properly for a mailing list, don't use
it for mailing lists.


--
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

--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

Stephen Kelly wrote:

>> There is no input file. There is only an input number. The task is from
>> Bo, who gave it as a simplified example.
> Oops, I'm wrong here. Bo said to read the number from a file.
> I don't think that changes anything though regarding dynamic build graph 
> being an advantage.

Sure? What about the (lack of) need for two rules to agree in advance about the 
location of a generated file? Also, there could be several layers of 
indirection, with the second set of generated files also containing meta data 
etc.


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

Re: [Development] NSURLConnection backend in 5.6.2

[Thiago Macieira]

On terça-feira, 13 de setembro de 2016 20:01:10 PDT Jake Petroules wrote:
> On Sep 13, 2016, at 12:55 PM, Thiago Macieira
> > wrote:
 
> On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote:
> I'd be blown away if they did and I can't see how there would be a
> dependency. Also using deprecated APIs is a bad idea for app store
> compliance. I believe there have been rejections for that in the past.
> 
> But did it work on macOS too? Or was it exclusively for the Apple embedded
> platforms?
> 
> NSURLConnection was only ever used on iOS, not any of the other platforms.

Ok, then that's less of a problem. If it could only be used on a platform 
where no one will ever want to use it again, we can reasonably conclude no one 
will be using it.

> PS: can you configure your mail client to quote text properly in the
> plain-text format?
> 
> Tell me how to do that in Apple Mail and I'm happy to. I think I heard a
> couple complaints after upgrading to Apple Mail 10 (Sierra). There's a
> checkbox under responding, "Use the same message format as the original
> message", maybe that will help.

I don't know how. Check with other Mac users. This is not a new thing, you've 
been doing it for months or more.

If you can't configure your MUA to quote properly for a mailing list, don't use 
it for mailing lists.


-- 
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly]

Stephen Kelly wrote:

> Christian Kandeler wrote:
> 
>> [Sorry about the formatting, using outlook]
>> 
>> Stephen Kelly wrote:
>>> Here's the CMake version:
>> 
>> [ ... ]
>> 
>>>  execute_process(
>>>   COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
>>> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
>>>   OUTPUT_VARIABLE fileList
>>> )
>> 
>> How do you know where the input file is located?
> 
> There is no input file. There is only an input number. The task is from
> Bo, who gave it as a simplified example.

Oops, I'm wrong here. Bo said to read the number from a file.

I don't think that changes anything though regarding dynamic build graph 
being an advantage.

Thanks,

Steve.


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

Re: [Development] NSURLConnection backend in 5.6.2

[Jake Petroules]

On Sep 13, 2016, at 12:55 PM, Thiago Macieira 
> wrote:

On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote:
I'd be blown away if they did and I can't see how there would be a
dependency. Also using deprecated APIs is a bad idea for app store
compliance. I believe there have been rejections for that in the past.

But did it work on macOS too? Or was it exclusively for the Apple embedded
platforms?

NSURLConnection was only ever used on iOS, not any of the other platforms.


PS: can you configure your mail client to quote text properly in the plain-text
format?

Tell me how to do that in Apple Mail and I'm happy to. I think I heard a couple 
complaints after upgrading to Apple Mail 10 (Sierra). There's a checkbox under 
responding, "Use the same message format as the original message", maybe that 
will help.


--
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

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly]

Konstantin Tokarev wrote:

>> -Qbs has great features that you can't find in other build systems (e.g.
>> it can build multiple ABIs/platforms at once).
> 
> For the record, premake can do it as well.

Can you show me the syntax for this with premake (and with Qbs)? I assume 
you're talking about building a tool on the host, then using it to generate 
sources, then cross compiling those sources, and having all of that in one 
build. My internet searches do not reveal anything about premakes ability 
here.

Thanks,

Steve.


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

Re: [Development] NSURLConnection backend in 5.6.2

[Thiago Macieira]

On terça-feira, 13 de setembro de 2016 19:44:35 PDT Jake Petroules wrote:
> I'd be blown away if they did and I can't see how there would be a
> dependency. Also using deprecated APIs is a bad idea for app store
> compliance. I believe there have been rejections for that in the past.

But did it work on macOS too? Or was it exclusively for the Apple embedded 
platforms?

PS: can you configure your mail client to quote text properly in the plain-text 
format?

-- 
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] Notes on "Qt Build Systems" @ QtCon 2016

[Stephen Kelly]

Christian Kandeler wrote:

> [Sorry about the formatting, using outlook]
> 
> Stephen Kelly wrote:
>> Here's the CMake version:
> 
> [ ... ]
> 
>>  execute_process(
>>   COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
>> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
>>   OUTPUT_VARIABLE fileList
>> )
> 
> How do you know where the input file is located?

There is no input file. There is only an input number. The task is from Bo, 
who gave it as a simplified example.
 
>> However, it is cheating in the same way that the QBS version from
>> Christian is cheating - it assumes '--list' exists:
> 
> Yes, I was assuming a cooperating tool.

In his real-world example, Bo said that there was a tool which generated 
output files, but the output files are not a-priori known: 

 https://www.mail-archive.com/development@qt-project.org/msg25970.html

Of course, if you have a 'cooperating tool' you can do anything with CMake 
too. My understanding is that because Qbs has a dynamic build graph, it can 
do things that CMake can't do. 

I'm looking for a good example of that so that I can understand. It is the 
gap that Qbs is to fill. Jake mentioned examples to show the difference 
between the Rolls-Royce Trent 900 jet engine that is Qbs, and the wet 
firecrackers that are CMake and qmake. I thought this would be a good one, 
but it turns out that in this case, Qbs and CMake have the same requirement 
of the tool.

>> Christian, can you create a version which does not require --list?
> 
> There are two possibilities:
> a) The inner workings of the tool are known and "simple enough". That's
> the case in Bo's example, so there we could just open the input file and
> derive the output artifacts from the number we find there. 

Yes, if we can find out "now" what the tool will generate "later", then 
everything is easy. 

If we require that of the tool, then we can have a static build graph, so I 
don't see how the dynamic build graph is an advantage in that case.

In the case Bo mentioned, he built the tool, so he can ensure it is 
cooperative. It seems his mistake and the source of his problem was to use 
qmake for the job instead of CMake or Qbs :).

> b) Otherwise,
> our outputArtifacts script has to run the tool in "real mode" (using the
> "--generate" option).

And how do you know what the outputArtifacts are? Do you require the tool to 
tell you what files it generated during this step? (ie, again be 
cooperative)

> The actual command would be a no-op then. This is
> icky, both conceptually and for practical reasons, because commands of
> non-competing rules are run in parallel, whereas the outputArtifacts
> scripts are not.

Right, assuming the tool is still 'cooperative' and tells you what files it 
generated, you would end up with the same thing with a CMake build - you 
would generate the files at CMake time, and then ninja would build them in 
parallel.

Again, that's no conceptual advantage of the dynamic build graph over the 
static one in the case of a somewhat cooperative tool. That's probably why 
Milian never saw a need for such a thing :).

So, I'm still trying to find out when the dynamic build graph is actually an 
advantage. I have an idea in mind, but it gets quite niche and still has 
some assumptions. Maybe you can tell me if I am right:

1) You have an 'uncooperative' tool which can not tell you what it will 
generate, and which does not output a list of what it generated. However, it 
accepts a command line argument specifying where it should generate its 
files.

2) So, you set it up to generate the files in some directory. You assume 
that the directory is empty before the tool is run, and you use the 
equivalent of running the 'ls' command to determine what the files are. 
Rules to run moc and to run the compiler are then added to your dynamic 
build graph, which then proceeds and eventually gets around to executing 
those rules.



If that is something Qbs is designed to do, then can you post a Qbs file 
which does it? You can use the generator.py I posted before. The script 
already accepts a directory to generate the files into - just pretend --list 
doesn't exist.

Thanks,

Steve.


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

Re: [Development] NSURLConnection backend in 5.6.2

[Jake Petroules]

On Sep 13, 2016, at 12:32 PM, Thiago Macieira 
> wrote:

On terça-feira, 13 de setembro de 2016 18:41:50 PDT Jake Petroules wrote:
They can and have before. Anyways, it doesn't matter. The code was unused,
untested, and was in the way of other things, so its removal is
inconsequential.

Also it caused build failure on tvOS/watchOS.

Are we sure none of our users depended on it?

I'd be blown away if they did and I can't see how there would be a dependency. 
Also using deprecated APIs is a bad idea for app store compliance. I believe 
there have been rejections for that in the past.


--
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

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Jake Petroules]

On Sep 13, 2016, at 12:10 PM, Christian Kandeler 
> wrote:

[Sorry about the formatting, using outlook]

Stephen Kelly wrote:
> Here's the CMake version:

[ ... ]

>  execute_process(
>   COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
>   OUTPUT_VARIABLE fileList
> )

How do you know where the input file is located?

> However, it is cheating in the same way that the QBS version from
> Christian is cheating - it assumes '--list' exists:

Yes, I was assuming a cooperating tool.

> Christian, can you create a version which does not require --list?

There are two possibilities:
a) The inner workings of the tool are known and "simple enough". That's the 
case in Bo's example, so there we could just open the input file and derive the 
output artifacts from the number we find there.
b) Otherwise, our outputArtifacts script has to run the tool in "real mode" 
(using the "--generate" option). The actual command would be a no-op then. This 
is icky, both conceptually and for practical reasons, because commands of 
non-competing rules are run in parallel, whereas the outputArtifacts scripts 
are not. I think so far we only use this approach for the infamous qdoc tool.

And asset catalogs, XIBs/NIBs/storyboards, Java sources, and TypeScript sources.



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

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

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

Re: [Development] NSURLConnection backend in 5.6.2

[Thiago Macieira]

On terça-feira, 13 de setembro de 2016 18:41:50 PDT Jake Petroules wrote:
> They can and have before. Anyways, it doesn't matter. The code was unused,
> untested, and was in the way of other things, so its removal is
> inconsequential.
> 
> Also it caused build failure on tvOS/watchOS.

Are we sure none of our users depended on it?

-- 
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] Notes on "Qt Build Systems" @ QtCon 2016

[Christian Kandeler]

[Sorry about the formatting, using outlook]

Stephen Kelly wrote:
> Here's the CMake version:

[ ... ]

>  execute_process(
>   COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list
> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5
>   OUTPUT_VARIABLE fileList
> )

How do you know where the input file is located?

> However, it is cheating in the same way that the QBS version from
> Christian is cheating - it assumes '--list' exists:

Yes, I was assuming a cooperating tool.

> Christian, can you create a version which does not require --list?

There are two possibilities:
a) The inner workings of the tool are known and "simple enough". That's the 
case in Bo's example, so there we could just open the input file and derive the 
output artifacts from the number we find there.
b) Otherwise, our outputArtifacts script has to run the tool in "real mode" 
(using the "--generate" option). The actual command would be a no-op then. This 
is icky, both conceptually and for practical reasons, because commands of 
non-competing rules are run in parallel, whereas the outputArtifacts scripts 
are not. I think so far we only use this approach for the infamous qdoc tool.


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

Re: [Development] NSURLConnection backend in 5.6.2

[Jake Petroules]

On Sep 13, 2016, at 11:40 AM, Konstantin Tokarev 
> wrote:



13.09.2016, 21:33, "Jake Petroules" 
>:
 Because the APIs are deprecated by Apple so they would have had to be 
removed/changed soon anyways, especially when an alternative (which is the 
default now) is already available.

AFAIK they cannot remove API from released SDK, and users may choose to use it 
even if it's not latest and greatest anymore.

They can and have before. Anyways, it doesn't matter. The code was unused, 
untested, and was in the way of other things, so its removal is inconsequential.

Also it caused build failure on tvOS/watchOS.

 On Sep 13, 2016, at 11:25 AM, Thiago Macieira 
> wrote:

 The changelog contains this entry:

 - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
   been removed, since SecureTransport is the default SSL backend on iOS
   and is enabled by default. This means that building with -no-openssl
   -no-securetransport will no longer provide SSL capabilities on iOS.

 WTH? Why are we removing options in a patch release? What happened?

 Is the backend so severely broken that it needed to be removed?
 --
 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

 --
 Jake Petroules - jake.petrou...@qt.io
 Consulting Services Engineer - The Qt Company
 Qbs build tool evangelist - qbs.io
 ,

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



--
Regards,
Konstantin

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

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

Re: [Development] NSURLConnection backend in 5.6.2

[Konstantin Tokarev]

13.09.2016, 21:33, "Jake Petroules" :
>  Because the APIs are deprecated by Apple so they would have had to be 
> removed/changed soon anyways, especially when an alternative (which is the 
> default now) is already available.

AFAIK they cannot remove API from released SDK, and users may choose to use it 
even if it's not latest and greatest anymore.

> Also it caused build failure on tvOS/watchOS.
>
>>  On Sep 13, 2016, at 11:25 AM, Thiago Macieira  
>> wrote:
>>
>>  The changelog contains this entry:
>>
>>  - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
>>    been removed, since SecureTransport is the default SSL backend on iOS
>>    and is enabled by default. This means that building with -no-openssl
>>    -no-securetransport will no longer provide SSL capabilities on iOS.
>>
>>  WTH? Why are we removing options in a patch release? What happened?
>>
>>  Is the backend so severely broken that it needed to be removed?
>>  --
>>  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
>
>  --
>  Jake Petroules - jake.petrou...@qt.io
>  Consulting Services Engineer - The Qt Company
>  Qbs build tool evangelist - qbs.io
>  ,
>
>  ___
>  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] NSURLConnection backend in 5.6.2

[Jake Petroules]

Because the APIs are deprecated by Apple so they would have had to be 
removed/changed soon anyways, especially when an alternative (which is the 
default now) is already available. Also it caused build failure on tvOS/watchOS.

On Sep 13, 2016, at 11:25 AM, Thiago Macieira 
> wrote:

The changelog contains this entry:

- [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
  been removed, since SecureTransport is the default SSL backend on iOS
  and is enabled by default. This means that building with -no-openssl
  -no-securetransport will no longer provide SSL capabilities on iOS.

WTH? Why are we removing options in a patch release? What happened?

Is the backend so severely broken that it needed to be removed?
--
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

--
Jake Petroules - jake.petrou...@qt.io
Consulting Services Engineer - The Qt Company
Qbs build tool evangelist - qbs.io

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

[Development] NSURLConnection backend in 5.6.2

[Thiago Macieira]

The changelog contains this entry:

 - [QTBUG-45031] The NSURLConnection backend of QNetworkAccessManager has
   been removed, since SecureTransport is the default SSL backend on iOS
   and is enabled by default. This means that building with -no-openssl
   -no-securetransport will no longer provide SSL capabilities on iOS.

WTH? Why are we removing options in a patch release? What happened?

Is the backend so severely broken that it needed to be removed?
-- 
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] QUuid documentation

[Benjamin TERRIER]

Le 10 sept. 2016 12:18 AM, "Edward Welbourne"  a écrit :
>
> Benjamin Terrier:
> >> However, my knowledge is that whatever the method one use to generate
> >> your UUID, one can never guarantee its uniqueness. Meaning that the
> >> Qt documentation is falsely guarantying unique UUID and therefore
> >> should be changed.
> >>
> >> If anyone can confirm, I'll create a bug report.
>
> Thiago Macieira
> > Right, it's not guaranteed. It's just that the chance of collision is
> > virtually zero.
>
> ... and for sufficiently small values of "virtually zero", that's as
> close a guarantee as you'll get to anything, because no matter how well
> you think you can guarantee things, cosmic rays still sporadically flip
> bits in your memory.
>
> I read a most illuminating paper a few years back that looked at the
> reliability of tests of prime-ness for large numbers.  There's a widely
> used approach that's cheap and theoretically not guaranteed but easy to
> apply to enough test-cases to reduce the likelihood of error to
> ignorably low.  This was compared to the best known "provably correct"
> algorithm for determining primeness - which is significantly more
> computationally expensive.  Due to the (ridiculously rare) flipping of
> bits by cosmic rays hitting the processor and memory, the latter was in
> fact *less* reliable than the former, because the former ran faster so
> incurred a smaller chance of errors due to stray rays.
>
> I don't think we should worry about documenting how not-quite-perfect
> our guarantee of UID uniqueness is in a case where - realistically -
> the difference from perfection is ignorable.
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

I agree with both of you.

Still I'd like the documentation to be changed, mainly for 2 reasons.


1. For the sake of correctness.
The sentence "the UUID will be of cryptographic quality, which will
make the UUID unique" is false
on a logical/mathematical/algorithmical point of view.
And here the documentation is about what the code does, what the
implemented algorithm provides, and
it does not provide a 100% guaranteed unique UUID.
Starting to justify that the UUID should be documented as guaranteed
unique in this part of the documentation
is out of scope because you make assumptions on where and how the code
will be executed.
It would be way better to tell that cryptographic quality UUID are as
unique as any UUID can be and that
in most use cases its uniqueness can be safely implied (because
hardware is less reliable, etc.).

2. For the sake of educating people
When reading "the UUID will be of cryptographic quality, which will
make the UUID unique", people who do not
have advance knowledge on UUID and such could come to think that there
is a way to guarantee UUID uniqueness.
And I'm pretty sure you could end up with quotes of Qt documentation
to back up the claim that
"UUID can be unique if the RNG is of cryptographic quality".

BR,

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

Re: [Development] [Qt-creator] [FYI] on gerrit change retargeting requests

[Jędrzej Nowacki]

On mandag 12. september 2016 14.39.57 CEST Orgad Shaneh wrote:
> On Tue, Sep 6, 2016 at 12:56 PM, J-P Nurmi  wrote:
> > On 06 Sep 2016, at 11:46, Konstantin Tokarev  wrote:
> > > 06.09.2016, 12:44, "Oswald Buddenhagen" :
> > >>> On Mon, Sep 05, 2016 at 09:17:59PM +, J-P Nurmi wrote:
> > >>>  On 05 Sep 2016, at 19:27, Marc Mutz  wrote:
> > >>>  > It's not about restricting what a user can do. It's simply missing
> > >>>  > implementation, and I believe that if it were easy to implement,
> > >>>  > Ossi would have done it long ago instead of playing retarget-monkey
> > >>>  > for the rest of us :)
> > >>>  
> > >>>  Doing it through the web UI would be a nice bonus, but having access
> > >>>  to the same script that is already used by the admins would be good
> > >>>  enough for starters.
> > >> 
> > >> yep - because i'm totally going to give everyone full write access to
> > >> the database. ;)
> > >> 
> > >> if you make a secure web frontend that authenticates against qt account
> > >> and verifies change ownership using the gerrit ssh interface, i'm
> > >> totally willing to deploy that. ;)
> > > 
> > > Idea: IRC bot accepting retarget requests, with rate limit e.g. one
> > 
> > request per minute. Bot runs on host with db access and can do only this
> > one thing.
> > 
> > Another idea: patch Gerrit to change the target branch (and create a new
> > patchset version to reset scores) when pushing to a different branch.
> 
> I have another suggestion, which should be quite easy to implement.
> 
> Either extend the sanity bot, or create a new bot, which listens on
> gerrit's event stream.
> 
> If *the change's owner* (or an approver?) posts a comment reading "Please
> retarget ", run your script on the server side. You need some
> sanity test that ensures this branch exists etc...
> 
> What do you say?
> 
> - Orgad

Actually that work is ongoing :-) I just need get a proper account in the 
right db.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules)

[Jędrzej Nowacki]

On fredag 19. august 2016 08.52.59 CEST Jędrzej Nowacki wrote:
> On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote:
> > How are the dependencies managed for projects/modules which are not part
> > of the qt5.git but are part of coin ?
> > 
> > Dominik
> 
> That is the reason of migrating "slowly". We need to define/find a product
> repository for them. Such super repository would define testing platforms,
> configurations and dependencies configurations. For experimental modules and
> in general, playground I would propose to create "qt-labs" product.
> Cheers,
>   Jędrek
 
Hi,

  In addition to what I said before "product less" modules, which we should 
not have, by default will depend on all Qt5 modules, so we can test them 
anyway.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development