1. Why some people have not upgraded
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
I think some people consider Euphoria v2.5 as being a downgrade from Euphoria
v2.4...
With the introduction of Euphoria v2.5 we lost:
1. Dynamic including (all methods except one)
2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
4. Include statement hack
3. Bound file tracing
5. Shrouded includes
6. Fast loading time
7. Block Parsing
Next release:
8. Twenty percent slowdown on recursive
operations in single task interpreted
programs and libraries (all currently).
Regards,
Vincent
2. Re: Why some people have not upgraded
- Posted by Al Getz <Xaxo at aol.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Vincent wrote:
>
> I think some people consider Euphoria v2.5 as being a downgrade from Euphoria
> v2.4...
>
> With the introduction of Euphoria v2.5 we lost:
>
> 1. Dynamic including (all methods except one)
> 2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
> 4. Include statement hack
> 3. Bound file tracing
> 5. Shrouded includes
> 6. Fast loading time
> 7. Block Parsing
>
> Next release:
>
> 8. Twenty percent slowdown on recursive
> operations in single task interpreted
> programs and libraries (all currently).
>
>
> Regards,
> Vincent
Hi Vincent,
I hadnt upgraded yet because of the slowdown during load time.
It's quite a bit on my 650MHz machine for programs that i use
quite often, yet with v2.4 it's very fast.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
3. Re: Why some people have not upgraded
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Vincent wrote:
> With the introduction of Euphoria v2.5 we lost:
>
> 1. Dynamic including (all methods except one)
This never worked at all with translating or binding,
and didn't work that well with interpreting.
> 2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
You can still do this. What are you talking about?
> 4. Include statement hack
I don't know what that is, but it doesn't sound very valuable.
> 3. Bound file tracing
You could never trace a bound file, unless it
was bound as a single monolithic clear source file.
Why not trace your original source? Or give your user the required
unbound source files in a directory along with the interpreter executable?
No need to install Euphoria.
> 5. Shrouded includes
Very rarely used, and it didn't work very well.
> 6. Fast loading time
You keep harping about this because you
are obsessed with speed, but most people will notice
little difference between a program that parses
in .1 seconds, versus one that parses in .8 seconds,
especially when Windows adds it's own variable start-up delay to
any program that you run, written in any language.
Over time, the percentage of people using ancient sub-1Ghz
machines will decline, and people will wonder what you are
going on about. It seemed to be mainly the IDE that people
complained about, but not many programs are over 100,000 lines
of source.
> 7. Block Parsing
Execution could sometimes
be usefully performed before parsing was complete,
allowing it to happen slightly sooner, while not
catching syntax errors later in a program, and requiring
all front-end data structures to be kept in memory during
program execution.
> Next release:
>
> 8. Twenty percent slowdown on recursive
> operations in single task interpreted
> programs and libraries (all currently).
You only know what I mentioned to you in private correspondence,
and I don't think you understood what I said. Recursive routines
will be as fast as ever using the Translator. Recursive routines
will *not* run 20% slower with the interpreter. That 20% figure
was just a number I pulled out of thin air as an estimate of
the slowdown of *one IL opcode* used in recursion,
not recursive routines as a whole. And there are ways that I can
speed it up.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Why some people have not upgraded
- Posted by C Bouzy <eucoder at hotmail.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
> With the introduction of Euphoria v2.5 we lost:
>
> 1. Dynamic including (all methods except one)
I still do not see why this is so important.
> 2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
We can still do this.
> 4. Include statement hack
Whats that?
> 3. Bound file tracing
How many users really needed that?
> 5. Shrouded includes
I miss that one.
> 6. Fast loading time
Also not an issue.
> 7. Block Parsing
I have no opinion for this.
> 8. Twenty percent slowdown on recursive
> operations in single task interpreted
> programs and libraries (all currently).
I wasn't aware of this, are you sure?
At the moment EU is able to handle all of my needs except I could use
non-blocking support. Once that is added I will be happy :)
----If you continue to do what you have always done,
you will get what you have always gotten.----
5. Re: Why some people have not upgraded
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 29, 2005
-
Last edited Dec 30, 2005
Robert Craig wrote:
Hi Rob,
> This never worked at all with translating or binding,
> and didn't work that well with interpreting.
Of course it didn't work with translating or binding, and it worked fine with
interpreting. Now there is my library, but all the other ones are broken. My
library isn't really dynamic though, it basically restarts the users' program
with a dynamically updating include list.
> You can still do this. What are you talking about?
The incompatability introduced with the '$' symbol. I didn't know how to put it
into words on one line. This wasn't an issue for me, but pissed off a few people;
Mario Steele was one of them, who now programs with Ruby.
> I don't know what that is, but it doesn't sound very valuable.
The include hack was one of the most useful bugs. It gave us ability to include
files with the same name in different file paths. Now Euphoria always treats
files with the same name as if they were identical regardless of their location.
This would likely cause a big problem if Euphoria ever became popular and people
started to write libraries with the same file names but had different content.
We'd waste literally hours yearly renaming files just so they could work with
others and our own. We'd have to do it over and over again with every update of
the 3rd party libraries.
This issue alone prevents Euphoria from nicely accommodating a large user base
with 10,000 or 100,000's of contributed programs and libraries. The chances for
identical file names is very high with that many contributions, especially since
programmers often use simular naming schemes. This is one of the biggest barriers
with Euphoria's language design.
You could easily change this in the source, but you just don't want to for some
ludicrous reason.
> You could never trace a bound file, unless it
> was bound as a single monolithic clear source file.
> Why not trace your original source? Or give your user the required
> unbound source files in a directory along with the interpreter executable?
> No need to install Euphoria.
This isn't my issue, I don't even use the binder or shrouder. This is a problem
for Jonas Temple; I'm just siting it here for the purpose of this list.
> You keep harping about this because you
> are obsessed with speed, but most people will notice
> little difference between a program that parses
> in .1 seconds, versus one that parses in .8 seconds,
> especially when Windows adds it's own variable start-up delay to
> any program that you run, written in any language.
> Over time, the percentage of people using ancient sub-1Ghz
> machines will decline, and people will wonder what you are
> going on about. It seemed to be mainly the IDE that people
> complained about, but not many programs are over 100,000 lines
> of source.
It's *WAY* more than just the IDE. It's any medium to large size program. It's a
difference between seconds and minutes on my old systems!! You think this isn't a
big deal... think again! Euphoria is suppost to run fine on 386-486 machines, but
it doesn't. I can go eat lunch while waiting for a large/huge program to load
with v2.5 on my 386, and if the program crashes I have to do it again! With my
Pentium 4, it's a matter of milli-seconds and several seconds, but that is still
significant when considering several seconds is barely acceptable with today's
C/C++ optimizing compilers.
Imagine if Euphoria ever become popular and people started writing million line
programs and librarys, they would load slowly even on fast computers and
impossibly slow on anything less.
I understand your reasoning for the Euphoria based front-end and I really
appriciate the PD-source, but I want more of those front-end optimizations not
excuses. I tried improving it myself, but didn't have much luck. A mere
additional 10 to 20 percent parsing speed improvement would satisfy me.
> Execution could sometimes
> be usefully performed before parsing was complete,
> allowing it to happen slightly sooner, while not
> catching syntax errors later in a program, and requiring
> all front-end data structures to be kept in memory during
> program execution.
Other than the slow down it causes, I have nothing against the new parsing
method and actually see benefits with it. It's just some others might not, thus I
listed it.
> You only know what I mentioned to you in private correspondence,
> and I don't think you understood what I said. Recursive routines
> will be as fast as ever using the Translator. Recursive routines
> will *not* run 20% slower with the interpreter. That 20% figure
> was just a number I pulled out of thin air as an estimate of
> the slowdown of *one IL opcode* used in recursion,
> not recursive routines as a whole. And there are ways that I can
> speed it up.
Make it so it's exactly as fast or faster than in v2.5. I wont be using
cooperative tasking except for DOS (maybe), so this issue will be with me all the
time. It's not fair that I have to suffer any sort of performance penalty just
because I'm not using your cooperative multi-tasking system.
BTW, I sent you an email with good news about Watcom. 
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Regards,
Vincent
6. Re: Why some people have not upgraded
Vincent wrote:
> Robert Craig wrote:
>
> Hi Rob,
>
> > This never worked at all with translating or binding,
> > and didn't work that well with interpreting.
>
> Of course it didn't work with translating or binding, and it worked fine with
> interpreting. Now there is my library, but all the other ones are broken. My
> library isn't really dynamic though, it basically restarts the users' program
> with a dynamically updating include list.
A library isn't necessary at all to do this. This has been discussed
here hundred times before. Why now discuss it again?
>> You can still do this. What are you talking about?
>
> The incompatability introduced with the '$' symbol. I didn't know how to put
> it into words on one line. This wasn't an issue for me, but pissed off a few
> people; Mario Steele was one of them, who now programs with Ruby.
The incompatability introduced with the '$' symbol is only a problem
with badly written code. Code should not be written in such a style
anyway. Has been discussed here several times.
<snip>
>> You could never trace a bound file, unless it
>> was bound as a single monolithic clear source file.
>> Why not trace your original source? Or give your user the required
>> unbound source files in a directory along with the interpreter executable?
>> No need to install Euphoria.
>
> This isn't my issue, I don't even use the binder or shrouder. This is a
> problem
> for Jonas Temple; I'm just siting it here for the purpose of this list.
I wonder what "the purpose of this list" is anyway.
<snip>
Regards,
Juergen
--
Have you read a good program lately?
7. Re: Why some people have not upgraded
Vincent wrote:
>
> Robert Craig wrote:
>
> Hi Rob,
>
> > This never worked at all with translating or binding,
> > and didn't work that well with interpreting.
>
> Of course it didn't work with translating or binding, and it worked fine with
> interpreting. Now there is my library, but all the other ones are broken. My
> library isn't really dynamic though, it basically restarts the users' program
> with a dynamically updating include list.
Rob's rationale does make sense even if it's a bit disheartening. The
translator/binder and interpreter should act the same so there is no problem with
distributing programs. It'd be way to easy for a user to develop a large
application that uses dynamic includes extensively and then find out that their
program can't be made self-contained otherwise.
> > You can still do this. What are you talking about?
>
> The incompatability introduced with the '$' symbol. I didn't know how to put
> it into words on one line. This wasn't an issue for me, but pissed off a few
> people; Mario Steele was one of them, who now programs with Ruby.
Rob was completely right in changing this. The '$' symbol is a good and useful
optimization that I have now whole-heartedly embraced in my coding since it
allows me to code a lot faster plus make my code run a lot faster. Also, the
newer method makes the logic of the code more evident I think. I have only gotten
an error due to this once and it was trivially fixed.
> > I don't know what that is, but it doesn't sound very valuable.
>
> The include hack was one of the most useful bugs. It gave us ability to
> include
> files with the same name in different file paths. Now Euphoria always treats
> files with the same name as if they were identical regardless of their
> location.
> This would likely cause a big problem if Euphoria ever became popular and
> people
> started to write libraries with the same file names but had different content.
> We'd waste literally hours yearly renaming files just so they could work with
> others and our own. We'd have to do it over and over again with every update
> of the 3rd party libraries.
>
> This issue alone prevents Euphoria from nicely accommodating a large user base
> with 10,000 or 100,000's of contributed programs and libraries. The chances
> for identical file names is very high with that many contributions, especially
> since programmers often use simular naming schemes. This is one of the biggest
> barriers with Euphoria's language design.
>
> You could easily change this in the source, but you just don't want to for
> some
> ludicrous reason.
OK, this I agree with completely. There is no reason that different files should
be treated as the same. This prevents me from "modularizing" my code by placing
includes in different directories. If there were any popular libraries that
needed this and couldn't be fixed easily I could maybe see this "feature" being
kept but I have found absolutely no examples of this error ever occuring. I would
much rather prefer this one little thing incorporated in the next version of
Euphoria than multi-tasking in any form.
(snip)
> > You keep harping about this because you
> > are obsessed with speed, but most people will notice
> > little difference between a program that parses
> > in .1 seconds, versus one that parses in .8 seconds,
> > especially when Windows adds it's own variable start-up delay to
> > any program that you run, written in any language.
> > Over time, the percentage of people using ancient sub-1Ghz
> > machines will decline, and people will wonder what you are
> > going on about. It seemed to be mainly the IDE that people
> > complained about, but not many programs are over 100,000 lines
> > of source.
>
> It's *WAY* more than just the IDE. It's any medium to large size program. It's
> a difference between seconds and minutes on my old systems!! You think this
> isn't a big deal... think again! Euphoria is suppost to run fine on 386-486
> machines, but it doesn't. I can go eat lunch while waiting for a large/huge
> program to load with v2.5 on my 386, and if the program crashes I have to do
> it again! With my Pentium 4, it's a matter of milli-seconds and several
> seconds,
> but that is still significant when considering several seconds is barely
> acceptable
> with today's C/C++ optimizing compilers.
>
> Imagine if Euphoria ever become popular and people started writing million
> line
> programs and librarys, they would load slowly even on fast computers and
> impossibly
> slow on anything less.
>
> I understand your reasoning for the Euphoria based front-end and I really
> appriciate
> the PD-source, but I want more of those front-end optimizations not excuses.
> I tried improving it myself, but didn't have much luck. A mere additional 10
> to 20 percent parsing speed improvement would satisfy me.
Vincent, develop a few thousand line Perl application and you'll beg for
Euphoria's speed. Yes, there is a slowdown in the 2.5 interpreter and yes, it is
noticable but it's still faster than everything else I've used. Also, if this
allows Rob to make bug fixes and changes to the language easier than I have no
problem with it. However, I've used it for serious DOS programming on embedded
devices and have had no serious problems speed wise.
> > Execution could sometimes
> > be usefully performed before parsing was complete,
> > allowing it to happen slightly sooner, while not
> > catching syntax errors later in a program, and requiring
> > all front-end data structures to be kept in memory during
> > program execution.
>
> Other than the slow down it causes, I have nothing against the new parsing
> method
> and actually see benefits with it. It's just some others might not, thus I
> listed
> it.
Disregarding the slowdown I think that's a fairly stupid reason to include that
on this list. If a user is too ignorant to upgrade for this reason alone then I
wonder if we should even bother trying to get them to upgrade at all.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
8. Re: Why some people have not upgraded
Juergen Luethje wrote:
> A library isn't necessary at all to do this. This has been discussed
> here hundred times before. Why now discuss it again?
There is really only one way to do it now, so your method must be very simular
to mine. Using a library with routines is more elegent that using open() and
puts(fn, ...); my library is much like a include system with a duplicate file
name scanner, and supports nesting dynamic/conditional includes. But you're
right, there is no reason to discuss this again.
> The incompatability introduced with the '$' symbol is only a problem
> with badly written code. Code should not be written in such a style
> anyway. Has been discussed here several times.
Any existing contributions that used this method are now broken. Luckily it's
only a handful of them, or we'd be in trouble.
> I wonder what "the purpose of this list" is anyway.
Rob seems a little suprized at why many people are still using v2.4 and older. I
made this list illistrate some reasons for him and to annoy you Juergen Luethje.
> Regards,
> Juergen
Regards,
Vincent
9. Re: Why some people have not upgraded
D. Newhall wrote:
> Rob's rationale does make sense even if it's a bit disheartening. The
> translator/binder
> and interpreter should act the same so there is no problem with distributing
> programs. It'd be way to easy for a user to develop a large application that
> uses dynamic includes extensively and then find out that their program can't
> be made self-contained otherwise.
Sure, I agree with that. I'm mean we can still do this, we just can't do it like
before anymore. This has to do with the new "parse everything" system.
> Rob was completely right in changing this. The '$' symbol is a good and useful
> optimization that I have now whole-heartedly embraced in my coding since it
> allows me to code a lot faster plus make my code run a lot faster. Also, the
> newer method makes the logic of the code more evident I think. I have only
> gotten
> an error due to this once and it was trivially fixed.
Yes the '$' is more efficent than the older length() method, but when he changed
this behind our back and broke a handful of existing applications and libraries
is what ticked some people off.
> Vincent, develop a few thousand line Perl application and you'll beg for
> Euphoria's
> speed. Yes, there is a slowdown in the 2.5 interpreter and yes, it is
> noticable
> but it's still faster than everything else I've used. Also, if this allows Rob
> to make bug fixes and changes to the language easier than I have no problem
> with it. However, I've used it for serious DOS programming on embedded devices
> and have had no serious problems speed wise.
Don't confuse execution speed with that of parsing. Euphoria's execution is
deliciously fast in every aspect. This has improved somewhat since v2.4 and will
continue to improve slightly. If Euphoria's execution were on the line, I'd be
gone faster than you could say "Sayonara". Im just talking about loading speed
and how unhappy I am about it.
I accept the Euphoria coded front-end since Rob has made good progress at
optimizing it, but there are still probably a couple more optimization
opportunities left that would retain code readability (no ASM). Even if there is
only a few percent increase to gain Robert should do it. Code generation
enhancements with the Eu2C translator will help out some too.
Regards,
Vincent
10. Re: Why some people have not upgraded
Vincent wrote:
>
> Juergen Luethje wrote:
>
> > A library isn't necessary at all to do this. This has been discussed
> > here hundred times before. Why now discuss it again?
>
> There is really only one way to do it now, so your method must be very simular
> to mine. Using a library with routines is more elegent that using open() and
> puts(fn, ...); my library is much like a include system with a duplicate file
> name scanner, and supports nesting dynamic/conditional includes. But you're
> right, there is no reason to discuss this again.
>
But wrapping these things just so inefficient. You might as well start
including machine.e and stop calling machine_proc.
Matt Lewis
11. Re: Why some people have not upgraded
Vincent wrote:
>
> D. Newhall wrote:
>
> > Rob was completely right in changing this. The '$' symbol is a good and
> > useful
> > optimization that I have now whole-heartedly embraced in my coding since it
> > allows me to code a lot faster plus make my code run a lot faster. Also, the
> > newer method makes the logic of the code more evident I think. I have only
> > gotten
> > an error due to this once and it was trivially fixed.
>
> Yes the '$' is more efficent than the older length() method, but when he
> changed
> this behind our back and broke a handful of existing applications and
> libraries
> is what ticked some people off.
>
This is the classic damned if you do, damned if you don't. It reminds me
of reading Raymond Chen's blog. Rob introduced something (which was nearly
unanimously *demanded*) that has the potential to make our lives lots easier,
plus faster and better, but people still complain because of a minor issue
that causes backward incompatibility with some dangerous and confusing code.
When I started using $, I found that I was nearly giggling because it was so
much better.
Matt Lewis
12. Re: Why some people have not upgraded
Robert Craig wrote:
>
> Vincent wrote:
> > 6. Fast loading time
>
> You keep harping about this because you
> are obsessed with speed, but most people will notice
> little difference between a program that parses
> in .1 seconds, versus one that parses in .8 seconds,
> especially when Windows adds it's own variable start-up delay to
> any program that you run, written in any language.
> Over time, the percentage of people using ancient sub-1Ghz
> machines will decline, and people will wonder what you are
> going on about. It seemed to be mainly the IDE that people
> complained about, but not many programs are over 100,000 lines
> of source.
>
I think you are missing part of the story. Your argument «perhaps» is correct
for programs written for single users.
Imagine a heavily used web site using Euphoria, with many, many simultaneous
users. Each user loading text files, images, opening and closing databases and
related tasks. Speed -measured in fractions of a second- will make the difference
even on a very high speed CPU with tons of RAM.
Reading these forum, it seems average users of Euphoria are working mainly with
desktop Windows applications. But there's a wide and still unexplored world
called Internet. If Euphoria wants to compete with PHP, Ruby, Perl, etc., must
accommodate to needs very different from those working on desktop applications.
For example, if RapidEuphoria.com was visited by too many simultaneous users, the
search method you use in your site would simply failed.
I've made some tests comparing Euphoria with PHP on a 3 Ghz server with 8 Gb
RAM. The results: more or less the same... due to... machine speed and RAM!!!.
So, using your argument, why to change from slow PHP to faster Euphoria if my
program can take advantage of machine speed? Why to change from PHP to Euphoria
when PHP has many built-in functions Euphoria lacks that make programming much
easier?
I said above that your argument «perhaps» is correct because even for desktop
applications and single users, speed is important. I registered Euphoria two
years ago trying to develop a windows application. After months of hard work, I
finally developed the program with PowerBASIC. The reason? Euphoria lacks of a
reliable windows library. Win32lib is «very slow» and buggy (and now
unsupported?) compared with other libraries. (wxEu, though multiplatform, is
bloated, at least compared with PowerBASIC)
Besides, your point of view tends towards the same direction to Microsoft and
its over-bloated software: it doesn't mind slowness and program size (8 Mb
instead of 100k) if we use a powerful machine. Also, optimization techniques and
good programming aren't important anymore because the ever growing speed of
machines will compensate bad programming and won't make us suffering much delay
with programs that otherwise would run as a turtle.
Do you know the main reason Internet users abandon sites is time? Why do you
think Yahoo is the most visited site in the world in spite of its ugly design?
Apart from its services, all in Yahoo sites is designed with speed in mind: fast
download, fast upload.
Size and speed matter, simply because they are related to each other, and in
some cases (as Internet) fraction of a second is important. Yes, I'm one of the
obsessed with speed and when programming the main thing I want (though not the
only one) is speed.
JG
13. Re: Why some people have not upgraded
Vincent wrote:
>
> Robert Craig wrote:
>
>
> > I don't know what that is, but it doesn't sound very valuable.
>
> The include hack was one of the most useful bugs. It gave us ability to
> include
> files with the same name in different file paths.
>
This is the single item in your list I agree with.
>
> > You keep harping about this because you
> > are obsessed with speed, but most people will notice
> > little difference between a program that parses
> > in .1 seconds, versus one that parses in .8 seconds,
> > especially when Windows adds it's own variable start-up delay to
> > any program that you run, written in any language.
>
> It's *WAY* more than just the IDE. It's any medium to large size program. It's
> a difference between seconds and minutes on my old systems!! You think this
> isn't a big deal... think again! Euphoria is suppost to run fine on 386-486
> machines, but it doesn't. I can go eat lunch while waiting for a large/huge
> program to load with v2.5 on my 386, and if the program crashes I have to do
> it again! With my Pentium 4, it's a matter of milli-seconds and several
> seconds,
> but that is still significant when considering several seconds is barely
> acceptable
> with today's C/C++ optimizing compilers.
And you'll find that any medium to large sized application written in *any*
language has a startup delay. You can eliminate the parsing issues by
binding or translating, if they're that onerous. If that's not enough,
you can figure out how to modularize your code, and spread it out into
multiple dlls, for instance, and spread the startup cost, allowing your
app to do something before it's all loaded.
The large cost of most Eu apps is probably going to be from the GUI or
other large library. I submitted a translated win32lib that can be used
from normal interpreter Eu source (http://www.rapideuphoria.com/windll.zip).
So there's an example of what I mentioned above. I've done the same thing
with ooeu.
Matt Lewis
14. Re: Why some people have not upgraded
Matt Lewis wrote:
> And you'll find that any medium to large sized application written in *any*
> language has a startup delay. You can eliminate the parsing issues by
> binding or translating, if they're that onerous. If that's not enough,
> you can figure out how to modularize your code, and spread it out into
> multiple dlls, for instance, and spread the startup cost, allowing your
> app to do something before it's all loaded.
>
> The large cost of most Eu apps is probably going to be from the GUI or
> other large library. I submitted a translated win32lib that can be used
> from normal interpreter Eu source (<a
> href="http://www.rapideuphoria.com/windll.zip">http://www.rapideuphoria.com/windll.zip</a>).
> So there's an example of what I mentioned above. I've done the same thing
> with ooeu.
>
> Matt Lewis
I realize that Matt, but a delay 10-20x longer than before is a ****** problem!
Compiling multiple DLLs and making wrappers for them will just waste time.
Using the translator or binder all the time defeats the purpose of using an
interpreter. If I wanted to compile all the time, I could just use C or C++ and
write programs that perform *much* faster than interpreted Euphoria.
Regards,
Vincent
15. Re: Why some people have not upgraded
Robert Craig wrote:
>
> Vincent wrote:
> > With the introduction of Euphoria v2.5 we lost:
> >
> > 1. Dynamic including (all methods except one)
>
> This never worked at all with translating or binding,
> and didn't work that well with interpreting.
>
> > 2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
>
> You can still do this. What are you talking about?
>
> > 4. Include statement hack
>
> I don't know what that is, but it doesn't sound very valuable.
>
> > 3. Bound file tracing
>
> You could never trace a bound file, unless it
> was bound as a single monolithic clear source file.
> Why not trace your original source? Or give your user the required
> unbound source files in a directory along with the interpreter executable?
> No need to install Euphoria.
>
> > 5. Shrouded includes
>
> Very rarely used, and it didn't work very well.
>
> > 6. Fast loading time
>
> You keep harping about this because you
> are obsessed with speed, but most people will notice
> little difference between a program that parses
> in .1 seconds, versus one that parses in .8 seconds,
> especially when Windows adds it's own variable start-up delay to
> any program that you run, written in any language.
> Over time, the percentage of people using ancient sub-1Ghz
I don't know about that.
I have a store that we Buy ,Sell, and Trade Electronic equipmemt.
TVs,Vcr,Dvds, and computers. The fastest computer I have picked up lately is a
500Mhz. Which is what I use at home now.
I passed up a 1Ghz. for $40 bucks lately (which I regret.)
I'm getting off tract here. Mainly I notice (with my 500Mhz. machine, which
I do not consider obsolete) a large slowdown in the interpeter between 2.4
and 2.5.
Especially since I upload version 7 of Edita.
Interpeting has become tedeously too slow with my not so oblolete machine.
> machines will decline, and people will wonder what you are
> going on about.
I do.
It seemed to be mainly the IDE that people
> complained about, but not many programs are over 100,000 lines
> of source.
>
> > 7. Block Parsing
>
> Execution could sometimes
> be usefully performed before parsing was complete,
> allowing it to happen slightly sooner, while not
> catching syntax errors later in a program, and requiring
> all front-end data structures to be kept in memory during
> program execution.
>
> > Next release:
> >
> > 8. Twenty percent slowdown on recursive
> > operations in single task interpreted
> > programs and libraries (all currently).
>
> You only know what I mentioned to you in private correspondence,
> and I don't think you understood what I said. Recursive routines
> will be as fast as ever using the Translator. Recursive routines
> will *not* run 20% slower with the interpreter. That 20% figure
> was just a number I pulled out of thin air as an estimate of
> the slowdown of *one IL opcode* used in recursion,
> not recursive routines as a whole. And there are ways that I can
> speed it up.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
16. Re: Why some people have not upgraded
don cole wrote:
>
> Robert Craig wrote:
> >
> > Vincent wrote:
> > > With the introduction of Euphoria v2.5 we lost:
> > >
> > > 1. Dynamic including (all methods except one)
> >
> > This never worked at all with translating or binding,
> > and didn't work that well with interpreting.
> >
> > > 2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
> >
> > You can still do this. What are you talking about?
> >
> > > 4. Include statement hack
> >
> > I don't know what that is, but it doesn't sound very valuable.
> >
> > > 3. Bound file tracing
> >
> > You could never trace a bound file, unless it
> > was bound as a single monolithic clear source file.
> > Why not trace your original source? Or give your user the required
> > unbound source files in a directory along with the interpreter executable?
> > No need to install Euphoria.
> >
> > > 5. Shrouded includes
> >
> > Very rarely used, and it didn't work very well.
> >
> > > 6. Fast loading time
> >
> > You keep harping about this because you
> > are obsessed with speed, but most people will notice
> > little difference between a program that parses
> > in .1 seconds, versus one that parses in .8 seconds,
> > especially when Windows adds it's own variable start-up delay to
> > any program that you run, written in any language.
> > Over time, the percentage of people using ancient sub-1Ghz
>
> I don't know about that.
> I have a store that we Buy ,Sell, and Trade Electronic equipmemt.
> TVs,Vcr,Dvds, and computers. The fastest computer I have picked up lately is
> a
> 500Mhz. Which is what I use at home now.
> I passed up a 1Ghz. for $40 bucks lately (which I regret.)
>
> I'm getting off tract here. Mainly I notice (with my 500Mhz. machine, which
> I do not consider obsolete) a large slowdown in the interpeter between 2.4
> and 2.5.
>
> Especially since I upload version 7 of Edita.
>
> Interpeting has become tedeously too slow with my not so oblolete machine.
>
>
> > machines will decline, and people will wonder what you are
> > going on about.
>
> I do.
> It seemed to be mainly the IDE that people
> > complained about, but not many programs are over 100,000 lines
> > of source.
> >
> > > 7. Block Parsing
> >
> > Execution could sometimes
> > be usefully performed before parsing was complete,
> > allowing it to happen slightly sooner, while not
> > catching syntax errors later in a program, and requiring
> > all front-end data structures to be kept in memory during
> > program execution.
> >
> > > Next release:
> > >
> > > 8. Twenty percent slowdown on recursive
> > > operations in single task interpreted
> > > programs and libraries (all currently).
> >
> > You only know what I mentioned to you in private correspondence,
> > and I don't think you understood what I said. Recursive routines
> > will be as fast as ever using the Translator. Recursive routines
> > will *not* run 20% slower with the interpreter. That 20% figure
> > was just a number I pulled out of thin air as an estimate of
> > the slowdown of *one IL opcode* used in recursion,
> > not recursive routines as a whole. And there are ways that I can
> > speed it up.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
I forgot to mention the main reason I uploaded was because alot of the new
contrbutions used the $ which gives a error with 2.4.
I have never had any need myself to use the $ , infact I don't even know
what is for.
Don Cole
A Bug is an un-documented feature.
A Feature is a documented Bug.
17. Re: Why some people have not upgraded
Adults having arguements over the most pathetic things!!!!! Well now its my
turn, I'm not an expert - I'm 15 and havn't started any type of 'official'
programming course, so what I know is through trial and error and what you guys
say on the forum!
Firstly, I wouldn't b in programming without Euphoria so I don't have much
against it - though I just used PHP for something else!
I can't believe people are complaining about 'parsing time'! Why? Over in sunny
old Britain (you know the island that is behind on most technology, but usually
beat France in the developed world), I just got a 1.7GHz Laptop - less than 1GHz
Desktop are definitely obsolite! But if you insist in using them, shroud the
script on a decend machine, which will practically get rid of parsing time.
I think parse everything is the only way to go - it gives a fighting chance
against compile languages!
And I shroud scripts to use on Web Servers - easier to upload and manage!
I also don't know why people were complaining about the GUI includes? Win32Lib
is great ... Thanks!
I still don't understand the pointless dynamic includes! Use different
functions!
And Matt the translating to dlls is a great idea - just someone needs to write a
program that translates the include then exports all the global functions -
simple?
Well, I would like shrouded includes and the $ sign is great, but I don't use it
because I get confused when I can! I think it should replace length() all the
time.
Feel free to complain,
Alex
18. Re: Why some people have not upgraded
My $0.02:
Rob wrote:
>Vincent wrote:
>> With the introduction of Euphoria v2.5 we lost:
>> 2. lhs_var[lhs_expr1][lhs_expr2] = rhs_expr
>
>You can still do this. What are you talking about?
Just to recap (and standing for once on Rob's side):
sequence s
s={{1,2}}
function f()
s={{1}}
return 99
end function
s[1][1]=f()
?s
2.4 displays {{99}}, 2.5 displays {{99,2}}. To make 2.5 work the same
it is necessary to code tmp=f() s[1][1]=tmp. This is not a big deal.
Such code is utterly horrible anyway - personally speaking, I would be
too embarrassed to claim it as a reason not to upgrade.
>> 4. Include statement hack
>
>I don't know what that is, but it doesn't sound very valuable.
Not certain what Vincent means either, but I am certain it would be
nicer to be able to install eg:
myapp/
myinc/
win32lib/
main.exw
Rather than 40+ source files all in the one directory, without
modifying euinc/path etc, and only needing relative paths in main.exw
not all files.
>> 5. Shrouded includes
>
>Very rarely used, and it didn't work very well.
Actually it worked fine 
.
>> 6. Fast loading time
>
>You keep harping about this
<snip>
>Over time, the percentage of people using ancient sub-1Ghz
Quite true. While I am one of those, in reality it makes no sense to
blame a software upgrade when the real culprit is a missing hardware
upgrade.
Yes, it is a reason I stick with 2.4, but not one I can validly expect
anyone else but me to do anything about, so why mention it?
9. Non-blocking support.
Like Chris said.
Regards,
Pete
19. Re: Why some people have not upgraded
Alex Chamberlain wrote:
>
> Adults having arguements over the most pathetic things!!!!!
:) This always happens just before there is a major EU release, it never
fails. A few weeks after the release another few EU users will leave in
anger vowing never to return. Alex you are exactly the type of consumer
Robert should be targeting. A young programmer with very little experience
trying to learn a new language. EU in my opinion is the easiest language to
learn, and it is so easy to develop in.
I have come to realize everyone here uses EU for different reasons, and
what my needs are might not be the same as the next user. I have no idea
why there is such a debate over speed, I can tell you I have had over a
million people download Cloak over the years, and I have never had one
customer complain about speed. Even Nexus Radio has a better load time
than WinAmp, and WinAmp was coded in C++!. And the load time for Nexus
would be faster but I use a program to encrypt and protect the exe file,
so that slows the load time a bit. My point is with computers getting
faster speed is not that much of an issue, unless you are running an
extremely slow computer.
I thought the purpose of Robert releasing the source code was to allow users
to add all the features they wanted to see added to the language without
having to depend on RDS, it is obvious this idea is not working very well.
This is the same argument over and over and I personally do not think it will
ever end.
What I would like to see happen to EU has nothing to do with the language
itself. I would like to see more Shareware and Commercial apps written in
EU. I just do not understand why only a small handful of people use EU for
more than personal projects. If download sites can be flooded with VB apps,
I see no reason why download sites can't be flooded with EU apps :) Even
if these apps are released as freeware, it will draw attention to the
language itself, and that is very important.
----If you continue to do what you have always done,
you will get what you have always gotten.----
20. Re: Why some people have not upgraded
C Bouzy wrote:
<snipped>
> What I would like to see happen to EU has nothing to do with the language
> itself. I would like to see more Shareware and Commercial apps written in
> EU. I just do not understand why only a small handful of people use EU for
> more than personal projects. If download sites can be flooded with VB apps,
> I see no reason why download sites can't be flooded with EU apps :) Even
> if these apps are released as freeware, it will draw attention to the
> language itself, and that is very important.
>
Yes yes yes - poeple, now is the time, unleash your euphoric programs unto the
world, show the world how good and simple it is to write. Release it as free
ware. Release it is shareware. Release it commercially, but above all, release
it, let it fly, let others USE IT.
Or something like that.
Chris
>
>
> ----If you continue to do what you have always done,
> you will get what you have always gotten.----
21. Re: Why some people have not upgraded
Vincent wrote:
>
> I realize that Matt, but a delay 10-20x longer than before is a ******
> problem!
> Compiling multiple DLLs and making wrappers for them will just waste time.
>
> Using the translator or binder all the time defeats the purpose of using an
> interpreter. If I wanted to compile all the time, I could just use C or C++
> and write programs that perform *much* faster than interpreted Euphoria.
>
This reminds me of "hardware junkies", people who upgrade their computer
2 or 3 times a year just to read email and surf the net. Lets say Robert
made EU 100x faster, then what? Is the extra speed really going to make
a significant difference in your projects?
I have mixed feelings about EU, but most of the issues you bring up are
non-issues in my book. More than half the items on your list I have never
had a use for, but I am sure they are very important to you.
One thing I have realized over the years while using EU, Robert will do as
he pleases with little to no regard to the users. Robert develops EU in
the direction he feels it should go, and the rest of us are just along for
the ride. Robert does not seem to understand when a developer is working
on a "product", the users opinions and feedback should influence the
direction of development, not the developers own personal agenda. It should
not have taken this long to get thread support, and there is no reason why
non-blocking support is still not available.
----If you continue to do what you have always done,
you will get what you have always gotten.----
22. Re: Why some people have not upgraded
- Posted by Vincent <darkvincentdude at yahoo.com>
Dec 30, 2005
-
Last edited Dec 31, 2005
C Bouzy wrote:
> This reminds me of "hardware junkies", people who upgrade their computer
> 2 or 3 times a year just to read email and surf the net. Lets say Robert
> made EU 100x faster, then what? Is the extra speed really going to make
> a significant difference in your projects?
Parsing speed... Absolutely!! The execution speed is fine.
Why doesn't Rob change the minimum system requirements for Euphoria to a Pentium
III 1 GHz, 256 MB RAM, 10 MB Free Disk space!
> I have mixed feelings about EU, but most of the issues you bring up are
> non-issues in my book. More than half the items on your list I have never
> had a use for, but I am sure they are very important to you.
Then you wouldn't have any reason to stay with v2.4, which is the whole purpose
of the list!
> One thing I have realized over the years while using EU, Robert will do as
> he pleases with little to no regard to the users. Robert develops EU in
> the direction he feels it should go, and the rest of us are just along for
> the ride. Robert does not seem to understand when a developer is working
> on a "product", the users opinions and feedback should influence the
> direction of development, not the developers own personal agenda. It should
> not have taken this long to get thread support, and there is no reason why
> non-blocking support is still not available.
You guys have thrown this thread all out of proportion. You see it's just a list
of *possible* reasons why some people haven't upgraded, **NOT** that they all
effect me!
In fact I personally only care about two things on the list:
1. Parsing Speed
2. Include Fix
The first one is by far the biggest problem for me, I just want to "explode" in
anger over what Rob has done to loading on my older machines.
I could care less what other people think about the loading issue, all I know is
I want it fast again and I want it now!!! But if not, I'm willing to settle with
a couple more small optimizations. I *WILL* keep fighting until I get those
optimizations!
Regards,
Vincent
23. Re: Why some people have not upgraded
- Posted by C Bouzy <eucoder at hotmail.com>
Dec 30, 2005
-
Last edited Dec 31, 2005
Vincent wrote:
> Why doesn't Rob change the minimum system requirements for Euphoria to a
> Pentium
> III 1 GHz, 256 MB RAM, 10 MB Free Disk space!
Because not all EU apps would need those requirements
> You guys have thrown this thread all out of proportion. You see it's just a
> list of *possible* reasons why some people haven't upgraded, **NOT** that
> they
> all effect me!
I see...
> I could care less what other people think about the loading issue, all I know
> is I want it fast again and I want it now!!! But if not, I'm willing to settle
> with a couple more small optimizations. I *WILL* keep fighting until I get
> those
> optimizations!
You really have not been around here long have you? haven't you learned yet
Robert takes a very long time before adding new features or fixing exisitng
ones. If I knew more about altering the EU source to add non-blocking support
I would do it myself, because if I wait for Robert it will be another 7
months before it is added.
----If you continue to do what you have always done,
you will get what you have always gotten.----
24. Re: Why some people have not upgraded
Vincent wrote:
>
> 1. Parsing Speed
> 2. Include Fix
>
> The first one is by far the biggest problem for me, I just want to "explode"
> in anger over what Rob has done to loading on my older machines.
Vincent:
You can improve loading speed by writing your code
to parse in a different way.
1. don't do dynamic includes that wastes time.
2. use only decimal numbers as constants and values because the parser has
to convert them from hex.
3. don't use append and prepend while parsing describe a large sequence
all at once instead of building it a piece at a time.
4. spend more time studing how your code is being parsed and less complaining
about loading speed.
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
25. Re: Why some people have not upgraded
Bernie Ryan wrote:
> Vincent:
>
> You can improve loading speed by writing your code
> to parse in a different way.
>
> 1. don't do dynamic includes that wastes time.
> 2. use only decimal numbers as constants and values because the parser has
> to convert them from hex.
It's not going to make any difference.
The scanner also has to read and convert decimal numbers from text strings.
Did you think computers use decimal internally?
Please use whichever base is more readable.
> 3. don't use append and prepend while parsing describe a large sequence
> all at once instead of building it a piece at a time.
These appends and prepends will be performed at run-time,
not parse time, and unless you have many thousands of them,
you won't notice any difference.
> 4. spend more time studing how your code is being parsed and less
> complaining
> about loading speed.
I would say write your code in as readable a manner as you can,
and forget about trying to shave a millisecond off your load time.
The parser is open source. Any one can study it and recommend
ways to speed it up.
Something that actually *will* improve your load time,
on very old, slow machines with small RAM,
is to remove any "with trace", "with profile" or
"with profile_time" statements that you are
no longer using. This will also help you at run-time.
You should search your copy of Win32Lib, IDE etc. to see
if any were left in there.
And of course you can achieve *zero* parse time
if you bind, shroud or translate any large program
that you use a lot. For smaller programs,
under about 10,000 lines, I wouldn't worry about it.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
26. Re: Why some people have not upgraded
C Bouzy wrote:
>
> Alex Chamberlain wrote:
> >
> > Adults having arguements over the most pathetic things!!!!!
>
> :) This always happens just before there is a major EU release, it never
> fails. A few weeks after the release another few EU users will leave in
> anger vowing never to return. Alex you are exactly the type of consumer
> Robert should be targeting. A young programmer with very little experience
> trying to learn a new language. EU in my opinion is the easiest language to
> learn, and it is so easy to develop in.
>
> I have come to realize everyone here uses EU for different reasons, and
> what my needs are might not be the same as the next user. I have no idea
> why there is such a debate over speed, I can tell you I have had over a
> million people download Cloak over the years, and I have never had one
> customer complain about speed. Even Nexus Radio has a better load time
> than WinAmp, and WinAmp was coded in C++!. And the load time for Nexus
> would be faster but I use a program to encrypt and protect the exe file,
> so that slows the load time a bit. My point is with computers getting
> faster speed is not that much of an issue, unless you are running an
> extremely slow computer.
>
> I thought the purpose of Robert releasing the source code was to allow users
> to add all the features they wanted to see added to the language without
> having to depend on RDS, it is obvious this idea is not working very well.
> This is the same argument over and over and I personally do not think it will
> ever end.
>
Did you wonder why this isn't working so well, even though features can be
easy to add? They are limited to the ey.ex stuff which is obviously slower,
so that you can't test whether the added feature would cause a performance
issue or not. Plus, everyone is adding a couple different feature, and can't
release contributions based on it, because that would involve running them
with eu.ex - see above.
I'd cnsider using ooeu, because it has most what I think Eu is missing,
except a decent global resolution system, which I designed. but what can I
release using it?
CChris
> What I would like to see happen to EU has nothing to do with the language
> itself. I would like to see more Shareware and Commercial apps written in
> EU. I just do not understand why only a small handful of people use EU for
> more than personal projects. If download sites can be flooded with VB apps,
> I see no reason why download sites can't be flooded with EU apps :) Even
> if these apps are released as freeware, it will draw attention to the
> language itself, and that is very important.
>
>
> ----If you continue to do what you have always done,
> you will get what you have always gotten.----
27. Re: Why some people have not upgraded
CChris wrote:
> C Bouzy wrote:
<snip>
>> I thought the purpose of Robert releasing the source code was to allow users
>> to add all the features they wanted to see added to the language without
>> having to depend on RDS, it is obvious this idea is not working very well.
>> This is the same argument over and over and I personally do not think it will
>> ever end.
>
>
> Did you wonder why this isn't working so well, even though features can be
> easy to add? They are limited to the ey.ex stuff which is obviously slower,
> so that you can't test whether the added feature would cause a performance
> issue or not.
This is only half true.
If a feature that was added to the Eu-in-Eu interpreter does *not* cause
performance problems, then it will also not cause performance problems
when added to the official C-coded interpreter.
> Plus, everyone is adding a couple different feature, and can't
> release contributions based on it, because that would involve running them
> with eu.ex - see above.
>
> I'd cnsider using ooeu, because it has most what I think Eu is missing,
> except a decent global resolution system, which I designed. but what can I
> release using it?
Everything except of certain games and software that controls nuclear
submarines.
Seriously: According to %EUDIR%\demo\bench\bench.doc, Eu-in-Eu is
e.g. 2 times faster than Python, and 4 times faster than Ruby.
I don't know how fast OOEU is, though. Matt, is there an "official"
benchmark test that compares the speed of Eu-in-Eu to the speed of OOEU?
BTW, Python ...
Among the *many* Python programs -- which are obviously not too slow for
their respective purpose -- there are certainly several ones which would
be nice to have as Euphoria programs. Since Python is also object
oriented, I think it should often be easier to translate Python programs
to OOEU than to translate them to "RDS standard Euphoria".
<snip>
Regards,
Juergen
--
Have you read a good program lately?
28. Re: Why some people have not upgraded
Juergen Luethje wrote:
> Everything except of certain games and software that controls nuclear
> submarines.
Games? why there isn't any risks at all playing "games" with nuclear reactor
controls. Look at that tempting red button that shuts down the water cooling
pumps; press it and see what happens! ;^}
> Seriously: According to %EUDIR%\demo\bench\bench.doc, Eu-in-Eu is
> e.g. 2 times faster than Python, and 4 times faster than Ruby.
> I don't know how fast OOEU is, though. Matt, is there an "official"
> benchmark test that compares the speed of Eu-in-Eu to the speed of OOEU?
Well considering OOEU is based on the PD-source, I'm guessing it's about the
same. OOEU does add alot of additional features; that probably adds some
overhead, thus imposing a small performance penalty.
I personally consider OOEU to add to much complexity with the new syntax, object
oriention, pass by reference, goto, pre-processor. I am glad Robert isn't
considering to add any of those features into official RDS Euphoria.
No offense Matt.
> BTW, Python ...
> Among the *many* Python programs -- which are obviously not too slow for
> their respective purpose -- there are certainly several ones which would
> be nice to have as Euphoria programs. Since Python is also object
> oriented, I think it should often be easier to translate Python programs
> to OOEU than to translate them to "RDS standard Euphoria".
Python actually isn't all that bad at some things:
Heapsort: Euphoria v2.5 is ~4.0x faster than Python v2.4
Fibonacci: Euphoria v2.5 is ~8.7x faster than Python v2.4
Ackermann: Euphoria v2.5 is ~13.5x faster than Python v2.4
Prime Sieve: Euphoria v2.5 is ~30.0x faster than Python v2.4
Regards,
Vincent
29. Re: Why some people have not upgraded
Robert Craig wrote:
> I would say write your code in as readable a manner as you can,
> and forget about trying to shave a millisecond off your load time.
> The parser is open source. Any one can study it and recommend
> ways to speed it up.
You don't know how you could improve it more? Well in that case, add some some
more optimizations into the translator; that might help some, since you translate
the front-end to C before compiling. I may look into this again soon and
definitely encourage others to as well.
> Something that actually *will* improve your load time,
> on very old, slow machines with small RAM,
> is to remove any "with trace", "with profile" or
> "with profile_time" statements that you are
> no longer using. This will also help you at run-time.
> You should search your copy of Win32Lib, IDE etc. to see
> if any were left in there.
Heh...
I spent over an hour searching and removing those statements from all the
Win32Lib and IDE source files just to shave off a few seconds on an almost four
minute load time.
> And of course you can achieve *zero* parse time
> if you bind, shroud or translate any large program
> that you use a lot. For smaller programs,
> under about 10,000 lines, I wouldn't worry about it.
..sigh..
Regards,
Vincent
30. Re: Why some people have not upgraded
Vincent wrote:
> Juergen Luethje wrote:
>
>> Everything except of certain games and software that controls nuclear
>> submarines.
>
> Games? why there isn't any risks at all playing "games" with nuclear
> reactor controls.
I don't think that I wrote about 'playing "games" with nuclear reactor
controls'.
<snip>
> I personally consider OOEU to add to much complexity with the new
> syntax, object oriention, pass by reference, goto, pre-processor. I
> am glad Robert isn't considering to add any of those features into
> official RDS Euphoria.
>
> No offense Matt.
And I like OOEU, besides other reasons, because of the following:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>> BTW, Python ...
>> Among the *many* Python programs -- which are obviously not too slow for
>> their respective purpose -- there are certainly several ones which would
>> be nice to have as Euphoria programs. Since Python is also object
>> oriented, I think it should often be easier to translate Python programs
>> to OOEU than to translate them to "RDS standard Euphoria".
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
This applies of course not only to Python.
I consider the topic of translating programs from other languages to
Euphoria especially important, since the Euphaoria user base is rather
small, and since there are (currently) no textbooks which contain
algorithms written in Euphoria.
<snip>
Regards,
Juergen
--
Have you read a good program lately?
31. Re: Why some people have not upgraded
Juergen Luethje wrote:
>
> Seriously: According to %EUDIR%\demo\bench\bench.doc, Eu-in-Eu is
> e.g. 2 times faster than Python, and 4 times faster than Ruby.
> I don't know how fast OOEU is, though. Matt, is there an "official"
> benchmark test that compares the speed of Eu-in-Eu to the speed of OOEU?
I haven't done this. I would expect ooeu to be slightly slower, due to some
extra checking that goes on during both parsing and execution.
Matt Lewis
32. Re: Why some people have not upgraded
- Posted by Al Getz <Xaxo at aol.com>
Dec 31, 2005
-
Last edited Jan 01, 2006
Hello again,
Vincent:
Yes, it pissed me off too to find out that v2.5 was going to parse
*much* slower than v2.4 ... i would have upgraded the day after it
came out if it wasnt for this slowdown.
Of course there's also some plus things to say, and i can name one...
the 'Source' code for v2.5 written in Euphoria. I've created a nice
debugger with this (doesnt have to be as fast opening source's). It's
also kept me busy studying it from time to time and i find it's very
interesting.
I guess i still cant help wishing Rob stuck with the C code and just
added functionality, and also provided the Eu 'Source' code.
I still plan to upgrade at some point though, because i've heard v2.5
exe's run faster and are smaller too. Thing is, i really like the idea
of using a text file to program and not having to compile anything before
you test it (exw files). I'd have to bind many of the programs i use
now in order to have them open up at the speed i need if i used v2.5
for all of my programs. A lot of them are quite long with many includes,
and they just seem to be getting longer and longer because im starting
to put functionality i had in several programs into one so i can open one
and use many of the functions.
Longer parse time means a longer delay when you are testing a program.
I've helped this to some extent with my debugger, but still if it picks
up an early error you have to abort and start over again.
Maybe 2.6 will parse faster?
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
33. Re: Why some people have not upgraded
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 31, 2005
-
Last edited Jan 01, 2006
Al Getz wrote:
> ... i would have upgraded the day after it
> came out if it wasnt for this slowdown.
> ...
> Maybe 2.6 will parse faster?
I'm sure it will. I don't know by how much,
but I'll see what I can do.
By the way, did you know that 2.5 official
parses at least 25% faster than 2.5 alpha?
(40% faster on older machines like yours).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
34. Re: Why some people have not upgraded
Robert Craig wrote:
> Al Getz wrote:
>> Maybe 2.6 will parse faster?
> I'm sure it will. I don't know by how much,
> but I'll see what I can do.
Now you're talking Rob! 
Nothing would please me more than to have improved parsing performance in the
next release, even if it's by a small margin.
Although it's impossible for the new parsing method to ever perform like the
older one, even a small improvement would signify genuine effort put forth to
make the system as fast and efficent as possible. So for that I cannot complain.
BTW, have you decided on whether the next release will be version 2.6 or 3.0?
Based on release history, you've jumped from version 1.5 to 2.0; shouldn't you
continue that trend?
Cheers,
Vincent
35. Re: Why some people have not upgraded
To break into this thread on upgrading, and 2.5's parsing delays...
Rob, what do you think of transparently caching the plaintext->opcode stage=
?
Simply put - that on execution, ex/exw will parse the source-code, and
generate a temporary file containing the program in opcode form.
(Whether that's in EUDIR or the same directory as the program doesn't
really matter)
One subsequent execution, the interpreter checks to see if this file
exists, and if:
- The source file's last-modified time matches a timestamp stored in
the temp file.
- A hash of the source file matches a checksum stored in the temp file.
Then it can just execute directly from the temp file, rather than
having to re-parse the code.
For programs consisting of multiple source files, the interpreter would eit=
her:
- apply the above checks to each file included. (The list of which
could be stored in the single temp file)
- use a temp file for each source file, and give the temp files the
ability to include one another.
For a program in development, this may not be all that useful...
although for *large* programs, having multiple temp files would
drastically reduce the parsing time.
However, for completed programs, like (as always) the ide, this would
make life much easier.
I know that 'temp file' is quite similar to what an .il file is, I
would be happy even if this were restricted to registered users...
--
MrTrick
----------
36. Re: Why some people have not upgraded
Patrick Barnes wrote:
>
> To break into this thread on upgrading, and 2.5's parsing delays...
>
> Rob, what do you think of transparently caching the plaintext->opcode stage=
> ?
> Simply put - that on execution, ex/exw will parse the source-code, and
> generate a temporary file containing the program in opcode form.
> (Whether that's in EUDIR or the same directory as the program doesn't
> really matter)
>
> One subsequent execution, the interpreter checks to see if this file
> exists, and if:
> - The source file's last-modified time matches a timestamp stored in
> the temp file.
> - A hash of the source file matches a checksum stored in the temp file.
> Then it can just execute directly from the temp file, rather than
> having to re-parse the code.
>
> For programs consisting of multiple source files, the interpreter would eit=
> her:
> - apply the above checks to each file included. (The list of which
> could be stored in the single temp file)
> - use a temp file for each source file, and give the temp files the
> ability to include one another.
>
> For a program in development, this may not be all that useful...
> although for *large* programs, having multiple temp files would
> drastically reduce the parsing time.
> However, for completed programs, like (as always) the ide, this would
> make life much easier.
>
> I know that 'temp file' is quite similar to what an .il file is, I
> would be happy even if this were restricted to registered users...
> --
> MrTrick
> ----------
>
>
I think this would eventually suffer from the same problem that we have with
include files.
That being said, if/when Euphoria gets multitasking the parser could be
multithreaded enabling execution to begin before the program was entirely parsed.
Then again, has anyone compared EU 2.5 startup with other languages? Is it
really that bad?
--
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
37. Re: Why some people have not upgraded
Jason Gade wrote:
>
(snip)
> Then again, has anyone compared EU 2.5 startup with other languages? Is it
> really
> that bad?
I have a 1,000 line pseuod-COBOL interactive interpreter shell I wrote while on
vacation after christmas. It's parsing time is noticably slow on my computer
taking about 2-3 seconds before the prompt appears. However, I have a perl script
that unzips a file and changes the path in the Windows registry that I did at
work to install a program we developed. The COBOL interpreter source is 3.5 times
larger than the install script but even after being compiled it could only match
the startup speed of the interpreter. So, while the startup speed of the
interpreter has decreased it can still execute a 28K program faster than an 8K
Perl scipt converted with Perl2EXE.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
38. Re: Why some people have not upgraded
On 1/1/06, Jason Gade <guest at rapideuphoria.com> wrote:
> Patrick Barnes wrote:
> >
> > To break into this thread on upgrading, and 2.5's parsing delays...
> >
> > Rob, what do you think of transparently caching the plaintext->opcode s=
tage=
> > ?
> I think this would eventually suffer from the same problem that we have w=
ith include files.
Which is that? The naming issues? Not if it were placed in the same
folder as the original folder...
> That being said, if/when Euphoria gets multitasking the parser could be m=
ultithreaded enabling execution to begin before the program was entirely pa=
rsed.
Only if it were pre-emptive... cooperative wouldn't do it, I'm afraid.
> Then again, has anyone compared EU 2.5 startup with other languages? Is i=
t really that bad?
Okay, well what I'd like would be something like the way Eclipse works
with Java, or PHP on Apache. There's *NO* compile button in the
Eclipse IDE... it compiles things in the background, so the fact that
you're dealing with a compiled language is completely transparent.
PHP caches the parsed source code as well, in a temporary folder - so
the overhead from parsing a commonly accessed source file (like
index.php) is reduced to an almost one-time operation - you don't need
binaries to have fast html preprocessing.
--
MrTrick
----------
39. Re: Why some people have not upgraded
Vincent wrote:
>
> Juergen Luethje wrote:
>
> > Everything except of certain games and software that controls nuclear
> > submarines.
>
> Games? why there isn't any risks at all playing "games" with nuclear reactor
> controls. Look at that tempting red button that shuts down the water cooling
> pumps; press it and see what happens! ;^}
>
> > Seriously: According to %EUDIR%\demo\bench\bench.doc, Eu-in-Eu is
> > e.g. 2 times faster than Python, and 4 times faster than Ruby.
> > I don't know how fast OOEU is, though. Matt, is there an "official"
> > benchmark test that compares the speed of Eu-in-Eu to the speed of OOEU?
>
> Well considering OOEU is based on the PD-source, I'm guessing it's about the
> same. OOEU does add alot of additional features; that probably adds some
> overhead,
> thus imposing a small performance penalty.
>
> I personally consider OOEU to add to much complexity with the new syntax,
> object
> oriention, pass by reference, goto, pre-processor. I am glad Robert isn't
> considering
> to add any of those features into official RDS Euphoria.
>
I am surprised by the illogical, bordering on the unfair, nature of such a
claim.
No one is compelled to use every feature of a given language in any given code
s/he writes using that language. I don't like gotos, so I hardly use them in
ooeu. However, I'd consider it unfair to prevent anyone using them because of
that personal taste issue.
Useless complexity is obviously not welcome, in Euphoria and about anywhere
else. Some language creators do introduce some unneeded complexity; their
creations end up unused. This also holds when the creator has some academic
authority, it only takes a bit longer.
However, if you want to do some complex things without too much effort, and
that's the aim of a programming language, then inevitably there has to be
some complexity somewhere. As little as possible, but zero is not a realistic
target.
What makes me grumble about Eu is its excessive minimalism, which cause some
sorts of legitimate programming to wind up excessively complicated, because
it is contrived by the excessive simplicity of the tools at hand. In other
words: simplicity of programming is a goal to strive for, and simplicity of
programming language may be an obstacle to it, and currently is in Eu.
I am not glad at all that Robert isn't considering
to add any of these features into official RDS Euphoria.
CChris
Oh, just an example of the elegance of simplicity...
function foo() has 4 or 5 internal variables, and some processing afeects all
in some consistent way.
In Pascal/Delphi, you'd just say:
function foo():sometype
var v1:integer;v2:array(6) of integer <whatever>
procedure some_proc()
{code here}
end;
begin; {foo}
...
some_proc()
end; {foo}
internal vars are modified according to whatever needs to be done. End of
programming. Also note the use of nested routines which even avoids passing
anything to some_proc. But passing by reference would help anyway.
Now in Eu:
function some_proc(integer v1,sequence v2,....)
--code here
return {v1,v2,...}
end function
function foo()
sequence returned_state
integer v1 sequence v2 <whatever>
--...
returned_state=some_proc(v1,v2,...)
v1=returned_state[1]
v2=returned_state[2]
-- all the list
end function
Things are even worse when some_proc() is in some utility module, because
some vars must become global and here come the nagging namespace issues.
How elegant this is when you have to repeat it across a handful of routines....
> No offense Matt.
>
> > BTW, Python ...
> > Among the *many* Python programs -- which are obviously not too slow for
> > their respective purpose -- there are certainly several ones which would
> > be nice to have as Euphoria programs. Since Python is also object
> > oriented, I think it should often be easier to translate Python programs
> > to OOEU than to translate them to "RDS standard Euphoria".
>
> Python actually isn't all that bad at some things:
>
> Heapsort: Euphoria v2.5 is ~4.0x faster than Python v2.4
> Fibonacci: Euphoria v2.5 is ~8.7x faster than Python v2.4
> Ackermann: Euphoria v2.5 is ~13.5x faster than Python v2.4
> Prime Sieve: Euphoria v2.5 is ~30.0x faster than Python v2.4
>
>
> Regards,
> Vincent
40. Re: Why some people have not upgraded
Robert Craig wrote:
>
> Al Getz wrote:
> > ... i would have upgraded the day after it
> > came out if it wasnt for this slowdown.
> > ...
> > Maybe 2.6 will parse faster?
>
> I'm sure it will. I don't know by how much,
> but I'll see what I can do.
>
> By the way, did you know that 2.5 official
> parses at least 25% faster than 2.5 alpha?
> (40% faster on older machines like yours).
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hello again Rob,
Oh ok, sounds great...i look forward to seeing the new release.
In the mean time i'll check to make sure
im using the most recent v2.5 (Official PD Rel.).
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
41. Re: Why some people have not upgraded
- Posted by Robert Craig <rds at RapidEuphoria.com>
Jan 01, 2006
-
Last edited Jan 02, 2006
Patrick Barnes wrote:
> To break into this thread on upgrading, and 2.5's parsing delays...
>
> Rob, what do you think of transparently caching the plaintext->opcode stage=
> ?
> Simply put - that on execution, ex/exw will parse the source-code, and
> generate a temporary file containing the program in opcode form.
> (Whether that's in EUDIR or the same directory as the program doesn't
> really matter)
>
> One subsequent execution, the interpreter checks to see if this file
> exists, and if:
> - The source file's last-modified time matches a timestamp stored in
> the temp file.
> - A hash of the source file matches a checksum stored in the temp file.
> Then it can just execute directly from the temp file, rather than
> having to re-parse the code.
>
> For programs consisting of multiple source files, the interpreter would eit=
> her:
> - apply the above checks to each file included. (The list of which
> could be stored in the single temp file)
> - use a temp file for each source file, and give the temp files the
> ability to include one another.
>
> For a program in development, this may not be all that useful...
> although for *large* programs, having multiple temp files would
> drastically reduce the parsing time.
> However, for completed programs, like (as always) the ide, this would
> make life much easier.
>
> I know that 'temp file' is quite similar to what an .il file is, I
> would be happy even if this were restricted to registered users...
It's an interesting idea, and I actually implemented something like
this on a compiler I worked on about 15 years ago, before Euphoria.
In those days, a compile would often take half an hour (on a machine
a bit slower than a 386). We were able to reduce this time somewhat
by doing what you are proposing.
However, Euphoria is supposed to be a simple language.
I would not want to add this complexity to the front end,
plus complexity to the manual, as well as having newbies
constantly say "what are those extra files for?".
In theory it would be "transparent", but people would still
see the extra files lying around, and if anything went wrong,
they would wonder if they were really up-to-date.
At some point, I'm going to look into shrouding of include
files, to get a .il that can be included. I'm not sure how
it will go, but I'd rather do that than complicate the
whole process of running the interpreter. I do not want to
introduce another type of intermediate file.
As far as the ide goes, it can be bound or translated to
save the parse time for its users. But even without that,
on my 1.8GHz P4, exw ide only takes about 4 seconds to display
the flash screen (whole program parsed already), and about 4 more seconds
to initialize the ide's data structures and set up its
initial GUI. And that's the biggest Euphoria program I'm aware of,
well over 100,000 lines of source when you include Win32Lib.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
42. Re: Why some people have not upgraded
- Posted by Robert Craig <rds at RapidEuphoria.com>
Jan 01, 2006
-
Last edited Jan 02, 2006
Vincent wrote:
> BTW, have you decided on whether the next release will be version 2.6 or 3.0?
> Based on release history, you've jumped from version 1.5 to 2.0; shouldn't you
> continue that trend?
OK, you've convinced me.
The next release will be 3.0
Multitasking, although most programs won't use it,
is a fundamental change in the way that Euphoria
programs can be run. There can now be many different
"threads of execution", running in parallel with each other,
and utilizing multiple independent call stacks.
If I don't use this opportunity to jump to 3.0,
then the release after this one might be just a large collection
of minor enhancements and bug fixes, and I might have
trouble ever justifying the jump. (Release numbers are kind of
arbitrary, but most people think of a .1 release as
being very minor, though in Euphoria terms, historically
it has been a major release )
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
43. Re: Why some people have not upgraded
- Posted by Juergen Luethje <j.lue at gmx.de>
Jan 01, 2006
-
Last edited Jan 02, 2006
Robert Craig wrote:
<snip>
> However, Euphoria is supposed to be a simple language.
> I would not want to add this complexity to the front end,
> plus complexity to the manual, as well as having newbies
> constantly say "what are those extra files for?".
> In theory it would be "transparent", but people would still
> see the extra files lying around, and if anything went wrong,
> they would wonder if they were really up-to-date.
>
> At some point, I'm going to look into shrouding of include
> files, to get a .il that can be included. I'm not sure how
> it will go, but I'd rather do that than complicate the
> whole process of running the interpreter. I do not want to
> introduce another type of intermediate file.
I think this is actually the way to go! I hope it will be possible
to create .il files that can be included (or linked or whatever).
Very much appreciated!
<snip>
Regards,
Juergen
--
Have you read a good program lately?
44. Re: Why some people have not upgraded
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 01, 2006
-
Last edited Jan 02, 2006
Juergen Luethje wrote:
>
> Robert Craig wrote:
>
> <snip>
>
> > However, Euphoria is supposed to be a simple language.
> > I would not want to add this complexity to the front end,
> > plus complexity to the manual, as well as having newbies
> > constantly say "what are those extra files for?".
> > In theory it would be "transparent", but people would still
> > see the extra files lying around, and if anything went wrong,
> > they would wonder if they were really up-to-date.
> >
> > At some point, I'm going to look into shrouding of include
> > files, to get a .il that can be included. I'm not sure how
> > it will go, but I'd rather do that than complicate the
> > whole process of running the interpreter. I do not want to
> > introduce another type of intermediate file.
>
> I think this is actually the way to go! I hope it will be possible
> to create .il files that can be included (or linked or whatever).
> Very much appreciated!
>
> <snip>
>
> Regards,
> Juergen
>
> --
> Have you read a good program lately?
It might also be an incentive for people to register to get the binder.
--
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
45. Re: Why some people have not upgraded
- Posted by Juergen Luethje <j.lue at gmx.de>
Jan 01, 2006
-
Last edited Jan 02, 2006
Jason Gade wrote:
> Juergen Luethje wrote:
>>
>> Robert Craig wrote:
>>
>> <snip>
>>
>>> However, Euphoria is supposed to be a simple language.
>>> I would not want to add this complexity to the front end,
>>> plus complexity to the manual, as well as having newbies
>>> constantly say "what are those extra files for?".
>>> In theory it would be "transparent", but people would still
>>> see the extra files lying around, and if anything went wrong,
>>> they would wonder if they were really up-to-date.
>>>
>>> At some point, I'm going to look into shrouding of include
>>> files, to get a .il that can be included. I'm not sure how
>>> it will go, but I'd rather do that than complicate the
>>> whole process of running the interpreter. I do not want to
>>> introduce another type of intermediate file.
>>
>> I think this is actually the way to go! I hope it will be possible
>> to create .il files that can be included (or linked or whatever).
>> Very much appreciated!
>>
>> <snip>
>>
>
> It might also be an incentive for people to register to get the binder.
That's what I believe, too. And I think it would be a good idea for RDS
to take advantage of it.
Regards,
Juergen
--
Have you read a good program lately?
46. Re: Why some people have not upgraded
- Posted by C Bouzy <eucoder at hotmail.com>
Jan 01, 2006
-
Last edited Jan 02, 2006
Robert Craig wrote:
>
> OK, you've convinced me.
> The next release will be 3.0
>
Hi Robert,
I am not sure if this was posted, but when can we expect the new version?
I ask this because I would hold off releasing my new project if the new
EU will be released in the next 3 to 4 weeks.
Thanks,
Chris
----If you continue to do what you have always done,
you will get what you have always gotten.----
47. Re: Why some people have not upgraded
C Bouzy wrote:
>
> Robert Craig wrote:
> >
> > OK, you've convinced me.
> > The next release will be 3.0
> >
>
> Hi Robert,
>
> I am not sure if this was posted, but when can we expect the new version?
> I ask this because I would hold off releasing my new project if the new
> EU will be released in the next 3 to 4 weeks.
In the next 3 to 4 weeks, there will probably be some kind
of "pre-alpha" release of multitasking in the
(C-backend) interpreter, and the Translator. It's unlikely I'll
have built-in non-blocking support that you've asked for,
but you'll be able to experiment again with the code
provided by Daniel Kluss, this time with a fast interpreter
and Translator. I don't want to speculate on when a full alpha
release will happen. There are several other things I'd like
to include in a 3.0 alpha release besides multitasking.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
48. Re: Why some people have not upgraded
Robert Craig wrote:
> In the next 3 to 4 weeks, there will probably be some kind
> of "pre-alpha" release of multitasking in the
> (C-backend) interpreter, and the Translator.
Sounds good...
> It's unlikely I'll have built-in non-blocking support that
> you've asked for, but you'll be able to experiment again with
> the code provided by Daniel Kluss, this time with a fast
> interpreter and Translator.
I did not expect non-blocking support in the alpha release, although
I am hoping it will be implemented in the near future :) That is one
feature I think almost everyone here would benefit from.
----If you continue to do what you have always done,
you will get what you have always gotten.----
49. Re: Why some people have not upgraded
Robert Craig wrote:
> In the next 3 to 4 weeks, there will probably be some kind
> of "pre-alpha" release of multitasking in the
> (C-backend) interpreter, and the Translator. It's unlikely I'll
> have built-in non-blocking support that you've asked for,
> but you'll be able to experiment again with the code
> provided by Daniel Kluss, this time with a fast interpreter
> and Translator. I don't want to speculate on when a full alpha
> release will happen. There are several other things I'd like
> to include in a 3.0 alpha release besides multitasking.
Rob
Does this mean that you are adding to the size of the interpreter ?
Will this effect the speed ?
Why are you adding a feature requested by 3 or 4 users and just
ignore the things that have been requested by many users in the past ?
I guess the sqeaky wheel gets the grease and the features that
few users need will be added just to please the few.
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
50. Re: Why some people have not upgraded
Bernie Ryan wrote:
>
> Rob
> Does this mean that you are adding to the size of the interpreter ?
> Will this effect the speed ?
> Why are you adding a feature requested by 3 or 4 users and just
> ignore the things that have been requested by many users in the past ?
> I guess the sqeaky wheel gets the grease and the features that
> few users need will be added just to please the few.
Hi Bernie,
What features are you referring too? I do not think Rob has committed to
any alternative parsing methods yet, and non-blocking support wont be added
for quite sometime, although that is a critical feature.
----If you continue to do what you have always done,
you will get what you have always gotten.----
51. Re: Why some people have not upgraded
Bernie Ryan wrote:
> Does this mean that you are adding to the size of the interpreter ?
Yes. For instance, exw.exe has increased in size
from 104,440 bytes to 107,520 bytes because of multitasking.
> Will this effect the speed ?
For almost all operations, no, though if you try very hard
you might be able to measure a tiny slowdown with recursion
in the interpreter, but not in translated code. On the other hand,
some programs will run much faster, because it will be easy
to let one task block (and poll) while letting other tasks
proceed to do useful work.
> Why are you adding a feature requested by 3 or 4 users and just
> ignore the things that have been requested by many users in the past ?
> I guess the sqeaky wheel gets the grease and the features that
> few users need will be added just to please the few.
I do what I think is best, and of course some people are
disappointed. I don't "ignore" what people want.
You've been on EUforum long enough to know that squeaky
wheels, such as yourself, usually do *not* get the grease.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
52. Re: Why some people have not upgraded
On Sun, 01 Jan 2006 16:24:14 -0800, "Robert Craig"
<guest at RapidEuphoria.com> said:
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Vincent wrote:
> > BTW, have you decided on whether the next release will be version 2.6 or
> > 3.0?
> > Based on release history, you've jumped from version 1.5 to 2.0; shouldn't
> > you
> > continue that trend?
>
> OK, you've convinced me.
> The next release will be 3.0
>
> Multitasking, although most programs won't use it,
> is a fundamental change in the way that Euphoria
> programs can be run. There can now be many different
> "threads of execution", running in parallel with each other,
> and utilizing multiple independent call stacks.
>
> If I don't use this opportunity to jump to 3.0,
> then the release after this one might be just a large collection
> of minor enhancements and bug fixes, and I might have
> trouble ever justifying the jump.
WHOA!!!
Non-Blocking i/o is the major excuse to bump version no, surely.
Pete
--
petelomax at fastmail.fm
--
http://www.fastmail.fm - Email service worth paying for. Try it for free
53. Re: Why some people have not upgraded
On Sun, 01 Jan 2006 16:24:06 -0800, "Robert Craig" said:
> It's an interesting idea, and I actually implemented something like
> this on a compiler I worked on about 15 years ago, before Euphoria.
> In those days, a compile would often take half an hour (on a machine
> a bit slower than a 386). We were able to reduce this time somewhat
> by doing what you are proposing.
>
> However, Euphoria is supposed to be a simple language.
> I would not want to add this complexity to the front end,
> plus complexity to the manual, as well as having newbies
> constantly say "what are those extra files for?".
> In theory it would be "transparent", but people would still
> see the extra files lying around, and if anything went wrong,
> they would wonder if they were really up-to-date.
>
> At some point, I'm going to look into shrouding of include
> files, to get a .il that can be included. I'm not sure how
> it will go, but I'd rather do that than complicate the
> whole process of running the interpreter. I do not want to
> introduce another type of intermediate file.
I would be interested in helping (non-shrouded, I suppose) where I
can. Is there, perchance, (I /am/ Lancastrian, so I understand the
mantra "if you don't ask, you don't get") any code from 2.4 which you
feel has been utterly replaced by 2.5, or any hints you might give as
to how such could be done open-source in eu.ex?
"No" is a valid answer,
Pete
--
petelomax at fastmail.fm
--
http://www.fastmail.fm - IMAP accessible web-mail
54. Re: Why some people have not upgraded
- Posted by Robert Craig <rds at RapidEuphoria.com>
Jan 03, 2006
-
Last edited Jan 04, 2006
petelomax wrote:
> Rob Craig wrote:
> > At some point, I'm going to look into shrouding of include
> > files, to get a .il that can be included. I'm not sure how
> > it will go, but I'd rather do that than complicate the
> > whole process of running the interpreter. I do not want to
> > introduce another type of intermediate file.
>
> I would be interested in helping (non-shrouded, I suppose) where I
> can. Is there, perchance, (I /am/ Lancastrian, so I understand the
> mantra "if you don't ask, you don't get") any code from 2.4 which you
> feel has been utterly replaced by 2.5, or any hints you might give as
> to how such could be done open-source in eu.ex?
>
> "No" is a valid answer,
> Pete
I haven't looked into shrouding of includes for 2.5 (and later),
except to note that while it's not "rocket science", it would
be complicated. If you have any ideas, I'd be interested, but
since I'm selling the Binder, I can't reveal the RDS .il format,
and therefore can't work openly with anyone else on this.
The 2.4 Binder has several bugs. Shrouding of includes in 2.4 was
possible, but few tried it, and those that did usually realized
it didn't work the way they really wanted. For instance,
it was *not* a transparent replacement for a clear-source include file.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
55. Re: Why some people have not upgraded
- Posted by Vincent <darkvincentdude at yahoo.com>
Jan 03, 2006
-
Last edited Jan 04, 2006
Robert Craig wrote:
> I haven't looked into shrouding of includes for 2.5 (and later),
> except to note that while it's not "rocket science", it would
> be complicated. If you have any ideas, I'd be interested, but
> since I'm selling the Binder, I can't reveal the RDS .il format,
> and therefore can't work openly with anyone else on this.
> The 2.4 Binder has several bugs. Shrouding of includes in 2.4 was
> possible, but few tried it, and those that did usually realized
> it didn't work the way they really wanted. For instance,
> it was *not* a transparent replacement for a clear-source include file.
OK, if people want this ability then I have nothing against it, but still fail
to see the need for this in most cases.
Why would people want to "hide" parts of their code, while offering the rest? If
they did, they could just make DLLs and SOs that have further benefits of faster
execution, and in some cases, work in other languages.
If it's mainly to improve loading, they could use DLLs and SOs that have zero
parsing too; they would also get faster execution as a free bonus.
Could it be that they prefer a shrouded include method because they don't wish
to buy the translator? But they would need to by the Binder right?
The translator costs ten dollars more than the binder, but they could try the
free version. Ten dollars extra is a small price to pay for the extra speed
improvements, tracing ability, and the ability to make Euphoria DLLs or SOs.
Regards,
Vincent
56. Re: Why some people have not upgraded
>Robert Craig wrote:
>
>> I haven't looked into shrouding of includes for 2.5 (and later),
>> except to note that while it's not "rocket science", it would
>> be complicated. If you have any ideas, I'd be interested, but
I had a think. Suppose win32lib.ew is:
<some code>
include dll.e
<...>
Then (full source shown):
include win32lib.ew
and
include dll.e
include win32lib.ew
would require two different .il images for win32lib.ew, one with dll.e
embedded and one which references the previously loaded instance.
If the rule was made that include xxx.il could only occur as the very
first line of a program, then it would not require any relocation or
fixups of any references to external globals, just insertions of the
new globals into the hash lookup table(s), which would make things far
easier.
My current thought is that an include xxx.il statement should
(obviously) load the .il if it exists, if not find the corresponding
source file and compile it normally, and at eof could dump the (whole)
symbol (and hash) table to file. The programmer would just need to
(manually) delete the .il file to force it to be rebuilt, and/or Edita
could do so automatically.
The missing file extension might be a problem, maybe:
include win32lib[.il from [win32lib]].ew [as win32]
If a program uses a number of standard libs, it could just use a
simple stub file containing all the required include statements. When
using a library like win32lib, it is usually/often about 90% of the
source anyway, for more complex programs, the programmer can manually
add selected (completed) components (barring forward reference issues)
to this file. In practice, aiming for anything over 80% is a waste of
time anyway, since that is what binding is for.
I shall sleep on this a few days, see if any further thoughts arise.
>> since I'm selling the Binder, I can't reveal the RDS .il format,
>> and therefore can't work openly with anyone else on this.
>
>> The 2.4 Binder has several bugs. Shrouding of includes in 2.4 was
>> possible, but few tried it, and those that did usually realized
>> it didn't work the way they really wanted. For instance,
>> it was *not* a transparent replacement for a clear-source include file.
>
Vincent wrote:
>OK, if people want this ability then I have nothing against it, but still fail
>to see the need for this in most cases.
To reduce the load time in 2.5, perhaps?
>
>Why would people want to "hide" parts of their code, while offering the rest?
Edita has two such (optional) components, Print Preview and Window
Painter. Not that there is any way yet to pay for them even if you
wanted to, but I am keeping that option open. Shipping a single
win32lib.il rather than the complete source also strikes me as a
reasonable idea.
> If they did, they could just make DLLs and SOs
The bulk of win32lib is constants, which, cmiiw, do not go well in dll
Regards,
Pete
57. Re: Why some people have not upgraded
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Jan 04, 2006
-
Last edited Jan 05, 2006
Pete Lomax wrote:
>
> If the rule was made that include xxx.il could only occur as the very
> first line of a program, then it would not require any relocation or
> fixups of any references to external globals, just insertions of the
> new globals into the hash lookup table(s), which would make things far
> easier.
This I think I can do [in ooeu] fairly easily. I'd basically load the
shrouded code, and then start parsing as though I were in the middle
(which I would be). There are some additional bookkeeping things that
I think would need to be updated, but I don't see why it couldn't work.
Matt Lewis
58. Re: Why some people have not upgraded
- Posted by "SIX-S" <sixs at ida.net>
Jan 05, 2006
-
Last edited Jan 06, 2006
I have been away from Euphoria for a while creating web sites in php. The
letters main subject seems to be complaining about Euphoria and the
developer of Euphoria, Robert Craig. Hasen't this been beat to death
enough?? If I am not happy enough I'll go to another language.
Lets get a new sbject.
Jvandal
59. Re: Why some people have not upgraded
On Thu, 5 Jan 2006 13:03:02 -0700, SIX-S <sixs at ida.net> wrote:
>I have been away from Euphoria for a while creating web sites in php. The
Welcome back
>letters main subject seems to be complaining about Euphoria and the
>developer of Euphoria, Robert Craig. Hasen't this been beat to death
>enough?? If I am not happy enough I'll go to another language.
>Lets get a new sbject.
A few small points:
1) The original title was not really intended as a "moan", afaict
2) It does help to keep the original thread title. Arguably some posts
warranted a change of subject: case in point: yours 
)
3) Some old-timers will always be somewhat disappointed by a new
release/announcement/lack of change, but they are still here, a fact
that no doubt amuses RC a little
4) It is also very easy to mistake genuine discussion (which is a very
necessary thing, imo) for repetitive whining.
Regards,
Pete
