Testing if current computer is Advanced while loading an API?

I am loading an API (os.loadAPI) and I am doing if (shell.openTab == nil to test if the computer is advanced, but for some reason shell is nil so I cannot test it that way. Is there test if the computer is advanced while loading an API otherwise (term.isColor is not reliable since term can be a monitor and not the computer itself)?

the reason shell is nil is because shell is not in the global (_G) table, its given to the program when running. However this being said term.isColor is the best way of checking if the terminal is Advanced. Even your method of checking the shell.openTab could — depending on your answer to the below question — present the same unreliability as you think term will.
What is your use case where you want to know if the computer is advanced and not just what it is outputting to?

theoriginalbit, on 02 April 2014 - 02:27 PM said:

What is your use case where you want to know if the computer is advanced and not just what it is outputting to?

I guess I can use term.isColor because at this point there is no change for to have been redirected. As for what I am doing, the API is for shared code for a turtle/computer to use for a program (turtle does the program and computer is a receiver). I need to know if the turtle/computer is advanced so I can set a flag to open the problem in a new tab if needed so I can easy multitask on the computer with it.

calling the native term.isColor should always result in whatever the terminal is, regardless of any redirection. Although i haven't messed around with 1.6 yet, i know there's some changes to the whole native thing there, so if you're running 1.6 it might not work as intended.

if term.native.isColor() then

Easiest way to see if the system supports tabs is to check whether the multishell API is accessible:

if multishell then ...

CometWolf, on 02 April 2014 - 02:51 PM said:

calling the native term.isColor should always result in whatever the terminal is, regardless of any redirection. Although i haven't messed around with 1.6 yet, i know there's some changes to the whole native thing there, so if you're running 1.6 it might not work as intended.

if term.native.isColor() then

i think its now

if term.native().isColor() then

CometWolf, on 02 April 2014 - 02:51 PM said:

calling the native term.isColor should always result in whatever the terminal is, regardless of any redirection.

Not true, people can override term.native as well, meaning you cannot guarantee that it will be the terminal. Just like you cannot guarantee that term.current will return a terminal object as people could redirect from a monitor to another monitor making the previous redirect being first said monitor.

I would say here that what Bomb Bloke said should work the easiest, however depending on where you plan on opening said new tab you may want to give a reference of shell to the api. example

main code

os.loadAPI("api")
api.setShell(shell)

api code (file called 'api')

local shell --# put this line at the top of your file

function setShell( s ) --# doesn't matter where this goes, as long as its after the above line
  shell = s
end

from this point onwards you can use the shell functions and variables in your api

wojbie, on 02 April 2014 - 03:03 PM said:

i think its now

if term.native().isColor() then

yes but using term.native() is now highly frowned upon.

theoriginalbit, on 02 April 2014 - 03:03 PM said:

Not true, people can override term.native as well, meaning you cannot guarantee that it will be the terminal. Just like you cannot guarantee that term.current will return a terminal object as people could redirect from a monitor to another monitor making the previous redirect being first said monitor.

Well obviously you can override the native term table, like you can with anything in computercraft, but if you're just using term.redirect you aren't doing that. It's the eqiuvalent of me saying you shouldn't use os.loadAPI cause someone might override it to crash their computer.

wojbie, on 02 April 2014 - 03:03 PM said:

yes but using term.native() is now highly frowned upon.

Why exactly is it frowned upon? IF you need to know what kind of graphics card you have installed do you ask windows/linux or look inside the case?

Bomb Bloke, on 02 April 2014 - 02:59 PM said:

if multishell then ...

This worked. Thanks

I can make a new post (and I will later if there is not a reply by the time I get home in like ~2 hours), but I am having another problem. How to I access variables from inside and outside of an API. I am currently doing it like below which does not work:

Outside API:

os.loadAPI("api")
api.init_blah()
print(api.blah) -- is still nil here

Inside API:

blah = nil
function init_blah()
    blah = {}
    blah["derp"] = "herp"
end

Lua is really weird without it handles these APIs and OO design.

I've never actually run into that issue when dealing with my own APIs, however os.loadAPI isn't really suited for OOP. Personally i use a modified loadfile that allowes me to set the environment it runs in, but the default loadfile works fine for most cases really.

local object
object = {
  new = function()
	--blahblah
  end
}
return object

object = loadfile("/object")()

What I am using the API functionality for (currently) to abstract out shared code, so loadfile will probably work a lot better. I am working on my complex branch mining program and it has turtle code and computer code as a receiver to keep track of the turtle. I really like the "Don't Repeat Yourself" paradigm, so if I can extract the program into three files and only need one on the turtle, one on the computer and a shared on both, then I like that.

wojbie, on 02 April 2014 - 03:13 PM said:

wojbie, on 02 April 2014 - 03:03 PM said:

yes but using term.native() is now highly frowned upon.

Why exactly is it frowned upon? IF you need to know what kind of graphics card you have installed do you ask windows/linux or look inside the case?

lol quote derp. The reason dan suggests to never use it now is due to the way the redirect stack works. there are very few use cases where you'd use term.native anymore. Almost every existing reason you'd now use term.current for.

angellus, on 02 April 2014 - 09:01 PM said:

Bomb Bloke, on 02 April 2014 - 02:59 PM said:

if multishell then ...

This worked. Thanks

I can make a new post (and I will later if there is not a reply by the time I get home in like ~2 hours), but I am having another problem. How to I access variables from inside and outside of an API. I am currently doing it like below which does not work:

Outside API:

os.loadAPI("api")
api.init_blah()
print(api.blah) -- is still nil here

Inside API:

blah = nil
function init_blah()
	blah = {}
	blah["derp"] = "herp"
end

Lua is really weird without it handles these APIs and OO design.

Inside API: api.blah = {}.

It's weird, but it works.

Lyqyd, on 02 April 2014 - 11:45 PM said:

Inside API: api.blah = {}.

It's weird, but it works.

I found this tutorial: http://wiki.roblox.com/index.php/Object-Oriented_Programming

It is really helpful. Thanks for the help though. I think I understand how Lua works now with all this. It is a lot like JavaScript (which I hated).