search

rainwoodman / tinypy

tpy, a pet python forked from tinypy
Other
21 stars 5 forks source link

Use --backend=tpy for running the test suite with tpy. #15

Closed rainwoodman closed 3 years ago

rainwoodman commented 3 years ago

Also update travis script to run all three test targets.

rainwoodman commented 3 years ago

@Wiguwbe

Wiguwbe commented 3 years ago

Seems fine.

Regarding the libtpy.so tests, I'm guessing a dedicated script for that would be better, right?

rainwoodman commented 3 years ago

Yes. I added a tpy-shared binary target that links against the so file. I feel (the use of the -Wl flags for rpath and soname) may not be very portable, so I added a disclaimer to the makefile target.

Wiguwbe commented 3 years ago

Looks fine. There may be even the possibility, special in installation (maybe future?) to ship the tpy as the current tpy-shared, that is, make tpy just the tpmain.c and link to the shared object.

rainwoodman commented 3 years ago

The shared object becomes a non-hermetic dependency, and that opens up a lot of variations to deal with in a Makefile. We probably need to introduce a modern build tool (cmake or bazel?) for proper so file handling; and that's definitely for the future.

Wiguwbe commented 3 years ago

Indeed. One of the things I was hoping to achieve (hence my initial makefile target for libtpy.so) is extracting just the interpreter, without the modules. That would allow for more something when embedding/sandboxing (i guess?). A developer would implement the required modules (and only them) around the interpreter. I'm also guessing that a modern build tool would facilitate that customization.

I'd say that the next steps would be documentation? Namely what features of python are implemented, what are planned or what to leave out (keyword arguments...) and, since I feel this has potential to be embeddable, a C interface. Shall I create the issues for these topics?

rofl0r commented 3 years ago

We probably need to introduce a modern build tool (cmake or bazel?) for proper so file handling

urgh please not. the appeal of tinypy is that it can be used without a lot of dependencies and be compiled quickly with a C compiler. that advantage goes away if one needs to compile the clusterfuck CMake with a C++ compiler (more than 1 million lines of code!!), and bazel is even worse because it requires JAVA installed.

i'm quite good with GNU Make so if you have a specific problem maybe i can help out.

rainwoodman commented 3 years ago

@Wiguwbe Yes it would be nice if you can create issues (and then we can prioritize). A few things I have on my list are:

  1. Really understand the garbage collection algorithm (and potentially rewrite it). Perhaps replace it with something more aligned with GObject's reference counting mechanism.
  2. Add an iterator protocol. "for i, a in enumerate(l)"
  3. Context manager. with AssertRaisesRegEx("....."): ....
  4. Integer type(s)

@rofl0r: Sure. Even if we add other toolchain Makefile+gcc would still be the default. Could you take a look if the current Makefile makes sense to you? I'd also note with @Wiguwbe's patch we are one step closer to self-bootstrapping.

rofl0r commented 3 years ago

@rofl0r: Sure. Even if we add other toolchain Makefile+gcc would still be the default.

i've seen various projects with more than one build systems, however it's quite rare that both are in a fully working state. usually whatever the main dev prefers stays up-to-date, while the other one bitrots.

Could you take a look if the current Makefile makes sense to you?

i certainly can, though i didn't fully understand yet what the issue at hand is, care to explain ?