Re: [Python-Dev] API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, Current merge rate is count in a mixed way (patch + PR). After reading Bertt's post "The history behind the decision to move Python to GitHub", I would like to separate the count of merge rate to hg and GitHub. It may check that did migrate to GitHub get the better process of CPython development. Best Regards, Louie. 2017-04-24 23:55 GMT+08:00 Louie Lu : > Hi all, > > thanks for all your reply, since roundup didn't contain JSON REST API, and > I'm not sure did roundup robot have deal with "patched but still open" > situation, thus I do some change to bpo-mergerate and have some result. > > GitHub repo: https://github.com/lulouie/bpo-mergerate > Demo site: https://bpo-mergerate.louie.lu > > Now bpo-mergerate using SQLite database and no more CSV file, and an > update.py script was added, on my host, it will automatically update the > bpo patch status hourly. > For the site, it is now using ajax and can deal with fuzzy search. > > The merge rate calculate is now find-grained to per-file, and will > automatically count the prefix merge rate, for example: > > Searching: Lib/test > Result: > path merged open totalrate > /Lib/test 3013 1359 4372 68.916 > Lib/test/test_ssl.py 60 15 75 80.000 > Lib/test/test_inspect.py 56 12 68 82.353 > > > I think the site function is complete now, welcome for any suggestion. > (maybe like speed.python.org make a timeline for the merge rate?) > > Best Regards, > Louie. > > 2017-04-24 12:08 GMT+08:00 Nick Coghlan : > >> On 21 April 2017 at 06:04, Wes Turner wrote: >> > Roundup has an xmlrpc API: >> > >> > - https://sourceforge.net/p/roundup/code/ci/default/tree/round >> up/xmlrpc.py >> > - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ >> test_xmlrpc.py >> >> There's also a pending patch to add a HTTPS+JSON REST API to our >> Roundup instance: >> http://psf.upfronthosting.co.za/roundup/meta/issue581 >> >> Definite +1 for the general idea of collecting and publishing these >> kinds of statistics, though - I can see them being quite useful to a >> variety of audiences. >> >> Cheers, >> Nick. >> >> P.S. The upstream Roundup project is also interested in offering that >> capability by default: http://issues.roundup-tracker.org/issue2550734 >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Details on replacing Python's dict object
Hello: I'm attempting to replace Python's dict object with an algorithm I created myself to improve on memory and time consumption of hashmaps. My initial tests on the algorithm show that it manages to keep a stable logarithmic performance even with extremely high load factors (>0.9). My knowledge of C and Python are good enough but I only know how the interpreter works from a theoretical viewpoint, never really done any deep investigation into it. This said, I need expert help to port the algorithm, any insight into the details of the dict object is greatly appreciated (and please let it be as technical and guru-ish as possible). Regards J. Aaron Lopez. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Details on replacing Python's dict object
While not super technical, this talk by RH got me up to speed on recent improvements in the implementation: https://www.youtube.com/watch?v=p33CVV29OG8 I believe there is some sample code linked that you might be able to use for testing/benchmarking, etc. -Mike On 2017-04-25 12:52, Jose Aaron Lopez Garcia wrote: Hello: I'm attempting to replace Python's dict object with an algorithm I created myself to improve on memory and time consumption of hashmaps. My initial tests on the algorithm show that it manages to keep a stable logarithmic performance even with extremely high load factors (>0.9). My knowledge of C and Python are good enough but I only know how the interpreter works from a theoretical viewpoint, never really done any deep investigation into it. This said, I need expert help to port the algorithm, any insight into the details of the dict object is greatly appreciated (and please let it be as technical and guru-ish as possible). Regards J. Aaron Lopez. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API for bugs.python.org or some statistic about lib/module merge rate?
Hi all, Fix some pr counting issue, and now the bpo-mergerate can choose hg (the old process), git, or all for mergerate counting. Also, relative bpo issue can be expand by clicking row for more detail. demo site: https://bpo-mergerate.louie.lu Best Regards, Louie. 2017-04-25 16:18 GMT+08:00 Louie Lu : > Hi all, > > Current merge rate is count in a mixed way (patch + PR). > > After reading Bertt's post "The history behind the decision to move Python > to GitHub", I would like to separate the count of merge rate to hg and > GitHub. > > It may check that did migrate to GitHub get the better process of CPython > development. > > > Best Regards, > Louie. > > > > 2017-04-24 23:55 GMT+08:00 Louie Lu : > >> Hi all, >> >> thanks for all your reply, since roundup didn't contain JSON REST API, >> and I'm not sure did roundup robot have deal with "patched but still open" >> situation, thus I do some change to bpo-mergerate and have some result. >> >> GitHub repo: https://github.com/lulouie/bpo-mergerate >> Demo site: https://bpo-mergerate.louie.lu >> >> Now bpo-mergerate using SQLite database and no more CSV file, and an >> update.py script was added, on my host, it will automatically update the >> bpo patch status hourly. >> For the site, it is now using ajax and can deal with fuzzy search. >> >> The merge rate calculate is now find-grained to per-file, and will >> automatically count the prefix merge rate, for example: >> >> Searching: Lib/test >> Result: >> path merged open totalrate >> /Lib/test 3013 1359 4372 68.916 >> Lib/test/test_ssl.py 60 15 75 80.000 >> Lib/test/test_inspect.py 56 12 68 82.353 >> >> >> I think the site function is complete now, welcome for any suggestion. >> (maybe like speed.python.org make a timeline for the merge rate?) >> >> Best Regards, >> Louie. >> >> 2017-04-24 12:08 GMT+08:00 Nick Coghlan : >> >>> On 21 April 2017 at 06:04, Wes Turner wrote: >>> > Roundup has an xmlrpc API: >>> > >>> > - https://sourceforge.net/p/roundup/code/ci/default/tree/round >>> up/xmlrpc.py >>> > - https://sourceforge.net/p/roundup/code/ci/default/tree/test/ >>> test_xmlrpc.py >>> >>> There's also a pending patch to add a HTTPS+JSON REST API to our >>> Roundup instance: >>> http://psf.upfronthosting.co.za/roundup/meta/issue581 >>> >>> Definite +1 for the general idea of collecting and publishing these >>> kinds of statistics, though - I can see them being quite useful to a >>> variety of audiences. >>> >>> Cheers, >>> Nick. >>> >>> P.S. The upstream Roundup project is also interested in offering that >>> capability by default: http://issues.roundup-tracker.org/issue2550734 >>> >>> -- >>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >>> >> >> > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
