1. Ideas for Euphoria v2.5
Hello there,
Now that i've seen the call for "Major ideas" for 2.5, i have to say
that a really major improvement would be to have a Windows based
debugger for operations on Windows systems.
I considered building one myself a while back.
Also, a secondary thread too, if that's possible.
If this is *too* major, than how about these:
[1]
Allow an include file to be included more than once, with
a different namespace qualifier.
The reasoning for it would be to reuse all the functions (global and
local) and all the variables too, while allowing individual globals
to be overwritten by new ones with the same name, while all the
local variables are simply taken out a second time as a second
(or Nth) instance with the same name. The local constants would
be simply reused unless they were initialized with a variable statement.
In short, the second (or nth) include of the same file (within the
current file) with a different namespace qualifier would make it act
the same way as an exact copy of the file with a different filename.
The only difference would be if there were also global overrides
possible,
but that's another story anyway and not as important.
Example:
-------------------------------------
--start of File.ew:
atom x,y,z
x=0 y=0 z=0
global procedure Load_x(atom a)
x=a
end procedure
global function Get_x_y_z()
return {x,y,x}
end function
--end of File.ew
-------------------------------------
include File.ew as X1
include File.ew as X2
include File.ew as Xn
X1:Load_x(1) --now File_X1's x=1
X2:Load_x(2) --now File_X2's x=2 but File_X1's x is still x=1
Xn:Load_x(n) --etc.
The implementation should be very straightforward, for example:
1. Load the file once into memory calling it by it's real name, then
2. Make a clone with some other name that cant be found in a file
system.
Of course it would be faster to parse it once and make all the clones
with
the resulting object, perhaps locating them in a different 'system'
namespace
invisible to the user. Just some ideas though.
Should be very easy to implement i would think because it doesnt involve
anything new really.
While this is all going on, the file would retain the ability to
be able to include itself with a namespace as it does now.
[2a]
reallocate()
This would be separate from 'allocate()' instead of making 'allocate'
act like 'reallocate' for already used variables, because keeping
track of 'reallocate' is different than keeping track of
allocate/free pairs.
Also easy to implement.
[2b]
If there was some way to force the pointer to zero (0) after it
got free'd, that would really be nice. In certain cases it
would be good to be able to test a pointer to see if it had
already been free'd. If it takes up too much time relative to the
other housekeeping that has to go on with the free'ing then
i'd retract my request without hesitation. I guess a good
threshold would be about 10% or less, with 20% as a max.
[3]
I find that the current memory exception handling is good.
[4]
I have to second the nomination for adding a fault handler
in case something goes Eu wrong during execution that wasnt
expected...and one level should be adequate...if the
fatal error code cant handle the problem then go to
the default error handler as is in place now.
This gives the end user the chance to recover data,
but not to keep on running the application.
Example:
Text Editor!
A built from-the-ground-up text editor, after running for
months on countless files, suddenly and very unexpectedly
crashes. A nice way to handle this case, especially if
the text is stored in sequences of sequences (where each line
or object is a separate sequence) would be to open a
"Fatal Save As" dialog box allowing the user to select a
path, then to index through the buffer sequence testing
each sub sequence for length and saving each object to
disk. Since there would be only two mechanisms
(dialog box, indexing and writing) i would think
this could be very error proofed beforehand.
Heck, with a little tact the file could be reloaded
again and scrolled and the cursor placed back in the
last valid position 
I'd bet that when text editors crash 99.999 percent of
their data is recoverable.
onSequenceInvalidIndex(routine_id("handle_it")) comes to mind
as someone else was talking about.
I think that would cover about 101% of all Eu errors
Take care for now,
Al
2. Re: Ideas for Euphoria v2.5
- Posted by Urzumph at HotPOP.com
Aug 14, 2003
Al Getz wrote:
> Now that i've seen the call for "Major ideas" for 2.5, i have to say
> that a really major improvement would be to have a Windows based
> debugger for operations on Windows systems.
> I considered building one myself a while back.
> Also, a secondary thread too, if that's possible.
There's only one thing I would like in euphoria, and I REALLY want it.
I would really like it if, when reporting errors, the interpreter would
give 5 lines above and below (assuming the lines are available, and that
it does not go outside the bounds of a function/procedure) where the
error occoured. This is most annoying when the error occours on a very
unimportant line like
expected to see possibly 'procedure' not if
end if
^
If I do ANY significant amount of coding before I execute the program,
chances are, I will have used several procedures, and probably a few
dozen ifs. That is decidedly un-helpful.
Side note: yes, the line numbers are useful, just not when you have
include files that are so long that you can't get to that line by hand,
they are near useless
3. Re: Ideas for Euphoria v2.5
Urzumph wrote:
> There's only one thing I would like in euphoria, and I REALLY want it.
>
> I would really like it if, when reporting errors, the interpreter would
> give 5 lines above and below (assuming the lines are available, and that
> it does not go outside the bounds of a function/procedure) where the
> error occoured. This is most annoying when the error occours on a very
> unimportant line like
>
> expected to see possibly 'procedure' not if
> end if
> ^
I personally never had such problems. When an error occurs, I have to
change the code anyway. And in my editor, I see many lines before and
after the error.
> If I do ANY significant amount of coding before I execute the program,
> chances are, I will have used several procedures, and probably a few
> dozen ifs. That is decidedly un-helpful.
>
> Side note: yes, the line numbers are useful, just not when you have
> include files that are so long that you can't get to that line by hand,
> they are near useless
Good editors have an option "Go to Line ...".
Bets regards,
Juergen
--
/"\ ASCII ribbon campain | "Everything should be made as simple
\ / against HTML in | as possible, but not simpler."
X e-mail and news, |
/ \ and unneeded MIME | [Albert Einstein]
4. Re: Ideas for Euphoria v2.5
- Posted by 1evan at sbcglobal.net
Aug 14, 2003
Urzumph at HotPOP.com wrote:
> Side note: yes, the line numbers are useful, just not when you have
> include files that are so long that you can't get to that line by
> hand, they are near useless
Pretty useful if you use an editor that can go to line numbers.
(Crimson Editor for 1, I'm sure there are many, many others.)
5. Re: Ideas for Euphoria v2.5
- Posted by eugtk at yahoo.com
Aug 14, 2003
--- Al Getz <Xaxo at aol.com> wrote:
> [1]
> Allow an include file to be included more than once,
> with a different namespace qualifier.
Dave Cuny had this in an early version of Py, and
it was very useful. Unfortunately, as soon as I
pointed
out how useful it was, he removed it :(
It offered a way to reuse code (which I have always
heard is a 'good thing') and a way to write clearer
code
(also a 'good thing').
I would also like to see user-defined types.
"Hey, we've already got that", you say?
Yes, but with only about 1/4 of the usefulness it
*could* have.
I'd like to see:
1. user defined types which can MODIFY the parameter
passed to them. Then, you could fix a problem or
ask the user to fix the problem, and continue on;
not just crash your program.
2. something similar - a user-written function which
can be called when a variable is REFERENCED, (as
opposed to on ASSIGNMENT, which is what type does
now.)
Irv
6. Re: Ideas for Euphoria v2.5
- Posted by Urzumph at HotPOP.com
Aug 20, 2003
> Good editors have an option "Go to Line ...".
>
> Bets regards,
> Juergen
>
Does that mean that notepad does not constitute a good editor? ;)
7. Re: Ideas for Euphoria v2.5
Urzumph wrote:
>> Good editors have an option "Go to Line ...".
>>
>> Bets regards,
>> Juergen
>>
>
> Does that mean that notepad does not constitute a good editor? ;)
I only can write the personal opinion of a single man, sittung here on
this black chair, of course.
Yes, it's part of my definition of a good editor, that the editor must
have an option "Go to Line ...".
The people at http://www.notepad.org/ may have a different point of view,
though.
Regards,
Juergen
--
/"\ ASCII ribbon campain | "Everything should be made as simple
\ / against HTML in | as possible, but not simpler."
X e-mail and news, |
/ \ and unneeded MIME | [Albert Einstein]
