26 replies to this topic

[Lyqyd]

Yesurbius, on 11 April 2013 - 08:25 PM, said:

But I realized a few things. First off .. I was thinking that when we are calling resume - we are calling the function itself... Not the case ... we are restarting the execution of the thread within the function - so the parameters of the function don't matter at all to resuming...

I... what? Have you been reading my posts? I said explicitly that the first time we call resume on a newly created coroutine, the parameters will be passed in as the initial parameters to the function. How much of what I've been writing have you been ignoring. No wonder I've been having to repeat myself.

[JokerRH]

Lyqyd, on 12 April 2013 - 05:35 AM, said:

Yesurbius, on 11 April 2013 - 08:25 PM, said:

But I realized a few things. First off .. I was thinking that when we are calling resume - we are calling the function itself... Not the case ... we are restarting the execution of the thread within the function - so the parameters of the function don't matter at all to resuming...

I... what? Have you been reading my posts? I said explicitly that the first time we call resume on a newly created coroutine, the parameters will be passed in as the initial parameters to the function. How much of what I've been writing have you been ignoring. No wonder I've been having to repeat myself.

Having a bad day?
But Yesurbius is right. The first resume will start the function but any following one will resume inside of the function, right were it yielded

[Lyqyd]

He's implying that the function cannot be provided its initial parameters.

[Yesurbius]

Actually I was implying that given the way the event system is set up - you don't need to pass parameters in to the coroutine via the resume - you can pass it in to the coroutine via queueEvent (assuming you are setting your coroutine up to respond to events)

As for reading your posts - I can assure you I am reading them multiple times . I appreciate the time you are spending trying to answer my questions - it is far more than I expected to receive. I have gotten different pieces mixed up in my head at times however .. For example - we were using the count function as an example and I kind of thought that coroutines would be returning values everytime they yield. While its true that they can .. it was complicating the issue .. that's why I went back to the original example .. which actually has a need for a dedicated event system.

As for my code - does it look like I finally got the concept or is it also wrong? The code isn't working but I'm hoping its syntax error or a bug - and not my design.

[Lyqyd]

It looks like it should mostly work. I'm not really sure what you've got the assert() call in there for, though. The design looks much better than previous iterations. Your tablify function can be shortened. This should be approximately equivalent:

function tablify(strSeq)
    local retValue = {}
    for str in string.gmatch(strSeq, "%S+") do
        table.insert(retValue, str)
    end
    return retValue
end

Try removing the assert() line and see what you get.

[Yesurbius]

Well - I think its safe to say I have it figured out. My program is working flawlessly, even with the sleep calls in the coroutines (which was causing issues before). I also managed to remove the tablify altogether and streamline the code a tad.

Note I use the assert(param1,param2)as shorthand for writing if <param1> == false then error(param2) end

When I get some time I'll modify my original program in this style. This was the first turtle program I wanted to make, to learn coroutines. My real project is a turtle autorun to upload arbitrary programs to the turtle... which I think I am in a better position to tackle now.

Thanks for the help,

function main(cmds)

  local routines = {}
  local eventdata = {}
  local filter = {}
  local status
  local n

  routines[1] = coroutine.create(go)
  routines[2] = coroutine.create(fuelManager)

  while true do
	for i,r in ipairs(routines) do
	  if filter[r] == nil or filter[r] == eventdata[1] or eventdata[1] == "terminate" then
		status, param = coroutine.resume(r, unpack(eventdata))
		assert(status,paraam)
		filter[r] = param
		if coroutine.status(r) == "dead" then
		  return i
		end
	  end
	end

	for i,r in ipairs(routines) do
	  if coroutine.status(r) == "dead" then
		return i
	  end
	end

	os.queueEvent("docmds", unpack(cmds))
	eventdata = { coroutine.yield() }
  end

end

function go()
  local tcmds = { }
  tcmds = { coroutine.yield("docmds") }
  local eventID = tcmds[1]
  table.remove(tcmds,1)
  if eventID == "docmds" then
	for i,v in ipairs(tcmds) do
	   print(v)
	   sleep(1)
	end
  end
end

function fuelManager()
  FuelOnHand = 40
  while FuelOnHand > 10 do
	FuelOnHand = FuelOnHand - 5
	print("Fuel: " .. FuelOnHand)
	sleep(1)
  end
end

local targs = { ... }
local func = ""
local i = 0
local func = main(targs)

if func == 1 then
  print("Commands Completed")
elseif func == 2 then
  print("Out of Gas")
else
  print("Not sure what happened ... " .. func)
end

[theoriginalbit]

Yesurbius, on 12 April 2013 - 06:11 PM, said:

Note I use the assert(param1,param2)as shorthand for writing if <param1> == false then error(param2) end

That is fine, it is the correct usage of assert, to replace

if not <param1> then error(<param2>) end

You may be interested in my custom assert that I posted here and describe in more detail in my tutorial on handling and creating errors here.