Viewer SyntaxError Expected "\n", "\r\n"

[paul-english]

When trying to view a worksheet in the public viewer, I'm getting a console error.

Uncaught SyntaxError: Expected "\n", "\r\n" or any character but end of input found. 

http://viewer.gorilla-repl.org/view.html?source=github&user=log0ymxm&repo=gorilla-worksheets&path=src/matrix-factorization.clj#

[zerko]

Can you try adding line break at end of file?

[zerko]

Also, does it work fine when you loading it in gorilla-repl itself?

[JonyEpsilon]

This is odd - it loads fine in Gorilla REPL itself, but the online viewer and the REPL use exactly the same parser code! So something must be happening to the line endings when the file is encoded/decoded to get it from Github I guess.

I should check the diff between the raw file, and what Github serves up, but probably the right solution is to make the parser a bit more tolerant towards line-endings.

(@log0ymxm as a side-note, I'm on vacation at the moment, so sorry if I don't respond to your reports in a timely fashion (I notice you filed another) - thanks and keep 'em coming :-) I'll be back to full power next week.)

[paul-english]

Strange that it uses the same parser, and has this error. I can add the newline, but I have git & my editor automatically truncating that extra newline in my code files, as do others. So this is still an issue.

@JonyEpsilon Thanks for the work on this, I'm happy to contribute.

[paul-english]

Is the static viewer on github? I didn't see any entrypoints or repos for it.

[zerko]

There is some code https://github.com/JonyEpsilon/gorilla-repl/tree/develop/resources/public/js-viewer but i dont know how it served on viewer.gorilla-repl.org

[zerko]

As for original issue, seems like github sends line breaks as \n not as base64 encoded \n https://api.github.com/repos/log0ymxm/gorilla-worksheets/contents/src/matrix-factorization.clj

We can split/decode/join back, for example.

[JonyEpsilon]

So, I think I've gotten to the bottom of this! I think the line-endings are a bit of a red-herring ...

It looks like the problem is that the regex that was supposed to strip out non-base64 characters, was also stripping out /, which is a valid base64 character. That was corrupting the decoded worksheet, and the parser was choking on it - not on the final line ending.

The solution is to just strip out the line-breaks from the base64 string (which are just there to make it look pretty in an email) and nothing else.

[JonyEpsilon]

@log0ymxm Have re-deployed viewer with new code, seems to work now.

p.s. all of the viewer code is in the main gorilla REPL project. There's a very tiny project to serve it up on Heroku, which I haven't published yet.

[alexander-yakushev]

I am having the same problem again with this gist: https://gist.github.com/alexander-yakushev/3e0e5ceadf2570e8a7ea. The error appears when the last newline in the file is missing. I tried running the viewer locally and it also shows this Expected "\n" error. I tried adding "\n" to content in js-viewer/github.js in getFromGist function and it worked.

[JonyEpsilon]

I thought I'd made the parser tolerant to having the newline at the end stripped, but looking at the code I think I didn't do it right. That ties up with your observation that adding a newline to the end fixes the problem.

I'll have another crack at making the parser more tolerant, and hopefully get it right this time! As a workaround - if you want to be able to view the file in the viewer - you could edit the gist to add a newline at the end of the file.

[alexander-yakushev]

if you want to be able to view the file in the viewer - you could edit the gist to add a newline at the end of the file.

I did and it worked, the workaround works perfectly for me until the issue is fixed.

[paul-english]

The PEG seems to choke on certain types of Markdown with the same error. I can't seem to pinpoint what part of my Markdown is causing this issue at the moment, but will report if I figure out.

[JonyEpsilon]

Hmm, that's a bit worrying. If you do manage to isolate the problem that would be super-useful :-)

[ghost]

I think I found one of the things that kill the parser.

If you have a mathjax element over multiple lines, like:

@@
@@