unexpected EOF error for empty python files

[smacker]

Code from https://github.com/bblfsh/bblfshd/issues/264: /Users/smacker/tmp/srcd-all/apollo/apollo/init.py:unexpected EOF

not sure if it's a problem in driver or client or sdk.

[creachadair]

I tried to reproduce this in the driver:

$ docker exec -it srcd-cli-bblfshd touch /tmp/empty.py
$ docker exec -it srcd-cli-bblfshd bblfshctl parse --address=localhost:9432 /tmp/empty.py
Status: Ok
Elapsed: 15.2µs

That would suggest this is downstream of the driver—but if you include the --native flag it generates a JSON error, so I'm not sure this is the whole story.

@dennwc am I doing something wrong here?

[bzz]

@creachadair Interesting find with --native! For some reason was not able to reproduce it using bblfsh-cli.

To reproduce this on latest master, similar to https://github.com/bblfsh/bblfshd/issues/266#issuecomment-474314324 do:

wget https://raw.githubusercontent.com/src-d/apollo/master/apollo/__init__.py

bblfsh-cli __init__.py
 couldn't parse __init__.py: unexpected EOF
bblfsh-cli -m annotated __init__.py
 couldn't parse __init__.py: unexpected EOF
bblfsh-cli -m native __init__.py
 couldn't parse __init__.py: unexpected EOF

logs

[2019-03-19T12:33:30+01:00] DEBUG empty request received, returning empty UAST
[2019-03-19T12:33:30+01:00] DEBUG request processed content 0 bytes elapsed=426.484µs filename=__init__.py
[2019-03-19T12:33:39+01:00] DEBUG empty request received, returning empty UAST
[2019-03-19T12:33:39+01:00] DEBUG request processed content 0 bytes elapsed=336.058µs filename=__init__.py
[2019-03-19T12:33:44+01:00] DEBUG empty request received, returning empty UAST
[2019-03-19T12:33:44+01:00] DEBUG request processed content 0 bytes elapsed=217.685µs filename=__init__.py

While running only on latest python driver:

docker run --rm -it -p 9432:9432 bblfsh/python-driver:v2.8.1
bblfsh-cli __init__.py

syntax error: Traceback (most recent call last):
  File "/opt/driver/bin/.local/lib/python3.6/site-packages/python_driver/requestprocessor.py", line 177, in process_request
    if failed:
UnboundLocalError: local variable 'failed' referenced before assignment

If no objections, going to move it to python-driver and handle it from there as part of the next release scope https://github.com/bblfsh/python-driver/milestone/1

[creachadair]

For some reason was not able to reproduce it using bblfsh-cli.

Hmm. I would have expected the Go client to use the same logic as bblfshctl. Does bblfsh-cli access a different RPC endpoint than bblfshctl uses?

[bzz]

For some reason was not able to reproduce it using bblfsh-cli.

Hmm. I would have expected the Go client to use the same logic as bblfshctl. Does bblfsh-cli access a different RPC endpoint than bblfshctl uses?

Indeed, it seems like bblfshctl uses UASTv1 protocol, while bblfsh-cli uses UASTv2.

[creachadair]

Indeed, it seems like bblfshctl uses UASTv1 protocol, while bblfsh-cli uses UASTv2.

Was this intentional, or did we just never get around to bringing them in sync? This could explain several odd differences I've encountered when trying to reproduce bug reports.

[bzz]

Indeed, it seems like bblfshctl uses UASTv1 protocol, while bblfsh-cli uses UASTv2.

Was this intentional, or did we just never get around to bringing them in sync? This could explain several odd differences I've encountered when trying to reproduce bug reports.

I think the latter one - nobody uses it, so we never got around to syncing them properly.

[dennwc]

We still suggest using bblfshctl in the documentation, so we should definitely sync it. I'll take care of it.