1. Requests for Eu 2.5
Hello all,
It would be nice to have a page on the Euphoria web site that lists what is
likely to be included in Eu 2.5. Also, if there are some popular
suggestions that are ruled out (and possibly the reason). I just thought it
could be useful for all users to have a place to view Robert's plans for
Euphoria 2.5 and on suggestions made.
Regards,
Peter Blonner
2. Re: Requests for Eu 2.5
YES, I agree!
It would be nice!
----- Original Message -----
From: "PeterBlonner" <peter at blonner.com>
To: <EUforum at topica.com>
Subject: Requests for Eu 2.5
>
>
> Hello all,
>
> It would be nice to have a page on the Euphoria web site that lists what
is
> likely to be included in Eu 2.5. Also, if there are some popular
> suggestions that are ruled out (and possibly the reason). I just thought
it
> could be useful for all users to have a place to view Robert's plans for
> Euphoria 2.5 and on suggestions made.
>
> Regards,
> Peter Blonner
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
> --
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.558 / Virus Database: 350 - Release Date: 2/01/04
>
---
--
3. Re: Requests for Eu 2.5
PeterBlonner wrote:
> It would be nice to have a page on the Euphoria web site that lists what is
> likely to be included in Eu 2.5. Also, if there are some popular
> suggestions that are ruled out (and possibly the reason). I just thought it
> could be useful for all users to have a place to view Robert's plans for
> Euphoria 2.5 and on suggestions made.
I'll consider it.
I tend to not have detailed long-term plans.
I just scan my long list of potentially useful
enhancements, mull them over, research them,
then I pick one, and do it.
At the moment I've just finished converting many thousands
of lines of C code to Euphoria. The E to C Translator,
which was formerly written 100% in C, is now written
100% in Euphoria. The new Translator is successfully
translating large programs such as Judith's IDE
(93,000 lines). The Translator even translates *itself*
successfully.
Next, I'll get the Interpreter working using 30% Euphoria
and 70% C. It will share the new Euphoria-written
front-end (parser and scanner) with the Translator.
Things are going faster on this than I expected,
and it's going to be very useful to have all this
stuff written in Euphoria. The speed of the Euphoria
code is at least as good as I expected, and I can use
profiling to analyze the hot spots, something that
wasn't easy in C.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: Requests for Eu 2.5
On 15 Jan 2004, at 21:45, Robert Craig wrote:
<snip>
> Next, I'll get the Interpreter working using 30% Euphoria
> and 70% C. It will share the new Euphoria-written
> front-end (parser and scanner) with the Translator.
Will we get the front end source code?
Kat
5. Re: Requests for Eu 2.5
Andy Serpa wrote:
> It would be nice to be able to optionally save the intermediate
> already-parsed Euphoria files (I think you called it IR code previously)
> that could be run be the interpreter, but skipping the parsing step.
> That would be especially nice for cgi scripts to get the most speed and
> the least overhead...
>
I would also like to see this.
I would like to the IR specs published when they are finalized--I would be
willing to have this done as part of the source code license, but I'd prefer
it free for all. I envision any Eu program being allowed to generate IR
code. This would be a boon to scripting because your program might well
need only a limited parser rather than the full Eu interpreter parser,
leading to easier maintainabiltity. It would also allow for highly
customized script languages to be handled more easily.
I wonder if the front end and the back end shouldn't be separate programs.
The front end would generate IR code in memory and shell to the back end,
passing the size and address of the memory block. The back end could also be
invoked directly on an IR file.
I would be willing to pay a fairly decent sum ($100 or so) for a Eu
Professional Edition that would allow me to bind a program with an alternate
front end and/or an alternate back end.
-- Mike Nelson
6. Re: Requests for Eu 2.5
Kat wrote:
> Will we get the front end source code?
I assuming that you'll get it as part of the
Interpreter Source, currently $49.
I might even get around to making a simple but slow
back-end written in Euphoria, so those who don't know C
could play around with an official Euphoria interpreter
written 100% in Euphoria. It could be translated or bound
into a stand-alone .exe. Some restrictions might apply
to protect my registration incentives.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Requests for Eu 2.5
Andy Serpa wrote:
> It would be nice to be able to optionally save the intermediate
> already-parsed Euphoria files (I think you called it IR code previously)
> that could be run be the interpreter, but skipping the parsing step.
> That would be especially nice for cgi scripts to get the most speed and
> the least overhead...
Yes, you'll be able to do that using the new shrouder/binder.
The parse time is smaller than most people think, and will
get even smaller as machines get faster - and machines will
continue to get faster at a greater rate than programs
get larger. That's why it now makes sense to parse
in Euphoria instead of C.
I currently speed up some CGI scripts by
translating/compiling them. That's another way to eliminate
the (small) parse time.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
8. Re: Requests for Eu 2.5
Mike Nelson wrote:
> I would like to the IR specs published when they are finalized--I would be
> willing to have this done as part of the source code license, but I'd prefer
> it free for all. I envision any Eu program being allowed to generate IR
> code. This would be a boon to scripting because your program might well
> need only a limited parser rather than the full Eu interpreter parser,
> leading to easier maintainabiltity. It would also allow for highly
> customized script languages to be handled more easily.
>
> I wonder if the front end and the back end shouldn't be separate programs.
> The front end would generate IR code in memory and shell to the back end,
> passing the size and address of the memory block. The back end could also be
> invoked directly on an IR file.
>
> I would be willing to pay a fairly decent sum ($100 or so) for a Eu
> Professional Edition that would allow me to bind a program with an alternate
> front end and/or an alternate back end.
I'll have to see how much work that would be.
The Intermediate Language (IL) would take a fair bit of
effort to document, and once people start coding to it,
it would become difficult to change. We'll have to see
how many people want to make alternate front-ends or back-ends.
In lieu of documentation, people could just examine my source.
In particular, they could use a back-end written in Euphoria
(if I get around to it) as a model of how the 160 or so
IL op codes are supposed to work.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Requests for Eu 2.5
Rob wrote:
<snip>
> At the moment I've just finished converting many thousands
> of lines of C code to Euphoria. The E to C Translator,
> which was formerly written 100% in C, is now written
> 100% in Euphoria. The new Translator is successfully
> translating large programs such as Judith's IDE
> (93,000 lines). The Translator even translates *itself*
> successfully.
This sounds great! I'm curious about the next Euphoria release.
In the current version of the translator, there is still that glitch
concerning abort(). When the argument to abort() is not 0, translated
programs are not compatible with interpreted programs. When the
following program:
puts(1, "Hello!")
abort(1)
is interpreted, it terminates immediately, as expected.
When translated and compiled, a console window pops up, showing a
blank line, and "Press Enter..." on the next line, waiting for the
user pressing [Enter], before it closes the window.
Firstly, I think interpreted programs and translated/compiled programs
should be as compatible as possible.
Secondly, this behaviour often is not desired by the programmer, and
s/he is not able to change it (except by changing the translated C code).
For me, abort(1), abort(2) etc. currently is unfortunately completely
useless in compiled programs.
I would appreciate it very much, if abort() would work in
translated/compiled programs exactly the same way as it currently works
in interpreted programs. If the programmer wants her/his program to
prompt the user, it is *very* easy to write the appropriate Euphoria
statements into her/his program her/himself. But the difference then is:
The programmer has the control what happens in her/his program, not the
translator. Actually the bottom line, why I started to write computer
programs, is that I want to have as much control about what my computer
does as possible. So I want any programming language to *give* me
control.
> Next, I'll get the Interpreter working using 30% Euphoria
> and 70% C. It will share the new Euphoria-written
> front-end (parser and scanner) with the Translator.
>
> Things are going faster on this than I expected,
Sorry, but your words make me curious: 
Will the new Euphoria version probably be released this year?
> and it's going to be very useful to have all this
> stuff written in Euphoria. The speed of the Euphoria
> code is at least as good as I expected, and I can use
> profiling to analyze the hot spots, something that
> wasn't easy in C.
Regards,
Juergen
--
/"\ ASCII ribbon campain | |\ _,,,---,,_
\ / against HTML in | /,`.-'`' -. ;-;;,_
X e-mail and news, | |,4- ) )-,_..;\ ( `'-'
/ \ and unneeded MIME | '---''(_/--' `-'\_)
10. Re: Requests for Eu 2.5
Juergen Luethje wrote:
> In the current version of the translator, there is still that glitch
> concerning abort(). When the argument to abort() is not 0, translated
> programs are not compatible with interpreted programs. When the
> following program:
> puts(1, "Hello!")
> abort(1)
> is interpreted, it terminates immediately, as expected.
>
> When translated and compiled, a console window pops up, showing a
> blank line, and "Press Enter..." on the next line, waiting for the
> user pressing [Enter], before it closes the window.
That's on my list.
It's trivial to fix.
> Sorry, but your words make me curious:
> Will the new Euphoria version probably be released this year?
Yes.
I don't like to wait much more than a year between releases.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
11. Re: Requests for Eu 2.5
On Fri, 16 Jan 2004 13:00:47 -0500, Robert Craig
<rds at RapidEuphoria.com> wrote:
<snip>
>The Intermediate Language (IL) would take a fair bit of
>effort to document,
Yes. Probably weeks or even months, to do it well.
> and once people start coding to it,
>it would become difficult to change.
I'd prefer to see a fairly strongly worded warning along the lines of
"The IR specification is NOT intended to be backwards compatible. Any
hand coded IR may need to be manually updated for future releases. Any
custom front-end generating IR may likewise need to be updated for
future releases. Backwards compatibility is restricted to the Euphoria
programming language, not the Intermediate Representation."...
and maybe:
"Where possible, inefficient backward compatibility may be provided,
however anyone intending to use IR directly is clearly concerned with
performance benefits, and should therefore plan additional effort to
propagate such to future releases, manually."
You should perhaps instead consider releasing 2.6 and later with an
old 2.5 back-end, which is fired up if and only if the version number
hard-wired into the IR indicates you have to. There may be some issues
with shared data and threading/forking style concepts that would need
to be resolved for that to work.
Let's not *plan* to repeat the mistake that is the 80x86 architecture!
(what odds would I have got 20 years ago that the most popular cpu
would run at 3GHz with only eight registers, and that only one of
those could be used for certain opcodes, and that values cannot be
transferred between the alu and the fpu except via memory, etc?)
>We'll have to see
>how many people want to make alternate front-ends or back-ends.
"Want to"? alot, judging by past posts. "Will actually" is the
question 
>In lieu of documentation, people could just examine my source.
>In particular, they could use a back-end written in Euphoria
>(if I get around to it) as a model of how the 160 or so
>IL op codes are supposed to work.
That would be a reasonable compromise. The question is, would that
make the IR specification strictly copyrighted, which I feel would be
counter-productive in the long term?
Pete
12. Re: Requests for Eu 2.5
Pete Lomax wrote:
>>In lieu of documentation, people could just examine my source.
>>In particular, they could use a back-end written in Euphoria
>>(if I get around to it) as a model of how the 160 or so
>>IL op codes are supposed to work.
>
> That would be a reasonable compromise. The question is, would that
> make the IR specification strictly copyrighted, which I feel would be
> counter-productive in the long term?
I don't understand the concept of copyrighting a
specification such as an IL, however, as now, people who buy
the source would not be able to redistribute it
in source form, only as executable code.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: Requests for Eu 2.5
Rob wrote:
> Juergen Luethje wrote:
>> In the current version of the translator, there is still that glitch
>> concerning abort(). When the argument to abort() is not 0, translated
>> programs are not compatible with interpreted programs. When the
>> following program:
>> puts(1, "Hello!")
>> abort(1)
>> is interpreted, it terminates immediately, as expected.
>>
>> When translated and compiled, a console window pops up, showing a
>> blank line, and "Press Enter..." on the next line, waiting for the
>> user pressing [Enter], before it closes the window.
>
> That's on my list.
> It's trivial to fix.
Thanks!
>> Sorry, but your words make me curious:
>> Will the new Euphoria version probably be released this year?
>
> Yes.
> I don't like to wait much more than a year between releases.
Very nice!
Regards,
Juergen
--
/"\ ASCII ribbon campain | This message has been ROT-13 encrypted
\ / against HTML in | twice for higher security.
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
