Computercrafts (or my) limits - ComputerCraft Forums (archive)

Jummit #1

Jummit's profile picture

327 posts

Location Julfander Squad Studio

Posted 20 March 2018 - 07:35 PM

I just wanted to ask if there are any cases where computercraft computers just shut down, freeze or in other ways behave different than you would expect if you see the code that was run. I had this a few times, the issue are things like

 table.serialize

or

 rednet.broadcast

Why is this?
(is this even computercrafts fault, or am I just doing something wrong? :unsure:/>)

I can't show the code with which it happens, sorry. I can't seem to reproduce the error.

Edited on 20 March 2018 - 06:37 PM

Purple #2

Purple's profile picture

102 posts

Location Alone in the dark, looking at the pretty lights with dreams of things I can not have.

Posted 20 March 2018 - 07:40 PM

How large are your tables? You could be trying to serialize something really huge and that just overloads the system. Same for broadcasting.

Jummit #3

Jummit's profile picture

327 posts

Location Julfander Squad Studio

Posted 20 March 2018 - 07:50 PM

Purple, on 20 March 2018 - 07:40 PM said:
How large are your tables? You could be trying to serialize something really huge and that just overloads the system. Same for broadcasting.

Thank you!
That could actually be the case! But how can I prevent that? Split the table into multiple ones, or splitting the broadcasted string into two?

Dave-ee Jones #4

Dave-ee Jones's profile picture

467 posts

Location Van Diemen's Land

Posted 20 March 2018 - 10:55 PM

You could send a subtable of the table.

For example:


local t_TOP = {
  t_BOT_1 = {
  },
  t_BOT_2 = {
  },
  t_BOT_3 = {
  }
}
for k,v in pairs(t_TOP) do
  rednet.broadcast(v)
  sleep(0.5)
end

(Apologies if there are minor syntax errors in the code, it's been a while since I last wrote Lua)

There could be problems with the broadcasting though. Because you're broadcasting something different every half second the computer that wants to receive it has to receive it and deal with each quite quickly. What you could do is have the receiving computer receive and parse the tables in parallel, though, which may help you.
E.g. Receive the next table while you're dealing with the first in parallel.

Also, if there is a large amount of subtables it would take a while to send a whole table.

This is just one suggestion and it may cause more errors than your first problem, though, depending on the rest of your program.

Do you have to send the whole table, or can you get away with sending parts of it and rebuild it on the other side?

SquidDev #5

SquidDev's profile picture

1426 posts

Location Does anyone put something serious here?

Posted 20 March 2018 - 11:10 PM

On a more general note, if you've got a bit of code which runs for a long time and doesn't call any of CC's Java-side functions (such as a peripheral call or writing to the terminal) then you won't get a "Too long without yielding" error - the computer will just shut down.

That being said, I am surprised that you've got tables which are that large - it might be worth checking that you haven't accidentally added some other information in there which isn't needed.

Bomb Bloke #6

Bomb Bloke's profile picture

7083 posts

Location Tasmania (AU)

Posted 21 March 2018 - 09:12 AM

Back in the day, if you rigged up a turtle with a "move around" coroutine running alongside a "use rednet" coroutine, ComputerCraft would break. I first signed up on these boards to complain about that (well, more in the hope that I was doing something wrong, but yeah).

It does sound like you're simply triggering yield protection, though.

EveryOS #7

EveryOS's profile picture

749 posts

Location BOO!!

Posted 21 March 2018 - 12:31 PM

Bomb Bloke, on 21 March 2018 - 09:12 AM said:
I first signed up on these boards to complain about that (well, more in the hope that I was doing something wrong, but yeah).

You're serious? I always thought you signed up because you knew dan200 or something.

Purple #8

Purple's profile picture

102 posts

Location Alone in the dark, looking at the pretty lights with dreams of things I can not have.

Posted 22 March 2018 - 01:33 PM

On a note related to this, I find it to be good practice to have a request-response system when broadcasting large amounts of data. As in, have the receiver request updates when it's ready to process them and the transmitter wait until a request until sending the next batch of files. Not only does it help with overloading it also lets you make the system easily expandable in the future to include multiple listeners on the request end.

It's basically how the HTTP protocol works.

Edited on 22 March 2018 - 12:34 PM

Gorzoid #9

Gorzoid's profile picture

44 posts

Posted 23 March 2018 - 09:32 AM

Something something hello I'd like to hear a TCP joke.

Purple #10

Purple's profile picture

102 posts

Location Alone in the dark, looking at the pretty lights with dreams of things I can not have.

Posted 23 March 2018 - 02:43 PM

Good catch. I said HTTP when I should have said TCP. Can not explain how that happened other than I derped.

Purple #11

Purple's profile picture

102 posts

Location Alone in the dark, looking at the pretty lights with dreams of things I can not have.

Posted 30 March 2018 - 01:09 PM

Speaking of TCP connections. I've just written up a small TCP client for rednet connections for my own personal use.
It supports tracking up to 100 connections (non paralel sadly, but it can track 100 different computers for ACK purposes), a client (single connection) and server (loop and respond to messages) system and the ability to redirect messages to functions of the users choice in a modular way. As in, you tell the TCP server what function to use to process received messages and it does the TCP part automatically and than sends the message on to your custom function for processing so that you don't have to mess with the TCP server code to get it to do your program logic.

Also, you can supply it with a function to handle non rednet input as well. So like say if you want to have the server shut down when you press T, you write a function to do that and supply it as a parameter to the TCP server call and when it detects a keypress your custom function will be called, detect if it's "T" and shut it down if that is true.

Would anyone be interested in me posting the code up here once I am done with light testing?