These are chat archives for dropbox/pyston

4th
Sep 2015
Sun
@Daetalus
Sep 04 2015 01:10
Hi @kmod Would you mind restart the gcc build of #893?
Sun
@Daetalus
Sep 04 2015 10:46
Hi @kmod , can we copy CPython's list_sort to Pyston?
Kevin Modzelewski
@kmod
Sep 04 2015 10:48
doesn't seem like a bad idea
are we running into issues with our implementation?
Sun
@Daetalus
Sep 04 2015 10:51
Current list.sort could not handle cmp and key keyword simultaneously. And also could not raise exception if the cmp function modified in comparison.
Just the CPython's list_sort is a bit long. Include its related function.
Kevin Modzelewski
@kmod
Sep 04 2015 10:53
well, copying their implementation seems like a reasonable solution
I'm not sure how high priority the problem is though
is this just from a cpython test?
Sun
@Daetalus
Sep 04 2015 10:54
Just want let the test_list could pass, nothing more.
yes
Kevin Modzelewski
@kmod
Sep 04 2015 10:57
I'd say if you're interested then go for it :)
but yeah it seems like somewhat of a pain so I don't think it would be that bad to just skip that test for now
Sun
@Daetalus
Sep 04 2015 11:04
Ok, so Just leave it.
Next week I will have enough time to make contribution to Pyston. I will try to finish the constant tuple issue first. Then would you mind to assign a task to me?
An Long
@aisk
Sep 04 2015 15:31
Hi, I want implement sys.long_info, but since pyston use gmp as long, how is it's 'sizeof_digit'? since gmp's mtz_t is not fixed length type.
Sun
@Daetalus
Sep 04 2015 15:35
Ignore it for now. Maybe the Pyston long implementation will switch to CPython in future(In order to support Windows platform).
CPython seems use array to represent long object. But the current Pyston long object doesn't need it.
An Long
@aisk
Sep 04 2015 15:38
Thx, so can I just implement sys.long_info with some const number, so we can run cpython/test_long.py? because this test file have extremely dependence on it.
Sun
@Daetalus
Sep 04 2015 15:39
That's ok.
An Long
@aisk
Sep 04 2015 15:39
Thanks :smile:
Marius Wachtler
@undingen
Sep 04 2015 16:12
man I just wasted nearly a whole day with trying out different small GC related changes which I thought could bring a little bit of perf improvement but resulted in no perf increase :-(. I knew that this is an area where we already looked into a lot but I still thought that some stuff has to increase perf...
Marius Wachtler
@undingen
Sep 04 2015 16:25
in order that no one tries the same again:
saw that from 50k reachable objects 20k are immortal strings
  • tried to directly use the intern string map instead putting them in the heaproot set
  • tried to add a immortal bit to the gc to we don't have to scan them at all
  • tried arround with builtin_prefetch etc because I saw that the isMarked call introduces to many cache misses...
  • tried simple concurrent marking
  • changed a few calls from conservative to untracked where we know that they can't contain pointers
Sun
@Daetalus
Sep 04 2015 21:02
Hi @kmod, I am fixing test_string. the string.Formatter need formatter_parser, which is in `from_cpython/Objects/stringlib/string_format.h"
Due to unicode implementation was copied from CPython directly. It has PyType_Ready(PyFormatterIter_Type) But it not work for string object if I call formatter_parser in str.cpp.
CPython seems call PyType_Ready(PyFormatterIter_Type) only in unicodeobject.c.
Kevin Modzelewski
@kmod
Sep 04 2015 23:55
oh hmm interesting
I think we might have to call PyType_Ready in from_cpython/Objects/stringobject.c
ie add some sort of initialization function and then call it from str.cpp