antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
<kenaan>
rlamy unicode-utf8 ac75e33e51bb /pypy/: Add utf8-based replacement for runicode.unicode_encode_decimal() to unicodehelper and fix PyUnicode_EncodeDeci...
drolando has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
drolando has joined #pypy
<kenaan>
mjacob py3.6 f04d4604c7e3 /: hg merge py3.5 (+ fixes) I'm not 100% sure about the merge in test_dis.py, but most of the tests are failing anyway.
mvantellingen has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]
mvantellingen has joined #pypy
dddddd has quit [Ping timeout: 248 seconds]
dddddd has joined #pypy
mat^2 has joined #pypy
mat^2 has quit [Remote host closed the connection]
<mjacob>
ronan: you've got an impressive run of fixing many of the weird bugs in the py3.5 branch
<mjacob>
ronan: let me know if you're stuck on any of the remaining ones; there are chances that i looked into these in the last weeks
<arigato>
fijal: not yet
<mjacob>
(without finding a really good solution)
<fijal>
ok
<arigato>
it's getting there, but the main issue is to design tests to make sure we're not left with issues of confusion between bytes and characters
<mjacob>
some time ago i hacked cpython 3.2 to use utf-8 internally and re turned out to be the most difficult to fix (at least of those features that are used to start the interpreter)
<mjacob>
arigato: could the annotator help in not mixing bytes and characters?
<mjacob>
(maybe i just dealt too much with languages with advanced type systems)
<arigato>
mjacob: yes, it's possible, but I'm unsure to want to go there
<arigato>
so far in a subset
<arigato>
, I've done it in pure Python
<arigato>
by using classes Position(n) instead of n
<arigato>
maybe it could be extended to pypy/module/_sre
<arigato>
after all, we should never do space.wrap(x) with x a Position(n)
<fijal>
we should never do space.wrap I would say :)
<arigato>
space.newint() :-)
<fijal>
arigato: I fail to understand yet-another-problem-with-r-uint
<arigato>
:-/
<fijal>
well yes, it's a classic problem
<fijal>
the annotation changes to r_uint
<fijal>
but it was int before
<fijal>
the int was wrong
* fijal
tries some signature
<fijal>
eh
<fijal>
so signature does not support optional arguments :/
<fijal>
arigato: is ord() known to return non-neg?
<arigato>
probably
<fijal>
arigato: no!
<fijal>
arigato: where would it be? annotation for ord?
<Alex_Gaynor>
arigato: look at the other def ord in that file, it's quite something
<arigato>
# warning, on 32-bit with 32-bit unichars, this might return
<arigato>
# negative numbers
<arigato>
<arigato>
indeed
<fijal>
eh ok
<fijal>
but the maxunicode is 0x10FFFF no?
<arigato>
in trunk we can have unicode strings containing characters past that
<fijal>
right, but not on this branch
<fijal>
I mean, that said, rawffi needs checking I presume
<arigato>
yes, in that branch we shouldn't use ord(unichar) a lot, and all the places probably need checking
<fijal>
it's mostly stuff in rawffi etc.
<fijal>
ok, but that's not something I actually want to check
<fijal>
I want to fix the translation so I can check benchmarks
<arigato>
that's something we're going to forget, then
<arigato>
please do something against us forgetting :-)
<fijal>
yes of course
<fijal>
maybe I'll just fix it
<fijal>
arigato: well the problem is we have not decided to merge the branch just yet
exarkun has quit [Read error: Connection reset by peer]
<mattip>
hi. We have 3 ARM targets, HardFloat (HL) raspian, HardFloat (HL) raring, and SoftFloat (EL) precise. I want to remove raring, it is no longer a debian-supported version
<mattip>
any objections? Any reason to keep raring around?
<mattip>
(it is debian 13.04)
<mattip>
my goal is to enable py3.5 on ARM, so trying to reduce the number of arm nightly runs
<LarstiQ>
s/debian/ubuntu/?
<fijal>
mattip: I have no idea who uses pypy on what ARM so why not?
<mattip>
also - no real reason to keep building default branch when it does not change
<mattip>
I can do the same trick I did for rpython with a changefilter on the branch. Any objections?
<arigato>
no, thanks
zmt00 has joined #pypy
<fijal>
arigato: should I just look at annotation and carefully check for all the places that call unichr_as_utf8 and unichr_as_utf8_append?
<fijal>
or I mean ord(unichr)
pilne has joined #pypy
<arigato>
unsure how, but it would be nice to have a list of all ord(unichr)
<fijal>
arigato: at the end of annotation?
<fijal>
(as a hack simply)
<arigato>
maybe?
<kenaan>
arigo unicode-utf8-re 170afb57631b /: Getting there
inhahe_ has quit [Ping timeout: 240 seconds]
inhahe_ has joined #pypy
<fijal>
eh tornado on OS X is misbehaving :?
<kenaan>
arigo unicode-utf8-re 6b113f6d5350 /pypy/module/_sre/: Tests and fixes
<arigato>
fijal: unicode-utf8-re fails to translate in interp_codecs, so I guess it's due to the particular revision I forked from
<fijal>
arigato: yeah, don't worry about translation failures
<fijal>
arigato: I *also* whacked at interp_sre to just translate
<arigato>
I'd say now it should be mergeable anyway, and we'll fix any more translation failures if there are some
<arigato>
yes
<fijal>
yeah I can deal with it
<fijal>
tomorrow though
<arigato>
ok, then please merge when you can, and then feel free to ask me about translation failures there
<arigato>
(or elsewhere, for that matter :-)
antocuni has joined #pypy
<fijal>
yes, works :-)
<fijal>
arigato: thanks!
<kenaan>
fijal unicode-utf8 93560a4f1a42 /: fix _rawffi and add a todo item
<arigato>
it *should* be correct, e.g. you can't write "ctx.match_start + 1" because in test mode it will explode
<arigato>
because match_start and most other integers are byte positions, in utf8
<arigato>
instead you have to call ctx.next(ctx.match_start)
<arigato>
...ah, which will explode translation right now
<fijal>
:]
<arigato>
next() is written using @not_rpython in the base class, to make sure we don't have an indirect call to it
<arigato>
which is the case in rsre_core
<arigato>
but indeed not in the few usages of next() from pypy.module._sre
<kenaan>
arigo unicode-utf8-re ebe0641d78a5 /: Must not call ctx.next() when the type of ctx is not exactly known. Workaround for interp_sre, where the fe...
<kenaan>
mattip buildbot 9c8b26858cfa /bot2/pypybuildbot/: kill raring build, activate py3.5 on ARM, add more onlyIfChanged
antocuni has quit [Ping timeout: 240 seconds]
exarkun has quit [Ping timeout: 255 seconds]
exarkun has joined #pypy
mentalita has quit [Quit: Leaving]
mentalita has joined #pypy
marr has quit [Remote host closed the connection]
antocuni has joined #pypy
<fijal>
arigato: ok, so the current status is that on tornado (which is a bit slower, like 5%, it's definitely within stddev of my measurments) traces are like 3x longer
<fijal>
so I guess we look
<fijal>
similar number of loops/bridges
<fijal>
so I guess we look, maybe on something less complex