1. RE: Robert Craig... One Wish Please
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C23817.74E45700
charset=iso-8859-1
YES YES YES YES YES YES YES YES YES YES YES YES
Just Do It!
> -----Original Message-----
> From: jordah ferguson [mailto:jorfergie03 at yahoo.com]
> Subject: Robert Craig... One Wish Please
>
>
>
> 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.
> >
<snip>
>
>
>
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C23817.74E45700
Content-Type: application/ms-tnef
2. RE: Robert Craig... One Wish Please
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C238E6.9B145630
charset=iso-8859-1
I see the main advantage for such 'pre-crash' routines is to be able to
restore the system to a stable or useful state. This is a "good neighbour"
policy. True, Euphoria does a great job is restoring allocated resources
back to the system when my program crashes, but there are some things that
it cannot know about. Such as temporary files, locked semaphores,
cooperative processes, etc... It would be useful to have the author of the
program take some responsibility in cleaning up when a crash occurs.
Another use is to establish some checkpoint/recovery protocol for when the
program restarts. That is, for some programs it is useful to know if the
previous run completed successfully or not.
-----------
cheers,
Derek.
> -----Original Message-----
> From: acran at readout.fsnet.co.uk [mailto:acran at readout.fsnet.co.uk]
> Sent: Thursday, 1 August 2002 9:01
> To: EUforum
> Subject: Re: Robert Craig... One Wish Please
>
>
>
> At 10:29 31/07/02 -0400, you wrote:
> <snip>
> >The issue is really whether we trap the error before it occurs with
> >hundreds of lines of error-checking code, or do we trap it after it
> >occurs with hundreds of lines of error-handling code? The cleaner
> >method is to trap the error before it occurs.
> <snip>
>
> I totally agree that is the cleaner approach.
>
> I generally write short programs (less that 500 lines and many much
> shorter) for my purposes (I'm from a system admin background)
> but even so
> I'd say between 30 percent and even 60 percent of the lines
> of code I write
> are some form of error checking, error reporting and, if
> possible, error
> correction.
>
> If you know a condition might exist that could cause future
> program flow to
> fail then check for it, if it exists then try and correct it and if
> "normal" processing cannot continue then raise an alert and
> either back off
> (if in a batch/unattended environment) or ask the user (if in an
> interactive environment) for an opinion on how to proceed.
>
> Of course you don't know what all the possible errors could
> be. For medium
> and larger sized programs it is impossible (humanly) to predict all
> combinations of logic flow so unexpected errors might and do
> occur. In my
> mind (yes it's a small place but the advantage is I know my
> way around 
> it is best to let the system tell you you've made a mistake.
> You work out
> what went wrong, how to handle this condition, amend your
> code and retest
> (but see my final comment!).
>
> If you rely on an error handling routine to patch things up
> and keep things
> going then you have hugely increased the complexity of your
> code. If you
> look at code you have to think in the back of you mind "well
> at this stage
> the code looks like it has done this with global variable X
> but at certain
> times the crash recovery routine may have changed the value
> under the feet
> of this routine". Hmmm. I can see tricky bugs lurking.
>
> And another thing: what happens if the error handling routine itself
> generates an error!?
>
> Finally: I know that everytime I travel by plane many many
> lines of code
> are flying it (for some of the time at least). I wonder if
> the language
> they used has "error handling routines"? Remember that the
> programmer(s)
> are not on the plane with you.
>
> Regards,
>
> Andy Cranston.
>
>
>
>
==================================================================
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en
de afzender direct te informeren door het bericht te retourneren.
==================================================================
The information contained in this message may be confidential
and is intended to be exclusively for the addressee. Should you
receive this message unintentionally, please do not use the contents
herein and notify the sender immediately by return e-mail.
==================================================================
------_=_NextPart_000_01C238E6.9B145630
Content-Type: application/ms-tnef
