Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Aplication crashes - not sure why

 [1/8] from: james:mustard at: 14-Apr-2002 13:31


Hi folks, I have been working on a database front end in REBOL/View and while testing the display aspects for subform switching have managed to get rebol to crash (in Windows2000) on a regular basis. I tried using recycle but it doesnt seem to recycle fast enough.. The script is at: http://www.mustard.co.nz/rebol/main.r To reproduce the behaviour just click back and foward between the "DEBTOR ENQUIRIES", "LOAD NEW CASES" and "PAYMENT LOADING" buttons. While rapid switching is not a daily occurrance it could happen and so is therefore of some concern. The eventual goal is to be able to reproduce Microsoft Access's form behaviour in Rebol for a more cross-platform solution. PS: The test machine is a AMD 1.4 with 384mb RAM. Please excuse the gradients (or remove them) if it performs slowly. Regards, James

 [2/8] from: sunandadh:aol at: 14-Apr-2002 4:42


James:
> Hi folks, I have been working on a database front end in REBOL/View and > while testing the display aspects for subform switching have managed to get > rebol to crash (in Windows2000) on a regular basis
Nice looking buttons! It's them waits in the action facets. You are creating simultaneous threads and rebol don't like that much as yet. Check the list archives for subject "multiple threads crash". Holger wrote in that thread: << Calling 'wait from within an awake handler is not really supported. It is bad style anyway, because in event-driven systems event handlers are not allowed to block. That's because blocking in an event handler makes programs extremely difficult to debug, in particular if the list of handlers (meaning, faces) is modified while another handler is suspended. The problem is that all those suspended handlers carry hidden "context" around with them, and you might end up with an "old" handler being woken up from suspension after the face it has been associated with has already been removed from the pane, by a different handler. Other complications are possible, as well. It is extremely difficult to foresee all of these side effects, so programs that use tricks like that are bound to be buggy and full of race conditions. As for the crashes, this is the result of a limit on recursion in current REBOL versions. Should be eliminated in one of the next version.
>>
But you probably do want to keep the waits. That way a user can interrupt a long-running action. Change them to wait 0, and you now have these two issues: 1. A long running process (such as running a monthly report) may create multiple threads -- the user can click any other button while the action is underway -- or even click multiple times on the same button. To handle that, you need a global variable that tells you if you have an action facet running. Check it at the start of every action. Return immediately if it is true, otherwise set it and continue. Remember to unset it at all the return points or the whole application gets blocked. 2. For good user relations (and the reason for wait 0 is), the user needs a way to cancel a long-running action. My application (which looks similar to your, but with less snazzy buttons) has a "Cancel button". If the user clicks that, it sets a global "stop it" variable. Long-running action facets check for this variable at regular intervals. Sunanda.

 [3/8] from: gchiu:compkarori at: 14-Apr-2002 21:06


On Sun, 14 Apr 2002 13:31:32 +1200 "James Marsden" <[james--mustard--co--nz]> wrote:
> Hi folks, I have been working on a database front end in > REBOL/View and > while testing the display aspects for subform switching > have managed to get > rebol to crash (in Windows2000) on a regular basis. I
IOS also crashes under XP. -- Graham Chiu

 [4/8] from: james:mustard at: 14-Apr-2002 22:54


Sunanda wrote:
> Nice looking buttons!
Thanks ;-) They are temporary until I create aqua style glass buttons with a greyscale effect.
> It's them waits in the action facets. You are creating simultaneous
threads
> and rebol don't like that much as yet. >
Ah hah.. Bad design on my part.
> Check the list archives for subject "multiple threads crash". Holger wrote
in
> that thread: <snip>
Hmm.. I am used to the VisualBasic/Access event model where i can use local static variables within event handlers to act as blocks to avoid event collisions. eg: sub event_ontimer() static busy as boolean if busy then exit sub busy = true ... event code ... busy = false end sub The waits were an attempt to stop repeated event firing - I assumed (wrongly) that the event would be locked. Of course it wouldn't be on hindsight and I would need to implement a blocker system like I traditionally do in VB/Access. As i was unsure how to apply static local variables in rebol (without building objects to store them in..) I wrongly chose to use wait. Perhaps it would just be tidier to build an object and store blocking flags for each event...
> To handle that, you need a global variable that tells you if you have an > action facet running. Check it at the start of every action. Return > immediately if it is true, otherwise set it and continue. Remember to
unset
> it at all the return points or the whole application gets blocked.
I prefer localised blockers to avoid application lockup and easier maintenance.
> 2. For good user relations (and the reason for wait 0 is), the user needs
a
> way to cancel a long-running action. My application (which looks similar
to
> your, but with less snazzy buttons) has a "Cancel button". If the user
clicks
> that, it sets a global "stop it" variable. Long-running action facets
check
> for this variable at regular intervals.
Hmm.. probably a good idea that - having a global die flag for action handlers. Will give it a go. Regards, James

 [5/8] from: james:mustard at: 14-Apr-2002 23:09


Well, its all fixed now :) Amazing how you miss the small things sometimes :) Here is the method I implemented: box with [block-engage: false] feel [ engage: func [f a e][ if not f/block-engage [ f/block-engage: true if a = 'down [f/effect: [gradient 1x0 150.150.150 128.255.128] show f wait 0] if a = 'up [f/effect: [gradient 1x0 150.150.150 196.196.196] show f wait 0] f/block-engage: false ] ] ] For a link to the now working code go here: www.mustard.co.nz/rebol/fixed-main.r

 [6/8] from: sunandadh:aol at: 14-Apr-2002 8:36


James:
> > It's them waits in the action facets. You are creating simultaneous > threads > > and rebol don't like that much as yet. > > > > Ah hah.. Bad design on my part
Not really -- the threading model is neither well explained nor (consequently) well-understood. And, with a bit of luck (given Holger's hints), it'll change for the better in a new release. You had no way of knowing, and were fortunate that your testing caught the problem so quickly. I've spun off the cliff numerous times coding fast round a tight Rebol learning curve. It's part of the charm of the language -- if you have the luxury to spend that amount of time learning from mistakes. Sunanda.

 [7/8] from: holger::rebol::net at: 14-Apr-2002 9:26


On Sun, Apr 14, 2002 at 09:06:56PM +1200, Graham Chiu wrote:
> On Sun, 14 Apr 2002 13:31:32 +1200 > "James Marsden" <[james--mustard--co--nz]> wrote:
<<quoted lines omitted: 4>>
> > rebol to crash (in Windows2000) on a regular basis. I > IOS also crashes under XP.
Not here. If you get crashes in IOS then please report them through the bug report mechanism in IOS. -- Holger Kruse [kruse--nordicglobal--com]

 [8/8] from: gchiu:compkarori at: 16-Apr-2002 18:46


On Sun, 14 Apr 2002 09:26:07 -0700 Holger Kruse <[holger--rebol--net]> wrote:
> > > have managed to get > > > rebol to crash (in Windows2000) on a regular basis.
<<quoted lines omitted: 4>>
> them through > the bug report mechanism in IOS.
Ooops, missed a comma. I meant to say, James' code also crashes in IOS running in XP. -- Graham Chiu

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted