cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
<simpson>
Hm, what are my options for dynamic field access on RPython objects? I have a doubly-linked datastructure, but I'm not sure how to walk the links on the outside because of polymorphism.
<simpson>
There's a note in the literature that the links can be a pair of a pointer and a selector/attribute/name/label/slot to access on the linked object, and that'd work fine in vanilla Python with getattr() and setattr(), but that's not RPython.
<simpson>
All of the objects involved have statically-known attributes and layouts. I just don't know which object subclass is going to be at each location.
<mattip>
_PyObject_GC_Malloc - do we want to allow users to link objects to the GC?
<mattip>
(that is the only on I did not comment on, I don't know what we should do here)
solarjoe4 has joined #pypy
inad923 has joined #pypy
dfee has quit [Ping timeout: 256 seconds]
antocuni has joined #pypy
raynold has quit [Quit: Connection closed for inactivity]
realitix has quit [Ping timeout: 264 seconds]
realitix has joined #pypy
Rhy0lite has joined #pypy
dfee has joined #pypy
dfee has quit [Ping timeout: 256 seconds]
dddddd has joined #pypy
marky1991 has joined #pypy
<kenaan>
cfbolz default b0fdbba6aeab /rpython/jit/metainterp/optimizeopt/info.py: fix a very rare segfault in the JIT, shown by Pycket (neither did I manage to write a test, nor to fix the broken...
mattip has left #pypy ["bye"]
realitix has quit [Quit: realitix]
realitix has joined #pypy
realitix has quit [Client Quit]
realitix has joined #pypy
marky1991 has quit [Remote host closed the connection]
<mjacob_>
simpson: you could create a new class for each element type
<arigato>
antocuni: pong
<mjacob_>
simpson: at compile time you have the full power of python
<arigato>
simpson: yes, but at run time you have to think it's Java/C#, so no generic things as dynamic attribute names, but instead you might need to make methods and override them in all subclasses. which you can do at compile time semi-automatically
JamJam_kid has joined #pypy
<arigato>
mattip (logs): Py_ReprEnter() is part of the CPython API, and there's no reason to forbid it, so let's implement it
<arigato>
in this case it can be a bit messy in RPython, so we might as well write it as space.appexec() doing tricks with thread-local objects
<simpson>
mjacob_: Yeah, I'm generating a class per element.
<simpson>
arigato: Yeah. What I've done is to improvise some 'selector' PBCs which can be used in place of strings for getattr() and setattr().
<arigato>
right, makes sense
<arigato>
you get a more static language, so when you occasionally need the dynamism you have to reinvent it from scratch yourself
<arigato>
every large application contains a limited, slow, awkard, buggy, ... version of Lisp, as the idiom goes
mcyprian has quit [Remote host closed the connection]
solarjoe4 has quit [Quit: Leaving]
<simpson>
Yep. I don't even really *want* dynamism. I want to do surgery on a graph of nodes, where all of the nodes are doubly-linked. This means that sometimes I have to ask nodes with unknown types to change their links. And I think that this means that the nodes need to have methods for this changing.
<arigato>
classical OOP, as meant by the common OOP languages
igitoor has quit [Ping timeout: 256 seconds]
<simpson>
Yes. I feel like I've reimplemented the bottom layers of Smalltalk.
igitoor has joined #pypy
igitoor has joined #pypy
igitoor has quit [Changing host]
<Rotonen>
abstract message passing?
<simpson>
Yeah. Really I want 'linear graph reduction', but the paper describing it doesn't get into the details of memory layout.
<simpson>
They just say 'Each method becomes a C procedure that performs surgery on the run-time working graph' and no details. I guess later they say that 'The C code calls various utilities...to manipulate graph structure', but that's it.
<Rotonen>
no idea what exactly you are doing, but take a look at the cuda solutions to the scope as well, maybe there are insights to be had
<Rotonen>
there's a lot on graph reductions stemming from cuda and opencl research
<simpson>
Yeah, but not on *linear graph* reduction. This seems to be a niche. FWIW I'm reading https://dspace.mit.edu/handle/1721.1/13191 but it is a full-length thesis.
<Rotonen>
well, there's the 1972 tarjan paper :P
<simpson>
Oh, nice find.
<Rotonen>
almost everything in the field cites that, heh, seems i still remembered the year correct as well :-)
<Rotonen>
used to do something half related a couple of careers ago
<simpson>
Lines 19-30 are what I ended up going with. It might not interpret fast, but it should JIT alright-ish in the long run.
dfee has joined #pypy
realitix has quit [Quit: realitix]
dfee has quit [Ping timeout: 260 seconds]
<arigato>
simpson: a more classical solution follows the visitor pattern. the goal is to have methods called "get_<label name>" on the base class and all subclasses
<arigato>
you can still have a generic way to invoke "get_<name>" by defining it in the Selector PBCs: in __init__, attach 'self.get = lambda object: object.get_<name>()'
<arigato>
which can be written using getattr() on a constant name, in RPython, i.e.:
<arigato>
just describing an alternative solution. yours is fine if the unrolling_iterable remains short in practice
<arigato>
the advantage of the solution I propose is that it would work if the labels correspond to different RPython types, e.g. ints versus instances
JamJam_kid has quit [Ping timeout: 248 seconds]
<arigato>
(at least, assuming you call directly "get_<some_int>()" or have several Selector classes for the different types)
<simpson>
arigato: The *only* operations that I'll be doing with these are assignment and querying, and I only need the queries for type discrimination.
<simpson>
I totally see where you're going, and yeah, a thicker layer like that would be useful if I needed to keep extending this.
<simpson>
This paper doesn't have any vertices with more than, say, five selectors. So that should be fine.
JamJam_kid has joined #pypy
<arigato>
yes
jamesaxl has quit [Ping timeout: 276 seconds]
jamesaxl has joined #pypy
tbodt has joined #pypy
inad923 has quit [Ping timeout: 248 seconds]
<antocuni>
arigato: did you see my question about the GC yesterday?