Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client-side compilation #4

Open
qsantos opened this issue Jul 26, 2016 · 4 comments
Open

Client-side compilation #4

qsantos opened this issue Jul 26, 2016 · 4 comments

Comments

@qsantos
Copy link

qsantos commented Jul 26, 2016

From my understanding, Jaspy requires a custom server because server.py handles GET requests to /load/ specially by asking compile_and_convert() from convert.py to compile it to bytecode, and then sending back the result.

However, my goal is to make a Python REPL available directly in the browser. So far, I have found either libraries that send the instructions back to a server for execution, or libraries that do not support interruptions of execution (input()).

WIth the VM interpreter, Jaspy seems like it should be able to do the trick. However, there remains the issue of compiling to bytecode. Considering that Jaspy is written in Python, compiling Jaspy itself to Javacript may be doable (of course, a few adaptations for I/O could be necessary).

So, I have a few questions:

  • what do you think of a fully client-sided interpreter?
  • do you plan to make Jaspy compatible with this?
  • do you plan to implement that yourself / have you started working on it?
  • do you have any pointers if I (or anyone) do start working on this?

Edit: I have just realized that Jaspy just relies on compile() to generate the bytecode. I will leave the issue there in case it is of interest.

@koehlma
Copy link
Owner

koehlma commented Jul 26, 2016

I think a fully client-side interpreter is a great idea and it is already one of the long term goals. My plan is to start with the bytecode compiler of the PyPy project and run it directly within the VM. An other idea would be to write the parser and compiler directly in JavaScript. However that is not on top of my priority list so I would be very happy if someone else would implement it.

Unfortunately I think the core interpreter is not quite ready to run something as complicated as the bytecode compiler of PyPy. Not even all instruction codes are implemented and many parts of the standard library and data structures are missing. When the interpreter will be more or less completed I believe it will not be too difficult to modify the PyPy compiler appropriately.

However currently I am unable to invest much spare time into this project. If you want to contribute and need some further information please let me know.

@qsantos
Copy link
Author

qsantos commented Jul 27, 2016

I'll be focusing on other projects for now, but Jaspy is a very interesting one and I'll keep it in mind for later!

@devxpy
Copy link

devxpy commented Apr 9, 2018

@koehlma, might I suggest you bring some of the features from your project over to Batavia ?
https://pybee.org/batavia/

@koehlma
Copy link
Owner

koehlma commented Apr 9, 2018

@devxpy Thanks for your suggestion. Usually, I am very much in favor of combining efforts, however, the specific features of Jaspy require a special architecture and are hard to integrate into an existing system. In my opinion, regarding Python implementations in the browser we are not yet ahead of the playing around with architectures and see what's possible stage. Batavia is, like Jaspy, based on a bytecode interpreter, which I believe will not be able to deliver the required performance. Besides that I am currently lacking sufficient spare time to invest into this project.

Also, I am thinking about rewriting Jaspy to support an advanced compilation framework based on abstract interpretation such that, e.g., only those parts of the standard library which are actually used are integrated into the final result. This again requires a different architecture than what any Python in the browser implementation currently uses. Please feel free to let me know what you think about that idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants