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
altendky has joined #pypy
camelCaser has quit [Read error: Connection reset by peer]
Guest888 has quit [Remote host closed the connection]
<mattip>
marmoute (or anyone who uses gitlab): for a gitlab newbie - is the common workflow to make a merge request on a branch in the same repo?
<mattip>
I amused to github where you fork and make a pull request from a different repo
lazka has joined #pypy
<lazka>
mattip, both works fine (also on github..)
<mattip>
lazka: thanks
<mattip>
i guess you need a commit bit to push without forking
<lazka>
one difference is that on a fork your CI runs in the context of the fork, so you only get access to shared runners
altendky has joined #pypy
adamholmberg has joined #pypy
<lazka>
You can also protect branches so that only maintainers can push there, but normal devs can still create other branches, which maintainers can then merge etc
<mattip>
nice
<lazka>
and compared to github there is a project wide merge policy: merge or rebase or rebase+merge, while in github you can decide for each PR
lazka has quit [Remote host closed the connection]
adamholmberg has quit [Ping timeout: 240 seconds]
<marmoute>
mattip: this is a valid workflow for gitlab. And the main workflow we are pushing for in heptapod so far
TheNewbie has joined #pypy
dddddd has joined #pypy
adamholmberg has joined #pypy
adamholmberg has quit [Ping timeout: 260 seconds]
TheNewbie has quit [Read error: Connection reset by peer]
altendky has quit [Quit: Connection closed for inactivity]
kipras has joined #pypy
kipras has quit [Client Quit]
_whitelogger has joined #pypy
jcea has joined #pypy
jcea has quit [Excess Flood]
jcea has joined #pypy
<tumbleweed>
you can use that workflow in github too. If you have push access to a repo, why would you need your own fork?
<tumbleweed>
mattip: fair enough (re links)
<tumbleweed>
I'd love to have the snap upstream, and not need my own repos for it, but those couple of patches make a big difference, that they're only appropriate for snaps
kipras has joined #pypy
<mattip>
tumbleweed: now that PyPy is shipping a "portable" build, will we run into platforms where terminfo and tcltk are incompatible?
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<arigato>
mattip: build_cffi_import could be moved somewhere else than directly in lib_pypy. All the _*_build.py too
<arigato>
ah, sorry, wrong way around: build_cffi_import is not in lib_pypy
<arigato>
maybe we could create a subdirectory of lib_pypy and put build_cffi_import and all the _*_build in it
<tumbleweed>
mattip: the issue I had with terminfo and tcl is that the snap includes the C libraries, but they were finding data from the host, that wasn't compatible
<tumbleweed>
that's not an issue you'd have
<mattip>
arigato: tools ? scripts ?
<arigato>
build?
<tumbleweed>
build feels like a build output directory
<mattip>
tumbleweed: even if we are shipping the curses module linked to centos6-based libraries?
<tumbleweed>
you're not including the centos6 based libraries, just hoping that their ABI is available
<arigato>
fine with tools or scripts then
<tumbleweed>
a snap is like a container - the libraries are there, and mostly relying on rpath to be used
<tumbleweed>
(a lazy container, rpath rather than chroot)
<tumbleweed>
without that terminfo hack, the snapped pypy REPL had no readline for me :/
<mattip>
pypy/lib on the rc3 builds contains libtinfow.so.6, libncursesw.so.6 from the manylinux2010-based docker build
<tumbleweed>
ah, I see
<tumbleweed>
yes, you may share those problems, then
<mattip>
and lib_pypy/_curses_cffi.pypy-73.so link to them
<mattip>
i see that squeaky-pl's portable-pypy build ships tcl and tk directories with the build
<tumbleweed>
I bet 99% of users never touch tcl/tk
<mattip>
tumbleweed: if you have a few minutes, could you check that the rc3 build's readline works where the snap without the patches didn't?
<tumbleweed>
so, I notice that it works for me, straight from your tarball
<mattip>
+1
<tos9>
mattip: (re: scientific fun, of course just as I got things working, scipy has broken something with one of the releases they did last week, so now trying to figure that out)
<mattip>
there is an issue for it, and I am almost done writing the test for the fix
* tumbleweed
tries without those patches
<tumbleweed>
then I need to go board a plane to ZA
<mattip>
ahh, beautiful. Enjoy!
<tumbleweed>
so, REPL is good, Tk is broken
<tumbleweed>
sounds about right
<mattip>
just for the record, what platform is that?
<mattip>
and thanks again for trying it out
<tumbleweed>
so, the snap is Ubuntu 16.04
<tumbleweed>
the host is Debian testing
<tumbleweed>
amd64
<mattip>
ok, I will try to fix the rc3
<tumbleweed>
what are you going to fix? bundle tcl?
<mattip>
sure, we do on windows, and I think there are linux tarballs of python that bundle it too
<tumbleweed>
cool, sounds sane
<tumbleweed>
I should stop including extra versions of these things in the snap, now that you're bundling them
<mattip>
we could then upstream the snap yaml
<tumbleweed>
yeah
<tumbleweed>
although launchpad builds probably won't work from hg repos
<tumbleweed>
but you could build and upload from pypy infra
<tumbleweed>
anyway, gotta go find my plane
<mattip>
bye
<mattip>
the untarred pypy is 150MB, tk + tcl add another 5.3MB.
marky1991 has joined #pypy
<mattip>
libpypy-c.so alone is 68MB, lib-python is 35MB. We will not win awards for a lightweight app
adamholmberg has joined #pypy
<mattip>
tos9: numpy works?
adamholmberg has quit [Ping timeout: 260 seconds]
<tos9>
mattip: I couldn't check because the package I just finished wants scipy too, and now won't even install on py3 (but pinning down to scipy<1.4 works again, so now I'll do that and check)
<tos9>
Actually I guess maybe it makes sense to have a vanilla build that all it does is build and test numpy on macos
<tos9>
So maybe I should do that instead.
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
Ai9zO5AP has joined #pypy
created has joined #pypy
<created>
Question - does anyone use rpython (seriously) other than pypy?
<simpson>
created: We use it for the Monte language's reference interpreter. ^^ is a really good list of other examples. What do you want to know?
<created>
Was thinking of playing with it maybe (not for anything serious)
<created>
But I'm a bit worried about 30 minutes JIT compile times? (if I understand correctly)
marky1991 has quit [Ping timeout: 268 seconds]
<created>
(Though I imagine it's possible to compile a non-JIT and test that initially?)
<created>
s/compile/translate/g
<cfbolz>
created: you test it without translating, usually
<cfbolz>
(it's just python code, after all!)
<created>
Ah, neat
<created>
I'll give that rpython BF tutorial a go
<simpson>
Translation times vary depending on the size of the interpreter that you're translating. If your language is small and simple, then it can take under a minute. The Monte build takes about 15min in translation. Just make sure not to run out of RAM!
<created>
(I thought you just didn't have 64bits of pypy at all, but I then saw various 64-bit linux builds)
<created>
I did read that, but I didn't get it - what's so special about windows as opposed to linux, other than the size of long?
<mattip>
it's that we use Signed pretty much everywhere in the code, and that is now translated into long. It needs to be long long on win64, but that might break things
<mattip>
we should probably edit the first paragraph about sys.maxint, since it doesn't exist on python3
<created>
How do linux64 builds work? They have Signed translate to a 64-bit long, equivalent to long long, no?
<cfbolz>
mattip: it's about sys.maxint on the translating python
<cfbolz>
(which stays python2
<cfbolz>
)
<created>
(And I'd imagine sys.maxint would be 2^64-1 on linux64, if it corresponds to long)
<mattip>
ahh, and grep sys.maxint shows up over 400 times in rpython
<created>
So in short, rather than converting long to Signed, I would expect converting long to 'long long' or some typedef - what am I missing that makes this impossible or difficult?
<mattip>
to start with, it needs someone willing to work on windows
<created>
I have seen your tests fail on windows more than on other platforms :]
<created>
I wanted to give it a try yesterday, but the local deps on windows haven't been updated for a while and don't seem to work anymore and getting such stuff to work is a lot of annoying pain