05:37 <hexology> is there a public timeline for if/when pypy will drop 2.7 support?

05:44 <Corbin> hexology: https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from-mozilla-for.html Probably never; RPython is tied to Python 2.7 and so it's a matter of self-hosting.

06:18 <hexology> thanks Corbin, that's an interesting situation

07:38 <fijal> hexology: I think never is a good estimate

07:39 <fijal> I don't believe porting rpython to python 3 is worth the effort at all

09:01 <cfbolz> (unless we get some serious funding)

09:08 <fijal> cfbolz: I think even then, it seems like messy work with no real benefits

09:08 <fijal> I would much rather go for "non python"

09:08 <fijal> but yeah, that would be a massive project and probably needs both massive funding and be fun to work on

09:09 <cfbolz> fijal: no, the goal would have to be "move to python3 and make it modular" or something

09:09 <fijal> or something

09:09 <fijal> I'm still more excited about some other language than python

09:09 <cfbolz> another language: a bit unclear which one

09:09 <cfbolz> but yes, maybe

09:10 <fijal> but yeah, it's all incredibly theorethical at this stage

09:55 <ctismer> LarstiQ: Right

10:23 <Hodgestar> cfbolz, fijal: <general-silliness>Rust! Then we can include PyPy in the Linux kernel one day!</general-silliness>

10:25 <cfbolz> Rust's GC story is still pretty unclear to me

12:25 <cfbolz> yaaaaay, segfault

12:26 <cfbolz> >>>> compile(b"aaaa = r'\xc3\xa4\xc3\xb3\xc3\xba \xc2 '", "", "exec")

12:26 <cfbolz> Aborted (core dumped)

12:39 <LarstiQ> in cpython too, or is this a parser implementation subtlety?

12:41 <cfbolz> LarstiQ: no, just a pypy bug

12:41 <cfbolz> calling the decode function with None as the errorhandler function

13:40 <antocuni> compiler theory question. Suppose I have a static language in which the user can allocate typed objects, and I don't have a GC. Is there a way to statically determine where to insert the free()s to avoid memory leaks?

13:40 <antocuni> I have a but feeling that the only way to solve the problem is to insert the notion of ownership inside the type

13:41 <antocuni> but I don't know if it's provable and/or if there are other solutions

13:41 <cfbolz> antocuni: in general, without extra info it's not possible (can be reduced to the halting problem)

13:41 <cfbolz> antocuni: your specific idea leads to rust, I think

13:42 <cfbolz> but you also need to be a bit more precise in your question. eg a valid way to implement what you want is to not ever call free, until the program finishes, where you free everything

13:44 <antocuni> yeah sure. The concrete problem is that we have a python-like subset of python (based on numba) and that these functions are executed in a long running process

13:45 <cfbolz> right

13:45 <cfbolz> so you want something that is "relatively soon after they die"

13:45 <antocuni> so the "never free" approach is theoretically valid but not in practice

13:46 <antocuni> yes, basically I wanted to know whether my gut feeling that "you can prove that it's impossible to do" was right or not

13:48 <cfbolz> I have the same gut feeling

13:48 <cfbolz> and if I had to do the proof I would think along the lines of Rice's theorem or how to reduce it to the halting problem or something

13:59 <antocuni> ok thanks... it's probably not needed to show the full proof, but I wanted to check whether I was saying nonsense :)

13:59 <antocuni> thanks

15:08 <ronan> fijal: I'm convinced pypy will die if we never port rpython

15:52 <Corbin> Porting RPython to 3.0 through 3.2 is a very different discussion than 3.6 or newer. It was a good idea to wait a few years for Python 3 to mature.

16:16 <Julian> ronan: why do you say that

16:16 <Julian> (I don't disagree at all, just curious)

16:17 <Julian> er by "don't disagree" what I mean is "I have no idea or opinion"

16:23 <ronan> Julian: it's going to be harder and harder to contribute and to build pypy. After some point, most people won't bother any more

16:28 <Corbin> ronan: nixpkgs is prepared to fill that gap, although folks will have to use Nix. The main problem IMO is that PyPI's owners are eventually going to make choices which break package distribution for Python 2, and most nixpkgs source tarballs are pulled from PyPI.

17:31 <cfbolz> One big problem of rpython 3 is going to be the fact that the cpython bytecode changes every version nowadays

17:48 <ronan> cfbolz: yes, OTOH, there are other people who have to deal with this nowadays ( e.g. numba). Maybe we can share the burden

20:41 <mattip> pyjion released a version https://www.trypyjion.com/

21:09 <[Arfrever]> cfbolz: CPython bytecode changed between each minor version in 2.* series too (e.g. between 2.6 and 2.7).

21:10 <cfbolz> [Arfrever]: oh absolutely

21:10 <cfbolz> [Arfrever]: I remember the transitions from 2.3 onwards, they were a pain