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
jinsun has joined #pypy
otisolsen70 has joined #pypy
idnar has quit [Ping timeout: 245 seconds]
graingert has quit [Ping timeout: 252 seconds]
graingert has joined #pypy
catern has quit [Ping timeout: 260 seconds]
idnar has joined #pypy
amazigh has joined #pypy
<amazigh> hello
<amazigh> I have an error during `poetry install`
<amazigh> at ~/pypy3.7-v7.3.7-linux64/lib-python/3/encodings/ in encode
<amazigh> same error with pypy 3.8
<amazigh> is it a known error?
<amazigh> I did not look into it yet
<amazigh> google failed to find something interesting.
jinsun has left #pypy [ - Chat comfortably. Anywhere.]
<cfbolz> amazigh: could you explain what exactly you are running so we can try to reproduce it?
<cfbolz> mattip: I would commit a fix to #3644 to py3.7, is that ok?
catern has joined #pypy
<amazigh> oops! sorry for the noise the problem was on my side, with sourcehut build service in the mix, instead of `poetry install` the following works: `poetry install --no-ansi --quiet`
<amazigh> locally (!), it works.
<cfbolz> cool
<cfbolz> and that's not noise, it's rubber duck debugging ;-)
<LarstiQ> conveniently not needing to explain what poetry and sourcehut are ;0
Guest96_ has joined #pypy
<mattip> cfbolz: feel free to commit to the py3.* branches, I will cherry-pick/merge as needed to the releases
<cfbolz> ok
<cfbolz> mattip: also found another related 3.9 bug
<mattip> cool
<mattip> so many corner cases, so little time :)
<cfbolz> yeah, that's what it feels like atm :-(
cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | so many corner cases, so little time
slav0nic has joined #pypy
<mattip> it seems like corner cases are also most of the current test failures
<mattip> maybe we should make a "pytest.mark.cornercase" decorator, and every now and then try to fix ten or twenty of them
<cfbolz> :-)
<LarstiQ> :)
Dejan has joined #pypy
<Cheery> Hi
<Cheery> considering to give constraints for the ukanren environment. It's a documented mod over existing implementation.
ebarrett has quit [Ping timeout: 260 seconds]
lritter has joined #pypy
slav0nic has quit [Remote host closed the connection]
greedom has joined #pypy
Dejan has quit [Quit: Leaving]
xcm has joined #pypy
xcm_ has quit [Read error: Connection reset by peer]
slav0nic has joined #pypy
otisolsen70_ has joined #pypy
otisolsen70 has quit [Ping timeout: 256 seconds]
greedom has quit [Remote host closed the connection]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
otisolsen70_ has quit [Quit: Leaving]
<cfbolz> ouch, just found a speed regression in the interpreter (the jit is fine) that I myself introduced at some point, around method calls to builtin types :-(
<Cheery> I just realised I'm in a turing tarpit with this thing. It feels nasty to actually code with these combinators.
<cfbolz> Cheery: hah :-)
<Cheery> fst : (($0 ⊸ ⊥) + ($1 ⊸ ⊥) ⊸ ⊥) ⊸ $0
<Cheery> then you wrangle a similar structure to the other side, you get an option which is an inverse of case statement.
<Cheery> but they're too complicated for my brains to handle. I need to come up with an alternative.
otisolsen70 has joined #pypy
exarkun has joined #pypy
<exarkun> Does this look familiar to anyone? AttributeError: cdata 'PROCESS_INFORMATION *' has no field 'dwFlags'
otisolsen70 has quit [Remote host closed the connection]
<cfbolz> exarkun: does it happen on 3.7 too?
<exarkun> Hm. I wonder if I can get 3.7 in this environment. Independent of that, it seems to be intermittent.
<mattip> exarkun: there is no dwFlags field in PROCESS_INFORMATION
<exarkun> mattip: That certainly explains the AttributeError. :)
<exarkun> The code that tries to read it is in the PyPy stdlib though
<exarkun> I am trying out 3.7 now
<mattip> right, it is being passed in to CreateProcess
<mattip> maybe from virtualenv\seed\wheels\ ?
Corbin has quit [Ping timeout: 240 seconds]
<mattip> weird. The call to Popen in virtualenv does not use the startupinfo arg
<exarkun> A PyPy 3.7 (7.3.7) run completed successfully
<mattip> I think the error is refering to the left=hand side "si" not the startup_info, since the latter is a python object not a cffi object
<mattip> but the error makes no sense, since si ="STARTUPINFO *") is two lines above
<mattip> exarkun: could you try to add some debug printing around the error: is it si or startup_info that is in error?
<mattip> "intermittent" suggests either the offending code is not called every time (i.e. the wheel is cached and does not need to be downloaded),
<exarkun> It happens on CI and there is no caching in my CI configuration, so I /suppose/ whatever it downloads, it downloads every time
<mattip> ahh, that makes it harder to debug
<exarkun> And related to that, sadly, I'm not sure how much deeper testing I can do. I can't reproduce it locally, only on CI
<exarkun> Strictly, I guess it happens in the step *after* Python gets installed in the environment, so there could be a step that rewrites part of the library with an instrumented version
<exarkun> I definitely won't get to that today though
<exarkun> If I see it again on PyPy 3.7 then I can probably justify spending some time getting more info
<mattip> right. FWIW, we have dropped support for 3.6
<exarkun> more reason not to investigate if it is 3.6-only I guess :)
<mattip> is it a public CI run?
<exarkun> Related to that, this is the PyPy that `actions/setup-python@v2` (GitHub Actions) gave me when I asked for "pypy3"
<exarkun> Yea it is - here is the run where I saw the problem,
Guest96_ has quit [Quit: Textual IRC Client:]
<mattip> fijal: any ideas how to reboot the arm64 build machine?
<mattip> it has a tendency to run out of disk space when it builds for a release
slav0nic has quit [Ping timeout: 268 seconds]