1. version of euphoria ZIP
- Posted by Bernie Ryan <xotron at bluefrog.com> Nov 04, 2005
- 453 views
- Last edited Nov 05, 2005
I think that if RDS is not going to bother to supply a zipped version of euphoria that they should at least have a list in the documentation indicating which files are required to run in windows and which files are required to run in DOS. The document directory is filled with useless files trying to convince users why they should use euphoria. Throw these docs out and put only useful information in the docs. Bernie My files in archive: w32engin.ew mixedlib.e eu_engin.e win32eru.exw Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
2. Re: version of euphoria ZIP
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 05, 2005
- 444 views
Bernie Ryan wrote: > > > I think that if RDS is not going to bother to supply a zipped > version of euphoria that they should at least have a list in the > documentation indicating which files are required to run in windows > and which files are required to run in DOS. The document directory > is filled with useless files trying to convince users why they > should use euphoria. Throw these docs out and put only useful > information in the docs. > > > Bernie > > My files in archive: > w32engin.ew mixedlib.e eu_engin.e win32eru.exw > > Can be downloaded here: > <a > href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a> Hi, Bernie It's pretty easy to make your own ZIPed copy of the Euphoria directory. Maybe I'll post one later tonight on my Yahoo Euphoria group. You can get a pretty good idea what is required to run Euphoria by looking at Euphoria\Bin\Bin.doc. The only files neccessary are the individual interpreter executables. Most of the standard library is wrappers for machine_proc/func routines, so in many cases you dont need it (I always use machine_proc/func; less "including" overhead that way). The documentation provided with Euphoria is excellent and you know it! C.htm/doc provide valid reasons why Euphoria is more productive than C/C++ in most cases, though some points might be repeated. Heck, pretty much any language is nicer than C or C++. The GIF banner on the main webpage is half true, but pretty much just marketing. Euphoria isnt more powerful than C++ (apples or oranges anyone?), but it sure is more "cleaner" than most BASIC dialects. RDS should do more marketing/advertising so more folks can find out about Euphoria, and make our little family bigger. Regards, Vincent ---------------------------------------------- ___ __________ ___ /__/\ /__________\ |\ _\ \::\'\ //::::::::::\\ |'|::| \::\'\ //:::_::::_:::\\ |'|::| \::\'\ //::/ |::| \::\\ |'|::| \::\'\ //::/ |::| \::\\|'|::| \::\'\__//::/ |::| \::\|'|::| \::\','/::/ |::| \::\\|::| \::\_/::/ |::| \::\|::| \::,::/ |::| \:::::| \___/ |__| \____| .``. ',,'
3. Re: version of euphoria ZIP
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 05, 2005
- 463 views
Vincent wrote: > Bernie Ryan wrote: >> >> I think that if RDS is not going to bother to supply a zipped >> version of euphoria that they should at least have a list in the >> documentation indicating which files are required to run in windows >> and which files are required to run in DOS. The document directory >> is filled with useless files trying to convince users why they >> should use euphoria. Throw these docs out and put only useful >> information in the docs. >> >> > Hi, Bernie > > It's pretty easy to make your own ZIPed copy of the Euphoria directory. > Maybe I'll post one later tonight on my Yahoo Euphoria group. > > You can get a pretty good idea what is required to run Euphoria by > looking at Euphoria\Bin\Bin.doc. The only files neccessary are the > individual interpreter executables. Most of the standard library is > wrappers for machine_proc/func routines, so in many cases you dont need > it (I always use machine_proc/func; less "including" overhead that way). I don't think that this is a good idea, because it reduces the readability of the code. > The documentation provided with Euphoria is excellent and you know it! > C.htm/doc provide valid reasons why Euphoria is more productive than > C/C++ in most cases, though some points might be repeated. Heck, pretty > much any language is nicer than C or C++. > > The GIF banner on the main webpage is half true, but pretty much just > marketing. Euphoria isnt more powerful than C++ (apples or oranges > anyone?), but it sure is more "cleaner" than most BASIC dialects. > > RDS should do more marketing/advertising so more folks can find out > about Euphoria, and make our little family bigger. > > > Regards, > Vincent > > ---------------------------------------------- > Ate you interested in an easy way to reduce "overhead" in e-mails? ) Regards, Juergen -- Have you read a good program lately?
4. Re: version of euphoria ZIP
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 05, 2005
- 457 views
Juergen Luethje wrote: > > Vincent wrote: > > > Bernie Ryan wrote: > >> > >> I think that if RDS is not going to bother to supply a zipped > >> version of euphoria that they should at least have a list in the > >> documentation indicating which files are required to run in windows > >> and which files are required to run in DOS. The document directory > >> is filled with useless files trying to convince users why they > >> should use euphoria. Throw these docs out and put only useful > >> information in the docs. > >> > >> > > Hi, Bernie > > > > It's pretty easy to make your own ZIPed copy of the Euphoria directory. > > Maybe I'll post one later tonight on my Yahoo Euphoria group. > > > > You can get a pretty good idea what is required to run Euphoria by > > looking at Euphoria\Bin\Bin.doc. The only files neccessary are the > > individual interpreter executables. Most of the standard library is > > wrappers for machine_proc/func routines, so in many cases you dont need > > it (I always use machine_proc/func; less "including" overhead that way). > > I don't think that this is a good idea, because it reduces the > readability of the code. Not really... you can use a constant in place of the routine #, plus you can use comments. constant SEEK = 19 machine_proc(SEEK, {fn, -1}) -- seek I wonder what routine this can be? Gee gosh uuhouh... I havent the slightest clue doc. It gets even easier once you memorize most or all the specific IDs for routines. The neat thing with machine_func is you can use machine_proc and ignore return values of functions! No need for any dummy "ignore" routines, or assigning variables. Of course if the routine is written entirely in Euphoria code & is long, then you would want to "include" it, instead of copying+pasting the whole routine into your application or library. > > > The documentation provided with Euphoria is excellent and you know it! > > C.htm/doc provide valid reasons why Euphoria is more productive than > > C/C++ in most cases, though some points might be repeated. Heck, pretty > > much any language is nicer than C or C++. > > > > The GIF banner on the main webpage is half true, but pretty much just > > marketing. Euphoria isnt more powerful than C++ (apples or oranges > > anyone?), but it sure is more "cleaner" than most BASIC dialects. > > > > RDS should do more marketing/advertising so more folks can find out > > about Euphoria, and make our little family bigger. > > > > > > Regards, > > Vincent > > > > ---------------------------------------------- > > > > Ate you interested in an easy way to reduce "overhead" in e-mails? ) This is nothing, as I'm sure you can recall the numerous times I have posted 1-2 page essays. Besides you dont need to use the Topica email delivery, just use the EUforum web interface and RSS feeds. > > Regards, > Juergen > > -- > Have you read a good program lately? > > Regards, Vincent ---------------------------------------------- ___ __________ ___ /__/\ /__________\ |\ _\ \::\'\ //::::::::::\\ |'|::| \::\'\ //:::_::::_:::\\ |'|::| \::\'\ //::/ |::| \::\\ |'|::| \::\'\ //::/ |::| \::\\|'|::| \::\'\__//::/ |::| \::\|'|::| \::\','/::/ |::| \::\\|::| \::\_/::/ |::| \::\|::| \::,::/ |::| \:::::| \___/ |__| \____| .``. ',,'
5. Re: version of euphoria ZIP
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 05, 2005
- 445 views
Vincent wrote: > Juergen Luethje wrote: >> >> Vincent wrote: <snip> >>> You can get a pretty good idea what is required to run Euphoria by >>> looking at Euphoria\Bin\Bin.doc. The only files neccessary are the >>> individual interpreter executables. Most of the standard library is >>> wrappers for machine_proc/func routines, so in many cases you dont need >>> it (I always use machine_proc/func; less "including" overhead that way). >> >> I don't think that this is a good idea, because it reduces the >> readability of the code. > > Not really... you can use a constant in place of the routine #, plus > you can use comments. > > constant SEEK = 19 > machine_proc(SEEK, {fn, -1}) -- seek A known problem concerning comments is, that it can happen that the program is changed/updated, and the comments remain unchanged. Of course I also use comments, but I want to say that good readable code that doesn't need comments is better than writing bad readable code, and trying to make it more readable by adding comments. Using a constant in place of the routine # leads to readable code, yes. Then instead of the "include overhead" we have "constant overhead" ... > I wonder what routine this can be? > Gee gosh uuhouh... I havent the slightest > clue doc. It gets even easier once you > memorize most or all the specific IDs for > routines. > > The neat thing with machine_func is you can use machine_proc and ignore > return values of functions! > > No need for any dummy "ignore" routines, or assigning variables. I see that this might be handy. > Of course if the routine is written entirely in Euphoria code & is long, > then you would want to "include" it, instead of copying+pasting the > whole routine into your application or library. > >> >>> The documentation provided with Euphoria is excellent and you know it! >>> C.htm/doc provide valid reasons why Euphoria is more productive than >>> C/C++ in most cases, though some points might be repeated. Heck, pretty >>> much any language is nicer than C or C++. >>> >>> The GIF banner on the main webpage is half true, but pretty much just >>> marketing. Euphoria isnt more powerful than C++ (apples or oranges >>> anyone?), but it sure is more "cleaner" than most BASIC dialects. >>> >>> RDS should do more marketing/advertising so more folks can find out >>> about Euphoria, and make our little family bigger. >>> >>> >>> Regards, >>> Vincent >>> >>> ---------------------------------------------- >>> >> >> Ate you interested in an easy way to reduce "overhead" in e-mails? ) > > This is nothing, as I'm sure you can recall the numerous times I have > posted 1-2 page essays. Besides you dont need to use the Topica email > delivery, just use the EUforum web interface and RSS feeds. I'm sorry for producing this misunderstanding. With "overhead" I definitely didn't mean any *text* that you wrote! And I see now that I forgot to quote the concerning part of your message. To make it clear now, I mean this: > ---------------------------------------------- > Regards, Juergen -- Have you read a good program lately?
6. Re: version of euphoria ZIP
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 05, 2005
- 434 views
Juergen Luethje wrote: > Vincent wrote: > >> Juergen Luethje wrote: >>> >>> Vincent wrote: <snip> >>>> Regards, >>>> Vincent >>>> >>>> ---------------------------------------------- (*) >>> Ate you interested in an easy way to reduce "overhead" in e-mails? ) >> >> This is nothing, as I'm sure you can recall the numerous times I have >> posted 1-2 page essays. Besides you dont need to use the Topica email >> delivery, just use the EUforum web interface and RSS feeds. > > I'm sorry for producing this misunderstanding. With "overhead" I definitely > didn't mean any *text* that you wrote! > And I see now that I forgot to quote the concerning part of your message. > To make it clear now, I mean this: > >> ---------------------------------------------- (*) Now I realize that I didn't forget to quote the concerning part, but it was removed from my previous mail, and from the mail before the previous mail, too. At the places where it now reads (*) there have been 14 lines that showed something like "vin". This was just too funny when you talked about reduction of overhead. Regards, Juergen -- Have you read a good program lately?
7. Re: version of euphoria ZIP
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 05, 2005
- 437 views
Juergen Luethje wrote: > A known problem concerning comments is, that it can happen that the > program is changed/updated, and the comments remain unchanged. > Of course I also use comments, but I want to say that good readable code > that doesn't need comments is better than writing bad readable code, and > trying to make it more readable by adding comments. Fair enough, however, I personally dont make mistakes of that kind. I normally use comments sparingly. > Using a constant in place of the routine # leads to readable code, yes. > Then instead of the "include overhead" we have "constant overhead" ... Constant overhead is trivial in comparison with include overhead. But for the record, you get both, along with some extra file scanning/parsing overhead with the desired method. I dont use constants with these machine routines anyway, comments work fine for me. Euphoria remains very fast even with significant program inefficiencies. So for most people who figure Euphoria is fast enough, they dont really need to bother with silly stuff like this. But since I am a speed freak, all my code has to be efficient & optimized. > I see that this might be handy. Sure, ignore() can be quite useful with some Euphoria coded functions that return unneeded data. > I'm sorry for producing this misunderstanding. With "overhead" I definitely > didn't mean any *text* that you wrote! > And I see now that I forgot to quote the concerning part of your message. > To make it clear now, I mean this: Maybe you mean my "VIN" ascii art too. I'll get rid of it, Rob probably has tight webspace for listfilter.com anyway, I wouldn't want stupid ascii art wasting space. > Regards, > Juergen Regards, Vincent
8. Re: version of euphoria ZIP
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 05, 2005
- 445 views
Vincent wrote: > Juergen Luethje wrote: > >> A known problem concerning comments is, that it can happen that the >> program is changed/updated, and the comments remain unchanged. >> Of course I also use comments, but I want to say that good readable code >> that doesn't need comments is better than writing bad readable code, and >> trying to make it more readable by adding comments. > > Fair enough, however, I personally dont make mistakes of that kind. Ohhhh... > I normally use comments sparingly. Due to your "creative quoting", some text is missing here. Previously I had written: | I don't think that this is a good idea, because it reduces the | readability of the code. And your reply was: | Not really... you can use a constant in place of the routine #, plus | you can use comments. So you probably should decide, whether or not you think comments should be used to make bad readable code more readable. >> Using a constant in place of the routine # leads to readable code, yes. >> Then instead of the "include overhead" we have "constant overhead" ... > > Constant overhead is trivial in comparison with include overhead. But > for the record, you get both, along with some extra file > scanning/parsing overhead with the desired method. I dont use constants > with these machine routines anyway, comments work fine for me. So your code clearly is less readable and/or less maintainable than "normal" code. While you are of course free to do what you want privately, obviously this way of writing code cannot be recommended in general. <snip> Regards, Juergen -- Have you read a good program lately?
9. Re: version of euphoria ZIP
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 05, 2005
- 453 views
Juergen Luethje wrote: > > Due to your "creative quoting", some text is missing here. > > Previously I had written: > | I don't think that this is a good idea, because it reduces the > | readability of the code. > > And your reply was: > | Not really... you can use a constant in place of the routine #, plus > | you can use comments. > > So you probably should decide, whether or not you think comments should > be used to make bad readable code more readable. If you read what I said, I said "you" can use constants & comments. But when I use machine_proc/func routines, I just use comments. I dont like stuffing my apps or libs with mumbo jumbo, that is what documentation is for, besides enough commenting can contriubute to slightly slower loading time. > So your code clearly is less readable and/or less maintainable than > "normal" code. While you are of course free to do what you want > privately, obviously this way of writing code cannot be recommended in > general. My code is very easy to read and maintain, simply using some machine specific routines w/ comments isn't going to make my code any less readable. You know we can debate about this for centuries, but in the end we're just gonna do what we want anyway. Obviously effeciency is not top priority for you, but that is quite ok. > Regards, > Juergen Regards, Vincent
10. Re: version of euphoria ZIP
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 06, 2005
- 458 views
- Last edited Nov 07, 2005
Vincent wrote: > Juergen Luethje wrote: <snip> >> So your code clearly is less readable and/or less maintainable than >> "normal" code. While you are of course free to do what you want >> privately, obviously this way of writing code cannot be recommended in >> general. > > My code is very easy to read and maintain, simply using some machine > specific routines w/ comments isn't going to make my code any less > readable. For most people it's not hard to understand that code such as machine_proc(64, 3) is not good readable. And I had told you about well known potential problems concerning comments, but I learned that you believe you are the only person on this planet who is "immune" to certain mistakes. > You know we can debate about this for centuries, but in the end we're > just gonna do what we want anyway. Obviously effeciency is not top > priority for you, but that is quite ok. This is not "obvious", but false and a simplistic statement. Writing efficient code does not just mean using some machine specific routines with comments. You might want to read the Euphoria documentation carefully, in order to learn more about writing efficient code. For instance I use profile and profile_time to examine programs. Depending on the program, there are several ways to make it more efficient. Sometimes I write parts of a program in assembler. Regards, Juergen -- Have you read a good program lately?
11. Re: version of euphoria ZIP
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 06, 2005
- 453 views
- Last edited Nov 07, 2005
Juergen Luethje wrote: > > Vincent wrote: > > > Juergen Luethje wrote: > > <snip> > > >> So your code clearly is less readable and/or less maintainable than > >> "normal" code. While you are of course free to do what you want > >> privately, obviously this way of writing code cannot be recommended in > >> general. > > > > My code is very easy to read and maintain, simply using some machine > > specific routines w/ comments isn't going to make my code any less > > readable. > > For most people it's not hard to understand that code such as > machine_proc(64, 3) machine_proc(64, 3) -- sleep machine_proc(SLEEP, 3) Those are pretty readable to me. > is not good readable. And I had told you about well known potential > problems concerning comments, but I learned that you believe you are the > only person on this planet who is "immune" to certain mistakes. Do you ever mistake 2+2 for being 5? Probably not. Do you forget how to spell your name? Probably not. Do you forget how to get to work everyday? Not usually. Do you forget how to drive? Not if you do it all the time. My point is these common activities become automatic, where you dont have to think about it, you just do it. In my case this also goes for adding and/or modifing comments next to certain pieces of my code. > > You know we can debate about this for centuries, but in the end we're > > just gonna do what we want anyway. Obviously effeciency is not top > > priority for you, but that is quite ok. > > This is not "obvious", but false and a simplistic statement. > Writing efficient code does not just mean using some machine specific > routines with comments. You might want to read the Euphoria > documentation carefully, in order to learn more about writing efficient > code. Well excuse me, when did I *ever* imply that using machine specific routines is the only way to improve program efficency? One of the most important factors in determinding efficency has to do with the algorithms one develops. FYI sir, I have read the Euphoria documentation several times, and overlook perform.htm/doc tips with everything I do in Euphoria. > For instance I use profile and profile_time to examine programs. > Depending on the program, there are several ways to make it more > efficient. Sometimes I write parts of a program in assembler. I suppose peeking & poking machine code is easily readable too, correct? > Regards, > Juergen Regards, Vincent
12. Re: version of euphoria ZIP
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Nov 07, 2005
- 468 views
Vincent wrote: > > Juergen Luethje wrote: > > > Using a constant in place of the routine # leads to readable code, yes. > > Then instead of the "include overhead" we have "constant overhead" ... > > Constant overhead is trivial in comparison with include overhead. But for the > record, you get both, along with some extra file scanning/parsing overhead > with > the desired method. I dont use constants with these machine routines anyway, > comments work fine for me. > > Euphoria remains very fast even with significant program inefficiencies. So > for > most people who figure Euphoria is fast enough, they dont really need to > bother > with silly stuff like this. But since I am a speed freak, all my code has to > be > efficient & optimized. > I think you're a great example of premature optimization. If you go around taking out all the machine_func wrappers, you probably haven't saved any noticeable time in either parsing or execution. Most of your optimization effort should usually be directed at better algorithmic solutions. You can often squeeze out a few percent by inlining certain things, but only if they're inside of inner loops or something. Matt Lewis
13. Re: version of euphoria ZIP
- Posted by Chris Burch <chriscrylex at aol.com> Nov 07, 2005
- 469 views
Matt Lewis wrote: > > Vincent wrote: > > > > Juergen Luethje wrote: > > > > > Using a constant in place of the routine # leads to readable code, yes. > > > Then instead of the "include overhead" we have "constant overhead" ... > > > > Constant overhead is trivial in comparison with include overhead. But for > > the > > record, you get both, along with some extra file scanning/parsing overhead > > with > > the desired method. I dont use constants with these machine routines anyway, > > comments work fine for me. > > > > Euphoria remains very fast even with significant program inefficiencies. So > > for > > most people who figure Euphoria is fast enough, they dont really need to > > bother > > with silly stuff like this. But since I am a speed freak, all my code has to > > be > > efficient & optimized. > > > > I think you're a great example of premature optimization. If you go around > taking out all the machine_func wrappers, you probably haven't saved any > noticeable time in either parsing or execution. Most of your optimization > effort should usually be directed at better algorithmic solutions. You > can often squeeze out a few percent by inlining certain things, but only > if they're inside of inner loops or something. > > Matt Lewis I get about 10 emails a day offering me ways to cope with that! Chris http://members.aol.com/chriscrylex/euphoria.htm http://uboard.proboards32.com/ http://members.aol.com/chriscrylex/EUSQLite/eusql.html
14. Re: version of euphoria ZIP
- Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 09, 2005
- 455 views
Vincent wrote: > Juergen Luethje wrote: >> >> Vincent wrote: [snipped (not necessary to repeat the same stuff over and over again)] >>> Obviously effeciency is not top priority for you, but that is quite ok. >> >> This is not "obvious", but false and a simplistic statement. >> Writing efficient code does not just mean using some machine specific >> routines with comments. You might want to read the Euphoria >> documentation carefully, in order to learn more about writing efficient >> code. > > Well excuse me, when did I *ever* imply that using machine specific > routines is the only way to improve program efficency? No, you did not imply that it's the *only* way to improve program efficency. But when you write: "Obviously effeciency is not top priority for you" just because I do not agree with you, that generally using machine_proc() is a good idea, then that statement implies that you think it's an *important* way to do so. But that is not the case (as Matt also has pointed out the day before yesterday). > One of the most important factors in determinding efficency has to do > with the algorithms one develops. > > FYI sir, I have read the Euphoria documentation several times, and > overlook perform.htm/doc tips with everything I do in Euphoria. OK, then you probably know some ways how to really make a program more efficient. >> For instance I use profile and profile_time to examine programs. >> Depending on the program, there are several ways to make it more >> efficient. Sometimes I write parts of a program in assembler. > > I suppose peeking & poking machine code is easily readable too, correct? As I wrote, I do so *sometimes*, in selected cases. I'm not advocating for writing all programms in assembler. It's like in medicine: We should get a correct diagnosis first, in order to be able to choose an appropriate therapy. Regards, Juergen -- Have you read a good program lately?
15. Re: version of euphoria ZIP
- Posted by Vincent <darkvincentdude at yahoo.com> Nov 10, 2005
- 445 views
Juergen Luethje wrote: > > Vincent wrote: > > > Juergen Luethje wrote: > >> > >> Vincent wrote: > > [snipped (not necessary to repeat the same stuff over and over again)] > > >>> Obviously effeciency is not top priority for you, but that is quite ok. > >> > >> This is not "obvious", but false and a simplistic statement. > >> Writing efficient code does not just mean using some machine specific > >> routines with comments. You might want to read the Euphoria > >> documentation carefully, in order to learn more about writing efficient > >> code. > > > > Well excuse me, when did I *ever* imply that using machine specific > > routines is the only way to improve program efficency? > > No, you did not imply that it's the *only* way to improve program > efficency. But when you write: > "Obviously effeciency is not top priority for you" > just because I do not agree with you, that generally using machine_proc() > is a good idea, then that statement implies that you think it's an > *important* way to do so. But that is not the case (as Matt also has > pointed out the day before yesterday). > Hi Juergen, It's not "important" sort of speak, but despite what Matt said, it *is* one of the *many* things you can do to improve program efficiency, in addition to improving your algorithms. It doesn't matter which way you choose as machine_proc/func is used anyway.. But directly using them eliminates the unnecessary including, scanning/parsing, extra subroutine calling, type definition (minuscule), variable (when using machine_proc instead of machine_func), and constant overhead. All this overhead is realatively small and hardly casts its shadow on Euphoria's blazing execution, but internally its quite noticable. Add a trace(1) into scanner.e then step through a few programs with the PD- source... perhaps you will notice all the expensive internal process of including files and scanning/parsing them. I'm not against "including" in general, I'm just suggesting not to abuse the feature if efficiency is really important to you. > > One of the most important factors in determinding efficency has to do > > with the algorithms one develops. > > > > FYI sir, I have read the Euphoria documentation several times, and > > overlook perform.htm/doc tips with everything I do in Euphoria. > > OK, then you probably know some ways how to really make a program more > efficient. > > >> For instance I use profile and profile_time to examine programs. > >> Depending on the program, there are several ways to make it more > >> efficient. Sometimes I write parts of a program in assembler. > > > > I suppose peeking & poking machine code is easily readable too, correct? > > As I wrote, I do so *sometimes*, in selected cases. I'm not advocating > for writing all programms in assembler. > It's like in medicine: We should get a correct diagnosis first, in order > to be able to choose an appropriate therapy. > Thats fine... you have your reasons to use it as I have mine to use machine routines. Since I dont really know any ASM, this is not an option for me. So I have to come up with other solutions like using machine routines to compensate. Of course using machine code offers complete low-level control, so eventually I'll need to at least partially understand it. > Regards, > Juergen > > -- > Have you read a good program lately? > > Regards, Vincent