antocuni changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | "PyPy: the Gradual Reduction of Magic (tm)"
<guilherme>
Hi everyone, the ebnf parser (rpython/rlib/parsing/ebnfparse.py) is ready to use or is still under development? I'm asking because according to the docs, it is still highly experimental but I saw some projects on github using it!
<abrown>
Anyone online who can answer some questions re: RPython?
<simpson>
I'll try.
<abrown>
Let me figure out how best to phrase this...
<abrown>
Roughly this: if I have a structure that, like a PyFrame, contains a list of cells, is there any way that I can access the values in those cells using constant offsets?
<abrown>
(I use PyFrame and Cell here because I've been looking at them and how the virtualizable concept is used but my classes are somewhat different)
<simpson>
You can use list indexing like in normal Python. Are you worried about what the JIT will do?
<simpson>
Oh, you're doing virtualizeable frames? Well, have you first double-checked that you need them? If you don't have coroutines or anything else that would require frames to be paused, you might be able to not do virtualizeables at all.
<abrown>
ah, that would be good
<abrown>
so if I just access the value like myobject.cells[i].myvalue... what will the JIT decide to do?
<abrown>
I feel like it should be able to optimize everything down to a constant offset load but that is not what I'm seeing...
<simpson>
If you declared "cells[*]" in your _immutable_fields_, and if i is constant, then the list access should be transparent to the JIT.
<simpson>
Do you have a trace that you could pastebin?
<abrown>
ok, I could make that field immutable with a bit of rework
<simpson>
Well, how often does it change normally?
<simpson>
There's quasi-immutables, if it changes almost never. Each change will invalidate some JIT code.
<abrown>
never after it is set... but it is set after __init__; any way to declare it immutable then
<Alex_Gaynor>
Uhh, if you _never_ read the value before it's set, technically _immutable_ should be safe. But I'd write a big comment so that if you ever invalidate that property you have no one to blame but yourself, because debugging that woudl be miserable
<abrown>
ha, ok
<simpson>
Or you can use a quasi-immutable. Or, if this is supposed to be a code object, you could consider generally making *all* of your code objects fully immutable, as a general principle.
<simpson>
I don't remember how to get quasi-immut lists but the code's in there.
<Alex_Gaynor>
`list?[*]` IIRC
guilherme has quit [Remote host closed the connection]
guilherme has joined #pypy
<abrown>
thanks; I think my fundamental problem is that I have trees of terms and traversing the tree involves a lot of gc_getfield_*; I was hoping that flattening the tree into an array and then telling the JIT it is immutable so I can avoid a lot of that
<abrown>
*I could avoid a lot of that
guilherme has quit [Ping timeout: 240 seconds]
<abrown>
I think with what you said above, simpson, I should be able to (+ some other clever stuff)
<abrown>
how can I understand what gc_getfield_ and other gc functions are doing?
guilherme has joined #pypy
astronavt has joined #pypy
astronavt has quit [Remote host closed the connection]
jamesaxl has joined #pypy
guilherme has quit [Remote host closed the connection]
guilherme has joined #pypy
<kenaan_>
rlamy py3.5 7597dd2c875f /pypy/module/marshal/test/test_marshal.py: Skip another test that cannot work with -A
<kenaan_>
rlamy py3.5 61fa4de7d9bb /pypy/tool/pytest/test/test_appsupport.py: xfail test
<kenaan_>
arigo cpyext-avoid-roundtrip f1b821c8b0a9 /pypy/module/cpyext/test/test_tupleobject.py: Add a passing test
<kenaan_>
arigo default dae84ef106dd /pypy/module/cpyext/: Half-test, and fix
<kenaan_>
arigo cpyext-avoid-roundtrip 56643108f56a /pypy/module/cpyext/: Test and fix for the case where state.C.Xxx calls directly some C function which tries to call back ...
<kenaan_>
arigo cpyext-avoid-roundtrip 614a92d3bfbd /pypy/module/cpyext/tupleobject.py: This should be fixed now
<antocuni>
arigato, mattip: I think that fix-vmprof-stacklet-switch-2 is ready to be merged, but as you see I started some builders to check
<antocuni>
I won't be online today and tomorrow: if you want to proceed with the release and the buildbots pass, feel free to merge the branch by yourself