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

Thaumic Tinker and co-routines getAspects issue

Started by BikerEleven, 15 June 2014 - 11:49 PM
BikerEleven #1
Posted 16 June 2014 - 01:49 AM
I was building an aspect refilling for thaumcraft using Thaumic Tinkers CC integration but discovered that the function getAspects() from tilejar peripherals causes the current co-routine to yield. That is a major issue as i'm working inside a semi complex emulator / OS that I made. My thread dispatch correctly catches the coroutine and marks its as "sleeping" but when I try to wake it it just causes errors.

Can anyone think of a way around this with computercraft or should I bring up the issue over on the Thaumic Tinker end?

A bit of test code I wrote to track down the issue to coroutines

names = peripheral.getNames();
for _,v in pairs(names) do
	if v:find("tilejar") then
		print("herp");
		print(peripheral.call(v, "getAspects"));
		print("derp");
	end
end

function derp()
	names = peripheral.getNames();
	for _,v in pairs(names) do
		if v:find("tilejar") then
			print("herp");
			print(peripheral.call(v, "getAspects"));
			print("derp");
		end
	end
end
cor = coroutine.create(derp);
print(coroutine.resume(cor));
sleep(1);
print(coroutine.resume(cor));

Results:

herp
Ignis
derp
herp
trueop_tick_sync
falsestartup:18: 1
theoriginalbit #2
Posted 16 June 2014 - 03:41 AM
well in the derp function you don't have any kind of infinite loop, nor are you yielding in the for loop, this means that the entire function will run before it gets to your sleep(1) … inherently this means that when you go to resume the coroutine a second time it is already dead.

in any case it seems that you're unfamiliar with coroutines, I suggest either using the parallel API or reading this tutorial to learn about coroutines.
BikerEleven #3
Posted 16 June 2014 - 06:06 AM
I know what i'm doing my little OS or whatever we call them has been working fine. "true op_tick_sync" are being returned from the co-routine. When I added
print(coroutine.status(cro));
above the sleep function it even prints "suspended". That just leaves me to believe the function from the peripheral is causing some sort of unexpected behavior because its being called from within a co-routine.
Edited on 16 June 2014 - 04:09 AM
theoriginalbit #4
Posted 16 June 2014 - 06:19 AM
… wait, that means that the peripheral is yielding, why are we yielding on getAspects, we shouldn't need to yield on that, I may need to take a look into that part of OpenP and fix that, someone may have set a variable wrong…

in any case you're still not handling the coroutine correctly. you must return the event data to the coroutine for it to resume, especially when its after specific events. there is a whole section written up on this in the tutorial I linked.
BikerEleven #5
Posted 16 June 2014 - 06:41 AM
Aha interesting I had not expected it to want data from the event queue but doing a quick work around in the test code,
print(coroutine.resume(cro, os.pullEvent()));
did the trick. As for my actual program I should be able to add a hook to my event dispatcher to deal with this special case while this gets looked into. And ya I apparently don't know how normal co-routines work my program has its own event dispatch system so i'm doing it the hard way, anyway thanks for the help.
–Edit–
Ya A quick little work around and a small bit of editing to how I wake co-routines fixed this issue in my actual program thanks.
Edited on 16 June 2014 - 04:50 AM
theoriginalbit #6
Posted 16 June 2014 - 07:21 AM
well you'd have other problems with anything that will ever yield, such as sleep, read, rednet.receive, any turtle function etc. I think the best solution here is to simply fix you coroutine implementation, then you won't have to make special cases, 'cause there are some peripherals that we add in OpenPeripheral that do need the yield.