These are chat archives for dropbox/pyston

24th
Mar 2015
Chris Toshok
@toshok
Mar 24 2015 00:52
oh interesting. looks like we’re boxing the docstring for functions when they’re executed
Travis Hance
@tjhance
Mar 24 2015 01:56
is that just because it’s actually an expression that gets "evaluated" when the code runs?
Chris Toshok
@toshok
Mar 24 2015 02:23
it occurred to me on the train that it might just be when the function is first compiled
Marius Wachtler
@undingen
Mar 24 2015 17:56
could someone please explain to me why the test/tests/binops_subclass.py test is supposed to print B.radd() and not A.add() on the 4. line
With the current implementation that I have right now it's printing A.add() and I don't know whats missing
Chris Toshok
@toshok
Mar 24 2015 18:00
it’s not printing B.radd() here
oh, oh, cpython does
interesting. if I change class B(A): to class B(object): it switches to A.add() in cpython
maybe cpython defers to the subclass in that situation?
Chris Toshok
@toshok
Mar 24 2015 18:10
actually in cpython/abstract.c there’s this comment:
Marius Wachtler
@undingen
Mar 24 2015 18:10
I first thought that It must be an error in the instancecheck or subclasscheck but for the x + y is does not even get called.
Chris Toshok
@toshok
Mar 24 2015 18:11
  Calling scheme used for binary operations:

  v     w       Action
  -------------------------------------------------------------------
  new   new     w.op(v,w)[*], v.op(v,w), w.op(v,w)
oh, and * =
  [*] only when v->ob_type != w->ob_type && w->ob_type is a subclass of
      v->ob_type
so it looks like it does prefer radd if rhs is a subclass of lhs
Marius Wachtler
@undingen
Mar 24 2015 18:14
thanks :-)
Chris Toshok
@toshok
Mar 24 2015 18:16
no problem. odd behavior :)
down to 2 failing tests on my colocation branch
and they’re not making much sense :)
Marius Wachtler
@undingen
Mar 24 2015 18:18
:-)
Kevin Modzelewski
@kmod
Mar 24 2015 18:49
yeah, it checks the rhs first if it's a subclass of the lhs
I think the rationale is that if you do something like int() + MyIntSubclass() you presumably want to override that behavior
Chris Toshok
@toshok
Mar 24 2015 18:54
so this is failing on my branch and I can’t figure out why:
d = dict()
d["hello world"] = 5
print d[u"hello world"]
fails with KeyError: u'hello world’
but hash() of both str/unicode forms is the same, and ”hello world” == u”hello world” is True
Kevin Modzelewski
@kmod
Mar 24 2015 18:55
oh weird
do str(u"hello world") and u"hello world".encode("ascii") work?
Chris Toshok
@toshok
Mar 24 2015 18:56
yup:
>> str(u"hello world")
'hello world'
>> u"hello world".encode("ascii")
'hello world’
Kevin Modzelewski
@kmod
Mar 24 2015 18:58
hmm
what about d.keys()[0] == u"hello world"
Chris Toshok
@toshok
Mar 24 2015 18:59
True
Kevin Modzelewski
@kmod
Mar 24 2015 19:05
hmm I'm out of ideas...
Chris Toshok
@toshok
Mar 24 2015 19:46
gah, it was this:
-    std::hash<std::string> H;
+    std::hash<string> H;
Travis Hance
@tjhance
Mar 24 2015 19:56
maybe don’t call it string
Marius Wachtler
@undingen
Mar 24 2015 19:56
...
:-P
Travis Hance
@tjhance
Mar 24 2015 19:56
lots of people are used to having using std::string in scope and just type string
Chris Toshok
@toshok
Mar 24 2015 19:56
good call
it’s pyston::string now, which would likely lead to even more confusion
Marius Wachtler
@undingen
Mar 24 2015 21:41
Do instancemethodGCHandler, propertyGCHandler, etc not have to call boxGCHandler(v, b);?
Chris Toshok
@toshok
Mar 24 2015 21:42
they should
Chris Toshok
@toshok
Mar 24 2015 22:47
ahah:
$ ./pyston_dbg -n test/tests/weakref4.py
None
$ ./pyston_dbg -I test/tests/weakref4.py
function
strange that that test isn’t failing for everyone
Chris Toshok
@toshok
Mar 24 2015 23:09
hrm, re: pyston::string, anyone got naming suggestions? @tjhance ? :)
it’s nearly equivalent to llvm::StringRef, except that it supports std::string operators and can create owned char[]’s
Chris Toshok
@toshok
Mar 24 2015 23:14
i could always just use pyston::String
Marius Wachtler
@undingen
Mar 24 2015 23:25
when I run weakref4.py it prints None
Chris Toshok
@toshok
Mar 24 2015 23:26
yeah, somehow it changed on my branch, but it only fails to clear the weakref in the interpreter
which seems like something my changes shouldn’t have affected
the correct output is definitely None
Marius Wachtler
@undingen
Mar 24 2015 23:27
I think naming the class with a uppercase letter makes sense. I think all our classes start uppercase.
mmh :-(
Chris Toshok
@toshok
Mar 24 2015 23:32
do we optimize <slice> = <slice>?
converting that to a single call with all the info it needed would likely help fannkuch a lot
32% of small allocs are from createSlice, 20% from BoxedList::ensure, 20% from listGetitemSlice()
something to think about :)
Marius Wachtler
@undingen
Mar 24 2015 23:37
interesting
thats how the AST looks like:
    #0x31c44e0 = l
    #0x31a5020 = <slice>(3:4)
    #0x31a4fe0 = #0x31c44e0[#0x31a5020]
    #0x31a4f80 = l
    #0x31c3890 = <slice>(2:3)
    #0x31a4f80[#0x31c3890] = #0x31a4fe0
Kevin Modzelewski
@kmod
Mar 24 2015 23:51
I'm not sure how common the slice=slice case is, but we could definitely create a runtime entry point that takes the slice arguments, rather than creating the slice and passing that through
does this show up in the django benchmark?
Chris Toshok
@toshok
Mar 24 2015 23:51
no, just fannkuch that I’ve seen
django didn’t seem too allocation heavy, it just was spending a ton of time in gc::markPhase
hrm, now weakref1.py is failing when run in the interpreter (just after rebasing) :/
but succeeds with -n