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
Rhy0lite has quit [Quit: This computer has gone to sleep]
pmp-p has quit [Ping timeout: 240 seconds]
pmp-p has joined #pypy
todda7 has quit [Ping timeout: 272 seconds]
speeder39_ has joined #pypy
jcea has quit [Quit: jcea]
_whitelogger has joined #pypy
speeder39_ has quit [Read error: Connection reset by peer]
speeder39_ has joined #pypy
jeroud has quit [Read error: Connection reset by peer]
speeder39_ has quit [Max SendQ exceeded]
samth has quit [Ping timeout: 272 seconds]
phlebas has quit [Ping timeout: 272 seconds]
speeder39_ has joined #pypy
speeder39_ has quit [Ping timeout: 244 seconds]
samth has joined #pypy
speeder39_ has joined #pypy
jeroud has joined #pypy
phlebas has joined #pypy
speeder39_ has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #pypy
todda7 has joined #pypy
todda7 has quit [Ping timeout: 272 seconds]
todda7 has joined #pypy
todda7 has quit [Client Quit]
tsaka__ has joined #pypy
tsaka__ has quit [Ping timeout: 260 seconds]
oberstet has joined #pypy
tsaka__ has joined #pypy
tsaka__ has quit [Ping timeout: 272 seconds]
Rhy0lite has joined #pypy
Rhy0lite has quit [Ping timeout: 256 seconds]
jcea has joined #pypy
lritter has joined #pypy
dddddd has quit [Ping timeout: 240 seconds]
<mattip> it seems the rpython/test/test_posix.py tests crash on win32
marky1991 has joined #pypy
<mattip> so they are not reporting the failures due to mixing os.* and rposix.* functions
<mattip> now that we switched compilers, they use different runtimes
<mattip> so fd = os.open(...) is not the same fd as rposix.open(...)
<arigo> these tests pass for me (default, win32, "Updated environment with vsver 160, using x64 False")
<mattip> with a cpython compiled with msvc 9?
<arigo> with the standard cpython 2.7, yes
<arigo> Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)] on win32
<mattip> wierd. They fail for me (I am on the buildbot machine)
<mattip> Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:19:08) [MSC v.1500 32 bit (Intel)] on win32
<arigo> no clue...
<mattip> is there a reason _not_ to use rposix.open instead of os.open ?
<arigo> everywhere in RPython? and that's also os.read(), os.write(), os.close(), etc. etc. etc.? I think s
<arigo> so
<mattip> no, just in the rposix/test/test_rposix.py
<arigo> where exactly?
<mattip> I will put my changes on a branch
<arigo> a bit everywhere you mean?
<arigo> I'm still very unclear how other tests would pass if these ones don't
<arigo> ‪like, any test that tests code from pypy (or any other RPython code) which happens to use os.open()
<arigo> and that runs untranslated
<arigo> what happened to the idea of trying to have ll2ctypes locate the "correct" libc?
<mattip> yes, that is how I discovered that the test_rposix tests crash on default
<arigo> fixing that should also fix test_rposix, no?
<mattip> this is the change that is needed, but it causes many test failures
dddddd has joined #pypy
<mattip> so then I went back to default to see why they don't fail there and surprise! they did
<arigo> just saying, "fixing" test_rposix looks like work that will only weaken the tests more than we really want
<mattip> then how do we deal with this problem?
<arigo> I must still be missing something. It seems you say that test_rposix fails because of a mismatch of libc versions, did I misunderstood it?
<mattip> all I can safely say is that for me rposix/test/test_rposix.py fails on win32, and that topic branch fixes the failures
<mattip> my hypothesis is that the failure is due to mixing runtimes, but now you say they pass, so I am confused
<arigo> OK, then all I say is that replacing os.open() with rposix.open() is not a valid fix because we'd like RPython code that uses os.open() to continue working untranslated
<arigo> note that I'm running the tests in the old environment, with "VC++ for Python"
<arigo> I guess nowadays they should be run with a newer VC, which would explain why they pass for me only
<mattip> but it is reporting "vsver 160"?
<arigo> confusingly, yes
<arigo> but maybe distutils.msvccompiler.get_build_version() returns the old VC for Python
<arigo> and the other code reporting "vsver 160" uses another logic to find it
<arigo> (just a guess)
<mattip> do the tests_rposix.py tests run to completion for you?
<arigo> yes
<arigo> 11 passed, 19 skipped
<mattip> huh. There should be 48 passed, 26 skipped
<arigo> is there a specific test that fails for you, which I could try locally?
<mattip> for me, test_os_write never kills the test run
<mattip> s/never/always/
<mattip> never completes, kills the test run
<arigo> right, for me too if I run in an environment without "VC++ for Python"
<arigo> ...OK, now also in an environment with "VC++ for Python"
<mattip> but that topic branch should complete the entire test run successfully
<arigo> sorry, I have no clue at all what's going on here, you better ignore me I guess
<mattip> ok. I will push ahead on that topic branch to make all rpython/rlib tests pass
<arigo> it did pass with 11 passed, 19 skipped *once* in *some* environment, and now it no longer does or the environment is subtly different or something
<mattip> I think the rpython code (not tests) that use os.open is safe as long as it stays with os.* functions and does not mix in rposix variants
<arigo> which is not completely possible because of some Python3-only functions which are not in os on Python2, but yes, I see the point and I don't want to prevent you from going ahead
<arigo> we risk obscure failures on pypy/module/posix on py3.6, but maybe we don't or we can just skip them or something
<mattip> I will put it on a non-topic branch for review and testing
<mattip> but as for os2rposix which only changes test_rposix.py (and clears the win32 failures): does it seem reasonable to merge?
<mattip> (where "it on an non-topic branch" refers to the pastebin change and subsequent changes to make it work)
<arigo> go ahead, just please revert it if you figure out soon a proper fix in ll2ctypes that also fixes that issue
<mattip> I fear the "fix" will be more of the same: converting os.* calls to rposix.* ones in tests
<mattip> but not in rpython code (since things JustWork right now)
<bbot2> Started: http://buildbot.pypy.org/builders/rpython-win-x86-32/builds/312 [mattip: force build, msvcrt]
<bbot2> Failure: http://buildbot.pypy.org/builders/rpython-win-x86-32/builds/312 [mattip: force build, msvcrt]
lritter has quit [Ping timeout: 256 seconds]