cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "nothing compares to the timeshifter, my personal polar expedition in software" - pedronis
<danchr>
fijal: it should be fine for building, but the issue is that PyPy3 no longer buids against the old and deprecated OpenSSL included with OS X
<danchr>
later versions of the OS dropped the headers (but retained the library) so upgrading wouldn't fix the issue, ironically, only make it worse by also affecting PyPy2
<danchr>
fijal: Mercurial has a 10.12 builder running on a Mac mini with 8GB memory — they might be able to share it a bit with PyPy
jcea has joined #pypy
arigato has quit [Ping timeout: 248 seconds]
<danchr>
hmmm, it's offline
<marmoute_>
danchr: I know Sean (smf) worked on getting another on online
<marmoute_>
danchr: hi by the way, how are you doing ?
<danchr>
marmoute_: I'm well, thank you — started at a new job about a year ago :)
<danchr>
I still use Mercurial, although we use Git & GitHub here…
<marmoute_>
Where/what for are you using Mercurial ?
<danchr>
Well, everything except Git repositories that rely heavily on submodules
<marmoute_>
So you use hggit for everything ?
<danchr>
yeah
<danchr>
it mostly works, and lets me keep relying on history evolution and shared repositories — which I use profusely
<danchr>
$ locate '*/.hg/sharedpath' | wc -l
<danchr>
33
<danchr>
marmoute_: I think this is getting every so slightly off topic for this channel ;)
ronan has joined #pypy
ronan has quit [Read error: Connection reset by peer]
linkmauve1 has joined #pypy
<linkmauve1>
Hi, with pypy3 5.9.0, whenever I press a key in poezio (a curses XMPP client) I get “TypeError: initializer for ctype 'uint32_t *' must be a compatible pointer, not cdata 'int[1]'”, this seems like a regression compared to #535.
<linkmauve1>
Sorry I didn’t check before the release. :(
<linkmauve1>
This happens in:
<linkmauve1>
val = lib.wget_wch(self._win, wch)
<linkmauve1>
File "/opt/pypy3/lib_pypy/_curses.py", line 409, in get_wch
arigato has joined #pypy
<linkmauve1>
According to 223ff388e219 it should be working.
<arigato>
linkmauve1: this should help, can you check?:
<linkmauve1>
How can I rebuild just this shared object again?
<arigato>
by running "pypy _curses_build.py"
<arigato>
but I think you don't even need to rebuild it
<arigato>
just apply the changes to _curses.py
<linkmauve1>
Segfault now. ^^'
<linkmauve1>
Hmm, the second time it didn’t segfault.
<linkmauve1>
Maybe because I’m now running it in gdb.
<arigato>
:-/
<linkmauve1>
No, it also works outside of gdb.
<linkmauve1>
And poezio seems completely usable. ^^
<linkmauve1>
Oh, I still have the coredump in journald.
<linkmauve1>
It’s totally not helpful though, ArchLinux didn’t build pypy3 with debug symbols…
<linkmauve1>
Here is the stack trace, it looks useless but if you think it isn’t I can give you the core file: https://linkmauve.fr/files/pypy3.txt
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
<linkmauve1>
So, aside from the memory consumption (43 MiB under cpython, 129 MiB under pypy3), poezio seems to work perfectly with this patch now, thanks!
<arigato>
the crash seems to be inside a callback from ares_query() called with cffi
<arigato>
I hope you won't continue to get random rare crashes
<linkmauve1>
I built pycares and aiodns as is, the first one depends on cpyext IIRC.
<linkmauve1>
I don’t think I will run poezio in pypy3, AFAIK the ARMv7 JIT is still not enabled by default, and with the huge increase of memory compared to cpython it won’t run well on my server anyway (which has only 512 MiB, not extendable).
<arigato>
linkmauve1: we have a ARMv7 JIT. Maybe arch(?) linux on ARMv7 doesn't include the jit in its pypy3 builds? It doesn't really make sense for us
<arigato>
Mudcastle: yes?
<Mudcastle>
arigato: A module I'm trying to convert to work with Pypy is copying sys.path into the PYTHONPATH environment variable before launching a subprocess python, and this seems to have the effect of overshadowing the built-in cStringIO since /opt/pypy/lib_pypy (and consequently the cStringIO.py file) falls under that, preventing the built-in import.
<Mudcastle>
Is this a failing of Pypy or the module?
<arigato>
that's certainly relying on a detail, but getting this kind of detail exactly like CPython is usually part of PyPy's job
<Mudcastle>
I can submit a bug report then.
<arigato>
yes, please. I'm failing to reproduce it, be sure to include all steps in the bug report
<Mudcastle>
Of course.
<linkmauve1>
arigato, actually ALARM doesn’t even include pypy and pypy3, maybe that’s something that should be fixed on their end now.
<linkmauve1>
I’ll report them an issue then, thanks. :)