06:58 <cfbolz> _vertig0: do you have a cpython2 around?

06:58 <cfbolz> (sorry for having really bad gaps in my replies, had a super busy week

06:58 <cfbolz> )

06:59 <cfbolz> basically if you can get *any* python2 with pygame, you can use the viewer

07:01 <_vertig0> cfbolz: No worries! I've read that you can't just use any cpython though, it has to be a special cpython 2 to be able to translate, which I'm not sure how to get that. In any case I ultimately had to modify pygame's source and then build it, using an old PyPy nightly build that had cpyext enabled. Wasn't fun but it worked. Thanks for the help though!

07:02 <cfbolz> ah, windows! you're right, thanks for reminding me

07:02 <cfbolz> there's another trick though:

07:02 <cfbolz> you can use a standard python2 *just* for pygame

07:03 <cfbolz> if you run `cpython2-with-pygame dotviewer/sshgraphserver.py LOCAL`

07:03 <cfbolz> then start a translation in another terminal, with pypy2 without pygame, then it will use the other process to show you graph views

07:04 <cfbolz> _vertig0: what are you working on anyway?

07:04 <_vertig0> Oh wow that is really handy to know, thanks!

07:05 <cfbolz> yeah, it's probably under-documented :-(

07:05 <_vertig0> cfbolz: I'm trying to do an LLVM translation backend for fun, but I've had trouble understanding how to plug in a brand new backend and where to hook it up to receive the output of the backendopt step :P

07:06 <_vertig0> Just gimme a second gonna save your tip in my notes for next time...

07:08 <cfbolz> I never tested, but maybe it's even possible to make sshgraphserver.py work on python3. that would make installation easier for the future

07:09 <cfbolz> adding a new backend should be possible, we used to have an llvm backend (long ago)

07:10 <cfbolz> it's a lot of work though :-(

07:10 <_vertig0> Yep I hijacked your llvm-translation-backend branch for that purpose :P

07:14 <_vertig0> The hardest part so far was figuring out where the existing C one picks up the rtyper output and loads it into the database since the interface for database loading seems to also double as functions used to retrieve stuff from the C database, at least from what I see so far

07:14 <_vertig0> (I don't know why I'm talking like I figured out how to do it when I haven't)

07:15 <cfbolz> yeah, IIRC every backend had their own "database", there wasn't any shared infrastructure for that kind of stuff

07:33 <korvo> _vertig0: (One of the fun things about RPython is that sometimes the big picture will make sense even when the code is difficult to understand. You're doing great.)

07:36 <cfbolz> everything old is new again: CPython is discussing official support for stackless/greenlets: https://discuss.python.org/t/add-virtual-threads-to-python/91403

07:37 <_vertig0> korvo: I hope it'll make sense to me in the end haha, right now I don't know what the rtyped intermediate representations are like or how to turn that into target code of any kind, let alone LLVM :P

07:39 <_vertig0> cpython considering a feature that Java has :O

07:40 <korvo> _vertig0: No rush. It's an ambitious goal and the translation process doesn't admit a nice linear decomposition into discrete non-overlapping stages.

07:41 <_vertig0> Haha thanks!

07:41 <korvo> Actually, have you read much about partial evaluation? It might help to know that a partial evaluator doesn't quite have the same internal structure as a 1960s-style compiler.

07:43 <_vertig0> Is that when you run through some code to see its structure without actually executing it? I vaguely remember something about this but not much

07:45 <cfbolz> rpython is a pretty traditional ssa-based compiler though

07:45 <cfbolz> at least at the backend level

07:47 <korvo> Oh, for sure. What I was hoping to explain was the bidirectional data flowing between different stages of the compiler.

07:49 <korvo> For example, it might be confusing that the number of blocks grows during translation. But partial evaluation helps to explain this: sometimes we need to partially evaluate a hunk of code with respect to multiple different environments, and this generates multiple new blocks that didn't exist in the original input source.

07:58 <_vertig0> I wouldn't say that necessarily confusing, compilers sometimes do have to expand blocks like that

07:59 <_vertig0> (Maybe expand is the wrong word for that but you get what I mean)

08:16 <cfbolz> most (optimizing) compilers add blocks in the optimization phase, I'd expect

08:35 <korvo> Sure. As I was typing that, I saw a bit more of cfbolz' perspective; an SSA block-splitting compiler is more like 1990s than 1960s, and shouldn't be thought of as the same thing.