arigato 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 | mac OS and Fedora are not Windows
danieljabailey has joined #pypy
jcea has quit [Quit: jcea]
koz_ has joined #pypy
<koz_> I decided to message here regarding https://mail.python.org/pipermail/pypy-dev/2019-February/015695.html, as mailing lists aren't my jam. I'm using Pypy on my 32-bit ARM microservers running Gentoo, to speed up various Python-based distro things (like portage).
<koz_> Current plan is to see if I can get canto-ng to work with Pypy.
<koz_> cfbolz: ^
Arfrever has quit [Quit: 御出で]
forgottenone has joined #pypy
_whitelogger has joined #pypy
<mattip> koz_: most of us are in European time zones. We asked because translating ARM32 guest on an X86 qemu host is very slow,
<mattip> koz_: so we are looking for alternatives to running builds
<koz_> mattip: I'm doing a native translation.
<koz_> Which is even slower. :P
<mattip> debian has access to this hardware https://db.debian.org/machines.cgi?host=hoiby
<mattip> is that anything close to what you have?
<mattip> it also weems the aarch64 port might solve the problem with a chroot builder for arm32
<mattip> ronan: translation is broken
bivab has quit [Quit: Connection closed for inactivity]
<koz_> mattip: Nowhere near that, sorry.
<koz_> I _am_ considering a dedicated build machine, but that's far in the future.
<mattip> cool. We are always looking for satisfied users to write guest blog posts, or to link to already published posts about pypy
<koz_> mattip: I'll keep that in mind, thanks.
<koz_> I am doing this in mind of having Pypy be ARM keyworded on Gentoo, so I'll mention it here if/when it ever happens.
dddddd has quit [Remote host closed the connection]
<mattip> thanks
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
lritter has joined #pypy
Zaab1t has joined #pypy
Zaab1t has quit [Client Quit]
rubdos has joined #pypy
rubdos_ has joined #pypy
rubdos has quit [Quit: WeeChat 2.2]
rubdos has joined #pypy
<kenaan> mattip default 8d4ef4fd2096 /pypy/module/cpyext/: use name instead of c_name to fix translation
<kenaan> mattip py3.6 363f2ef2fd93 /pypy/module/cpyext/: merge default into branch
dddddd has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<mattip> cfbolz: might be nice to mention hypothesis on the test podcast
<cfbolz> sure!
<cfbolz> mattip: I can show you my notes once I type them up
<cfbolz> (what I plan to say)
<mattip> +1
<cfbolz> mattip: we're speaking thursday evening
forgottenone has quit [Quit: Konversation terminated!]
forgottenone has joined #pypy
rubdos has quit [Quit: WeeChat 2.2]
<kenaan> cfbolz py3.6 3b7015c3581a /lib_pypy/_decimal.py: fix test_decimal
forgottenone has quit [Quit: Konversation terminated!]
<kenaan> cfbolz py3.6 57e5774b430e /lib-python/3/test/mod_generics_cache.py: add missing file
forgottenone has joined #pypy
Ai9zO5AP has joined #pypy
i9zO5AP has joined #pypy
Ai9zO5AP has quit [Ping timeout: 245 seconds]
<kenaan> mattip default fa5202d97bc9 /pypy/conftest.py: len('3.6') is 3, fix comparison
<kenaan> mattip py3.6 0aa14088b8a4 /pypy/conftest.py: merge default into branch
xcm is now known as Guest83435
Guest83435 has quit [Killed (orwell.freenode.net (Nickname regained by services))]
xcm has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<mattip> I set up a build slave in a 32-bit stretch chroot on bencher4, and there are lots of rpython failures
<mattip> confusion between Signed and SignedLongLong
<mattip> any thoughts?
<mattip> it is using python2.7.13, gcc6.3.0
Zaab1t has joined #pypy
<arigato> mattip: I can't find any mention of SignedLongLong, where is it?
<mattip> TestIncrementalMiniMarkGC::()::test_instantiate_nonmovable
<mattip> in rpython/memory/test/test_transformed_gc.py
<arigato> thanks! the first remark is that many other tests fail differently
<mattip> is the chroot reporting a 64 bit cpu?
<arigato> yes, but in most places we use "sys.maxint > 2**32" as the real test
<arigato> exceptions would be in jit/backend
<mattip> how is this stretch (debian) chroot different from the previous xenial (ubuntu) chroot?
<arigato> I don't know
<mattip> it has gcc 6 instead of 5
<arigato> I would go for debugging the actual failures
<arigato> in pdb
<mattip> ok
* mattip off for dinner, will try later
<arigato> e.g. the SignedLongLong issues, with pdb we can learn at least which function contains the wrong combination of types
i9zO5AP has quit [Quit: WeeChat 2.3]
Ai9zO5AP has joined #pypy
Zaab1t has quit [Quit: bye bye friends]
<mattip> it is in the graph of ArenaCollection.allocate_new_arena
<mattip> the op that raises is v898 = cast_adr_to_int(v897, ('emulated')
<mattip> )
<arigato> maybe the address happens to be a pointer located in the upper half of the 32-bit address space, and our emulation of cast_adr_to_int('emulated') returns an unsigned number
<arigato> which is not a Signed
<arigato> check opimpl.py or maybe llinterp.py for cast_adr_to_int
<mattip> lltypesystem/llmemory.cast_adr_to_int has a 'emulated' mode
<arigato> check all implementations of _cast_adr_to_int
<arigato> for example, the one in llarena.py
<arigato> returns something based on the array module's buffer_info() method
<arigato> maybe that can return an unsigned number too large for 31 bits
<mattip> good guess. On stretch32, array.array('i', [10]).buffer_info() returns (4171952592L, 1)
<mattip> on xenial32, (153574416, 1)
<arigato> OK
<arigato> then, take that number and use number = rffi.cast(lltype.Signed, number)
<arigato> or do that on the final "number + self.offset" value
* mattip comparing the python headers for configuration differences
<arigato> that's unlikely to be there
<arigato> it's more a system difference where malloc() tends to return number in 0 < m < 2**31
<arigato> or not
<arigato> my guess is that, so far, we've only tested linux32 systems where m tended to be naturally below 2**31
<arigato> rlib.rvmprof.test.test_rvmprof should not run at all: rvmprof is only supposed to support 64-bit
zzarr has quit [Ping timeout: 246 seconds]
<mattip> I don't know how much time I want to put into 32 bit linux, but it is annoying
<mattip> that it doesn't work out of the box
<mattip> (nothing against the work that has been done, just frustrated by trying to set this up)
<mattip> </rant>
<mattip> rffi.cast(rffi.SIGNED, 4199276548) -> -95690748
<mattip> so we are missing a cast somewhere?
<arigato> yes, sorry, that's what I've been trying to say above
<arigato> add "rffi.cast(lltype.Signed, number)" at the right place, and everything should be fine
<mattip> :)
<mattip> ok, that seemed to help, just like you said in llarena.fakearearenaaddress._cast_to_int
forgottenone has quit [Ping timeout: 255 seconds]
<mattip> i don't see code that checks 32/64 in testing rvmprof
forgottenone has joined #pypy
<mattip> arigato: thanks
<kenaan> mattip default 0bfaff4207c3 /rpython/rtyper/lltypesystem/llarena.py: fix when malloc() returns an address with the last bit set (arigato)
<kenaan> mattip py3.6 edc5179ca4b1 /rpython/rtyper/lltypesystem/llarena.py: merge default into branch
rubdos has joined #pypy
dddddd has quit [Remote host closed the connection]
dddddd has joined #pypy
forgottenone has quit [Quit: Konversation terminated!]
forgottenone has joined #pypy
lritter has quit [Ping timeout: 246 seconds]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
rubdos has quit [Quit: WeeChat 2.2]
forgottenone has quit [Quit: Konversation terminated!]
<kenaan> andrewjlawrence winoverlapped aadc1d859506 /lib_pypy/: Fixed first test case for windows events
Ai9zO5AP has quit [Quit: WeeChat 2.3]
forgottenone has joined #pypy