Hi Thiago,
Ah, I tottally agree, then. I will stop this thread. Because even if
it's very interesting is turning a little bit off-topic.
If you are in IRC we can talk since I'm very interested in this kind of
design rules.
Best regard
And thank you a lot!
On 04/10/17 20:04, Thiago Maciei
On Wednesday, 4 October 2017 09:30:46 PDT Thiago Macieira wrote:
> It would have, if you hadn't explicitly cast the difference away. A lot of
> Glib-using code does that because of GCallback and G_CALLBACK.
>
> Avoid those like the plague, except for functions that really take no
> arguments and r
Thiago,
I should say that even with my error causing me havok of hours destroyed.
The callback way is good enough to be used, I don't know why you say
"Any other use is flawed by design". But that's another discussion.
I think you gave great insights of the Framework, debugging and where to
On Wednesday, 4 October 2017 09:24:03 PDT Gonzalo Aguilar Delgado wrote:
> typedef gboolean (*SG64ZeroMQHandler)(SG64ZeroMQ* mq, ThriftStruct*
> message, GError **error);
>
> instead
>
> typedef gboolean (*SG64ZeroMQHandler)(SG64ZeroMQ* mq, ThriftStruct*
> message, gpointer data, GError **error);
On Wednesday, 4 October 2017 08:57:07 PDT Thiago Macieira wrote:
> This variable is wrong. The shared_null in Qt 5 has a counter always equal
> to 0. It should never grow from it, so 299 and 3 are definitely wrong. The
> debugging information is coming from Qt 4 because of the presence of
> "array"
Thiago, Konstantin,
You are both great. Indeed the problem was that pesky pointer. It's so
bizarre that it happened to me... Soo long.
There's something I was aware but didn't really realized. Indeed
Konstantin when I made the pointer a static cast to the class, it
doesn't matter what goes i
On Wed, Oct 4, 2017 at 6:50 PM, Gonzalo Aguilar Delgado <
gagui...@aguilardelgado.com> wrote:
> Hi Konstantin,
>
> That's something I was not aware of.
>
You're explicitly casting an opaque to an object pointer, and there can be
literally anything behind that address, the compiler has no way of kn
On Wednesday, 4 October 2017 08:41:32 PDT Gonzalo Aguilar Delgado wrote:
> Hello Thiago,
>
> Hope you can see something...
Thanks.
Did you also run this under valgrind? Maybe using a prelinker? Some pointers
are funny.
> #0 0x761d7cec in QMetaObject::activate(QObject*, QMetaObject
> c
Hi Konstantin,
That's something I was not aware of. So it's the best clue I heard today.
Oh men!!! You are so great
My Class address is 55a7ebe0
Received Class address is d15dddf0
Do you think that registering the address using this pointer here is
wrong? Or it's just that there's a
On Wed, Oct 4, 2017 at 6:39 PM, Gonzalo Aguilar Delgado <
gagui...@aguilardelgado.com> wrote:
> Yes it is. Because the code of the function starts to execute. In the
> example the processMessage. Until the operation stops on emit and the
> program crash.
>
emit requires you to have a valid `this`
Hello Thiago,
Hope you can see something...
Thread 9 (Thread 0x7fffd15de700 (LWP 24773)):
#0 0x761d7cec in QMetaObject::activate(QObject*, QMetaObject
const*, int, void**) (sender=0x7fffd15dddf0, m=,
local_signal_inde
Hello Kostantin,
Yes it is. Because the code of the function starts to execute. In the
example the processMessage. Until the operation stops on emit and the
program crash.
Quite nasty.
It's something about threading... But what?
On 04/10/17 17:34, Konstantin Shegunov wrote:
This is the fir
Hi Thiago,
Forget it. I removed it since long ago. I'm using QueuedConnection
everywhere.
But still have troubles in all places where threading is involved. I'm
truly desperate after 3 days working on fixing this. I've never had this
kind of troubles with any framework I used before. In any
On Wednesday, 4 October 2017 08:32:03 PDT Gonzalo Aguilar Delgado wrote:
> The inferior stopped because it received a signal from the operating system.
>
> Signal name :
>
>
>
> SIGSEGV
Can you paste the backtrace from all threads when that signal happens? Right-
click the funtion stack in Qt
This is the first line where you dereference the this pointer from what I
could see, isn't it?. Are you sure you're getting a valid object? I mean
are you sure MQMessageManager* self = static_cast(data); is
what you think it is?
___
Interest mailing list
On Wednesday, 4 October 2017 06:45:09 PDT Tony Rietwyk wrote:
> I don't think the documentation is clear enough, but my assumption is
> that emitting a signal connected with BlockingQueuedConnection can only
> be done in a thread created by QThread that has called QThread.exec in
> its run override
Hello,
I moved from that solution that's not working to another approach I've
used in other projects. It's like the pooled mechanism used by Qt to
send signals. I've created a Queue with QQueue.
The callback only has to put a new message to be processed in the queue.
The class that was previ
Hello Sergio,
Thank you a lot for asking. A test case will be great but it would mean
to do a pthread thread and all the other stuff (callbacks from c and so
on) so at this time is quite difficult to craft one.
I've posted relevant code in pastie:
https://pastebin.com/ruHutpDX
I don't know
Hi Tony,
Forget about the blockingqueuedconnection it never does the emit. So
will never arrive to the target. You can set any kind of delivery that's
supported by QT it will fail a lot before. While doing the emit. This
value was left behind just to test different things. The real queue used
On Wed, Oct 4, 2017 at 12:08 PM, Gonzalo Aguilar Delgado
wrote:
> Hello,
>
> I'm facing a problem that don't know how to tackle. I created a library that
> runs on C. It's based on callbacks and it seems to work in other projects
> well.
Hi, last time we spoke you were finishing a test case that
Hi Gonzalo,
I don't think the documentation is clear enough, but my assumption is
that emitting a signal connected with BlockingQueuedConnection can only
be done in a thread created by QThread that has called QThread.exec in
its run override. Does your callback thread really have to wait for t
Hello,
Ok. But what does it has to do with the emit signal? It should not crash
even if the signal is emitted from worker thread.
I find not useful this without an explanation on how to make it work and
why. But thank you for your response.
On 04/10/17 14:12, Harish Surana wrote:
From Qt
>From Qt Documentation
http://doc.qt.io/qt-5/thread-basics.html#gui-thread-and-worker-thread
"As mentioned, each program has one thread when it is started. This thread
is called the "main thread" (also known as the "GUI thread" in Qt
applications). The Qt GUI must run in this thread. All widgets a
Hello,
I'm facing a problem that don't know how to tackle. I created a library
that runs on C. It's based on callbacks and it seems to work in other
projects well.
When connecting to Qt and classes I found a couple of problems that now
they are extending.
It seems that I cannot set a callb
24 matches
Mail list logo
