1. version of euphoria ZIP
- Posted by Bernie Ryan <xotron at bluefrog.com>
Nov 04, 2005
-
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
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
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
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
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
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
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
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
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
-
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
-
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
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
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
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
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
