Hi!
Forgive me for butting into this off-topic discussion about "true software
egnineering"
(which is a horrible wording).
AFAI understand that discussion is about quality.
Well, if you want to know how to develop quality software, you need to look
into safety
(not security!) industry. People
Hi Guiseppe,
> (The topic is still "how to port Qt to another platform".)
It is in the nature of discussions, that they might change direction -
like it happened with the AGILE side track.
> (Yes, I 100% agree that QtQuick could be modularized much further, e.g.
> drop its dependency from QtQm
On 29/09/18 23:35, Roland Hughes wrote:
Syllogism, nice word. For those who did not wish to look it up
[snip]
Thank you, but I assume that people reading this mailing list are smart
enough to look up the words that they don't know, or ask me directly for
an explanation.
Logic A form of d
On 29/09/18 23:45, Roland Hughes wrote:
Roland, consider yourself on notice. Your comment about OpenZinc was fine --
even if it is a competitor, telling people about their options is the right
thing to do. You can relate your experience with Qt and where things did not
satisfy you. But you cannot
Hi,
On 28/09/18 10:55, Uwe Rathmann wrote:
This is another blatant false statement, because you can port just the
parts of Qt that you need, and even those can be further trimmed down
using the feature system. (That's actually how you would do a port in
the first place.)
While I agree with almo
On 9/29/18 11:45 PM, Roland Hughes wrote:
I'm returning there for a few months to participate in a re-evaluation
process. They are considering ditching Qt for Electron. Doing side by
side development on all platforms to see which works best for them.
When we stumble into one of those featu
On 9/28/18 9:26 AM, interest-requ...@qt-project.org wrote:
And we don't use Jenkins. This is a completely FALSE assertion, no basis in
truth, intended to do harm. It's very easily proven wrong, since the testing
is open, clearly tests and failures cause changes to be rejected. In other
words, t
On 9/28/18 9:26 AM, Giuseppe D'Angelo wrote:
I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed
RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX
compliant). Currently the RTOS has only a text console output based on INT10
services. The R
On Thu, 27 Sep 2018 18:03:55 +0200, Giuseppe D'Angelo via Interest wrote:
> This is another blatant false statement, because you can port just the
> parts of Qt that you need, and even those can be further trimmed down
> using the feature system. (That's actually how you would do a port in
> the f
On Freitag, 28. September 2018 00:20:37 CEST Kim Hartman wrote:
> Thanks Tuuka (and others),
>
> We've ported much of the BOOST libraries, so pthreads are most possible.
> I've started an internal audit of the rest of POSIX services we would need
> in order to create an INtime QPA. Is there a mor
On Thursday, 27 September 2018 15:20:37 PDT Kim Hartman wrote:
> We've ported much of the BOOST libraries, so pthreads are most possible.
> I've started an internal audit of the rest of POSIX services we would need
> in order to create an INtime QPA. Is there a more comprehensive list of
> POSIX ca
Good reference. Thanks!
-Original Message-
From: Interest On
Behalf Of Thiago Macieira
Sent: Thursday, September 27, 2018 12:15 PM
To: interest@qt-project.org
Subject: Re: [Interest] Porting Qt to our RTOS
On Wednesday, 26 September 2018 23:53:17 PDT Tuukka Turunen wrote:
> Hi
nality? Is there such a thing as a generic QPA?
Kim
-Original Message-
From: Tuukka Turunen
Sent: Wednesday, September 26, 2018 11:53 PM
To: Jason H ; Kim Hartman
Cc: interest@qt-project.org
Subject: Re: [Interest] Porting Qt to our RTOS
Hi Kim,
Even partial Posix will help you get go
On Thursday, 27 September 2018 09:03:55 PDT Giuseppe D'Angelo via Interest
wrote:
> Il 27/09/2018 17:14, Roland Hughes ha scritto:
> > On 9/27/18 1:53 AM, Kim Hartman wrote:
> > The short answer is that you shouldn't.
> >
> > The AGILE processes behind Qt development
>
> 1) This is an unproven
On Wednesday, 26 September 2018 23:53:17 PDT Tuukka Turunen wrote:
> Hi Kim,
>
> Even partial Posix will help you get going. It is possible to do without,
> but then more work will be needed.
I echo the part about POSIX. If you don't have a POSIX layer, you're going to
have to port even things l
Il 27/09/2018 17:14, Roland Hughes ha scritto:
On 9/27/18 1:53 AM, Kim Hartman wrote:
I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed
RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX
compliant). Currently the RTOS has only a text con
On 9/27/18 1:53 AM, Kim Hartman wrote:
I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed
RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX
compliant). Currently the RTOS has only a text console output based on INT10
services. The RTOS i
tried to do it.
> Sent: Thursday, September 27, 2018 at 2:09 AM
> From: "Kim Hartman"
> To: "interest@qt-project.org"
> Subject: [Interest] Porting Qt to our RTOS
>
> I am investigating how to bring Qt to our INtime RTOS. The INtim
m Hartman"
> To: "interest@qt-project.org"
> Subject: [Interest] Porting Qt to our RTOS
>
> I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed
> RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX
> compliant).
I am investigating how to bring Qt to our INtime RTOS. The INtime Distributed
RTOS runs on standard PC hardware as a multicore AMP OS (no SMP and not POSIX
compliant). Currently the RTOS has only a text console output based on INT10
services. The RTOS is fully preemptive, with strict priority ba
20 matches
Mail list logo
