Re: Rob: List?
Vincent wrote:
> Robert Craig wrote:
> > OK, I've gone through my list of ideas, and I've picked
> > some that I think are worth doing for 3.0 alpha.
>
> > I'm not including bug fixes on this list, though
> > I certainly intend to fix most of the reported bugs.
>
> > There are numerous good suggestions on my master list
> > that I'm not listing here because I don't want to take
> > too much longer in getting an alpha release out. I'll be
> > able to do a few more small improvements for the beta release.
>
> Great. I'll comment on each of them.
>
> > 1. make a separate version of exu, ecu.a (PD+Complete), and
> > backendu without ncurses and without libgpm. i.e. position() won't work.
> > Just use plain vanilla standard I/O. Trace window would just output
> > most recent line of source, most recent var update etc.
> > Linux and FreeBSD. Test use of ANSI escape chars to get 2-d position.
>
> We know about this one. This will be useful for script kiddies and seasoned
> developers alike who want to do BASH scripting with Euphoria. I'll probably
> be learning BASH in future operating system courses, so this is a valuable
> addition
> to the language.
>
> I do predict a few bugs spawning in the beginning, since you would be removing
> pieces of code in the backend and adding a new trace feature.
>
> This would leave you with two seperate versions of specific backend source
> files?
>
> > 2. provide non-blocking I/O support to assist multitasking
>
> Christopher Bouzy is going to love this one.
>
> Can you explain how you might approach this? This doesnt seem cut and dry. How
> might one go about implementing non-blocking support and what exactly will it
> offer us? Will there be any new routines associated with it?
>
> > 3. Incorporate Daniel's multi-threaded non-blocking WIN32 API calls
>
> Not to offend Daniel's work but I just dont trust his library and recall
> reading
> about performance issues. The library uses architecture specific machine code
> and brings up questions about reliability. It also is Windows specific thus
> offering little or no benefits to Linux and BSD developers.
>
> I would be uncomfortable with any fine grain/internal integration of it inside
> the Euphoria interpreter. However simply providing TDLL.e in the EUDIR/INCLUDE
> directory sounds like a good alternative to me.
>
> Perhaps you spice it up and add official documentation for it? That will allow
> users to use it without implementing it internally and potentially making room
> for low-level subtile bugs and other oddities.
>
> I feel that this is a very reasonable request, what do you think?
I haven't looked into this enough to comment.
> > 4. improve viewing of vars in trace display - at least allow subscripts
> > with numeric constants
> > add length (and nesting level) to trace var display? - Alan Oxley
> > and many others
>
> Fantastic. These will all be useful to me and probably everyone else who plans
> to upgrade.
>
> > 5. get profile_time working in WIN32 and Linux/FreeBSD (and DOS).
> > measure the time spent inside each function,
> > (subtract the overhead of getting the time)
>
> Just what the doctor ordered! I'll be watching out for this one.
>
> > 6. front-end optimization of temps - fewer temps gives better performance
>
> I remember this issue very clearly. Improving internal temp variable operation
> will be a big welcome. As I recall this could be a massive performance killer
> in very specific scenarios.
>
> <a
> href="http://www.listfilter.com/cgi-bin/esearch.exu?thread=1&fromMonth=8&fromYear=A&toMonth=A&toYear=A&keywords=%22Euphoria+bug+">http://www.listfilter.com/cgi-bin/esearch.exu?thread=1&fromMonth=8&fromYear=A&toMonth=A&toYear=A&keywords=%22Euphoria+bug+</a>(Robert)%22
>
> > 7. try again to speed up scanning/parsing/emiting (front end)
>
> Cheers mate! Even if the gain is small it still would be 24-karat gold on my
> old systems. 
>
> > 8. Translator optimizations:
> > - translator: if a call_proc/call_func has an argument sequence where
> > all the elements are known to be integers, we shouldn't bother to
> > emit Ref's on the elements
> >
> > - could easily optimize code generation for compare() in translator
>
> Got to love them optimizations!
>
> > 9. several other minor enhancements and bug fixes, e.g.
> > - try latest CauseWay (Hayden McKay, also see Vincent's message)
> > - try compressing ex.exe etc. with UPX instead of CauseWay - Matt
> > Lewis
> > - investigate check_break/allow_break - Jason Gade
> > - execute.e - we should really perform error checks before
> > calling log, rand etc.
> > - pretty_print(), option 3 - should include \t \r \n as
> > valid "ASCII range" characters, especially to increase
> > likelihood of strings being displayed. Juergen Luethje
> > - printf(-1, ...) should give an error - Daniel Kluss
> > - add a run-time error check to detect if a supplied crash routine
> > is not a function or does not have exactly one parameter
> > - "-icon" feature for translator, like binder - Vincent Howell
>
> All those sound good except the UPX one. I guess I just cannot convince you
> not to use it? I guess the bright side of using UPX rather than the Causeway
> compressor is that I can easily decompress the file with the "upx -d" option.
>
> > Feel free to comment on these, and suggest other ideas.
> > But keep in mind I want to get 3.0 alpha out within a few months.
>
> All of these ideas are excellent and well worth the wait seeing them. The only
> thing I would strongly advise is not to incorporate Daniel's routines directly
> into Euphoria, but rather provide his library with the download package. It
> will probably be much safer, cleaner and easier anyway.
Thanks for your comments. I understand that exe compression is
of questionable value.
As I said before, I'm just starting to explore most of these
features. I'll back out of anything that no longer seems worth doing.
> So what kind of prices are we looking at for a v3.0 translator upgrade? Will
> it be about the same as now since the US dollar hasnt really gained or lost
> on the Canadian dollar lately or will we see a notable price hike because of
> the new and improved functionability of your products?
I never decide those issues until just before the alpha release,
but you are right that there hasn't been much change in the
U.S. dollar / Canadian dollar exchange rate since the last release.
(although the Canadian dollar has risen slightly, mainly because
we have lots of oil up here )
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
