04:27 <LarstiQ> graingert: pypy2 should work too?

08:12 <graingert> LarstiQ: no all the tests are skipped on pypy2

08:13 <graingert> LarstiQ: https://github.com/pypy/pypy/blob/91ae44d33199a47679ff49468587ed8993ad2e2f/rpython/rlib/rstacklet.py#L81-L85

08:14 <graingert> I deleted the skip and got a segmentation fault

08:17 <arigato> I think that only a very small subset of tests should be skipped?

08:17 <graingert> it's all the tests that failed in my branch.

08:17 <graingert> python2.7 won't build on this version of ubuntu so I needed to use docker

08:18 <arigato> ah, pypy/module/_continuation/test/test_zpickle.py

08:26 <arigato> _continuation is related to stackless python; I definitely forgot everything about the actual order in which things execute (despite writing this code long ago)

08:26 <arigato> unsure why there is (or was) this logic to pop the stack here; it looks like part of the regular bytecode implementation was never run at all?

08:34 <arigato> ah yes, it's *picking* the _continuations, which is part of the code I definitely deny all knowledge about

08:36 <arigato> or more precisely, https://github.com/pypy/pypy/pull/5087/commits/91ae44d33199a47679ff49468587ed8993ad2e2f runs after unpickling a continuation, so it just created some Python frame objects in memory and now it has to run them from whatever state they happen to be in

08:37 <arigato> the assumption is that all the frames that were pickled where in the middle of some call (e.g. to the next inner frame, or to some function to switch the execution flow away)

08:37 <arigato> but when resuming we only see the Python frames themselves, as they were in the middle of calls

08:38 <arigato> but the hack was needed because we restart the Python frames at the next bytecode

08:42 <arigato> my feeling is that pickling continuations has always been an obscure pypy-only feature that (I hope) nobody really uses, and which can easily trigger one of the asserts in the code, so it's completely experimental

15:31 <korvo> Whoa. FWIW being able to unpickle continuations would be enough to implement orthogonal persistence, which is normally a runtime-defining feature. Wild that it's just a part of a part of a library.

15:33 <cfbolz> no, it's in rpython, so part of the language implementation

15:33 <cfbolz> it's also py2 only

15:53 <korvo> Huh, okay. So like, if I wanted to compile some sort of image-based language stored as pickles, I could unpickle the image at the beginning of translation?

15:54 <korvo> As opposed to e.g. PySOM's fun hack where an image can be stored as literal bytes in the executable.

15:54 <cfbolz> pickle is a python feature, not an rpython feature

15:55 <cfbolz> korvo: there were image based rpython vms at some point though, mainly (only?) the squeak port

15:57 <korvo> cfbolz: Sure. I mean, like, compiling the high-level code to RPython itself. Like, first Futamura instead of second Futamura.

15:58 <korvo> Sorry, I don't think I'm helping.

15:58 <cfbolz> if you "just" want to fuse some code into the binary that's not so hard

15:58 <cfbolz> that's how importlib works in py3

16:01 <korvo> What I want is nebulous and unreasonable, usually. Like, this week I was thinking it'd be nice to access git repositories from RPython binaries.

16:02 <korvo> I'm gonna subprocess a wrapper in Python 3 which uses Dulwich, because I need to monkey-patch Dulwich to allow git repos with certain invalid characters.

16:02 <korvo> The hope was that I could load code from git repositories instead of loading it from documents. Nebulous and unreasonable.