1. Tiny typo in Manual
- Posted by Alex Caracatsanis Jul 13, 2008
- 903 views
- Last edited Jul 14, 2008
If it weren't for the already excellent quality of the Manual, this would be too trivial to mention:
under the routine allow_break()
under heading parameters
"1 b, ........FALSE (0) to disable iy" should end with "... it"
Alex
2. Re: Tiny typo in Manual
- Posted by Shawn Pringle Jul 14, 2008
- 888 views
If it weren't for the already excellent quality of the Manual, this would be too trivial to mention:
under the routine allow_break()
under heading parameters
"1 b, ........FALSE (0) to disable iy" should end with "... it"
Alex
There are good number of spelling errors in the manual. There are also several false statements:
In ceil: When value is an atom, the returned value is an atom without a fractional part, the smallest one not less than value.
which is the definition floor and its a poorly explained correct definition seperated with a comma.
It should instead read: When value is an atom, the returned value is the smallest integer which is greater than or equal to value.
ceil(-0.5) = 0
There was also something about platform() being slower than using ifdef which we know isn't true.
3. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 14, 2008
- 890 views
There was also something about platform() being slower than using ifdef which we know isn't true.
Um, it is true. Here are two sample programs anyone can run:
test1.ex
include os.e integer c = 0 for a = 1 to 100000 do if platform() = LINUX then c = a * 2 end if end for ? c
test2.ex
integer c = 0 for a = 1 to 100000 do ifdef LINUX then c = a * 2 end ifdef end for ? c
Here are my results, but please run them and see if you find similar results. It's rather large.
jeremy@cowgar:~$ time exu test1.ex 200000 real 0m0.130s user 0m0.028s sys 0m0.004s jeremy@cowgar:~$ time exu test2.ex 200000 real 0m0.004s user 0m0.004s sys 0m0.000s
You should set the platform and ifdef call to your own platform.
Jeremy
4. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 14, 2008
- 879 views
There was also something about platform() being slower than using ifdef which we know isn't true.
Um, it is true. Here are two sample programs anyone can run:
test1.ex
include os.e integer c = 0 for a = 1 to 100000 do if platform() = LINUX then c = a * 2 end if end for ? c
test2.ex
integer c = 0 for a = 1 to 100000 do ifdef LINUX then c = a * 2 end ifdef end for ? c
Here are my results, but please run them and see if you find similar results. It's rather large.
jeremy@cowgar:~$ time exu test1.ex 200000 real 0m0.130s user 0m0.028s sys 0m0.004s jeremy@cowgar:~$ time exu test2.ex 200000 real 0m0.004s user 0m0.004s sys 0m0.000s
You should set the platform and ifdef call to your own platform.
I updated those two programs, I made the iteration be 100,000,000 and I included os.e in test2.e for parsing fairness (i.e. the first one had to parse it, so make the second parse it even though it's not directly needed by ifdef). Here are those results:
jeremy@cowgar:~$ time exu test1.e 200000000 real 0m1.016s user 0m0.924s sys 0m0.004s jeremy@cowgar:~$ time exu test2.e 200000000 real 0m0.693s user 0m0.688s sys 0m0.004s
Jeremy
5. Re: Tiny typo in Manual
- Posted by Shawn Pringle Jul 14, 2008
- 866 views
There was also something about platform() being slower than using ifdef which we know isn't true.
Um, it is true. Here are two sample programs anyone can run:
test1.ex
include os.e integer c = 0 for a = 1 to 100000 do if platform() = LINUX then c = a * 2 end if end for ? c
test2.ex
integer c = 0 for a = 1 to 100000 do ifdef LINUX then c = a * 2 end ifdef end for ? c
Here are my results, but please run them and see if you find similar results. It's rather large.
jeremy@cowgar:~$ time exu test1.ex 200000 real 0m0.130s user 0m0.028s sys 0m0.004s jeremy@cowgar:~$ time exu test2.ex 200000 real 0m0.004s user 0m0.004s sys 0m0.000s
You should set the platform and ifdef call to your own platform.
Jeremy
Ah, I stand corrected then.
Could you translate both to C and compile and repeat the experiment with binaries? I expect there to be no difference in that case, as well. Let's see though.
Shawn Pringle
6. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 14, 2008
- 900 views
Could you translate both to C and compile and repeat the experiment with binaries? I expect there to be no difference in that case, as well. Let's see though.
Shawn, was just doing that. As we suspected, no difference. I upped the iteration count quite a bit (to 300,000,000 3 times) and both test1 and test2 turned out to be 0.601s. (lowest of both in 3 runs each, same as my other test results).
Jeremy
7. Re: Tiny typo in Manual
- Posted by Unkmar Jul 14, 2008
- 930 views
<SNIP>
jeremy@cowgar:~$ time exu test1.e 200000000 real 0m1.016s user 0m0.924s sys 0m0.004s jeremy@cowgar:~$ time exu test2.e 200000000 real 0m0.693s user 0m0.688s sys 0m0.004s
Jeremy
I don't understand what (real, user, sys) represent. You only have one print statement in each program. Where would these values be coming from?
8. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 14, 2008
- 920 views
jeremy@cowgar:~$ time exu test1.e 200000000 real 0m1.016s user 0m0.924s sys 0m0.004s jeremy@cowgar:~$ time exu test2.e 200000000 real 0m0.693s user 0m0.688s sys 0m0.004s
I don't understand what (real, user, sys) represent. You only have one print statement in each program. Where would these values be coming from?
The actual command is prefixed with time which is standard on unix systems. time launches the program given to it on the command line and times it's execution and outputs the information above you see. This is important in doing benchmarks because it counts not just execution time, but load time and parse time. In the above test parse time was something that is important. If I were to do timing in the actual source code, then those timers would not start until all parsing was completed. Not to mention, time is so easy to use.
I do not think Windows has a similar command, does it? It would be nice for testing.
Jeremy
9. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 14, 2008
- 887 views
real 0m1.016s user 0m0.924s sys 0m0.004s
I don't understand what (real, user, sys) represent. You only have one print statement in each program. Where would these values be coming from?
On IRC, this was clarified:
[10:55] <utilimar> I understand that the program runs and that you time the run of the program. I don't understand what (real, user, sys) mean? [10:56] <utilimar> Which of those is/are important? [10:59] <iamlost> i can explain [10:59] <iamlost> sys is the amount of time spent in syscalls [11:00] <iamlost> user is the amout of time that the kenrel claims was spent in user code (i.e. teh actual code you write) [11:00] <iamlost> real is the time from when the program was started to the time when it was ended [11:00] <iamlost> in theory real = user + sys [11:01] <iamlost> you are better off paying attention to the real part [11:01] <iamlost> and igorning the other two
Jeremy
10. Re: Tiny typo in Manual
- Posted by Matt Lewis Jul 14, 2008
- 891 views
Could you translate both to C and compile and repeat the experiment with binaries? I expect there to be no difference in that case, as well. Let's see though.
Shawn, was just doing that. As we suspected, no difference. I upped the iteration count quite a bit (to 300,000,000 3 times) and both test1 and test2 turned out to be 0.601s. (lowest of both in 3 runs each, same as my other test results).
A lot of the code in the translator is dedicated to trying to figure out what values your code will take, and optimizing the C-code. This includes making assumptions about when it's safe to assume 31-bit integer values, as well as for variables that only ever have a single value.
The result of platform is evaluated at compile time, though any if statements in which the result is used are evaluated at run time, which explains the difference between ifdef, where everything happens at compile time. Further, the translator will omit code that it determines must be a dead branch, such as:
for a = 1 to 100000 do if platform() = LINUX then c = a * 2 elsif platform() = WIN32 then c = a * 3 end if end for
This code turns into:
// for a = 1 to 100000 do
{ int _1a;
_1a = 1;
L1:
if (_1a > 100000)
goto L2;
R1:
// if platform() = LINUX then
// elsif platform() = WIN32 then
// c = a * 3
_1c = _1a * 3;
L3:
L4:
// end for
L5:
_1a = _1a + 1;
goto L1;
L2:
;
}
...when translated (on windows).
11. Re: Tiny typo in Manual
- Posted by CChris Jul 15, 2008
- 876 views
jeremy@cowgar:~$ time exu test1.e 200000000 real 0m1.016s user 0m0.924s sys 0m0.004s jeremy@cowgar:~$ time exu test2.e 200000000 real 0m0.693s user 0m0.688s sys 0m0.004s
I don't understand what (real, user, sys) represent. You only have one print statement in each program. Where would these values be coming from?
The actual command is prefixed with time which is standard on unix systems. time launches the program given to it on the command line and times it's execution and outputs the information above you see. This is important in doing benchmarks because it counts not just execution time, but load time and parse time. In the above test parse time was something that is important. If I were to do timing in the actual source code, then those timers would not start until all parsing was completed. Not to mention, time is so easy to use.
I do not think Windows has a similar command, does it? It would be nice for testing.
Jeremy
It would be easy to add an immmediate_time() which would cause time() to be recorded right when it it parsed, an immediate_elapsed_time() to store the elapsed time at parse time, and an elapsed_tim() to fo the same at runtime.
So you'd say
immediate_time() some_code() ?immediate_elapsed_time() -- parse time ?elapsed_time() -- runtime
elapsed_time() would be a little tricky for bound/shrouded/trnslated cod, but still.
CChris
12. Re: Tiny typo in Manual
- Posted by Jim C. Brown Jul 15, 2008
- 924 views
It would be easy to add an immmediate_time() which would cause time() to be recorded right when it it parsed, an immediate_elapsed_time() to store the elapsed time at parse time, and an elapsed_tim() to fo the same at runtime.
This still doesn't allow benchmarks to include the time it takes to start up and initialize the interpreter (or translator).
These aren't really functions, if they are evaluated at parse time. They should be some kind of statement that can't be confused with a routine name.
Since, with the exception of developers of the interpreter itself (who can add the appropriate time() statements to parser.e and scanner.e directly), most people would not care how long it takes to parse, I'm not sure why this would be necessary? When benchmarking against another language, the benchmarker may just use the time command anyways (since few other langauges seem to support an immediate_time statement).
13. Re: Tiny typo in Manual
- Posted by CChris Jul 15, 2008
- 893 views
It would be easy to add an immmediate_time() which would cause time() to be recorded right when it it parsed, an immediate_elapsed_time() to store the elapsed time at parse time, and an elapsed_tim() to fo the same at runtime.
This still doesn't allow benchmarks to include the time it takes to start up and initialize the interpreter (or translator).
These aren't really functions, if they are evaluated at parse time. They should be some kind of statement that can't be confused with a routine name.
Since, with the exception of developers of the interpreter itself (who can add the appropriate time() statements to parser.e and scanner.e directly), most people would not care how long it takes to parse, I'm not sure why this would be necessary? When benchmarking against another language, the benchmarker may just use the time command anyways (since few other langauges seem to support an immediate_time statement).
immmediate_time() restarts the stopwatch, so it is a procedure. I say restarts because say common.e would start it, thus allowing to reckon parse time. The backend wuld start its own stopwatch in all cases.
immmediate_elapsed_time() is a function. The "immediate_" part clearly says that it is not a runtime thing. It may not be as useful, but its implementation cost is about nil.
elapsed_time() is a true function, which retrieves immediate_elapsed_time() if it makes sense. That's the trickier part.
Of course, parse time doesn't make sense for bound/translated code. For shrouded code, this would take into account decompression time, and immediate_elapsed_time() would have no effect (it wouldn't be in the IL anyway).
CChris
14. Re: Tiny typo in Manual
- Posted by Jim C. Brown Jul 15, 2008
- 916 views
I still don't like the syntax. I mean, you can't exactly override immediate_elapsed_time() with a user provided function like you could with peek()
Or can you?
It would be easy to add an immmediate_time() which would cause time() to be recorded right when it it parsed, an immediate_elapsed_time() to store the elapsed time at parse time, and an elapsed_tim() to fo the same at runtime.
This still doesn't allow benchmarks to include the time it takes to start up and initialize the interpreter (or translator).
These aren't really functions, if they are evaluated at parse time. They should be some kind of statement that can't be confused with a routine name.
Since, with the exception of developers of the interpreter itself (who can add the appropriate time() statements to parser.e and scanner.e directly), most people would not care how long it takes to parse, I'm not sure why this would be necessary? When benchmarking against another language, the benchmarker may just use the time command anyways (since few other langauges seem to support an immediate_time statement).
immmediate_time() restarts the stopwatch, so it is a procedure. I say restarts because say common.e would start it, thus allowing to reckon parse time. The backend wuld start its own stopwatch in all cases.
immmediate_elapsed_time() is a function. The "immediate_" part clearly says that it is not a runtime thing. It may not be as useful, but its implementation cost is about nil.
elapsed_time() is a true function, which retrieves immediate_elapsed_time() if it makes sense. That's the trickier part.
Of course, parse time doesn't make sense for bound/translated code. For shrouded code, this would take into account decompression time, and immediate_elapsed_time() would have no effect (it wouldn't be in the IL anyway).
CChris
15. Re: Tiny typo in Manual
- Posted by CChris Jul 15, 2008
- 904 views
I still don't like the syntax. I mean, you can't exactly override immediate_elapsed_time() with a user provided function like you could with peek()
Or can you?
immmediate_time() restarts the stopwatch, so it is a procedure. I say restarts because say common.e would start it, thus allowing to reckon parse time. The backend wuld start its own stopwatch in all cases.
immmediate_elapsed_time() is a function. The "immediate_" part clearly says that it is not a runtime thing. It may not be as useful, but its implementation cost is about nil.
elapsed_time() is a true function, which retrieves immediate_elapsed_time() if it makes sense. That's the trickier part.
Of course, parse time doesn't make sense for bound/translated code. For shrouded code, this would take into account decompression time, and immediate_elapsed_time() would have no effect (it wouldn't be in the IL anyway).
CChris
These would be predefined smbols like peek(), so, syntactically speaking, you can override them like peek().
However, the override will be evaluated at run time only, which is of course mostly useless. This reminds me of something I had thought about for a while: syntax plugins. They would allow to inject code at parse time, which is what you wish override could do in that case. I'll need more time to come up wth something, I currently don't know how I'd implement it. Apart from a nifty sed script on the .e source files, which is not looking good at all.
CChris
16. Re: Tiny typo in Manual
- Posted by Matt Lewis Jul 15, 2008
- 922 views
I still don't like the syntax. I mean, you can't exactly override immediate_elapsed_time() with a user provided function like you could with peek()
Or can you?
C'mon guys. This is getting silly. If you really want to do this (and I don't see a great need for it), why not just add a command line switch to tell the parser to report how long it took?
$ exu -ptime foo.exuMatt
17. Re: Tiny typo in Manual
- Posted by CChris Jul 16, 2008
- 882 views
I still don't like the syntax. I mean, you can't exactly override immediate_elapsed_time() with a user provided function like you could with peek()
Or can you?
C'mon guys. This is getting silly. If you really want to do this (and I don't see a great need for it), why not just add a command line switch to tell the parser to report how long it took?
$ exu -ptime foo.exuMatt
This ia also supposed to work with exw.exe, which is not supposed to be used on the command line, and will be invoked 95% of times using a double click on a .exw file. You can always Start -> Run... to launhch thru a command line with any switches, but this is clumsy. So, there has to be a command available inside the code. Command line is not the only way to launch a program.
CChris
18. Re: Tiny typo in Manual
- Posted by Matt Lewis Jul 16, 2008
- 874 views
C'mon guys. This is getting silly. If you really want to do this (and I don't see a great need for it), why not just add a command line switch to tell the parser to report how long it took?
$ exu -ptime foo.exu
This ia also supposed to work with exw.exe, which is not supposed to be used on the command line, and will be invoked 95% of times using a double click on a .exw file. You can always Start -> Run... to launhch thru a command line with any switches, but this is clumsy. So, there has to be a command available inside the code. Command line is not the only way to launch a program.
It would still work with exw, which can also be launched from the command line, or from a batch file, or from an IDE that allows you to specify command line arguments (who says it isn't supposed to be used from the command line?). Or possibly through a config file (once we get around to beefing that up). Or you could create a shortcut that used the switches.
Just because some people are afraid of the command line doesn't mean that everyone else should bend over backwards to accommodate them. We're not talking about end users here, but about developers. And there are workable solutions either way that don't require cluttering euphoria code with directives to output timing numbers. I suspect that one of the first things that IDE developers start working on after 4.0 coming out is a way to use these new switches from within the IDE.
Also, it seems to me that this is something you might be interested in only occasionally. You probably wouldn't want to always run with these options. So what's wrong with dropping to the command line on a rare occasion?
In fact, I'd say that we shouldn't allow this as a switch in the interpreter, but as an alternative build option (because I really don't see the need for this, but I could be wrong). I definitely wouldn't clutter up source code to allow this. If you want to time some code, you can always do it from another euphoria process using system_exec. And we now have the "-test" option that only parses code, so you could compare parse time only to parse+run times.
Matt
19. Re: Tiny typo in Manual
- Posted by CChris Jul 16, 2008
- 885 views
[quote Matt Lewis]
C'mon guys. This is getting silly. If you really want to do this (and I don't see a great need for it), why not just add a command line switch to tell the parser to report how long it took?
$ exu -ptime foo.exu
This ia also supposed to work with exw.exe, which is not supposed to be used on the command line, and will be invoked 95% of times using a double click on a .exw file. You can always Start -> Run... to launhch thru a command line with any switches, but this is clumsy. So, there has to be a command available inside the code. Command line is not the only way to launch a program.
It would still work with exw, which can also be launched from the command line, or from a batch file, or from an IDE that allows you to specify command line arguments (who says it isn't supposed to be used from the command line?). Or possibly through a config file (once we get around to beefing that up). Or you could create a shortcut that used the switches.
Isn't Euphoria supposed to remain simple to use?
Just because some people are afraid of the command line doesn't mean that everyone else should bend over backwards to accommodate them. We're not talking about end users here, but about developers. And there are workable solutions either way that don't require cluttering euphoria code with directives to output timing numbers. I suspect that one of the first things that IDE developers start working on after 4.0 coming out is a way to use these new switches from within the IDE.
I am not saying there shouldn't be a switch. I'm saying that there should be an alternative to it. The config file is probably acceptable.
Also, it seems to me that this is something you might be interested in only occasionally. You probably wouldn't want to always run with these options. So what's wrong with dropping to the command line on a rare occasion?
I don't agree with the "rare occasions". The truth is more like "rare groups of occasions". You test the impact of changes over some short period, during which you'll use almost exclusively the timer, and then revert to no timer for a long time. This is why, even though the groups of occasions are rare, the number of launches may be locally high, so convenience is still needed.
In fact, I'd say that we shouldn't allow this as a switch in the interpreter, but as an alternative build option (because I really don't see the need for this, but I could be wrong). I definitely wouldn't clutter up source code to allow this. If you want to time some code, you can always do it from another euphoria process using system_exec. And we now have the "-test" option that only parses code, so you could compare parse time only to parse+run times.
Matt
This is ok if you assume every euphoria developer - which is different from "any developer for Euphoria" - has a C compiler available. But I doubt this should be the case, and would strongly disagree against any creeping attempt to enforce this sort of things sideways. This has nothing to do with how easy it is to install or use the compiler - OpenWatcom looks to me as an obvious choice, and gcc is probably a de facto standard. The point is that benchmarking an Euphoria program doesn't have to require a C compiler, so that internal time interface should be available.
Again, using eu.conf is probably a good compromise, and your point about timing a -test run for parse time assessment is correct.
CChris
20. Re: Tiny typo in Manual
- Posted by Matt Lewis Jul 16, 2008
- 872 views
It would still work with exw, which can also be launched from the command line, or from a batch file, or from an IDE that allows you to specify command line arguments (who says it isn't supposed to be used from the command line?). Or possibly through a config file (once we get around to beefing that up). Or you could create a shortcut that used the switches.
Isn't Euphoria supposed to remain simple to use?
Yes. But I don't see anything in what I said that compromises that goal. In fact, I supplied several possible ways to get the job done. I don't think that any of them are particularly arcane.
In fact, I'd say that we shouldn't allow this as a switch in the interpreter, but as an alternative build option (because I really don't see the need for this, but I could be wrong). I definitely wouldn't clutter up source code to allow this. If you want to time some code, you can always do it from another euphoria process using system_exec. And we now have the "-test" option that only parses code, so you could compare parse time only to parse+run times.
This is ok if you assume every euphoria developer - which is different from "any developer for Euphoria" - has a C compiler available. But I doubt this should be the case, and would strongly disagree against any creeping attempt to enforce this sort of things sideways. This has nothing to do with how easy it is to install or use the compiler - OpenWatcom looks to me as an obvious choice, and gcc is probably a de facto standard. The point is that benchmarking an Euphoria program doesn't have to require a C compiler, so that internal time interface should be available.
Again, using eu.conf is probably a good compromise, and your point about timing a -test run for parse time assessment is correct.
Or maybe we can extend the eutest suite to allow an option for doing timing. Again, it's really simple to do this from within a euphoria process. Are people really that interested in the time it takes to parse their code? And then what will they do with that information? I don't think there's a lot that can be done about reducing parse time for an application except getting rid of code.
Whereas run-time optimizations can make big changes, and we already have some profiling, and it's usually not too hard to code a few time()s around the hot spots, and figure out how to reduce the time. You're usually not so interested in the overall time, but need something more granular, which we can already do.
I think we need a use case for why this is an interesting thing to do. Remember that we were originally talking about trying to replace functionality of a standard GNU utility on machines that don't have them (they are available in multiple ways for Windows, BTW). But this one is really simple, and could be mainly replaced by a euphoria program external to the interpreter.
I'm still unconvinced that this would be a good addition to the interpreter.
Matt
21. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 16, 2008
- 859 views
This ia also supposed to work with exw.exe, which is not supposed to be used on the command line, and will be invoked 95% of times using a double click on a .exw file. You can always Start -> Run... to launhch thru a command line with any switches, but this is clumsy. So, there has to be a command available inside the code. Command line is not the only way to launch a program.
This is getting crazy! 95% of the time double click? Wow. Where did that statistic come from? Did you do a poll somewhere I missed? I have never launched a .exw from the GUI. I did a quick poll in the IRC and no one there does either. I think you are all alone in launching from the Windows GUI. Maybe a completed app is launched from the GUI, but this is a developer option as Matt has said. Besides, if you are delivering a completed app, you should really give your users the courtesy of a translated program which is much faster.
Now, let's look at some other true window programs and how they deal with command line arguments. explorer.exe ... That takes command line arguments. One of them is the directory to start in. From the console you can type:
explorer.exe C:\
Now, to make this happen from the Windows GUI, you simply create a shortcut to explorer.exe and in the Target field you add to the end C:\ ... Now name your shortcut "Explore C:\". The point is the Windows interface works fine with command line parameters and was designed to. All you need to do is create a shortcut to your .exw program, add a -time (or whatever) and rename your shortcut to be "Benchmark MyApp".
Command line arguments are the way to pass optional parameter or alternate behaviors to your application. It's easy and it's the correct way of doing it, even on Microsoft GUI applications themselves.
Jeremy
22. Re: Tiny typo in Manual
- Posted by CChris Jul 16, 2008
- 898 views
It would still work with exw, which can also be launched from the command line, or from a batch file, or from an IDE that allows you to specify command line arguments (who says it isn't supposed to be used from the command line?). Or possibly through a config file (once we get around to beefing that up). Or you could create a shortcut that used the switches.
Isn't Euphoria supposed to remain simple to use?
Yes. But I don't see anything in what I said that compromises that goal. In fact, I supplied several possible ways to get the job done. I don't think that any of them are particularly arcane.
I am not opposing simple vs arcane, but simple vs clumsy, simple vs requiring red tape, simple vs requiring advance planning.
You know, I work in a wokplace where most of us use computers a lot, but few have a computer culture, let alone a programming culture. The less manipulations, the better acceptance and the fewer errors. I think we always should keep this in mind. Euphoria could be just right for this sort of audience; let's not leave them behind. You suggest methods that do work, but some are not natural for many.
In fact, I'd say that we shouldn't allow this as a switch in the interpreter, but as an alternative build option (because I really don't see the need for this, but I could be wrong). I definitely wouldn't clutter up source code to allow this. If you want to time some code, you can always do it from another euphoria process using system_exec. And we now have the "-test" option that only parses code, so you could compare parse time only to parse+run times.
This is ok if you assume every euphoria developer - which is different from "any developer for Euphoria" - has a C compiler available. But I doubt this should be the case, and would strongly disagree against any creeping attempt to enforce this sort of things sideways. This has nothing to do with how easy it is to install or use the compiler - OpenWatcom looks to me as an obvious choice, and gcc is probably a de facto standard. The point is that benchmarking an Euphoria program doesn't have to require a C compiler, so that internal time interface should be available.
Again, using eu.conf is probably a good compromise, and your point about timing a -test run for parse time assessment is correct.
Or maybe we can extend the eutest suite to allow an option for doing timing. Again, it's really simple to do this from within a euphoria process. Are people really that interested in the time it takes to parse their code? And then what will they do with that information? I don't think there's a lot that can be done about reducing parse time for an application except getting rid of code.
For starters, you may be interested in comparing some Eu version with another in this respect.
Getting an idea onn how the way one codes impacts what can be done with the code, and in which time, is probably quite educational too.
Normally, the execution time is largely more than the parse time, so including it or not may not matter much in terms of ordinary benchmarking. And if this is not true and execution time still matters though the program is small, code will be translated anyway. I guess that's what most CGI coders do. Otherwise, they could be interested.
Whereas run-time optimizations can make big changes, and we already have some profiling, and it's usually not too hard to code a few time()s around the hot spots, and figure out how to reduce the time. You're usually not so interested in the overall time, but need something more granular, which we can already do.
time() does not have near the resolution needed to time hotspots, ie places of code traversed briefly but very often. There are high resolution timers which work better. Perhaps including Tone Å¡koda's to the interpreter would be a better idea, I think it is cross platform. I'd support the move. That won't work on 486 PCs, but who uses them any longer?
I think we need a use case for why this is an interesting thing to do. Remember that we were originally talking about trying to replace functionality of a standard GNU utility on machines that don't have them (they are available in multiple ways for Windows, BTW).
The message title says we started from a tiny typo in the manual...
But this one is really simple, and could be mainly replaced by a euphoria program external to the interpreter.
I'm still unconvinced that this would be a good addition to the interpreter.
Matt
Have an option that can be set from a config file, along with any fancier hack with two processes, shortcuts or whatnots you can come up with. Or consider having a true hi-res timing system inside the interpreter, which would be even better imho. And there is working, time tested code around, so the development/test costs will be reduced.
CChris
23. Re: Tiny typo in Manual
- Posted by CChris Jul 16, 2008
- 875 views
This ia also supposed to work with exw.exe, which is not supposed to be used on the command line, and will be invoked 95% of times using a double click on a .exw file. You can always Start -> Run... to launhch thru a command line with any switches, but this is clumsy. So, there has to be a command available inside the code. Command line is not the only way to launch a program.
This is getting crazy! 95% of the time double click? Wow. Where did that statistic come from? Did you do a poll somewhere I missed? I have never launched a .exw from the GUI. I did a quick poll in the IRC and no one there does either. I think you are all alone in launching from the Windows GUI.
In 10 years of office work, I have seen not a single persn launch from command line of any kind outside the computer assistance persons, except for very specific and temporary issues (change of version messups and the like). You may say that's not a poll. More of a census indeed.
We do program a lot, but hardly need to deal with the OS more than the strict minimum (importing or exporting files, for the most part). Believe it or not, this happens on the same planet.
Maybe a completed app is launched from the GUI, but this is a developer option as Matt has said. Besides, if you are delivering a completed app, you should really give your users the courtesy of a translated program which is much faster.
I thought the whole point of an interpreter is to release source that can be inspected by users if only for security reasons, examining a data processing algorithm (I work in statistics) or the like. Then, a translated executable may be delivered at the same time if speed is needed and user is not supposed to translate anything. I translate my code by alt-right clicking a file, after setting my explorer once for all to execute the appropriate commands in such case, for instance. If what we want is mainly producing executables, then any true compiled language is better than Euphoria.
Now, let's look at some other true window programs and how they deal with command line arguments. explorer.exe ... That takes command line arguments. One of them is the directory to start in. From the console you can type:
explorer.exe C:\
Now, to make this happen from the Windows GUI, you simply create a shortcut to explorer.exe and in the Target field you add to the end C:\ ... Now name your shortcut "Explore C:\". The point is the Windows interface works fine with command line parameters and was designed to. All you need to do is create a shortcut to your .exw program, add a -time (or whatever) and rename your shortcut to be "Benchmark MyApp".
Command line arguments are the way to pass optional parameter or alternate behaviors to your application. It's easy and it's the correct way of doing it, even on Microsoft GUI applications themselves.
Jeremy
<sarcasm>
That's probably why they all care to offer a graphic configuration panel of some kind. Simpler and less costly, I guess.
</sarcasm>
While what you say is technically true, I can guarantee you that it is not well known outside the professional developers' community, as large as it stands. My point is: we shouldn't need to perform otherwise unfrequent actions when simpler methods are possible at a low implementation cost.
I think the alternatives I suggested in my previous reply are quite reasonable on both sides, unless I am missing something.
CChris
24. Re: Tiny typo in Manual
- Posted by Jeremy Cowgar Jul 16, 2008
- 905 views
In 10 years of office work, I have seen not a single persn launch from command line of any kind outside the computer assistance persons, except for very specific and temporary issues (change of version messups and the like). You may say that's not a poll. More of a census indeed.
You are now talking about a different group of people. Sure, end users are not going to go to a command line to launch Microsoft Word, nor do I think they should have to in order to launch MyEuphoriaApp. We are not talking about end users. We are talking about developers who are profiling their code. Users are not going to run a ms timer on your app.
Maybe a completed app is launched from the GUI, but this is a developer option as Matt has said. Besides, if you are delivering a completed app, you should really give your users the courtesy of a translated program which is much faster.
I thought the whole point of an interpreter is to release source that can be inspected by users if only for security reasons, examining a data processing algorithm (I work in statistics) or the like. Then, a translated executable may be delivered at the same time if speed is needed and user is not supposed to translate anything. I translate my code by alt-right clicking a file, after setting my explorer once for all to execute the appropriate commands in such case, for instance. If what we want is mainly producing executables, then any true compiled language is better than Euphoria.
Ok, now here you are talking about another group of people again. Are you saying that end users are going to be inspecting source code? If it's an open source application, I would expect the source code to be available. For instance, Firefox is open source, OpenOffice, Emacs, Vim, etc... They all provide executables for their users, however if you want the source it is available for your inspection as well, but they do not expect the user to be dealing with source code.
Now, to make this happen from the Windows GUI, you simply create a shortcut to explorer.exe and in the Target field you add to the end C:\ ... Now name your shortcut "Explore C:\". The point is the Windows interface works fine with command line parameters and was designed to. All you need to do is create a shortcut to your .exw program, add a -time (or whatever) and rename your shortcut to be "Benchmark MyApp".
Command line arguments are the way to pass optional parameter or alternate behaviors to your application. It's easy and it's the correct way of doing it, even on Microsoft GUI applications themselves.
<sarcasm>
That's probably why they all care to offer a graphic configuration panel of some kind. Simpler and less costly, I guess.
</sarcasm>
They make a GUI to make Explorer have multiple places of opening up on a click? I thought the GUI interface for that was "Create Shortcut" ?
While what you say is technically true, I can guarantee you that it is not well known outside the professional developers' community, as large as it stands. My point is: we shouldn't need to perform otherwise unfrequent actions when simpler methods are possible at a low implementation cost.
Again, we are talking about developers. No end user is going to be timing your code, adjusting it and trying to make a better algorithm that takes less time.
I think the alternatives I suggested in my previous reply are quite reasonable on both sides, unless I am missing something.
Your suggestions were pre-parse time. As Matt said, that doesn't hardly matter as what are you going to do to reduce the parse time but remove code. But to me, this discussion has move from timing to the validity of command line arguments. I am trying to think of other languages that do not have command line arguments. I can think of a few, but all of them are GUI RAD based tools. Other successful languages such as Python, Ruby, Java, etc... all have command line arguments. It didn't stop them from being productive.
Jeremy
25. Re: Tiny typo in Manual
- Posted by Irv Jul 16, 2008
- 863 views
... Other successful languages such as Python, Ruby, Java, etc... all have command line arguments. It didn't stop them from being productive.
Jeremy
The -D command line argument has been (IMHO) the #1 best addition to Euphoria, because of the time and trouble it saves when debugging code. No 'end user' is going to use it, unless I tell 'em to try, in which case they might be able to send me information which would be more helpful than "your program broke" :)
26. Re: Tiny typo in Manual
- Posted by Shawn Pringle Jul 16, 2008
- 881 views
... Other successful languages such as Python, Ruby, Java, etc... all have command line arguments. It didn't stop them from being productive.
Jeremy
The -D command line argument has been (IMHO) the #1 best addition to Euphoria, because of the time and trouble it saves when debugging code. No 'end user' is going to use it, unless I tell 'em to try, in which case they might be able to send me information which would be more helpful than "your program broke" :)
It's much ado about nothing. How long do you think it takes a program to parse say, Judith's IDE? Some fraction of a second that only happens once when you start it up. If the amount of time bothers you you can always press the turbo button.
Shawn Pringle
27. Re: Tiny typo in Manual
- Posted by Matt Lewis Jul 16, 2008
- 878 views
Yes. But I don't see anything in what I said that compromises that goal. In fact, I supplied several possible ways to get the job done. I don't think that any of them are particularly arcane.
I am not opposing simple vs arcane, but simple vs clumsy, simple vs requiring red tape, simple vs requiring advance planning.
So am I.
You know, I work in a wokplace where most of us use computers a lot, but few have a computer culture, let alone a programming culture. The less manipulations, the better acceptance and the fewer errors. I think we always should keep this in mind. Euphoria could be just right for this sort of audience; let's not leave them behind. You suggest methods that do work, but some are not natural for many.
Chris, come on, this is getting really bizarre. We're talking about a 'feature' that would only be useful for someone who is going to be hacking on the interpreter. I don't think this is too much to ask. I'm not asking your grandmother to figure out how to send command line arguments.
Whereas run-time optimizations can make big changes, and we already have some profiling, and it's usually not too hard to code a few time()s around the hot spots, and figure out how to reduce the time. You're usually not so interested in the overall time, but need something more granular, which we can already do.
time() does not have near the resolution needed to time hotspots, ie places of code traversed briefly but very often. There are high resolution timers which work better. Perhaps including Tone Å¡koda's to the interpreter would be a better idea, I think it is cross platform. I'd support the move. That won't work on 486 PCs, but who uses them any longer?
I disagree. It's plenty good for figuring out where things are bogging down. If it's not, then you probably don't need to optimize. You can get a good idea of where the problem code is by zooming in on major chunks of code. And you can always do a profile to figure out where the likely trouble areas are, if you haven't already figured it out.
I think we need a use case for why this is an interesting thing to do. Remember that we were originally talking about trying to replace functionality of a standard GNU utility on machines that don't have them (they are available in multiple ways for Windows, BTW).
The message title says we started from a tiny typo in the manual...
But this one is really simple, and could be mainly replaced by a euphoria program external to the interpreter.
I'm still unconvinced that this would be a good addition to the interpreter.
Have an option that can be set from a config file, along with any fancier hack with two processes, shortcuts or whatnots you can come up with. Or consider having a true hi-res timing system inside the interpreter, which would be even better imho. And there is working, time tested code around, so the development/test costs will be reduced.
You still haven't provided an argument for doing it. And I still oppose it.
Matt
28. Re: Tiny typo in Manual
- Posted by Unkmar Jul 20, 2008
- 840 views
Create a batch file for your short-term timing stuff.
