Re: [Development] Mutex future directions

2012-05-19 Thread lars.knoll
A few comments from my side: * I am not a big fan of inlining the public classes neither. It feels a bit like over-optimizing at the wrong place. Reason is that this might make it a impossible later on to refactor our code. * It's ok to have some low level inline class for internal use if that

Re: [Development] Mutex future directions

2012-05-19 Thread Thiago Macieira
On sábado, 19 de maio de 2012 00.36.56, Olivier Goffart wrote: On Friday 18 May 2012 23:25:47 Thiago Macieira wrote: Which non-negligible performance penalty are you takling about here? The need to allocate memory and do the test-and-set loop for setting the private. There is no memory

Re: [Development] Mutex future directions

2012-05-19 Thread Thiago Macieira
On sábado, 19 de maio de 2012 07.30.56, lars.kn...@nokia.com wrote: * it would be good to see how much of a real world (ie. not with artificial benchmarks) difference you get due to inlining the mutex code. Is it really relevant? Here's a suggestion for one: the Creator C++ parser. I remember

Re: [Development] Mutex future directions

2012-05-19 Thread Thiago Macieira
On sábado, 19 de maio de 2012 10.26.03, Thiago Macieira wrote: But fast uncontended case is critical because it allows the use of mutex in part that might or not be used with threads. Example: QObject. We need to put mutexes while emiting a signal because maybe it is used in multiple

[Development] mkcal+qml qorganizer

2012-05-19 Thread Nicola De Filippo
Hi, I'm developing a calendar with QML, with qorganizer mkcal backend. I noticed that if I use backend memory and i save a OrganizerEvent with OrganizerModel of QML is all ok, but if I use mkcal not save anything. i'm forced to save invoking a C + + function. I searched the bugs, but I have not

Re: [Development] Mutex future directions

2012-05-19 Thread Olivier Goffart
On Saturday 19 May 2012 07:30:56 lars.kn...@nokia.com wrote: A few comments from my side: * I am not a big fan of inlining the public classes neither. It feels a bit like over-optimizing at the wrong place. Reason is that this might make it a impossible later on to refactor our code. In

Re: [Development] Mutex future directions

2012-05-19 Thread Olivier Goffart
Hi, Regarding valgrind: *) On debug build, nothing is inlined. *) If we keep it inline, then we would just need a patch like this [1] Regarding Transactional memory: *) Very interesting *) Notice the end of section 8.2.1: Improper use of hints will not cause functional bugs though it

Re: [Development] Qt 5.0 beta and final timelines

2012-05-19 Thread Laszlo Papp
When would alpha 2 happen? I am also interested in that information. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] SIC: QAbstractPrintDialog QAbstractPageSetupDialog

2012-05-19 Thread John Layt
On Wednesday 16 May 2012 23:49:42 John Layt wrote: Actually removing the abstract base class is just a case of s/QAbstractPrintDialog/QPrintDialog and tweaking the constructors, as the class is not really abstract, the only virtual method is exec(), nothing else gets reimplemented in the

Re: [Development] Mutex future directions

2012-05-19 Thread Charley Bay
snip, QMutex future-direction-discussion I've followed this very technical discussion from the beginning-- impressive array of topics. Thanks to all digging into this, and great thanks to Thiago for opening the issue. I have a question on the point of recursive-locks: I understand

Re: [Development] Mutex future directions

2012-05-19 Thread Thiago Macieira
On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote: Hi, Regarding valgrind: *) On debug build, nothing is inlined. *) If we keep it inline, then we would just need a patch like this [1] -fno-inline doesn't help because of -fvisibility-inlines-hidden. The call cannot be rerouted

Re: [Development] Mutex future directions

2012-05-19 Thread Thiago Macieira
On sábado, 19 de maio de 2012 10.48.22, Charley Bay wrote: snip, QMutex future-direction-discussion I've followed this very technical discussion from the beginning-- impressive array of topics. Thanks to all digging into this, and great thanks to Thiago for opening the issue. I have a

[Development] Documentation Session in QtCS 2012

2012-05-19 Thread Sivan Greenberg
Hello All, As I'm keen on contributing to improve out documentation, I took the liberty to put up on the wiki a session outline for what I hope will be a productive doc sessions including (if time permits) thoughts of beyond 5.0 and following hack sessions to get some of the new decisions

Re: [Development] [Interest] mkcal+qml qorganizer

2012-05-19 Thread xizhi . zhu
What platform are you using? Have you waited until the saving is done? -- Sent from my Nokia N9 On 19.5.2012 16:44 Nicola De Filippo wrote: Hi, I'm developing a calendar with QML, with qorganizer mkcal backend. I noticed that if I use backend memory and i save a OrganizerEvent with

Re: [Development] Mutex future directions

2012-05-19 Thread Olivier Goffart
On Saturday 19 May 2012 19:05:58 Thiago Macieira wrote: On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote: Hi, Regarding valgrind: *) On debug build, nothing is inlined. *) If we keep it inline, then we would just need a patch like this [1] -fno-inline doesn't help

Re: [Development] Mutex future directions

2012-05-19 Thread Olivier Goffart
On Sunday 20 May 2012 02:17:53 Olivier Goffart wrote: You can see it works by trying the attached wrapper.c Actually, I realize my implementation of the hook for tryLock was wrong as i forgot the return value. Fixed, just in case someone wants to use it. -- Olivier Woboq - Qt services and

[Development] How to let QtCore and QtGui etc. static linked against with one precompiled object

2012-05-19 Thread song.7.liu
Hi, I want to let QtCore and QtGui etc. modules static linked against with one pre-compiled achieve object. So could someone help how to modify the qmake.conf under the related mkspecs folder ? Many thanks ;) Thanks, Song ___ Development mailing