01:00 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-s390x/builds/1326 [default]

01:00 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5289 [default]

01:45 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/477 [default]

05:00 <bbot2> Started: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/2951 [default]

07:12 <bbot2> Success: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/2951 [default]

12:14 <mattip> does anyone here know how compilation within a Ubuntu snap works?

12:14 <mattip> it seems the portable pypy builds are not working correctly when pip install invokes the compiler,

12:15 <mattip> the portable libm is found instead of the external, up-to-date libm

12:15 <mattip> https://github.com/numpy/numpy/issues/16142

12:38 <mattip> maybe the problem is that the snap contianer should not be using its own libm, is that due to our package script?

12:40 <mattip> no, we are not packaging libm in the portable builds

17:38 <tos9> whee, I no longer know what's real anymore... same Python interpreter (a symlink between two paths), different sys.path depending on whether you use the symlink or not

17:38 <tos9> https://bpaste.net/H5DQ

17:38 <tos9> probably this is related to my own bug ticket on virtualenv but my brain hurts

18:34 <njs> tos9: https://www.python.org/dev/peps/pep-0405/#specification

18:35 <njs> the interpreter changing its behavior based on the path where it's invoked from isn't just for venvs though, it's fundamentally required if you want a python binary that work when be placed at different absolute paths in the filesystem

18:53 <tos9> njs: I am obviously behind on things that have changed, but my point was "something more has changed"

18:53 <tos9> (I guess again this isn't pypy specific)

18:53 <tos9> njs: But I don't follow the second message -- this worked "fine" in pre-virtualenv20

18:54 <tos9> so it seems now what's changed is virtualenv==20 now follows that pep, and virtualenv<20 did not, so now if you have a symlink, you get a different site-packages

18:54 <njs> oh, I see

18:54 <tos9> specifically...

18:54 <tos9> njs: virtualenv --python /usr/local/bin/python3 venv20 && venv20/bin/python -m pip install virtualenv'<20' && venv20/bin/virtualenv --python pypy3 venv2 && venv2/bin/python -m pip install attrs && echo 'in-place' && venv2/bin/python -c 'import attr' && ln -s ~/Desktop/venv2/bin/python bla && echo 'symlink' && ./bla -c 'import attr'; rm -rf venv20 venv2 bla

18:54 <tos9> that works with virtualenv<20, and does not with virtualenv>=20

18:55 <njs> yeah I think traditionally virtualenv python binaries diverged from vanilla python binaries, and used some wacky hacks to find the right environment

18:55 <njs> a symlink changing how your python binary works is normal behavior in vanilla python binaries

18:55 <tos9> that sounds extremely weird to me

18:56 <tos9> though of course I believe you :), and that PEP says it

18:56 <tos9> I don't know why that's a good idea though.

18:57 <tos9> (or what to do instead, but maybe I give up with how fragile everything is :/ at least for this week)

19:00 <njs> virtualenv v20 is a complete rewrite, and I think part of that is that on py3 it switched to using the new venv stuff instead of the janky hacks the virtualenv used to use

19:00 <njs> and the nice thing about respecting symlinks is that it makes venv creation super fast, because your "new python binary" can just be a symlink to the original one, instead of a copy like it had to be for old-virtualenv

19:03 <tos9> njs: (I shouldn't really talk much more without reading, but since I don't plan on doing that because I just wanted to do work :/ not diagnose more issues) -- why does that require changing symlink behavior

19:03 <tos9> it seems like it should just be a pyvenv.cfg behavior

19:03 <tos9> if you find a pyvenv.cfg, you use it

19:04 <tos9> if you don't, you follow the symlink to get back to where it originally lives

19:04 <tos9> programs changing their behavior when you symlink them doesn't seem like very normal behavior to me, but maybe it is and I just don't pay attention

19:05 <tos9> I guess to fix my issue instead of symlinking I just get to write out wrapper files that exec the original binary or something but ugh

19:07 <njs> yeah, I can see an argument for your proposal, but that would require the python interpreter startup do some special case stuff to detect and resolve symlinks, and it sounds like that wasn't done back 15 years ago or whatever, so now it would be a backcompat break, maybe

19:07 <njs> or maybe it could be done, but it hasn't been, so :-/

23:54 <tos9> in case anyone wants to play with a microbenchmark, https://github.com/christianscott/levenshtein-distance-benchmarks/pull/5/files

23:54 <tos9> I tried to see where else improvements are but I couldn't remember the name of the thing to use now instead of jitviewer ( antocuni I think every time I ask this you link me at some tool you wrote but I can't find it )

23:55 <tos9> but will prob re-ask that tomorrow on europe-time so I learn it for the 100th time

23:55 <ronan> tos9: vmprof

23:56 <tos9> ronan: last time I tried it it didn't run anymore

23:56 <tos9> does it run again do you know?

23:56 <tos9> ronan: also hi! Hope you're well

23:57 <ronan> tos9: yeah, I don't think the web server works any more, but you can install vmprof-server

23:58 <tos9> I think that's what I ended up doing last time too

23:58 <tos9> though hey vmprof.com just did... something

23:58 <tos9> let's see whether that something is correct or not

23:59 <tos9> ok never mind yeah whatever it did didn't work, will go back to vmprof-server'ing