Re: rigid data structures
Maurizio writes:
> But, just for the list readers, can you anticipate us what
> new features are you thinking to add to your wonderful creation?
I have a long list of potential new features. At this stage
I have mostly done research into these features to choose
the ones with the best cost/benefit ratio. I don't like to talk
about a feature that I *might* add, in case I later feel like I'm
committed to that feature, even when a much better
feature comes along. Junko is also working on some stuff
that we don't want to talk about yet, since it might not
be feasible.
However, I don't mind listing what has actually been
implemented and tested so far. The list is long,
messy (and perhaps boring), as it comes from
my own notes to myself, and hasn't been cleaned
up much for public consumption. It's
roughly in chronological order.
- minor improvements/corrections in refman.doc and library.doc
- BUG FIX: added if ... then to allocate_string() so it won't
store into address 0 when allocate() returns 0
User can check for 0. Thanks to Ralf and Greg Harris
- BUG FIX: In ex.err "traced lines leading up to the failure"
would drop the first piece of each statement
when "with trace" and either "with profile" or "with profile_time"
were selected. Thanks to Christopher Hickman.
- BUG FIX: save_text_image and display_text_image were not correct for
number of lines > 25 AND using an alternate active page (>page 0) Thanks to
Jean Bayon.
- BUG FIX: in message_box() there was a storage leak - thanks to Terry
Constant
- raised MAX_USER_FILE to 25 from 15
i.e. was 12 user files open, now 22
- optimization and feature: short-circuit evaluation of conditional
AND/OR expressions in if/elsif/while. This speeds up some code,
but it also allows more elegant conditional statements, like:
if atom(x) or length(x) = 1 then ... which would cause errors in 2.0.
A warning is issued if a function with possible side-effects might be
short-circuited. This is to catch possible "broken" code written for earlier
releases of Euphoria. No problem if code was bound. Remember to allow
warnings or you won't see it. S.C. evaluation only takes place in
conditional expressions (where we know that an atom result must be
produced.)
- optimization: branch straightening. In the intermediate code, a jump from
A to B to C becomes a jump from A to C. Longer chains
will also be optimized.
- Warnings are now displayed *after* your program finishes execution, so
they can't disappear with clear_screen(),
graphics_mode() etc.
Some programs now show warnings where none were seen before.
- The state of all with/without settings is saved upon entering an
included file and restored at the end of the included file.
An included file can change the settings,
but they will be restored at the end of the included file.
e.g. warnings might be turned off just within the included file
(and any files it includes). As a result some programs now
display warnings where none were seen before.
- BUG FIX: the object() type now returns 1 in every case.
(object() previously existed, but was undocumented and incorrect)
- optimization: global/local initialization checks are replaced
by no-ops after the first check is performed.
- BUG FIX: read_bitmap() was neglecting to close the bitmap file
if it had an unsupported format. Thanks to Jesus Consuegra
and Graeme Burke.
- BUG FIX: trace() will no longer have any effect unless it is executed
inside a "with trace" section. This will prevent it from causing get_key()
to delay 8 seconds each time, unless you are really doing an interactive
trace.
- BUG FIX: scramble was not handling ascii character 255 properly
- thanks to Graeme Burke.
- trace window only shows file name at the top, not full path - less likely
to spill off the end, less "busy" display
- BUG FIXED: bind/shroud would have an error if you give it control-Z
for the filename - Andy Kurnia.
- BUG FIXED: (Irv Mullins) numbers typed into your program greater than
about 88 digits would crash Euphoria (due to WATCOM C sscanf() failing!).
This was fixed by replacing sscanf with hand-written code from get.e
translated into C. This saved 2K
(after compression) in ex.exe, and a little more than 2K in exw.exe.
The values of constant atoms typed into your program are now very likely to
match exactly the values computed by get() or created by value().
- numeric literals greater than 1e308 (roughly) are now
set to inf by the scanner. They used to cause a compile-time error.
- optimization: subroutine call+return overhead reduced
by an average of 30%. Speed-up occurs for all normal function/
procedure/type calls, user-defined type-checks,
call_proc/call_func calls using a routine id, and Windows call-backs.
Only recursive calls cost the same. Programs with a high density of calls
can easily be 10% or more faster because of this.
- the default print format for atoms was changed from %g to %.10g
This format is used by print(), ?, the trace facility, and ex.err
dumps.
This allows large integers -9,999,999,999 to +9,999,999,999
to be printed as integers, rather than as scientific notation.
(e+009). It also provides about 10 digits of accuracy to be
displayed on fractional numbers, rather than just 6.
Note print()/get() is less likely to lose accuracy on large integers
and floating-point numbers. You should really use atom_to_float64
and float64_to_atom to avoid losing any accuracy when saving/restoring
atoms. (Art Adamson pointed out a problem that led to this improvement.)
- Bug fixed: In WIN32, C functions declared as returning char, unsigned
char, short or unsigned short would not always have the value returned
correctly. The low order 8 or 16 bits would be correct,
but the upper bits of the Euphoria atom returned from c_func()
might be garbage. Thanks to Greg Harris.
- Bug fixed: bind/shroud would sometimes choose the same name as a user's
symbol name in cases where the user's name was not
shroudable, e.g. -clear_routines was specified, or it was a
global name in the main file, and it was a very short name.
This would cause an error when the program was run -
"name already defined". (thanks to Rolf Schroeder)
- A compile-time error in scrambled code will no longer display
the offending line. It was being displayed in shrouded form
which is a minor breach of security. (thanks to Rusty Davis)
- The scrambling algorithm has been improved.
The old algorithm is still supported.
- Change: When the user simply types ex or exw
and is prompted for the name of the Euphoria .ex or .exw file,
command_line() will now be updated to include the file name as the
second command-line argument, as if the user had typed: ex name
(No args can be specified)
It used to just show just one command-line argument in this case
("ex.exe" or "exw.exe").
So your program won't have to worry about how it has been run.
I also trim leading and trailing blanks in the prompted-for file
name in all cases now. Thanks to Mathew Hounsell
- the overhead cost of draw_line() has been reduced by a few percent
- get() and value() are now *much* faster in most cases.
-> Thanks to Jiri Babor: unget() and subsequent get_char() have been
eliminated, plus get_char() has had a test removed.
-> I also speeded up get_number() with smarter coding
-> subroutine call overhead is reduced in 2.1 and
get()/value() make a lot of calls to get_ch() and other routines.
[Times measured "without type_check" - there's also a big speed up
when type_checking is left on]
New v2.1 ex.exe with new v2.1 get.e:
45% faster: reading sequence of f.p. numbers from a file
2.25x faster: when reading sequence of integers from a file
- get/value will now avoid inf in cases like 0.0000001e310 where the
exponent part would have been inf, but the mantissa was less than 1.
You really must have a blank, tab or new-line separating all
top-level objects in the file (as stated in LIBRARY.DOC)
(used to work with sequences before but not atoms)
- get() and value() were allowing ''' as single-quote character
but ex/exw were declaring it an error. Now get() and value()
declare it as an error too.
- BUG FIX: if you have a unary minus operation applied to a constant
symbol that is defined earlier in the *same* constant statement,
ex.exe and exw.exe may crash. e.g.
constant a = 10, b = -a
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
|
Not Categorized, Please Help
|
|
