Suggestion

[Wilker-uwu]

This mod is awesome, but the only problem with this mod is the programming.

The programming of OpenComputers is even harder than the ComputerCraft mod. This video explains why https://www.youtube.com/watch?v=Dqyh-fT__sg

Java could be easier to understand...

[fnuecke]

Uh, thanks, I guess?

If you're trying to say it needs more code in OC to get something done than in CC, then I strongly disagree with that generalization. There may be some cases where that's true, but the reverse can be true as well. The code in the description you posted doesn't even do the same thing in the two different "versions". To be frank, that code is kinda dumb anyway. It's almost like it's being deliberately obtuse by using coroutines where it's completely pointless. A cleaner, less shit, functionally identical, yet easier to understand version would be

local component = require("component")
os.sleep(2)
for address in component.list("note_block") do
  component.proxy(address).trigger()
end

The video's poster's issue I'm guessing is the slight delay. That's because the call must be made in a synchronized fashion, since it's a world interaction. Either CC has special code in place for this, or it's calling it from the worker thread, which is... actually kinda dangerous, since that can easily lead to ConcurrentModificationExceptions (by that code triggering a chunk load when accessing the noteblock tile entity for example).

As for Java being easier to understand, that is highly subjective. I'd argue that very much depends on how the code is written in either Java, Lua or any other language.

[gjgfuj]

I believe cc calls things from the worker thread.

On Wed, 11 Nov 2015 6:43 am fnuecke notifications@github.com wrote:

Uh, thanks, I guess?

If you're trying to say it needs more code in OC to get something done than in CC, then I strongly disagree with that generalization. There may be some cases where that's true, but the reverse can be true as well. The code in the description you posted doesn't even do the same thing in the two different "versions". To be frank, that code is kinda dumb anyway. It's almost like it's being deliberately obtuse by using coroutines where it's completely pointless. A cleaner, less shit, functionally identical, yet easier to understand version would be

local component = require("component") os.sleep(2) for address in component.list("note_block") do component.proxy(address).trigger() end

The video's poster's issue I'm guessing is the slight delay. That's because the call must be made in a synchronized fashion, since it's a world interaction. Either CC has special code in place for this, or it's calling it from the worker thread, which is... actually kinda dangerous, since that can easily lead to ConcurrentModificationExceptions (by that code triggering a chunk load when accessing the noteblock tile entity for example).

As for Java being easier to understand, that is highly subjective. I'd argue that very much depends on how the code is written in either Java, Lua or any other language.

— Reply to this email directly or view it on GitHub https://github.com/MightyPirates/OpenComputers/issues/1521#issuecomment-155544929 .

[natedogith1]

I don't know what CC does, but the noteblocks aren't CC, they're OpenPeripherals. And they have a task queue sort of thing, when you call a method the task gets added to the queue and the computer yields. However, this is CC, where there's only user yields (unlike OC's sysyields), so you can catch the OpenPeripheral yield and call another world-interacting method.

[fnuecke]

Well, in that case it's an issue on the OP side, really, since then those could just be direct calls :P (And this must be explicit integration or something on that end, since the generic CC peripheral driver in OC always does direct calls).