cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<bbot2> Retry: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/25 [nulano: test branch, win64]
<nulano> oops, I was hoping it would survive since win32 was done translating
Orimendix has quit [Ping timeout: 240 seconds]
Orimendix has joined #pypy
cjmcdonald has joined #pypy
Guest_91 has joined #pypy
Orimendix has left #pypy ["Leaving"]
Guest_91 has quit [Ping timeout: 245 seconds]
jcea has quit [Ping timeout: 246 seconds]
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<mattip> nulano: windows decided to update and rebooted the machine
<nulano> ahhh, great :D
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/26 [nulano: test branch, win64]
<nulano> the "'import site' failed" message is coming from targetpypystandalone.py line 136
<mattip> maybe it is importing the wrong site.py. It should import the one in the virtualenv
<mattip> , and maybe is importing the one from the resolved symlink to libpypy-c.so in the original directory?
<nulano> I don't think it's a symlink on windows
<mattip> ahh, yeah, so much for that theory :(
<nulano> at least it doesn't look like a symlink in explorer
<mattip> dunno. I am looking at linux64 failures on py3.6. There is a weird one in _cffi_backend
<mattip> that looks like a problem with upstream cffi comparing buf[0] == '\x00'
<mattip> but that should be buf[0] == b'\x00'
<mattip> arigato ^^^ thoughts?
_whitelogger has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/26 [nulano: test branch, win64]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7265 [mattip: test branch, win64-py3.6]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/27 [mattip: test branch, win64-py3.6]
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/108 [mattip: test branch, win64-py3.6]
<bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8387 [mattip: test branch, win64-py3.6]
jacob22 has quit [Read error: Connection reset by peer]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/27 [mattip: test branch, win64-py3.6]
jacob22 has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7265 [mattip: test branch, win64-py3.6]
Techcable has quit [Quit: ZNC - http://znc.in]
Techcable has joined #pypy
<arigato> mattip: sorry, this is broken in cffi too right now
* arigato fixes
<mattip> thanks
<arigato> done, you need to merge default into py3.6
oberstet has joined #pypy
<mattip> ok
<bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8387 [mattip: test branch, win64-py3.6]
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/108 [mattip: test branch, win64-py3.6]
<tumbleweed> arigato: on the topic of things broken in cffi. Have you seen https://foss.heptapod.net/pypy/cffi/-/issues/475 ?
<arigato> tumbleweed: yes, I'm right now attempting to build a debug-mode python 3.9 and failing
<arigato> how can I double-check if a compiled python is in debug mode?
<arigato> it certainly no longer seems to print the line [ref: ...] at the end
<tumbleweed> hrm... yeah, sys.flags.debug isn't set any more
<mgedmin> "defining the Py_DEBUG macro no longer implies the Py_TRACE_REFS macro"
<mgedmin> "The Py_TRACE_REFS macro, which adds the sys.getobjects() function and the PYTHONDUMPREFS environment variable, can be set using the new ./configure --with-trace-refs build option."
<tumbleweed> according to setup.py:
<tumbleweed> '--with-pydebug' in sysconfig.get_config_var("CONFIG_ARGS")
<arigato> mgedmin: thanks, but still sys.flags.debug==0
<arigato> also, if I make a virtualenv with the uninstalled python then it no longer finds <Python.h>
<arigato> which I'm pretty sure used to work
<mgedmin> sys.flags.debug is for the -d command-line argument, which turns on parser debugging output?
<tumbleweed> virtualenv got rewritten, things that used to work don't necessarily any more
<tumbleweed> mgedmin: ah, right
<arigato> ...ah, yes, I see why it's not finding Python.h. sorry
<arigato> OK so we don't have any way to know if a python was built in debug mode?
<tumbleweed> the sysconfig check above
<tumbleweed> it's hacky, but also directly from cpython's setup.py :)
<arigato> OK
<tumbleweed> hasattr(sys, 'gettotalrefcount') works too
<tumbleweed> (even if it doesn't print [ref: ...]
<tumbleweed> that's commonly used in the stdlib
lritter has joined #pypy
rfgpfeiffer has joined #pypy
fling has quit [Ping timeout: 260 seconds]
fling has joined #pypy
_whitelogger has joined #pypy
jcea has joined #pypy
rfgpfeiffer has quit [Remote host closed the connection]
epony has quit [Quit: cya (ame) in 10 minutes for sysupgrades.. you should upgrade too, NWO!]
epony has joined #pypy
<rjarry> guys, I have an issue with @def_extern functions
<rjarry> basically, I register a callback in a C library with a @def_extern function
<rjarry> and I have a SIGTERM handler which performs sys.exit(1)
<rjarry> this causes the SystemExit exception to be injected into the frame of the @def_extern function
<rjarry> which in turn, is swallowed by cffi wrapper
<rjarry> do you have a solution ?
<rjarry> I have the feeling that signals should be masked before calling python code from C
<rjarry> at least it should be possible to do something like:
<rjarry> @ffi.def_extern(mask_signals=True)
jcea has quit [Ping timeout: 240 seconds]
cjmcdonald has left #pypy ["Leaving"]
lritter has quit [Quit: Leaving]
jcea has joined #pypy
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7266 [mattip: test branch, win64-py3.6]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/28 [mattip: test branch, win64-py3.6]
<bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/109 [mattip: test branch, win64-py3.6]
<bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8388 [mattip: test branch, win64-py3.6]
<mattip> nulano: in a local translation of win64-py3.6 I got an error that the annotator is finding cpyext.pyobject.w_root_as_pyobject
<mattip> I seem to remember that showed up on win64 at some point too, do you remember what the fix was?
<mattip> (using pypy2.7 win64 as a translating host)
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/28 [mattip: test branch, win64-py3.6]
<nulano> I do not recall that in PyPy2, sorry
dstufft has quit [Excess Flood]
dstufft has joined #pypy
stillinbeta has quit [Ping timeout: 272 seconds]
tbodt has quit [Ping timeout: 272 seconds]
stillinbeta has joined #pypy
tbodt has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/109 [mattip: test branch, win64-py3.6]
altendky has quit [Ping timeout: 272 seconds]
altendky has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8388 [mattip: test branch, win64-py3.6]
<nulano> mattip, does _hpy_universal depend on cpyext?
<antocuni> nulano: yes, if the option "hpy_cpyext_API" is set to True (the default)
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7266 [mattip: test branch, win64-py3.6]
dansan has quit [Quit: The C preprocessor is a pathway to many abilities some consider to be unnatural.]
dansan has joined #pypy
[Arfrever] has quit [Remote host closed the connection]