OpenEuphoria

1. Robert Craig... One Wish Please

• Posted by jordah ferguson <jorfergie03 at yahoo.com> Jul 30, 2002
• 440 views

Hi Robert,

I have only one wish i would like added to exw. The ability to call a 
routine at crash time or in case of a windows exception, similar to what 
Matt lewis has done but built into the Euphoria interpreter/translator. 

     This is very handy when cleaning up GDI resources and Memory 
allocations made using API calls rather than EU Calls. Generally, this 
would help us clean-up and avoid reboots due to resource leaks.

How about that? WIN32 programmers back me up

jordah ferguson
Robert Craig wrote:
> Ricardo Forno writes:
> > 1) Comments C type: /* ... */ to ease commenting out code blocks.
> 
> I use F12 in ed to insert a bunch of comments.
> (Removing them is a bit harder.)
> In C, I find it strange that there are two different ways
> of commenting code. /* ... */ was the original way,
> then they added // to be more compatible with C++.
> I can never make up my mind which one to use, so
> I use both, almost at random. I'd rather stick to one
> consistent method.
> 
> > 2) Enhancements to the trace facility:
> > A) Variables should not be shown automatically but only at an user
> > request.
> 
> Why? What harm does it do to show a few variables on the screen
> automatically?
> 
> > B) Allow showing expressions, at least of the form x[i][k],
> > z[2..n], etc.
> 
> Yes, I'll probably do that in the next release.
> 
> > Better if all valid expressions were allowed, including
> > function calls.
> 
> True, but unfortunately it's extremely difficult to implement.
> 
> > c) On a more advanced mood, allow entering the editor while in trace
> > mode, defining and executing new routines, modifying old ones,
> > modifying and creating variables, etc.
> 
> That's hard too.
> 
> > 3) Allow executing string variables, that can 
> > contain code like "x = y * p".
> > 4) Allow defining functions from a string, for example:
> > "function foo(integer u) return power(u, u) end function"
> 
> I don't like any feature that requires code or variables to be 
> constructed
> at run-time and executed. I used this in APL, and found it
> was an overly-powerful solution searching desperately for a problem.
> Rarely useful in practice. Theoretically it buys you nothing
> in terms of the algorithms you can implement.
> It's also extremely hard to implement in the current interpreter
> without starting from scratch. Any translated to C code that
> used this feature would need to carry around a
> complete copy of the interpreter.
> 
> > 5) A function that returns the amount of available real storage at the
> > moment.
> > It will ease the task of determining the size of buffers to avoid
> > using virtual storage.
> 
> You could write a routine that calls allocate() with progressively
> smaller sizes until it doesn't get a 0 returned, although that
> wouldn't exclude virtual storage.
> 
> You might want to know the total free space, or you might want
> to know the largest contiguous block of storage that's available.
> 
> You'd also need to know how much space Euphoria variables
> consume. I don't like to make the implementation details
> of Euphoria's internal representation so explicit.
> In most Euphoria programming you shouldn't have to think
> in terms of bits, bytes and nibbles.
> 
> I might consider doing something, 
> but now that I have 256Mb RAM, 
> I don't expect to run out of memory very often.
> 
> > 6) A facility to save the status and variables 
> > of a program in the middle of
> > execution, also available from the trace screen. This will ease
> > debugging; you could advance execution to a certain point, save,
> > continue, and in case of failure, restart at the saved point.
> 
> Do you want me to undo all the changes that you've made to files?
> Set the screen back the way it was? Open and close windows, 
> undo the side effects of .dll routines that you've called, 
> memory that you've overwritten, etc.?
> 
> > 7) Add the following *internal* data types: byte, word (2 bytes), and
> > perhaps (why not?) bit and nibble (half byte), all in 
> > order to save storage.
> > Programs should switch from one to other according to needs.
> > For example, assume a sequence s  s = {}. Then, s &= 1. This can
> > be a byte (or bit) type. If then s &= 65, it remains byte. If then
> > s &= 3456, it should switch to word (the entire sequence). If then
> > s[1] = 12345678, it should switch to the current Euphoria integer type.
> > If then s[2] = 89.876, maybe the current scheme could be maintained
> > (AFAIK, only this element becomes floating point, and the rest remain
> > integer), or else the entire sequence switches to floating.
> 
> You've just described exactly the way APL does things.
> The problem with having n internal data types, is that you
> have to handle n-squared cases for every binary operation
> in the interpreter (or translator). This would be slow, and would
<snip>

3. Re: Robert Craig... One Wish Please

• Posted by Sabal.Mike at notations.com Jul 30, 2002
• 399 views

I've been asking for a crash_routine() for years.

Mike Sabal

>>> jorfergie03 at yahoo.com 07/30/02 12:49PM >>>

Hi Robert,

I have only one wish i would like added to exw. The ability to call a 
routine at crash time or in case of a windows exception, similar to
what 
Matt lewis has done but built into the Euphoria interpreter/translator.


     This is very handy when cleaning up GDI resources and Memory 
allocations made using API calls rather than EU Calls. Generally, this

would help us clean-up and avoid reboots due to resource leaks.

How about that? WIN32 programmers back me up

jordah ferguson

5. Re: Robert Craig... One Wish Please

• Posted by mistertrik at hotmail.com Jul 30, 2002
• 386 views

>From Robert Craig:
>A global exception handler has been on my list for a long time,
>at least in principle. It wouldn't be hard to implement,
>but it raises some issues that have to be examined carefully,
>
>    - It might preclude doing an eventual full treatment of
>      exceptions like C++ and other languages, where
>      each block of statements can have its own handler.

Ok, so a global exception handler is not difficult. Can you comment on the 
difficulty of implementing full treatment of exceptions?

And will it have 'proper' try/catch syntax, rather than through a procedural 
interface? I would think the first is easier to understand.
i.e.

try <exception>
    --some code
    --exception_causing code
    --some more code
catch <exception>
    --deal with it.
end try

OR
==

procedure catch()
    --deal with it.
end procedure

set_try("<exception>", routine_id("catch"))
--some code
--exception_causing code
--some more code
end_try("<exception>")


Also, if we could define exceptions, it would be nice... :P
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_    <-------------------/
\__| Mr Trick

7. Re: Robert Craig... One Wish Please

• Posted by kbochert at ix.netcom.com Jul 31, 2002
• 398 views

-------Phoenix-Boundary-07081998-

You wrote on 7/30/02 8:42:27 PM:

>
>Ok, so a global exception handler is not difficult. Can you comment on the 
>difficulty of implementing full treatment of exceptions=3F
>
>And will it have 'proper' try/catch syntax, rather than through a 
>procedural interface=3F I would think the first is easier to understand.
>i.e.
>
>try <exception>
>    --some code
>    --exception_causing code
>    --some more code
>catch <exception>
>    --deal with it.
>end try
>
>OR
>=3D=3D
>
>procedure catch()
>    --deal with it.
>end procedure
>
>set_try("<exception>", routine_id("catch"))
>--some code
>--exception_causing code
>--some more code
>end_try("<exception>")
>

Bliss has throw-catch exceptions.

The throw statement searches the current run-time stack
for a procedure that has a catch. If found, control
is passed to it, and a variable is set to hold the
interesting information (id, msg, etc.). If no catch
is found, it is a fatal runtime error.

As a result of following this thread, I am 'finishing
off' the implementation by adding:

1) A variable can hold the routine id of a function
   to be called when an uncaught exception occurs.

2) Internal run-time errors generate exceptions (throw).

Does this meet the needs=3F

There is no 'try' 
No provision is made for returning from the throw.
   ( Isn't it true that when an array out of bounds
   error occurs the proper course is to retry a
   block of code, rather than a single instruction=3F)

An example:
   procedure foo (integer x)
      if x =3D 0 then
         throw ({202, "Argument cannot be 0"})
      end if
      ...
   end procedure

   procedure zot (integer cnt)
      ...
      foo (cnt)
      ...
      return
   catch
      if THROWN[1] =3D 202 then
         =3F"Oops -- cnt was zero!"
         return
      else
         throw()    -- rethrow the exception
      end if
   end procedure
  


Karl Bochert


-------Phoenix-Boundary-07081998---

9. Re: Robert Craig... One Wish Please

• Posted by petelomax at blueyonder.co.uk Jul 31, 2002
• 394 views

{{{ On Tue, 30 Jul 2002 23:49:31 -0400, Robert Craig <rds at RapidEuphoria.com> wrote:

Agreed. I vote the program *WILL* terminate after the call is made. Basically, (state this) the _on_crash_ routine can be set & is cleared before the routine is called; if the programmer is daft enuf to reset it during the crash procedure *ALL BETS ARE OFF*

I vote: forget this; xlate to C is a speed/release issue anyways. I suspect we're all more concerned with alpha/beta issues.

btw, I'm not up to speed on this. are you saying that given checks such as index of -1 are no longer checked at all in a xlated to c pgm?

Erm? I would strongly recommend (if it helps) that such a routine can only exist at top-level; not in an include file; no local vars - & even no calling of other procedures/functions (again if it helps).

Erm again, I wouldn't expect either a) more than one fatal error trapping routine, or b) it to have *ANY* access other than to global variables - it's a programming (/er) issue, again. So it would/could only access stuff your standard top-to-bottom interpreter wouldn't dare release yet.

Not at all what I want. I want the program to be able to save some stuff (globals), simple message perhaps, crap out & die as usual. Re-starting the program (eg a long edit) then offers the user a choice of restoring to file-on-disk or applying changes to some workable point (again, up to the programmer to figure that beast out)

I wholly, wholly, completely and utterly disagree; this is *NOT* exception handling; this is crap out and die handling. A different beast altogether.

• NO*

When possible, but largely, again, this is a programmer issue; It's *much* more important for an app to know which bit it was doing rather than a "divide by zero" just happened, as you all know.

I trust you wholly in that respect.

<snip>

Rob, you're in alpha mode for 2.4 right now yeah? Live a little Stamp your foot down on some sensible limitations. Please don't use the word "exception"; it only confuses. Try fatal error instead. (or crap out and die handling!-) And yank it if it goes pear shaped.

Pete