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
tsaka__ has quit [Ping timeout: 265 seconds]
sven- has joined #pypy
sven has quit [Quit: ZNC 1.7.4 - https://znc.in]
sven- is now known as sven
sven- has joined #pypy
jcea has quit [Ping timeout: 240 seconds]
oberstet has quit [Remote host closed the connection]
sven has quit [Ping timeout: 240 seconds]
sven- is now known as sven
forgottenone has joined #pypy
pmp-p has quit [Read error: Connection reset by peer]
glyph_ has joined #pypy
glyph has quit [Quit: End of line.]
glyph_ is now known as glyph
pmp-p has joined #pypy
<mattip> is there a way to mark rarithmetic.intmask() so that the annotater will only accept intmask(int_type)?
<mattip> that way translation on 32-bit would crash in the annotation stage, not in the JIT stage
mgedmin has quit [Ping timeout: 240 seconds]
mgedmin has joined #pypy
tsaka__ has joined #pypy
oberstet has joined #pypy
lritter has joined #pypy
jcea has joined #pypy
<antocuni> mattip: look at rtyper/rbuiltin.py:rtype_intmask
<antocuni> you can probably put some extra check there
<antocuni> mattip: or even annotator/builtin.py:rarith_intmask
otisolsen70 has joined #pypy
<mattip> nope, neither of those caught it. Maybe because it happens in the JIT production?
<antocuni> mattip: what is the exact problem you are trying to solve?
<mattip> the crash of 32-bit translation
<mattip> at the bottom
<antocuni> to it is trying to call intmask on a pointer? If you put a check in rarith_intmask you can surely catch this case
<antocuni> I have troubles to understand that traceback though
<antocuni> it seems to fail when trying to specialize an op "llong_from_int", but I don't understand why it calls rtype_intmask after that
<mattip> because it is not really an int, it is a pointer, so inside llong_from_int there is intmask(),
<mattip> in rpython/jit/codewriter/support.py:_ll_1_llong_from_int()
<antocuni> ah ok
<mattip> it generates that op when optimizing apparently?
<antocuni> not when "optimizing" but when generating the jitcodes, I think
<mattip> but now I see that there is a call way up the backtrace to transform_graph(graph), I didn't climb that high up yet
<mattip> maybe
<antocuni> yeah, it would be helpful to know what is the culprit graph/function
<mattip> it is in _cffi_backend/misc.py: write_raw_signed_data(), which is now called from _cppyy/capi/loadable_capi.py:W_RCTypeFunc.rcall
<mattip> maybe the argtype.size is off for pointers on 32 bit, so the cast is wrong
otisolsen70 has quit [Quit: Leaving]
riddle has quit [Ping timeout: 272 seconds]
oberstet has quit [Quit: Leaving]
forgottenone has quit [Read error: Connection reset by peer]
forgottenone has joined #pypy
Techcable has joined #pypy
Techcable has quit [Client Quit]
Techcable has joined #pypy
asmeurer has joined #pypy
forgottenone has quit [Quit: Konversation terminated!]
asmeurer has quit [Client Quit]
lritter has quit [Quit: Leaving]
asmeurer has joined #pypy
Taggnostr has quit [Remote host closed the connection]
Taggnostr has joined #pypy