Sheet worker and the API window

I am getting this in the API bos: "Loading 0 translation strings to worker..." "SyntaxError: Unexpected string" "SyntaxError: Unexpected string\n at eval (<anonymous>)\n at messageHandler (evalmachine.<anonymous>:284:6)\n at process.<anonymous> (/home/node/d20-api-server/node_modules/tiny-worker/lib/worker.js:60:55)\n at emitTwo (events.js:106:13)\n at process.emit (events.js:194:7)\n at process.nextTick (internal/child_process.js:766:12)\n at _combinedTickCallback (internal/process/next_tick.js:73:7)\n at process._tickCallback (internal/process/next_tick.js:104:9)" Any way of knowing what I broke?

Aside from the possibility of a bug, if you're getting API window messages, it's either a Script or a Sheet Worker. If you have no scripts running, try removing all the sheet workers (temporarily) from your sheet and see if the message goes away. If it does, add them back in in batches till you can find the one which is causing an issue.

You've got invalid code. Based on the order of logs, probably in your sheetworkers but possibly in an API script. Copy your code and run it through the closure compiler . Based on your error stack, it looks like it's from a function called emitTwo, although from that stack it's also possible that's a Roll20 function.

I'm not sure if Scott C is talking about something like this (i.e. I don't know what a closure compiler is), but I use this to help me find errors in my JS:&nbsp;<a href="http://esprima.org/demo/validate.html" rel="nofollow">http://esprima.org/demo/validate.html</a>

Heh, pretty much what the closure compiler is. It's just the one I use. Although on rereading the error stack, I'm not sure a code validator will find the issue since it's apparently something being thrown at eval that eval doesn't understand.

Scott C. said: Heh, pretty much what the closure compiler is. It's just the one I use. Although on rereading the error stack, I'm not sure a code validator will find the issue since it's apparently something being thrown at eval that eval doesn't understand. I think this eval is the API trying to evaluate the sheet worker code (which has a syntax error).

Yeah, kinda figured that what it was, but I had a lot more sheet workers than I wanted to sort through. So I have started a "removed what I just touched and add it back in one part at a time until it stops working again" process.&nbsp; Which is frustrating. Who got me into coding, in the first place?&nbsp;

The best way to do this check CPP is to go by halves. Add in half the sheet workers. If nothing breaks, add in half the workers that remain. Keep doing this till something breaks. Once something breaks, remove half the sheet workers you just added. If nothing breaks, keep removing half till something breaks. By repeating this process, you get to the faulty sheet worker pretty quickly. When you see a break, you always know it was in the last set of sheet workers you fiddled with, and can keep narrowing down till you find it. It works if there are multiple problematic sheet workers too, since you are still always narrowing down the group of untested or tested-but-failing workers to smaller and smaller groups.

GiGs said: The best way to do this check CPP is to go by halves. Add in half the sheet workers. If nothing breaks, add in half the workers that remain. Keep doing this till something breaks. Once something breaks, remove half the sheet workers you just added. If nothing breaks, keep removing half till something breaks. By repeating this process, you get to the faulty sheet worker pretty quickly. When you see a break, you always know it was in the last set of sheet workers you fiddled with, and can keep narrowing down till you find it. It works if there are multiple problematic sheet workers too, since you are still always narrowing down the group of untested or tested-but-failing workers to smaller and smaller groups. Should run it through a compiler like closure that I linked or the validate that Finderski linked as that will find a bunch of things that can throw syntax errors, then you don't need to do all the crazy add/remove/add/remove.

Agreed, but if you aren't rigorous about syntax, tabs/spacing, etc., closure compilers can throw up a lot of spurious errors that people who aren't comfortable with javascript find offputting and intimidating. CPP said he was taking the long road, I just provided a tip to speed it up.

Found the problem.&nbsp; Thanks all.&nbsp;&nbsp; It was a comma that got lost.&nbsp; Comma has been taken out behind the shack and shot, and its corpse is displayed at the begining of the code as a lesson to all other forms of punctuation.&nbsp;

Ah, if only that actually worked to get all the other punctuation to march in lockstep. Not sure how many times I've had syntax errors because I used a colon instead of a semi-colon or what not. Glad you got it fixed CPP.

GiGs said: Agreed, but if you aren't rigorous about syntax, tabs/spacing, etc., closure compilers can throw up a lot of spurious errors that people who aren't comfortable with javascript find offputting and intimidating. CPP said he was taking the long road, I just provided a tip to speed it up. The great thing about the closure compiler I linked is it doesn't really care about spaces or formatting. It just looks at the code itself (for lack of a better term). That, or I'm way more rigorous about my code formatting than I think I am.

Scott C. said: GiGs said: Agreed, but if you aren't rigorous about syntax, tabs/spacing, etc., closure compilers can throw up a lot of spurious errors that people who aren't comfortable with javascript find offputting and intimidating. CPP said he was taking the long road, I just provided a tip to speed it up. The great thing about the closure compiler I linked is it doesn't really care about spaces or formatting. It just looks at the code itself (for lack of a better term). That, or I'm way more rigorous about my code formatting than I think I am. Yeah, the one I linked to also ignores style and formatting and looks strictly at syntax And, agree with Scott, glad you got it sorted, CPP.

Scott C. said: GiGs said: Agreed, but if you aren't rigorous about syntax, tabs/spacing, etc., closure compilers can throw up a lot of spurious errors that people who aren't comfortable with javascript find offputting and intimidating. CPP said he was taking the long road, I just provided a tip to speed it up. The great thing about the closure compiler I linked is it doesn't really care about spaces or formatting. It just looks at the code itself (for lack of a better term). That, or I'm way more rigorous about my code formatting than I think I am. Your link doesnt work for me, Scott. Can you post it so I can check it out. I've used yours Finderski, and like it. I have it bookmarked :)

Huh, must not have grabbed the whole thing. Here's the address: <a href="https://closure-compiler.appspot.com/home" rel="nofollow">https://closure-compiler.appspot.com/home</a>