For moderators: please close this thread
Hello everyone!
I went into strange situation with tables. The files that may be involved in this problem: bin/netOS bin/ttyManager, however other files in archive are needed to boot OS. It has to be on disk, or you have to change path in boot file.
When you boot netOS, after few startup messages it goes to screen like this:
netOS indev
TTY 1, PID 2
username1>
that is changing with this in period of 5 sec:
netOS indev
TTY 1, PID 3
username0>
the number after TTY is "term.id"(I use custom APIs) which is defined here:
bin/ttyManager
local function newTTY(stdin, stdout, _f, _api) --line 43
_G = getfenv()
local self = {}
self.active = false
local ttyStdin = task.nullin
local ttyStdout = {}
ttyStdout._x = 1
ttyStdout._y = 1
ttyStdout.id = #ttys --HERE line 51
ttyStdout._textColor = colors.white
ttyStdout._backColor = colors.black
ttyStdout._blink = true
ttyStdout._width, ttyStdout._height = stdout.getSize()
ttyStdout._buf = {} --line 56
....
local process = task.new("tty"..tostring((#ttys)+1), TTY, _api, ttyStdin, ttyStdout, (#ttys)+1, _f) --line 310
self.activate = function()
self.active = true
ttyStdout._repaint()
process.setStdout(ttyStdout)
process.setStdin(stdin)
stdout.setBackgroundColor(ttyStdout._backColor)
stdout.setTextColor(ttyStdout._textColor)
end
self.deactivate = function()
self.active = false
process.setStdin(ttyStdin)
process.setStdout(ttyStdout)
end
table.insert(ttys, self) --HERE this increments this number
return self
end --line 326
"stringed" here:
local function TTY(n, _f, PID) --line 31
local fnFile, err = loadfile( fs.combine(os.getPath(), "/bin/lua" ))
if fnFile then
--_G = getfenv() -- workaround of CC bug
local _api = _G
local tEnv = {}
setmetatable( tEnv, { __index = _api } )
setfenv( fnFile, tEnv )
end
login(os.version().."\n TTY "..tostring(term.id)..", PID="..tostring(PID), fnFile, PID) --HERE - passed as parameter to function
end --line 31
number after username("username#>") is THE SAME number, but displayed a bit later :
local function login(welcome, _f, PID) --line 8
os.addEventListener("key") -- #1
os.addEventListener("char") --#1
local _exit = false
while not _exit do
term.clear()
term.setCursorPos(1, 1)
term.print(welcome)
-- for n = 1, 3, 1 do
term.write("username"..tostring(term.id).."> ") --HERE
local username = term.read()
term.write("password"..tostring(term.id).."> ")
local password = term.read()
term.print("")
if os.login(username, password) then _exit = true break end
-- end
end --line 29
os.removeEventListener("key")
os.removeEventListener("char")
_f(PID)
end
#1 os.addEventListener(event) makes task listen to given event, also yields coroutine, so other can run
So these numbers should be the same, right?
more tests:
bin/ttyManager
function run(PID) -- #1 line 329
newTTY(task.stdin, task.stdout, login) --#2
newTTY(task.stdin, task.stdout, login) --#2
os.addEventListener("timer")
ttys[2].activate()
local test = true
local timer = os.startTimer(0) --#3
while true do
local e, p1 = os.pullEvent()
if e == "timer" and p1 == timer then
if test then
ttys[2].deactivate()
ttys[1].activate()
test = false
else
ttys[1].deactivate()
ttys[2].activate()
test = true
end
timer = os.startTimer(5)
end
end
end --line 356
#1 function run is ran bu OS as task
#2 task.stdin can be found in bin/netos line about 350 it basicly redirects user input events THIS WORKS
task.stdout can be found also in bin/net os about the same lines as above, basicly termAPI, but a little improved to os needs
#3 puts event immediately to queue, so (as of my calculations) the loop will loop right after "os.addEventListener("char")" of tty processes, so before rendering stuff, BUT
if you set it to for example 1 sec delay, so it will run after some rendering in login function(tty process)
what happens? … task with lower PID(the first created one) doesn't show anything! if you turn of
term.clear()
term.setCursorPos(1, 1)
in login function you can see, that instead of drawing in it's own console first tty draws on second's. BUT if you press ENTER on "empty" screen you can see that now it draws properly, because we changed "stdout"(termAPI) of this task in "activate" function, BUT we changed to to THE SAME as during creation, why is that?They shouldn't be interfering with ANY other task In dev version of OS I have about 15 different tasks ran from different sources and nothing like that happens, although stdout mechanism wasn't tested much, so can be buggy.
Please help me if you followed along, thanks for your help!
I hope you understand what i said ;)/>
[attachment=829:netOS.zip]