Shuffled lines in uploaded lua code

[cmatei]

I am using the http://chilipeppr.com/esp32 workspace. Uploading the code in the 'intended' attached image, then clicking 'Capture the contents of the file and open it in the LUA editor' produces the 'result'. It seems the upload shuffles the lines in the file.

It seems the reshuffle is particularly sensitive to "node.restart()", other code seems to go in fine. The only occurence of node.restart() in the workspace code seems to be as an event handler for the reset button, I can't spot any other magic related to it.

After spending quite a few hours trying to figure out why the device resets continuosly, this is amusing :))

Intended:

Result:

[chilipeppr]

The file upload in ChiliPeppr works by sending print() statements to an open file. The reverse process works by printing to the console and the local browser Javascript captures it by looking for a start and end string sequence. It's not a perfect approach and seems you may have found a bug. I tend to just not use the icon you're seeing the bug with. Instead I just always open the file from localStorage and upload. With respect to your code crashing, by setting timer = null in line 27, your 1 second later callback would not have a timer in memory anymore. I think you'll get a crash.

…

On Mon, Jan 13, 2020 at 6:10 AM Matei Conovici ***@***.***> wrote: I am using the http://chilipeppr.com/esp32 workspace. Uploading the code in the 'intended' attached image, then clicking 'Capture the contents of the file and open it in the LUA editor' produces the 'result'. It seems the upload shuffles the lines in the file. It seems the reshuffle is particularly sensitive to "node.restart()", other code seems to go in fine. The only occurence of node.restart() in the workspace code seems to be as an event handler for the reset button, I can't spot any other magic related to it. After spending quite a few hours trying to figure out why the device resets continuosly, this is amusing :)) Intended: [image: intended] <https://user-images.githubusercontent.com/181390/72261989-a6962d00-361e-11ea-8b64-a2ba9c49bb0a.jpg> Result: [image: result] <https://user-images.githubusercontent.com/181390/72261637-df81d200-361d-11ea-9034-30e88c79c3d1.jpg> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AB4J23M2PIJ7FVL6NPI4N3TQ5RY5FA5CNFSM4KGCZ2L2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IFYMQWA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4J23JETBM7ZUGIYT2MF3TQ5RY5FANCNFSM4KGCZ2LQ> .

[cmatei]

The problem is not with editing the fle back, it's rather that it gets garbled on upload. The culprit seems to be in bufferflow_nodemcu.go actually, in serial-port-json-server. That's looking for the node.restart() sequence in the buffer, presumably to handle reset.

[chilipeppr]

Oh, yes, you're right. That buffer does specifically look for that string to reset the buffering mechanism. Sadly I couldn't find an easy way around that. The problem is that you can't upload too fast over the serial port or you overflow the USB chip on your ESP board, so you have to watch for responses to indicate your serial data is processed. That can get clogged, thus you have to know when to unclog which is looking for the node.restart() sequence. I guess I've never run into this problem before because I've never put that in my code. A better way for ChiliPeppr to handle this would be to upload this code via a binary sequence instead of as strings.

…

On Mon, Jan 13, 2020 at 8:20 AM Matei Conovici ***@***.***> wrote: The problem is not with editing the fle back, it's rather that it gets garbled on upload. The culprit seems to be in bufferflow_nodemcu.go actually, in serial-port-json-server. That's looking for the node.restart() sequence in the buffer, presumably to handle reset. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AB4J23P64FLIMT2AEPWEC53Q5SID5A5CNFSM4KGCZ2L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIZKSPY#issuecomment-573745471>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4J23PY2IAMCU234333ZZDQ5SID5ANCNFSM4KGCZ2LQ> .

[chilipeppr]

It's a lame idea but you could set a new local variable to node and then call restart from that variable name to bypass the buffer reset string

…

On Mon, Jan 13, 2020, 8:25 AM John Lauer ***@***.***> wrote: Oh, yes, you're right. That buffer does specifically look for that string to reset the buffering mechanism. Sadly I couldn't find an easy way around that. The problem is that you can't upload too fast over the serial port or you overflow the USB chip on your ESP board, so you have to watch for responses to indicate your serial data is processed. That can get clogged, thus you have to know when to unclog which is looking for the node.restart() sequence. I guess I've never run into this problem before because I've never put that in my code. A better way for ChiliPeppr to handle this would be to upload this code via a binary sequence instead of as strings. On Mon, Jan 13, 2020 at 8:20 AM Matei Conovici ***@***.***> wrote: > The problem is not with editing the fle back, it's rather that it gets > garbled on upload. The culprit seems to be in bufferflow_nodemcu.go > actually, in serial-port-json-server. That's looking for the node.restart() > sequence in the buffer, presumably to handle reset. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#3?email_source=notifications&email_token=AB4J23P64FLIMT2AEPWEC53Q5SID5A5CNFSM4KGCZ2L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIZKSPY#issuecomment-573745471>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AB4J23PY2IAMCU234333ZZDQ5SID5ANCNFSM4KGCZ2LQ> > . >

[cmatei]

That was my workaround as well, thanks.