<zaytsev>
hmmm the builds still don't run through, i'm very disappointed. it can find the damn tools when i run it under pypy on command line though. maybe i should have tried also cpython, and/or rebooted the machine
<zaytsev>
windows is full of strange unpleasant dark vodoo magick
<mattip>
zaytsev: :(
<mattip>
fijal: pycon USA? not planning at this stage
<zaytsev>
maybe registry changes are not applied for running service or something like that. the env vars were affected
<mattip>
would be nice to get someone into the language summit if possible
<mattip>
it is May 1 in Cleveland
antocuni has quit [Ping timeout: 245 seconds]
<fijal>
Cleveland is quite a bit out of the way for a lot of people....
xcm has quit [Remote host closed the connection]
themsay has quit [Ping timeout: 268 seconds]
xcm has joined #pypy
jcea has joined #pypy
<cfbolz>
oberstet: cool, no, that's great
<cfbolz>
fijal: didn't you plan to do a announcement blog post about arm64?
<fijal>
cfbolz: we have nothing more to say than that's on that Nov one
dddddd has joined #pypy
<cfbolz>
fijal: ah, seems I forgot about this one, sorry
Ai9zO5AP has joined #pypy
wleslie has quit [Ping timeout: 250 seconds]
Ai9zO5AP has quit [Read error: Connection reset by peer]
i9zO5AP has joined #pypy
i9zO5AP has quit [Client Quit]
wleslie has joined #pypy
Ai9zO5AP has joined #pypy
antocuni has joined #pypy
Rhy0lite has joined #pypy
<ebarrett>
hi!
<ebarrett>
i've been greeping around in the pypy sources to see if you guys do anything if a trace is interrupted by a signal
<ebarrett>
*grepping
<ebarrett>
in theory, the signal handler could land you back in python code, right?
oberstet has quit [Quit: Leaving]
<fijal>
ebarrett: the signal handler itself is just setting flags
<fijal>
in python you have to wait to an obvious point before you actually deal with it
<ebarrett>
so you regiter a catch all handler and pass it up to the user later?
<ebarrett>
(as a flag)
<fijal>
"catch all"?
<fijal>
yeah I think so
<ebarrett>
right
<ebarrett>
so it's possible for a mad user to use the FFI to set their own handler and call back into python and re-enter the trace recording code?
adamholmberg has joined #pypy
adamholm_ has joined #pypy
adamholmberg has quit [Ping timeout: 244 seconds]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<cfbolz>
ebarrett: no
<cfbolz>
ebarrett: the "own handler" wouldn't be a signal handler in the C sense
<cfbolz>
it would also only be called at a safe spot later
<cfbolz>
ah, wait
<cfbolz>
I see
<cfbolz>
with FFI
<ebarrett>
yeah
<ebarrett>
nasty, huh?
<cfbolz>
that's probably a good way to generate crashes
<cfbolz>
ebarrett: but you aren't allowed to do arbitrary things in signal handlers in C, are you?
<ebarrett>
you shouldn't do anything substatial, no
<ebarrett>
but, you can, if you are sick
<Alex_Gaynor>
there's a pretty restricted set of functions that are async signal safe, not even malloc in most libc
<ebarrett>
yeah, there's a list in the manpages for the signal funcs
<ebarrett>
calling back to Python seems like an awful idea
<cfbolz>
yes, will immediately use forbidden stuff
<cfbolz>
so in other words, you get what you deserve :-P
<Alex_Gaynor>
You definitely can't call Python from an async-signal-safe context. The _best case scenario_ for doing that would be summoning demons from the POSIX netherworld.
<ebarrett>
I tend to agree :)
<kenaan>
mattip unicode-utf8-py3 a7867a23009b /pypy/objspace/std/: finish f287dec62c4e for swapcase, capitalize
<antocuni>
I tried with a nightly and it seems to work, so I assume that it has been fixed inside pypy at some point?
<mattip>
right, it is "known" - as in there are multiple issues on both the NumPy and PyPy issue tracker
<mattip>
we should release 7.0 already
<antocuni>
yes, it sounds like a good idea
<mattip>
I was hoping to get unicode-utf8 in, it gives a nice speed bump
<antocuni>
how long do you estimate it would take to merge it?
<mattip>
we should discuss it at the sprint, it is a pretty big change and needs some review
<antocuni>
right, it makes sense
<mattip>
OTOH, we could release it as a 7.1 since the changes should only be internal
<antocuni>
what about releasing 6.1 now which fixes numpy, and leave 7.0 for utf8 which seems like a big change to me?
<antocuni>
or 7.0 and 7.1 as you propose
<antocuni>
but I think that having a broken numpy is very bad :(
<mattip>
it comes down to priorities: keep fixing the last little niggles so we can merge unicode-utf8, or release
oberstet has joined #pypy
<mattip>
antocuni: it just means people need to download a buldbot nightly instead of a bitbucket release
inhahe_ has joined #pypy
<mattip>
it's not like we do special vetting on the commit we choose to release
<antocuni>
yeah I know, but it's suboptimal for various reasons; in particular, I cannot build wheels for non-released pypys
<mattip>
ahh
<antocuni>
so if you integrate it in a broader build process, it makes everything much slower
<antocuni>
also, from a marketing point of view, telling people "this bug has been fixed in pypy 6.1" sounds better than "download a nightly build from an obscure location" :)
<antocuni>
I am willing to help with the release if you want; I don't really know what steps are involved though as I didn't do it for ages now
inhahe has quit [Ping timeout: 268 seconds]
ronan has quit [Ping timeout: 252 seconds]
<mattip>
we would have to go without ARM, the builders have been down since Dec
<mattip>
since I tend to forget, I try to keep that up-to-date
<mattip>
the hardest thing is the release notes, I try to go through the commits since the last release and summarize
<mattip>
using the whatsnew as a base
<mattip>
I think it should be 7.0 since we changed cpyext headers
<mattip>
and not 6.1
<antocuni>
in theory the whatsnew.rst is there precisely to avoid to have to go through all the commits manually
<mattip>
I have a script to do the download-from-buildbot, repackage, generate sha256, upload-to-bitbucket, so that part is simple
<mattip>
in theory
<mattip>
many meaningful commits are not on branches
<antocuni>
about buildbots: I wonder whether we should move to github/travis at some point; it seems we are not very good at maintaining our building infrastructure
<mattip>
at numpy we are using azure, travis, and shippable (for ARM64)
lritter has quit [Ping timeout: 245 seconds]
<mattip>
azure is pretty good, they have mac, linux, windows
<antocuni>
is it for free?
<mattip>
but only integrate with github
<mattip>
yes, up to 10 jobs
<mattip>
let me check the time limit
<mattip>
they claim "unlimited minutes for public repositories"
ronan has joined #pypy
* mattip
off, bbl
<antocuni>
sounds good; another advantage of doing it this way is that if we set up things correctly, we automatically run all the tests when we push, even on branches
<mattip>
antocuni: it would be great if you could start the process toward 7.0
<antocuni>
instead of having to manually trigger the builds and check things before merging
<antocuni>
mattip: I'll try, but please have a look at what I'll do :)
<mattip>
thanks
<cfbolz>
mattip: I can do the merge to unicode-utf8-py3 if you want
<mattip>
another benefit of you doing it is improvements to the process documentation
<mattip>
cfbolz: yes please
<antocuni>
ah, I suppose I need to make a branch for both pypy2 and pypy3?
<cfbolz>
ok. should get to it tomorrow morning
<mattip>
right, like release-pypy2.7-v7.x, release-pypy3.5-v7.x, release-pypy3.6-v7.x
<mattip>
(we should do an alpha 3.6)
<cfbolz>
imo that's putting the hurdle for the release too high
* mattip
gone
<cfbolz>
or should we just say "whatever works works" for 3.6?
<antocuni>
my idea for this release was "let's do something quick so that we can fix numpy"
<cfbolz>
right
<cfbolz>
+1
<antocuni>
so I am more of the idea of not doing an alpha 3.6, which probably takes time