Robert Craig... One Wish Please
- Posted by jordah ferguson <jorfergie03 at yahoo.com> Jul 30, 2002
- 439 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>