Hi all, I'm trying to write a binding of wxWidgets 3.0 into Pharo 3.0. I wrote some glue-code to implement a C interface to wxWidgets (that is C++). I can open windows on the screen of my Winxp-box, I place buttons into them, I change position and size of the windows and I can attach BlockClosures on MOVE and CLICK events. Wow: if a cow-boy like me is able to do that, it means NativeBoost is really magic! Here the question. Sometime Pharo crashes. it happens when an event occurs (and a st callback was attached on). In some sessions Pharo stay alive, in some other it dies. What should I do? Re-compile a vm and run Pharo in debug mode? I'm not sure I could understand the reason of the crash... Thanks paolo --- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com
On 12 January 2014 19:02, paolo.bernardi.67@gmail.com < paolo.bernardi.67@gmail.com> wrote:
Hi all,
I'm trying to write a binding of wxWidgets 3.0 into Pharo 3.0. I wrote some glue-code to implement a C interface to wxWidgets (that is C++).
I can open windows on the screen of my Winxp-box, I place buttons into them, I change position and size of the windows and I can attach BlockClosures on MOVE and CLICK events. Wow: if a cow-boy like me is able to do that, it means NativeBoost is really magic!
Here the question. Sometime Pharo crashes. it happens when an event occurs (and a st callback was attached on). In some sessions Pharo stay alive, in some other it dies.
What should I do? Re-compile a vm and run Pharo in debug mode? I'm not sure I could understand the reason of the crash...
usually nobody can. :) There's no debugging except one provided by smalltalk debugger and very low-level like gdb debugger for C. And you basically alone there :)
All i can say that callbacks for handling window events need special handling: - you basically should prevent VM to do event handling during handling of event by callback. Another problem is that then if you put halt into code which handling events, you will halt the image and won't be able to use it (like in smalltalk debugger). For details, you can read thread: http://lists.gforge.inria.fr/pipermail/pharo-project/2012-September/069448.h... parts of this plan is realized right now, but it is not yet ready for release. Thanks
paolo
--- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com
-- Best regards, Igor Stasenko.
Anybody know where to find what the acceptable arguments to --trace on the command line are, and what each means? So far, I've tried: --trace Lots of output --trace=0 No output --trace=1 Looks maybe the same as --trace with no argument --trace=2 No output --trace=3 A whaling big lot of very interesting output Slightly better descriptions of these would be nice. :-) Thanks, -Martin
On Sun, Jan 12, 2014 at 11:43 AM, Martin McClure <martin@hand2mouse.com>wrote:
Anybody know where to find what the acceptable arguments to --trace on the command line are, and what each means?
So far, I've tried:
--trace Lots of output --trace=0 No output --trace=1 Looks maybe the same as --trace with no argument --trace=2 No output --trace=3 A whaling big lot of very interesting output
Slightly better descriptions of these would be nice. :-)
Cogit>>sendTrace: aBooleanOrInteger <doNotGenerate> "traceFlags is a set of flags. 1 => print trace (if something below is selected) 2 => trace sends 4 => trace block activations 8 => trace interpreter primitives 16 => trace events (context switches, GCs, etc) 32 => trace stack overflow 64 => send breakpoint on implicit receiver (Newspeak VM only)" traceFlags := aBooleanOrInteger isInteger ifTrue: [aBooleanOrInteger] ifFalse: [aBooleanOrInteger ifTrue: [6] ifFalse: [0]] -- best, Eliot
On 01/12/2014 03:26 PM, Eliot Miranda wrote:
On Sun, Jan 12, 2014 at 11:43 AM, Martin McClure <martin@hand2mouse.com <mailto:martin@hand2mouse.com>> wrote:
Anybody know where to find what the acceptable arguments to --trace on the command line are, and what each means?
So far, I've tried:
--trace Lots of output --trace=0 No output --trace=1 Looks maybe the same as --trace with no argument --trace=2 No output --trace=3 A whaling big lot of very interesting output
Slightly better descriptions of these would be nice. :-)
Cogit>>sendTrace: aBooleanOrInteger <doNotGenerate> "traceFlags is a set of flags. 1 => print trace (if something below is selected) 2 => trace sends 4 => trace block activations 8 => trace interpreter primitives 16 => trace events (context switches, GCs, etc) 32 => trace stack overflow 64 => send breakpoint on implicit receiver (Newspeak VM only)" traceFlags := aBooleanOrInteger isInteger ifTrue: [aBooleanOrInteger] ifFalse: [aBooleanOrInteger ifTrue: [6] ifFalse: [0]] --
Thanks Eliot, that helps a lot! Regards, -Martin
Il 12/01/2014 19.41, Igor Stasenko ha scritto:
All i can say that callbacks for handling window events need special handling: - you basically should prevent VM to do event handling during handling of event by callback.
Do I achieve that when starting in headless mode? (no ui, no messages...)
On 13 January 2014 00:08, paolo.bernardi.67@gmail.com < paolo.bernardi.67@gmail.com> wrote:
Il 12/01/2014 19.41, Igor Stasenko ha scritto:
All i can say that callbacks for handling window events need special
handling: - you basically should prevent VM to do event handling during handling of event by callback.
Do I achieve that when starting in headless mode? (no ui, no messages...)
nope. VM will still run event loop (in ioProcessEvents) and do more or less the same things. that is another reason, btw to bring event loop handling to image level.
-- Best regards, Igor Stasenko.
Il 13/01/2014 2.25, Igor Stasenko ha scritto:
On 13 January 2014 00:08, paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com> <paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com>> wrote:
Il 12/01/2014 19.41, Igor Stasenko ha scritto:
All i can say that callbacks for handling window events need special handling: - you basically should prevent VM to do event handling during handling of event by callback.
Do I achieve that when starting in headless mode? (no ui, no messages...)
nope. VM will still run event loop (in ioProcessEvents) and do more or less the same things. that is another reason, btw to bring event loop handling to image level.
-- Best regards, Igor Stasenko.
Could I prevent VM (as you say, Igor) do process events using primitiveEventProcessingControl? I tried hacking NBFFICallback >> pvtEnter:stackPointer:primitiveMethod: by disabling events before block execution and enabling them after callback termination. Pharo still works for a while, then crashes.
On 15 January 2014 17:58, paolo.bernardi.67@gmail.com < paolo.bernardi.67@gmail.com> wrote:
Il 13/01/2014 2.25, Igor Stasenko ha scritto:
On 13 January 2014 00:08, paolo.bernardi.67@gmail.com <mailto: paolo.bernardi.67@gmail.com> <paolo.bernardi.67@gmail.com <mailto: paolo.bernardi.67@gmail.com>> wrote:
Il 12/01/2014 19.41, Igor Stasenko ha scritto:
All i can say that callbacks for handling window events need special handling: - you basically should prevent VM to do event handling during handling of event by callback.
Do I achieve that when starting in headless mode? (no ui, no messages...)
nope. VM will still run event loop (in ioProcessEvents) and do more or less the same things. that is another reason, btw to bring event loop handling to image level.
-- Best regards, Igor Stasenko.
Could I prevent VM (as you say, Igor) do process events using primitiveEventProcessingControl?
I tried hacking NBFFICallback >> pvtEnter:stackPointer:primitiveMethod:
by disabling events before block execution and enabling them after callback termination.
Pharo still works for a while, then crashes.
nice try.. now i am out of ideas why else it would be crashing :)
-- Best regards, Igor Stasenko.
Il 15/01/2014 19.43, Igor Stasenko ha scritto:
On 15 January 2014 17:58, paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com> <paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com>> wrote:
Il 13/01/2014 2.25, Igor Stasenko ha scritto:
On 13 January 2014 00:08, paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com> <mailto:paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com>> <paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com> <mailto:paolo.bernardi.67@gmail.com <mailto:paolo.bernardi.67@gmail.com>>> wrote:
Il 12/01/2014 19.41, Igor Stasenko ha scritto:
All i can say that callbacks for handling window events need special handling: - you basically should prevent VM to do event handling during handling of event by callback.
Do I achieve that when starting in headless mode? (no ui, no messages...)
nope. VM will still run event loop (in ioProcessEvents) and do more or less the same things. that is another reason, btw to bring event loop handling to image level.
-- Best regards, Igor Stasenko.
Could I prevent VM (as you say, Igor) do process events using primitiveEventProcessingControl?
I tried hacking NBFFICallback >> pvtEnter:stackPointer:primitiveMethod:
by disabling events before block execution and enabling them after callback termination.
Pharo still works for a while, then crashes.
nice try.. now i am out of ideas why else it would be crashing :)
-- Best regards, Igor Stasenko.
maybe primitiveEventProcessingControl still could be the solution, vm should be already blinded (event processing disabled) when the cb is fired. My nice :) try, instead, just tried to blind vm when cb was already fired. Now I should try to blind vm _before_ any cb is fired. But I'm not sure wxWidgets has chances to ear (and processing) incoming OS events when the vm's thread is freezed.
participants (4)
-
Eliot Miranda -
Igor Stasenko -
Martin McClure -
paolo.bernardi.67＠gmail.com