cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
<hexology> is there a public timeline for if/when pypy will drop 2.7 support?
<Corbin> hexology: Probably never; RPython is tied to Python 2.7 and so it's a matter of self-hosting.
glyph has quit [Quit: End of line.]
glyph has joined #pypy
<hexology> thanks Corbin, that's an interesting situation
Atque has quit [Quit: ...]
<fijal> hexology: I think never is a good estimate
<fijal> I don't believe porting rpython to python 3 is worth the effort at all
greedom has joined #pypy
ambv has quit [Quit: Client limit exceeded: 20000]
greedom has quit [Remote host closed the connection]
<cfbolz> (unless we get some serious funding)
ambv has joined #pypy
<fijal> cfbolz: I think even then, it seems like messy work with no real benefits
<fijal> I would much rather go for "non python"
<fijal> but yeah, that would be a massive project and probably needs both massive funding and be fun to work on
<cfbolz> fijal: no, the goal would have to be "move to python3 and make it modular" or something
Lightsword has quit [Quit: ZNC]
<fijal> or something
<fijal> I'm still more excited about some other language than python
<cfbolz> another language: a bit unclear which one
<cfbolz> but yes, maybe
<fijal> but yeah, it's all incredibly theorethical at this stage
<ctismer> LarstiQ: Right
Lightsword has joined #pypy
<Hodgestar> cfbolz, fijal: <general-silliness>Rust! Then we can include PyPy in the Linux kernel one day!</general-silliness>
<cfbolz> Rust's GC story is still pretty unclear to me
Atque has joined #pypy
<cfbolz> yaaaaay, segfault
<cfbolz> >>>> compile(b"aaaa = r'\xc3\xa4\xc3\xb3\xc3\xba \xc2 '", "", "exec")
<cfbolz> Aborted (core dumped)
<LarstiQ> in cpython too, or is this a parser implementation subtlety?
<cfbolz> LarstiQ: no, just a pypy bug
<cfbolz> calling the decode function with None as the errorhandler function
Atque has quit [Remote host closed the connection]
Atque has joined #pypy
otisolsen70 has joined #pypy
Ninpo has quit [Changing host]
Ninpo has joined #pypy
<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?
<antocuni> I have a but feeling that the only way to solve the problem is to insert the notion of ownership inside the type
<antocuni> but I don't know if it's provable and/or if there are other solutions
<cfbolz> antocuni: in general, without extra info it's not possible (can be reduced to the halting problem)
<cfbolz> antocuni: your specific idea leads to rust, I think
<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
<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
<cfbolz> right
<cfbolz> so you want something that is "relatively soon after they die"
<antocuni> so the "never free" approach is theoretically valid but not in practice
<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
<cfbolz> I have the same gut feeling
<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
Julian has joined #pypy
<antocuni> ok thanks... it's probably not needed to show the full proof, but I wanted to check whether I was saying nonsense :)
<antocuni> thanks
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
<ronan> fijal: I'm convinced pypy will die if we never port rpython
Julian has quit [Ping timeout: 256 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 260 seconds]
Julian has joined #pypy
otisolsen70_ has joined #pypy
otisolsen70_ has quit [Remote host closed the connection]
otisolsen70 has quit [Ping timeout: 240 seconds]
<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.
<Julian> ronan: why do you say that
<Julian> (I don't disagree at all, just curious)
<Julian> er by "don't disagree" what I mean is "I have no idea or opinion"
<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
<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.
Julian has quit [Ping timeout: 264 seconds]
<cfbolz> One big problem of rpython 3 is going to be the fact that the cpython bytecode changes every version nowadays
Julian has joined #pypy
<ronan> cfbolz: yes, OTOH, there are other people who have to deal with this nowadays ( e.g. numba). Maybe we can share the burden
Julian has quit [Client Quit]
slav0nic has joined #pypy
Atque has quit [Quit: ...]
<mattip> pyjion released a version
<[Arfrever]> cfbolz: CPython bytecode changed between each minor version in 2.* series too (e.g. between 2.6 and 2.7).
<cfbolz> [Arfrever]: oh absolutely
<cfbolz> [Arfrever]: I remember the transitions from 2.3 onwards, they were a pain
slav0nic has quit [Ping timeout: 264 seconds]
Atque has joined #pypy