1. Upcoming releases
- Posted by Robert Craig <robert_craig at COMPUSERVE.COM>
Jun 09, 1997
-
Last edited Jun 10, 1997
Later this week we're going to release a minor
update to version 1.5. Version 1.5a will contain
a bunch of performance improvements, a couple
of bug fixes, and some improvements to the documentation.
It will mainly be helpful to game developers and
others who are "pushing the performance envelope".
I'll post a message when it is ready.
Registered users of v1.5 can upgrade for free.
Send us e-mail in a few days to get the download instructions.
Once 1.5a is out, I will focus on the WIN32 version, =
which admittedly has slipped a bit from earlier estimates.
You'll probably see an alpha WIN32 version in =
2 to 4 months (I want to get outdoors occasionally
and enjoy the short Canadian summer!).
The alpha WIN32 version will be as I've described before:
- initially very primitive with little GUI support
- you can run as a Windows console application =
(in a text window)
- most text-mode programs written for the DOS
version will run without change
- pixel graphics modes will not be available in the =
alpha release
- you'll be able to call C routines in DLLs, passing them =
parameters
- your program will be a 32-bit Windows program,
not a 32-bit extended DOS program
For many people, the WIN32 version will not initially
be that useful. I'm hoping that 3rd party developers
who know about Windows programming, and have C/C++ compilers,
will help us to develop components (.DLLs and .e files) =
that will be easy for other Euphoria people to use. =
I'll soon add a page on the Web site to keep you up-to-date
on what we're doing with WIN32.
We are certainly *not* abandoning the DOS version. We are
just adding a new platform for Euphoria. Most of the source
code is shared between the two versions. We hope that
the Windows version will evolve into something that makes
Windows programming a lot easier than it is now.
Regards,
Rob Craig
Rapid Deployment Software
2. Re: Upcoming releases
Robert Craig wrote:
> Later this week we're going to release a minor
> update to version 1.5. Version 1.5a will contain
> a bunch of performance improvements, a couple
> of bug fixes, and some improvements to the documentation.
Can you specify them? I guess it includes the concatenation "&".
> The alpha WIN32 version will be as I've described before:
>
> - initially very primitive with little GUI support
> - you can run as a Windows console application =
> (in a text window)
I still don't get this... I'm using Win95 with Euphoria 1.5 in a
text console... wich is the difference??? For me a windows application
is basically a GUI stuff. Even worst, windows is slower than DOS...
why do the same thing in a slower interpreter?
When is comming a Linux version (cool)???
--
Regards,
Daniel Berstein
architek at geocities.com
http://www.geocities.com/SiliconValley/Heights/9316
3. Re: Upcoming releases
: 2 to 4 months (I want to get outdoors occasionally
: and enjoy the short Canadian summer!).
:
Ever hear of a lap top computer(BG) I have fooled around with a program
lang called liberty basic and it is slow in windows I ran bench mark test
with it and Euphoria won hands down.Besides why can't dos do just as good
as windows?
David Mosley
ampenter at sisna.com
4. Re: Upcoming releases
Daniel Berstein wrote:
>
> Robert Craig wrote:
> > The alpha WIN32 version will be as I've described before:
> >
> > - initially very primitive with little GUI support
> > - you can run as a Windows console application =
> > (in a text window)
>
> I still don't get this... I'm using Win95 with Euphoria 1.5 in a
> text console... wich is the difference??? For me a windows application
> is basically a GUI stuff. Even worst, windows is slower than DOS...
> why do the same thing in a slower interpreter?
>
> When is comming a Linux version (cool)???
>
> --
I think Daniel has a very good point, here. Euphoria is small, fast and weird,
anathema to Windoz users, but fits right in with the Linux crowd (these folks
seem to like doing everything themselves)
Why jump into an already over-crowded market when the time might be more
profitably be spent refining Euphoria for DOS (or perhaps making it Euphoria
INSTEAD OF dos - think about imbedding it on an eprom for dedicated controllers,
etc. May be good money in that!)
Anyway, if you just can't live without neat windows, the TEXT_GUI modules
already provide Win 3.1, Win 95 and Mac Copland graphics iinterfaces, faster
than windoz does That code does at least 90% of what we want, let's continue
refining it.
Hey, I know there are lots of windoz things Euphoria can't do - interprocess
communication, etc - but people who need and know how to use these things
already program in Delphi or C++. For a simple program , the kind most
people are going to write, TEXT_GUI looks and works just fine, and is really
simple.
Irv - my $0.02 worth
5. Re: Upcoming releases
- Posted by Ralf Nieuwenhuijsen <nieuwen at POP.XS4ALL.NL>
Jun 10, 1997
-
Last edited Jun 11, 1997
> Anyway, if you just can't live without neat windows, the TEXT_GUI modules
> already provide Win 3.1, Win 95 and Mac Copland graphics iinterfaces, faster
> than windoz does That code does at least 90% of what we want, let's continue
> refining it.
I always thought windows and dos program weren't different except
windows programs call dll and load some standard code which generates
a constant look-and-feel and saves a lot of update-trouble and
hd-space, the dll's are automatically updated with new versions of
programs, i can see the use of it...
But the only thing Euphoria needs is a couple of routines which call
dll's. If you use the standard windows dll to generate a window and
some basic gui, is your own choice. This gives us far more
flexibility then a text-console, which is a totally unnessasary
thing, and the effect can easily be done by an own Euphoria .E, we
don't need no slow dll for everything, but some stuff like printing &
soundcards and stuff can be a lot easier if we had the option to call
a dll (Windows or NOT).
I could be wrong... ..if so please tell me..
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
6. Re: Upcoming releases
Daniel Berstein writes:
> Can you specify them? I guess it includes the concatenation "&".
(please ignore the equals signs and 3D things that keep getting
inserted in my messages)
Version 1.5a:
* Many operations and library routines are now much faster. Performance
figures below are based on a 150 MHz Pentium machine running Windows 95=
and using a cheap S3 video card.
Thanks to Michael Bolin, get_key() is 100x faster when there is no key
in the buffer (the usual case).
Thanks to Michael Bolin, get_all_palette() is over 100x faster and this=
makes save_screen() much faster.
The following routines have now been built directly into ex.exe, to avo=
id
the overhead of calling machine_proc() or machine_func(). There is no l=
onger
a requirement to include graphics.e or machine.e to call: pixel(),
get_pixel(), mem_set() or mem_copy(). This makes calls to these routine=
s
much faster, especially when small numbers of bytes or pixels are invol=
ved.
For example, mem_copy() of 20 bytes or less is at least 2.5x faster and=
mem_set() of 20 bytes or less is at least 10x faster.
pixel() is much faster in all graphics modes, and is now extremely fast=
in
mode 19. pixel() is almost as fast as using poke() in mode 19, and pixe=
l()
will safely ignore any pixels that are written off-screen. mem_copy()
and mem_set() remain the fastest ways to write an image onto the mode 1=
9
screen, but you must already have the image stored in memory. Plotting =
a
single pixel is 70% faster in most modes, and 4.5x faster in mode 19.
Plotting a sequence of 10 pixels is 50% faster in most modes, and over
4x faster in mode 19 compared to version 1.5.
poke() of a long sequence into memory, other than video memory, is 50%
faster. poke() into video memory is not any faster.
get_pixel() is faster in all modes, especially where a single pixel
value is read.
display_image() is faster because pixel() is faster. A 10x10 image
can be displayed at least 30% to 40% faster in any graphics mode,
and over 4x faster in mode 19.
All arithmetic and bitwise operations applied to sequences of integers =
are
now faster. For example, adding a long sequence of integers to another =
long
sequence of integers is 29% faster.
a & b (concatenation) is 15% faster in most cases, and is dramatically
faster in the case where you grow a very long sequence by concatenating=
many small sequences onto it.
getc() is 12% faster.
match() is 8% faster in typical cases.
append()/prepend() are 15% faster in many cases.
find() of an integer within a sequence of integers is 64% faster.
formation of a 2-element sequence {a,b} is 11% faster
Internal copying of a shared sequence when it can no longer be shared i=
s
15% faster. Some other internal operations of the interpreter are also
somewhat faster.
* The following demo programs have been improved slightly:
mouse.ex, mydata.ex, eprint.ex, search.ex
* BUG FIXED: If a run-time error occurred at the top-level of a program, =
on a
line containing multiple statements, the ex.err traceback might fail.
* BUG FIXED: While tracing, the library routines call(), mem_copy() and
mem_set() might write to the trace screen, rather than writing to the
main output screen.
* The documentation for get_mouse() has been improved.
> I still don't get this... I'm using Win95 with Euphoria 1.5 in a
> text console... what's the difference???
You're right. For many existing programs there won't be a visible =
difference between using ex.exe and using the new win32 version =
of ex.exe. However the key thing is that you'll be able to call =
C routines in WIN32 DLLs. There are a few other minor advantages =
too, such as full support for long filenames, and 20% faster
floating-point calculations.
> When is coming a Linux version (cool)???
It's hard to say. I want to get the WIN32 alpha out before
looking more at Linux.
Regards,
Rob Craig
Rapid Deployment Software
7. Re: Upcoming releases
- Posted by Michael Packard <lgp at EXO.COM>
Jun 10, 1997
-
Last edited Jun 11, 1997
All I can say is "woo-hoo!"
Michael Packard
Lord Generic Productions
lgp at exo.com http://exo.com/~lgp
A Crash Course in Game Design and Production
http://exo.com/~lgp/euphoria
8. Re: Upcoming releases
> We are certainly *not* abandoning the DOS version. We are
> just adding a new platform for Euphoria. Most of the source
> code is shared between the two versions. We hope that
> the Windows version will evolve into something that makes
> Windows programming a lot easier than it is now.
I'm glad you are not abandoning the DOS version, as I do not want to ever
program under the Windows architecture. I've never been a fan of Windows
and am a DOS loyalist. I always felt if you want to design a program that
uses a graphics interface, then sit down and write the silly thing in the
first place.
David Gay
http://www.digital-liquid.com/abgte
"A Beginner's Guide To Euphoria"
9. Re: Upcoming releases
Terry McKenna wrote:
>
> Irv,
>
> I have noticed that you have made the reference to Euphoria as "weird", how
so?
>
No offense was intended - Rapid Deployment seems to have a genius or two
at work. Euphoria is _really different_ from most other programming
environments in lots of ways:
I started to elaborate on this, but have just deleted all I typed. I think it
would be better for me to post these ideas on my web page rather than
clutter the listserver. Drop by http://www.mindspring.com/~mountains
tomorrow and read.
> Another question I have is, is Euphoria really a good language to learn as a
first language? There isn't much documentation or support. Would I be better
off
>
Should you learn it as a first language? Depends upon what you intend to
do next. If you're learing just for fun or to write programs for yourself,
or games to sell, the by all means learn Euphoria.
If you'll be taking programming classes in college, might just as well bite
the bullet and learn C. They'll scoff at Euphoria. Of course, by the time you
finish college, employers will scoff at anyone who learned C! That's life.
If employment is your goal, read the want ads. You'll see lots of Delphi,
Oracle, C++, sometimes PowerBasic That's a hint.
Irv
10. Re: Upcoming releases
Ralf Nieuwenhuijsen wrote:
>
> I always thought windows and dos program weren't different except
> windows programs call dll and load some standard code which generates
> a constant look-and-feel and saves a lot of update-trouble and
> hd-space, the dll's are automatically updated with new versions of
> programs, i can see the use of it...
>
> I could be wrong... ..if so please tell me..
>
Actually, Ralf, windoz and DOS programs have very little in common. Windoz
programs are event-driven. Put simply, the user can do almost anything at
any time, and the program must respond appropriately.
DOS programs are, in effect, the opposite. The programmer specifies what
he wants the user to do next, and the program waits patiently for the user to
respond properly.
Windoz programs are event-driven and rely on message passing to coordinate
between the operating system, the program(s) currently running, and the user.
There are several hundred different messages that windoz itself may send,
unannounced. Your program must either respond to these, or pass them on to
some underlying code which can handle them.
In addition, your program must generate its own messages to send to windoz,
or to other programs, or to other parts of itself.
The entire "architecture" is different.
That's why a windoz "HELLO,WORLD" program can take 50 or 100 lines of code,
and maybe 200,000 - 300,000 more bytes for the exe file!
Irv
11. Re: Upcoming releases
- Posted by Ralf Nieuwenhuijsen <nieuwen at POP.XS4ALL.NL>
Jun 11, 1997
-
Last edited Jun 12, 1997
Wow, it's gonna be lightning-fast...
-=-=-=-=-=-=-= Before read past here, know that is gonna be long...
-=-=-=-=-=-=-= It's about possible new improvements to Euphoria..
-=-=-=-=-=-=-= If you don't care or don't want to read long messages
-=-=-=-=-=-=-= PLEASE DONT READ IT!!!
-=-=-=-=-=-=-= (Is this the way, to solve my long message tick?)
About the interpreter () routine, can't you just make an include
statement inserted like this:
if [some condiftion] then
include [somefile].e
else
include [otherfile].e
end if
It would end all trouble, best is to have a include routine which
you can give a code-sequence containing the code.
An other suggestion is atoms with a unlimited number of bits...
So you can have quicker acces to a big package of data cause it
doesn't need the flexible sequence structure. It saves time and
memory and you can then add a lot of nifty tricks...
Like getting some value of each 8 bits and then of each 16 bits with
no converting time at all!!!
Or make a table that simply resizes it's dimensions with almost no
cpu!!
And the NULL value, whenever some routine (intern or not) is called
with a NULL as a argument, it is ignored...
Then when you poke for example, the pixels with the NULL value would
not be poked, this could make it all a lot easier....
Also have some more preprocces commands, like enums and partners
(different var-name, same memory addres) and select case (like in
qbasic) and many others...
Look at the preproccesor of David Cunny, it genuis, at least include
'with each .. in ... do' constructs, they are great!!
Having more clearly code will have a great impact on Euphoria..
Like i said, OOP could easily be done by a preproccesor, why not
make Euphoria more OOP, so you can have clones of .E and collections
(sequences with search 'keys')
Maybe a very quick inline compiled when loaded machine independent
but very low-low-close to the system- language can be included.
Perhaps a routine declared as 'system' or something.. ..it could
easily be possible and if the low-low code is then compiled for the
current machine, machine-specific code optimizations can be done
which can make Euphoria faster than any other language compared on
not typical default systems....
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
12. Re: Upcoming releases
Ralf Nieuwenhuijsen wrote:
<snip>
> Also have some more preprocces commands, like enums and partners
> (different var-name, same memory addres) and select case (like in
> qbasic) and many others...
> Look at the preproccesor of David Cunny, it genuis, at least include
> 'with each .. in ... do' constructs, they are great!!
> Having more clearly code will have a great impact on Euphoria..
>
Ralf has a very good point here - there are a couple of constructs that really
*do* increase the clarity of code. Case is almost mandatory. With each would
be really nice, too, especially since Euphoria does so much with sequences.
Hopefully, RDS does put clarity and simplicity top on their list of priorities.
Irv
