1. Rob: List?
- Posted by Antonio Alessi <a.admin at myway.it> Apr 01, 2006
- 607 views
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
- 582 views
- 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
- 590 views
- 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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 21, 2006
- 567 views
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?
- Posted by Vincent <darkvincentdude at yahoo.com> Mar 21, 2006
- 564 views
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?
- Posted by "Greg Haberek" <ghaberek at gmail.com> Mar 21, 2006
- 583 views
> - "-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?
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 21, 2006
- 574 views
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?
- Posted by Vincent <darkvincentdude at yahoo.com> Mar 21, 2006
- 588 views
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?
- Posted by Antonio Alessi <a.admin at myway.it> Mar 21, 2006
- 563 views
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?
- Posted by Bernie Ryan <xotron at bluefrog.com> Mar 21, 2006
- 567 views
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
- 566 views
- 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
- 565 views
- 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
- 583 views
- 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
- 560 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 22, 2006
- 551 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 22, 2006
- 556 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 22, 2006
- 544 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 22, 2006
- 563 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 22, 2006
- 565 views
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?
- Posted by Brian Broker <brian_broker at yahoo.com> Mar 22, 2006
- 577 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 22, 2006
- 566 views
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?
- Posted by Juergen Luethje <j.lue at gmx.de> Mar 22, 2006
- 555 views
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
- 584 views
- 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
- 564 views
- 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?
- Posted by Juergen Luethje <j.lue at gmx.de> Mar 25, 2006
- 574 views
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?
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 25, 2006
- 569 views
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