1. RE: Moving on...
Derek Parnell wrote:
>
>
> On Wed, 13 Aug 2003 11:45:49 +0000 (08/13/03 21:45:49)
> , Peter Willems <peter at integratedmoves.com> wrote:
>
> >
> > I've made the decision...
>
> [big snip]
>
> I do agree with all your sentiments.
>
> Basically, Euphoria is not yet ready for commercial applications. It is
> *so* close but I couldn't rely on apps written in Euphoria to be robust.
>
> And as you mention, general development time is greatly reduced with
> Euphoria.
>
> I'm not giving up on it yet either.
>
> The main problems, IMHO...
>
> ** No crash clean up routine.
>
> ** No easy access to GUI, Databases, Internet development. Currently we
> must either do these from first principles or use unoffical libraries
> that
> are still in development. This is similar to starting with a C compiler
> without access to commercial libraries.
>
> ** Not many trained developers available. (This is a minor issue as
> learning Eu is very fast).
>
> --
>
> cheers,
> Derek Parnell
>
Hi Derek,
I agree too, but at least now im seeing the event horizon where
Euphoria starts to take on serious competition. Before namespaces
i just didnt see it happening. Other small improvements are
starting to accumulate also which make it more versatile.
If we take a brief (albiet VERY brief 
look into the past,
it wasnt all that long ago when people were discussing how much
better Euphoria was then QBASIC, and now it's just taken for
granted. Euphoria is now so much better then BASIC that isnt
even an issue anymore.
Im having fun building up my own recent library,
but i do find it a bit tedious to have to start everything
from the very ground up -- after all most of the programming
is getting the basic functionality of C before you can even
start doing anything else.
More small improvements will help though i'm sure.
Maybe we should start a 'wish list' for 2.5 to submit to Rob now?
Top of my list is 'reuseable include files'.
Take care for now,
Al
2. RE: Moving on...
Al Getz wrote:
>
> Maybe we should start a 'wish list' for 2.5 to submit to Rob now?
>
Hello all,
First time post but long time user.
Anyway, from the web site: wwww.rapideuphoria.com/news.htm
**What's Next?
**
**We are now considering major feature requests for 2.5!
Notice the "major feature" ;)
Marc
3. RE: Moving on...
>
> **What's Next?
> **
> **We are now considering major feature requests for 2.5!
>
> Notice the "major feature" ;)
>
Off the top of my head, what I want (nothing new here):
-- allow a custom type (or something like it) to
actually override the value being assigned and
change it to something else (I would love this!)
-- exception handling system (tied in with above)
-- custom crash clean-up
-- variable_id() or equivalent
-- a conditional operator ( like "s = (a > b) ? a : b" in C )
-- exit(x) to break out of nested loops (exit would be short for
exit(1))
-- "continue" to skip rest of eval of this iteration of loop and
start next iteration now
-- some new shorthand, specifically to make slicing of sequences
easier:
-- a single symbol meaning "length(this sequence)" ($ maybe)
-- negative indexes to indicate "x many elements from end"
4. RE: Moving on...
Marc Giao wrote:
>
>
> Al Getz wrote:
> >
> > Maybe we should start a 'wish list' for 2.5 to submit to Rob now?
> >
>
> Hello all,
>
> First time post but long time user.
>
> Anyway, from the web site: wwww.rapideuphoria.com/news.htm
>
> **What's Next?
> **
> **We are now considering major feature requests for 2.5!
>
> Notice the "major feature" ;)
>
> Marc
>
Hello Marc and welcome to the active list.
Thanks for pointing that out. I missed that i guess 'cause i
dont read everything I guess it would be good to check
the 'News' now and then.
Take care for now,
Al
5. RE: Moving on...
euman at bellsouth.net wrote:
>
>
> ----- Original Message -----
> From: "Al Getz" <Xaxo at aol.com>
>
> > More small improvements will help though i'm sure.
> > Maybe we should start a 'wish list' for 2.5 to submit to Rob now?
> >
> > Top of my list is 'reuseable include files'.
> >
> > Take care for now,
> > Al
>
> Multi-process execution / thread capable...
> Multi-process execution / thread capable...
> Multi-process execution / thread capable...
>
> [Goto] [label] inside proc / func
> possibly an EXIT
>
> sequence expected_var
> expected_var = {1,2}
>
> procedure proc(var)
> :init_label
> if var = expected_var[1] then
> GOTO first_label
> elsif var = expected_var[2] then
> GOTO second_label
> else GOTO init_label end if
>
> :first_label
> "Well, Im in the first_label now"
> EXIT
> :second_label
> "Well, Im in the second_label now"
> EXIT
> -- you'll argue the point that I would continuosly loop if (var) isnt
> either of
> -- the (expected_var) sequence. Answer, (var) could be an in ram pointer
> -- that is changed....IF we had multi-process control.
> end procedure
>
> I dont need 1000 explanations on how to make this work in Euphoria now,
> just making a generalized statment....
>
> Euman
>
>
Very good idea, definitely.
Two threads would be good enough--one for background and
one for forground. That would handle a lot.
For now im using queried functions instead of plain ol'
take-as-long-as-you-want-to-return functions when the
need arises for multithread-like behavior.
It's a little harder but it works.
Is that general enough?
Take care for now,
Al
P.S.
Keeping an eye out for another update on the File Manager
6. RE: Moving on...
Derek Parnell wrote:
> On Wed, 13 Aug 2003 11:45:49 +0000 (08/13/03 21:45:49)
> , Peter Willems <peter at integratedmoves.com> wrote:
>
> >
> > I've made the decision...
>
> [big snip]
>
> I do agree with all your sentiments.
>
> Basically, Euphoria is not yet ready for commercial applications. It is
> *so* close but I couldn't rely on apps written in Euphoria to be robust.
>
My point also.
> And as you mention, general development time is greatly reduced with
> Euphoria.
I'm still VERY impressed with how compact the language is.
> I'm not giving up on it yet either.
Luckilly so, as it seems to me that you are one of the driving
forces behind the community 
> The main problems, IMHO...
>
> ** No crash clean up routine.
Agreed, Eu needs good exception handling.
> ** No easy access to GUI, Databases, Internet development.
Tmo a good IDE would go a long way here, but I agree that the
actual libraries (that would be managed by that IDE) are not
yet "there" also.
> Currently we
> must either do these from first principles or use unoffical libraries
> that
> are still in development. This is similar to starting with a C compiler
> without access to commercial libraries.
I think that the fact that many libraries are immature is the
result of several things:
- Not enough combined effort, most libraries are one-man shows.
- Not enough testing of new version of the libraries to make
sure that problems get ironed out.
I think that a lot has to do with the fact that the community
is "losely" organized. What Euphoria needs most is a dedicated
community website (www.euphoria.org anyone ?) with dedicated
forum areas, a wikiwikiweb for brainstorming and decision making,
an online CVS system where library development can be controlled,
etc.
> ** Not many trained developers available. (This is a minor issue as
> learning Eu is very fast).
Yep, but if there would be a central community website, I'm sure
that there could also be more documentation available to get
new users up to speed even faster.
Hans Peter Willems
7. RE: Moving on...
Hello Peter,
Interesting stuff.
Peter Willems wrote:
>
> - Not enough combined effort, most libraries are one-man shows.
> - Not enough testing of new version of the libraries to make
> sure that problems get ironed out.
>
> I think that a lot has to do with the fact that the community
> is "losely" organized. What Euphoria needs most is a dedicated
> community website (www.euphoria.org anyone ?) with dedicated
> forum areas, a wikiwikiweb for brainstorming and decision
>making,
> an online CVS system where library development can be
>controlled,
> etc.
>
> Hans Peter Willems
>
Certainly some very very nice ideas here. Anything like
that would be great.
It's true that development goes faster when there is more
then one person working on something, but the thing is,
does everyone really want to work on the same exact project?
Usually this isnt the case unless there is some concrete
reward, even if it's small. Most people i think do what they
do because they really want to do it, not because they are
getting paid
Also, what if one person wants to do it THIS way, and the
other person wants to do it THAT way?
Also, how would you organize the several libraries developments?
Some ideas?
Not enough testing of existing libraries:
Yes, but it's hard to find people who are willing to take
the time to download files and do the required set up,
and also be able to return reasonable results with the limited
documentation that comes with most libraries (not all) knowing
it's an alpha or beta.
Most people want stuff that already works.
You have to keep up with the current releases too.
My idea on this would be to share the testing load, by
testing one application for another person that in return tests
your application. The prerequisite would be good documentation
to help understand the requirements as well as what to look for.
The only problem here is that if five people test your program,
you're going to be testing five programs that week
or feeling pretty guilty
Could be quite a learning experience i guess though because
you'd be seeing new code and new ways of doing things all the
time...
Well, take care for now,
Al
8. RE: Moving on...
Hey Al,
Thanks for your reply, again this is very inspirational.
> It's true that development goes faster when there is more
> then one person working on something, but the thing is,
> does everyone really want to work on the same exact project?
I think that other projects are showing that it can work this
way. I do think that more people would like to participate IF
they actually knew that they could. I think that some form of
project management (through a community site) would help much
to attract participants in the first place.
> Usually this isnt the case unless there is some concrete
> reward, even if it's small. Most people i think do what they
> do because they really want to do it, not because they are
> getting paid
Agreed. But I'm sure there are more people that would like
to help, just for the fun of it.
> Also, what if one person wants to do it THIS way, and the
> other person wants to do it THAT way?
This is specifically where a community website would help.
If there are specific areas where certain projects are discussed,
a framework for submitting and voting on things could be setup.
> Also, how would you organize the several libraries developments?
> Some ideas?
Same thing. The development sources should be managed on the site
(with CVS or something like that). Each specific library should
have it's own pages on the site, including dedicated discussion
areas on the forum, etc.
I'm confinced that this is mainly an organizational issue. With
the correct tools in place it should work.
> Not enough testing of existing libraries:
> Yes, but it's hard to find people who are willing to take
> the time to download files and do the required set up,
> and also be able to return reasonable results with the limited
> documentation that comes with most libraries (not all) knowing
> it's an alpha or beta.
The problem with testing is that there is to much time between
releases with many things added/changed each time. For testing
it would be better to release small updates that cover 2-3 changes
max each time, making it easy to test just those changes.
Of course incremental design with small-change releases needs a
community effort to share the workload AND a project system that
can manage it.
> Most people want stuff that already works.
I think with Euphoria most people want stuff to be developed so
that it works.... in a stable manner.
> You have to keep up with the current releases too.
The community website should have an RSS system (as in BLOG) that
can syndicate all news about releases into one XML-feed. There
are loads of freeware readers to keep people updated all the time.
> My idea on this would be to share the testing load, by
> testing one application for another person that in return tests
> your application. The prerequisite would be good documentation
> to help understand the requirements as well as what to look for.
> The only problem here is that if five people test your program,
> you're going to be testing five programs that week
> or feeling pretty guilty
The problem is that developers are very bad testers
The point is that if the libraries have their own development
space on the community website, problems can be discussed much
more to the point.
My experience is that testers stop testing mostly for a lack of
response from the developer(s). Communication is king.
> Could be quite a learning experience i guess though because
> you'd be seeing new code and new ways of doing things all the
> time...
The whole Euphoria experience is already big fun for me
> Well, take care for now,
You too
Hans Peter Willems
9. RE: Moving on...
From: Peter Willems
> Al Getz wrote:
> > It's true that development goes faster when there is more
> > then one person working on something, but the thing is,
> > does everyone really want to work on the same exact project?
>
> I think that other projects are showing that it can work this
> way. I do think that more people would like to participate IF
> they actually knew that they could. I think that some form of
> project management (through a community site) would help much
> to attract participants in the first place.
I think it's important to remember that a 'project team' isn't synonymous
with 'coders' (I know that Peter and Derek are posting with this in mind).
Even simple help with documentation can dramatically raise the quality of a
project. I strongly recommend using the makedoc utility that comes with
Win32Lib (I've made a lot of modifications to my copy). It makes the
process a lot less painful. Since I've started using it religiously, I
think my documentation has seen huge improvements (I'd rate most of it at
poor to fair now :). One thing that's always a turnoff to me is a short
readme.txt file saying to look at the comments in the file to see how
everything works. Please use some sort of doc generator (like the
above-mentioned makedoc.exw) that pulls those comments out into an HTML file
or something. The easier and more user friendly your projects, the better
they'll be received. It's always worth delaying a day to release if you
spend the time documenting everything. Plus testers and demo writers are a
lot of help.
One problem, as Al alludes, is that many projects cover a fairly narrow
spectrum of interest. There may be only 2 or 3 people even remotely
interested in a project in the Euphoria community. Unless its something you
feel very passionate about, without interest and feedback from others, you
*will* lose interest in any project. This often leads others to believe
that the project is dead. They don't inquire about it, seeing that it's
very incomplete and inactive, and so the developer never regains interest in
it. It's a chicken and the egg scenario in some respects.
> > Usually this isnt the case unless there is some concrete
> > reward, even if it's small. Most people i think do what they
> > do because they really want to do it, not because they are
> > getting paid
>
> Agreed. But I'm sure there are more people that would like
> to help, just for the fun of it.
We actually have a reward system. No one's going to get rich off the
MicroEconomy, but it's a great way to recognize the efforts of others, not
to mention encourage them. Personally, I feel it to be a responsibility to
put my votes in (just like voting in real elections). I don't always vote
for things that I actually have a use for, but often for projects that seem
interesting to me for one reason or another. I hope that the votes help
motivate the authors to continue to develop.
Matt Lewis
10. RE: Moving on...
- Posted by eugtk at yahoo.com
Aug 14, 2003
--- Peter Willems <peter at integratedmoves.com> wrote:
...
> I think that the fact that many libraries are
> immature is the
> result of several things:
>
> - Not enough combined effort, most libraries are
> one-man shows.
> - Not enough testing of new version of the
> libraries to make
> sure that problems get ironed out.
>
> I think that a lot has to do with the fact that
> the community
> is "losely" organized. What Euphoria needs most
> is a dedicated
> community website (www.euphoria.org anyone ?)
> with dedicated
> forum areas, a wikiwikiweb for brainstorming and
> decision making,
> an online CVS system where library development
> can be controlled,
> etc.
A good idea - if Euphoria were open source.
Unfortunately, we can brainstorm all we want, but
Rob is the one who decides what actually can be done
with the language, and he has demonstrated repeatedly
that speed and stability are his main concerns.
Find something slow - he'll fix it quickly.
Find something broken - he'll fix it even more
quickly.
This is admirable.
However, if you want something added, fugettaboutit.
Therefore, any such community will inevitably turn
into yet another "Let's write a Eu clone" site.
> > Dave wrote:
> > ** Not many trained developers available. (This is
> a minor issue as
> > learning Eu is very fast).
In order for a Eu developer to actually contribute the
things which are now needed, he or she must be very
familiar with - not just Euphoria - but some pretty
advanced concepts (databases, network protocols, the
C language, etc).
More familiar, in fact, than the average user of
other languages, who can usually just cut & paste
to get something running. The Eu developer has to
have a pretty good grasp of a lot of inner workings
before
even beginning to port those things to Eu.
Eu has to offer something more than whatever language
that programmer now uses, if we expect that programmer
to be motivated to reinvent yet another wheel.
What does Eu offer?
I don't know. Let's look instead at languages which
have *lots* of experienced programmers contributing
lots of nice things, and see if we can figure out what
they have that Eu doesn't.
All of these languages offer more than Eu, except in
the areas of speed and readability, and are far more
popular:
Python - well organized, versatile, thousands of
users, lots of development going on, open source.
Guido isn't starving.
Perl - disorganized, nearly unreadable, extremely
versatile, tens of thousands of users, hundreds of
developers contributing, open source.
Larry isn't starving.
Ruby - well organized, readable (but not as good as
Eu) thousands of users (but less than Python), lots of
developers, open source,
Matz isn't starving.
So there are perhaps a few things we can learn from
this:
1. Speed and readability aren't the only things that
matter.
2. Open source probably *does* help make a language
more popular.
3. Rob wouldn't likely starve if he made Eu open
source.
Irv
11. RE: Moving on...
> From: eugtk at yahoo.com [mailto:eugtk at yahoo.com]
> In order for a Eu developer to actually contribute the
> things which are now needed, he or she must be very
> familiar with - not just Euphoria - but some pretty
> advanced concepts (databases, network protocols, the
> C language, etc).
>
> More familiar, in fact, than the average user of
> other languages, who can usually just cut & paste
> to get something running. The Eu developer has to
> have a pretty good grasp of a lot of inner workings
> before even beginning to port those things to Eu.
>
> Eu has to offer something more than whatever language
> that programmer now uses, if we expect that programmer
> to be motivated to reinvent yet another wheel.
Yes, although perversely, this is part of why I've enjoyed using Euphoria:
it's forced me to learn a lot of new stuff to write some of the libraries
that I wrote. Not that I recommend this for everyone, and I agree that it
really holds back a lot of development in Euphoria. In some areas I think
that the libraries are beginning to mature (Win32Lib, EuGTK, EuCOM, ODBC to
varying degrees) to the cut & paste level.
Internet programming is one of my weaknesses, but it seems to me that a lot
of internet development in Eu is based on 3rd party DLLs that wrap windows
TCP/IP functionality. From a purist perspective, it would be better if
these could be pure Eu so that a user really could cut and paste with Eu
code.
> All of these languages offer more than Eu, except in
> the areas of speed and readability, and are far more
> popular:
>
> Python - <snip>
> Guido isn't starving.
>
> Perl - <snip>
> Larry isn't starving.
>
> Ruby - <snip>
> Matz isn't starving.
>
<snip>
> 3. Rob wouldn't likely starve if he made Eu open
> source.
I've never really followed or paid any attention to any of these (languages
or authors). Here are a few questions that the business major in me would
ask:
* What is the business model that keeps them from starving? Books?
Donations?
* Is their primary means of support the language and its spinoffs?
* How did they get there?
* Is there a feasible way for Rob to get there from here? How long before
open sourced Eu would show him a profit? What sort of investment might be
required?
>From a practical standpoint, these are the [first] questions Rob has to
answer before he throws away a proven model that makes him a decent amount
of money (by his own account). I think we can all agree that Rob isn't
terribly interested in taking these steps by himself, but if a coherent
business plan were presented to him...
Matt Lewis
12. RE: Moving on...
Matt Lewis wrote:
> From: Peter Willems
> > Al Getz wrote:
> > > It's true that development goes faster when there is more
> > > then one person working on something, but the thing is,
> > > does everyone really want to work on the same exact project?
> >
> > I think that other projects are showing that it can work this
> > way. I do think that more people would like to participate IF
> > they actually knew that they could. I think that some form of
> > project management (through a community site) would help much
> > to attract participants in the first place.
>
> I think it's important to remember that a 'project team' isn't
> synonymous
> with 'coders' (I know that Peter and Derek are posting with this in
> mind).
Actually, what I had in mind is that a community website with
dedicated forums, wiki, etc, might invite many "non-coders" to
participate in other ways as well. For example, discussion about
a needed feature is already "participation" in my book. I also
know that many coders measure the interest in their "product" by
the amount of input they get from users.
> Even simple help with documentation can dramatically raise the quality
> of a
> project. I strongly recommend using the makedoc utility that comes with
> Win32Lib (I've made a lot of modifications to my copy). It makes the
> process a lot less painful. Since I've started using it religiously, I
> think my documentation has seen huge improvements (I'd rate most of it
> at
> poor to fair now :). One thing that's always a turnoff to me is a short
> readme.txt file saying to look at the comments in the file to see how
> everything works. Please use some sort of doc generator (like the
> above-mentioned makedoc.exw) that pulls those comments out into an HTML
> file
> or something. The easier and more user friendly your projects, the
> better
> they'll be received. It's always worth delaying a day to release if you
> spend the time documenting everything. Plus testers and demo writers
> are a
> lot of help.
I would even recommend raising such documentation and a specific
doc-generator as a must for the projects that are hosted on such
a community website
> One problem, as Al alludes, is that many projects cover a fairly narrow
> spectrum of interest. There may be only 2 or 3 people even remotely
> interested in a project in the Euphoria community.
From my pov the community website should primarilly focus on
building the most needed libraries up to a stable version.
Starting other projects based on the community simply needs
enough participants (but I would say that three people is enough
to get something going on a usable scale).
> Unless its something you
> feel very passionate about, without interest and feedback from others,
> you
> *will* lose interest in any project. This often leads others to believe
> that the project is dead. They don't inquire about it, seeing that it's
> very incomplete and inactive, and so the developer never regains
> interest in
> it. It's a chicken and the egg scenario in some respects.
But if the project is hosted on a community website then the
developer can easy request feedback or ask if anyone else want
to participate or even take over the project. This is common
practice in other developer communities.
> > > Usually this isnt the case unless there is some concrete
> > > reward, even if it's small. Most people i think do what they
> > > do because they really want to do it, not because they are
> > > getting paid
> >
> > Agreed. But I'm sure there are more people that would like
> > to help, just for the fun of it.
>
> We actually have a reward system. No one's going to get rich off the
> MicroEconomy, but it's a great way to recognize the efforts of others,
> not
> to mention encourage them. Personally, I feel it to be a responsibility
> to
> put my votes in (just like voting in real elections). I don't always
> vote
> for things that I actually have a use for, but often for projects that
> seem
> interesting to me for one reason or another. I hope that the votes help
> motivate the authors to continue to develop.
I actually think that the reward system is nice but not usable
on a community driven website. The main goal of a community is
to "drive" that community
We need a community that will drive the development based on
creating/developing BETTER tools (like libraries) for the
community.
Hans Peter Willems
13. RE: Moving on...
eugtk at yahoo.com wrote:
<snip>
> A good idea - if Euphoria were open source.
> Unfortunately, we can brainstorm all we want, but
> Rob is the one who decides what actually can be done
> with the language, and he has demonstrated repeatedly
> that speed and stability are his main concerns.
Speed and stability are things that clearly lay within the
domain of interpreter implementation. However, libraries are
not and can be developed (as is demonstrated by many) outside
of the interpreter.
Most of the functionality of languages like Perl, Python, etc.
are handled as libraries. The main reason for the use of external
libraries is that functionality can be added fast and easy without
having to rely on releasing updates for the interpreter itself.
> Find something slow - he'll fix it quickly.
> Find something broken - he'll fix it even more
> quickly.
>
> This is admirable.
>
> However, if you want something added, fugettaboutit.
> Therefore, any such community will inevitably turn
> into yet another "Let's write a Eu clone" site.
I really see no reason for that.
> > > Dave wrote:
> > > ** Not many trained developers available. (This is
> > a minor issue as
> > > learning Eu is very fast).
>
> In order for a Eu developer to actually contribute the
> things which are now needed, he or she must be very
> familiar with - not just Euphoria - but some pretty
> advanced concepts (databases, network protocols, the
> C language, etc).
> More familiar, in fact, than the average user of
> other languages, who can usually just cut & paste
> to get something running. The Eu developer has to
> have a pretty good grasp of a lot of inner workings
> before
> even beginning to port those things to Eu.
Agreed. And the simplest way to get a lot of expertise into one
spot so everyone can build on it is by creating a community.
> Eu has to offer something more than whatever language
> that programmer now uses, if we expect that programmer
> to be motivated to reinvent yet another wheel.
>
> What does Eu offer?
>
> I don't know. Let's look instead at languages which
> have *lots* of experienced programmers contributing
> lots of nice things, and see if we can figure out what
> they have that Eu doesn't.
>
> All of these languages offer more than Eu, except in
> the areas of speed and readability, and are far more
> popular:
I think Eu has more to offer then speed and readability...
> Python - well organized, versatile, thousands of
> users, lots of development going on, open source.
> Guido isn't starving.
I looked at Python and like the language, but it is MUCH to slow.
Besides, I have to install to much supporting stuff to get even
a simple project running. It's great for large web-based
applications as the interpreter can run on a large fast server and
the internet connection is the bottleneck anyway. But don't try
to run a moderate app standalone on a PIII-450 unless you have
a lot of time on your hands.
> Perl - disorganized, nearly unreadable, extremely
> versatile, tens of thousands of users, hundreds of
> developers contributing, open source.
> Larry isn't starving.
But again, Perl is NOT a choice to write consumer applications
that can run standalone on a machine.
> Ruby - well organized, readable (but not as good as
> Eu) thousands of users (but less than Python), lots of
> developers, open source,
> Matz isn't starving.
I didn't dig to deep into Ruby, although it looks good. Besides
that it has the same problem as Eu in that there are not yet
enough supporting libraries. But I could be wrong here.
> So there are perhaps a few things we can learn from
> this:
> 1. Speed and readability aren't the only things that
> matter.
But the contribute largely to the popularity of the language.
> 2. Open source probably *does* help make a language
> more popular.
Open source languages like Python being popular is just a sign
of the time. Before the open source movement languages where
popular because of the amount available of funtion libraries.
> 3. Rob wouldn't likely starve if he made Eu open
> source.
Probably not, but it IS his decision to make.
Hans Peter Willems
14. RE: Moving on...
- Posted by eugtk at yahoo.com
Aug 14, 2003
--- Peter Willems <peter at integratedmoves.com> wrote:
> Speed and stability are things that clearly lay
> within the
> domain of interpreter implementation. However,
> libraries are
> not and can be developed (as is demonstrated by
> many) outside
> of the interpreter.
> Most of the functionality of languages like Perl,
> Python, etc.
> are handled as libraries. The main reason for the
> use of external
> libraries is that functionality can be added fast
> and easy without
> having to rely on releasing updates for the
> interpreter itself.
In some cases, yes. However, for the really important
things, such as OOP, named structures, exceptions,
and, hey, even the dreaded 'goto', libraries are no
substitute for support within the language itself.
Anything less is
doomed to be slow and awkward.
> > Python - well organized, versatile, thousands of
> > users, lots of development going on, open source.
> > Guido isn't starving.
>
> I looked at Python and like the language, but it
> is MUCH to slow.
Actually, it's fast enough for me. Where it _really_
falls down is when you get ready to ship a product.
Your customers either have to download and install
Python - what is it now, 8 megs? - or you can 'bind'
your
Python program and ship it, just like Euphoria.
Except that "Hello World" in Python binds to 4.4 megs!
> > Ruby - well organized, readable (but not as good
> as
> > Eu) thousands of users (but less than Python),
> lots of
> > developers, open source,
> > Matz isn't starving.
>
> I didn't dig to deep into Ruby, although it looks
> good. Besides
> that it has the same problem as Eu in that there
> are not yet
> enough supporting libraries. But I could be wrong
> here.
Just from reading the ruby newsgroup, it seems that
there is a Ruby answer for most any question,
including
the ones we discuss here so often - internet
connectivity,
database connectivity, etc. And it's usually simple
and
straighforward.
> > So there are perhaps a few things we can learn
> from
> > this:
> > 1. Speed and readability aren't the only things
> that
> > matter.
>
> But the contribute largely to the popularity of
> the language.
All the ones named above are slower than Eu, yet
they are far more popular, even to the point that
they are acceptable for actual commercial work.
Which Eu isn't.
So there must be other, more important factors at
work.
Irv
15. RE: Moving on...
- Posted by eugtk at yahoo.com
Aug 14, 2003
--- Matt Lewis <matthewwalkerlewis at yahoo.com> wrote:
> I've never really followed or paid any attention to
> any of these (languages
> or authors). Here are a few questions that the
> business major in me would
> ask:
>
> * What is the business model that keeps them from
> starving? Books?
> Donations?
> * Is their primary means of support the language and
> its spinoffs?
I'm just guessing, but it's quite likely that Guido
van Rossum (Python) probably makes more just from his
speaking engagements than Rob does from Euphoria.
And he's recently gotten a new job which involves
computer security - using Python, naturally.
And of course a couple of books...
Larry Wall (perl) works full time for O'Reilly &
Associates, developing perl, and writing books about
perl.
Yukihiro Matsumoto (Ruby) writes books for O'Reilly,
also, and has written several open-source software
packages.
The problem, of course, is that hardly anyone wants
to buy a book about Euphoria. The first step would be
to determine why that is true.
Irv
16. RE: Moving on...
> From: Dan Moyer [mailto:DANIELMOYER at prodigy.net]
> Could you give some detail on the mods you've made to your copy of
> MakeDoc.exw?
>
> I ask because although I've been temporarily side-tracked, I
> was (& intend
> to return to) making an "editor" intended to make it easy to add the
> slash-tag style commenting to any existing library, so
> MakeDoc can use that
> library to create the htm doc. Idea is for library creator
> not to have to
> concern themselves with the slash-tags, just fill out a
> "form" for each
> global intended for library user use.
First, I added some categories in addition to proc/func etc to match what I
needed. Take a look at the docs for EuSQL. I changed the font and
background colors. I also added a feature to allow categories to have
parents and children, so you could navigate through sub/super categories in
the docs, and only categories without parents show up in the TOC. I just
added a /parent tag. Take a look at the source and docs for EDB for
examples of using this. I can post my copy of makedoc.exw, too, since it's
changed a bit from the current, plus my version is from before the
pre-multi-file mods.
Matt Lewis
17. RE: Moving on...
> libraries are no substitute for support within the language itself
> Irv
If you count the standard library as being "within the language" that is
certainly true. When C became popular, every compiler included console
functions such as getch(), gotoxy(), putpixel(), and clrscr(). These
were left out of the 'Standard C Library' leaving only teletype
primitives and that cost C portability and popularity.
On the Euphoria front, though, I like the language clean and pretty much
as it is. One of its strengths is that it doesn't have a
designed-by-committee architecture. Isn't Java an 80Mb download now?
18. RE: Moving on...
eugtk at yahoo.com wrote:
> All the ones named above are slower than Eu, yet
> they are far more popular, even to the point that
> they are acceptable for actual commercial work.
> Which Eu isn't.
> So there must be other, more important factors at
> work.
The easiest question I'll answer all year ...
execution speed has much less value then ease of use, functionality
and flexibility.
Regards,
Ray Smith
http://rays-web.com
19. RE: Moving on...
Kenneth Roger wrote:
> > libraries are no substitute for support within the language itself
> > Irv
>
> If you count the standard library as being "within the language" that is
>
> certainly true.
But it's still an external *library* !
That means you can add stuff to it or modify functions (as has
happened many times with the C-libs... I've seen many "revised"
standard libs when I was -into C- long ago.
> When C became popular, every compiler included console
> functions such as getch(), gotoxy(), putpixel(), and clrscr(). These
> were left out of the 'Standard C Library' leaving only teletype
> primitives and that cost C portability and popularity.
>
> On the Euphoria front, though, I like the language clean and pretty much
>
> as it is.
Me too
> One of its strengths is that it doesn't have a
> designed-by-committee architecture.
The other problem I mentioned before is that with such an
architecture, the "committee" has to agree on stuff before it's
being implemented. Having user-control over the library development
increases implementation speed.
> Isn't Java an 80Mb download now?
The SDK is indeed that big, but don't forget that it comes with
a very good IDE included (Sun's NetBeans IDE) so it's not only
the language files (errmmm...... but most of it is I believe).
Hans Peter Willems
20. RE: Moving on...
Peter Willems wrote:
> Actually, what I had in mind is that a community website with
> dedicated forums, wiki, etc, might
[snip]
> I would even recommend raising such documentation and a specific
> doc-generator as a must for the projects that are hosted on such
> a community website
[snip]
> But if the project is hosted on a community website then the
> developer can easy request feedback or ask if anyone else want
> to participate or even take over the project. This is common
> practice in other developer communities.
An "EU Community" has very little hope of developing past the current
mailing list.
People who decide to do major contributions to projects and then give
it all away will almost always decide to do it on 100% open source
projects.
Why would anyone put huge amounts of effort into helping develop Eu
furthur (i.e. by writing doco, libraries, apps, etc) when the core is
closed and is only being "very slowly" developed and 100% controlled
by 1 person???
ok a few people contribute (I was one of them) but compared to other
languages very few.
Closed source products (i.e. Euphoria, Microsoft products etc) are
made by people who want to make money.
Open Source products (i.e. Perl, Python, Ruby) are made by people who
want to make great products.
That's why these open source languages can now compete with the best
closed source languages that the biggest companies (with huge
amounts) of money develop.
When someone says ... look here is my product and I want to make it
open source they are saying help me make this a "great" product.
Very strong communities have developed around open source products
because there is a desire to "improve" software for the good of the
people. It sounds crazy but it's true!
Some may argue that open source projects are controlled by 1 person
(or small numbers of people). This is true, but if this person (or
people) don't progress as users expect then the project forks and a
new leader takes control and improves the product.
(Most open source projects these days have senior committies who vote
on changes which seems like a very good solution)
The only thing that will make Euphoria more popular is for it to
become open source. I respect Rob's choose not to do this, but the
end result is, Euphoria is lossing ground to other languages at a
very fast rate with no chance of catching up.
It is actually interesting to read this list from time to time and
hear people talking about "how to improve" Euphoria.
Talented people, I mean really talented people (I'm by no means
including myself!!!) just aren't going to jump into the Euphoria
community and write high class libs utils doco etc. It's just not
going to happen. All of these poeple are over using Perl, Python and
Ruby etc having a great time. Open Source is like a light that
flicks on in your head, when it turns on you just can't imagine why
you didn't understand it before, or why others can't see what you see!
If Euphoria is doing everything you want to it do now, then great,
if you'd like it to other things and you yourself aren't able to, or
not willing to do it, then don't hold your breath!
Ray Smith
http://rays-web.com
21. RE: Moving on...
Ray Smith wrote:
>
> Peter Willems wrote:
>
> > Actually, what I had in mind is that a community website with
> > dedicated forums, wiki, etc, might
> [snip]
> > I would even recommend raising such documentation and a specific
> > doc-generator as a must for the projects that are hosted on such
> > a community website
> [snip]
> > But if the project is hosted on a community website then the
> > developer can easy request feedback or ask if anyone else want
> > to participate or even take over the project. This is common
> > practice in other developer communities.
>
> An "EU Community" has very little hope of developing past the current
> mailing list.
> People who decide to do major contributions to projects and then give
> it all away will almost always decide to do it on 100% open source
> projects.
So where are all those files in the archive coming from then.
There are loads of libraries available but they are just not
finished enough. Tmo THAT is purely the result of lack of
response from users towards the developers, something that could
be enhanced greatly by a better organized community.
> Why would anyone put huge amounts of effort into helping develop Eu
> furthur (i.e. by writing doco, libraries, apps, etc) when the core is
> closed and is only being "very slowly" developed and 100% controlled
> by 1 person???
Maybe because it's a great programming language
> ok a few people contribute (I was one of them) but compared to other
> languages very few.
That has more to do with the "visibility" of the language.
> Closed source products (i.e. Euphoria, Microsoft products etc) are
> made by people who want to make money.
People need to eat, need to earn money to do so and some make
money by developing software. There's nothing wrong with that.
> Open Source products (i.e. Perl, Python, Ruby) are made by people who
> want to make great products.
Those people also have other means of making money, or else they
die of starvation. It is also clear that a lot of projects where
made open-source because the original owner didn't have the time
left to work on it because they found out they also had to make
a living (take a look at the Xbasic story).
I won't say that Open Source is not a viable business model, but
only for companies that make their money by selling support
packages. If you are not a support-company but instead a
development-company, you obviously need to make your money with
*development*, so you need to sell software instead of giving it
away.
> That's why these open source languages can now compete with the best
> closed source languages that the biggest companies (with huge
> amounts) of money develop.
Let's be honest here, there is currently not one Open Source
development platform that is either fully deployable for large
business platforms or has been developed without big businesses
funding or leading it's development.
When I'm talking about a development platform I mean it in the
exact sense of the words. For serious deployment you need more
then *just* the language. You need databases, GUIs, report
generators, etc. There are currently only a few languages that
are completely supported in these areas and those are ALL developed
with the help and funding of big businesses:
- Java is developed by SUN, including their Netbeans IDE
- The Eclipse Java platform is developed by IBM
There are currently no other Open Source languages that have this
level of supporting development platforms, the only other ones
available are all commercial tools like the Borland languages and
the stuff from MS.
> When someone says ... look here is my product and I want to make it
> open source they are saying help me make this a "great" product.
> Very strong communities have developed around open source products
> because there is a desire to "improve" software for the good of the
> people. It sounds crazy but it's true!
It's not crazy, it's idealism. It has nothing to do with feeding
your familly and that is something that people need to do also....
... It sounds crazy but it's true!
> Some may argue that open source projects are controlled by 1 person
> (or small numbers of people). This is true, but if this person (or
> people) don't progress as users expect then the project forks and a
> new leader takes control and improves the product.
Yep, and the original owner has no problems as he wasn't making
his income from that project in the first place.
> (Most open source projects these days have senior committies who vote
> on changes which seems like a very good solution)
Yep, and in some cases these committies are even on someone's
payroll.
Most people seem to forget that Open Source is becomming more
popular because big companies have found a way to make money
with it. Before that it was just for fun. The Linux story tells
it all.
> The only thing that will make Euphoria more popular is for it to
> become open source. I respect Rob's choose not to do this, but the
> end result is, Euphoria is lossing ground to other languages at a
> very fast rate with no chance of catching up.
I don't think Euphoria is loosing ground, just that it isn't
gaining ground fast enough.
> It is actually interesting to read this list from time to time and
> hear people talking about "how to improve" Euphoria.
Yep
> Talented people, I mean really talented people (I'm by no means
> including myself!!!) just aren't going to jump into the Euphoria
> community and write high class libs utils doco etc. It's just not
> going to happen.
So, again, where are all these libraries coming from then ?
> All of these poeple are over using Perl, Python and
> Ruby etc having a great time.
I think the Eu users also have a great time with their language
of choice. Oh, and I've never even heard a seasoned Perl coder
calling coding in Perl "fun". It's a very capable language, but
fun has nothing to do with it
> Open Source is like a light that
> flicks on in your head, when it turns on you just can't imagine why
> you didn't understand it before, or why others can't see what you see!
Open Source is a great thing, but it is not the ultimate business
model.
> If Euphoria is doing everything you want to it do now, then great,
> if you'd like it to other things and you yourself aren't able to, or
> not willing to do it, then don't hold your breath!
Agreed, but that goes for a lot of other languages also.
Hans Peter Willems
22. RE: Moving on...
- Posted by eugtk at yahoo.com
Aug 16, 2003
--- Ray Smith <smithr at ix.net.au> wrote:
> Closed source products (i.e. Euphoria, Microsoft
> products etc) are
> made by people who want to make money.
>
> Open Source products (i.e. Perl, Python, Ruby) are
> made by people who
> want to make great products.
That's it, in a nutshell.
I'd like to add one thing:
Before you invest a lot of your valuable time in
learning
a closed-source, commercial product, you should
realize that in the never-ending quest for more money,
most companies plan for their products to become
"obsolete" and "unsupported" at a certain future date.
That date
is usually a day or two after you get really
productive with that product.
In addition, there's a real incentive to not fix bugs
-
because if they did, why would anyone buy next year's
"new and improved" edition?
Open source products tend to have a longer useful
lifespan, since they mostly operate on the theory that
'if it ain't broke, don't fix it'. And the open source
folks
see a bug as an embarassment, not as an opportunity
to sell you an upgrade.
Irv
23. RE: Moving on...
jbrown105 at speedymail.org wrote:
> There is the OpenEuphoria movement. Why has no one even mentioned that?
> There is working being done on making a compatible open source core for
> those librarys ... if what you say is true then when this is done the OE
> community will become very popular quickly.
Yes, I think if an Open Source Euphoria existed, this would become the
building blocks of many great additions which would make Euphoria far
far more popular. I'd be back to programming Euphoria full time if
an Open Source Euphoria existed.
> However, while there was a lot of initial interest, the movement has
> slowed
> quite a bit. Apparently there isn't a huge amount of interest in having
> Euphora Open source after all...
I haven't seen any real progress with OpenEU in almost a year. At the
current rate it looks like it would take up to 5 years to get even
close to the current "offifical Euphoria". It might be too late in 5
years for it to make a difference???
Ray Smith
http://rays-web.com
24. RE: Moving on...
Just some general replies ...
Open Source doesn't mean socially inept hackers coding after midnight
in a dark room. As you say Open Source is being embrassed by some of
the worlds largest companies and this is really a great advertisment
for the Open Source philosophy.
I agree Open Source isn't for everybody ... the idea behind my post
was that Euphoria (being developed the way it is) can't compete with
other languages. The only way for Euphoria to take the next big
step forward is to become open source.
Obviously if Euphoria's income is being used to "feed the family" so
to speak no one could (or should) try to make RDS make it open source.
If Euphoria's income isn't doing that, then I'm saying there are some
really strong arguements to make Euphoria open source.
Looking through all of the Eu contributions I'd say that few are
useful, even less are at any level of completeness and most are
not updated anymore as the original authors have moved on. There are
a few really good libs/tools/utilities ... but really ... not that
many.
Ray Smith
http://rays-web.com
Peter Willems wrote:
Ray Smith wrote:
>
> Peter Willems wrote:
>
> > Actually, what I had in mind is that a community website with
> > dedicated forums, wiki, etc, might
> [snip]
> > I would even recommend raising such documentation and a specific
> > doc-generator as a must for the projects that are hosted on such
> > a community website
> [snip]
> > But if the project is hosted on a community website then the
> > developer can easy request feedback or ask if anyone else want
> > to participate or even take over the project. This is common
> > practice in other developer communities.
>
> An "EU Community" has very little hope of developing past the current
> mailing list.
> People who decide to do major contributions to projects and then give
> it all away will almost always decide to do it on 100% open source
> projects.
So where are all those files in the archive coming from then.
There are loads of libraries available but they are just not
finished enough. Tmo THAT is purely the result of lack of
response from users towards the developers, something that could
be enhanced greatly by a better organized community.
> Why would anyone put huge amounts of effort into helping develop Eu
> furthur (i.e. by writing doco, libraries, apps, etc) when the core is
> closed and is only being "very slowly" developed and 100% controlled
> by 1 person???
Maybe because it's a great programming language
> ok a few people contribute (I was one of them) but compared to other
> languages very few.
That has more to do with the "visibility" of the language.
> Closed source products (i.e. Euphoria, Microsoft products etc) are
> made by people who want to make money.
People need to eat, need to earn money to do so and some make
money by developing software. There's nothing wrong with that.
> Open Source products (i.e. Perl, Python, Ruby) are made by people who
> want to make great products.
Those people also have other means of making money, or else they
die of starvation. It is also clear that a lot of projects where
made open-source because the original owner didn't have the time
left to work on it because they found out they also had to make
a living (take a look at the Xbasic story).
I won't say that Open Source is not a viable business model, but
only for companies that make their money by selling support
packages. If you are not a support-company but instead a
development-company, you obviously need to make your money with
*development*, so you need to sell software instead of giving it
away.
> That's why these open source languages can now compete with the best
> closed source languages that the biggest companies (with huge
> amounts) of money develop.
Let's be honest here, there is currently not one Open Source
development platform that is either fully deployable for large
business platforms or has been developed without big businesses
funding or leading it's development.
When I'm talking about a development platform I mean it in the
exact sense of the words. For serious deployment you need more
then *just* the language. You need databases, GUIs, report
generators, etc. There are currently only a few languages that
are completely supported in these areas and those are ALL developed
with the help and funding of big businesses:
- Java is developed by SUN, including their Netbeans IDE
- The Eclipse Java platform is developed by IBM
There are currently no other Open Source languages that have this
level of supporting development platforms, the only other ones
available are all commercial tools like the Borland languages and
the stuff from MS.
> When someone says ... look here is my product and I want to make it
> open source they are saying help me make this a "great" product.
> Very strong communities have developed around open source products
> because there is a desire to "improve" software for the good of the
> people. It sounds crazy but it's true!
It's not crazy, it's idealism. It has nothing to do with feeding
your familly and that is something that people need to do also....
... It sounds crazy but it's true!
> Some may argue that open source projects are controlled by 1 person
> (or small numbers of people). This is true, but if this person (or
> people) don't progress as users expect then the project forks and a
> new leader takes control and improves the product.
Yep, and the original owner has no problems as he wasn't making
his income from that project in the first place.
> (Most open source projects these days have senior committies who vote
> on changes which seems like a very good solution)
Yep, and in some cases these committies are even on someone's
payroll.
Most people seem to forget that Open Source is becomming more
popular because big companies have found a way to make money
with it. Before that it was just for fun. The Linux story tells
it all.
> The only thing that will make Euphoria more popular is for it to
> become open source. I respect Rob's choose not to do this, but the
> end result is, Euphoria is lossing ground to other languages at a
> very fast rate with no chance of catching up.
I don't think Euphoria is loosing ground, just that it isn't
gaining ground fast enough.
> It is actually interesting to read this list from time to time and
> hear people talking about "how to improve" Euphoria.
Yep
> Talented people, I mean really talented people (I'm by no means
> including myself!!!) just aren't going to jump into the Euphoria
> community and write high class libs utils doco etc. It's just not
> going to happen.
So, again, where are all these libraries coming from then ?
> All of these poeple are over using Perl, Python and
> Ruby etc having a great time.
I think the Eu users also have a great time with their language
of choice. Oh, and I've never even heard a seasoned Perl coder
calling coding in Perl "fun". It's a very capable language, but
fun has nothing to do with it
> Open Source is like a light that
> flicks on in your head, when it turns on you just can't imagine why
> you didn't understand it before, or why others can't see what you see!
Open Source is a great thing, but it is not the ultimate business
model.
> If Euphoria is doing everything you want to it do now, then great,
> if you'd like it to other things and you yourself aren't able to, or
> not willing to do it, then don't hold your breath!
Agreed, but that goes for a lot of other languages also.
Hans Peter Willems
Ray Smith
http://rays-web.com
25. RE: Moving on...
Ray Smith wrote:
> Just some general replies ...
>
> Open Source doesn't mean socially inept hackers coding after midnight
> in a dark room. As you say Open Source is being embrassed by some of
> the worlds largest companies and this is really a great advertisment
> for the Open Source philosophy.
That was exactly what I meant. It also means that there is
money involved. Anyone who thinks that Open Source is about
"free software" is completely missing the point. Open Source
is about maintainable products. But I think I don't have to
convince you at this point as I take you see it the same way.
In that same way I agree that Open Source could be good for
Euphoria.
> I agree Open Source isn't for everybody ... the idea behind my post
> was that Euphoria (being developed the way it is) can't compete with
> other languages. The only way for Euphoria to take the next big
> step forward is to become open source.
.... or get a lot of funding... or both.
The fact that some great languages are Open Source does not mean
that only Open Source languages are good. There are many non
Open Source languages as well that are very good. Actually the
Open Source languages are still very much in the minority. The fact
that a few Open Source languages are so popular has more to do with
the "free software" idea then the "maintainability" idea.
> Obviously if Euphoria's income is being used to "feed the family" so
> to speak no one could (or should) try to make RDS make it open source.
That was my point indeed.
> If Euphoria's income isn't doing that, then I'm saying there are some
> really strong arguements to make Euphoria open source.
But there are also arguments to keep it proprietary. There is
a very important reason that Sun is not releasing Java into
Open Source and I think it is for keeping a standard.
> Looking through all of the Eu contributions I'd say that few are
> useful, even less are at any level of completeness and most are
> not updated anymore as the original authors have moved on.
As I said before, I think developers move on because of lack of
user feedback. If nobody (seems to) use your stuff, than why
bother.
> There are
> a few really good libs/tools/utilities ... but really ... not that
> many.
It's a start
Hans Peter Willems
26. RE: Moving on...
jbrown105 at speedymail.org wrote:
> So, perhaps the reason Java isnt open source has nothing to do with
> keeping
> it a standard after all... (or at best, if that is a reason, its a
> misguided
> one imho).
AFAIK the source code of Java can be downloaded from Sun but you are
not allowed to re-distribute derivate versions of it.
Hence, the source code is available but it doesn't fit the "open
source" model.
As you say, the reason for this was to stop MS from railroading Java
with their own version and creating splintered versions. (i.e. the
reason MS created C#).
Ray Smith
http://rays-web.com
27. RE: Moving on...
jbrown105 at speedymail.org wrote:
On Mon, Aug 18, 2003 at 02:46:33PM +0200,
Christian.CUVIER at agriculture.gouv.fr wrote:
> > The interest on OE died a bit with the dropping of PEU (which is not
> > really true
> > even - my runtime lib "borrows" a great deal of code from PEU, tho it is
> > considerably cleaned up).
> >
> > I'm hoping, when I finish my translator, it will rise up again. (But
> > right now
> > I'm using my "made up" OE specs, since Derek and CChris havent produced
> > me
> > an official OE standard v0.1 yet -- but no rush guys ;)
> >
>
> Quite a few descriptions of aspects of OE and the expected features ie
> in the "description" posts I posted on OpenEu. Due to the general lack
> of comments, I don't know if there is broad agreement, broad
> disagreement or anything in between about them.
Hmmm ok. I'll have to go to topica and dig those emails up sometime (not
a big hassle tho really).
> Additionally, a voting system had been put forth to select priorities
> and make some decisions. As of today, they were 4 votes. I was wondering
>
> if it is wise to star writing solid specs on such material. I frrl Derek
>
> has to send some signal to us about that.
That could be a problem. It would seem then that there is little
interest
in designing OE. Until we get more input, we can either sit around and
do
nothing waiting (not only a waste of time but also not likely to gain us
more
interest) or make some presumtions about what should be put in
Some topics elicited heavy discussion, and one may form presumptions
from that. When I'm back, I post a compilation of what I think was
decided and how I think undecided things might go. That's all the horses
we have, as Rett would say.
and then make
changes to later versions after we've gotten some user feedback (part of
the
reason we might not be getting much is because users want to be able to
test
the feature out before it is decided that it is a bad idea).
P.S. Where is the voting system exactly? Last i heard one had to email
Derek,
has that changed?
AFAIU, the voting is public and consists of emails with a fixed list of
items. Casting a vote means assigning to each item a priority - I for
immediate, M for moderate, N for no, thanks.
Two rounds of voting already took place (well, the second one failed
miserably).
CChris
> I'm taking a two week leave without any Internet connection.
> Keep on the good work!
Thanks, see you in 2 weeks.
>
> CChris
>
jbrown
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME | http://verify.stanford.edu/evote.html
