1. Upcoming releases
- Posted by Robert Craig <robert_craig at COMPUSERVE.COM> Jun 09, 1997
- 707 views
- 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
- Posted by Daniel Berstein <architek at GEOCITIES.COM> Jun 10, 1997
- 664 views
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
- Posted by Scott Stubberud <ampenter at SISNA.COM> Jun 10, 1997
- 702 views
: 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
- Posted by Irv <mountains at MINDSPRING.COM> Jun 10, 1997
- 687 views
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
- 676 views
- 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
- Posted by Robert Craig <robert_craig at COMPUSERVE.COM> Jun 11, 1997
- 686 views
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
- 652 views
- 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
- Posted by David Alan Gay <moggie at INTERLOG.COM> Jun 11, 1997
- 661 views
> 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
- Posted by Irv <mountains at MINDSPRING.COM> Jun 11, 1997
- 672 views
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
- Posted by Irv <mountains at MINDSPRING.COM> Jun 11, 1997
- 666 views
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
- 673 views
- 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
- Posted by Irv <mountains at MINDSPRING.COM> Jun 13, 1997
- 666 views
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