Hi Holger,
Den 08. mai 2012 23:04, skrev ext Holger Hans Peter Freyther:
> Hi,
>
> I am looking into why QtV8 stopped working for MIPS (the obvious candidate is
> that there is lithium support now). While doing this I noted that in
> FullCodeGenerator::EmitResolvePossiblyDirectEval the following i
On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan
wrote:
> On Tuesday, May 8, 2012, Girish Ramakrishnan wrote:
>> Hi,
>>
>> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
>> wrote:
>>> The change landed. For some reason, the ci is failing compile in all
>>> other modules. Works locally wi
On Tue, May 8, 2012 at 4:22 PM, Rohan McGovern wrote:
> Girish Ramakrishnan said:
>> Hi,
>>
>> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
>> wrote:
>> > The change landed. For some reason, the ci is failing compile in all
>> > other modules. Works locally with shadow builds but not on CI
On Tue, 8 May 2012 20:08:38 ext Frank Hemer wrote:
> On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> > > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > > > language with essentially no support from off-the-shelf tools.
> > >
> > > It's this "compulsory" part that
On Tuesday, May 8, 2012, Girish Ramakrishnan
forwardbias.in > wrote:
> Hi,
>
> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
> forwardbias.in >
wrote:
>> The change landed. For some reason, the ci is failing compile in all
>> other modules. Works locally with shadow builds but not on CI. I a
Girish Ramakrishnan said:
> Hi,
>
> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
> wrote:
> > The change landed. For some reason, the ci is failing compile in all
> > other modules. Works locally with shadow builds but not on CI. I am on
> > it.
> >
>
> Fix is integrating: https://coderev
Hi,
I am looking into why QtV8 stopped working for MIPS (the obvious candidate is
that there is lithium support now). While doing this I noted that in
FullCodeGenerator::EmitResolvePossiblyDirectEval the following is not
consistent:
ARM:
1.) language_mode
2.) is_qml_mode
3.) start_position
ia32
I have no idea,
And I hope that we can do some change for branch names:
master ==> qt4
qt5==> master
or simply merge qt5 ==> master
Regards,
Debao
On Tue, May 8, 2012 at 9:45 AM, Alberto Mardegan
wrote:
> Hi all,
> I've got a question about the QML Desktop components at:
> http
On Friday 04 May 2012, Samuel Rødal wrote:
> On Linux, it's all up to the graphics driver in my experience. With the
> binary Nvidia driver the only reliable way I've seen of enabling vsync
> has been to do "export __GL_SYNC_TO_VBLANK=1" before launching an
> application. AMD's Catalyst control pan
On Monday 07 May 2012, Samuel Rødal wrote:
> On 05/04/2012 04:22 PM, ext Samuel Rødal wrote:
> > As for the open source drivers I don't know of any reliable way of
> > enabling vsync. There's the GLX_SGI_video_sync extension which is
> > supposed to give a uniform way to sync rendering regardless o
On terça-feira, 8 de maio de 2012 16.57.47, Marc Mutz wrote:
> > Between a move constructor and QSharedDataPointer, I'd rather stay with
> > the
> > latter. It avoids the manual reference counting, which may include subtle
> > errors.
>
> The manual reference counting reduces to calling ref() in th
Hi all,
I've got a question about the QML Desktop components at:
https://qt.gitorious.org/qtplayground/qtdesktopcomponents
Some components, such as TextField, are implemented as a derivative of
another (homonymous) component defined in the "custom/" subdirectory.
Why is this separation needed
On Thursday, May 03, 2012 23:00:49 Harri Porten wrote:
> On Thu, 3 May 2012, Thiago Macieira wrote:
> >> My suggestion is to replace them by callbacks and keep the setters in
> >> a
> >> private header. Someone is against this idea?
> >
> > Not at all.
> >
> > I suggested that the Squish and Gamm
Hi,
On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
wrote:
> The change landed. For some reason, the ci is failing compile in all
> other modules. Works locally with shadow builds but not on CI. I am on
> it.
>
Fix is integrating: https://codereview.qt-project.org/#change,25570.
Sorry for bl
On Tuesday May 8 2012, Thiago Macieira wrote:
> On terça-feira, 8 de maio de 2012 15.22.55, Marc Mutz wrote:
> > I'm also giving each class a move constructor. There, the classes which
> > hold their pimpl in smart pointers create the problem[1] that the move
> > ctor cannot be inline. I'm tempted
On terça-feira, 8 de maio de 2012 15.22.55, Marc Mutz wrote:
> I'm also giving each class a move constructor. There, the classes which
> hold their pimpl in smart pointers create the problem[1] that the move
> ctor cannot be inline. I'm tempted to remove the use of these in favour of
> going back
On terça-feira, 8 de maio de 2012 15.42.41, Marc Mutz wrote:
> > Most of the flags like -fno-exceptions ... are still binary compatible.
>
> What happens if an exception travels through C++ code compiled
> with -fno-exceptions? Will it pass through? Will it call all dtors? Or will
> it ruin the st
Hi Olivier,
Please excuse the delay in answering.
On Wednesday April 25 2012, Olivier Goffart wrote:
> On Wednesday 25 April 2012 15:07:24 Marc Mutz wrote:
[...]
> > > We could implement a move setter (Foo::setText(QString&&)). But that
> > > would
> > > mean duplication, and it could not be in
Hi,
I've just uploaded a patch series that aims to homogenise the value classes,
at least the pimpled (d-pointered) ones, with respect to basic C++ operations
like copying and moving. QEasingCurve can be seen as the prototype of these
classes:
a. member-swap()
b. inline copy and move assign
On Tuesday 08 May 2012 13:18:26 lars.kn...@nokia.com wrote:
> On 5/8/12 12:08 PM, "ext Frank Hemer" wrote:
> >On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> >> > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> >> > > language with essentially no support from off-th
On 5/8/12 12:08 PM, "ext Frank Hemer" wrote:
>On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
>> > > Now we suddenly have an easy to use, yet compulsory, Turing complete
>> > > language with essentially no support from off-the-shelf tools.
>> >
>> > It's this "compulsory" part that I don't u
On Tuesday 08 May 2012 09:50:16 Peter Kuemmel wrote:
> > > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > > language with essentially no support from off-the-shelf tools.
> >
> > It's this "compulsory" part that I don't understand.
> > The current situation is that if you
On Fri, May 4, 2012 at 8:20 AM, Girish Ramakrishnan
wrote:
> On Fri, Apr 20, 2012 at 7:16 AM, Girish Ramakrishnan
> wrote:
>> 2012/4/20 Stephen Kelly :
>>> On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote:
>>>
Proposal sounds ok to me as well. If someone still has concerns, plea
On Tuesday 08 May 2012 04:13:40 Alan Alpert wrote:
> On Mon, 7 May 2012 07:44:56 ext André Pönitz wrote:
> > On Mon, Apr 23, 2012 at 07:35:02AM +, lars.kn...@nokia.com wrote:
> > > [...] And who says that 100% of the code has to be C++?
> >
> > Nobody reasonably wants that. But people like to h
On 05/08/2012 04:13 AM, Alan Alpert wrote:
> It's this "compulsory" part that I don't understand. The current situation is
> that if you don't want to use QML you don't use it.
Lars wrote in his blog about the vision behind Qt5, but isn't the main
idea behind this one:
a) application development
> > Now we suddenly have an easy to use, yet compulsory, Turing complete
> > language with essentially no support from off-the-shelf tools.
>
> It's this "compulsory" part that I don't understand.
> The current situation is that if you don't want to use
> QML you don't use it.
Does "don't use it"
26 matches
Mail list logo
