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
<antocuni>
I can't find any place in rpython which generates a "/* nothing */" instead of a real expression
dddddd has joined #pypy
<arigato>
that's for Void variables
<arigato>
the problem is that we have an expression like "ll_assert(x is not None)" in the source, and x is annotated as e.g. SomePBC(None)
<arigato>
though I'm not sure about the details
<arigato>
maybe it's "ll_assert(x != lltype.nullptr(..))" and x is SomePBC(None)
<arigato>
(there is '/* nothing */' in translator/c/funcgen.py)
<arigato>
(and in primitive.py too)
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
Guest38573 has quit [Quit: Leaving]
<antocuni>
arigato: thanks, I wonder why my grep didn't find them
<antocuni>
probably I messed up something with the '*' :)
lritter has joined #pypy
<antocuni>
uh, I am confused. This is probably unrelated to my problem, but in interp_fcntl there are a number of lines which just call "_get_error()" without using the result
<antocuni>
_get_error RETURNS an OperationError but does NOT raise it. So the question is: is this intended, or all these lines are missing a "raise"?
<arigato>
uh
<arigato>
uh? no clue. in "default" it says "raise" at every call
<antocuni>
ah
<arigato>
indeed just caling _get_error() is a noop
<arigato>
a wait
<arigato>
no no obscure mess
<arigato>
see the docstring of wrap_oserror2()
<arigato>
eintr_retry=True means "if you return, then it will return None, and really means you should retry the operation"
<antocuni>
very obscure API :(
adamholmberg has joined #pypy
<arigato>
probably we have the opposite bug
<arigato>
there are still a few places that say "raise _get_error()" and they will thus raise None
<antocuni>
ah, then this might be the problem which causes lldebug to fail
<arigato>
ah it's a very recent checkin to the py3.6 branch, 8dd2368777ad
<antocuni>
I suppose that this should be a more prominent RPython error, not one which fails only in lldebug
<arigato>
yes, absolutely
<arigato>
I guess it actually means the API is not prone to mistake-not-seen-later, but instead "only" to mistake-causing-obscure-failure
<antocuni>
and _get_error should probably be renamed to "_raise_error_maybe" or something like that
<arigato>
+1
<arigato>
do you want me to try to fix the annotation issue of "raise None"?
<antocuni>
if you feel like :)
<arigato>
sure
<antocuni>
I went down this black hole while trying to debug and hpy segfault :)
<Dejan>
why don't you, Mercurial fans us hg-git and move the PyPy to a Git repo somewhere (GitLab for an example)? :)
<antocuni>
so I wouldn't mind to go back to my original issue
<Dejan>
s/us/use/
<arigato>
OK, then I'll leave you to fix fcntl/ now, and later I can do a function rename if you didn't
<antocuni>
ok, thank you
<arigato>
Dejan: the main problem is that git repos don't record branch names (for the mercurial definition of "branch")
Smigwell has joined #pypy
<Dejan>
use tag for that purpose
<Dejan>
tag and branch are almost the same thing in Git
<Dejan>
(not a Git expert here)
<antocuni>
Dejan: we are using mercurial's named branches, which don't have any git equivalent
<Dejan>
again, tags
<antocuni>
nope; git tags are just pointers to particular commits. In mercurial, the branch name is saved as metadata for every commit which belongs to that
<arigato>
please feel free to write a detailed explanation about why git tags are equivalent to mercurial's named branches, but I think it's not the case
<Dejan>
why are regular git branches not good enough ?
<Dejan>
ah, git names the tip of the branch...
<Dejan>
so it is not really the same
<Dejan>
idk, I have a feeling insisting on Mercurial is going to restrict the number of contributions to the project, but if you guys are fine with that then it is all right
<antocuni>
and if you click on the commit, you immediately see it was developed in the "gc-hooks" branch
jvesely has joined #pypy
jvesely has quit [Remote host closed the connection]
<antocuni>
so you have more context to understand what was going on at that time. With git, this knowledge is simply lost
jvesely has joined #pypy
<Dejan>
khm... yes if you deleted the branch (after merge), right?
<arigato>
I guess it's a matter of style, but our current style is just too much oriented to branches. More generally it also prevents me from using git seriously (I tried for one full year on another project and really failed)
<Dejan>
if it is still there, git branch --contains <commit ID>
<Dejan>
will give you the branch name
<arigato>
we know there are approximations, now go away we already discussed this a lot :-)
<Dejan>
okidoki!
<arigato>
(I can give real-life use cases in which that command cannot give you a unique branch name)
<arigato>
(and sorry about the tone, I didn't mean to be angry)
<Dejan>
do not worry, i understand
<Dejan>
:)
<antocuni>
arigato: I pushed 3c442802de7f, although it seems that keenan is no longer printing commits here
<arigato>
antocuni: ups, this fix is partial
<arigato>
the point of _raise_error_maybe() is that if it returns normally, you should retry
<arigato>
or else we should have called with eintr_retry=False
<arigato>
pushed stuff too, which I hope doesn't break the rest of pypy
<antocuni>
ah I see
<antocuni>
but then we are really missing tests :(
<antocuni>
ronan: it seems it's a job for you ^^^ :)
<arigato>
uh, not sure I see what you see
<arigato>
where are we missing test? somewhere precise?
<antocuni>
it's a more general: this logic is complex and all the tests we have are passing right now
<antocuni>
so before introducing even more complex logic, we should have a failing test to fix
<arigato>
ah, you mean tests for the _raise_error_maybe => _always
<arigato>
I thought you meant for the general fix against "raise None"
<antocuni>
yes, I mean tests for this logic inside fcntl
lesshaste has joined #pypy
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
micisuta has quit [Ping timeout: 268 seconds]
jacob22_ has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
idnar has quit [Remote host closed the connection]
idnar has joined #pypy
jvesely has quit [Quit: jvesely]
jacob22_ has quit [Read error: Connection reset by peer]
jacob22_ has joined #pypy
idnar has quit [Remote host closed the connection]
idnar has joined #pypy
Rhy0lite has joined #pypy
micisuta has joined #pypy
<antocuni>
what happens if I lltype.scoped_alloc() something and then I read the content after it has been freed? (BEFORE translation)
<antocuni>
I would expect to get some sort of error/warning, but it seems I am not?
<antocuni>
in particular, I'm talking about hpy_universal/interp_module.py:attach_legacy_methods in the hpy branch
<antocuni>
there is a scoped_alloc of PyMethodDefP, then I (indirectly) pass a PyMethodDef to cpyext.W_PyCFunctionObject, which saves it as "self.ml"
<antocuni>
so I would expect it to crash when it tries to read self.ml.c_ml_meth
<antocuni>
but what I observe is that the tests are passing, and after translation it is segfaulting
micisuta1 has joined #pypy
micisuta has quit [Ping timeout: 272 seconds]
micisuta1 is now known as micisuta
camelCaser has quit [Ping timeout: 268 seconds]
camelCaser has joined #pypy
<antocuni>
oh, I see; pymethods is indeed marked as DEAD, so doing e.g. "pymethods[0]" after the scoped_alloc raises RuntimeError
<antocuni>
however, if I read pymethods[0] before it's freed, then I can use the result even after the free
<antocuni>
I wonder whether there is a way to get a failing test from this code, or whether I should fix it blindly :(
micisuta has quit [Ping timeout: 265 seconds]
<arigato>
ah
<arigato>
I bet it's possible to hack around until this case is also detected
<arigato>
unsure it's worth the effort
<antocuni>
yeah, I guessed so
<antocuni>
it's probably easier to just fix it
<antocuni>
fwiw, I am going to create a W_StaticData (or some name like that) which holds the PyMethodDef* and to stick it inside w_mod
<antocuni>
unless you have a better idea for managing the lifetime of this array
<antocuni>
(and I suppose we are going to have similar problems in the future, so W_StaticData should be able to hold them all)
<mjacob_>
arigato: of course, it would be fine for me to attend only part of the days, but i remember that in the last years it was harder to get rooms on the weekend, and making mar 1 the day of arrival would avoid that
<arigato>
it's hard to avoid weekends if the sprint is 7 days long
<mjacob_>
yes, it will be over one weekend in any case
<cfbolz>
arigato: cpython 3.7 allows function calls with more than 255 arguments. I should probably work on making sure that that still happens in constant stack space, like we did for building huge lists/dicts/sets/tuples, right?
<arigato>
anyway, these stranges dates are an attempt to squeeze people's availability, but e.g. if matti says no in the end, we can certainly push the dates a few days later
<arigato>
cfbolz: do I even want to know what kind of horrible hack it uses?
<cfbolz>
arigato: on cpython?
<arigato>
yes
<cfbolz>
it's kind of reasonable actually
<cfbolz>
CALL_FUNCTION doesn't support kwargs any more (we haven't followed that)
<cfbolz>
so extended_args simply supports many args
<cfbolz>
in more complicated cases, a tuple is built and f(*tup) is used
<arigato>
OK
<cfbolz>
so yes, one thing we could do is follow CPython again on the CALL* bytecodes
<arigato>
right
<cfbolz>
doesn't win us too much, but relatively clean
<arigato>
yes
<cfbolz>
ok, I'll do that
<arigato>
but also, if there are more than N arguments we should probably always fall back to the constant-stack tuple-building logic
<cfbolz>
arigato: yes
<cfbolz>
That would be my plan too
<cfbolz>
arigato: if you find some time to look at the sre changes of 3.7 that would be great
<arigato>
no promizes but I can try
<mjacob_>
arigato: yes, i just wanted to remark my preferences for the case that others have similar preferences, too. and you should give more weigth to matti's preferences since he has a longer journey.
<cfbolz>
Thanks :-)
<mjacob_>
arigato: thanks for organizing it, btw!
<arigato>
np! (*2)
jvesely has joined #pypy
jvesely has quit [Ping timeout: 260 seconds]
jvesely has joined #pypy
omry has joined #pypy
micisuta has joined #pypy
micisuta1 has joined #pypy
micisuta has quit [Ping timeout: 265 seconds]
micisuta1 is now known as micisuta
Ai9zO5AP has joined #pypy
jvesely has quit [Quit: jvesely]
jvesely has joined #pypy
lritter has quit [Ping timeout: 258 seconds]
lritter has joined #pypy
speeder39_ has joined #pypy
mattip has joined #pypy
<mattip>
it seems I will not be able to make the sprint this year, too much else happenning
jacob22_ has quit [Read error: Connection reset by peer]
jacob22_ has joined #pypy
Rhy0lite has quit [Quit: Leaving]
CrazyPython has joined #pypy
adamholmberg has quit [Remote host closed the connection]