cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | mac OS and Fedora are not Windows
mattip has quit [Ping timeout: 252 seconds]
mattip has joined #pypy
jcea has quit [Remote host closed the connection]
<catern>
dear #pypy, is it crazy for me to use cffi just as a convenient build step? I want to compute some data/do various things, and store the results into variables in the library built by cffi
dddddd has quit [Remote host closed the connection]
<mjacob>
cfbolz: i tend to say yes. if i'm unlucky, there will be an exam in this week. also, i plan to do a weeks-long journey in spring and i'll see how things align.
<mjacob>
catern: i'm not sure i understand what you're doing exactly. cffi uses distutils internally for building
<vstinner>
the real talk started on python-dev when I asked to add my "new C API" in the master branch: _PyCoreConfig_AsDict
<cfbolz>
vstinner: awesome!
arigato has joined #pypy
marky1991 has joined #pypy
<LarstiQ>
how does the inlining of Py_INCREF affect pypy?
<vstinner>
LarstiQ: it makes the C API of CPython more "regular", conform to C99
<LarstiQ>
sure, but I don't know enough of the details to see if this will break/become slower/what
<LarstiQ>
is the object completely the same?
<vstinner>
LarstiQ: at this stage, PyPy is not directly impacted in any way
<vstinner>
i would like to prevent Py_SIZE() to be used as an lvalue. that would impact PyPy, since currently Py_SIZE() is an insane macro :)
<vstinner>
(sorry, i was in two meetings)
<vstinner>
well, my current problem is now to explain how the current C API is a threat to CPython itself
<vstinner>
people are whinning that converting macros to function calls will destroy their C code written by hand and micro-optimized after years of work
<vstinner>
destroy performances*
<vstinner>
one of the key is if PyPy will suddenly run a C extension faster if some problematic functions are no longer used
* simpson
searching for polite response
<simpson>
Honestly I've only had luck dealing with this mindset with in-person conversations about performance.
<simpson>
On your current track, I might emphasize GC, and how the GC's performance depends crucially on whether or not it can hide some information from external users.
<vstinner>
in my list of ideas, i imaginzed a CPython fork without GC at all :)
<vstinner>
if your code is perfect (never create any ref cycle), you don't need a GC and you can remove PyGC_Head which uses 16 bytes
<vstinner>
well, i'm not sure that it's useful, but i like the idea that it would become doable :)
<simpson>
Hm, I guess. That is definitely not a direction for which I would ever aim my code, personally, but I can see the appeal.
<vstinner>
simpson: hum. it seems like most people completely misunderstood my plan...
<LarstiQ>
vstinner: I was clearly not thinking, extensions need to be recompiled anyway
<mattip>
making Py_INCREF into a function would not help PyPy, it is fine as a macro
<mattip>
not writing c-extensions at all would help PyPy more
<vstinner>
Alex_Gaynor: modifying Py_SIZE() to prevent to be able to write "Py_SIZE(obj) = size;" cannot be done in the current C API, since I don't want to break the backward compatibility
<vstinner>
my whole plan is to have a new opt-in API
<Alex_Gaynor>
Don't copy Py_SIZE in the new API then, heh
<vstinner>
Alex_Gaynor: Py_SIZE() has to stay, it's fine to use it to *get* the value of an object
<Alex_Gaynor>
sure, but make it an inline function, not a macro
<vstinner>
Alex_Gaynor: i would like to add Py_SET_SIZE() (or Py_SetSize()!?)
<vstinner>
Alex_Gaynor: yes
<vstinner>
Alex_Gaynor: Py_SIZE() is not the problem. the real problem is the backward compatibility. that's why i chose to propose a new opt-in API
<vstinner>
with a new API, we can do whatever we want!
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
arigato has quit [Quit: Leaving]
abrown has joined #pypy
<abrown>
I'm trying to use two jitdrivers in the same file and am running into issues; I get errors from the annotator like "[annrpython:WARNING] SomeInstance(can_be_None=False, classdef=src.ast.While) does not contain SomeInstance(can_be_None=False, classdef=src.ast.Exp)"
<abrown>
from setbinding(...) in annrpython.py
<abrown>
It seems like this is a type issue... can anyone explain what setbinding() is trying to do?
mattip has quit [Quit: Leaving]
marky1991 has quit [Ping timeout: 244 seconds]
<cfbolz>
abrown: can you paste the code and maybe a bit of context of the error message?
<cfbolz>
does translation work without the two jit drivers?
<abrown>
hm, yes, let me check
<abrown>
without the JIT: no issues
<abrown>
let me see if I can paint the picture: I have a bunch of AST nodes that all descend from Exp--nodes like Add, Subtract, While, FunctionCall, etc.
<abrown>
each of these has an evaluate() method
<abrown>
While already has a working jitdriver; I wanted to play around with a jitdriver in FunctionCall to see if I could trace recursive function calls
<cfbolz>
abrown: it's very hard to answer without looking at some code, I fear
<abrown>
the sole jitdriver green variable is `code` to which I am passing the AST node instance, e.g. the While instance or the FunctionCall instance
<simpson>
abrown: Suspecting you need `if isinstance(src.ast.While):` or similar.
<abrown>
ok, let me push the code and send a link
<ronan>
abrown: I guess that the JIT causes some code to be reannotated in a way that's inconsistent with the annotation phase
<ronan>
e.g. there could be jit-specific code that passes a FunctionCall to a function that would only see While otherwise
<abrown>
simpson: I do something like `function_jitdriver.jit_merge_point(code=self)`... shouldn't RPython know that self is a While or a FunctionCall?
<ronan>
abrown: I think it should. What's the annotation error?
<abrown>
it prints a warning: "[annrpython:WARNING] SomeInstance(can_be_None=False, classdef=src.ast.While) does not contain SomeInstance(can_be_None=False, classdef=src.ast.Exp)" and then setbinding() does an `assert False`
<abrown>
ronan: and it looks like something is backwards because Exp does contain While... I can't figure out why it is checking the opposite
<abrown>
hm... so one of the jitdrivers says that the get_location function receives While and the other FunctionCall and the annotator is trying to reconcile those to Exp?
<ronan>
yes
<abrown>
shouldn't it be able to reconcile these? they both descend from Exp and both have a to_string() method...
<simpson>
But that might not be sufficient. You'd need to either add another subclass specifically for the JIT'able expressions.
<simpson>
Or maybe I'm totally misunderstanding what's wrong.
<ronan>
it doesn't work because this is late-stage that isn't allowed to update existing function annotations
<abrown>
ok
<ronan>
*late-stage annotation
<abrown>
easy fix: have two get_location functions :)
<ronan>
yes, or specialize the existing one
<abrown>
ah, yes... specializing: so something like @specialize.arg(1)?
<ronan>
@specialize.argtype(0), rather
<abrown>
ah, ok
<abrown>
so let me check my understanding: why I add @specialize.argtype(0), the annotator will create two (or more) different flow graphs for get_location--one for While expressions and another for FunctionCall expressions
<abrown>
*why -> when
<ronan>
yes
<abrown>
ok, and why can't the type resolution stuff work to generalize to Exp? i.e. what do you mean by late-stage?
<ronan>
late-stage annotation is any annotation that happens after the annotate phase
<abrown>
so anything related to jitdriver stuff?
<ronan>
yes
<abrown>
ok, that helps; thanks!
<ronan>
this is really a bug in rpython, but it's annoying to fix
<abrown>
yeah, it's hard to figure out what went wrong; thanks for the help, though... would have taken me a while to piece it together on my own
kipras has joined #pypy
marky1991 has joined #pypy
abrown has quit [Quit: Leaving]
arigato has joined #pypy
forgottenone has quit [Ping timeout: 252 seconds]
Zaab1t has quit [Quit: bye bye friends]
marky1991 has quit [Ping timeout: 252 seconds]
marky1991 has joined #pypy
marky1991 has quit [Ping timeout: 245 seconds]
marky1991 has joined #pypy
adamholmberg has joined #pypy
mattip has joined #pypy
<mattip>
it seems bbot keeps getting banned from this channel when it starts too many jobs so is accused of spamming
<mattip>
could we add a sleep between the messages?
<mattip>
also kenaan_ is here, but I don't see commit messages
nunatak has quit [Quit: Leaving]
lritter has quit [Quit: Leaving]
<arigato>
:-/
<mattip>
hmm 'nohup python commit_bot' ?
<mattip>
commit_bot started, but I didn't see a new kenaan connection
<arigato>
is that on baroquesoftware.com?
<arigato>
we recently updated the OS and it may have broken all vitualenvs (in an easy-to-fix-but-manual way)
<arigato>
you need to run "virtualenv /path/to/existing/venv"
<mjacob>
arigato: is there already a tendency for whether or not there will be a leysin sprint (considering the duesseldorf sprint and the possibly unclear situation of ermina)?
marky1991 has quit [Read error: Connection reset by peer]
<mjacob>
(the fact that i already try to organize my spring journey is maybe a clear sign that i have something very important to do instead ;))