48 posts
Posted 01 January 2014 - 02:30 PM
Previously, all the APIs in /rom/apis could be assumed to be safe to run without any kind of pcall trickery to make sure it's a valid, error-free, file. With the invention of resource pack support in 1.55, this is no longer a completely sound assumption. I suggest adding something around it so that people adding new APIs, or existing APIs even which have been converted into resource pack form to be unable to cause a doomed blank screen on the computer / turtle's terminal.
I'd suggest just adding a pcall that prints out "Failed to auto-load API <api-name>: <error-here>" or similar if it fails. I'm not entirely sure how that would effect the bios and all, but It's worth some effort to look into.
1522 posts
Location
The Netherlands
Posted 01 January 2014 - 04:58 PM
its useless to add more safety to the bios imo.
- You get notified by os.loadAPI that your API has compile errors
- The main loop where the BIOS uses external API's, is already being pcalled
- The BIOS only uses 1 external API
48 posts
Posted 01 January 2014 - 05:32 PM
APIs in /rom/apis will be automatically loaded. If they throw up an error (say, from an assert() call) they will silently break the computer or turtle. It's been awhile since I looked at the bios, but I believe it's not doing anything to safety check when it's loading the APIs from there, which is what was causing this problem for a user who joined #computercraft earlier today.
1522 posts
Location
The Netherlands
Posted 01 January 2014 - 07:51 PM
actually you are right, but unspecific.
The problem is in os.loadAPI, which apparantly doesnt check for runtime errors when it runs the API function.
Suggestion how to fix os.loadAPI - 6 line fix
local tAPIsLoading = {}
function os.loadAPI( _sPath )
local sName = fs.getName( _sPath )
if tAPIsLoading[sName] == true then
printError( "API "..sName.." is already being loaded" )
return false
end
tAPIsLoading[sName] = true
local tEnv = {}
setmetatable( tEnv, { __index = _G } )
local fnAPI, err = loadfile( _sPath )
if fnAPI then
setfenv( fnAPI, tEnv )
local ok, runtimeErr = pcall( fnAPI )
if not ok then
printError( runtimeErr )
tAPIsLoading[sName] = nil
return false
end
else
printError( err )
tAPIsLoading[sName] = nil
return false
end
local tAPI = {}
for k,v in pairs( tEnv ) do
tAPI[k] = v
end
_G[sName] = tAPI
tAPIsLoading[sName] = nil
return true
end
Edited on 01 January 2014 - 06:52 PM
2151 posts
Location
Auckland, New Zealand
Posted 01 January 2014 - 09:38 PM
I can see the merit in this, but I'd presume (hope!) that people test their programs extensively before adding them to a ROM pack.
8543 posts
Posted 01 January 2014 - 10:06 PM
I don't see how the problem is any different now than it was previously, so I'm not sure why this is necessary. It certainly wouldn't hurt to ensure that the startup sequence is somewhat protected, but there aren't any recent changes that affect the booting sequence.
1111 posts
Location
Portland OR
Posted 23 January 2014 - 02:50 AM
I have recently ran into this problem. It would be nice to have CC handle these types of errors differently. When you add a custom API to /rom/apis with a resource pack and it fails to load you basically end up with all of your computers bricked until you remove the API or fix the issue.
It would be nice to have it error and give you a message and just not load the API instead of getting a bricked computer with a blank screen that allows you to do absolutely nothing like you do now.
I had to move my API into the programs folder and manually load it using a modified startup file and os.loadAPI() in order to get it working. Not difficult to do by any means, just less then ideal.
686 posts
Posted 26 January 2014 - 01:35 AM
So don't add broken APIs to rom? Simple?
2151 posts
Location
Auckland, New Zealand
Posted 26 January 2014 - 03:47 AM
So don't add broken APIs to rom? Simple?
I know right? I just can't see thee need. Test your APIs on a computer first, simple.
1111 posts
Location
Portland OR
Posted 26 January 2014 - 04:25 AM
I've had my API's work fine on the computer then break when added to the ROM. Something about it is different and they do not load the same.
To Duplicate download MysticT's sync API from Here:
http://www.computercraft.info/forums2/index.php?/topic/4255-sync-api-terminal-monitor-synchronization/page__hl__sync__fromsearch__1Manually load it and see it works just fine.
Now put it in ROM via a resource pack and watch your comps brick.
Can't explain why, no error message.
A real computer would not do this. You would just get errors and have some features not functional.
Edited on 26 January 2014 - 03:31 AM