OpenEuphoria

1. v2.5 suggestions

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 22, 2004
• 556 views

How about a specific constant we can use with abort() that will trigger the
crash routines?  abort(1/0) will work, I suppose, but abort(FATAL_ERROR) might be
more elegant.  Also, a way to reset or re-order multiple crash routines would
probably come in handy.

And let's get routine_id()'s for the built-in functions for the final v2.5
already.  This can't possibly be a very big deal at all...

3. Re: v2.5 suggestions

• Posted by "Mike Sabal" <Sabal.Mike at notations.com> Nov 22, 2004
• 556 views

>>> guest at RapidEuphoria.com 11/22/2004 10:22:52 AM >>>
> And let's get routine_id()'s for the built-in functions for the final
v2.5 already.
>  This can't possibly be a very big deal at all...

I know, it sounds simple, but there are some complications.
I'll look at it again.
----------------------------------
One possible solution is wrap the built-in functions you need to
routine_id.  I can only imagine a handful of reasons why you would need
this (a roundabout way of executing strings being one of them), since
all the built-ins are above any written code.  It might look something
like this:

atom putsID
global procedure id_puts_screen(sequence s)
  puts(1,s)
end procedure
putsID = routine_id("id_puts_screen")

call_proc(putsID,{"Testing."})

Using routine_ids for built-ins would be slower than calling them
directly; but if it were really needed, perhaps a standard include of
all built-ins wrapped would answer the need.

HTH,
Michael J. Sabal

5. Re: v2.5 suggestions

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 23, 2004
• 546 views

Robert Craig wrote:
> 
> Andy Serpa wrote:
> > How about a specific constant we can use with abort() that will trigger the
> > crash routines?
> >  abort(1/0) will work, I suppose, but abort(FATAL_ERROR) might be more
> >  elegant.  Also,
> > a way to reset or re-order multiple crash routines would probably come in
> > handy.
> 
> Thanks for the suggestion.
> When I get more feedback from several people, I'll see what improvements
> can be made. I've used crash_routine() myself to e-mail ex.err's 
> and other debug info from remote CGI programs. A translated program 
> that dies, normally just reports a machine-level exeception, with
> no traceback or variable dump, but with crash_routine() it can 
> output useful debug info before dying. There are probably many
> other useful things you can do.
> 

It occurred to me as I was setting up some crash_routine()'s that most of the
time for myself I won't be doing any special error handling, just doing cleanup
(for .dlls and such) and I really would want the same routines called on ANY
program exit, crash or not.  So I created a simple similar system for use with
abort():


------------------------
-- abort.e

without warning
-- provide abort routines just like crash routines
-- can be called on exit w/ abort
-- rid = abort_routine, will be passed abort exit code,
-- and should return 0 to keep the chain going
-- or nonzero to do a real abort() immediately

sequence abort_rids
abort_rids = {}

global procedure abort_routine(integer rid)
	-- make sure we include each routine only once
	if not find(rid,abort_rids) then
		abort_rids &= rid
	end if
end procedure



-- rewrite abort --
procedure my_abort(integer exit_code)
	abort(exit_code)
end procedure

integer abort_in_progress
abort_in_progress = 0
global procedure abort(integer exit_code)

	-- if already in the middle of an abort 
	-- and we get another one, exit immediately
	if abort_in_progress = 1 then
		my_abort(exit_code)
	end if
	abort_in_progress = 1

	-- call abort routines
	for i = 1 to length(abort_rids) do
		-- each abort_routine may check the exit_code if
		-- desired to handle normal or abnormal exit
		if call_func(abort_rids[i],{exit_code}) != 0 then
			my_abort(exit_code)
		end if
	end for
	my_abort(exit_code)
end procedure
with warning

--------------------------------


Now I set most of my cleanup routines to be both abort_routine()s and
crash_routine()s.  And make sure I put abort(0) at the end of the program, even
if it would exit there anyway.

 
> > And let's get routine_id()'s for the built-in functions for the final v2.5
> > already.
> >  This can't possibly be a very big deal at all...
> 
> I know, it sounds simple, but there are some complications.
> I'll look at it again.

Since they are built-ins, they could have permanent, fixed id numbers, no? 
Also, you don't have to do ALL the built-ins -- there is probably no particular
use to have routine_ids for low-level stuff like call(), poke(), and routine_id()
itself.  However, the "library-type" functions like log(), arctan(), etc. should
have ids.  length() would also be useful.  The i/o functions might be useful for
some, although I wouldn't use them.

There are a few general uses for routine_id() that I can think of:

A) for forward referencing functions not declared yet, or for mutually recursive
function calling (two functions that each call each other)

B) for win32lib type libraries where you set up user-defined "handlers"

C) for interpreters, expression evaluators, genetic programming, etc.

A & B probably don't need routine_ids for the built-ins because they deal with
user-defined functions.  C definitely does, and is the type of stuff I do all the
time.  Yes, you can wrap them, but then you've got more overhead for what is
already going to be "an interpreter being interpreted by an interpreter".  Speed
is at a premium with this type of thing.  Doing C-type stuff is also the reason
I'm always clamoring for variable_id() -- it would literally EXPLODE the
capabilities of Euphoria.  And I know it can be implemented because Matt Lewis
and others have already done it.  It also would fill (along with routine_ids for
the built-ins) what I consider "logic holes" in Euphoria -- things you would
expect to be there based on what is there now, but just aren't simply because you
haven't implemented them, not for any logical reason...