1. Rob: List?
HI Rob,
with this formula:
global object i_
function FOUND( object sym, sequence stream)
if atom( sym) then
i_ = find( sym, stream)
else
i_ = match( sym, stream)
end if
return i_
end function
--- ========
a fast solution is allowed:
while FOUND( ZEROsym, prm) do
prm[i_] = 0
end while
I wonder if it could implemented into the EU language a reserved variable
like « i_ », active inside the "while / end while" and usable for various
situations into the loop.
What I mean is that, instead of having to set an express routine as above,
every function, from find( ) or match( ) to get_..(), length(), sin() etc.
ACTIVATED BY THE WHILE COMMAND should automatically return a value into
the variable i_ for any scope. Something like what happens with the FOR
routine, but a bit more sophisticated.
Regards,
Antonio Alessi
2. Rob: List?
- Posted by Vincent <darkvincentdude at yahoo.com>
Mar 20, 2006
-
Last edited Mar 21, 2006
When can we expect to see the list? Are you posting it here or on the Future of
Euphoria page?
I must admit that I am anxious to see what you decided on.
Regards,
Vincent
3. Re: Rob: List?
- Posted by Robert Craig <rds at RapidEuphoria.com>
Mar 20, 2006
-
Last edited Mar 21, 2006
Vincent wrote:
> When can we expect to see the list? Are you posting it here or on the Future
> of Euphoria page?
>
> I must admit that I am anxious to see what you decided on.
By the end of today I'll have something for you.
I guess I'll post it in both places.
Lately I've been looking more at things like Google ads,
"marketing" etc., but I guess it's time to get back
into serious coding. 
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Rob: List?
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.
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.
2. provide non-blocking I/O support to assist multitasking
3. Incorporate Daniel's multi-threaded non-blocking WIN32 API calls
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
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)
6. front-end optimization of temps - fewer temps gives better performance
7. try again to speed up scanning/parsing/emiting (front end)
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
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
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.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Rob: List?
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?
> 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.
http://www.listfilter.com/cgi-bin/esearch.exu?thread=1&fromMonth=8&fromYear=A&toMonth=A&toYear=A&keywords=%22Euphoria+bug+(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.
...
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 guess I'm hoping you dont raise them to much otherwise I wont be able to
afford a translator upgrade; gas for my car is becoming fairly expensive.
Regards,
Vincent
6. Re: Rob: List?
> - "-icon" feature for translator, like binder - Vincent Howell
Don't forget my suggestion for a "-xp" feature for the WIN32
Translator. OR an option to include resource files right in the
command line for any translator (much more useful).
~Greg
7. Re: Rob: List?
Here are my comments on each item of this list.
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.
>
> 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.
>
Probably useful. I have no opinion as I don't use Linux (yet).
> 2. provide non-blocking I/O support to assist multitasking
>
Could you elaborate on this? If it means that Eu gets at last a set of file
xplat commands which are not blocking, this is a welcome development.
How would a progress or completion status for a I/O command be reported?
> 3. Incorporate Daniel's multi-threaded non-blocking WIN32 API calls
>
Seems to overlap 2) above. Also, isn't it simpler to extend the semantics of
"integer" to cover what ALL language around do, ie machine size integers
(32 or 64 bit according to host hardware)? And why do this in Windows only
then? Looks like a half baked thing.
> 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
>
At last something useful here.
> 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)
>
Not bad, but elapsed time monitoring is easy without this,, as the overhead
of getting the time() is hopefully constant, so that it cancels out when
substracting two readings. Is it useful to add this specific feature? All
right, perhaps a more detailed picture would show how useful that could be.
> 6. front-end optimization of temps - fewer temps gives better performance
>
> 7. try again to speed up scanning/parsing/emiting (front end)
>
Are you sure the time you'll spend in these tricky optimisations will not
outweigh the sum of all execution time gains achieved through them?
Perhaps most Eu users still use 486s or older, in which case these are relevant.
If not, see my final comments.
> 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
>
Ok, these are probably useful. When I *really* (and rarely) need raw speed,
I directly code in C if asm is not an option. Here again, are these little
optimisations worth your efforts?
> 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
>
Ok, fitting nuts and bolts tighter is always a good thing.
> 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.
>
Development and testing time is much larger than execution time,
except for very specific tasks. Hence I would have welcome anything that makes
Euphoria more flexible when it comes to coding, since bugs usually arise in
the translation from the developer's goals and the constrained extent of what
an interpreter can understand.
But nothing in the above suggests any move towards this direction:
- No provision for having a better control on what is, or is not, in namespaces,
and specially in the unnamed one where all global symbol live;
- No provision to allow passing arguments as reference to routines;
- No provision to allow more practical, yet structured, control over execution
flow,
which could take the form of:
* optional argument to the exit statement: exit n loops/exit the loop with this
label
* a continue statement (skip remainder of current iteration)
* a retry statement (restart current iteration)
* a select (or switch, or inspect...) statement to handle multiple choices
Also, I really think some integrated tool to manage context switch in
multitasked environments is needed, because the same library may be queried
by different tasks "at the same time", ie while some not shareable data is
being used. Most OSes know about thread vars, this could be the simplest way
to go. Except DOS admittedly.
The technical improvements most of this list is made of are, in my opinion,
quite less useful than adding some of the above.
CChris
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
8. Re: Rob: List?
CChris wrote:
>> 6. front-end optimization of temps - fewer temps gives better performance
>> 7. try again to speed up scanning/parsing/emiting (front end)
> Are you sure the time you'll spend in these tricky optimisations will not
> outweigh the sum of all execution time gains achieved through them?
> Perhaps most Eu users still use 486s or older, in which case these are
> relevant.
> If not, see my final comments.
#6 is a very important. In some cases it can cause a very large performance
drop. I dont know how effective Rob will be at improving this for us, but I will
say anything is better than nothing.
#7 is useful on all systems five years old or more. You will see a very
noticable parsing delay even on a Pentium III machine when trying to run a large
program like Win32Lib IDE. On a 386 or 486 any medium to large size program will
take between tens of seconds to a few minutes to load. The IDE takes almost four
minutes to load to the splash screen on my 486 with v2.5!
So yes, I strongly support these optimization efforts and look forward to them.
I'm not expecting any miracle improvements but at least marginal will suffice.
Whatever Robert can do to improve these to his maximum ability is all that I
could hope for.
>> 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
> Ok, these are probably useful. When I *really* (and rarely) need raw speed,
> I directly code in C if asm is not an option. Here again, are these little
> optimisations worth your efforts?
Any optimizations are worth the effort in Euphoria at least. One of the biggest
selling points of Euphoria is it's performance as an interpreted language. If
that did not count we'd likely be better off using Python or Ruby with complete
standard libaries and large supportive communities.
> CChris
Regards,
Vincent
9. Re: Rob: List?
Hi Rob,
I wonder if it could be possible to interface an external routine with the
Trace( ) procedure, i.e. when the value of a variable is requested.
A special command, like "!" instead of "?", should simply run an external
routine.exw or routine.exe, with a prefixed name.
In this case the tool I have built could offer far greater possibilities
to the programmer, even if the variable cannot be changed from there,
which is a further option, but not a primary one.
As you can see this dEbUg tool works in two modes:
as a shell, it retains and displays a variable's content, without affecting
the calling prog.; as an openDialog( ) it takes the calling prog. waiting
until the window is exited and I believe that this feature could be well
integrated, opening a new chapter that can add much power to the current
tracing.
Regards,
Antonio Alessi
10. Re: Rob: List?
Rob:
I would like to see setjmp() longjmp() added to built-in functions.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
11. Re: Rob: List?
- Posted by Jeremy Peterson <ptl99 at hotmail.com>
Mar 21, 2006
-
Last edited Mar 22, 2006
I can see why Rob didn't do this before. Now everyone will be arguing about the
stuff he might add, and 1/3 will like a certain feature, 1/3 will hate it, 1/6
won't care, and 1/6 will just wish everyone else would shut up. :) It should be
pretty interesting though.
Jeremy
12. Re: Rob: List?
- Posted by Vincent <darkvincentdude at yahoo.com>
Mar 21, 2006
-
Last edited Mar 22, 2006
Jeremy Peterson wrote:
>
> I can see why Rob didn't do this before. Now everyone will be arguing about
> the stuff he might add, and 1/3 will like a certain feature, 1/3 will hate it,
> 1/6 won't care, and 1/6 will just wish everyone else would shut up. :) It
> should be pretty interesting though.
>
> Jeremy
Jeremy you know that its human nature for people to disagree each others ideas.
There is no way Robert or anyone can satisfy all. Personally I'm quite happy with
Rob's feature decisions except for that one detail with Danial's library.
Regards,
Vincent
13. Re: Rob: List?
- Posted by Jeremy Peterson <ptl99 at hotmail.com>
Mar 21, 2006
-
Last edited Mar 22, 2006
Vincent wrote:
>
> Jeremy Peterson wrote:
> >
> > I can see why Rob didn't do this before. Now everyone will be arguing about
> > the stuff he might add, and 1/3 will like a certain feature, 1/3 will hate
> > it,
> > 1/6 won't care, and 1/6 will just wish everyone else would shut up. :) It
> > should be pretty interesting though.
> >
> > Jeremy
>
> Jeremy you know that its human nature for people to disagree each others
> ideas.
> There is no way Robert or anyone can satisfy all. Personally I'm quite happy
> with Rob's feature decisions except for that one detail with Danial's library.
>
>
> Regards,
> Vincent
I'm just getting out some popcorn and sitting back to wait for the sparks to
start flying :). I do agree with you that its human nature for people to
disagree with each other... wait, no I don't :). I just think people get too
wrought up over certain features that they like or don't like.
Jeremy
14. Re: Rob: List?
- Posted by amux <jjsg at abc.se>
Mar 22, 2006
Jeremy Peterson wrote:
>
> I can see why Rob didn't do this before. Now everyone will be arguing about
> the stuff he might add, and 1/3 will like a certain feature, 1/3 will hate it,
> 1/6 won't care, and 1/6 will just wish everyone else would shut up. :) It
> should be pretty interesting though.
>
> Jeremy
And the rest! will/should try Delphi 3. :o}
/amux
15. Re: Rob: List?
Greg Haberek wrote:
> Don't forget my suggestion for a "-xp" feature for the WIN32
> Translator. OR an option to include resource files right in the
> command line for any translator (much more useful).
I hadn't forgotten (it was just last week), but I did forget to
add it to the list I posted.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Rob: List?
Bernie Ryan wrote:
> I would like to see setjmp() longjmp() added to built-in functions.
Those are low-level, unstructured, "goto-like" features.
I tried using them in a C program once, and eventually removed them
because of maintenance issues.
It's extremely unlikely I would ever implement them in Euphoria.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
17. Re: Rob: List?
Antonio Alessi wrote:
> I wonder if it could be possible to interface an external routine with the
> Trace( ) procedure, i.e. when the value of a variable is requested.
> A special command, like "!" instead of "?", should simply run an external
> routine.exw or routine.exe, with a prefixed name.
>
> In this case the tool I have built could offer far greater possibilities
> to the programmer, even if the variable cannot be changed from there,
> which is a further option, but not a primary one.
>
> As you can see this dEbUg tool works in two modes:
> as a shell, it retains and displays a variable's content, without affecting
>
> the calling prog.; as an openDialog( ) it takes the calling prog. waiting
> until the window is exited and I believe that this feature could be well
> integrated, opening a new chapter that can add much power to the current
> tracing.
I'll think about it for the future. Right now it's a lot
easier if I improve the variable display within my own
trace code, rather than trying to call a Euphoria routine
while I'm in the middle of executing some other Euphoria routine.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
18. Re: Rob: List?
CChris wrote:
> > 2. provide non-blocking I/O support to assist multitasking
> >
>
> Could you elaborate on this? If it means that Eu gets at last a set of file
>
> xplat commands which are not blocking, this is a welcome development.
> How would a progress or completion status for a I/O command be reported?
I haven't decided exactly how it will work, but Linux and Windows
have API calls that let you start some I/O, and then check a variable
or memory location to detect when it has finished. Meanwhile you can
do other things, rather than getting blocked at that point.
> > 3. Incorporate Daniel's multi-threaded non-blocking WIN32 API calls
> >
>
> Seems to overlap 2) above.
> Also, isn't it simpler to extend the semantics of
> "integer" to cover what ALL language around do, ie machine size integers
> (32 or 64 bit according to host hardware)?
I have no idea what integers have to do with non-blocking API calls,
but Euphoria's integers only use 31 bits, because (effectively)
there is a bit that says "this is not an integer, it's
a pointer to a larger object". Most other languages don't have
dynamic "larger objects" like Euphoria's sequences.
> And why do this in Windows only
> then? Looks like a half baked thing.
If it turns out to be easy, why not?
> > 6. front-end optimization of temps - fewer temps gives better performance
> >
> > 7. try again to speed up scanning/parsing/emiting (front end)
> Are you sure the time you'll spend in these tricky optimisations will not
> outweigh the sum of all execution time gains achieved through them?
> Perhaps most Eu users still use 486s or older, in which case these are
> relevant.
>
> If not, see my final comments.
>
> > 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
> >
>
> Ok, these are probably useful. When I *really* (and rarely) need raw speed,
>
> I directly code in C if asm is not an option. Here again, are these little
> optimisations worth your efforts?
When you optimize code you always run into diminishing returns.
You start off making some impressive improvements in speed with
very little effort. Eventually you start expending a lot of coding
effort just to shave 1% off the time. It's a judgement call
that I will have to make.
> Development and testing time is much larger than execution time,
> except for very specific tasks. Hence I would have welcome anything that makes
> Euphoria more flexible when it comes to coding, since bugs usually arise in
>
> the translation from the developer's goals and the constrained extent of what
>
> an interpreter can understand.
>
> But nothing in the above suggests any move towards this direction:
>
> - No provision for having a better control on what is, or is not, in
> namespaces,
> and specially in the unnamed one where all global symbol live;
I don't want to open the namespace issue.
I suspect most people don't use it, and don't fully understand it,
let alone wish to see it become more complicated.
> - No provision to allow passing arguments as reference to routines;
I have no desire to do that.
Euphoria should be based on values, not locations that can be
pointed-to and changed in subtle indirect ways.
> - No provision to allow more practical, yet structured, control over execution
> flow,
> which could take the form of:
> * optional argument to the exit statement: exit n loops/exit the loop with
> this
> label
> * a continue statement (skip remainder of current iteration)
> * a retry statement (restart current iteration)
> * a select (or switch, or inspect...) statement to handle multiple choices
There's nothing really wrong with adding a bunch of new control-flow
statements. It's simply my philosophy that Euphoria should have a
small number of control-flow statements. That might bother some
professional programmers in some instances, but will ease the
burden on beginners and hobbyists.
> Also, I really think some integrated tool to manage context switch in
> multitasked environments is needed, because the same library may be queried
>
> by different tasks "at the same time", ie while some not shareable data is
> being used. Most OSes know about thread vars, this could be the simplest way
>
> to go. Except DOS admittedly.
When more people start using multitasking, we'll have
a much better idea of what additional features are needed.
Note that I probably won't implement all of these features.
I could back out of something if it looks harder or
less useful than I thought at first. Also, I'm sure
I'll end up doing some other things that aren't on this list.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
19. 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
20. Re: Rob: List?
Robert Craig wrote:
> - try compressing ex.exe etc. with UPX instead of CauseWay - Matt Lewis
I thought that the exe's were already compressed with UPX? Or is/was it just
exw.exe? Forgive me if I've missed previous discussion on this issue.
-- Brian
21. Re: Rob: List?
Brian Broker wrote:
>
> Robert Craig wrote:
> > - try compressing ex.exe etc. with UPX instead of CauseWay - Matt Lewis
>
> I thought that the exe's were already compressed with UPX? Or is/was it just
> exw.exe? Forgive me if I've missed previous discussion on this issue.
I've been using UPX, except on DOS, where the CauseWay DOS extender
comes with its own exe compressor.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
22. Re: Rob: List?
Cuvier Christian wrote:
>> Subject: Re: Rob: List?
When we read "RE: Digest for EUforum at topica.com, issue 5758" on the
main Euforum page, how can we know that the concerning post contains
text about the topic "Rob: List?"??
So in your posts use the proper subject, please. Thanks!
>> posted by: Robert Craig <rds at RapidEuphoria.com>
>>
>> CChris wrote:
>>>> 2. provide non-blocking I/O support to assist multitasking
>>>>
>>>
>>> Could you elaborate on this? If it means that Eu gets at
>> last a set of file
>>>
>>> xplat commands which are not blocking, this is a welcome
>> development.
>>> How would a progress or completion status for a I/O command
>> be reported?
>>
>> I haven't decided exactly how it will work, but Linux and Windows
>> have API calls that let you start some I/O, and then check a variable
>> or memory location to detect when it has finished. Meanwhile you can
>> do other things, rather than getting blocked at that point.
>>
>
> Of course, and the current mechanisms in Eu already allow to wrap and use
> them. So what is this support made of? That was my original question.
Wrapping the API calls yourself will take you more time for writing and
bug searching/fixing. In this post
<http://www.listfilter.com/EUforum/m7071.html> you wrote that you want
to save this time -- and so do I.
I want to write "pure Euphoria" programs, if possible. Maybe wrapping
those API calls is so complicated, that I'm not able to do so. Of course
Rob's programming skills are much, much better than mine, so he is able
do write stuff, that would not be possible for me. But the result of
Rob's work is a simple and easy to use programming language, so that I
can use it to write programs -- you see the principle?
So "We can do this ourselves in C or assembler or whatever." holds only
true for a little number of Eu programmers, and it's not an argument
when talking about improvement of Euphoria at all.
Additionally, most Eu routines are cross-platform. So why should I
want to write my own Windows wrappers, and when I've changed to Linux
write again Linux wrappers for the same stuff? Why should I want to do
so, when Rob offers to implement those very useful routines for the next
Eu version???
<snip>
Regards,
Juergen
--
Have you read a good program lately?
23. Re: Rob: List?
- Posted by Robert Craig <rds at RapidEuphoria.com>
Mar 22, 2006
-
Last edited Mar 23, 2006
CChris writes:
> By the way, you had mentioned a possibility of adding exception handling to
> Eu. That could have been useful, but disappeared from your list. Are you
> still considering this move?
I don't recall ever seriously proposing adding
exception handling, beyond the global crash_routine() mechanism
that we have already.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
24. Re: Rob: List?
- Posted by menno <m.s.ter.haseborg at home.nl>
Mar 23, 2006
-
Last edited Mar 24, 2006
May a stubid , but I have implented a OPEN for a IP number in my version of PEU
.
As file=open("localserver",mode) . mode canbe s=server a=accept c=client .
Wich this option you can connect to a server or client IP name/number . The
protocal handling can be done in EU (or PEU) .
Windows handling is very well done by WINLIB but in Linux is a bit of a problem
.
The GraphApp has be wraped to Euphoria and works well in Linux as in MSWindows ,
give it a try I think .
I thing it is a good idea to remove Ncurses from the Linux version .
Most of the things can be done by ANSI code even POSITION() .
Only if you run in RXVT you need other character set to get the pc850 code back
, that can be a problem because you only can do that as superuser to install them
.
Mouse handling in Linux will be still a problem , in console mode you nees GMP
in RXVT you can use a ANSI code to get the mouse .
And the are not the same !
Sorry my bad english , I hope it will be usefull . Greatings Menno .
25. Re: Rob: List?
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.
[snipped the list]
> 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.
I'm looking forward to see the items on the list implemented in Euphoria.
Two more suggestions:
a) Make function message_box() cross-platform.
b) Add a new function, say:
i1 = popup_box(s1, s2, x, i2)
which would be similar to message_box(), but with the additional
parameter i2 for specifying the timeout. If e.g. i2=30, then the
box will automatically disappear after 30 seconds.
Regards,
Juergen
--
Have you read a good program lately?
26. Re: Rob: List?
Juergen Luethje wrote:
> Two more suggestions:
> a) Make function message_box() cross-platform.
> b) Add a new function, say:
> i1 = popup_box(s1, s2, x, i2)
>
> which would be similar to message_box(), but with the additional
> parameter i2 for specifying the timeout. If e.g. i2=30, then the
> box will automatically disappear after 30 seconds.
Thanks for the suggestions.
I'll add them to my master list,
but I don't think I'll get to them for 3.0.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
