OpenEuphoria

1. Why some people have not upgraded

• Posted by Vincent <darkvincentdude at yahoo.com> Dec 29, 2005
• 603 views
• 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

3. Re: Why some people have not upgraded

• Posted by Robert Craig <rds at RapidEuphoria.com> Dec 29, 2005
• 541 views
• 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

5. Re: Why some people have not upgraded

• Posted by Vincent <darkvincentdude at yahoo.com> Dec 29, 2005
• 542 views
• 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

7. Re: Why some people have not upgraded

• Posted by D. Newhall <derek_newhall at yahoo.com> Dec 30, 2005
• 528 views

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

9. Re: Why some people have not upgraded

• Posted by Vincent <darkvincentdude at yahoo.com> Dec 30, 2005
• 547 views

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

11. Re: Why some people have not upgraded

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Dec 30, 2005
• 521 views

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

13. Re: Why some people have not upgraded

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Dec 30, 2005
• 530 views

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

15. Re: Why some people have not upgraded

• Posted by don cole <doncole at pacbell.net> Dec 30, 2005
• 556 views

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>

17. Re: Why some people have not upgraded

• Posted by Alex Chamberlain <alex.chamberlain at tiscali.co.uk> Dec 30, 2005
• 541 views

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   

19. Re: Why some people have not upgraded

• Posted by C Bouzy <eucoder at hotmail.com> Dec 30, 2005
• 530 views

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.----

21. Re: Why some people have not upgraded

• Posted by C Bouzy <eucoder at hotmail.com> Dec 30, 2005
• 526 views

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.----

23. Re: Why some people have not upgraded

• Posted by C Bouzy <eucoder at hotmail.com> Dec 30, 2005
• 515 views
• 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.----

25. Re: Why some people have not upgraded

• Posted by Robert Craig <rds at RapidEuphoria.com> Dec 31, 2005
• 518 views

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

27. Re: Why some people have not upgraded

• Posted by Juergen Luethje <j.lue at gmx.de> Dec 31, 2005
• 519 views

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?

29. Re: Why some people have not upgraded

• Posted by Vincent <darkvincentdude at yahoo.com> Dec 31, 2005
• 524 views

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

31. Re: Why some people have not upgraded

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Dec 31, 2005
• 576 views

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

33. Re: Why some people have not upgraded

• Posted by Robert Craig <rds at RapidEuphoria.com> Dec 31, 2005
• 562 views
• 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

35. Re: Why some people have not upgraded

• Posted by Patrick Barnes <mrtrick at gmail.com> Jan 01, 2006
• 536 views

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
----------

37. Re: Why some people have not upgraded

• Posted by D. Newhall <derek_newhall at yahoo.com> Jan 01, 2006
• 510 views

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

39. Re: Why some people have not upgraded

• Posted by CChris <christian.cuvier at agriculture.gouv.fr> Jan 01, 2006
• 538 views

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

41. Re: Why some people have not upgraded

• Posted by Robert Craig <rds at RapidEuphoria.com> Jan 01, 2006
• 513 views
• 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

43. Re: Why some people have not upgraded

• Posted by Juergen Luethje <j.lue at gmx.de> Jan 01, 2006
• 523 views
• 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?

45. Re: Why some people have not upgraded

• Posted by Juergen Luethje <j.lue at gmx.de> Jan 01, 2006
• 525 views
• 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?

47. Re: Why some people have not upgraded

• Posted by Robert Craig <rds at RapidEuphoria.com> Jan 02, 2006
• 524 views

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

49. Re: Why some people have not upgraded

• Posted by Bernie Ryan <xotron at bluefrog.com> Jan 02, 2006
• 539 views

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

51. Re: Why some people have not upgraded

• Posted by Robert Craig <rds at RapidEuphoria.com> Jan 02, 2006
• 540 views

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

53. Re: Why some people have not upgraded

• Posted by petelomax at fastmail.fm Jan 03, 2006
• 557 views

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

55. Re: Why some people have not upgraded

• Posted by Vincent <darkvincentdude at yahoo.com> Jan 03, 2006
• 518 views
• 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

57. Re: Why some people have not upgraded

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 04, 2006
• 508 views
• 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

59. Re: Why some people have not upgraded

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 06, 2006
• 518 views

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