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.
>
> > 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>
|
Not Categorized, Please Help
|
|
