cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake | IRC logs: and | Matti: I made a bit of progress, the tests now only segfault towards the end
<mjacob> kurisu: instead of using the workaround described in the last sentence, you can pass "-global" to "init" in the tcl script
<mjacob> kurisu: "load -global ./mytest[info sharedlibextension]" works for me
<kurisu> mjacob: thanks!
<mjacob> arigato: starting with Python 3.8, C extensions no longer link to libpython (search for bpo-21536 in should cffi state that RTLD_LOCAL is generally unsupported?
<Corbin> Ugh, I need to write a proper peephole optimizer for my bytecode. I have the ability to rewrite the most recently emitted bytecode, but that's not enough. Is there a framework for peephole optimization in RPython already?
dustinm- has quit [Ping timeout: 246 seconds]
dustinm has joined #pypy
habnabit_ has quit [Ping timeout: 246 seconds]
habnabit_ has joined #pypy
<fijal> Corbin: I don't think there is any library support (not sure how you would do it even)
<Corbin> No worries. I'm just lazy.
infernix has quit [Ping timeout: 240 seconds]
f4at has joined #pypy
infernix has joined #pypy
<fijal> Backwards compatibility, no longer strictly required:
<fijal> Python2.2 used LONG_LONG instead of PY_LONG_LONG
<cfbolz> Corbin: we never wrote much rpython libs for interpreters
<cfbolz> it turns out they are all too different from each other
dmalcolm has quit [Ping timeout: 240 seconds]
otisolsen70 has quit [Quit: Leaving]
<LarstiQ> cfbolz: is that true in general, or for the intepreters worked on so far?
<LarstiQ> might there be families of interpreters that could share libs?
<cfbolz> who knows
<fijal> do we know what's _rawffi/alt?
<fijal> LarstiQ: in my limited experience writing libraries that has 0 or 1 known use case is a bit of a lost cause
f4at has quit [Quit: bye]
f4at has joined #pypy
f4at has quit [Client Quit]
<LarstiQ> fijal: yes, factor it out after there are 2 more usages
<LarstiQ> or
dmalcolm has joined #pypy
<fijal> cfbolz: can I add to rffi.llexternal a parameter "natural_arg_count=X"
<fijal> ?
<fijal> I think I would like to not have to support variadic args in RPython
<fijal> just have a way to say "by the way, this happens to be a variadic call, please instruct ABI accordingly"
<cfbolz> fijal: does that mean we would have to pass that to *all* llexternal in rlib?
<fijal> no
<fijal> only ones that are undercover variadic
<cfbolz> fijal: right, which in theory can be platform specific (or even libc implementation specific) I suppose
<fijal> yeah of course, the whole platform declaration is platform specific :)
<fijal> I don't think that part bothers me
<fijal> this only matters for tests btw
<cfbolz> ok, good
<arigato> cfbolz: re cffi, I don't see how changing space.type() to space.isinstance_w() can affect what gets virtualized by the JIT
<cfbolz> Did I write on the wrong issue?
<arigato> ...yes you did?
f4at has joined #pypy
f4at has quit [Client Quit]
<arigato> :-)
<cfbolz> Sorry
Atque has joined #pypy
<fijal> aaaa, why does heptapod have to do the same thing as github and not show branch commits?
<fijal> merge default ruins the history
dmalcolm_ has joined #pypy
dmalcolm has quit [Ping timeout: 272 seconds]
<mattip> can you get tortoise hg?
f4at has joined #pypy
<fijal> mattip: I'm trying to get it from the website, is that wrong?
<mattip> dunno. On ubuntu I need to build it from source
mannerism has quit [Ping timeout: 248 seconds]
lritter has joined #pypy
<fijal> no, I mean reading the hg history from heptapod
mannerism has joined #pypy
<arigato> cfbolz: re issue #2889, yes, I agree
<fijal> arigato: is there a reason why lltype2ctypes(r_int32()) returns r_int32?
<arigato> no idea
<fijal> ok :-)
<fijal> there is a mess somewhere, because I *need to* strip artgtypes
<fijal> this is all such a hack....
<arigato> I guess converting r_int32 to ints in this direction would work, but also, keeping the r_int32 should mostly work too?
<fijal> it works, except in the setup where I remove argtypes
<fijal> because it's a variadic arg
<arigato> and it doesn't work in that case because [insert a ctypes bad reason]?
<arigato> oh, I guess we need to convert r_int32 to ctypes.c_int()?
<fijal> I think something goes wrong?
<arigato> in theory, calling a variadic function with a C 'int' or a C 'long' is quite incompatible
<fijal> yes
<arigato> ...ok
<fijal> I think it's also true in practice
<fijal> va_arg(x, long) and va_arg(x, int) provides a different answer, I claim
<arigato> I'd think on little-endian platforms they don't, as in if you pass a C 'long' and you do va_arg(x, int) everything should work, but I don't know about M1
<arigato> of course it's wrong, and even if this particular case works right now it won't in next year's great new platform
<fijal> I'm pondering if I want to understand more why it does not work on open(2), my example works now
<fijal> arigato: it might have something to do with masking? like you don't care if the top half of your register contains garbage
<arigato> yeah, maybe it's a better use of our time to do a fix that's supposed to work on other platforms too
<arigato> maybe have lltype2ctypes(r_int32()) return ctypes.c_int(), as that looks like the safe answer, and then run all tests on all platforms, I guess
<fijal> I have made a slightly more localized hack
<cfbolz> arigato: of course my quick hack made my example program slower (even though the raw malloc is gone from the trace...)
<arigato> :-/
<arigato> cfbolz: are you looking at the trace at the right level? I may be wrong but I seem to remember there is some raw-malloc-removal optimization if the pointer doesn't escape the trace
<arigato> ah, but if it's passed into the residual function call, then it escapes
<fijal> cfbolz: do you feel like checking if pypy-c py.test test_optimizeopt works for you? what about m1 branch?
<fijal> it does something strange for me
<fijal> right, it reorders setarrayitems, can we fix that test somehow?
<cfbolz> fijal: sorry, busy with the kids for the next two hours or so
<cfbolz> fijal: did you merge default into M1 at some point?
<fijal> yep, I did
<cfbolz> That rings a bell but I thought I fixed it
<cfbolz> It's a dict ordering issue
<cfbolz> We have code for regular fields
<fijal> yeah
<cfbolz> That fixes it
<cfbolz> But not array items
<fijal> ok
<fijal> I gonna see if metainterp tests pass and then start thinking about porting the JIT I guess?
<cfbolz> fijal: awesome!
<mattip> <fijal> reading the hg history from heptapod
Atque has quit [Quit: ...]
<mattip> I don't try, it it so much easier in tortoise hg
<fijal> seems like I can really just have two maps one is w+r one is r+x?
Atque has joined #pypy
<cfbolz> fijal: which test is it that fails for you on pypy?
<fijal> FAIL optimizeopt/test/
<fijal> FAIL optimizeopt/test/
<fijal> ok, I think I understand why this is so arcane
<cfbolz> fijal: it fails for me on m1
<cfbolz> but if I merge default it passes :-P
<fijal> I'm happy to merge the default?
<fijal> so m1 lacks mremap
<fijal> or OS X lacks, rather
<fijal> but we can achieve the same thing using vm_map etc, but this is obviously a bit arcane
<fijal> but I think we can cargo cult it from libffi
<cfbolz> fijal: just saying, above I asked you "did you merge default" and you said yes
<fijal> "at some point" ;-)
<fijal> that was a very specific question, I merged it like 2 weeks ago?
<cfbolz> should I merge or do you want to
<fijal> I think I'm done for today so if you can, please do?
<fijal> I'll play some games or something, it has been a long day
<cfbolz> sounds like a good plan
<cfbolz> (it's a clean merge anyway)
f4at has quit [Quit: bye]
f4at has joined #pypy
f4at has quit [Quit: bye]
Atque has quit [Quit: ...]
f4at has joined #pypy
Guest96 has joined #pypy
Guest96 has quit [Quit: Textual IRC Client:]
Guest96 has joined #pypy
Guest96 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
lritter has quit [Ping timeout: 248 seconds]
Atque has joined #pypy
Atque has quit [Client Quit]
f4at has quit [Quit: bye]