Re: [Development] [QML] Assigning ints to enumeration properties

[Knoll Lars]

On 3/6/13 8:23 PM, "Alan Alpert" <4163654...@gmail.com> wrote:

>On Wed, Mar 6, 2013 at 3:11 AM, Laszlo Papp  wrote:
>> On Wed, Mar 6, 2013 at 9:48 AM, Olivier Goffart 
>>wrote:
>>>
>>> This is not a warning, this is an error in C++
>>>
>>> enum Foo { A ,  B };
>>> Foo bar = 1; // error: invalid conversion from Œint¹ to ŒFoo¹
>>> int blah = bar; // No warning. unless you use enum class then it is a
>>> error.
>>
>>
>> At least, I can second that even with msvc variants, but perhaps Alan
>>meant
>> -fpermissive or so.
>
>Yes - although I thought -fpermissive was on by default for gcc (but
>it isn't, now that I've checked). Whoops.
>
>>
>>> I think implicit casts is *not* a good idea.
>>>
>>> Allowing explicit casts should be good.
>>
>>
>> That would be a bit uglier in QML than a static or function type
>>explicit
>> cast like in C++ unless there is a nice trick not to make map, object,
>> mapper function or so for enums with many values. Perhaps parseInt() or
>> something similar? I would not know.
>>
>> If there is no nice trick, I would suggest allowing it (perhaps with a
>> warning on the console?) because I do not wish to maintain such code if
>>I
>> know what I am doing. :)
>
>Unfortunately neither explicit casts nor a warning on the console
>would work well.

Why wouldn't explicit casts work? I can understand limitations in the
engine making this difficult, but in principle a syntax similar to JS
constructor objects should be doable. Like that we could even get the same
syntax as on the C++ side:

enumProperty: MyEnumType(myInt)

>We can't have explicit casts because the scripts are in JavaScript,
>which is dynamically typed. The only static typing is on QML objects,

We could expose a JS method from C++ that does the casting. This comes
with some overhead right now, but I believe we can actually make this
pretty cheap (a no-op) later on when we progress further on v4.

Cheers,
Lars

>so the function would only make sense when assigning to a property. In
>most cases then, you'd just make the property type int. The problem is
>when trying to have a good C++ API for the item as well; in C++ you
>want enum types and then they can cast to int if they want. So either
>you compromise your C++ API (use ints) or you compromise your QML API
>(use enums, but have to use hacky workarounds to cast ints).
>
>The workarounds bit ties into a couple of performance related aspects.
>You can currently work around it by taking a known enum (like
>Qt::AlignLeft = 1), and adding a number. This forms a script which can
>be assigned to an enum type, but it's ugly and a bad performance
>precedent to use scripts this way. The QML 1 engine is also very slow
>at using enums, so using ints instead would help tune up existing QML
>1 applications (while they port to QML 2 of course, which has improved
>enum performance already).
>
>The problem with a warning on the console is that these are emitted
>every time the application runs. So if you've written your application
>correctly and are happy with it, the user shouldn't be seeing the
>console flooded with warnings. This is why QML needs to be
>conservative with the compile warnings, compared to C++, they should
>all be considered runtime warnings.
>
>--
>Alan Alpert
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] [QML] Assigning ints to enumeration properties

[Laszlo Papp]

On Wed, Mar 6, 2013 at 7:23 PM, Alan Alpert <4163654...@gmail.com> wrote:

> The problem with a warning on the console is that these are emitted
> every time the application runs. So if you've written your application
> correctly and are happy with it, the user shouldn't be seeing the
> console flooded with warnings. This is why QML needs to be
> conservative with the compile warnings, compared to C++, they should
> all be considered runtime warnings.
>

setPermissive/setVerbose like method for the interpreter maybe? That could
be useful for the development process for instance, and not just for this
case, i.e. more like in general about getting verbose warnings about
potential places that can cause bugs. They could check such a verbose
output before publishing the application or so.

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

Re: [Development] [QML] Assigning ints to enumeration properties

[Olivier Goffart]

On Wednesday 06 March 2013 11:23:49 Alan Alpert wrote:
[...]
> We can't have explicit casts because the scripts are in JavaScript,
> which is dynamically typed.

Yes. Considering that, I guess implicit cast are ok.
But don't pretend it is to match C++ :-)

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QML] Assigning ints to enumeration properties

[Alan Alpert]

On Wed, Mar 6, 2013 at 3:11 AM, Laszlo Papp  wrote:
> On Wed, Mar 6, 2013 at 9:48 AM, Olivier Goffart  wrote:
>>
>> This is not a warning, this is an error in C++
>>
>> enum Foo { A ,  B };
>> Foo bar = 1; // error: invalid conversion from ‘int’ to ‘Foo’
>> int blah = bar; // No warning. unless you use enum class then it is a
>> error.
>
>
> At least, I can second that even with msvc variants, but perhaps Alan meant
> -fpermissive or so.

Yes - although I thought -fpermissive was on by default for gcc (but
it isn't, now that I've checked). Whoops.

>
>> I think implicit casts is *not* a good idea.
>>
>> Allowing explicit casts should be good.
>
>
> That would be a bit uglier in QML than a static or function type explicit
> cast like in C++ unless there is a nice trick not to make map, object,
> mapper function or so for enums with many values. Perhaps parseInt() or
> something similar? I would not know.
>
> If there is no nice trick, I would suggest allowing it (perhaps with a
> warning on the console?) because I do not wish to maintain such code if I
> know what I am doing. :)

Unfortunately neither explicit casts nor a warning on the console
would work well.

We can't have explicit casts because the scripts are in JavaScript,
which is dynamically typed. The only static typing is on QML objects,
so the function would only make sense when assigning to a property. In
most cases then, you'd just make the property type int. The problem is
when trying to have a good C++ API for the item as well; in C++ you
want enum types and then they can cast to int if they want. So either
you compromise your C++ API (use ints) or you compromise your QML API
(use enums, but have to use hacky workarounds to cast ints).

The workarounds bit ties into a couple of performance related aspects.
You can currently work around it by taking a known enum (like
Qt::AlignLeft = 1), and adding a number. This forms a script which can
be assigned to an enum type, but it's ugly and a bad performance
precedent to use scripts this way. The QML 1 engine is also very slow
at using enums, so using ints instead would help tune up existing QML
1 applications (while they port to QML 2 of course, which has improved
enum performance already).

The problem with a warning on the console is that these are emitted
every time the application runs. So if you've written your application
correctly and are happy with it, the user shouldn't be seeing the
console flooded with warnings. This is why QML needs to be
conservative with the compile warnings, compared to C++, they should
all be considered runtime warnings.

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

Re: [Development] Incorporating Intel Threading Building Blocks into Qt? (Was: Evolving Qt's multithreading API)

[Sze Howe Koh]

On 4 March 2013 20:41, Olivier Goffart  wrote:
> What exactly do you want to use TBB for?
>
> Can we not just suggest users to use TBB directly? And just make sure Qt play
> nice with it.
>
> Or do you want to make a wrapper library to qt-ify it? What exactly do you
> want to qt-ify? Is it only the underscores and naming conventions or is there
> more to do?
>
> Or do you think Qt could use TBB for implementing some of the algorithms
> within the Qt library?

The idea was to bring high-level multithreading functionality (e.g.
task scheduling, algorithms, thread-safe containers) into Qt, by
putting a wrapper around a 3rd-party library instead of inventing it
all ourselves. But yes, making Qt play nice with said library would
involve even less work than wrapping it. I'd imagine that Qt-fication
would involve not just naming conventions, but also signal/slot
support, integrating their algorithms with Qt containers, and hiding
modules that are redundant in Qt (e.g. their own mutexes).

I don't have a strong vision for it myself. It was something that
Thiago indicated interest in before
(http://lists.qt-project.org/pipermail/development/2012-November/007901.html),
so while I was on the topic of revamping Qt's multithreading API, I
included this in the list-of-things-to-explore.

A different possibility we could look at is absorbing ThreadWeaver
upstream, perhaps?


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

Re: [Development] integer bug in Qt4.8.x

[Thomas Senyk]

On Wed, March 06, 2013 12:25:32 Samuel Rødal wrote:
> On 03/06/2013 11:38 AM, Thomas Senyk wrote:
> > Hi,
> > 
> > I think I stumbled over a bug in Qt4.8.x - QtDeclarative, but I wanted to
> > asked for opinions first.
> > 
> > First of all: This is not happening in Qt5 (neither QtQuick2.0 nor QtQuick
> > 1.1)
> > 
> > This seems to only happen on ARM... at least I couldn't reproduce on any
> > x86 machine I tried.
> > 
> > The ARM system I tested on:
> >- imx6
> >- yocto based rootfs, sysroot and toolchain
> >- Qt5 built using mkspecs/devices/linux-imx6-g++ (not haven the bug)
> >- Qt4 built with my own mkspec based on the Qt5 device-mkspec
> >- Qt4/5 source-code from git with a most recent checkout
> > 
> > The bug:
> > 
> > It's about imprecise 'int' in QtQuick1.1 / JS (only Qt4!)
> > A code snipped triggering it would be:
> > 
> > property int ex: 0
> > 
> > Component.onCompleted:
> > {
> > 
> >  var tmp;
> >  var c = 1;
> >  
> >  for ( tmp = ex + 1; /*forever*/; tmp++ )
> >  {
> >  
> >  if ( tmp !== ( ex + 1 ) )
> >  {
> >  
> >  console.log( "error: " + tmp + " != " + ex + " + 1" );
> >  
> >  }
> >  
> >  c = c+1;
> >  
> >  if ( c > 10 )
> >  {
> >  
> >  console.log( tmp );
> >  c = 1;
> >  
> >  }
> >  
> >  ex = tmp;
> >  
> >  }
> > 
> > }
> > 
> > 
> > The log looks like:
> > 
> > ...
> > 820
> > 830
> > error: 8388610 != 8388610 + 1
> > error: 8388612 != 8388612 + 1
> > error: 8388614 != 8388614 + 1
> > error: 8388616 != 8388616 + 1
> > ...
> > 
> > 
> > where 8388610 == 0x82
> > 
> > For me it looks a little bit like some sort of floating-point accuracy
> > problems ... or a casting-error ... ?
> > 
> > 
> > Greets
> > Thomas
> 
> Numbers in JavaScript are defined to be implemented as floating point.
> So I would expect the loop to end up printing error at some point.
> However, a JavaScript implementation is supposed to use double precision
> floating point numbers, in which case the loop would run for a really
> long time before printing out such an error (double can exactly
> represent all 32-bit integers).
> 
> However, with single precision floating point numbers you hit the
> problem a lot sooner, and this C program, using single precision
> floating point, shows the error happening at 16777216:
> 
> #include 
> int main(int argc, char **argv)
> {
>  volatile float value = 1;
>  volatile int v1, v2;
>  do {
>  v1 = value;
>  v2 = (float)(value + 1.0);
>  value = v2;
>  } while (v1 != v2);
>  printf("%d %d\n", v1, v1 / 2);
> }
> 
> So there's still something strange going on, since 16777216 is two times
> 8388608, which is where the error manifests in your example. Not sure
> what the explanation of that is, but at least I guess we can assume that
> the JavaScript engine used for QML in Qt 4 might use float (probably
> when qreal is float) and thus is not fully compliant.


I guess that's the answer/confirm I was looking for.

So -DQT_COORD_TYPE  could be one solution.
 ... although that would create more performance problems then using 'var' 
instead of 'int' for specific properties.

Thanks.

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

Re: [Development] integer bug in Qt4.8.x

[Samuel Rødal]

On 03/06/2013 11:38 AM, Thomas Senyk wrote:
> Hi,
>
> I think I stumbled over a bug in Qt4.8.x - QtDeclarative, but I wanted to
> asked for opinions first.
>
> First of all: This is not happening in Qt5 (neither QtQuick2.0 nor QtQuick
> 1.1)
>
> This seems to only happen on ARM... at least I couldn't reproduce on any x86
> machine I tried.
> The ARM system I tested on:
>- imx6
>- yocto based rootfs, sysroot and toolchain
>- Qt5 built using mkspecs/devices/linux-imx6-g++ (not haven the bug)
>- Qt4 built with my own mkspec based on the Qt5 device-mkspec
>- Qt4/5 source-code from git with a most recent checkout
>
>
>
> The bug:
>
> It's about imprecise 'int' in QtQuick1.1 / JS (only Qt4!)
> A code snipped triggering it would be:
>
> property int ex: 0
>
> Component.onCompleted:
> {
>  var tmp;
>  var c = 1;
>
>  for ( tmp = ex + 1; /*forever*/; tmp++ )
>  {
>  if ( tmp !== ( ex + 1 ) )
>  {
>  console.log( "error: " + tmp + " != " + ex + " + 1" );
>  }
>
>  c = c+1;
>
>  if ( c > 10 )
>  {
>  console.log( tmp );
>  c = 1;
>  }
>
>  ex = tmp;
>  }
>
> }
>
>
> The log looks like:
>
> ...
> 820
> 830
> error: 8388610 != 8388610 + 1
> error: 8388612 != 8388612 + 1
> error: 8388614 != 8388614 + 1
> error: 8388616 != 8388616 + 1
> ...
>
>
> where 8388610 == 0x82
>
> For me it looks a little bit like some sort of floating-point accuracy
> problems ... or a casting-error ... ?
>
>
> Greets
> Thomas

Numbers in JavaScript are defined to be implemented as floating point. 
So I would expect the loop to end up printing error at some point. 
However, a JavaScript implementation is supposed to use double precision 
floating point numbers, in which case the loop would run for a really 
long time before printing out such an error (double can exactly 
represent all 32-bit integers).

However, with single precision floating point numbers you hit the 
problem a lot sooner, and this C program, using single precision 
floating point, shows the error happening at 16777216:

#include 
int main(int argc, char **argv)
{
 volatile float value = 1;
 volatile int v1, v2;
 do {
 v1 = value;
 v2 = (float)(value + 1.0);
 value = v2;
 } while (v1 != v2);
 printf("%d %d\n", v1, v1 / 2);
}

So there's still something strange going on, since 16777216 is two times 
8388608, which is where the error manifests in your example. Not sure 
what the explanation of that is, but at least I guess we can assume that 
the JavaScript engine used for QML in Qt 4 might use float (probably 
when qreal is float) and thus is not fully compliant.

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

Re: [Development] [QML] Assigning ints to enumeration properties

[Laszlo Papp]

On Wed, Mar 6, 2013 at 9:48 AM, Olivier Goffart  wrote:

>  This is not a warning, this is an error in C++
>
> enum Foo { A ,  B };
> Foo bar = 1; // error: invalid conversion from ‘int’ to ‘Foo’
> int blah = bar; // No warning. unless you use enum class then it is a
> error.
>

At least, I can second that even with msvc variants, but perhaps Alan meant
-fpermissive or so.

I think implicit casts is *not* a good idea.
>
> Allowing explicit casts should be good.
>

That would be a bit uglier in QML than a static or function type explicit
cast like in C++ unless there is a nice trick not to make map, object,
mapper function or so for enums with many values. Perhaps parseInt() or
something similar? I would not know.

If there is no nice trick, I would suggest allowing it (perhaps with a
warning on the console?) because I do not wish to maintain such code if I
know what I am doing. :)

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

Re: [Development] Fwd: [webkit-dev] Heads-up: C++11 and WebKit2

[Simon Hausmann]

On Wednesday, March 06, 2013 11:00:09 AM Simon Hausmann wrote:
> Hi,
> 
> FYI, the QML 2 integration of WebKit is going to require some C++11 support
> in the compiler side in the future. As far as I can see this "future" would
> be Qt 5.2 at the earliest. Qt 5.0 and Qt 5.1 are not affected at this
> point.

A point of clarification: If the compiler does not end up providing the 
necessary support, the QML2 integration of WebKit will simply be left out from 
the build. The existing C++ API of QtWebKit would remain available and 
functional of course.


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

Re: [Development] Fwd: [webkit-dev] Heads-up: C++11 and WebKit2

[Simon Hausmann]

On Wednesday, March 06, 2013 11:10:04 AM Olivier Goffart wrote:
> On Wednesday 06 March 2013 11:00:09 Simon Hausmann wrote:
> > Hi,
> > 
> > FYI, the QML 2 integration of WebKit is going to require some C++11
> > support
> > in the compiler side in the future. As far as I can see this "future"
> > would
> > be Qt 5.2 at the earliest. Qt 5.0 and Qt 5.1 are not affected at this
> > point.
> 
> Which features of C++11 exactly are going to be required?

See the original email: "Specifically, we’d like to make use of rvalue 
references and move semantics "

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

[Development] integer bug in Qt4.8.x

[Thomas Senyk]

Hi,

I think I stumbled over a bug in Qt4.8.x - QtDeclarative, but I wanted to 
asked for opinions first.

First of all: This is not happening in Qt5 (neither QtQuick2.0 nor QtQuick 
1.1)

This seems to only happen on ARM... at least I couldn't reproduce on any x86 
machine I tried.
The ARM system I tested on:
  - imx6
  - yocto based rootfs, sysroot and toolchain
  - Qt5 built using mkspecs/devices/linux-imx6-g++ (not haven the bug)
  - Qt4 built with my own mkspec based on the Qt5 device-mkspec
  - Qt4/5 source-code from git with a most recent checkout



The bug:

It's about imprecise 'int' in QtQuick1.1 / JS (only Qt4!)
A code snipped triggering it would be:

property int ex: 0

Component.onCompleted:
{
var tmp;
var c = 1;

for ( tmp = ex + 1; /*forever*/; tmp++ )
{
if ( tmp !== ( ex + 1 ) )
{
console.log( "error: " + tmp + " != " + ex + " + 1" );
}

c = c+1;

if ( c > 10 )
{
console.log( tmp );
c = 1;
}

ex = tmp;
}

}


The log looks like:

...
820
830
error: 8388610 != 8388610 + 1
error: 8388612 != 8388612 + 1
error: 8388614 != 8388614 + 1
error: 8388616 != 8388616 + 1
...


where 8388610 == 0x82

For me it looks a little bit like some sort of floating-point accuracy 
problems ... or a casting-error ... ?


Greets
Thomas

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

Re: [Development] Fwd: [webkit-dev] Heads-up: C++11 and WebKit2

[Olivier Goffart]

On Wednesday 06 March 2013 11:00:09 Simon Hausmann wrote:
> Hi,
> 
> FYI, the QML 2 integration of WebKit is going to require some C++11 support
> in the compiler side in the future. As far as I can see this "future" would
> be Qt 5.2 at the earliest. Qt 5.0 and Qt 5.1 are not affected at this
> point.

Which features of C++11 exactly are going to be required?
C++11 introduces a lot of changes, and each compilers implement a different 
subset of it.

We need to see which feature are used and stop supporting compilers that do 
not support them.  (Or rather, decide which compiler we want to support, and 
see which feature we can then use)

I'm all for requiring basic C++11 support with Qt5.2.
That mean we could finaly use 'auto' and lambda functions.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: [webkit-dev] Heads-up: C++11 and WebKit2

[Simon Hausmann]

Hi,

FYI, the QML 2 integration of WebKit is going to require some C++11 support in 
the compiler side in the future. As far as I can see this "future" would be Qt 
5.2 at the earliest. Qt 5.0 and Qt 5.1 are not affected at this point.



Simon--- Begin Message ---
Hello everyone,

Some time ago we started using C++11 in the Mac port of WebKit2. In the near 
future we’re going to expand our use of C++11 in the WebKit2 codebase. 
Specifically, we’d like to make use of rvalue references and move semantics in 
our IPC code to avoid needlessly copying data and to give some serializable 
objects (such as Mach ports) better semantics. 

If you’re a port that is building WebKit2, you're probably already building 
with a compiler that supports rvalue references; according to 
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport, support for move 
semantics exists in Visual Studio 2010 and later, as well as GCC 4.3 and later 
(and any reasonable modern version of clang).

- Anders

___
webkit-dev mailing list
webkit-...@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
--- End Message ---
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QML] Assigning ints to enumeration properties

[Olivier Goffart]

On Tuesday 05 March 2013 13:34:14 Alan Alpert wrote:
> I'd like to make a slight change to enum property behavior in QML.
> Currently you get a compile error if you assign an int to an enum
> property, similar to the warning you'll get in C++ if you do the same.
> However in C++ you can easily work around this by casting it to the
> enum, or just ignoring the warning. Neither option is available in
> QML.

This is not a warning, this is an error in C++

enum Foo { A ,  B };
Foo bar = 1; // error: invalid conversion from ‘int’ to ‘Foo’
int blah = bar; // No warning. unless you use enum class then it is a error.

> Note that since this relaxes the constraints of the language,
> previously running QML will continue to run as before.
> 
> I'll enumerate the pros and cons:
> 
> Pros:
> -Matches expectations from C++ users a little better

If you mean implicit conversion, then they don't.

> -Matches expectations from script users a little better
> Cons:
> -Code is usually less readable when you use ints.
> -Less typesafe (although the actual type of enum isn't checked, merely
> that it is an enum, so it's not that big a loss).
> 
> And a further quirk, you can already get this behavior if you make
> your properties int properties instead of enums currently (because
> enums can be assigned to int properties). However this is ugly for
> classes which are also exposed as C++ APIs, as they'd much prefer to
> use enums for a good C++ API.
> 
> Since it's a bit of a borderline issue, with minimal gains or losses,
> I'd like some further opinions on the issue. Does anyone feel strongly
> for or against this change?

I think implicit casts is *not* a good idea.

Allowing explicit casts should be good.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Please Help Update Sanity Test Guidelines

[Motyka Rafal]

Hello,

This is a request for help to update/correct the new Sanity Test Guidelines 
page.
Please feel free to change the page: 
http://qt-project.org/wiki/Sanity-Test-Guidelines
It's meant to be used for Qt releases as help for manual sanity testing (broad, 
not deep).

Any help will be highly appreciated.

Best regards,

/Rafal




Rafal Motyka
QE Engineer
Digia, Qt



Email: rafal.mot...@digia.com
Mobile: +47 95005389
http://qt.digia.com
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qt
Qt Twitter: www.twitter.com/qtcommercial


--

PRIVACY AND CONFIDENTIALITY NOTICE

This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. Digia Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.

-

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

Re: [Development] CI Network Server Problems

[Peter Hartmann]

On 03/05/2013 10:09 PM, Richard Moore wrote:
> I've tried setting up a test server
> with two different versions of ubuntu (the documented one, and the
> latest LTS version) but neither works. This makes it impossible for me
> to help address the CI failures.

I also have some problems: I have my own test server instance, but could 
not get down to 0 test failures for the network tests so far.

Maybe it would be possible to get a snapshot of the virtualised test 
server image from the CI system?

Peter

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development