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
nulano has quit [Ping timeout: 272 seconds]
nulano has joined #pypy
lritter has joined #pypy
lritter has quit [Quit: Leaving]
jcea has quit [Ping timeout: 260 seconds]
oberstet has quit [Quit: Leaving]
lritter has joined #pypy
lritter has quit [Ping timeout: 264 seconds]
Taggnostr has quit [Remote host closed the connection]
Taggnostr has joined #pypy
_whitelogger has joined #pypy
_whitelogger has joined #pypy
jacob22_ has quit [Read error: Connection reset by peer]
<antocuni>
arigato: from the traceback it looks like "yum" is trying to connect to some HTTP server but fails due to an ssl error
<arigato>
Yes
<arigato>
Any idea at all about what I can do now?
<antocuni>
in theory, you can download the docker image locally and get a shell inside it to try things
<antocuni>
but in practice, I am failing to get a shell inside this specific image and I don't know why
<antocuni>
ok, it seems to be a docker problem of bencher7, because the same command line works on my machine
<antocuni>
arigato: so, what I did is:
<antocuni>
docker run -it quay.io/pypa/manylinux1_x86_64:2020-10-06-c4a4a7c # this gives you a bash prompt inside the docker image
<antocuni>
and from inside the docker:
<antocuni>
yum install -y texinfo
<antocuni>
and it seems to work. So it doesn't seem a problem related to the docker image (e.g. ssl version too old or so) nor the web server
oberstet has joined #pypy
<antocuni>
so I suggest to just restart the job and see whether the error is gone magically
<arigato>
Ok
<arigato>
because one problem never comes alone:
<arigato>
now I can no longer push to ssh://hg@foss.heptapod.net/pypy/cffi
<antocuni>
horray technology :(
<antocuni>
arigato: FWIW, I can successfully clone that repo
<antocuni>
arigato: but if you want to push to rerun the job, it's not strictly necessary. There should be a button to restart the job directly inside azure pipelines
<arigato>
antocuni: OK, the error seems to have disappeared. *shrug* internet technology
<antocuni>
good :)
<arigato>
another minor bug report about the issue tracker itself of heptapod: when I post, the date is initially set to "in two minutes", which goes down to zero and then to "xxx ago". Looks like a small unsynchronized time issue :-)
<antocuni>
arigato: it might be that it's using your local browser time to compute "xxx ago"
<antocuni>
actually, it's likely that it's using that, else it has no chances to update it in real time without doing an http request
<arigato>
ah
<arigato>
I thought it would be using a combination: get the initial server time, and then use delta times locally (so not depend on my absolute local time)
<arigato>
but indeed, my computer's clock is two minutes late. it's time to debug my time
<antocuni>
FWIW, it seems it's using this JS library to do that: https://timeago.org/
<antocuni>
investigating whether it's using the absolute local clock or a delta is left as an exercise to the reader
<arigato>
thanks :-)
<arigato>
mattip: re issue #3348: maybe it occurs because of the exact details of libexpat.so?
<arigato>
I would suggest to try in Ubuntu 20.04, if you know how to set that up easily
<mattip>
I am using the tarball as downloaded, which vendors lib/libexpat.so.1
<arigato>
ah right
<mattip>
but maybe the reporter is locally compiling?
<arigato>
unlikely
<arigato>
his "pypy3" reports the exact same version info as the one from the 7.3.3 tarball
<arigato>
including the compilation date, so yes
<mattip>
ahh, right, missed that thanks
<mattip>
I even tried creating virtualenvs via
<mattip>
pypy -mvenv /tmp/pypyv1
<mattip>
and
<mattip>
virtualenv -p pypy3 /tmp/pypyv2
<mattip>
still cannot reproduce
<arigato>
mattip: unrelated: I should try to finish the py3.7-rsre branch
<mattip>
would be nice to add in the rutf8-simd one as well
<arigato>
it seems to be 30e0be7f8135, according to "hg bisect"
<arigato>
this checkin looks wrong to me, because this general utf8 decoding function might be called from many places
<arigato>
I think what occurs is that it's called from module/pyexpat somewhere,
<arigato>
and it passes "final=False" and that logic in 30e0 makes it ignore "final=False"
<arigato>
so you get a decoding error, even though you shouldn't
<arigato>
it only shows rarely because, I guess, module/pyexpat calls it on large chunks of data, and randomly the data boundary happens to be in the middle of a utf-8 multibytes char code
<arigato>
It would seem much safer to add another parameter that is only set to True from cpyext, to make sure the behavior doesn't change for other callers
<arigato>
mattip: I'll need your approval I think. The rpython-rsre-for-37 tests show a bit more failures than usual on default, but as far as I can tell they are all of the kind "random stuff" and entirely unrelated to regexps in any way
Exrney has joined #pypy
* mattip
looking
<mattip>
I think it is OK. There is some interaction between running rpython and own on linux64, maybe bencher is getting overloaded
<Exrney>
`ensurepip` is giving me an invalid utf-16 error when I try to run it
<Exrney>
hmm?
<mattip>
Exrney: that was for arigato
<Exrney>
sorry, my messages didnt seem to be going through
<Exrney>
ah
<Exrney>
sry
<mattip>
what platform are you on?
<Exrney>
windows 10
<Exrney>
it appears to be caused by winreg
<Exrney>
```
<Exrney>
oops
<Exrney>
File "C:\Users\askul\AppData\Local\Programs\pypy3.7-v7.3.3-win32\lib-python\3\mimetypes.py", line 248, in enum_types