1. Eu Rebellion (was: New Euphoria Users Website)
> From: jbrown105 at speedymail.org [mailto:jbrown105 at speedymail.org]
> On 0, Chris Bensler <bensler at mail.com> wrote:
<snip>
> > I personally, would rather not see any ranting, but instead
> see people
> > committing to acheive the goals themselves. Obviously this
> is up to the
> > indiviudal to decide.
<snip>
> Other than Bach and assorted modified interpreters, I don't really see
> the
> elements of your "rebellion" of Eu either.
>
> Then again, I'd doubt such rebellion would do much to Rob.
As an author of an assorted modified interpreter, I'll say that there hasn't
exactly been a lot of excitement over the new features that have been made
in the new interpreters. Karl's has certainly gotten the most press and
10.50 in micro-bucks (IIRC, Igor is the only other person to release a
modified interpreter). Of course, he's also put out the most features, and
included probably the number one request: structures.
Don't get me wrong, I didn't think that I'd created a better mouse trap, and
that everyone would instantly beat a path to my door. However, there were
at least two people (Kat, and someone else whom I can't recall, but who said
he would donate 6 months worth of mico-economy money to anyone who could
solve it) who had asked for one feature--flexible variable
referencing/creation--and a whole host of others who have asked for the
second--specifying a crash routine. To date, not only haven't I received
any micro-bucks (didn't really expect any), but I haven't gotten any user
feedback, either.
<shameless plug> One nice thing about the variable stuff is that you can use
it just for debugging--get a dump of all variables to an eds database upon a
crash basically by including one file and using my interpreter--easy to take
out and use the real deal for distribution. So you can get some real
benefit, but not be locked into a non-standard interpreter. </shameless
plug>
I don't really feel shorted by this, since I had a lot of fun doing it, and
learned a lot as well. However, it sends a message that perhaps these
things aren't that important. And guess what, that message is heard by not
only myself, but by Rob, too. I sometimes forget to vote my money, but
usually get all 3.00 up there, often for somewhat obscure things that aren't
the most useful pieces of code, but at least hit my areas of interest, or
that I think are useful things to be doing (I think I've voted for most of
the reformatted help files).
Someone recently postulated that the structure of the interpreter [being
optimized for speed rather than maintainability] was a reason for lack of
speedy changes. I disagree. I've had difficulty in modifying the source,
but I attribute that to my lack of C skills and the simple fact that I'm
wading into someone else's code (which gets multiplied by my C ineptitude).
Karl would like to sell Bach, so I wouldn't really expect him to share
source code with Rob, so it may not be so realistic to see structures, etc
put into Eu2.4--not that Rob couldn't implement them himself. I have no
such illusions about my output, however, I'd be happy to hand the code over
to Rob (or anyone else who's interested and owns the source). The only
reason I didn't release it was the license. I know I've offered it to
anyone willing to compile it on linux.
Perhaps a separate message board/mailing list for the source code. I
suppose Rob would have to maintain it in order to keep it secure and not
violate the license, but that might really spur development. Maybe just a
message board on the RDS web site with password access, where we could
exchange messages and post code? IMO, this is a very valid reason for
splitting from the main list, and might be very useful--to us and to Rob.
Matt Lewis
PS Structures are the only part of Bach that really interest me.
2. Re: Eu Rebellion (was: New Euphoria Users Website)
On 15 Nov 2002, at 8:02, Matthew Lewis wrote:
>
>
> > From: jbrown105 at speedymail.org [mailto:jbrown105 at speedymail.org]
> > On 0, Chris Bensler <bensler at mail.com> wrote:
>
> <snip>
>
> > > I personally, would rather not see any ranting, but instead
> > see people
> > > committing to acheive the goals themselves. Obviously this
> > is up to the
> > > indiviudal to decide.
>
> <snip>
>
> > Other than Bach and assorted modified interpreters, I don't really see
> > the
> > elements of your "rebellion" of Eu either.
> >
> > Then again, I'd doubt such rebellion would do much to Rob.
>
> As an author of an assorted modified interpreter, I'll say that there
hasn't
> exactly been a lot of excitement over the new features that have been
made in
> the new interpreters. Karl's has certainly gotten the most press and
10.50 in
> micro-bucks (IIRC, Igor is the only other person to release a modified
> interpreter). Of course, he's also put out the most features, and
included
> probably the number one request: structures.
>
> Don't get me wrong, I didn't think that I'd created a better mouse trap,
and
> that everyone would instantly beat a path to my door. However, there
were at
> least two people (Kat, and someone else whom I can't recall, but who
said he
> would donate 6 months worth of mico-economy money to anyone who could
solve it)
> who had asked for one feature--flexible variable
referencing/creation--and a
> whole host of others who have asked for the second--specifying a crash
routine.
> To date, not only haven't I received any micro-bucks (didn't really
expect any),
> but I haven't gotten any user feedback, either.
I don't think i asked for pass-by-reference, i had asked for variable
creation
and knowing what vars there are, which is more of an associated-list sorta
animal. I didn't know you had a crash routine, i didn't know you had a new
interpreter out until i searched the archives by "Lewis"!
Re the DDE package, i did ask for it, but i can't use it, i get this:
D:\Euphoria\dde\dde.ew:10
registerw32Function has not been declared
DdeInitialize = registerw32Function( user32, "DdeInitializeA",
Programs in the archives that fail to run are common.
> <shameless plug> One nice thing about the variable stuff is that you can
use it
> just for debugging--get a dump of all variables to an eds database upon
a crash
> basically by including one file and using my interpreter--easy to take
out and
> use the real deal for distribution. So you can get some real benefit,
but not
> be locked into a non-standard interpreter. </shameless plug>
Er,, if you use EDS, which i don't, because i didn't know i could get a
list of
the vars in it *while running*. Your's lists when it crashes. Which is
nice, but
on a database that fills the harddrive, getting a var dump after a crash
is a
bad thing.
> I don't really feel shorted by this, since I had a lot of fun doing it,
and
> learned a lot as well. However, it sends a message that perhaps these
things
> aren't that important. And guess what, that message is heard by not
only
> myself, but by Rob, too. I sometimes forget to vote my money, but
usually get
> all 3.00 up there, often for somewhat obscure things that aren't the
most useful
> pieces of code, but at least hit my areas of interest, or that I think
are
> useful things to be doing (I think I've voted for most of the
reformatted help
> files).
>
> Someone recently postulated that the structure of the interpreter [being
> optimized for speed rather than maintainability] was a reason for lack
of
> speedy changes. I disagree. I've had difficulty in modifying the
source,
> but I attribute that to my lack of C skills and the simple fact that I'm
> wading into someone else's code (which gets multiplied by my C
ineptitude).
>
> Karl would like to sell Bach, so I wouldn't really expect him to share
> source code with Rob, so it may not be so realistic to see structures,
etc
> put into Eu2.4--not that Rob couldn't implement them himself. I have no
> such illusions about my output, however, I'd be happy to hand the code
over to
> Rob (or anyone else who's interested and owns the source). The only
reason I
> didn't release it was the license. I know I've offered it to anyone
willing to
> compile it on linux.
I'd have liked to look into Karl's source just to see the examples on how
he
did things, but then too, i'd like to eliminate the restriction on the
number (not
the scope) of "goto". Problem is, he wants money for it. Like you, i
haven't
done anything productive in C. I still have the words ringing in my ears,
from
someone who got me to start use the wintel platform 10 years ago: "C won't
last as a language, it's too difficult.".
> Perhaps a separate message board/mailing list for the source code. I
> suppose Rob would have to maintain it in order to keep it secure and not
> violate the license, but that might really spur development. Maybe just
a
> message board on the RDS web site with password access, where we could
> exchange messages and post code? IMO, this is a very valid reason for
> splitting from the main list, and might be very useful--to us and to
Rob.
Not to Rob, that's the reason people are leaving.
(
Kat
3. Re: Eu Rebellion (was: New Euphoria Users Website)
Kat wrote:
> Re the DDE package, i did ask for it, but i can't use it, i get this:
> D:\Euphoria\dde\dde.ew:10
> registerw32Function has not been declared
> DdeInitialize = registerw32Function( user32, "DdeInitializeA",
>
> Programs in the archives that fail to run are common.
Your win32lib is outdated. Get at least the one year old version. (0.55.1)
The description on archive page says : "You'll probably need the New Win32Lib"
Martin
4. Re: Eu Rebellion (was: New Euphoria Users Website)
> Despite all the GUI toolkits, Euphoria is still a DOS application.
Anything
> extention beyond that has been developed by the users, and isn't
officially
> supported by RDS.
As such, why concern ourselves what will be "supported" by RDS? Let's start
a EUPHORIA Users Group that will build on the core provided by RDS. Who
cares what RobC will "support" or not? We're just using him for his core
language. :)
There are groups who do the same with Java, VB, Python, Puka, Lua,
LiverNuts, etc...
> I'm not saying this is a bad thing. That's just the way it is, and I don't
see
> any reason to think it will change in the near future.
RDS won't change it, but what stops a group of brilliant developers from
taking things as far as possible?
Or is the core of EUPHORIA just too limiting? Or are there different
roadblocks?
5. Re: Eu Rebellion (was: New Euphoria Users Website)
On 0, "C. K. Lester" <cklester at yahoo.com> wrote:
>
> > Despite all the GUI toolkits, Euphoria is still a DOS application.
> Anything
> > extention beyond that has been developed by the users, and isn't
> officially
> > supported by RDS.
>
> As such, why concern ourselves what will be "supported" by RDS? Let's start
> a EUPHORIA Users Group that will build on the core provided by RDS. Who
> cares what RobC will "support" or not? We're just using him for his core
> language. :)
>
> There are groups who do the same with Java, VB, Python, Puka, Lua,
> LiverNuts, etc...
>
> > I'm not saying this is a bad thing. That's just the way it is, and I don't
> see
> > any reason to think it will change in the near future.
>
> RDS won't change it, but what stops a group of brilliant developers from
> taking things as far as possible?
>
> Or is the core of EUPHORIA just too limiting? Or are there different
> roadblocks?
>
This was the idea behind Dredge. Exu was the core, and then the parsers
would
build on top of it. However, this didn't inspire a lot of people,
apparently,
so I've decided it may be time to put it on the back burner.
Instead, I'm gonna try to move to an open-source Exu. Perhaps this might
inspire more people?
jbrown
--
6. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by Rom <kjehas at frisurf.no>
Nov 15, 2002
-
Last edited Nov 16, 2002
From: "C. K. Lester" <cklester at yahoo.com>
> As such, why concern ourselves what will be "supported" by RDS? Let's start
> a EUPHORIA Users Group that will build on the core provided by RDS. Who
> cares what RobC will "support" or not?
Actually I think that would be wonderful! In my case, I could invest maybe $500
in tools (source/modules supplied by RDS...) if that could fit my own agenda...
Rom
7. Re: Eu Rebellion (was: New Euphoria Users Website)
On 0, David Cuny <dcuny at LANSET.COM> wrote:
> Matthew Lewis wrote:
>
> > However, if we produced working interpreters that we
> > all found useful, we might be able to demonstrate the utility and
> > effectiveness of the changes, plus giving Rob a leg up on the official
> > implementation.
>
> Having written several preprocessors and even a Euphoria interpreter, I
> disagree. Robert's reaction to most of my stuff was along the lines of
> "That's nice, but it won't happen in Euphoria." Which is, of course, entirely
> his perogative.
Seeing what I have so far, I'd have to agree with David.
>
> I don't think that people will start using alternative interpreters, either.
> Not just because they are crippled, but because there is no guarantee for
> future compatibility. The fear that a product might become unsupported is
> pretty powerful.
Very true. This doesn't explain lack of use of preprocessors, but
alternative
interpreters do have the risk of falling behind. Hence, people will not
flock
to them easily. It doesn't help that we're not allowed to share the
source
code.
>
> Despite all the GUI toolkits, Euphoria is still a DOS application. Anything
> extention beyond that has been developed by the users, and isn't officially
> supported by RDS.
True. Except for c_func/c_proc and friends, and a few misc functions
(like free_console(), or message_box()), its mostly DOS based. (Notice
that
Rob won't add more to the Win/Nix versions, such as Windows graphics to
graphics.e, but once DID offer to enhance certain elements of the DOS one
from Juergen's long-file name lib. (Then again, that might be little more
than a bug fix for the DOS file handling routines, in which case even
the DOS version has stalled, not suprisingly.)
>
> The tools for interfacing Euphoria to the Windows or GTK libraries are about
> at the level of assembly code (except assembly supports structures). The
> Euphoria editor is a DOS application, and the trace under Windows is
> basically a console window (which is why it runs so slowly).
>
> I'm not saying this is a bad thing. That's just the way it is, and I don't see
>
> any reason to think it will change in the near future.
>
> -- David Cuny
>
It won't. Not with the current situation. However, I plan to try to
create an
open-source POSIX compliant Exu. Perhaps that may inspire more users.
(Open
source, should it ever be unsupported, can easily be taken up again by
someone
else.)
jbrown
--
8. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by tone.skoda at gmx.net
Nov 15, 2002
-
Last edited Nov 16, 2002
Can bach run win32lib and other libraries and normal eu programs?
this is what i want in modified interpreter:
-structures (like in bach)
-classes (like in bach)
-better (windows) debugger
-able to run old libraries and programs
-possibly free, or some small restriction
-some other minor changes (constants in routines, routines can be anywhere,
not just before they are called, ...)
-should not be much slower than original interpreter
Once such interpreter is developed we can use it for long time and
concentrate on writing some good applications with it.
9. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by irv at take.maxleft.com
Nov 15, 2002
-
Last edited Nov 16, 2002
On Friday 15 November 2002 05:31 pm, Dave wrote:
<snip>
>
> Despite all the GUI toolkits, Euphoria is still a DOS application. Anything
> extention beyond that has been developed by the users, and isn't officially
> supported by RDS.
>
Everyone here, with one possible exception, realizes that Euphoria would have
already died out if it were not for the contributions of users like yourself,
Derek, Judith, etc.
Let's face facts, Rob's main claim to fame here is fast sequence handling.
I'm quite sure he accomplishes this without any supernatural
assistance - in other words, if he can put together the bytes to do it, so
can someone else. Perhaps that someone else could do the job even better,
avoiding some of the shortcomings of the existing scheme.
It may be that he is hoping that will happen, so he can be rid of the hassles
and go on to something else.
Regards,
Irv
10. Re: Eu Rebellion (was: New Euphoria Users Website)
Matthew Lewis wrote:
> However, if we produced working interpreters that we
> all found useful, we might be able to demonstrate the utility and
> effectiveness of the changes, plus giving Rob a leg up on the official
> implementation.
Having written several preprocessors and even a Euphoria interpreter, I
disagree. Robert's reaction to most of my stuff was along the lines of
"That's nice, but it won't happen in Euphoria." Which is, of course, entirely
his perogative.
I don't think that people will start using alternative interpreters, either.
Not just because they are crippled, but because there is no guarantee for
future compatibility. The fear that a product might become unsupported is
pretty powerful.
Despite all the GUI toolkits, Euphoria is still a DOS application. Anything
extention beyond that has been developed by the users, and isn't officially
supported by RDS.
The tools for interfacing Euphoria to the Windows or GTK libraries are about
at the level of assembly code (except assembly supports structures). The
Euphoria editor is a DOS application, and the trace under Windows is
basically a console window (which is why it runs so slowly).
I'm not saying this is a bad thing. That's just the way it is, and I don't see
any reason to think it will change in the near future.
-- David Cuny
11. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by jbrown105 at speedymail.org
Nov 15, 2002
-
Last edited Nov 16, 2002
On 0, irv at take.maxleft.com wrote:
> On Friday 15 November 2002 05:31 pm, Dave wrote:
> <snip>
> >
> > Despite all the GUI toolkits, Euphoria is still a DOS application. Anything
> > extention beyond that has been developed by the users, and isn't officially
> > supported by RDS.
> >
>
> Everyone here, with one possible exception, realizes that Euphoria would have
> already died out if it were not for the contributions of users like yourself,
> Derek, Judith, etc.
>
> Let's face facts, Rob's main claim to fame here is fast sequence handling.
> I'm quite sure he accomplishes this without any supernatural
> assistance - in other words, if he can put together the bytes to do it, so
> can someone else. Perhaps that someone else could do the job even better,
> avoiding some of the shortcomings of the existing scheme.
Back in 1993, most languages were still dealing with C type arrays and
simple strings. Now, most languages have something similar to sequences
(Java Vactors, for example), so Rob's "claim-to-fame" isn't such a claim,
after all. Only reason its alive is because of us, and its short
learning curve, again neither of which are unique to just Eu.
>
> It may be that he is hoping that will happen, so he can be rid of the hassles
> and go on to something else.
Possible, but I'd have to say unlikely. He seems to want to keep the
Euphoria
User Base alive, he just doesn't want to add too much too it. If he
wanted it to
end, he'd just give away the source for free and let others mantain new
versions.
>
> Regards,
> Irv
>
My viewpoint is that since the core of our community and code, the
interpreter,
is not controlled by us, so we will never be able to take it where we
want.
(Parsers, as I've learned, are a bit messy to use, and modified
interpreters
seem unlikely to take to the mainstream thus far.) I believe that Eu will
continue to "stagnate" until this changes.
The question then, becomes How?
jbrown
--
12. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by dm31 at uow.edu.au
Nov 16, 2002
|Having a language which behave more like we think (using
true/false/unknown as boolean type instead of True/False could open up
for logical programming ... not implemented anywhere)
I have a tri-logic library that works in C++. If some one wanted to
wrap it, or maybe port the code to use in the Interpreter natively.
It handles =, and, or, xor and not. Just email me if you want the
logic specs, or the source.
|Is it possible to make a database structure that can be linked
|together with other databases? Exiting, a killing app?
On this thought, not been one big in with database coding, has anyone
consider giving EDS the ability to be distributed? Or can it already
support distributed databases?
13. Re: Eu Rebellion (was: New Euphoria Users Website)
From: <tone.skoda at gmx.net>
> this is what i want in modified interpreter:
> -structures (like in bach)
> ....
> .....
My primery interest is using Euphoria inside other programs. When you build a
large application (in another language) you sooner or later want to add a an
application language to it(some VBA....).
Using Euphoria for prototyping also seems to be a good idea. Being able to use
Euphoria for web programming should be an easy task.
Having a language which behave more like we think (using true/false/unknown as
boolean type instead of True/False could open up for logical programming ... not
implemented anywhere)
I don't care that much about GUI programming because you can do that very well
in other IDE's.
Even if Euphoria is used for DOS programming or as some kind of scripting, I
miss an extensive IDE.... giving you all possible support.
There are difficult choices here: If the language is growing very large then the
IDE building work will also be more costly. In a changing environment smallness
means better ability to adapt.
Using A.L.I.C.E as a general purpose database frame is something that requires
only little programming code, but could change our conception of databases.
A.L.I.C.E can possible grow into a global network... Is it possible to make a
database structure that can be linked together with other databases? Exiting, a
killing app?
What I would see is clear positioning of Euphoria. You don't have to be big to
be successful (MySql and PHP isn't big).
Rom
14. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by Kat <kat at kogeijin.com>
Nov 15, 2002
-
Last edited Nov 16, 2002
On 15 Nov 2002, at 18:05, jbrown105 at speedymail.org wrote:
>
> On 0, "C. K. Lester" <cklester at yahoo.com> wrote:
> >
> > > Despite all the GUI toolkits, Euphoria is still a DOS application.
> > Anything
> > > extention beyond that has been developed by the users, and isn't
> > officially
> > > supported by RDS.
> >
> > As such, why concern ourselves what will be "supported" by RDS? Let's start
> > a
> > EUPHORIA Users Group that will build on the core provided by RDS. Who cares
> > what RobC will "support" or not? We're just using him for his core language.
> > :)
> >
> > There are groups who do the same with Java, VB, Python, Puka, Lua,
> > LiverNuts, etc...
> >
> > > I'm not saying this is a bad thing. That's just the way it is, and I don't
> > see
> > > any reason to think it will change in the near future.
> >
> > RDS won't change it, but what stops a group of brilliant developers from
> > taking things as far as possible?
> >
> > Or is the core of EUPHORIA just too limiting? Or are there different
> > roadblocks?
> >
>
> This was the idea behind Dredge. Exu was the core, and then the parsers
> would
> build on top of it. However, this didn't inspire a lot of people,
> apparently,
> so I've decided it may be time to put it on the back burner.
>
> Instead, I'm gonna try to move to an open-source Exu. Perhaps this might
> inspire more people?
Except for the "u" in exu.
Kat
15. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by jbrown105 at speedymail.org
Nov 15, 2002
-
Last edited Nov 16, 2002
On 0, Kat <kat at kogeijin.com> wrote:
> On 15 Nov 2002, at 18:05, jbrown105 at speedymail.org wrote:
<snip>
> >
> > Instead, I'm gonna try to move to an open-source Exu. Perhaps this might
> > inspire more people?
>
> Except for the "u" in exu.
>
> Kat
>
I'll try to keep DJGPP and CYGWIN support in it. Other than that, I won't
be making open-sourced exw's or ex's. (But I will consider adding code
from
other people for such native support. That is the beauty of open-source.)
jbrown
--
16. Re: Eu Rebellion (was: New Euphoria Users Website)
From: <dm31 at uow.edu.au>
> .... has anyone consider giving EDS the ability to be distributed?
> Or can it already support distributed databases?
The hash table, which is central to most databases, can return a reference given
a key. If the key is not defined, it will return nil (or you can add a new key).
EDS works like this for sure.
What ALICE does is to use natural language as a key ... (without any actual
parsing ... just simple reduction). When a key (=sentence) is inputed, then ALICE
will always return a reference. What it returns may be concise or just some
defallt answer for that category. ALICE has about 40000 categories today (it can
be expeanded to anything). You may say these categories are sorting all natural
sentences into a category. Then the creator of ALICE says that if current
chatterbot cannot handle the request (beyond a default asnwer), then it should be
possible to pass the request to another chatterbot (today the technology is right
there).
Rom
17. Re: Eu Rebellion (was: New Euphoria Users Website)
- Posted by Kat <kat at kogeijin.com>
Nov 15, 2002
-
Last edited Nov 16, 2002
On 16 Nov 2002, at 13:26, dm31 at uow.edu.au wrote:
>
> |Having a language which behave more like we think (using
> true/false/unknown as boolean type instead of True/False could open up
> for logical programming ... not implemented anywhere)
Not true, Turbo Pascal has "bytebool", which was a byte to signify the
boolean condition. You can set the level of validity of the truth, and a test of
the truth was positive for any value over 0. This may be easy in Eu
programming too.
Kat
18. Re: Eu Rebellion (was: New Euphoria Users Website)
From: "Kat" <kat at kogeijin.com>
> > true/false/unknown as boolean type instead of True/False .....
>
> Not true, Turbo Pascal has "bytebool", which was a byte to signify the
> boolean condition. You can set the level of validity of the truth, and a test
> of
> the truth was positive for any value over 0. This may be easy in Eu
> programming too.
(Delphi helpfile about ByteBool)
A Boolean variable can assume the ordinal values 0 and 1 only, but variables of
type ByteBool, WordBool, and LongBool can assume other ordinal values. An
expression of type ByteBool, WordBool, or LongBool is considered False when its
ordinal value is zero, and True when its ordinal value is nonzero. Whenever a
ByteBool, WordBool, or LongBool value is used in a context where a Boolean value
is expected, the compiler will automatically generate code that converts any
nonzero value to the value True.
This code works bad in any language:
Boolean A
if not A then ...(...action for that case)
The line should not have fired because A is uninstantiated (=unknown). We
haven't said yet that A is False (actual it does not fire in Delphi ... contrary
to above documentation).
The logic should have been:
if A then ...
else if not A then ...
else .....(meaning A is nil)
The True/False dictomy is used in all logical operators (and, or...). When
implementing T/F/nil logic here (in operators like and/or too) programming code
will change much.
The meaning of
A and B
vs
A and B (with nil states allowed)
is quite different.
The output from (A and B) in C++ or Delphi or Euphoria today is such that is
makes it unsuitable for stating anything people normally regard as a rule. You
have to know exactly how a computer program works and then make custom
programming.
But I was wrong in not making it clear that this is not only a question of a
type (custom types may be defined freely in C++/Delphi), but also a question of
control logic (which is also based on True/False).
Rom
19. Re: Eu Rebellion (was: New Euphoria Users Website)
On 15 Nov 2002, at 16:35, C. K. Lester wrote:
>
> > Despite all the GUI toolkits, Euphoria is still a DOS application.
> Anything
> > extention beyond that has been developed by the users, and isn't
> officially
> > supported by RDS.
>
> As such, why concern ourselves what will be "supported" by RDS? Let's start a
> EUPHORIA Users Group that will build on the core provided by RDS. Who cares
> what
> RobC will "support" or not? We're just using him for his core language. :)
>
> There are groups who do the same with Java, VB, Python, Puka, Lua,
> LiverNuts, etc...
>
> > I'm not saying this is a bad thing. That's just the way it is, and I don't
> see
> > any reason to think it will change in the near future.
>
> RDS won't change it, but what stops a group of brilliant developers from
> taking things as far as possible?
I guess.
> Or is the core of EUPHORIA just too limiting? Or are there different
> roadblocks?
Getting people to work together is a problem, specially me, as i won't be
around much longer. I'd like to help, but i now have no way to go get food and
no way to get it delivered. And i won't fight for it.
Kat
