1. v2.5 Opens exw files wayyyy too slow
Hi there,
Im used to v2.4 which has no problem opening exw files within a fraction
of a second so that there is almost no delay at all when running exw
files. With v2.5, this doesnt seem to be the same at all. When a file
is opened even with a moderate number of include files there is a very
noticable delay -- on the order of 1.4 seconds or so -- which isnt very
good. I'll assume the exe bound files run faster, but that doesnt help.
If you call a few exw files from other run files you'll get mucho delay
added even to a relatively small program. This is definitely NOT as good
as 2.4 by any measure for working with multiple exw files.
Even opening a single exw file really bites however, and im surprised
to see this degradation from 2.4 to 2.5 .
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
2. Re: v2.5 Opens exw files wayyyy too slow
On Sun, 19 Dec 2004 18:54:33 -0800, Al Getz <guest at rapideuphoria.com> wrote:
> Im used to v2.4 which has no problem opening exw files within a fraction
> of a second so that there is almost no delay at all when running exw
> files. With v2.5, this doesnt seem to be the same at all. When a file
> is opened even with a moderate number of include files there is a very
> noticable delay -- on the order of 1.4 seconds or so -- which isnt very
> good.
I'm assuming you're using win32lib for all of these?
The sole reason for the slowdown is the fact that Eu2.5 parses all
35,000 lines of win32lib before it starts your program. Eu2.4 did this
on a more incremental basis.
> I'll assume the exe bound files run faster, but that doesnt help.
If you bind the program, it will not have to parse it, so this problem
is avoided.
--
MrTrick
3. Re: v2.5 Opens exw files wayyyy too slow
I posted this earlier:
Date: 2004 Nov 19 3:44
From: CoJaBo
Subject: Re: Eu 2.5 verryy sloww on Win XP ?
Robert Craig wrote:
>
> Gbadebo Oladosu wrote:
> > Yes, I found this to be the case on Win XP as well.
> > I tested 2.5 with a Windows program, and you could tell right away by
> > how long it took for the program window to come up compared to 2.4.
> >
> > 'Debo
> >
> > codepilot Gmail Account wrote:
> > >
> > > I have 2600+ AMD XP, win98 euphoria 2.5 alpha, and winwire also goes slow.
> > > Daniel
> > >
> > > On Thu, 18 Nov 2004 02:36:31 -0800, Andy Drummond
> > > <guest at rapideuphoria.com> wrote:
> > > >
> > > > posted by: Andy Drummond <andy at kestreltele.com>
> > > >
> > > > I have downloaded the alpha Eu 2.5, and it seems odd.
> > > > On my home PC - Pentium 3 500MHz Win 98SE - it runs fast as you like.
> > > > On my work PC - Pentium 4 2.8GHz Win XP & SP2 - it runs about 1-2%
> > > > of the speed of Eu 2.4. I installed it clean (renamed previous Euphoria
> > > > directory) and tried WinWire demo program - you can follow the letter E
> > > > quite easily, whereas at home it is all a blur and hard to see at all.
> > > > I tried Judith's IDE (I have a bound version which is reliable) and it
> > > > took over a minute just for the splash screen to appear.
> > > >
> > > > So - does anyone have any suggestions? it sounds decidedly weird to me.
>
> winwire looks pretty fast to me. 2.5 alpha, XP, Pentium 4 1.8 GHz.
Using a Athlon 64 2.8Ghz with 2GB RAM NVIDIA GeForce4 440
Go 64MB Gfx card, Win XP.
2.4: looks like a spinning E
2.5A: looks like colored static(that's quite fast!)
>
> Judith's IDE is a special case.
Time till splash screen:
2.4: less than 1 second
2.5a: 3 seconds
Time till completely started:
2.4: about 10 seconds
2.5a: about 5 seconds
CJBN Webserver start time:
2.4: 7 seconds (4 till splash)
2.5a: 2 seconds (2 till splash)
The Win32Dib demos(fps):
2.4: 20-800
2.5a: 100-1000
2.5 alpha seems to start the program slower,
but overall it runs much faster.
I care more about program speed than startup
time.
> It has code at the very beginning of the source
> to display a splash screen. Under 2.4 this splash
> screen appears almost immediately, then you wait for parsing
> to complete. That's because 2.4 will execute code before it
> has finished parsing the program. 2.5 parses the *whole* program before
> executing anything. Including Win32Lib etc., the IDE is
> 100,000 lines of Euphoria code. That's a lot
> of parsing to do, and 2.5 has a Euphoria-coded parser.
> 2.4 has a C-coded parser. So you might consider
> the IDE to be the "worst-case" example. It's the biggest
> Euphoria program I know of.
> If you bind the IDE using 2.5, or translate/compile it,
> it will start up much faster, because no parsing need be done.
> (Bound programs under 2.4 must be parsed).
> Other very large (tens of thousands of lines) programs may also
> appear to start up a tad slower using the 2.5 interpreter,
> but we're only talking about a second or two (unless you have an ancient
> machine). I think with the vast majority of programs,
> you'd hardly notice any difference. As computers get faster,
> this small difference will get even smaller.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
4. Re: v2.5 Opens exw files wayyyy too slow
On Sun, 19 Dec 2004 18:54:33 -0800, Al Getz <guest at RapidEuphoria.com>
wrote:
>noticable delay -- on the order of 1.4 seconds or so --
Rob mentioned some improvements made since 2.5a was released,
suggesting that figure might drop to 0.48 for the beta. We'll have to
wait and see.
Pete
5. Re: v2.5 Opens exw files wayyyy too slow
- Posted by don cole <doncole at pacbell.net>
Dec 20, 2004
-
Last edited Dec 21, 2004
Since parsing win32lib.ew seems to be causing the slowness,
couldn't Euphoria be designed to do that just once ,say when you open your
editor.
Although one changes his or her program many times while test it
with the editor, rarely would you change any thing within win32lib itself.
Just a thought.
don cole
SF
6. Re: v2.5 Opens exw files wayyyy too slow
- Posted by Patrick Barnes <mrtrick at gmail.com>
Dec 20, 2004
-
Last edited Dec 21, 2004
Yes, perhaps something similar to C's .o files would be good.
That is, large libraries can be made in an intermediate IL-like form,
so that it's *much* quicker to load them into the program.
When you run a program with the interpreter the first time, it
generates .o files for each library you include, and starts the
program. The next time it's run, it sees that the .o files already
exist (and they're up-to-date) so it just reads in the .o files and
runs.
It'd certainly make things a lot quicker. I know it doesn't sound as
simple, but the extra step wouldn't affect programmers adversely,
because the interpreter would do everything.
Think of it as 'caching'.
Rob, your thoughts?
On Mon, 20 Dec 2004 14:47:16 -0800, don cole <guest at rapideuphoria.com> wrote:
>
> posted by: don cole <doncole at pacbell.net>
>
> Since parsing win32lib.ew seems to be causing the slowness,
> couldn't Euphoria be designed to do that just once ,say when you open your
> editor.
> Although one changes his or her program many times while test it
> with the editor, rarely would you change any thing within win32lib itself.
>
> Just a thought.
> don cole
> SF
>
>
>
>
--
MrTrick
7. Re: v2.5 Opens exw files wayyyy too slow
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Dec 20, 2004
-
Last edited Dec 21, 2004
On Tue, 21 Dec 2004 10:09:52 +1100, Patrick Barnes <mrtrick at gmail.com>
wrote:
>That is, large libraries can be made in an intermediate IL-like form,
>so that it's *much* quicker to load them into the program.
For some previous thoughts on this matter please read:
http://palacebuilders.pwp.blueyonder.co.uk/ilsave.htm
Any comments, suggestions, or other welcome.
I'd like to see someone attempt this in eu.ex, as I believe that is
the best chance of this appearing in 2.6 (due in summer 2006);
sadly the probability of this happening in 2.5 is 0.01% or less.
Regards,
Pete
PS the "parent" page for the above is
http://palacebuilders.pwp.blueyonder.co.uk/pdeuex.htm
8. Re: v2.5 Opens exw files wayyyy too slow
Patrick Barnes wrote:
>
> Yes, perhaps something similar to C's .o files would be good.
> That is, large libraries can be made in an intermediate IL-like form,
> so that it's *much* quicker to load them into the program.
> When you run a program with the interpreter the first time, it
> generates .o files for each library you include, and starts the
> program. The next time it's run, it sees that the .o files already
> exist (and they're up-to-date) so it just reads in the .o files and
> runs.
>
> It'd certainly make things a lot quicker. I know it doesn't sound as
> simple, but the extra step wouldn't affect programmers adversely,
> because the interpreter would do everything.
>
> Think of it as 'caching'.
I'm not going to make things more complicated.
1. If you have a decent machine (less than 3 years old),
you can probably parse 100,000 lines in 3 seconds.
99% of programs are much smaller than that.
Maybe your scheme would cut that to 1 second.
Judith's IDE, for example, then takes 3 more seconds
executing code to initialize itself (nothing to do with parsing).
2. 2.5 beta parses significantly faster than 2.5 alpha in all cases.
It's dramatically faster on old machines with small memories
(64 MB or less) when very large programs are parsed.
3. Old, slow machines are disappearing every day, being replaced
by > 2GHz machines. Already, most people have little concern about
parse speed. In a couple of years no one will care about this.
Why build a major new mechanism that has little use now, and
will be completely useless in a couple of years?
It will be one more thing to confuse beginners.
4. If you translate, your app will start with zero parse time.
If you bind, your app will also now start with zero parse time (in 2.5).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: v2.5 Opens exw files wayyyy too slow
On Mon, 20 Dec 2004 16:26:49 -0800, Robert Craig
<guest at rapideuphoria.com> wrote:
> I'm not going to make things more complicated.
>
> 1. If you have a decent machine (less than 3 years old),
> you can probably parse 100,000 lines in 3 seconds.
> 99% of programs are much smaller than that.
> Maybe your scheme would cut that to 1 second.
> Judith's IDE, for example, then takes 3 more seconds
> executing code to initialize itself (nothing to do with parsing).
Well, many people don't *have* decent machines, and can't afford to
upgrade them. Otherwise, yes, it's a largely valid point.
> 2. 2.5 beta parses significantly faster than 2.5 alpha in all cases.
> It's dramatically faster on old machines with small memories
> (64 MB or less) when very large programs are parsed.
That is very good to hear. Any ideas as to when it will be released?
(Heh sorry, no pressure)
> 3. Old, slow machines are disappearing every day, being replaced
> by > 2GHz machines. Already, most people have little concern about
> parse speed. In a couple of years no one will care about this.
> Why build a major new mechanism that has little use now, and
> will be completely useless in a couple of years?
> It will be one more thing to confuse beginners.
Hey, what about my 286 in the closet!
Yes, it may become less useful over time, but remember that the way
CPU technology is going, we're not going to get much faster
clock-speeds. It's more likely going to be multi-cored, which I don't
think would help parse time much. Speaking of major new mechanisms,
how about multi-threaded execution?
> 4. If you translate, your app will start with zero parse time.
> If you bind, your app will also now start with zero parse time (in 2.5).
That's against one of the major selling points of euphoria. Namely,
that it's Edit, Run, Edit, Run, Edit, Run. If it has to be
bound/compiled, it adds an extra step.
Thanks for your response.
Just one thing though... what about the large windows libraries, like
win32lib? You can't bind them, the new programmer needs to interpret
win32lib every time they run their little tiny windows app.
It would be nice to be able to turn libraries into semi-compiled
files, to make interpreting faster. Despite all of your explanations
above, I still believe this is important. Why?
Joe Newbie downloads Euphoria... realises that he needs win32lib to do
windows programming, downloads that too.
Now, if he has to wait several seconds for:
include win32lib.ew
winMain( create(Window, "Hello World",0,Default,Default,200,100,0), Normal)
to run, what's he going to think?
Without a doubt, he'll think: "This language is really slow!"
I think there should at least be a way to 'bind' or 'shroud' libraries
in such a way that a program can include them without the parser
having to interpret it every time. Do you think that's technically
feasible? I guess a header in the file containing lookups for each
global function and variable name would be enough. It could be only
available to registered users, that's fine...
--
MrTrick
10. Re: v2.5 Opens exw files wayyyy too slow
Robert Craig wrote:
> 2. 2.5 beta parses significantly faster than 2.5 alpha in all cases.
> It's dramatically faster on old machines with small memories
> (64 MB or less) when very large programs are parsed.
This is good -- speed is of course one of Euphoria's selling points.
> 3. Old, slow machines are disappearing every day, being replaced
> by > 2GHz machines. Already, most people have little concern about
> parse speed. In a couple of years no one will care about this.
> Why build a major new mechanism that has little use now, and
> will be completely useless in a couple of years?
> It will be one more thing to confuse beginners.
Well, I've got a 1.3 GHz laptop and a 1.8 GHz desktop that are both relatively
new. I don't plan on upgrading either one for the next 3-5 years...
> 4. If you translate, your app will start with zero parse time.
> If you bind, your app will also now start with zero parse time (in 2.5).
I think that this is one of the reasons for registering Euphoria. Several weeks
ago I didn't see any incentive to register since there is no longer a complete
edition.
On a related note, is the translator a separate product from the
binder/shrouder? If I register the translator, do I get the binder/shrouder as
well or do I have to register for that separately?
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
=====================================
Too many freaks, not enough circuses.
j.
11. Re: v2.5 Opens exw files wayyyy too slow
Hello again,
Thanks for all the input from everyone here in the forum.
I have to agree with some of the other posts, especially that one
of the 'selling' points of Euphoria is that you can create what
may be called "text file exe files" (text files that run as executables)
but with a long delay before they open this changes everything.
If the delay starts to get near the compile time for a C program
we dont gain anything there.
I couldnt live with 1.5 seconds to open an exw file, and i dont want
to put out some $500 USD just to open exw files fast so the only use
for v2.5 would be to bindw AFTER programs were written with v2.4 and
tested under v2.4 . This means i wouldnt be able to use the new
'$' or 'crash_routine()' because v2.4 doesnt recognize them,
which brings me to my next question about the cost to upgrade from
v2.4 to v2.5 .
I would have preferred to see two versions, one that sequenced
code as is, and one that sequenced code the old (2.4) way. It
would be nice to debug with the old way, then bind with the new way.
I could probably live with 0.25 seconds delay, 0.50 seconds would
be getting a bit too slow. With v2.4 almost every program i have
opens so fast you cant even notice it took longer than an exe file!
This includes programs that use COM too. I think the longest to-open
exw program i use frequently is a dictionary program, which does a lot
of loading before it can run. The opening speed approaches 0.5 seconds
under v2.4 .
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
12. Re: v2.5 Opens exw files wayyyy too slow
Robert Craig wrote:
> 3. Old, slow machines are disappearing every day, being replaced
> by > 2GHz machines. Already, most people have little concern about
> parse speed. In a couple of years no one will care about this.
> Why build a major new mechanism that has little use now, and
> will be completely useless in a couple of years?
> It will be one more thing to confuse beginners.
Rob is righter than rain. Every couple of years I like
to consider the advancements in computing power and "bang per buck":
1982 - entry level computer:
VIC-20 - $300.00
5k memory, 2Mhz 8-bit cpu
no operating system
no software
Floppy Disk Drive - $175.00
maybe 170kb
modem - 300baud $300.00
Hard Drive - 10MB $300.00
------------------------------------------------
$1,075.00
Remember, we're talking 1982 dollars here for
an 8bit cpu running @ 02Mhz. A 2000Ghz computer
would be x1000 faster. hmmm, but we're talking
about a 32 bit computer compared to an 8 bit.
So lets say its x4000 faster. And these two
factors are just a fraction of the cumulative
increase in power realized by our present day
entry level computer. I dare say that for
about 1/3 the relative cost of that 1982
personal computer I can now own a computer that
is at least 100,000 times as powerful.
2004 - entry level computer
emachine T2899 $499.00
* AMD Athlon™ XP processor 2800+* with QuantiSpeed™ architecture
and 333MHz frontside bus
512KB L2 cache memory for efficient system processing
160.0GB hard drive
NVIDIA GeForce4 MX graphics with 64MB DDR shared video memory;
nForce audio with 6-channel support
5 total high-speed USB 2.0 ports, including one in the
integrated 8-in-1 media manager; also supports CompactFlash,
SmartMedia, Secure Digital, MultiMediaCard, Memory Stick,
Memory Stick PRO and IBM Microdrive
Built-in 10/100 Ethernet LAN; V.92 high-speed data/fax modem
Standard multimedia keyboard and 2-button wheel mouse
Windows XP Home Edition operating system preinstalled;
software package included with Microsoft Media Player,
Power DVD, Nero 6.0 Suite and more
AMD, the AMD Arrow logo, AMD Athlon, QuantiSpeed, AMD
PowerNow! and combinations thereof are trademarks of
Advanced Micro Devices, Inc.
*This model number indicates relative software performance
among AMD processors.
Ken Rhodes
100% Microsoft Free!
13. Re: v2.5 Opens exw files wayyyy too slow
On 20 Dec 2004, at 18:13, Kenneth Rhodes wrote:
>
>
> posted by: Kenneth Rhodes <wolf_man_jacques at excite.com>
>
> Robert Craig wrote:
>
> > 3. Old, slow machines are disappearing every day, being replaced
> > by > 2GHz machines. Already, most people have little concern about
> > parse speed. In a couple of years no one will care about this.
> > Why build a major new mechanism that has little use now, and
> > will be completely useless in a couple of years?
> > It will be one more thing to confuse beginners.
>
> Rob is righter than rain. Every couple of years I like
> to consider the advancements in computing power and "bang per buck":
>
> 1982 - entry level computer:
> VIC-20 - $300.00
> 5k memory, 2Mhz 8-bit cpu
> no operating system
> no software
>
> Floppy Disk Drive - $175.00
> maybe 170kb
>
> modem - 300baud $300.00
>
> Hard Drive - 10MB $300.00
I priced a harddrive for a C64 in 1991, it was still $1000 for 2
megabytes.=
> ------------------------------------------------
> $1,075.00
>
> Remember, we're talking 1982 dollars here for
> an 8bit cpu running @ 02Mhz. A 2000Ghz computer
> would be x1000 faster. hmmm,=20
You want to correct that line? And where is this 2Thz computer?
> but we're talking
> about a 32 bit computer compared to an 8 bit.
> So lets say its x4000 faster. And these two
> factors are just a fraction of the cumulative
> increase in power realized by our present day
> entry level computer. I dare say that for
> about 1/3 the relative cost of that 1982
> personal computer I can now own a computer that
> is at least 100,000 times as powerful.
>
>
> 2004 - entry level computer
> emachine T2899 $499.00
>
> * AMD Athlon=99 XP processor 2800+* with QuantiSpeed=99 architecture
> and 333MHz frontside bus
>
> 512KB L2 cache memory for efficient system processing=20=09
>
>
> 160.0GB hard drive=20=09
>
>
> NVIDIA GeForce4 MX graphics with 64MB DDR shared video memory;
> nForce audio with 6-channel support=20=09
>
>
> 5 total high-speed USB 2.0 ports, including one in the
> integrated 8-in-1 media manager; also supports CompactFlash,
> SmartMedia, Secure Digital, MultiMediaCard, Memory Stick,
> Memory Stick PRO and IBM Microdrive=20=09
>
>
> Built-in 10/100 Ethernet LAN; V.92 high-speed data/fax modem=20=09
>
>
> Standard multimedia keyboard and 2-button wheel mouse=20=09
>
>
> Windows XP Home Edition operating system preinstalled;
> software package included with Microsoft Media Player,
> Power DVD, Nero 6.0 Suite and more=20=09
>
>
> AMD, the AMD Arrow logo, AMD Athlon, QuantiSpeed, AMD
> PowerNow! and combinations thereof are trademarks of=20
> Advanced Micro Devices, Inc.
>
> *This model number indicates relative software performance
> among AMD processors.=20=09
It makes me laugh at how out of touch some people are. I have lost my
home and property, am bankrupt, because of a dog. Anywhere i go, there's=
going to be a dog, and the more affordable a place is, the worse the
dogs. =
I'll=20
likely be dead or living in my car after tomorrow noon, so count me among=
those who won't be upgrading their computer to run winXP or the latest Eu.
Kat
http://TiggrBox.Info
14. Re: v2.5 Opens exw files wayyyy too slow
Kenneth Rhodes wrote:
>
> Robert Craig wrote:
>
> > 3. Old, slow machines are disappearing every day, being replaced
> > by > 2GHz machines. Already, most people have little concern about
> > parse speed. In a couple of years no one will care about this.
> > Why build a major new mechanism that has little use now, and
> > will be completely useless in a couple of years?
> > It will be one more thing to confuse beginners.
>
> Rob is righter than rain. Every couple of years I like
> to consider the advancements in computing power and "bang per buck":
>
> 1982 - entry level computer:
> VIC-20 - $300.00
> 5k memory, 2Mhz 8-bit cpu
> no operating system
> no software
>
> Floppy Disk Drive - $175.00
> maybe 170kb
>
> modem - 300baud $300.00
>
> Hard Drive - 10MB $300.00
> ------------------------------------------------
> $1,075.00
Now that is OLD! The oldest computer I have is
an early Pentium with 14MB RAM(it used 2 8MB
SIMMs, but only used 14MB). It had a "massive"
1GB hard drive and "high speed" 2X SCSI CD-ROM
drive! The oldest WORKING computer I have is
an early Pentium III, 256MB RAM
12.6GB HDD(131GB used... acording to Windows!).
The oldest computer I once had was an Apple I.
Look on Ebay or a place selling old computers
for a slightly outdated computer,
I've seen them sell for $100!
>
> Remember, we're talking 1982 dollars here for
> an 8bit cpu running @ 02Mhz. A 2000Ghz computer
> would be x1000 faster. hmmm, but we're talking
> about a 32 bit computer compared to an 8 bit.
> So lets say its x4000 faster. And these two
> factors are just a fraction of the cumulative
> increase in power realized by our present day
> entry level computer. I dare say that for
> about 1/3 the relative cost of that 1982
> personal computer I can now own a computer that
> is at least 100,000 times as powerful.
>
>
> 2004 - entry level computer
> emachine T2899 $499.00
>
> * AMD Athlon™ XP processor 2800+* with QuantiSpeed™ architecture
> and 333MHz frontside bus
>
> 512KB L2 cache memory for efficient system processing
>
>
> 160.0GB hard drive
>
>
> NVIDIA GeForce4 MX graphics with 64MB DDR shared video memory;
> nForce audio with 6-channel support
>
>
> 5 total high-speed USB 2.0 ports, including one in the
> integrated 8-in-1 media manager; also supports CompactFlash,
> SmartMedia, Secure Digital, MultiMediaCard, Memory Stick,
> Memory Stick PRO and IBM Microdrive
>
>
> Built-in 10/100 Ethernet LAN; V.92 high-speed data/fax modem
>
>
> Standard multimedia keyboard and 2-button wheel mouse
>
>
> Windows XP Home Edition operating system preinstalled;
> software package included with Microsoft Media Player,
> Power DVD, Nero 6.0 Suite and more
>
>
> AMD, the AMD Arrow logo, AMD Athlon, QuantiSpeed, AMD
> PowerNow! and combinations thereof are trademarks of
> Advanced Micro Devices, Inc.
>
> *This model number indicates relative software performance
> among AMD processors.
>
>
>
> Ken Rhodes
> 100% Microsoft Free!
>
15. Re: v2.5 Opens exw files wayyyy too slow
CoJaBos_temp_account wrote:
<snip>
> Now that is OLD! The oldest computer I have is
> an early Pentium with 14MB RAM(it used 2 8MB
> SIMMs, but only used 14MB). It had a "massive"
> 1GB hard drive and "high speed" 2X SCSI CD-ROM
> drive! The oldest WORKING computer I have is
> an early Pentium III, 256MB RAM
> 12.6GB HDD(131GB used... acording to Windows!).
> The oldest computer I once had was an Apple I.
>
> Look on Ebay or a place selling old computers
> for a slightly outdated computer,
> I've seen them sell for $100!
I actually have a working Apple ][+ with two floppy drives and monitor. I broke
one of the paddles, though. My parents have my old Amiga 500 that I plan on
getting back one of these days. I have unfortunately scrapped an old Quadra 800,
Amiga 3000, and a Power Computing Mac clone.
I also have an Atari 2600 that works, and an NES.
I love old equipment...
I still have my first PC compatable which is a Pentium 166, but I don't know
what kind of working order it is in. It is just stored in the garage with the
rest of the junk.
=====================================
Too many freaks, not enough circuses.
j.
16. Re: v2.5 Opens exw files wayyyy too slow
Robert Craig wrote:
>
> 3. Old, slow machines are disappearing every day, being replaced
> by > 2GHz machines. Already, most people have little concern about
> parse speed. In a couple of years no one will care about this.
> Why build a major new mechanism that has little use now, and
> will be completely useless in a couple of years?
> It will be one more thing to confuse beginners.
>
Are you saying that with faster and faster machines coming out in the future
speed of program execution will now longer be of concern to programers?
Don Cole
Sf
17. Re: v2.5 Opens exw files wayyyy too slow
don cole wrote:
> Are you saying that with faster and faster machines coming out in the future
> speed of program execution will now longer be of concern to programers?
No, I'm saying that the initial *parsing speed* will
be less important in the future, since machine speeds
will increase faster than programmers can write bigger programs.
*Execution speed*, which is slightly faster with 2.5 than 2.4,
will always be important. Programmers have craved faster execution
speed for as long as computers have existed. There are always
new applications coming along that can benefit from more speed.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
18. Re: v2.5 Opens exw files wayyyy too slow
Anyone wanna buy a 25MB hard drive that weighs 8 lbs and takes up two
5 1/4" bays? 
~Greg
On Mon, 20 Dec 2004 19:19:09 -0800, Jason Gade <guest at rapideuphoria.com>
wrote:
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> CoJaBos_temp_account wrote:
> <snip>
>
> > Now that is OLD! The oldest computer I have is
> > an early Pentium with 14MB RAM(it used 2 8MB
> > SIMMs, but only used 14MB). It had a "massive"
> > 1GB hard drive and "high speed" 2X SCSI CD-ROM
> > drive! The oldest WORKING computer I have is
> > an early Pentium III, 256MB RAM
> > 12.6GB HDD(131GB used... acording to Windows!).
> > The oldest computer I once had was an Apple I.
> >
> > Look on Ebay or a place selling old computers
> > for a slightly outdated computer,
> > I've seen them sell for $100!
>
> I actually have a working Apple ][+ with two floppy drives and monitor. I
> broke one of the paddles, though. My parents have my old Amiga 500 that I plan
> on getting back one of these days. I have unfortunately scrapped an old Quadra
> 800, Amiga 3000, and a Power Computing Mac clone.
>
> I also have an Atari 2600 that works, and an NES.
>
> I love old equipment...
>
> I still have my first PC compatable which is a Pentium 166, but I don't know
> what kind of working order it is in. It is just stored in the garage with the
> rest of the junk.
>
> =====================================
> Too many freaks, not enough circuses.
>
> j.
>
>
>
>
19. Re: v2.5 Opens exw files wayyyy too slow
Jason Gade wrote:
> On a related note, is the translator a separate product from the
> binder/shrouder?
> If I register the translator, do I get the binder/shrouder as well or do I
> have to
> register for that separately?
The three products: Binder, Translator, and Source, are all
independent of one another. You can buy any one, two or all three.
I should mention, you can build a fast interpreter using the Source
and the free version of the translator, but then you'll have
a message and delay at the start, so it might be a good idea
to get the registered version of the Translator as well,
unless you are just getting the Source for educational purposes
or something.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
20. Re: v2.5 Opens exw files wayyyy too slow
Patrick Barnes wrote:
> On Mon, 20 Dec 2004 16:26:49 -0800, Robert Craig wrote:
>> I'm not going to make things more complicated.
>>
>> 1. If you have a decent machine (less than 3 years old),
>> you can probably parse 100,000 lines in 3 seconds.
>> 99% of programs are much smaller than that.
>> Maybe your scheme would cut that to 1 second.
>> Judith's IDE, for example, then takes 3 more seconds
>> executing code to initialize itself (nothing to do with parsing).
>
> Well, many people don't *have* decent machines, and can't afford to
> upgrade them.
... or don't want to do so. Am I supposed to buy a new PC, just in order
to reduce the parsing time of the new Euphoria interpreter?
Some people keep writing, that a new PC only costs about 500 USD.
Then the upgrade from Eu 2.4 Complete Edition to the Eu 2.5 binder costs
for me 524 USD rather than 24 USD. Any further comments necessary?
> Otherwise, yes, it's a largely valid point.
>
>> 2. 2.5 beta parses significantly faster than 2.5 alpha in all cases.
>> It's dramatically faster on old machines with small memories
>> (64 MB or less) when very large programs are parsed.
I hope 2.5 beta will run dramatically faster also on other old machines.
My PC contains a Pentiom II prozessor, 400 MHz. Although it's got
*256 MB* RAM, promgrams that e.g. include Win32Lib are parsed unbearable
slow by Eu 2.5 alpha. I'll have to wait and see, what "dramatically
faster" actually means, too.
> That is very good to hear. Any ideas as to when it will be released?
> (Heh sorry, no pressure)
>
>> 3. Old, slow machines are disappearing every day, being replaced
>> by > 2GHz machines. Already, most people have little concern about
>> parse speed.
"most people"? How much percent? Where do that statistical data come from?
>> In a couple of years no one will care about this.
Then it will be the best, to use Eu 2.5 not now, but "in a couple of
years"?
>> Why build a major new mechanism that has little use now, and
>> will be completely useless in a couple of years?
>> It will be one more thing to confuse beginners.
>
> Hey, what about my 286 in the closet!
> Yes, it may become less useful over time, but remember that the way
> CPU technology is going, we're not going to get much faster
> clock-speeds. It's more likely going to be multi-cored, which I don't
> think would help parse time much. Speaking of major new mechanisms,
> how about multi-threaded execution?
>
>> 4. If you translate, your app will start with zero parse time.
>> If you bind, your app will also now start with zero parse time (in 2.5).
>
> That's against one of the major selling points of euphoria. Namely,
> that it's Edit, Run, Edit, Run, Edit, Run. If it has to be
> bound/compiled, it adds an extra step.
Yes.
> Thanks for your response.
>
> Just one thing though... what about the large windows libraries, like
> win32lib? You can't bind them, the new programmer needs to interpret
> win32lib every time they run their little tiny windows app.
>
> It would be nice to be able to turn libraries into semi-compiled
> files, to make interpreting faster. Despite all of your explanations
> above, I still believe this is important. Why?
That's one of the the main points in this context. I wrote about it
already some weeks ago.
> Joe Newbie downloads Euphoria... realises that he needs win32lib to do
> windows programming, downloads that too.
> Now, if he has to wait several seconds for:
> }}}
<eucode>
> include win32lib.ew
> winMain( create(Window, "Hello World",0,Default,Default,200,100,0), Normal)
> </eucode>
{{{
> to run, what's he going to think?
> Without a doubt, he'll think: "This language is really slow!"
Yes, and he'll be completely right in this regard.
> I think there should at least be a way to 'bind' or 'shroud' libraries
> in such a way that a program can include them without the parser
> having to interpret it every time.
Eu 2.4 *has* this possibility. Paradoxically, it's not available in Eu
2.5 any more, while parsing time has considerably increased ...
> Do you think that's technically
> feasible? I guess a header in the file containing lookups for each
> global function and variable name would be enough. It could be only
> available to registered users, that's fine...
Regards,
Juergen
--
Have you read a good program lately?
21. Re: v2.5 Opens exw files wayyyy too slow
Pete Lomax wrote:
>
> On Tue, 21 Dec 2004 10:09:52 +1100, Patrick Barnes <mrtrick at gmail.com>
> wrote:
>
> >That is, large libraries can be made in an intermediate IL-like form,
> >so that it's *much* quicker to load them into the program.
>
> For some previous thoughts on this matter please read:
>
> <a
> href="http://palacebuilders.pwp.blueyonder.co.uk/ilsave.htm">http://palacebuilders.pwp.blueyonder.co.uk/ilsave.htm</a>
>
> Any comments, suggestions, or other welcome.
> I'd like to see someone attempt this in eu.ex, as I believe that is
> the best chance of this appearing in 2.6 (due in summer 2006);
> sadly the probability of this happening in 2.5 is 0.01% or less.
It's very possible to do this with ooeu, at least for one file. The
latest release does almost everything you'd need, except rebuild the
hash table (which is part of why the docs say that you can't shroud
with eval). I've got that working now. I think it could be possible
to merge multiple files in together, by storing all pointers to symtab
entries as sequences or something (to indicate that they need to be
fixed up). I'm not sure how easy it would be to keep everything as
modular as you mention on your page.
Matt Lewis
22. Re: v2.5 Opens exw files wayyyy too slow
>>>Now that is OLD! The oldest computer I have is
>>>an early Pentium with 14MB RAM(it used 2 8MB
>>>SIMMs, but only used 14MB). It had a "massive"
>>>1GB hard drive and "high speed" 2X SCSI CD-ROM
>>>drive! The oldest WORKING computer I have is
>>>an early Pentium III, 256MB RAM
>>>12.6GB HDD(131GB used... acording to Windows!).
>>>The oldest computer I once had was an Apple I.
>>>
>>>Look on Ebay or a place selling old computers
>>>for a slightly outdated computer,
>>>I've seen them sell for $100!
>>>
>>>
>>I actually have a working Apple ][+ with two floppy drives and monitor. I
>>broke one of the paddles, though. My parents have my old Amiga 500 that I plan
>>on getting back one of these days. I have unfortunately scrapped an old Quadra
>>800, Amiga 3000, and a Power Computing Mac clone.
>>
>>I also have an Atari 2600 that works, and an NES.
>>
>>I love old equipment...
>>
>>I still have my first PC compatable which is a Pentium 166, but I don't know
>>what kind of working order it is in. It is just stored in the garage with the
>>rest of the junk.
>>
>>=====================================
>>Too many freaks, not enough circuses.
>>
>>j.
>>
>>
My contribution to the old hardware still in possession ( and working! )
Is a Texas Instruments TI-99/4A with cassette adapter. And the not as
old C64 with FDD, Monitor, and Printer, and the classic SX64 which was a
heavy briefcase version of the C64(with builtin FDD & monitor) which was
hard to obtain when it was being sold so I'm assuming it's now worth
something. And my sister has my old Amiga 500, don't know if it even
works anymore with all the abuse she and her family give to machines.
And the old brick HDD's, I remember being so excited when a company
released a HDD for the C64, it was 10 MB if I recall correctly and it
was a box the size of a medium PC which was massive compared to the C64
itself. But the ability to store a hundred or so floppy's and access
them at lightning speed without a fastloader was amazing back then!
23. Re: v2.5 Opens exw files wayyyy too slow
Hello again,
I dont think processor speeds are increasing at the same rate as they
have been over say the last five years due to a number of factors,
therefore the assumtion that faster CPU's in the future will solve
the problem might not be valid...at least for any time we feel like
waiting for Also, the cost for upgrading becomes much more than
the cost of the Eu upgrade or even a full version price even if faster
works.
I'll ask a friend if i can do a few experiments with his 3.2GHz computer
as soon as possible. The spec's are: 3.2GHz, 512MB Ram, 600MHz FSB.
The system cost was over $1000.00 USD ... something most people arent
going to want to pay for unless they need the upgrade for another
reason too. 400 to 700MHz does an awful lot aside from Eu, but still wont
parse a moderate Eu library very quickly.
I run circuit analysis software pretty quickly at 650MHz (lots of circuit
elements) yet Eu parsing takes a long time.
I think there's got to be some solution other than forcing users
to go out and purchase new machines if they want to run exw files
most of the time...
I noticed that the source comes with the new PD v2.5, so i was wondering
if it would be possible to build a combination parser/executor from
the available code? This combination would ideally parse in blocks
and allow execution of the individual block before proceeding to the
next block. The user could have some syntax to force parsing of
sections of code that should be completely parsed before execution.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
24. Re: v2.5 Opens exw files wayyyy too slow
Robert Craig wrote:
>
> Jason Gade wrote:
> > On a related note, is the translator a separate product from the
> > binder/shrouder?
> > If I register the translator, do I get the binder/shrouder as well or do I
> > have to
> > register for that separately?
>
> The three products: Binder, Translator, and Source, are all
> independent of one another. You can buy any one, two or all three.
>
> I should mention, you can build a fast interpreter using the Source
> and the free version of the translator, but then you'll have
> a message and delay at the start, so it might be a good idea
> to get the registered version of the Translator as well,
> unless you are just getting the Source for educational purposes
> or something.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Okay, that makes sense. I'll have to think about registering the translator.
Thanks.
=====================================
Too many freaks, not enough circuses.
j.
25. Re: v2.5 Opens exw files wayyyy too slow
----- Original Message -----
From: "Robert Craig"
Sent: Tuesday, December 21, 2004 12:54 PM
Subject: RE: v2.5 Opens exw files wayyyy too slow
>
>
> posted by: Robert Craig <rds at RapidEuphoria.com>
>
> Chris Bensler wrote:
[SNIP]
>> What about my software customers? I should expect that every one of them
>> can afford a brand new computer every year because Euphoria is catering
>> only to the now?
>
> You have customers?
> Parse time is extremely important to you?
> Why not get the binder for $39, or in your case, upgrade for $24?
> Then your app will start up even *faster* than with 2.4.
Maybe I don't like the idea of compile time. Or in this case bind time.
That is an extra step I must take every time I modify the program.
Every time I add a feature.
I like the process of:
Edit -> Run,
Instead of:
Edit -> Bind -> Run
>> Most people don't have the slightest clue how to operate a computer,
>
> But you want them to run your app as a bunch of separate files?
> Why not bind into one .exe?
Maybe they only see the .ex or .exw the other files are in the path but
well out of view. Just like the multitude of DLL's, OCX's, VXD's and
such that Windows runs on.
>> The office I work at still has a 300mhz at it's front desk. And it's
>> more than sufficient.
>> Until last year, the office was serving 10 machines with a 400Mhz
>> gateway.
>> ...
>> You think we're all rich or something?
>
> You work in an office that has 10 machines, but you can't
> afford $24 for the Binder?
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Can't afford or find it pointless.
So I buy the binder so that I can now bind everytime I change a file
before I run it.
I prefer: Edit - Run
over: Edit - BIND - Run
unkmar
26. Re: v2.5 Opens exw files wayyyy too slow
----- Original Message -----
From: "Jason Gade"
Sent: Wednesday, December 22, 2004 1:09 PM
Subject: RE: v2.5 Opens exw files wayyyy too slow
>
> posted by: Jason Gade <jaygade at yahoo.com>
>
> Chris Bensler wrote:
>
>> 2 seconds is not even acceptible for a compiler anymore. How should it
>> be any more acceptible for an interpeter, which is supposed to excecute
>> my code immediately. That IS the main purpose of an interpeter isn't it?
>
> Almost any web browser or office suite takes longer than 2 seconds to start
> up.
>
A web browser or office suite is much more than a Win32 Euphoria "Hello World"
program that uses Win32lib.
unkmar
27. Re: v2.5 Opens exw files wayyyy too slow
Juergen Luethje wrote:
>
> Patrick Barnes wrote:
>
> > On Mon, 20 Dec 2004 16:26:49 -0800, Robert Craig wrote:
> >> I'm not going to make things more complicated.
> >>
> >> 1. If you have a decent machine (less than 3 years old),
> >> you can probably parse 100,000 lines in 3 seconds.
> >> 99% of programs are much smaller than that.
> >> Maybe your scheme would cut that to 1 second.
> >> Judith's IDE, for example, then takes 3 more seconds
> >> executing code to initialize itself (nothing to do with parsing).
> >
> > Well, many people don't *have* decent machines, and can't afford to
> > upgrade them.
>
> ... or don't want to do so. Am I supposed to buy a new PC, just in order
> to reduce the parsing time of the new Euphoria interpreter?
> Some people keep writing, that a new PC only costs about 500 USD.
You can find slightly outdated ones for less. Try ebay.
> Then the upgrade from Eu 2.4 Complete Edition to the Eu 2.5 binder costs
> for me 524 USD rather than 24 USD. Any further comments necessary?
>
> > Otherwise, yes, it's a largely valid point.
> >
> >> 2. 2.5 beta parses significantly faster than 2.5 alpha in all cases.
> >> It's dramatically faster on old machines with small memories
> >> (64 MB or less) when very large programs are parsed.
>
> I hope 2.5 beta will run dramatically faster also on other old machines.
> My PC contains a Pentiom II prozessor, 400 MHz. Although it's got
> *256 MB* RAM, promgrams that e.g. include Win32Lib are parsed unbearable
> slow by Eu 2.5 alpha. I'll have to wait and see, what "dramatically
> faster" actually means, too.
Remember that Eu 2.5 is still alpha, there is still time for improvement.
>
> > That is very good to hear. Any ideas as to when it will be released?
> > (Heh sorry, no pressure)
> >
> >> 3. Old, slow machines are disappearing every day, being replaced
> >> by > 2GHz machines. Already, most people have little concern about
> >> parse speed.
>
> "most people"? How much percent? Where do that statistical data come from?
>
> >> In a couple of years no one will care about this.
>
> Then it will be the best, to use Eu 2.5 not now, but "in a couple of
> years"?
>
> >> Why build a major new mechanism that has little use now, and
> >> will be completely useless in a couple of years?
> >> It will be one more thing to confuse beginners.
> >
> > Hey, what about my 286 in the closet!
> > Yes, it may become less useful over time, but remember that the way
> > CPU technology is going, we're not going to get much faster
> > clock-speeds. It's more likely going to be multi-cored, which I don't
> > think would help parse time much. Speaking of major new mechanisms,
> > how about multi-threaded execution?
> >
> >> 4. If you translate, your app will start with zero parse time.
> >> If you bind, your app will also now start with zero parse time (in 2.5).
> >
> > That's against one of the major selling points of euphoria. Namely,
> > that it's Edit, Run, Edit, Run, Edit, Run. If it has to be
> > bound/compiled, it adds an extra step.
>
> Yes.
>
> > Thanks for your response.
> >
> > Just one thing though... what about the large windows libraries, like
> > win32lib? You can't bind them, the new programmer needs to interpret
> > win32lib every time they run their little tiny windows app.
> >
> > It would be nice to be able to turn libraries into semi-compiled
> > files, to make interpreting faster. Despite all of your explanations
> > above, I still believe this is important. Why?
>
> That's one of the the main points in this context. I wrote about it
> already some weeks ago.
>
> > Joe Newbie downloads Euphoria... realises that he needs win32lib to do
> > windows programming, downloads that too.
> > Now, if he has to wait several seconds for:
> > }}}
<eucode>
> > include win32lib.ew
> > winMain( create(Window, "Hello World",0,Default,Default,200,100,0), Normal)
> > </eucode>
{{{
> > to run, what's he going to think?
> > Without a doubt, he'll think: "This language is really slow!"
>
> Yes, and he'll be completely right in this regard.
>
> > I think there should at least be a way to 'bind' or 'shroud' libraries
> > in such a way that a program can include them without the parser
> > having to interpret it every time.
>
> Eu 2.4 *has* this possibility. Paradoxically, it's not available in Eu
> 2.5 any more, while parsing time has considerably increased ...
>
> > Do you think that's technically
> > feasible? I guess a header in the file containing lookups for each
> > global function and variable name would be enough. It could be only
> > available to registered users, that's fine...
>
> Regards,
> Juergen
>
> --
> Have you read a good program lately?
>
>
28. Re: v2.5 Opens exw files wayyyy too slow
- Posted by "Juergen Luethje" <j.lue at gmx.de>
Dec 23, 2004
-
Last edited Dec 24, 2004
CoJaBos_temp_account wrote:
> Juergen Luethje wrote:
>>
>> Patrick Barnes wrote:
>>
>>> On Mon, 20 Dec 2004 16:26:49 -0800, Robert Craig wrote:
>>>> I'm not going to make things more complicated.
>>>>
>>>> 1. If you have a decent machine (less than 3 years old),
>>>> you can probably parse 100,000 lines in 3 seconds.
>>>> 99% of programs are much smaller than that.
>>>> Maybe your scheme would cut that to 1 second.
>>>> Judith's IDE, for example, then takes 3 more seconds
>>>> executing code to initialize itself (nothing to do with parsing).
>>>
>>> Well, many people don't *have* decent machines, and can't afford to
>>> upgrade them.
>>
>> ... or don't want to do so. Am I supposed to buy a new PC, just in order
>> to reduce the parsing time of the new Euphoria interpreter?
>> Some people keep writing, that a new PC only costs about 500 USD.
>
> You can find slightly outdated ones for less. Try ebay.
Why should I do so?
>> Then the upgrade from Eu 2.4 Complete Edition to the Eu 2.5 binder costs
>> for me 524 USD rather than 24 USD. Any further comments necessary?
>>
>>> Otherwise, yes, it's a largely valid point.
>>>
>>>> 2. 2.5 beta parses significantly faster than 2.5 alpha in all cases.
>>>> It's dramatically faster on old machines with small memories
>>>> (64 MB or less) when very large programs are parsed.
>>
>> I hope 2.5 beta will run dramatically faster also on other old machines.
>> My PC contains a Pentiom II prozessor, 400 MHz. Although it's got
>> *256 MB* RAM, promgrams that e.g. include Win32Lib are parsed unbearable
>> slow by Eu 2.5 alpha. I'll have to wait and see, what "dramatically
>> faster" actually means, too.
>
> Remember that Eu 2.5 is still alpha, there is still time for improvement.
That's why I wrote "wait and see". Wait for the beta release.
Understandable?
[snipped old text]
Regards,
Juergen
--
We don't know where to GOTO if we don't know where we've COME FROM.
http://www.fortran.com/fortran/come_from.html
29. Re: v2.5 Opens exw files wayyyy too slow
> I like the process of:
> Edit -> Run,
> Instead of:
> Edit -> Bind -> Run
> So I buy the binder so that I can now bind everytime I change a file
> before I run it.
>
> I prefer: Edit - Run
> over: Edit - BIND - Run
Now I understand why Euphoria can be blamed for being a hobbyist
programming language. If the people who use it run the code
after every edit, then they really are hobbyists.
<flame>
In the old days when I had to learn programming, you had to write
long chunks of code, check that the logic and content were right,
and then get a reservation at the terminal room to punch in your
code. We were allowed a maximum of 30min per person per day there.
This was because there were only a half dozen paper terminals,
and we were some 300 students.
That was hardly the change-one-line-and-rerun method. But we
sure learned to program. Heck, we even had to think in advance!
Actually, to many of us now, sitting at the keyboard writing
code is not Programming. What we call Programming is when you
sit at your desk, drawing data structures or flowcharts or UML
on paper or chalkboard while doing Hard Thinking. Or Think
while driving or in the shower, or walking the dog.
Only when you've done this Programming, you walk to
the computer and punch in the code.
<double flame>
And any nontrivial task gets done sooner and better, and needs
less debugging than with the "try-and-retry" method.
I dare say, one never even becomes a good programmer unless
one separates thinking and typing.
</double flame>
Now, precisely because the target audience of Visual Basic is
the never-get-past-beginner kind of people, VB even checks your
syntax while writing.
</flame>
The speed of Euphoria is perfectly adequate. Period.
Those who call themselves non-hobbyist programmers have used
and are using compiled languages in addition to Euphoria.
Having got used to them removes the anxiety of a couple of
seconds' wait.
Try this for a change:
Run
-> Think -> Think -> Think -> Type
-> Think -> Think -> Think -> Type
-> Think -> Think -> Think -> Type
-> Run
Sure beats Edit -> Run -> Edit -> Run
30. Re: v2.5 Opens exw files wayyyy too slow
Georg Wrede wrote:
> Now I understand why Euphoria can be blamed for being a hobbyist
> programming language. If the people who use it run the code
> after every edit, then they really are hobbyists.
Obviously. To see how professionals like Georg do it, see:
http://databrook.com/users/irvm/photo.jpg
(completely family and work-safe)
Irv
31. Re: v2.5 Opens exw files wayyyy too slow
Hey, that's my computer! Hee hee.
Take care and have a happy holiday!
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
32. Re: v2.5 Opens exw files wayyyy too slow
Georg Wrede wrote:
>
> ETC.
Georg:
I have been using computers since 1955 !
Just a beginner.
You have forgotten that computers only had 4K 8K 16K of
memory and you were using programs that were only a few
hundred lines of code; not 400K of lines or even millions
of lines of code. Programs can no longer be built using
those old ideas. We would have to cut down all the trees
in the forest just for the paper print-outs if you had
a desk big enough to place them on.
You can't live in the past and use modern computers.
The old paper ways Sure don't beat Edit -> Run -> Edit -> Run
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
33. Re: v2.5 Opens exw files wayyyy too slow
Georg Wrede wrote:
>
> Now I understand why Euphoria can be blamed for being a hobbyist
> programming language. If the people who use it run the code
> after every edit, then they really are hobbyists.
>
<lol>
With all due respect Mr. Wrede, sir: you’re so full of s... you’re unsanitary.
<more_lol>
</lol>
</more_lol>
Regards and Seasons Greetings.
Marc
34. Re: v2.5 Opens exw files wayyyy too slow
- Posted by Georg Wrede <georg at iki.fi>
Dec 24, 2004
-
Last edited Dec 25, 2004
Various authors:
> To see how professionals like Georg do it, see:
> http://databrook.com/users/irvm/photo.jpg
Damn, I've been trying to download the picture, but it's
been continuously donw for the last 6 hours. :(
> We could all sleep in caves still too :P
> You can't live in the past and use modern computers.
> The old paper ways Sure don't beat Edit -> Run -> Edit -> Run
> With all due respect Mr. Wrede, sir: you’re so full of s...
> you’re unsanitary.
Thank you all for your attention. From your responses it seems
you belong to the lucky ones who are not terminally spoiled
by edit-run-edit-run style.
I see every week programmers (both young and old) who do it
that way, and some of them really do not get it when told that
programming is not the same as typing code. Ah, well, maybe
they'll learn later.
-----
Chris Bensler wrote:
> If Euphoria would return all parser errors at once, what you
> are saying might be more acceptible.
I wouldn't be surprised if that feature appeared in Euphoria.
But at the moment there may be more pressing things to do.
> However, interpeted programming is not quite the same as compiled
> programming. With compilers, you have extensive error reporting,
> and a heavy duty debugger, and a degree in computer science to be
> able to use them effectively.
Hmm. Since Euphoria is an interpreted language...
That you can compile Euphoria code doesn't change the fact that
it is primarily an interpreted language. So you are exactly right.
> You are right in that people should be planning before they code,
> but I don't know anybody that plans mistakes.
Yes, they _should_ plan before they code. Seen anybody do it?
Given an assignment everybody runs to the keyboard.
Once I visited a programming firm with a good
track record. They told me their "secret": since no programmer
wants to do planning, they decided to have them make prototypes.
But to avoid prototype code ending in the final product, they
decided to have them do the prototypes in another language. The
programmers could choose their language freely, as long as it was
not the Production language.
The improvement in code quality was more than they had hoped for.
Also, the total time for finalized projects was actually about
the same as before. (The most surprised were the programmers.)
> I should add:
> Why is it do you think that almost every compiler (actually every
> one I've ever seen) returns as many errors as it can, even if
> those errors are cascaded?
I agree with you. Who could do a major project in C++ with a
compiler that pukes at the first error?
> Also, why is that almost every compiler has a highly advanced
> debuggger?
Money. If Rob had money to hire a big staff, I'd bet we had
an industrial strength debugger, a compiler that not only finds
dozens of errors, but also would give state-of-the-art help and
advice on them. Maybe even correct some of the most obvious
mistakes?
> The answer is: so that you don't have to spend so much time in
> compilation. Granted nowadays with faster machines, compilation
> time is not as big of a concern anymore.
Some alternative ways to cut the time spent compiling in half:
1. Buy a machine twice as fast.
2. Have Rob jump somersaults and go through the needle, to
really make the compiler scream.
3. Learn to touch type, so you can keep your eyes on the screen,
so you catch your typos immediately.
4. Learn the (very small) grammar, and the most used idioms!
There exist few languages with less to learn than Euphoria.
5. Draw a picture of your own data structures! And hang it
above the monitor.
Oh, and do all five, and you spend 1/(2**5) time compiling.
Then you can stick a label on your cubicle: "I spend 96.9%
less time compiling."
-- Another Euphoric, since Nov. 18, 2004 --
