This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
crusti's profile picture

[1.48][SMP] Saved edits not acknowledged, old code run instead

Started by crusti, 09 January 2013 - 05:18 AM
crusti #1
Posted 09 January 2013 - 06:18 AM
Server is running Minecraft 1.4.6

I'm programming directly on a labeled turtle with the edit program provided.
The code file is named tmain and stored in a user-created folder called /user.
If I make a change in the file and save (or save several times) and then exit and run, it happens frequently that the old code runs instead. On one occasion I removed a print line, saved and ran the code and the line printed. Ran again and the line did not print.

Exiting the editor doesn't help.
Exiting the world doesn't help.

I'm running on an SMP server, and I'm not the admin so I have no access to any of the saved files.
I'll continue to evaluate how this happens or if it's consistent but if anyone has experienced this it would be helpful to know.

Thanks,
Crusti
Cloudy #2
Posted 09 January 2013 - 08:30 AM
I personally can't even see how that's possible. How are you running the program? Do you know anything about the server hardware or operating system?
Shnupbups #3
Posted 09 January 2013 - 08:30 AM
If it is an API, make sure to unload and reload it before using it again if you have made changes.

Else I'm not entirely sure what could be going on here…
Orwell #4
Posted 09 January 2013 - 08:36 AM
Are you sure that you don't pollute the environment? If you accidentally alter a built in function for example, then it could be that your code doesn't run consistently every time.
crusti #5
Posted 11 January 2013 - 05:41 PM
Thanks for the replies gentlefolk.

As far as I know, I haven't tampered with any known function. I don't know if the server had been rebooted but the admin claimed to have not had the problem I had with any of his CC programs. I don't know anything about the server OS or hardware, other than it's pretty beefed up.

The symptom changed to where I was guaranteed not to be running the most recent edit of the code, and often running multiple times would not run the most recent edit. So I got into the habit of making trivial changes, but then received "attempt to call nil" errors much of the time. After some trivial edits generally the code would run if it wasn't buggy.

Perhaps the real issue was the length of the code. The admin had a look at my "430 lines of crap" and noted that it took a long time to compile, and thus timing might have become an issue. He had little confidence in my program behaving as a properly-written program would. So perhaps there was a problem with timing, and running previously-compiled code while the newest code was yet uncompiled.(?)

It was at this time that I learned an api is a code library in lua and that I can offload functions and test procedures to libraries. Yay!
Further, the admin made available a means to get code from the web, so I can at least have copy and paste for writing less crappy code out of game.

I'll report back to say whether I'm still experiencing this issue after condensing into some smaller library files.

Again, thank you for your concern and helpful replies.
Heracles421 #6
Posted 11 January 2013 - 05:49 PM
I can firmly say that 430 lines of code shouldn't take more than a second to compile and run, I've ran codes with about 1400 lines of code and doesn't take more than 1 second to fully load. It MAY be the server's computer, but I don't think it really that bad
immibis #7
Posted 12 January 2013 - 12:23 AM
Upload the code from in-game ("pastebin put yourfilenamegoeshere") and post the link here, in case it's a problem with your code.
Velander #8
Posted 02 March 2013 - 07:07 AM
I am seeing the same behavior when I modify a program in TurtleScripts and then reload it before rerunning the program. The first time I run it it is using not only previous code, but the variables that are set by parameters have the same values that were used the last time the program was run. If I run the program a second time I sometimes get an error indicating concatenate with a null value, but then I run the program a third time and everything works with the new code and parameters.

Even if I don't change the program code at all, but just run it with different parameters, the program will print out the parameters that I ran it with, but then the variables that are assigned these values end up with the values that were used the last time the program was run. If I rerun it a couple more times then it finally has the correct variable values.

I will take my current complicated program and strip it down to a sample program to show what is happening and post examples.


I am running FTB v1.2.2.
Velander #9
Posted 08 March 2013 - 01:15 PM
I discovered that problems that I was seeing where the program was accessing values from the previous execution were caused because the variables that I was using as global were defined with the local option. Once I removed the local option from the global variables, and only left that option on the variables that are defined withing the functions, then I stopped having the problem with the program running with values that were left over from the last time the program was run. I don't understand why this was occurring, but it seems to have fixed the problem.

I will put together an example of the problem I was seeing and how it worked after the local option was removed when I have more time.
Cloudy #10
Posted 08 March 2013 - 08:20 PM
You've just established it is an error in your code, so no need to post example code.
Cranium #11
Posted 09 March 2013 - 06:48 AM
I discovered that problems that I was seeing where the program was accessing values from the previous execution were caused because the variables that I was using as global were defined with the local option. Once I removed the local option from the global variables, and only left that option on the variables that are defined withing the functions, then I stopped having the problem with the program running with values that were left over from the last time the program was run. I don't understand why this was occurring, but it seems to have fixed the problem.

I will put together an example of the problem I was seeing and how it worked after the local option was removed when I have more time.
That's why it is always good practice to make everything local unless you have a good reason not to.