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
jiffe has quit [Ping timeout: 260 seconds]
jiffe has joined #pypy
tumbleweed has joined #pypy
infernix has quit [Ping timeout: 240 seconds]
infernix has joined #pypy
jcea has quit [Ping timeout: 264 seconds]
_whitelogger has joined #pypy
<simpson>
What are the bounds of what I can do while the GIL is released in multi-threaded RPython? Basically nothing, right?
<mattip>
is there a way to tell the gc to ignore globals() from imported modules?
<mattip>
there is a mmap class in numpy that uses __del__ to release a memoryview of the mmap rather than have a close() method,
<mattip>
since there may be other consumers of the mmap, so the memoryview may not be the only one holding a reference to it
<mattip>
the test takes over 15 minutes on my machine since, on pypy, the "del obj" call must be followed by a gc.collect() to actually work
<mattip>
and the process is called in a loop ~150 times
<mattip>
each time calling gc.collect multiple times
oberstet has joined #pypy
<mattip>
there are millions of objects to trace, many of them globals() of modules (docstrings, classes, ...)
<mattip>
it would be nice to be able to ignore the things that are imortal
<fijal>
they're not outright immortal, you can remove them from the modules
<fijal>
but also, the problem is that you have to mark everything alive
<fijal>
so stuff that can be referenced by those modules
todda7 has quit [Read error: Connection reset by peer]
<fijal>
the problem here is that you want to call __del__, so you need to collect the entire heap, you can't use the incremental nature of the GC
todda7 has joined #pypy
<mattip>
hmm. I guess I could try to run the test in a subprocess so the gc has less work to do
<mattip>
annoying
<mattip>
ok, I seem to have a work-around
<LarstiQ>
how?
<mattip>
the numpy class has a flush method, which is effective on linux but not windows
<mattip>
since windows needs the memmap to actually be closed for the test to succeed
<mattip>
but this particular test is skipped on windows
<cfbolz>
marky1991: did you find the problem in the end?
<mattip>
I guess the bottom line is you really want to avoid gc.collect in tests, since they end up importing the whole world
<LarstiQ>
right
lritter has joined #pypy
todda7 has quit [Ping timeout: 272 seconds]
todda7 has joined #pypy
todda7 has quit [Client Quit]
jcea has joined #pypy
oberstet has quit [Read error: Connection reset by peer]
<marky1991>
the checked-in translate.sh is still building with jit on and no lldebug though
<cfbolz>
yes yes, I just ignored that :-P
<marky1991>
cool : )
<cfbolz>
ok, gdb
<cfbolz>
it's in Transformer._plussed
<marky1991>
yes, i saw that as well, but i odn't see what's wrong with it
<marky1991>
what's wrong with ._plussed?
<cfbolz>
this code isn't really rpython enough:
<cfbolz>
except (AttributeError, IndexError):
<cfbolz>
you can't catch AttributeErrors
<cfbolz>
and I think that's what's happening
<marky1991>
hm, interesting
<cfbolz>
you have a plus node that has a null pointer as .children
<marky1991>
i' don;t remember why i implemented it that way in the first place
<marky1991>
i'll try getting rid of it and see fi that resolves it
<marky1991>
thanks!
<cfbolz>
I suspect because you don't control the Node class that rlib.parsing gives you?
<marky1991>
cating indexerror is fine, right?
<cfbolz>
yes
<marky1991>
hm, yes
<cfbolz>
ah, I see
<marky1991>
hmm
<cfbolz>
you need to check with isinstance whether it's a rlib.parsing.tree.Nonterminal (then it has children) or not
<marky1991>
ok
<cfbolz>
let me know how it goes!
<cfbolz>
(wow, I don't remember how rlib.parsing works *at all*)
<marky1991>
i probably need to move away from it or enhance it at some point
<marky1991>
e.g. it doesn't support non-ascii i think
<marky1991>
but it was very convenient
<cfbolz>
it's super old, and I suspect it should be killed
<marky1991>
i forgot how pypy itself does it
<marky1991>
need to look at some point
<cfbolz>
it has its own handwritten ll(1) parsing engine
<cfbolz>
(but it's going to have to change soonish, since CPython changed)
<simpson>
CPython uses PEG now, right? Do they depend heavily on semantic actions? Are you going to use their grammar verbatim, or is that not workable?
<marky1991>
yay, no more segfault
<cfbolz>
simpson: it's all semantic actions
<cfbolz>
very annoygin
<marky1991>
thanks a lot cfbolz
<marky1991>
hm, isn't there a page describing ''What's NOT rpython"?
<marky1991>
the general rule of course is 'whatever translates
<marky1991>
but that rule didn't work here
<simpson>
cfbolz: Indeed, yeah. I wish I had good ideas for how to improve that; there's gotta be some way to prevent the grammar from diverging too much.