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
lritter has quit [Ping timeout: 240 seconds]
lritter has joined #pypy
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
lritter has quit [Remote host closed the connection]
xcm has quit [Read error: Connection reset by peer]
xcm has joined #pypy
asmeurer has joined #pypy
gour_ has joined #pypy
tsaka_ has joined #pypy
gour has quit [Ping timeout: 256 seconds]
dddddd has joined #pypy
asmeurer has quit [Quit: asmeurer]
Ashleee has quit [Quit: Leaving... bbl]
Ashleee has joined #pypy
gour_ is now known as gour
thrnciar has quit [Ping timeout: 260 seconds]
thrnciar has joined #pypy
<mjacob>
antocuni: can you try the third command again with `hg-git==0.9.0a1`?
<mjacob>
antocuni: the HTTP auth broke a while ago when the HTTP library used by the Git access library changed
oberstet has joined #pypy
<antocuni>
mjacob: it works! Thanks
<mjacob>
antocuni: between 0.8.13 and 0.9.0a1 we fixed the case when username and password are provided in the url
<antocuni>
does it also work if I put the credential inside hgrc?
<antocuni>
in an [hgauth] section?
<mjacob>
antocuni: not yet
<mjacob>
antocuni: we'd like to recover lazily getting the password, but this is not easy with urllib3, which is used for HTTP access (previously, with the urllib from standard library) it was easy
<antocuni>
so, the only way for now is to use the user:password@github.com syntax, right?
<mjacob>
for now, yes
<antocuni>
ok, this should be enough for my use case. Thank you a lot
<mjacob>
antocuni: if i remember, i'll let you know once we fixed case 1 and 2
<dholth>
Know anything about debugging the greenlet module in cffi embedding mode in pypy3 nightly?
<dholth>
continulets seem to work a little better
<mattip>
is the question "why are continulets better?" or "can I stop in a debugger?" or something else?
<dholth>
I'm porting the old pypy uwsgi plugin plus the asyncio.c event loop to the cffi embedding interface. It seems like the websocket chat example is hanging. maybe locks? https://github.com/unbit/uwsgi/pull/2146
<dholth>
so 'can I stop in a debugger' would be the question
<dholth>
or 'are greenlets broken in pypy3 in some way'
<dholth>
or 'do they interoperate with C'
<dholth>
the continulets-based websocket chat demo does work.
<dholth>
imho it is cool
Ododo has joined #pypy
<Ododo>
Hello all. my question is about cffi: I have a bunch of C headers files that i would like to parse automatically and add all the structures in ffi.cdefs. So can i use them in python code. This also means resolving all the types because some structures embeds other structures. Do you know a script that can do such thing ?
<dholth>
That's just the filter_by_file function. The other part is less robust.
<Ododo>
thanks. but maybe i could just read the headers content and put the string in cdef don't know if it would work like that..
thrnciar has quit [Ping timeout: 264 seconds]
<mattip>
Ododo: there is no generic script. You may have some luck running the c-preprocessor over them and feeding that to cdef
<mattip>
another strategy is to use regex and replace to remove offending includes and defines
<Ododo>
ok. in my case there is multiple headers files that share definitions, so maybe running the preprocessor and compute a kind of a unique header could be the solution.
<dholth>
You run it something like cat ../../uwsgi.h | gcc -E - -D "__attribute__(x)"= | filtercdefs.py > output . Usually there is a set of filenames that have most of the definitions you are interested in.
<dholth>
And the preprocessor can delete things like __attribute__ that pycparser doesn't want
<Ododo>
yep. so i think i'll go for something like that... =)
<dholth>
would you believe the redis websocket demo works better when redis is running. not 100% though.
<Ododo>
Basically i have a c program thats emmbed my cffi scripts. The program allocates structures based on it's headers. But i want to be able to access a reference to a structure at any time and manipulate that structure in-memory from cffi.
<Ododo>
if that is possible ..
<dholth>
sounds like a typical use case
<dholth>
and, mine works. thanks for the cool library!
<dholth>
it turns out it wasn't greenlets' fault at all, just swallowed exceptions
<simpson>
One of the worst of the ancient foes of concurrency.
<dholth>
null'oh, swallower of exceptions
oberstet has quit [Quit: Leaving]
<mattip>
interesting. Azure pipelines has support for windows 32 bit pypy apparently
<antocuni>
mattip: azure pipeliens or github actions?
<antocuni>
(or it's the same?)
<mattip>
this specifically is azure pipelines. I think underneath it is the same, who knows
<mattip>
this is all I needed to do to get win32 pypy into numpy-wheels azure build
asmeurer_ has quit [Quit: asmeurer_]
<antocuni>
wonderful!
<mattip>
PYTHON_VERSION: "pypy3"
<mattip>
PYTHON_ARCH: "x86"
<mattip>
and then add a task: UsePythonVersion@0
<antocuni>
mattip: is numpy still developed for python2.7, or the newest versions are py3 only?
<mattip>
py3 only, we tore out python2 support in the next version
<antocuni>
would it be possible to upload pypy2 wheels for the latest numpy which still work? This way I could remove numpy from my pypy-wheels repo
<mattip>
dunno. I guess I could ask the keeper of the keys to just take your wheel and upload it. It is just linux64, correct?
<mattip>
and does it have OpenBLAS ?
<antocuni>
that's one of my points: I am not confident at all that the numpy I am building it's equivalent to the official ones
<antocuni>
e.g. IIRC I am installing openblas from ubuntu packages, but numpy uses a custom build?
zmt01 has joined #pypy
<mattip>
yes, we bundle a version in the wheel
<antocuni>
yes me too
<antocuni>
else it would not be compatible with manylinux :)
<mattip>
cool
<antocuni>
but I am probably bundling a slightly different version
<mattip>
numpy only builds a linux64 wheel for pypy3 7.3.1 right now. I want to add a win32 one next
<mattip>
can't people get the equivalent to your wheel via apt now? It is ~18 months since the last release
<antocuni>
like, apt install pypy-numpy or something like that? It doesn't seem to exist
zmt00 has quit [Ping timeout: 244 seconds]
<mattip>
too bad
<mattip>
maybe once we have the complete set of wheels for pypy3, aarch64, ppc64le, s390x I could convince them to go back and do one last python2 release
<mattip>
but I doubt it
<antocuni>
sounds too complicate
<antocuni>
well, too bad I suppose... people can continue to use my repo