1. New "maxstatements" feature suggestion
Hello!
Occasionally I make mistakes with loops and my program grabs 99% CPU.
Entirely my fault of course. But, its hard to get the operating system
to break in and abort the program. Some languages allow a max statement
count to be specified so that the program halts itself as soon as this
max is reached. Any chance of this being added? Since euphoria has
profiling, there is a statement counter in place to check against, yes?
Regards
Alan
2. Re: New "maxstatements" feature suggestion
Alan Oxley wrote:
>
> Hello!
> Occasionally I make mistakes with loops and my program grabs 99% CPU.
> Entirely my fault of course. But, its hard to get the operating system
> to break in and abort the program. Some languages allow a max statement
> count to be specified so that the program halts itself as soon as this
> max is reached. Any chance of this being added? Since euphoria has
> profiling, there is a statement counter in place to check against, yes?
Doing this would slow every program down. A better way which I sometimes use is
to simply place a ?1 at the top of the program. That way you can kill a
misbehaving program using Ctrl C. If you've got trace(3) running it will even
tell you where it got stuck.
Regards,
Pete
3. Re: New "maxstatements" feature suggestion
Pete Lomax wrote:
> Doing this would slow every program down. A better way which I sometimes use
> is to simply place a ?1 at the top of the program. That way you can kill a
> misbehaving
> program using Ctrl C. If you've got trace(3) running it will even tell you
> where
> it got stuck.
>
> Regards,
> Pete
Your suggestion works for the programmer while developing/debugging.
I'd like a solution where a enduser won't have his machine locked
up due to a bug in a GUI. Users put in strange parameters/criteria that I don't
think of, and its therefore not covered.
Regards
Alan
4. Re: New "maxstatements" feature suggestion
Alan Oxley wrote:
>
> Your suggestion works for the programmer while developing/debugging.
> I'd like a solution where a enduser won't have his machine locked
> up due to a bug in a GUI. Users put in strange parameters/criteria that I
> don't
> think of, and its therefore not covered.
>
Alan:
Simply put a constant at the top of your program.
constant
MAXLOOP = 10
integer ctr
Then when you have a loop that your concern about
put a test to exit or abort().
if MaxLoop = ctr then exit else ctr += 1 end if
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
5. Re: New "maxstatements" feature suggestion
Bernie Ryan wrote:
> Alan:
>
> Simply put a constant at the top of your program.
>
> constant
> MAXLOOP = 10
> integer ctr
>
> Then when you have a loop that your concern about
> put a test to exit or abort().
>
> if MaxLoop = ctr then exit else ctr += 1 end if
>
True, this can be done. But to be safe, it would have to be coded
wherever you suspect there might be a problem. And in the other
places that you didn't suspect? Or put it in *every* loop?
I admit I'm lazy. Why not get the language to help me out
with a builtin. As Pete says there will be overhead though;
so why not have it as an optional like "with profile"
"with type_check" "with trace"? These also have overhead but you
turn them off when convenient.
Regards
Alan
6. Re: New "maxstatements" feature suggestion
Alan Oxley wrote:
> Bernie Ryan wrote:
> > Alan:
> >
> > Simply put a constant at the top of your program.
> >
> > constant
> > MAXLOOP = 10
> > integer ctr
> >
> > Then when you have a loop that your concern about
> > put a test to exit or abort().
> >
> > if MaxLoop = ctr then exit else ctr += 1 end if
> >
>
> True, this can be done. But to be safe, it would have to be coded
> wherever you suspect there might be a problem. And in the other
> places that you didn't suspect? Or put it in *every* loop?
> I admit I'm lazy. Why not get the language to help me out
> with a builtin. As Pete says there will be overhead though;
> so why not have it as an optional like "with profile"
> "with type_check" "with trace"? These also have overhead but you
> turn them off when convenient.
Maybe you just should design your loops more carefully? 
Regards,
Juergen
7. Re: New "maxstatements" feature suggestion
Juergen Luethje wrote:
>
> Alan Oxley wrote:
>
> > Bernie Ryan wrote:
> > > Alan:
> > >
> > > Simply put a constant at the top of your program.
> > >
> > > constant
> > > MAXLOOP = 10
> > > integer ctr
> > >
> > > Then when you have a loop that your concern about
> > > put a test to exit or abort().
> > >
> > > if MaxLoop = ctr then exit else ctr += 1 end if
> > >
> >
> > True, this can be done. But to be safe, it would have to be coded
> > wherever you suspect there might be a problem. And in the other
> > places that you didn't suspect? Or put it in *every* loop?
> > I admit I'm lazy. Why not get the language to help me out
> > with a builtin. As Pete says there will be overhead though;
> > so why not have it as an optional like "with profile"
> > "with type_check" "with trace"? These also have overhead but you
> > turn them off when convenient.
>
> Maybe you just should design your loops more carefully?
>
> Regards,
> Juergen
Ah, but he's said he's lazy. All he really has to do is say there's no solution,
then Matt'll find it.
Chris
9. Re: New "maxstatements" feature suggestion
Being serious for a minite
Ask yourselves this question, honestly please:
If the maxstatement feature was already there, would you never use it?
Don't forget Robert's mantra about Euphoria being easy and faster to code
and debug. If this was not what nearly all of us want, how come we
are not coding in binary only ? Cos we are lazy? Come on guys!
If the machine can help us then why not let it.
Cheers
Alan
10. Re: New "maxstatements" feature suggestion
- Posted by Juergen Luethje <j.lue at gmx.de>
Jun 08, 2007
-
Last edited Jun 09, 2007
Alan Oxley wrote:
> Being serious for a minite
> Ask yourselves this question, honestly please:
> If the maxstatement feature was already there, would you never use it?
Seriously, I never have missed such a function.
> Don't forget Robert's mantra about Euphoria being easy and faster to code
> and debug. If this was not what nearly all of us want, how come we
> are not coding in binary only ? Cos we are lazy? Come on guys!
> If the machine can help us then why not let it.
My serious view is, that there are some jobs where care really matters,
e.g. surgery, driving aeroplanes and programming. Such a maxstatement
feature will not free us from the task to be careful. There actually
should be extreme few possibilities for the user to put a program into
an endless loop. In this few cases I think it is OK to kill the program
by using the task manager.
Regards,
Juergen
11. Re: New "maxstatements" feature suggestion
- Posted by don cole <doncole at pacbell.net>
Jun 08, 2007
-
Last edited Jun 09, 2007
Alan Oxley wrote:
>
> Hello!
> Occasionally I make mistakes with loops and my program grabs 99% CPU.
> Entirely my fault of course. But, its hard to get the operating system
> to break in and abort the program. Some languages allow a max statement
> count to be specified so that the program halts itself as soon as this
> max is reached. Any chance of this being added? Since euphoria has
> profiling, there is a statement counter in place to check against, yes?
>
> Regards
> Alan
Hello Alan,
If you are getting stuck in a loop, is it always the same loop?
If so I like Juergen suggestion of re-evaluating the loop. IMHI I see no need to
restructure the language.
Don Cole
12. Re: New "maxstatements" feature suggestion
- Posted by Derek Parnell <ddparnell at bigpond.com>
Jun 08, 2007
-
Last edited Jun 09, 2007
Alan Oxley wrote:
>
> Being serious for a minite
> Ask yourselves this question, honestly please:
> If the maxstatement feature was already there, would you never use it?
That is correct. I would not use it. Not out of principle but simply because I
wouldn't need to. I have never needed it in the past and I can't see why things
would suddenly change.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
13. Re: New "maxstatements" feature suggestion
Alan Oxley wrote:
>
> Being serious for a minite
> Ask yourselves this question, honestly please:
> If the maxstatement feature was already there, would you never use it?
Erm, yes! (I would NEVER use it!).
Quite obviously, within my little baby Edita, there are some routines that say
800 calls are serious brew a cuppa/watch a film/hope it is finished by the time I
wake up, and some where 10,000,000 *must* happen while I blink.
You ain't ever gonna better manual "for i=1 to maxstatement do" wrappers.
Regards,
Pete
14. Re: New "maxstatements" feature suggestion
Pete Lomax wrote:
>
> Alan Oxley wrote:
> >
> > Being serious for a minite
> > Ask yourselves this question, honestly please:
> > If the maxstatement feature was already there, would you never use it?
>
> Erm, yes! (I would NEVER use it!).
> Quite obviously, within my little baby Edita, there are some routines that say
> 800 calls are serious brew a cuppa/watch a film/hope it is finished by the
> time
> I wake up, and some where 10,000,000 *must* happen while I blink.
>
> You ain't ever gonna better manual "for i=1 to maxstatement do" wrappers.
>
> Regards,
> Pete
While you are definitely right, I think Eu lacks some features that would be
very helpful during development and testing, but would have to be diabled
in actual code as they'd affect performance. We already have profiling.
Things like maxstatements, assertions and other would be useful, as long as
they can be turned off at will, because of that speed issue.
That's how Eiffel works, for example. Specifically, loops there have optional
"variant" and "invariant" clauses. "invariant" is a boolean expression that
causes an exception if checked wrong on iteration start. "variant" is an
integer expression which should decrease between iterations starts and remain
positive, else bombs out. The clauses are optional, and even if you code
them, they do something only if assertion checking is turned on at the
highest level. Otherwise, they just act as comments - comments that do
something when you turn them on. And turning them on is done in a control
file, so there's no code editing and forgetting to comment/uncomment.
I really love that aspect of the language.
Just an idea of things Eu could usefully borrow.
CChris
15. Re: New "maxstatements" feature suggestion
You could use euphoria's multitasking to control how much CPU a loop takes. I
used the tasking routines all the time now. (Thanks Rob for adding that
feature! I don't know how much people use tasking, but i sure do.)
Another thing you can do is use nanosleep() to slow down the loop.
It is in this library: http://www.rapideuphoria.com/idle.e
~Ryan W. Johnson
Fluid Application Environment
http://www.fluidae.com/
[cool quote here, if i ever think of one...]
16. Re: New "maxstatements" feature suggestion
Thanks.
The other alternatives suggested make sense too. My issue is that if the
loop that you are suspicious of, is a loop where you don't know how
many iterations there is going to be up front. Eg, a loop where you
are reading records from a file of unknown length. Then your
suggestion or the maxstatements would be best.
Putting in my own loop counter seems the easiest all round.
Thanks guys,
Alan Oxley
17. Re: New "maxstatements" feature suggestion
Ryan W. Johnson wrote:
>
> You could use euphoria's multitasking to control how much CPU a loop takes. I
> used the tasking
> routines all the time now. (Thanks Rob
> for adding that feature! I don't know how much people use tasking, but i sure
> do.)
>
> Another thing you can do is use nanosleep() to slow down the loop.
> It is in this library: <a
> href="http://www.rapideuphoria.com/idle.e">http://www.rapideuphoria.com/idle.e</a>
>
> ~Ryan W. Johnson
>
> Fluid Application Environment
> <a href="http://www.fluidae.com/">http://www.fluidae.com/</a>
>
> [cool quote here, if i ever think of one...]
You can also use hirestime.e in the archive to bypass the millisecond
resolution issue under Windows. At least when the CPU is Pentium-class.
Merging this with idle.e could provide a good xplat library. Does Linux's
nano_sleep() work right on older CPUs?
CChris
PS: Ryan, would you be interested by a coauthored merger?
