1. same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1821 views
Well, it's happened again. And this is an ooollld topic. In 3.1 and previous, it was "cured" by wrapping ALL code in procedures, such as main(). Not all code in Eu4 does this, specifically news.ex for example. This is what happens if you launch an application, and then edit the source code a minute later after the application supposedly has already loaded that code:
http://imgbin.org/index.php?page=image&id=717
The source code line as seen by the *running* application sees a mangled line, and reports the wrong line number. The interpreter should have already loaded the file and converted it to il code, and from then on ignored the file on the drive. It doesn't.
useless
2. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1811 views
The source code line as seen by the *running* application sees a mangled line, and reports the wrong line number. The interpreter should have already loaded the file and converted it to il code, and from then on ignored the file on the drive. It doesn't.
Are you running code that modifies its own source? Based on what you've shown, I'd rather suspect that this is a bug in the error reporting system.
Matt
3. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1798 views
The source code line as seen by the *running* application sees a mangled line, and reports the wrong line number. The interpreter should have already loaded the file and converted it to il code, and from then on ignored the file on the drive. It doesn't.
Are you running code that modifies its own source? Based on what you've shown, I'd rather suspect that this is a bug in the error reporting system.
Matt
No, i am not.
[12:36] <rywilly> where is alphanwhat ?
[12:36] <katsmeow-afk> it's scrambled
[12:37] <katsmeow-afk> it doesn't exist
[12:37] <rywilly> oh
[12:37] <rywilly> what is it supposed to say?
[12:37] <katsmeow-afk> that's the demonstrateable part of the bug
[12:37] <katsmeow-afk> the bug is the interpreter is reloading the source file
[12:38] <katsmeow-afk> and apparently partially overlaying it
[12:38] <rywilly> oh
[12:38] <katsmeow-afk> "alphanwhat" is nowhere in the source code
[12:38] <rywilly> ic
[12:39] <katsmeow-afk> and if i had not been editing it to debug it, and saved a copy of the new source, the running app would not have crashed
[12:39] <katsmeow-afk> yet the runing app should not give a what about the new source code
[12:39] <katsmeow-afk> it's RUNNING
[12:39] <katsmeow-afk> it should have it's own copy already in il code by now
[12:39] <katsmeow-afk> the il code should be executing
[12:39] <katsmeow-afk> i did not edit theil code
[12:40] <katsmeow-afk> ergo, there should have been no problems
[12:40] <katsmeow-afk> with this bug, i cannot edit code while the app is running
[12:40] * katsmeow-afk adds this explaination to the post
useless
4. Re: same problem in v4 as previous editions
- Posted by jeremy (admin) Aug 28, 2009
- 1765 views
[12:39] <katsmeow-afk> and if i had not been editing it to debug it, and saved a copy of the new source, the running app would not have crashed
[12:39] <katsmeow-afk> yet the runing app should not give a what about the new source code
[12:39] <katsmeow-afk> it's RUNNING
[12:39] <katsmeow-afk> it should have it's own copy already in il code by now
[12:39] <katsmeow-afk> the il code should be executing
[12:39] <katsmeow-afk> i did not edit theil code
[12:40] <katsmeow-afk> ergo, there should have been no problems
[12:40] <katsmeow-afk> with this bug, i cannot edit code while the app is running
[12:40] * katsmeow-afk adds this explaination to the post
Something else is going on. By no means does Euphoria do that. That's a pretty complex task to even come remotely close to doing, only a few languages do that and they are used in systems such as telephone switches, satellite systems, etc... Euphoria does not do that, there is another explanation, but I don't know what it is, but it's for sure not Euphoria re-loading source code of an already running application.
Jeremy
5. Re: same problem in v4 as previous editions
- Posted by jimcbrown (admin) Aug 28, 2009
- 1747 views
Something else is going on. By no means does Euphoria do that. That's a pretty complex task to even come remotely close to doing, only a few languages do that and they are used in systems such as telephone switches, satellite systems, etc... Euphoria does not do that, there is another explanation, but I don't know what it is, but it's for sure not Euphoria re-loading source code of an already running application.
Jeremy
Well, it is possible that
a) The app is "running" because the DOS console window is already showing, but the interpreter is still parsing the code into il, and managed to read the file as it was in the middle of being saved.
b) When the app crashed, the error reporting reread the line from the file, as the file was in the middle of being saved.
6. Re: same problem in v4 as previous editions
- Posted by jeremy (admin) Aug 28, 2009
- 1762 views
Well, it is possible that
a) The app is "running" because the DOS console window is already showing, but the interpreter is still parsing the code into il, and managed to read the file as it was in the middle of being saved.
b) When the app crashed, the error reporting reread the line from the file, as the file was in the middle of being saved.
I guess that is possible, but it would have to be done w/in a milli-second or two. I can't imagine launching a program, ALT-Tabbing to your editor, making a change and saving the file before Euphoria is done parsing it?
Jeremy
7. Re: same problem in v4 as previous editions
- Posted by ryanj Aug 28, 2009
- 1747 views
Well, it is possible that
a) The app is "running" because the DOS console window is already showing, but the interpreter is still parsing the code into il, and managed to read the file as it was in the middle of being saved.
b) When the app crashed, the error reporting reread the line from the file, as the file was in the middle of being saved.
Does the interpreter re-read the source when generating an error report, or does it have a copy of the source text in memory?
8. Re: same problem in v4 as previous editions
- Posted by jimcbrown (admin) Aug 28, 2009
- 1766 views
Well, it is possible that
a) The app is "running" because the DOS console window is already showing, but the interpreter is still parsing the code into il, and managed to read the file as it was in the middle of being saved.
b) When the app crashed, the error reporting reread the line from the file, as the file was in the middle of being saved.
Does the interpreter re-read the source when generating an error report, or does it have a copy of the source text in memory?
I believe that it rereads the source from the file on disk.
9. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1724 views
<snippppppp>
Something else is going on. By no means does Euphoria do that. That's a pretty complex task to even come remotely close to doing, only a few languages do that and they are used in systems such as telephone switches, satellite systems, etc... Euphoria does not do that, there is another explanation, but I don't know what it is, but it's for sure not Euphoria re-loading source code of an already running application.
Jeremy
I believe it is, somehow. Textpad will pop up a msg after the Eu app crashes, saying the sourse has been modified, and do i want to reload it. Usually, almost always, there is no actual text modification, but what Textpad is triggering on is the timestamp of the file, which Textpad tests every 2 sec or so. The timestamp is indeed changed. Rarely, the text in the source code has been trashed, even more rarely, it's trashed severely.
This is an old topic, it's been discussed before. And i am not the only one who's reported it.
I use this to stop me from working on a file:
system("attrib +r "&rootdrive&"\\DataMinerCode\\mine_intellicast\\getter\\Getintellicast10.exw",2)
But obviously, stopping me from working sorta takes the "Rapid" out of RDS.
useless
10. Re: same problem in v4 as previous editions
- Posted by jeremy (admin) Aug 28, 2009
- 1768 views
I believe that it rereads the source from the file on disk.
We are missing what she is saying:
[12:39] <katsmeow-afk> and if i had not been editing it to debug it, and saved a copy of the new source, the running app would not have crashed ... [12:40] <katsmeow-afk> with this bug, i cannot edit code while the app is running
She is saying that because she edited the source code of a running application that her running application crashed.
Jeremy
11. Re: same problem in v4 as previous editions
- Posted by jimcbrown (admin) Aug 28, 2009
- 1785 views
We are missing what she is saying:
[12:39] <katsmeow-afk> and if i had not been editing it to debug it, and saved a copy of the new source, the running app would not have crashed ... [12:40] <katsmeow-afk> with this bug, i cannot edit code while the app is running
She is saying that because she edited the source code of a running application that her running application crashed.
Jeremy
D'oh!
Sorry, I missed that. That changes everything.
12. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1783 views
I believe that it rereads the source from the file on disk.
We are missing what she is saying:
[12:39] <katsmeow-afk> and if i had not been editing it to debug it, and saved a copy of the new source, the running app would not have crashed ... [12:40] <katsmeow-afk> with this bug, i cannot edit code while the app is running
She is saying that because she edited the source code of a running application that her running application crashed.
Jeremy
True, if i lock the file to read-only, as shown howto in previous post, it won't crash. But if i am bebugging, and running just to get a new ex.err file, and add anything to the source file, it likely will crash with a scrambled source file.
useless
13. Re: same problem in v4 as previous editions
- Posted by jeremy (admin) Aug 28, 2009
- 1732 views
True, if i lock the file to read-only, as shown howto in previous post, it won't crash. But if i am bebugging, and running just to get a new ex.err file, and add anything to the source file, it likely will crash with a scrambled source file.
Are you in the debugger executing the code, then when something comes up, leaving it in the debugger, editing, then going back to continue your debug session in the debugger?
Jeremy
14. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1752 views
True, if i lock the file to read-only, as shown howto in previous post, it won't crash. But if i am bebugging, and running just to get a new ex.err file, and add anything to the source file, it likely will crash with a scrambled source file.
Are you in the debugger executing the code, then when something comes up, leaving it in the debugger, editing, then going back to continue your debug session in the debugger?
Jeremy
What?
And Textpad, not Eu's debugger or Andrea's or Judith's ide. Textpad doesn't execute code, it writes out a .bat file, which contains the executeable name, source filename, and some parameters, and passes that to the OS.
useless
15. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1734 views
Does the interpreter re-read the source when generating an error report, or does it have a copy of the source text in memory?
I believe that it rereads the source from the file on disk.
It definitely does not re-read the source when an error is reported! I direct your attention to be_symtab.c:FindLine(). Similar code exists in execute.e.
Matt
16. Re: same problem in v4 as previous editions
- Posted by jeremy (admin) Aug 28, 2009
- 1784 views
What?
I asked if you are in the debugger, the one build into Euphoria and then editing code else where (which text editor doesn't matter), however, judging from your response, I take it that you were not in the debugger.
Jeremy
17. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1726 views
Does the interpreter re-read the source when generating an error report, or does it have a copy of the source text in memory?
I believe that it rereads the source from the file on disk.
It definitely does not re-read the source when an error is reported! I direct your attention to be_symtab.c:FindLine(). Similar code exists in execute.e.
Matt
Then it has a copy of the source in memory and periodically refers to it? The show-stopping bug is this: The IL code should be immuteable. If, perchance, the OS (winxp, sp2+whatever) is noticing the source file is in memory when it updates the file on disk, would that cause the interpreter to note the source file is "new" (maybe even before the OS is done updating the copy because of a task switch), regenerate the IL code and overlay/insert it in/onto the running IL code, where the IL code executor finds the anomaly and refuses to believe it?
useless
18. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1746 views
She is saying that because she edited the source code of a running application that her running application crashed.
True, if i lock the file to read-only, as shown howto in previous post, it won't crash. But if i am bebugging, and running just to get a new ex.err file, and add anything to the source file, it likely will crash with a scrambled source file.
Here's how it works:
- Euphoria reads your source code and parses it as it does so. Any error is reported immediately when found.
- The information generated from parsing is converted into the format that the backend uses, and control is passed from the euphoria written front end to the back end
- The backend fixes up some pointers and initializes itself for running
- The backend starts executing your code
- If a runtime error occurs, the error is reported, based on what is in memory.
Note that it's the same code that executes shrouded [bound] code as normal interpreted code. The default for shrouded code is to get rid of all name information. It always removes the text of your source code, so that you get semi-intelligent error messages, but not the full trace that you would get from a regular interpreted error.
Note that the only time any file is read is when it is first included in your program. Once it gets to the end, it's closed and never read again. I don't know what happened to you, but it wasn't that it tried to re-read anything.
Matt
19. Re: same problem in v4 as previous editions
- Posted by jeremy (admin) Aug 28, 2009
- 1719 views
Then it has a copy of the source in memory and periodically refers to it? The show-stopping bug is this: The IL code should be immuteable. If, perchance, the OS (winxp, sp2+whatever) is noticing the source file is in memory when it updates the file on disk, would that cause the interpreter to note the source file is "new" (maybe even before the OS is done updating the copy because of a task switch), regenerate the IL code and overlay/insert it in/onto the running IL code, where the IL code executor finds the anomaly and refuses to believe it?
No. It will not happen. Do this for example:
include std/os.e while 1 do puts(1, "Hello\n") sleep(1) end while
Then launch the program. Now, while that program is running, change Hello to Goodbye and save. What you are suggesting is that on the running program, that it would then start saying Goodbye?
Just give it a try and report back what happens.
Jeremy
20. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1715 views
It definitely does not re-read the source when an error is reported! I direct your attention to be_symtab.c:FindLine(). Similar code exists in execute.e.
Then it has a copy of the source in memory and periodically refers to it? The show-stopping bug is this: The IL code should be immuteable. If, perchance, the OS (winxp, sp2+whatever) is noticing the source file is in memory when it updates the file on disk, would that cause the interpreter to note the source file is "new" (maybe even before the OS is done updating the copy because of a task switch), regenerate the IL code and overlay/insert it in/onto the running IL code, where the IL code executor finds the anomaly and refuses to believe it?
Yes, it keeps the source code in memory. There are a couple of places where the IL code changes once it starts running:
- GLOBAL_INIT_CHECK ops turn into NOPs after the first time they are encountered
- SWITCH_RT ops turn into SWITCH, SWITCH_I or SWITCH_SPI ops after the first time they are encountered
I'm not aware of any others. I do not believe that these ops would have an effect like what you've described. They are certainly not driven by any outside circumstances.
There is no check for a newer file. The front end simply attempts to open the file when it is first encountered as an include. It may pause to read other files depending on other include statements. I suppose it might be possible for something else to corrupt or change the file during this process. I'm not familiar enough about OS file locking semantics to say too much about that.
As I said, my suspicion is that you've found a bug in the error reporting mechanism. Especially with all of the changes to the parser, there have been several during 4.0 development that have resulted in reporting the wrong line number or even the wrong file and line altogether. I wouldn't be surprised to find another bug.
Matt
21. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1709 views
She is saying that because she edited the source code of a running application that her running application crashed.
True, if i lock the file to read-only, as shown howto in previous post, it won't crash. But if i am bebugging, and running just to get a new ex.err file, and add anything to the source file, it likely will crash with a scrambled source file.
Here's how it works:
- Euphoria reads your source code and parses it as it does so. Any error is reported immediately when found.
- The information generated from parsing is converted into the format that the backend uses, and control is passed from the euphoria written front end to the back end
- The backend fixes up some pointers and initializes itself for running
- The backend starts executing your code
- If a runtime error occurs, the error is reported, based on what is in memory.
Note that it's the same code that executes shrouded [bound] code as normal interpreted code. The default for shrouded code is to get rid of all name information. It always removes the text of your source code, so that you get semi-intelligent error messages, but not the full trace that you would get from a regular interpreted error.
Note that the only time any file is read is when it is first included in your program. Once it gets to the end, it's closed and never read again. I don't know what happened to you, but it wasn't that it tried to re-read anything.
Matt
Even if the news.ex launched a new task with the new included file? Even if it did, however, the IL code should not have been scrambled. The scrambling is always of the same form, some source code is offset, as if a selected text block was shifted the amount of the newly written code, and dropped back at the shifted position. Why it's causing a error in the *executing and running* application, if there is no way to generate new IL code, i dunno.
useless
22. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1711 views
Note that the only time any file is read is when it is first included in your program. Once it gets to the end, it's closed and never read again. I don't know what happened to you, but it wasn't that it tried to re-read anything.
Even if the news.ex launched a new task with the new included file? Even if it did, however, the IL code should not have been scrambled. The scrambling is always of the same form, some source code is offset, as if a selected text block was shifted the amount of the newly written code, and dropped back at the shifted position. Why it's causing a error in the *executing and running* application, if there is no way to generate new IL code, i dunno.
When you say 'launched a new task,' if you mean a euphoria task, then nothing is re-read. If you launch a new process (using system() or system_exec()) then that new process starts from scratch, and certainly would read the source code. I suppose you could maybe use fork() or something (where it's available), but that's not what system() and system_exec() do.
I don't have enough of an understanding of what happened to cause the error. Can you email me some code that demonstrates this issue? Or post it to the bug tracker? It needs to be fixed, whether its simply getting line numbers wrong or if it's something more exotic.
Matt
23. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1686 views
Just as a hoot, what if the interpreter, before (or after?) loading the source file, copy/renamed it? Then, supposedly, the original is not linked in any way thru the OS to the renamed/loaded file.
useless
24. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1668 views
Just as a hoot, what if the interpreter, before (or after?) loading the source file, copy/renamed it? Then, supposedly, the original is not linked in any way thru the OS to the renamed/loaded file.
Here are all of the places in the interpreter front end that open files:
main.e:84: return open(real_name, "r") pathopen.e:234: fn = open( conf_path, "r" ) pathopen.e:431: try = open( file_path, "r" ) pathopen.e:467: try = open(file_path, "r") pathopen.e:477: try = open(file_path, "r") pathopen.e:512: try = open(file_path, "r") pathopen.e:524: try = open(file_path, "r") platform.e:129: fh = open(lcmds[1], "rb") scanner.e:520: return open(new_include_name, "r")
Here are all of the places in the backend of the interpreter that open files:
be_machine.c:321:IFILE long_iopen(char *name, char *mode)
be_machine.c:324: return iopen(name, mode);
be_machine.c:330: return open(name, mode);
be_rterror.c:201: TempErrFile = iopen(TempErrName, "w");
be_rterror.c:800: conin = iopen("CON", "r");
be_runtime.c:486: debug_log = iopen("debug.log", "w");
be_runtime.c:646: TempErrFile = iopen(TempErrName, "w");
be_runtime.c:3783: fp = long_iopen(cname, cmode);
be_runtime.c:4663: trace_file = iopen("ctrace-d.out", "wb");
be_runtime.c:4665: trace_file = iopen("ctrace.out", "wb");
be_runtime.c:5185: f = iopen("ex.pro", "w");
be_runtime.c:5620: wrnf = iopen(TempWarningName,"w");
Those are all either opening error or logging files, or opening a file for use code.
Matt
25. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1734 views
<snipp>
I don't have enough of an understanding of what happened to cause the error. Can you email me some code that demonstrates this issue? Or post it to the bug tracker? It needs to be fixed, whether its simply getting line numbers wrong or if it's something more exotic.
Matt
Yes, i have saved a .rar of all files, including the 4 pics on imgbin, to: http://designerthinking.com/temp/news.ex.rar
For those uninterested in pics, a new pic is at http://imgbin.org/index.php?page=image&id=720
What i did:
1) in Textpad, launch news.ex with C:\euphoria40b1\bin\euiw.exe
2) when the dosbox pops up,
3) in Textpad, switch to http.e window, and add line "blarf"
4) in Textpad, save http.e
5) wait a sec as the running app adds new lines to show it's till running fine
6) in Textpad, edit "with trace" to "without trace", save the file again
7) see dosbox pop up with error as seen in imgbin pic
8) after a screen capture documentation, in the error dosbox, i "Press Enter"
9) Textpad then pops up window as seen at http://imgbin.org/index.php?page=image&id=721
Here's selected lines from the ex.err:
C:\euphoria40b1\news.ex\http.e:144
<0076>:: expected to see an assignment after 'i', such as =, +=, -=, *=, /= or &=
i if find(what[idx],alphanum) then
^
But line 144 remains:
if find(what[idx],alphanum) then
There is no preceeding "i" in the source. Please note, the http.e source WAS "with trace", and i edited it to "without trace" while the app was running, and got no line dump from http.e in ex.err.
useless
26. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1705 views
What i did:
1) in Textpad, launch news.ex with C:\euphoria40b1\bin\euiw.exe
2) when the dosbox pops up,
3) in Textpad, switch to http.e window, and add line "blarf"
4) in Textpad, save http.e
5) wait a sec as the running app adds new lines to show it's till running fine
6) in Textpad, edit "with trace" to "without trace", save the file again
7) see dosbox pop up with error as seen in imgbin pic
8) after a screen capture documentation, in the error dosbox, i "Press Enter"
9) Textpad then pops up window as seen at http://imgbin.org/index.php?page=image&id=721
The issue appears to be (yes, I was able to reproduce it) that when euphoria code opens a file for reading, it does not open it for exclusive reading (at least on windows). It looks like if you write to the file during a read, Bad Things Happen. I suppose we could open source files in "u" mode to prevent anyone else from writing to them while we're reading them.
What you were seeing was a wget.ex process (launched by system()) crashing when it happened to read in garbage, or at least, when it started reading from somewhere in the file that it didn't really want to be reading. I'd recommend not editing source code while launching programs that will use that code.
Matt
27. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1659 views
<snipps>
The issue appears to be (yes, I was able to reproduce it) that when euphoria code opens a file for reading, it does not open it for exclusive reading (at least on windows). It looks like if you write to the file during a read, Bad Things Happen. I suppose we could open source files in "u" mode to prevent anyone else from writing to them while we're reading them.
What you were seeing was a wget.ex process (launched by system()) crashing when it happened to read in garbage, or at least, when it started reading from somewhere in the file that it didn't really want to be reading. I'd recommend not editing source code while launching programs that will use that code.
Matt
But, i did not edit the file "while launching programs", the program was already launchED and RUNNING properly. The program had been running long enough to be displaying line after line on-screen. And you said the app will read in all files PRIOR to running, and never read them in again.
So ok, in the eu interpreter source code (not the files in the rar i posted), set them to +r or +whatever when reading in during application startup, set them back to whatever their status was before actual running. Then see if the crash can be reproduced.
But i suspect it will be reproduced, because, in the example i gave, the original RUNNING code, already executed several times before i edited and saved, had "with trace", and if the new edit had not been loaded and converted to IL code, the crash should have written a log of executed lines leading up to the crash. However, since new IL code was generated when the saved file was written, the interpreter "knew" there was a "without trace" and didn't do a line dump.
useless
28. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1648 views
But, i did not edit the file "while launching programs", the program was already launchED and RUNNING properly. The program had been running long enough to be displaying line after line on-screen. And you said the app will read in all files PRIOR to running, and never read them in again.
Please refer to this line in news.ex:
system(sprintf("euiw.exe wget.ex -q -b -O %s %s > %s", {mytemp, url, null_device}), 2)
So ok, in the eu interpreter source code (not the files in the rar i posted), set them to +r or +whatever when reading in during application startup, set them back to whatever their status was before actual running. Then see if the crash can be reproduced.
But i suspect it will be reproduced, because, in the example i gave, the original RUNNING code, already executed several times before i edited and saved, had "with trace", and if the new edit had not been loaded and converted to IL code, the crash should have written a log of executed lines leading up to the crash. However, since new IL code was generated when the saved file was written, the interpreter "knew" there was a "without trace" and didn't do a line dump.
No, please re-read what I wrote, and look at the code, and you'll see that programs were still being launched. Note that news.ex doesn't even include http.e. It's wget.ex that does. And multiple copies were launched as the various tasks were created.
Matt
29. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1657 views
But, i did not edit the file "while launching programs", the program was already launchED and RUNNING properly. The program had been running long enough to be displaying line after line on-screen. And you said the app will read in all files PRIOR to running, and never read them in again.
Please refer to this line in news.ex:
system(sprintf("euiw.exe wget.ex -q -b -O %s %s > %s", {mytemp, url, null_device}), 2)
So ok, in the eu interpreter source code (not the files in the rar i posted), set them to +r or +whatever when reading in during application startup, set them back to whatever their status was before actual running. Then see if the crash can be reproduced.
But i suspect it will be reproduced, because, in the example i gave, the original RUNNING code, already executed several times before i edited and saved, had "with trace", and if the new edit had not been loaded and converted to IL code, the crash should have written a log of executed lines leading up to the crash. However, since new IL code was generated when the saved file was written, the interpreter "knew" there was a "without trace" and didn't do a line dump.
No, please re-read what I wrote, and look at the code, and you'll see that programs were still being launched. Note that news.ex doesn't even include http.e. It's wget.ex that does. And multiple copies were launched as the various tasks were created.
Matt
Ok, so the interpreter isn't caching anything to launch new tasks, i did not know that. But funny how it's so easy to be writing new file contents as the new system() call is reading that same file. I didn't know opening a file for writing in one app (Textpad) would allow another app (Euphoria) to be reading that file. So opening for a write doesn't lock that file, even tho i get a "that file is in use by another application" error fairly often? And apparently, a file open for reading (Euphoria) doesn't stop it being written to (Textpad)?
Still this is not the same scenario as reported in past years, when an app didn't use system for anything but wget.exe, and i still had to +r the Euphoria source file. So could you do as you thought of, and lock the file when reading it in, make sure Eu has sole ownership of it before using it? And of course, unlocking it after reading it in.
useless
30. Re: same problem in v4 as previous editions
- Posted by mattlewis (admin) Aug 28, 2009
- 1644 views
I didn't know opening a file for writing in one app (Textpad) would allow another app (Euphoria) to be reading that file. So opening for a write doesn't lock that file, even tho i get a "that file is in use by another application" error fairly often? And apparently, a file open for reading (Euphoria) doesn't stop it being written to (Textpad)?
What I think is going on is that the write happens during the read. As soon as textpad writes out the file, I suspect that euphoria starts reading from the beginning again. Assuming we change the way we open the file, you should get an error from Textpad in the future, saying that it can't access that file.
Matt
31. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1604 views
I didn't know opening a file for writing in one app (Textpad) would allow another app (Euphoria) to be reading that file. So opening for a write doesn't lock that file, even tho i get a "that file is in use by another application" error fairly often? And apparently, a file open for reading (Euphoria) doesn't stop it being written to (Textpad)?
What I think is going on is that the write happens during the read. As soon as textpad writes out the file, I suspect that euphoria starts reading from the beginning again. Assuming we change the way we open the file, you should get an error from Textpad in the future, saying that it can't access that file.
Matt
That beats what's happening now, and is acceptable, as i can just hit save again.
useless
32. Re: same problem in v4 as previous editions
- Posted by DerekParnell (admin) Aug 28, 2009
- 1668 views
Euphoria makes the assumption that the source file is not modified whilst the program is still running (i.e. the eui process is still active). This is not an unreasonable assumption, IMO. However, explicitly locking the source file against writes by eui is also a reasonable thing to do.
I notice the effect when my app crashes and there is a "press enter to continue" type message, but before pressing enter I edit the file and try to save it. My editor says I can't save it because it is opened by something else.
Will locking the source by eui mean I can't get another program to read it at the same time? I would still like to be able to read the source file while eui is still running against it.
33. Re: same problem in v4 as previous editions
- Posted by useless Aug 28, 2009
- 1572 views
Euphoria makes the assumption that the source file is not modified whilst the program is still running (i.e. the eui process is still active). This is not an unreasonable assumption, IMO. However, explicitly locking the source file against writes by eui is also a reasonable thing to do.
I notice the effect when my app crashes and there is a "press enter to continue" type message, but before pressing enter I edit the file and try to save it. My editor says I can't save it because it is opened by something else.
Will locking the source by eui mean I can't get another program to read it at the same time? I would still like to be able to read the source file while eui is still running against it.
I hope in understood Matt correctly when he said lock the file while reading it, and he didn't say lock it while running it. I have some apps that run for months, and if it's locked i won't be able to clone it.
useless
