cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
lritter has quit [Quit: Leaving]
Atque has quit [Quit: ...]
Atque has joined #pypy
slav0nic has joined #pypy
<fijal> cfbolz: ok, so the first issue I think is that HTTPResponse is inheriting from io.BufferedIOBase
<fijal> in lib-python/3/http/
<cfbolz> fijal: right
<cfbolz> fijal: I am wondering whether we can do some kind of quick experiment whether we are thinking about the correct things
<cfbolz> fijal: and one thing to try might be to quickly run benchmarks with "import _pyio as io" in all these places
<fijal> I've done some quick experiment (quick and dirty "readline" implementation)( and it's very fast
<cfbolz> ok, good
<cfbolz> so then the next question is which level to optimize this on. we can improve the io module
<cfbolz> or stop using it
<fijal> I wonder if io module is improvable with the whole abstraction craze
<fijal> in a way HTTPResponse is using it exactly as advertised (and possibly really bad for the JIT) by abusing all those space.call_method("read") overloads
<fijal> s/abusing/using/ pick your words
glyph has quit [Quit: End of line.]
glyph has joined #pypy
<cfbolz> fijal: yes
<cfbolz> fijal: the pure python version would probably really be better
<fijal> yes
<fijal> let me try it
<cfbolz> or we add careful jit drivers to the io module
<fijal> I'm quite worried that it's a lipstick on a pig
<cfbolz> the "systematic" way to do this is to optimize call_method(<some constant>)
<fijal> it kinda does not help because it's still a call from an arb rpyhton code
<fijal> (so not a loop)
<cfbolz> fijal: "it" being what?
<fijal> adding jit driver
<cfbolz> right
<cfbolz> anyway, it's a warmup problem, partly, right?
<cfbolz> so jitdriver doesn't help
<fijal> partly, yes
<fijal> but warming functions from the start is both more effort and works less well
<fijal> (but a factor is more like 2x than 200x)
<cfbolz> yeah
<cfbolz> anyway, let's try pyio?
<fijal> HTTP/1.1 client library
<fijal> <intro stuff goes here>
<fijal> <other stuff, too>
<fijal> nothing like high quality standard library heh
<fijal> AttributeError: module 'pyio' has no attribute 'RawIOBase'
<fijal> cfbolz: ^^^
<cfbolz> :-(
<cfbolz> it's _pyio I think?
<cfbolz> yes
<fijal> more or less the same
<cfbolz> hmpf
<cfbolz> fijal: what happens if you still inherit from io.BufferedIOBase but add your own readline implementation?
<fijal> good question!
<fijal> cfbolz: I think I need better benchmarks, more synthetic
<cfbolz> ok
<cfbolz> fijal: fwiw, I have a weird idea how to make call_method faster in the interpreter
<cfbolz> we can add local lookup caches for each call site quite easily
<fijal> hm
<fijal> maybe worth doing?
<cfbolz> fijal: I want to finish the dict stuff I am doing now first (want to try to have that ready for the release)
<cfbolz> but then I am happy to try it (it's been on my list since a while)
<fijal> ok cool
<fijal> cfbolz: I think disregard my answers - it's mostly about the streaming (or not) of the http queries
<fijal> so establishing new socket takes a while, but I
<fijal> need to try to streamline that (seems like all http servers/clients can do that anyway)
<cfbolz> ok
vext01_ has joined #pypy
vext01_ is now known as ebarrett
<ebarrett> hi #pypy
<ebarrett> I'm looking to your test suite for inspiration
<ebarrett> do you have a style of test where you specify IR and a trace through it, and then check the output of the trace compiler?
<cfbolz> ebarrett: oh hi edd!
<cfbolz> I'll answer your question in a bit, but also had been meaning to tell you that I put the unipycation branches from the (now dead) fork of pypy that used to live on bitbucket into the main repo
<cfbolz> somebody had asked me about the code
<ebarrett> hi cfbolz
<ebarrett> oh wow!
<ebarrett> that surprises me :)
<cfbolz> that just counts ops
<ebarrett> i see
<cfbolz> ebarrett: there's also a much more specific kind, wait a sec
<cfbolz> ebarrett: and these probably come closest to what you are thinking about:
<cfbolz> they are annoying and break a lot 😅
<cfbolz> (but catch bugs)
<ebarrett> yeah, i can imagine
<ebarrett> so any tests where you say: here's a CFG and suppose the trace took the path 'X -> Y -> Z', the optimised trace should look like <blah>?
<cfbolz> no, we test that as two steps usually
<cfbolz> "this code leads to that trace" one test
<cfbolz> "this trace is optimized like that" other test
<ebarrett> ok
<cfbolz> note also that our traces are made out of operations, not control flow edges (?)
<ebarrett> yep
<ebarrett> ok, thanks
<cfbolz> this is the C tracing right? not the hardware tracer?
<ebarrett> yeah
<ebarrett> i want tests where i present an LLVM IR module, and a list of blocks a trace passed through, and then test the trace compiler did the right thing
<ebarrett> it's complicated by our LLVM passes which will change the block structure of the IR
<cfbolz> right
<cfbolz> make it as nice as you can, you'll do that a lot :-P
<ebarrett> yup :)
<Cheery> There is this old problem that pushes through as I'm thinking about modules. What to do about operators?
<Cheery> I could introduce typeclasses, but it'd leave a certain kind of a language behind.
<Cheery> another thing I could do is to just introduce things in different modules and let user choose how they're named.
Atque is now known as hammond
hammond is now known as Atque
Dejan has joined #pypy
Julian has joined #pypy
otisolsen70 has joined #pypy
Julian has quit [Quit: leaving]
<mattip> cfbolz: the failing app_main tests seem to be checking that
<mattip> _locale.setlocale(_locale.LC_CTYPE, None)
<mattip> change in response to the "-X utf8" flag
<mattip> is that right?
<cfbolz> mattip: can you paste the link?
<cfbolz> Ah damn, I thought I fixed all of these
<cfbolz> I'll take a look
<cfbolz> mattip: I think it's the other way round: unless utf-8 mode is explicitly turned off, if the locale is C or Posix, it should be turned on
<mattip> the locale is not C nor Posix
<mattip> and the mode is on
<cfbolz> And -X Utf8 wasn't passed
<cfbolz> That sounds wrong?
jacob22 has quit [Ping timeout: 240 seconds]
lritter has joined #pypy
jacob22 has joined #pypy
<cfbolz> mattip: I (hopefully) fixed the last problem with speedup-dict-copy, let's see
<mattip> cfbolz: I think -X utf8 by default only happens inside a docker, but I don't understand why
<cfbolz> mattip: yeah, I also don't trivially manage to reproduce this
<mattip> maybe running as root?
<mattip> speedup-dict-copy - cool
jacob22 has quit [Ping timeout: 240 seconds]
<mattip> inside the docker, "lc = _locale.setlocale(_locale.LC_CTYPE, None)" in _parse_command_line() returns "C"
<mattip> that must be the untranslated _locale
<mattip> the python2 _locale.setlocale() inside the docker reports "C", the python3,8 one does not
<mattip> pypy2 also reports "C"
<Cheery> does rpython handle utf-8 correctly?
<Cheery> I'm getting results where my symbols are garbled.
<Cheery> ok. added the age-old # -*- coding: utf-8 -*-
<Cheery> and it started working.
<Cheery> I want a better logic programming language to do this. :)
<cfbolz> Cheery: that's really a python2 question then 😉
<Cheery> yeah. :)
<mattip> pypy2/python2 is inconsistent: in I get "C", in I get a utf8 locale
jacob22 has joined #pypy
<mattip> ok, nvrmind, it is a false negative in the test somehow due to locale and docker
<mattip> if I run the docker with docker run -e LANG=C.UTF-8 -e LC_ALL=C.UTF-8 ... the tests pass
<mattip> cfbolz: I want to release a rc1, hopefully the speedup-copy-dict will make it in later
<cfbolz> mattip: right
<cfbolz> mattip: about dict copy: it does not matter too much
<cfbolz> it's a small speed regression for 3.9
<cfbolz> we can even release the alpha with it
<mattip> ok
<cfbolz> (the issue is moot, it's not completely done anyway :-( )
<mattip> grr, the aarch64 buildbot is stuck
<mattip> fijal: do you have access to the aws control panel for the machine?
<Cheery> oh and I got sample code.
<Cheery> main = app . exch . split (greeting . greeting) (id)
<Cheery> now there's the moment that I'd need to decide what I'll do with this.
<Cheery> the try-first thing.
<Cheery> before I allowed recursive code, it was deadlock-free at least in theory.
<Dejan> so this is some sort of interpreter?
<Cheery> and on-load typechecker.
Dejan has quit [Quit: Leaving]
greedom has joined #pypy
greedom has quit [Remote host closed the connection]
<fijal> mattip: no
otisolsen70 has quit [Quit: Leaving]
slav0nic has quit [Ping timeout: 250 seconds]
lritter has quit [Ping timeout: 268 seconds]