<arigato>
is this another attempt at justifying why git would not have worked with our work style? :-)
<mattip>
yup
<arigato>
just to be clear, after looking into the matter, I'm not saying now "hg is better" or "git is worse", but instead I agree that the kind of repo you end up building is a bit different in both cases
<arigato>
so for a large repo built using one the tools, switching to the other tool can create a lot of friction
<mattip>
when I am doing archeology on numpy commits, I have to find the merge-to-default commit, figure out which github PR this is, and only when I go to github can I figure out what the commit was part of
<mattip>
anyhow, for the matter at hand, I think eintr_retry=False is correct
<tos9>
mattip: (FWIW I know this conversation was had already :D but just in case you haven't seen them before, maybe you'd find `git log --merges <YOURCOMMIT>` or https://github.com/mhagger/git-when-merged handy)
<tos9>
ls
ionelmc has quit [Quit: Connection closed for inactivity]
<arigato>
I've written this comment in py3.6-sandbox-2 (which should be merged to py3.6 at some point):
<arigato>
about def urandom() in interp_posix.py:
<arigato>
# NOTE: this is not used for 'os.urandom' on POSIX; instead,
<arigato>
# is needed (or complete enough) nowadays.
<arigato>
# app_posix.urandom() is. However, module/_random/ actually
<arigato>
# calls this code directly. XXX Unsure the version in app_posix
<arigato>
so I don't know why we have two versions
<mattip>
confusing
<arigato>
definitely
<arigato>
maybe we should (1) remove the app_posix version; (2) add the check for errno in the interp-level version
<mattip>
on default, right?
<arigato>
on py3.6
<arigato>
ah, the (2) part, yes, it should probably go on default too
<arigato>
fwiw, this shows up in the sandboxing branches because "/dev/urandom" is not available by default to the sandboxed process, and the stdlib contains code like "try: os.urandom(); except NotImplementedError:"
<arigato>
(I think it contains such code only on default, no longer in py3.6)
<Dejan>
i have recently started using pypy 3.6 on my aarach64 vps, and started using it on my aarch laptops :)
<simpson>
Looks reasonably portable at a glance. I'm sure that there's Fun lurking underneath.
<Dejan>
simpson, yes, i would assume dataclasses should be fairly easy
<Dejan>
arigato, i think it is just pure python
<arigato>
hopefully there is nothing to do
<Dejan>
but to me personally aarch64 support in PyPy3 is the most welcome feature :D
<ronan>
I'm wondering why utf8_encode_utf_16_helper() has a fallback for invalid utf-8 input, that's never supposed to happen
<arigato>
ronan: even if the utf8 source has random surrogates?
<arigato>
otherwise, it's maybe a leftover dating back to the pre-utf8 world
<ronan>
to be precise, the input is supposed to be a valid utf8sp encoded string
<ronan>
rutf8.codepoint_at_pos() can't fail on it, unless we have a broken unicode object to start with
<arigato>
it can be called from cpyext.unicodeobject
<arigato>
ah but also only on space.utf8_w(...)
<arigato>
so no idea why
<arigato>
I'm also failing to see where the utf8_encode_utf_16*() functions are used
<arigato>
it's either dead code (apart from the _helper one) or there is metaprogramming that I'm not managing to find
<ronan>
hmm
<arigato>
ah, in module._codecs.interp_codecs there is getattr(unicodehelper, ...)
<arigato>
...which also always passes "w_arg._utf8", so yes, I think you're correct
<arigato>
ronan: do you feel like starting the py3.7 branch, or should I attempt to?
* ronan
wishes RPython had a utf8-encoded string type
<ronan>
arigato: I was thinking of doing it later this week
<arigato>
cool, I'll let you do it then
<arigato>
thanks!
<ronan>
ok
<mattip>
hi. unicode_helper kind of grew out of a bunch of different branches, so there might be dead code there
<mattip>
and I tried to make it the same on default and py3.6, don't know if I succeeded
xcm has quit [Ping timeout: 245 seconds]
<kenaan>
rlamy py3.6 9abe3f6c09a4 /pypy/interpreter/unicodehelper.py: Remove confusing and unused error path for invalid-at-interplevel input in encoders
niceplace_ has joined #pypy
xcm has joined #pypy
ekaologik has joined #pypy
<_aegis_>
mattip: yeah, I keep reading that windows 64-bit doc and wondering if I'm going to be the person to do it, probably going to ship cpython3.7 on windows for now and circle back around though
<_aegis_>
I hope it's just rpython types and not like a lot of windows apis changing
<_aegis_>
is there a major reason cross compiling *shouldn't* work? wouldn't it be easier to use 64-bit linux pypy to do the first translation?
<_aegis_>
than to hack up cpython or something
<_aegis_>
like expect a "pypy linux + mingw-w64 + wine" environment to exist during bootstrapping
<mattip>
there are places we use the translating python to ask about the host platform, so those must be carefully refactored
<_aegis_>
ah interesting
<_aegis_>
at least allow a command line flag override?
<mattip>
like sys.maxsize and sys.platform, those would all have to become target.maxsize, target.platform
<_aegis_>
rpython support cross-translating a 64-bit pypy from 32-bit pypy?
<_aegis_>
*does
<_aegis_>
otherwise maxsize should be the same
<_aegis_>
and no maxint or int type in python3
<mattip>
I thought we were talking about rpython translation
<_aegis_>
has the rpython tree drifted much in the pypy3 branches?
<_aegis_>
I'd only really want to do this work once, and I care way more about pypy3
<mattip>
rpython should only have 1 or two diffs between default - py3.6, mainly due to windows
<mattip>
pypy has diverged much more
<arigato>
there is no way at this point we can support cross-compiling from a "too different" platform
<arigato>
32bit vs 64bit definitely counts as "too different"
<arigato>
anything posix-y versus windows, too
<arigato>
so I fear there is no way around the hack I described
<arigato>
I think mingw versus real windows is also "too different"
<_aegis_>
my thought is from linux to mingw
<_aegis_>
and mingw is at least posixy
<arigato>
depends what your goal is
<_aegis_>
I want a 64-bit windows C abi dll
<_aegis_>
and mingw should provide that
<arigato>
if the goal is a mingw64-based pypy, then you can probably do that by reviving the mingw hacks and using only mingw (no linux)
<_aegis_>
ah, but if I used mingw on windows I'd still run into the 64-bit translation issue? since there's no 64-bit windows pypy yet
<arigato>
how does cpython2.7 compile on mingw64 anyway? what is sys.maxint?
<_aegis_>
in mingw long is still 32-bit
<arigato>
ok then cross-compiling from linux to mingw64 is not going to work either
<_aegis_>
dang it, I'm trying to avoid a windows box in my build pipeline :)
<arigato>
that's a lot cause if the goal is a 64-bit windows
<lazka>
I think it started to compile at least, but failed quickly there
lazka has quit [Remote host closed the connection]
<cfbolz>
ronan: I actually really like the idea of an rpython utf-8 type. It could also know its two lengths. Would need a bit of design to get it right of course