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

Is this dead? #61

Open
ghost opened this issue Mar 18, 2018 · 9 comments
Open

Is this dead? #61

ghost opened this issue Mar 18, 2018 · 9 comments

Comments

@ghost
Copy link

ghost commented Mar 18, 2018

Last commit 2009, yet there are much more recent issues.

@SuperWangKai
Copy link

I'm curious too 🤔

@rainwoodman
Copy link

I had this exactly the same idea over a shower. Some google landed me here. Looks unmaintained indeed. Wonder how much it will take to give this some Python 3 flavor.

@pfalcon
Copy link

pfalcon commented Feb 3, 2019

Non-toy, Python3-flavored spiritual successor of tinypy is https://github.com/micropython/micropython .

However, it would be nice to fix up this repo, so it worked out of the box.

@pfalcon
Copy link

pfalcon commented Feb 3, 2019

Well, @rainwoodman seems to be doing quite a lot of work in his fork: https://github.com/rainwoodman/tinypy

@rainwoodman
Copy link

Indeed. The general direction is to make it easier to hack on and set the background such that hacks will naturally land into the right places.

I am in the middle of several things -- it was fun, but time has been scarce. May I bug you from time to time on issues?

  1. Reorganizing the API. I added a layered structure: basic data structures (tpd), language services (tp), and python interface (tpy). I am trying to kill all the cyclic dependency between layers. This may have broken several extension modules.

  2. Switch to meta to dispatch all methods. This would allow subclassing of all builtin classes, and extending the builtin classes (think of jQuery alike) without modifying the VM.

  3. disabling import from file; only support importing from existing fully qualified module names, which are associated with code objects by some other mechanism. The idea is to avoid a big, fat standard library that needs to be carried with the interpreter, and will also remove file-system dependency from the core vm.

Other to do list is a new testing framework; an audit of the code on thread safety is also on my list; adding an Exception class; and probably eliminate setjmp/longjmp, if that's possible at all -- how do you see this?

A binding to a tensor library could be nice.

@pfalcon
Copy link

pfalcon commented Feb 4, 2019

@rainwoodman, Good plans list, thanks, I'm sure people interested in tinypy will find it useful.

May I bug you from time to time on issues?

I assume you address to "wider tinypy community". I'm sure it will respond. In the meantime, let me ask a question from my side: what's your motivation for doing all those non-trivial, effortful things to tinypy?

@rainwoodman
Copy link

I am not so certain about the size of the audience. There isn't much space left, especially given the neither language nor the extension API is compatible with Python or lua.

A good candidate as a hobby or a place to learn about how to build languages, but I don't see much more beyond these.

@SuperWangKai
Copy link

@rainwoodman Please see this -
http://mruby.org/

@rainwoodman
Copy link

Thanks.

I wonder how they are doing the tests -- it smells like they are using mruby as a ruby extension, then assert the output of the extension module. But this would mean if the target system doesn't have ruby tests cannot be run there.

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