From: Development
on behalf of Thiago Macieira
>Suggestion: use the x.y release and when we make that release, we rename it in
>JIRA.
That is the current approach and it does not work or scale. Between branching
time and release time is a fairly long
Hi Lars, Simon,
I think I got it. Thanks a lot for your tips!
Sincerely yours,
Valery Kotov
On 8 August 2018 at 09:32, Simon Hausmann wrote:
> Hi,
>
>
> If you want to use the ValueArray, then you need to make sure that it's
> the last member of your type. Then encapsulate the creation if the
On Tuesday, 7 August 2018 18:19:10 PDT Young Moon Jung wrote:
> Hi Thiago.
>
> Thank you for your reply!
> It was very helpful for me.
>
> I have a one more question.
> Actually I load .qml file in main.cpp by using QQmlApplicationEngine Class.
> Is it mean that I can compile qml application with
On Wednesday, 8 August 2018 02:58:08 PDT Frederik Gladhorn wrote:
> branch is x.y -> find the next valid patch version
Suggestion: use the x.y release and when we make that release, we rename it in
JIRA.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Sourc
I wrote:
> I notice that QTest includes support, in [0], alongside its BLACKLIST
> files for problematic tests, for a GPU_BLACKLIST file; [...]
>
> Inevitably, I'm contemplating a featurectomy.
The reviews can be found here:
https://codereview.qt-project.org/#/q/status:open+branch:dev+topic:gpu-b
>>> I'm not the only one :
>>> https://github.com/search?p=1&q=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS&type=Code
On 08/08/2018 01:41 PM, Edward Welbourne wrote:
>> This URL got me:
>>
>> We could not perform this search
>>Must include at least one user, organization, or repo
On 08/08/2018 01:41 PM, Edward Welbourne wrote:
I'm not the only one :
https://github.com/search?p=1&q=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS&type=Code
This URL got me:
We could not perform this search
Must include at least one user, organization, or repository
so I'm
On Tuesday, July 31, 2018 8:15:50 PM CEST Ville Voutilainen wrote:
> On 31 July 2018 at 20:49, Thiago Macieira wrote:
> > I know CMake meets these requirements, but it has other problems and the
> > fact that it currently does not build Qt. On that front, qbs is ahead.
> > But qbs has a shorter tr
I wrote:
>> Inevitably, I'm contemplating a featurectomy.
Jean-Michaël Celerier (8 August 2018 13:33) replied
> I remember using it to be able to run integration tests on a virtual X11
> server in Travis CI.
How long ago ?
Are you *still* using it for this ?
Do you anticipate using it with 5.12
> Inevitably, I'm contemplating a featurectomy. Laszlo, who introduced
this for some fragile embedded systems in 2015, doesn't believe it's in
use, I don't see any evidence that it's documented anywhere (so I don't
expect anyone to be using it outside Qt itself *and* I can only work out
how it's
Hi all,
I notice that QTest includes support, in [0], alongside its BLACKLIST
files for problematic tests, for a GPU_BLACKLIST file; there are,
however, no GPU_BLACKLIST files anywhere in our source tree (in any
currently live branch, from 5.6 to dev). There's a whole complex
QTEST_ADD_GPU_BLACKL
On onsdag 8. august 2018 12.13.46 CEST André Hartmann wrote:
> Hi Frederik,
>
> one more question: does the script also sets the final Git-SHA1 in the
> Jira "commits" field?
>
> If yes, that would really be a *big* improvement.
Yes, that's the plan.
Frederik
>
> > Everything else (wip/foob
Coin production was updated today at Mon Aug 6 13:27:20 EEST 2018 with new
baseline.
For CI related issues, you may create bug report as instructed in
https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin and/or consult the
internal #qtci IRC-channel.
See change-list attached for related p
Hi Frederik,
one more question: does the script also sets the final Git-SHA1 in the
Jira "commits" field?
If yes, that would really be a *big* improvement.
> Everything else (wip/foobar, other branch names) will be ignored,
> unless someone explains what to do with them otherwise.
I think th
OK, now it's clear. I will try it out and report if that worked.
Thanks for your help!
ср, 8 серп. 2018 о 09:52 Olivier Goffart пише:
> On 2018-08-08 08:48, Taras Kushnir wrote:
> > Hi Olivier
> >
> > Thanks for fast response.
> >
> > Sorry for asking trivial questions but I didn’t quite unders
> On 30 Jul 2018, at 06:00, Thiago Macieira wrote:
>
> On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> It would also be pretty nice to know if there is a policy with respect the
>> llvm supported version. As they do not keep ABI compatibility distros
>> nor
> On 30 Jul 2018, at 06:00, Thiago Macieira wrote:
>
> On Sunday, 29 July 2018 13:36:43 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> It would also be pretty nice to know if there is a policy with respect the
>> llvm supported version. As they do not keep ABI compatibility distros
>> nor
On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:
> > -Original Message-
> > From: Development > project.org> On Behalf Of Jani Heikkinen
> >
> > >The plan is to update the fix versions and close the task as done when
> > >a line in the commit message starts with "Fixes:".
> > >
Hi Valery,
> On 8 Aug 2018, at 09:10, Valery Kotov wrote:
>
> Hello all,
>
> I have a question about QV4 heap objects and what could be stored in them.
> I would like to move data structure from c++ heap to GC heap. Unfortunately,
> my data structure stores a pair of QLists internally.
> As fa
Hi,
If you want to use the ValueArray, then you need to make sure that it's the
last member of your type. Then encapsulate the creation if the type in a
factory function that works a bit like ExecutionContext::newCallContext:
(1) Calculate how much memory you're going to need for the type
Hello all,
I have a question about QV4 heap objects and what could be stored in them.
I would like to move data structure from c++ heap to GC heap.
Unfortunately, my data structure stores a pair of QLists internally.
As far as I'm aware, QV4::Heap objects should be "trivially constructible",
and t
21 matches
Mail list logo