Re: [Development] Nominating Peter Varga for approver status
On Wednesday, May 23, 2012 09:02:00 AM ext Simon Hausmann wrote: Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving upstream and a very complex patch set on our side. Based on his contributions he has clearly shown an understanding of V8 and the way QML is using it. An understanding that I believe is deep enough for him to easily review and approve contributions. I trust him to follow the process and I trust him to review only patches he's comfortable reviewing. Two seconds and no objections within a couple of weeks. Congratulations Peter! Who can set Peter's access up? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Q_EXPORT_PLUGIN_2 breaks source compat
On 6/10/12 9:45 PM, ext Thiago Macieira thiago.macie...@intel.com
wrote:
On domingo, 10 de junho de 2012 20.44.05, David Faure wrote:
Is it really desired to break source compat so much, after making the
promise of almost no porting required? Porting to a different plugin
framework doesn't sound trivial. Well, maybe it is, who knows -- there
is
no entry in dist/changes-5.0.0 about this!
It's necessary if we want to skip the loading of the old-style plugins.
There's no way to get the metadata from them besides loading.
This change was intentional.
Yes, it was unfortunately needed. This had also been discussed with
various people before the feature freeze.
The old style plugins require loading to get the keys() data, something
that's unacceptable in terms of performance. Porting is actually not very
difficult. It's simply about:
* add Q_PLUGIN_METADATA macro to your plugin object:
class MyPlugin : public QFooPlugin
{
Q_PLUGIN_METADATA(IID org.qt-project.foo FILE
myplugindescription.json)
}
* Add a myplugindescription.json file next to myplugin.h containing:
{ Keys: [ keyA, KeyB, Š ] }
The json data will get compiled into the plugin into a special ELF
section, that we can find fast at runtime without having to dlopen the
plugin.
* remove the Q_EXPORT_PLUGIN macro
The json file btw allows us to extend the meta data for plugins longer
term, as you can pretty much store anything in the json file.
I am e.g. thinking of changing the json format for image plugins to
something better than what we have now, containing the list of supported
mime types, and some feature description (can it load scaled, can it save,
etc.). Combine that with qmimedatabase, and we can significantly simplify
our image loading code as well as avoid having to load plugins that can't
handle the image for 99% of the cases.
But you're right that I still need to update the docs. I'll make sure they
are up to date for the beta.
Cheers,
Lars
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Peter Varga for approver status
On 6/11/12 8:17 AM, ext Simon Hausmann simon.hausm...@nokia.com wrote: On Wednesday, May 23, 2012 09:02:00 AM ext Simon Hausmann wrote: Hi, I would like to nominate Peter for approver status. As part of the team in the University of Szeged he has completed the past few rebases of V8 in the qtjsbackend module, a task that is anything but easy, with a fast moving upstream and a very complex patch set on our side. Based on his contributions he has clearly shown an understanding of V8 and the way QML is using it. An understanding that I believe is deep enough for him to easily review and approve contributions. I trust him to follow the process and I trust him to review only patches he's comfortable reviewing. Two seconds and no objections within a couple of weeks. Congratulations Peter! Who can set Peter's access up? Done. Congratulations Peter! Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating QFile::encodeName/decodeName
Thiago Macieira wrote: I won't de-inline the encodeName and decodeName functions. I have no interest in changing them. I'm fine with leaving them as they are, if you think it is too much hassle (compatibility issues and such) to remove altogether. I don't think they are the solution to the problem as I see it. I would add file:// parsing directly as a feature of QFileSystemEntry, with no additional public API. This can be done for 5.1. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About pcre in qt5
Giuseppe D'Angelo wrote: On 11 June 2012 00:49, tasuku.suz...@nokia.com wrote: Disabling PCRE makes sense for me. As we have QT_NO_REGEXP already, add it to feature list and fix the build. To be ultra pedantic, perhaps QT_NO_REGEXP should be renamed into samething like QT_NO_REGULAREXPRESSION for selectively disabling PCRE+QRegularExpression (butkeeping QRegExp)? I'm not sure we should allow QRegExp to be used when there is no QRegularExpression, as we want code to move over to using QRegularExpression, not the other way around. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Make qdoc an officially supported tool for generating QML API documentation
Hi, We have been very busy to get qdoc running outside of Qt (I am starting to use qdoc as LaTeX-lite now if I just need an HTML page). I do agree that the qdoc manual should be improved with examples that do not necessarily reflect how we use qdoc with Qt. All changes that we are doing to qdoc are only added to the Qt5 version of qdoc (which is qdoc instead of qdoc3). The Qt5 version should also support the \inherits you mentioned in the QTBUG (be aware that you cannot use \inherits when documenting .qml files, since we automatically use the top level element in the .qml file. Casper On 6/8/12 5:16 PM, ext Sven Anderson sven.ander...@snom.com wrote: Hi all, since qdoc is the only tool that can create documentation for QML APIs, but it's (AFAIK) not supported as an external tool - although that is very much needed especially for QML - I suggest to make qdoc the offical tool for generation of external QML API documentation (and fix it accordingly). I filed a suggestion here: https://bugreports.qt-project.org/browse/QTBUG-26096 Best regards, Sven ___ 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] Possible binary compatibility problem in a future Qt version
On Friday 8. June 2012 12.31.50 ext Thiago Macieira wrote: On sexta-feira, 8 de junho de 2012 10.31.31, Jedrzej Nowacki wrote: Qt meta-type system is assuming that type information is constant and consistent. It make sense because in C++ a type trait can not be changed during execution of an application. We agreed that unregistering of a type is a bad idea and that updating a type data can cause malfunction in Qt itself (not mentioning external library or applications). In Qt5 we introduced a lot of template based auto-detection for different features. Most of the data gathered by QTypeInfo, QMetaTypeId helpers classes are stored in QMetaType internal data, so it can also be used during a runtime introspection. So far so good, we have inlined data which is constant and consistent with data that we stored in QMetaType. So what will happen if we compile an application with an older Qt and link against a newer one, assuming that we introduced or changed a new type's information? That cannot happen. A type's information cannot change incompatibly from one version to the next. It must stay constant until Qt 6. Take for example the movability flag: if a type changes from unmovable to movable, QList's allocation strategy might change. A type's information can only be modified by adding new traits. Keep in mind that by introducing a new trait you are actually changing existing state. Imagine that we do not have movable flag. So by default everything is not movable. Then we introduce it, suddenly some types virtually change movable attribute. In this case it 98% safe, because default value is always valid. (...) I'd suggest that any automatic flags can only exist if they are either: a) present in Qt 5.0 b) completely forwards and backwards compatible for all uses (something that might be hard to prove) a) And bug-less... such flag can not be fixed without recompiling. b) Such requirement makes the flag completely useless. I hope that you mean forward compatibility, which means that an app compiled with an older Qt version would work correctly with a newer Qt version. Any other flags must be user-specified, with Q_DECLARE_TYPEINFO. That way, we guarantee that the flag will remain the same throughout the lifetime of Qt 5 and that type. Changing any of the flags that can pose incompatible problems is a binary- incompatible change of the type itself. It must not be done if the library providing that type wishes to remain BC. User-specified flags make sense, Thanks for feedback. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Alpha 2 this week or skip it
qt3d successful comipled by msvc11 when I insert #include functional to the \qt5\qt3d\3rdparty\assimp\code\AssimpPCH.h ahead of all other #include . 2012/6/11 Laszlo Papp lp...@kde.org: On Sun, Jun 10, 2012 at 12:07 PM, techabc tech...@gmail.com wrote: yes, thing get well in my another project. Could you please clarify the error output again after including functional ? Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Possible binary compatibility problem in a future Qt version
On segunda-feira, 11 de junho de 2012 10.33.13, Jedrzej Nowacki wrote: A type's information can only be modified by adding new traits. Keep in mind that by introducing a new trait you are actually changing existing state. Imagine that we do not have movable flag. So by default everything is not movable. Then we introduce it, suddenly some types virtually change movable attribute. In this case it 98% safe, because default value is always valid. Which is why I said this below. See (b): (...) I'd suggest that any automatic flags can only exist if they are either: a) present in Qt 5.0 b) completely forwards and backwards compatible for all uses (something that might be hard to prove) a) And bug-less... such flag can not be fixed without recompiling. b) Such requirement makes the flag completely useless. I hope that you mean forward compatibility, which means that an app compiled with an older Qt version would work correctly with a newer Qt version. No, I mean that you cannot add an automatic flag that changes the behaviour of existing code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On segunda-feira, 11 de junho de 2012 11.02.24, João Abecasis wrote:
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
uint flags;
int size; // ### move to the main class body?
// -- 4 bytes padding here on 64-bit systems --
qptrdiff offset; // in bytes from beginning of header
// size is 16 / 24 bytes
};
The most often used elements have to be offset and size. The ref-count is
used in copying and detaching, as typically will be the flags.
Agreed.
As long as we're doing more open-heart surgery I would support moving offset
and size to the beginning of the struct, to try to avoid padding holes.
I don't think moving them around will change anything. It won't make the code
any faster and it won't avoid a padding hole. The structure contains an odd
number of 32-bit entries, so it requires one 32-bit padding somewhere to add
up to a multiple of 64 bits.
If we are to inline any data in QVector/QString/QByteArray/QList themselves,
offset and size should go together, which would potentially make
sizeof(QContainer) == 3 * sizeof(void*), up from sizeof(void*). Read-only
operations wouldn't touch the header or the reference count at the cost of
copies and, well, sizeof(QContainer).
I agree. Moving just the size wouldn't help much. It would optimise isEmpty(),
but not anything else.
If we move the offset, then I see no point in keeping it an offset. I'd just
keep a regular pointer. It's an offset only so we could keep the Data header
relocation-free when saving in a static variable.
For a month or two, QStringLiteral returns a QString, not just a QStringData.
So this surgery is possible.
Note also that if we move both, then we finally have cheap substrings, since
the pointer to the beginning of the data and the size are kept separate from
the reference counter. Two different QStrings could have pointers to the same
data and also share the reference counter.
struct QArrayAllocatedData : public QArrayData
{
uint alloc;
// 4 bytes tail padding on 64-bit systems
// size is 20 / 32 bytes
};
struct QArrayForeignData : public QArrayData
{
void *token;
void (*notifyFunction)(void *);
// size is 24 / 40 bytes
};
Following Olivier's suggestion I think it might be beneficial to have alloc
unconditionally in the base class, even if it is not being used at times.
If nothing else, it saves padding. Additionally, deleter function and token
would be more generally useful if they can be used with the alloc member.
Yes, if we move the alloc member to the main struct, then it will simply
occupy the space currently used for padding. The total overhead for an
allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is 16-
byte aligned, this means our data is always 8 bytes off.
In my opinion, that's actually worse than having a larger header.
Say, you allocate a buffer, you want some QContainer to manage it *and*
change it in place as necessary *and* free it when done. This is similar to
the WebKit use case, but here we don't assume an external ref-count so
ref-count of 1 means the data can be changed.
[see discussion below]
The changes are:
- instead of a single bit of flags, there's a full integer now (32 bits),
which allow us to to more things.
- I've reserved 3 of those bits to indicate the type of array: raw data
(like QStringLiteral and fromRawData), heap-allocated data, foreign data.
I want to clearly discuss what those bits or flags will mean and their exact
semantics. These are my suggestions:
- CapacityReserved (taking over from the current bit)
- Mutable (taking over from alloc != 0, frees alloc member to be reused
when data is immutable)
Sure, that's doable.
- Notify/Deleter (new functionality)
Ok, I see. You're splitting the deleter from the immutability. Since we do
have a flag for immutability, we can serve WebKit's use-case, but also do in-
place modifications.
I find that a nice use-case.
You're going further and suggesting that we could also tell the container how
much memory was reserved externally, so it could grow around without
reallocating. I think that's your reason for keeping the alloc member together
with the notify function.
However, I don't think that's going to be a very useful use-case. I already
think that in-place modification of externally-allocated data is a stretch use-
case, but one that could be eventually useful. Allowing the container to use
memory around that is too much, IMHO.
- foreign data is like fromRawData: it comes from somewhere else, we don't
manage its memory and it's immutable. The difference is that we'll call a
notify function (see above) when our refcount drops to zero. This allows,
for example, to use QString on data managed by WTF::String or UTF-16 data
stored in an mmap'ed page.
Let's make foreign and immutable orthogonal.
Agreed.
I'll prepare a change.
- the alloc member is
Re: [Development] Changing container privates again
Thiago Macieira wrote: Following Olivier's suggestion I think it might be beneficial to have alloc unconditionally in the base class, even if it is not being used at times. If nothing else, it saves padding. Additionally, deleter function and token would be more generally useful if they can be used with the alloc member. Yes, if we move the alloc member to the main struct, then it will simply occupy the space currently used for padding. The total overhead for an allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is 16- byte aligned, this means our data is always 8 bytes off. In my opinion, that's actually worse than having a larger header. But that's what we currently have and wouldn't change with you suggestion above, right? Would it be worth to set the minimum alignment for the data as 16-bytes, at the expense of padding we explicitly add in QArrayData::allocate? (Since this decision can be done inside that function it would have no impact on ABI) Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On segunda-feira, 11 de junho de 2012 16.00.58, João Abecasis wrote: Thiago Macieira wrote: Following Olivier's suggestion I think it might be beneficial to have alloc unconditionally in the base class, even if it is not being used at times. If nothing else, it saves padding. Additionally, deleter function and token would be more generally useful if they can be used with the alloc member. Yes, if we move the alloc member to the main struct, then it will simply occupy the space currently used for padding. The total overhead for an allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is 16- byte aligned, this means our data is always 8 bytes off. In my opinion, that's actually worse than having a larger header. But that's what we currently have and wouldn't change with you suggestion above, right? We currently have 24 bytes. With my changes, it goes to 32 bytes, which is the second most ideal value. The ideal one would be 16 bytes. Would it be worth to set the minimum alignment for the data as 16-bytes, at the expense of padding we explicitly add in QArrayData::allocate? (Since this decision can be done inside that function it would have no impact on ABI) QArrayData::allocate can take that decision. In fact, that was in my plans for some future improvement. But that means we'll use 32 bytes anyway for all allocations, in any platform. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Assignment of JIRA bugs to non-approvers
Hello, I believe this was briefly discussed on IRC, but just to recapitulate, is it possible to have JIRA bugs assigned automatically to non-approvers? We are in the process of revamping Blackberry's Qt page on Github (github.com/blackberry/Qt), and one of the things we would like to do is to do away with the 'Issues' area, and direct all the QNX/BB Qt bugs to the Qt bugtracker - to allow closer community interaction and to be coherent with the rest of the Qt ecosystem. It would be nice if someone could point out if this is possible, and if so, what has to be done to comply with the requirements (if any). Cheers, Rafael -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
Thiago Macieira wrote:
Ok, I see. You're splitting the deleter from the immutability. Since we do
have a flag for immutability, we can serve WebKit's use-case, but also do in-
place modifications.
Yes.
I find that a nice use-case.
You're going further and suggesting that we could also tell the container how
much memory was reserved externally, so it could grow around without
reallocating. I think that's your reason for keeping the alloc member
together
with the notify function.
Yes.
However, I don't think that's going to be a very useful use-case. I already
think that in-place modification of externally-allocated data is a stretch
use-
case, but one that could be eventually useful. Allowing the container to use
memory around that is too much, IMHO.
Heh, mpeterss just walked into my office with a QIODevicePrivateLinearBuffer
issue...
There, QIODevice manages a read cache. When you call readAll on that, it copies
all the data to QByteArray and resets its data:
QByteArray readAll()
{
char* data = first;
int length = len;
QByteArray retVal(data, length);
clear();
return retVal;
}
Depending on length, it'd be good to relinquish your buffer to QIODevice and
allocate a new one. Saves the memcpy(): Here you go, do what you like with it
but call free() when you're done playing.
In this use case mutability might not be the most important thing, but then why
limit how the buffer can be used if the original owner no longer requires any
restrictions?
Anyway, I don't think this is a stretch as long as we don't allow these
decisions to be made implicitly for the user. For instance, we shouldn't be
changing the semantics of fromRawData as it exists today, but we could enable
users to be explicit about what's in the raw buffer and how it can be used.
Say, Hey QString, here's a UTF-16 string *and* it's already null-terminated --
just don't change it :-)
Cheers,
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On segunda-feira, 11 de junho de 2012 16.16.59, João Abecasis wrote:
However, I don't think that's going to be a very useful use-case. I
already
think that in-place modification of externally-allocated data is a stretch
use- case, but one that could be eventually useful. Allowing the
container to use memory around that is too much, IMHO.
Heh, mpeterss just walked into my office with a QIODevicePrivateLinearBuffer
issue...
There, QIODevice manages a read cache. When you call readAll on that, it
copies all the data to QByteArray and resets its data:
QByteArray readAll()
{
char* data = first;
int length = len;
QByteArray retVal(data, length);
clear();
return retVal;
}
Depending on length, it'd be good to relinquish your buffer to QIODevice and
allocate a new one. Saves the memcpy(): Here you go, do what you like with
it but call free() when you're done playing.
The notify thing could do that. I'm not sure about the QIODevice use-case,
though. QRingBuffer is a scattered buffer and QByteArray cannot manage that
anyway. You need to consolidate before returning from readAll() and do a lot
of memcpy. So why not let QByteArray allocate the memory in the first place?
There, we don't have foreign data anymore.
In this use case mutability might not be the most important thing, but then
why limit how the buffer can be used if the original owner no longer
requires any restrictions?
Because we don't know how it was allocated or what's around it. We stored a
function that does free already. Do you want to store one that does realloc?
Anyway, I don't think this is a stretch as long as we don't allow these
decisions to be made implicitly for the user. For instance, we shouldn't be
changing the semantics of fromRawData as it exists today, but we could
enable users to be explicit about what's in the raw buffer and how it can
be used. Say, Hey QString, here's a UTF-16 string *and* it's already
null-terminated -- just don't change it :-)
We have bits available to store that extra information if we want to.
But I don't see the point of mutable foreign data with extra buffer.
What's more, we can easily add a new type if we want to. In fact, let's
discuss the new headers *without* looking at how ForeignData is implemented.
Let's just assume that there is such a thing.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
Thiago Macieira wrote:
On segunda-feira, 11 de junho de 2012 16.00.58, João Abecasis wrote:
Thiago Macieira wrote:
Following Olivier's suggestion I think it might be beneficial to have
alloc
unconditionally in the base class, even if it is not being used at times.
If nothing else, it saves padding. Additionally, deleter function and
token
would be more generally useful if they can be used with the alloc member.
Yes, if we move the alloc member to the main struct, then it will simply
occupy the space currently used for padding. The total overhead for an
allocation would be 24 bytes on 64-bit systems. Since glibc's allocator is
16- byte aligned, this means our data is always 8 bytes off.
In my opinion, that's actually worse than having a larger header.
But that's what we currently have and wouldn't change with you suggestion
above, right?
We currently have 24 bytes. With my changes, it goes to 32 bytes, which is
the
second most ideal value. The ideal one would be 16 bytes.
The proposed QArrayAllocatedData is 32-bytes in size, but at the cost of two
4-byte padding holes. That's not that much different from a 24-byte header with
no holes -- you can always add padding at the end ;-)
With a 32-byte default header you get the prepend optimization for free:
struct QArrayData
{
qptrdiff offset;
uint size;
QtPrivate::RefCount ref;
uint flags;
uint alloc;
qptrdiff beginOffset;
};
24/32 bytes. (16/24 bytes if we move offset and size out)
Did you mean something else?
Would it be worth to set the minimum alignment for the data as 16-bytes, at
the expense of padding we explicitly add in QArrayData::allocate? (Since
this decision can be done inside that function it would have no impact on
ABI)
QArrayData::allocate can take that decision. In fact, that was in my plans
for
some future improvement.
But that means we'll use 32 bytes anyway for all allocations, in any platform.
The decision can still be made conditional on the architecture or so.
João
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On segunda-feira, 11 de junho de 2012 16.47.46, João Abecasis wrote:
The proposed QArrayAllocatedData is 32-bytes in size, but at the cost of two
4-byte padding holes. That's not that much different from a 24-byte header
with no holes -- you can always add padding at the end ;-)
With a 32-byte default header you get the prepend optimization for free:
struct QArrayData
{
qptrdiff offset;
uint size;
QtPrivate::RefCount ref;
uint flags;
uint alloc;
qptrdiff beginOffset;
};
24/32 bytes. (16/24 bytes if we move offset and size out)
beginOffset and offset overload each other. I don't see the need for both. We
can get rid of one, since they mean the same thing.
If we move offset and size out, then we need to drop to 16 bytes on 64-bit
systems. It should be only the refcount, flags and alloc (the latter only for
allocated data).
By moving the alloc out, we also drop the overhead of QStringLiteral to only 2
ints. And it could go down to one, if we set the immutable header flag in the
flags too.
Would it be worth to set the minimum alignment for the data as 16-bytes,
at
the expense of padding we explicitly add in QArrayData::allocate? (Since
this decision can be done inside that function it would have no impact on
ABI)
QArrayData::allocate can take that decision. In fact, that was in my plans
for some future improvement.
But that means we'll use 32 bytes anyway for all allocations, in any
platform.
The decision can still be made conditional on the architecture or so.
True.
But I can turn around and say that on some architectures we want the header to
be as small as possible, so we don't want to keep the alloc member in static
allocations.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Build error in bluetooth module on Mac OS X 10.6
Hi! I'm trying to build Qt5 on the Mac following the wiki page instructions. It fails when compiling the bluetooth qml module: g++ -headerpad_max_install_names -mmacosx-version-min=10.6 -single_module -dynamiclib -o libdeclarative_bluetooth_debug.dylib .obj/debug-shared/plugin.o .obj/debug-shared/qdeclarativebluetoothservice.o .obj/debug-shared/qdeclarativebluetoothsocket.o .obj/debug-shared/qdeclarativebluetoothdiscoverymodel.o .obj/debug-shared/qdeclarativebluetoothimageprovider.o .obj/debug-shared/moc_qdeclarativebluetoothservice_p.o .obj/debug-shared/moc_qdeclarativebluetoothsocket_p.o .obj/debug-shared/moc_qdeclarativebluetoothdiscoverymodel_p.o .obj/debug-shared/qrc_bluetooth.o -F/Users/njeiseck/projects/qt/qt5/qtbase/lib -L/Users/njeiseck/projects/qt/qt5/qtbase/lib -framework QtQuick -L/Users/njeiseck/projects/qt/qt5/qtbase/lib -F/Users/njeiseck/projects/qt/qt5/qtbase/lib -framework QtQml -framework QtNetwork -framework QtCore -framework QtV8 -framework QtGui -framework QtBluetooth -framework QtConcurrent -framework OpenGL -framework AGL ld: framework not found QtQuick collect2: ld returned 1 exit status make[4]: *** [../../../../qtbase/imports/QtBluetooth/libdeclarative_bluetooth_debug.dylib] Error 1 make[3]: *** [debug] Error 2 make[2]: *** [sub-bluetooth-make_default] Error 2 make[1]: *** [sub-imports-make_default-ordered] Error 2 make: *** [module-qtconnectivity-src-make_default-ordered] Error 2 I guess that QtQuick framework reference must come after the framework path. However I'm not yet familiar with the Qt 5 build system, so any hint where to fix that would be appreciated. Thanks! Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Assignment of JIRA bugs to non-approvers
Hi Rafael, I believe this was briefly discussed on IRC, but just to recapitulate, is it possible to have JIRA bugs assigned automatically to non-approvers? The automatic assignment of new tasks is based on component ownership. Anyone who is assignable can be the owner of a component, and they can elect to be the default assignee for tasks raised against that component (the other option is to default new tasks to Unassigned). We are in the process of revamping Blackberry's Qt page on Github (github.com/blackberry/Qt), and one of the things we would like to do is to do away with the 'Issues' area, and direct all the QNX/BB Qt bugs to the Qt bugtracker - to allow closer community interaction and to be coherent with the rest of the Qt ecosystem. Those bugs should certainly go to the Qt bug tracker. You will probably find that many of them aren't specific to QNX/BB and that people interested in other platforms can help. At present the bug tracker doesn't have components for specific platforms. We used to have those and they unfortunately became a dumping ground for any bug seen on a platform, rather than only getting bugs that were specific to those platforms. Bugs should generally be raised against the appropriate component, with the affected platform(s) noted in Environment field. The maintainer of that component can then reassign to people looking after specific platforms if they determine that the bug is in the platform support code (or if the reporter is already certain that the bug is platform-specific, they can assign directly). It would be nice if someone could point out if this is possible, and if so, what has to be done to comply with the requirements (if any). I think the main thing is to make sure that Maintainers know who the potential assignees are when they discover a bug in platform-specific code. I don't think we have that documented very well at present, even for the desktop platforms. Cheers, -- Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Retina display
So apple announced just now the retina display 15 inch macbook. What plans does QT have for this support? Is there any way we can get qt 4 to render its widgets for this new resolution? -Jason 'Like' us on Facebook for exclusive content and other resources on all Barracuda Networks solutions. Visit http://barracudanetworks.com/facebook ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Retina display
On Mon, Jun 11, 2012 at 2:45 PM, Jason Dictos jdic...@barracuda.com wrote: So apple announced just now the retina display 15 inch macbook. What plans does QT have for this support? Is there any way we can get qt 4 to render its widgets for this new resolution? Dude people needs to get hardware to test first :) -Jason -- 'Like' us on Facebook for exclusive content and other resources on all Barracuda Networks solutions. Visit http://barracudanetworks.com/facebook ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Retina display
You can actually run it now, on any mac: http://www.redmondpie.com/how-to-enable-hidpi-display-mode-retina-like-in-os-x-lion-video/ It's been a long time coming actually. -Jason -Original Message- From: Alexis Menard [mailto:alexis.men...@openbossa.org] Sent: Monday, June 11, 2012 1:59 PM To: Jason Dictos Cc: development@qt-project.org Subject: Re: [Development] Retina display On Mon, Jun 11, 2012 at 2:45 PM, Jason Dictos jdic...@barracuda.com wrote: So apple announced just now the retina display 15 inch macbook. What plans does QT have for this support? Is there any way we can get qt 4 to render its widgets for this new resolution? Dude people needs to get hardware to test first :) -Jason -- 'Like' us on Facebook for exclusive content and other resources on all Barracuda Networks solutions. Visit http://barracudanetworks.com/facebook ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia 'Like' us on Facebook for exclusive content and other resources on all Barracuda Networks solutions. Visit http://barracudanetworks.com/facebook ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QStringRef conversion functions
I was wondering if there would be a possibility of getting some of the conversion functions that are in QString implemented in QStringRef (toInt, toFloat, etc...). The reasoning behind this is that I am using the QXMLStreamReader to parse an XML file with over 88,704 floating point values. I am trying to improve the speed at which the file is parsed and I believe one of the bottlenecks is taking an attribute of QStringRef and copying its data into a QString in order to convert to a float. I would prefer that the copy never happen but that would require some more intelligence be added into the QStringRef class. Would this be possible to add this in time for the Qt 5.0 release? If not, would it be possible to add this for Qt 5.1 release? Keith Gardner Software Engineer Zebra Imaging 9801 Metric Blvd., Suite 200 Austin, TX 78758 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About pcre in qt5
On 11 June 2012 09:21, João Abecasis joao.abeca...@nokia.com wrote: Giuseppe D'Angelo wrote: On 11 June 2012 00:49, tasuku.suz...@nokia.com wrote: Disabling PCRE makes sense for me. As we have QT_NO_REGEXP already, add it to feature list and fix the build. To be ultra pedantic, perhaps QT_NO_REGEXP should be renamed into samething like QT_NO_REGULAREXPRESSION for selectively disabling PCRE+QRegularExpression (butkeeping QRegExp)? I'm not sure we should allow QRegExp to be used when there is no QRegularExpression, as we want code to move over to using QRegularExpression, not the other way around. Sure -- I was purely talking in terms of individual features to compile in: QRegExp and QRegularExpression are independent and therefore could be individually disabled... Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStringRef conversion functions
On segunda-feira, 11 de junho de 2012 14.54.44, Girish Ramakrishnan wrote: Hi, On Mon, Jun 11, 2012 at 11:38 AM, Keith Gardner kgard...@zebraimaging.com wrote: I was wondering if there would be a possibility of getting some of the conversion functions that are in QString implemented in QStringRef (toInt, toFloat, etc...). The reasoning behind this is that I am using the QXMLStreamReader to parse an XML file with over 88,704 floating point values. I am trying to improve the speed at which the file is parsed and I believe one of the bottlenecks is taking an attribute of QStringRef and copying its data into a QString in order to convert to a float. I would prefer that the copy never happen but that would require some more intelligence be added into the QStringRef class. I am tempted to say it's 5.1 material but it would be nice to see how much gains you are getting out of these new apis and how intrusive the new code is. Can you push your change to gerrit ? We might be able to remove QStringRef before Qt 5.0 and replace it with plain QString. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QStringRef conversion functions
2012/6/12 Thiago Macieira thiago.macie...@intel.com: On segunda-feira, 11 de junho de 2012 14.54.44, Girish Ramakrishnan wrote: Hi, On Mon, Jun 11, 2012 at 11:38 AM, Keith Gardner kgard...@zebraimaging.com wrote: I was wondering if there would be a possibility of getting some of the conversion functions that are in QString implemented in QStringRef (toInt, toFloat, etc...). The reasoning behind this is that I am using the QXMLStreamReader to parse an XML file with over 88,704 floating point values. I am trying to improve the speed at which the file is parsed and I believe one of the bottlenecks is taking an attribute of QStringRef and copying its data into a QString in order to convert to a float. I would prefer that the copy never happen but that would require some more intelligence be added into the QStringRef class. I am tempted to say it's 5.1 material but it would be nice to see how much gains you are getting out of these new apis and how intrusive the new code is. Can you push your change to gerrit ? We might be able to remove QStringRef before Qt 5.0 and replace it with plain QString. That is what I'd love to see in 5.0. Making sub-QStrings as cheap as QStringRef currently is would give us quite significant performance boost in some common use-cases. Then, QStringRef definitely should go. Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About pcre in qt5
On 2012/06/12, at 4:20, ext Giuseppe D'Angelo wrote: On 11 June 2012 09:21, João Abecasis joao.abeca...@nokia.com wrote: Giuseppe D'Angelo wrote: On 11 June 2012 00:49, tasuku.suz...@nokia.com wrote: Disabling PCRE makes sense for me. As we have QT_NO_REGEXP already, add it to feature list and fix the build. To be ultra pedantic, perhaps QT_NO_REGEXP should be renamed into samething like QT_NO_REGULAREXPRESSION for selectively disabling PCRE+QRegularExpression (butkeeping QRegExp)? I'm not sure we should allow QRegExp to be used when there is no QRegularExpression, as we want code to move over to using QRegularExpression, not the other way around. Sure -- I was purely talking in terms of individual features to compile in: QRegExp and QRegularExpression are independent and therefore could be individually disabled… Yeah, I was wrong. We should have QT_NO_REGULAREXPRESSION for PCRE + QRegularExpression. QRegExp should be disabled by QT_NO_REGEXP or QT_NO_DEPRECATED if it will be marked as deprecated. -- Tasuku Suzuki ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
