1. same problem in v4 as previous editions

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

new topic     » topic index » view message » categorize

2. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: same problem in v4 as previous editions

mattlewis said...
useless said...

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: same problem in v4 as previous editions

useless said...

[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

new topic     » goto parent     » topic index » view message » categorize

5. Re: same problem in v4 as previous editions

jeremy said...

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.

new topic     » goto parent     » topic index » view message » categorize

6. Re: same problem in v4 as previous editions

jimcbrown said...

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: same problem in v4 as previous editions

jimcbrown said...

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?

new topic     » goto parent     » topic index » view message » categorize

8. Re: same problem in v4 as previous editions

ryanj said...
jimcbrown said...

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.

new topic     » goto parent     » topic index » view message » categorize

9. Re: same problem in v4 as previous editions

jeremy said...

<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

new topic     » goto parent     » topic index » view message » categorize

10. Re: same problem in v4 as previous editions

jimcbrown said...

I believe that it rereads the source from the file on disk.

We are missing what she is saying:

useless said...

[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

new topic     » goto parent     » topic index » view message » categorize

11. Re: same problem in v4 as previous editions

jeremy said...

We are missing what she is saying:

useless said...

[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.

new topic     » goto parent     » topic index » view message » categorize

12. Re: same problem in v4 as previous editions

jeremy said...
jimcbrown said...

I believe that it rereads the source from the file on disk.

We are missing what she is saying:

useless said...

[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

new topic     » goto parent     » topic index » view message » categorize

13. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

14. Re: same problem in v4 as previous editions

jeremy said...
useless said...

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

new topic     » goto parent     » topic index » view message » categorize

15. Re: same problem in v4 as previous editions

jimcbrown said...
ryanj said...

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

new topic     » goto parent     » topic index » view message » categorize

16. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

17. Re: same problem in v4 as previous editions

mattlewis said...
jimcbrown said...
ryanj said...

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

new topic     » goto parent     » topic index » view message » categorize

18. Re: same problem in v4 as previous editions

useless said...
jeremy said...

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:

  1. Euphoria reads your source code and parses it as it does so. Any error is reported immediately when found.
  2. 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
  3. The backend fixes up some pointers and initializes itself for running
  4. The backend starts executing your code
  5. 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

new topic     » goto parent     » topic index » view message » categorize

19. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

20. Re: same problem in v4 as previous editions

useless said...
mattlewis said...

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:

  1. GLOBAL_INIT_CHECK ops turn into NOPs after the first time they are encountered
  2. 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

new topic     » goto parent     » topic index » view message » categorize

21. Re: same problem in v4 as previous editions

mattlewis said...
useless said...
jeremy said...

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:

  1. Euphoria reads your source code and parses it as it does so. Any error is reported immediately when found.
  2. 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
  3. The backend fixes up some pointers and initializes itself for running
  4. The backend starts executing your code
  5. 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

new topic     » goto parent     » topic index » view message » categorize

22. Re: same problem in v4 as previous editions

useless said...
mattlewis said...

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

new topic     » goto parent     » topic index » view message » categorize

23. Re: same problem in v4 as previous editions

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

new topic     » goto parent     » topic index » view message » categorize

24. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

25. Re: same problem in v4 as previous editions

mattlewis said...

<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

new topic     » goto parent     » topic index » view message » categorize

26. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

27. Re: same problem in v4 as previous editions

mattlewis said...

<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

new topic     » goto parent     » topic index » view message » categorize

28. Re: same problem in v4 as previous editions

useless said...

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) 
useless said...

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

new topic     » goto parent     » topic index » view message » categorize

29. Re: same problem in v4 as previous editions

mattlewis said...
useless said...

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) 
useless said...

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

new topic     » goto parent     » topic index » view message » categorize

30. Re: same problem in v4 as previous editions

useless said...

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

new topic     » goto parent     » topic index » view message » categorize

31. Re: same problem in v4 as previous editions

mattlewis said...
useless said...

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

new topic     » goto parent     » topic index » view message » categorize

32. Re: same problem in v4 as previous editions

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.

new topic     » goto parent     » topic index » view message » categorize

33. Re: same problem in v4 as previous editions

DerekParnell said...

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu