<arigato>
no problem :-) I'll leave the patch in anyway, to avoid redefinition if somebody really sets it too
<graingert>
arigato: just need to work out the magic that makes PyPy behave the same
<arigato>
graingert: dig inside CPython's ast compiler to figure out the ordering of "free" variables, and then dig inside PyPy's ast compiler to figure out if and why it is different
<antocuni>
graingert: patchy looks both interesting and horrifying at the same time :)
<graingert>
antocuni: it's the best
<graingert>
a bit dodgy on pypy though
<arigato>
cpython seems to sort the free variables alphabetically
<antocuni>
graingert: that test is not really meaningful: it has 50% of probability to work by chance, if the order is random or not well defined. It should contain many more variables with random names to be more robust
<graingert>
antocuni: probably, but it's never failed in many runs
<graingert>
arigato: but on PyPy the dict should be ordered
<arigato>
it doesn't matter
<graingert>
?
<arigato>
there are no dicts around
<arigato>
only a few ones used internally
<arigato>
and their order doesn't matter
<graingert>
arigato: so the dict_keys_inorder fn doesn't matter?
<antocuni>
arigato: it seems to matter on CPython 2.7 though, see the link I pasted above
<arigato>
I think CPython 3.x added alphabetical ordering of co_freevars for no reason I understand, because previously the order is deterministic too
<graingert>
arigato: is the order deterministic or not?
<arigato>
antocuni: no, note that the order of iteration inside dict_keys_inorder() doesn't change anything
<arigato>
it just changes the order in which the items of the new tuple are filled,
<rowillia>
LarstiQ: I played around with it quite a bit and unfortunately I've gotten a bit lost in how ctypes work in PyPy. The core of the issue is in assigning to `p_mins[0]` (type(p_mins) is `<class '_ctypes.pointer.LP_LP_c_double'>`)
<arigato>
but they will end up the same
<rowillia>
type(p_mins[0]) is <class '_ctypes.pointer.LP_c_double'>
<LarstiQ>
rowillia: what should the value of dimensions be?
<LarstiQ>
rowillia: the snippet isn't runnable as is?
vkirilic_ has quit [Remote host closed the connection]
<rowillia>
LarstiQ: I have it in a debugger now, `dimension` is 2
<arigato>
antocuni: ah, but dictbytype(), called earlier, is dict-order-dependent
<arigato>
it depends on the order of another dict, which contains all free variables as keys
<antocuni>
arigato: I admit that I don't fully understand the code
<rowillia>
@LarstiQ so far I've been unable to create a repro not using rtree
<arigato>
graingert: so in my current opinion, you are relying (on 2.7) on the fact that usually, if a dict has the same few keys, then d.keys() will return them in the same order
<arigato>
independently on the order in which they were actually inserted into the dict
<arigato>
this can fail though in case of hash collisions
<graingert>
ah no not the same order as insertion
<graingert>
two dicts with the same operations will return keys in the same order
<arigato>
yes, but I'm saying something else
<arigato>
if you stick a few string keys in an empty dictionary
<arigato>
then d.keys() will often return the keys in an order that doesn't depend on the insertion order
<arigato>
it's what the compiler does, so I think that's the reason for why co_freevars ends up in a consistent order
<arigato>
here's an example where CPython 2.7.3 fails foul of this:
<graingert>
arigato: always the same ordering for a single execution
<graingert>
of Python
<graingert>
with the same ops
<arigato>
yes, as I said, that's not what I'm saying
<arigato>
but never mind
rowillia has quit [Remote host closed the connection]
<antocuni>
graingert: btw, "same ops ==> same dict" is not a valid assumption in general. It works with strings because they always hash the same, but if you take e.g. instances, then the hash depend on the id(), which is not deterministic
tbodt has quit [Remote host closed the connection]
<graingert>
but A(1) != A(1)
<antocuni>
who cares. I simply pointed out that "same ops ==> same order of keys" is not generally valid
Guest13312 has joined #pypy
tbodt has joined #pypy
Guest13312 has quit [Client Quit]
<graingert>
antocuni: for ops to be the same they either have to be:
<graingert>
contain equal tuples all(a == b for a, b in zip(ops1, ops2))
<graingert>
contain the same tuples all(id(a) == id(b) for a, b in zip(ops1, ops2))
<graingert>
the same list by id(ops1) == id(ops2)
<graingert>
although my assertion was only for id(ops1) == id(ops2)
jamesaxl has quit [Read error: Connection reset by peer]
<graingert>
but I don't know why that would cause freevars to have a different order
<graingert>
when they are all strings
jamesaxl has joined #pypy
<antocuni>
sure, I'm not talking about freevars. I'm just saying that dictionary order is *generally* not deterministic
<antocuni>
it is deterministic if you have a bunch of conditions, like the ones you wrote down (and which are not enough, I think)
<antocuni>
but this is a weird definition of "general case"
<antocuni>
that said, I don't really care
<antocuni>
and it's dinner time :)
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tbodt has joined #pypy
<graingert>
antocuni: no it's always deterministic, that's why hashdos is a thing
<antocuni>
I don't know what to say, after having showed an example in which it's not
* antocuni
off
jamesaxl has quit [Ping timeout: 260 seconds]
<graingert>
antocuni: they had to make hashes intentionally non-deterministic with PYTHONHASHSEED. But that's only between runs
<graingert>
but dictionaries are deterministic with regard to PYTHONHASHSEED
jamesaxl has joined #pypy
antocuni has quit [Ping timeout: 240 seconds]
Guest13312 has joined #pypy
<kenaan>
arigo default 423026acc94c /pypy/: Fix co_freevars and co_cellvars to always list variables in alphabetical order. It seems that some bytecode hacks ...
<arigato>
graingert: fixed
<arigato>
thanks for the report
<graingert>
arigato: on neato
Guest13312 has quit [Client Quit]
<graingert>
arigato: can we get that in 2.7
<cfbolz>
will be in the next release of both pypy2 and pypy3
<graingert>
arigato: do you have a URL so I can send that to my co(_freevars)-conspirator
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<kenaan>
rlamy PyBuffer 4d42369e2fb3 /pypy/objspace/std/memoryobject.py: Fix tolist() on 1-D buffers
<simpson>
dash: It's really seductive, isn't it? Python's so close to being self-hostable in a way that lets us hack the interpreter trivially and change the language radically.
<simpson>
And yet.
<dash>
simpson: If you only have to do it for a single python program, it's probably not too too much work.
<simpson>
dash: I suppose that that would have worked if our single Python program were a specializeable Monte interpreter.
<simpson>
Which we'd write in RPython since that's the only practical Python specializer. So I guess that we made the right choice.
<dash>
simpson: that sounds very like what you're doing now...
<dash>
heheh
oberstet has quit [Ping timeout: 252 seconds]
tbodt has joined #pypy
vkirilichev has quit [Remote host closed the connection]
<graingert>
dash: why don't they just use HolyC
<dash>
graingert: I daren't speculate.
vkirilichev has joined #pypy
<dash>
(I just saw comments from Terry on a completely unrelated post. Spooky.)
<graingert>
you then return your state, and a Mapping of actions
<graingert>
say URL and some data
<dash>
graingert: sure, you could, but you could also just call some methods on some objects
<graingert>
dash: you can't hand those to ufora
<dash>
graingert: only because python is bad
<graingert>
dash: unless they don't mutate
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
realitix has quit [Quit: Leaving]
tbodt has joined #pypy
linkmauve1 has quit [Ping timeout: 240 seconds]
tbodt has quit [Client Quit]
tbodt has joined #pypy
tbodt has quit [Client Quit]
tbodt has joined #pypy
jamesaxl has joined #pypy
arigato has quit [Quit: Leaving]
tbodt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jamesaxl has quit [Ping timeout: 240 seconds]
tbodt has joined #pypy
jamesaxl has joined #pypy
tbodt has quit [Client Quit]
tbodt has joined #pypy
tbodt has quit [Client Quit]
tbodt has joined #pypy
tbodt has quit [Client Quit]
jamesaxl has quit [Read error: Connection reset by peer]
Guest13312 has joined #pypy
<graingert>
dash: how is python bad?
tbodt has joined #pypy
<dash>
graingert: many answers are possible :) But the main criticism I have, in this context, is that it lacks encapsulation, so building secure environments like ufora wants is extremely hard and limited
<dash>
graingert: it's fairly easy to imagine a python-like language where you can pass objects to untrusted code and be sure the untrusted code can't do anything unauthorized with them
<graingert>
dash: I'd like Python to add more stuff so an immutable sunset makes sense
<graingert>
dash: I'm not interested in permissions
<dash>
?
<graingert>
dash: just immutable code
tbodt has quit [Client Quit]
<graingert>
Subset
<graingert>
Not sunset
<cfbolz>
dash, graingert, simpson: all this is getting rather off topic to #pypy
<dash>
cfbolz: sorry :)
<simpson>
cfbolz: Sorry, I was just considering that blog post, which considers whether PyPy reuse would work for their project.
<graingert>
Does pypy 3.5 support the comma placement rules of 3.6?
jamesaxl has joined #pypy
tbodt has joined #pypy
<graingert>
Like it's got f expressions
tbodt has quit [Client Quit]
tbodt has joined #pypy
tbodt has quit [Client Quit]
<LarstiQ>
comma placement rules?
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
<graingert>
LarstiQ: you can put trailing commas everywhere
<graingert>
Like def foo(*args, **kwargs,):
tbodt has joined #pypy
tbodt has quit [Client Quit]
tbodt has joined #pypy
tbodt has quit [Client Quit]
tbodt has joined #pypy
tbodt has quit [Client Quit]
<simpson>
They finally fixed it!?
<dash>
:O
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
oberstet has joined #pypy
Rhy0lite has quit [Quit: Leaving]
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
the_drow has quit [Ping timeout: 240 seconds]
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
jamesaxl has quit [Read error: Connection reset by peer]
<kenaan>
tobweber stmgc[c8-long-transactions] 1b47d69c4988 /c8/stm/: Implement simple single thread mode that is activated if there are two or less segments in u...
<kenaan>
tobweber stmgc[c8-long-transactions] f7c0d9ef8692 /c8/: Log single thread mode changes
<kenaan>
tobweber stmgc[c8-long-transactions] 9fd6311549e1 /c8/stm/: Add debug output and minor refactorings
aboudreault has quit [Excess Flood]
aboudreault has joined #pypy
jamesaxl has joined #pypy
ramonvg has joined #pypy
jamesaxl has quit [Read error: Connection reset by peer]
jamesaxl has joined #pypy
yuyichao has quit [Ping timeout: 240 seconds]
squeaky_pl has joined #pypy
glyph_ is now known as glyph
jamesaxl has quit [Read error: Connection reset by peer]