On 19 October 2016 at 01:28, Chris Barker - NOAA Federal
wrote:
> def get_builtin_methods():
>>... return [(name, method_name) for name, obj in
>> get_builtin_types().items() for method_name, method in
>> vars(obj).items() if not method_name.startswith("__")]
>>...
> len(get_bu
Hi Victor,
Thanks for the great contribution to the unified benchmark development! In
addition to the OutReachy program that we are currently supporting, let us know
how else we could help out in this effort.
Other than micros and benchmarking ideas, we'd also like to hear suggestions
from t
On 20 October 2016 at 17:38, Ethan Furman wrote:
> On 10/20/2016 03:56 AM, Victor Stinner wrote:
>
>> Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
>> results in depth (up to the hardware and kernel drivers!), I wrote new
>> tools and enhanced existing tools.
>
>
> Thank yo
On 20.10.16 13:56, Victor Stinner wrote:
Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
results in depth (up to the hardware and kernel drivers!), I wrote new
tools and enhanced existing tools.
Great work! Thank you Victor.
__
On Thu, Oct 20, 2016 at 11:23 AM, Skip Montanaro
wrote:
>
> On Thu, Oct 20, 2016 at 7:35 AM, Victor Stinner
> wrote:
>>
>> Are you on the 2.7 branch or the default branch?
>>
>> You might try to cleanup your checkout:
>>
>> hg up -C -r 2.7
>> make distclean
>> hg purge # WARNING! it removes *all*
On 10/20/2016 03:56 AM, Victor Stinner wrote:
Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
results in depth (up to the hardware and kernel drivers!), I wrote new
tools and enhanced existing tools.
Thank you!
--
~Ethan~
___
P
Thank you Victor! This is a massive amount of work.
On 2016-10-20 6:56 AM, Victor Stinner wrote:
* I plan to run performance on CPython 2.7, CPython 3.7, PyPy and PyPy
3. Maybe also CPython 3.5 and CPython 3.6 if they don't take too much
resources.
I think it's important to run 3.5 & 3.6 to
On Thu, Oct 20, 2016 at 7:35 AM, Victor Stinner
wrote:
>
> Are you on the 2.7 branch or the default branch?
>
> You might try to cleanup your checkout:
>
> hg up -C -r 2.7
> make distclean
> hg purge # WARNING! it removes *all* files not tracked by Mercurial
> ./configure && make
>
> You should al
On Thu, Oct 20, 2016 at 4:56 AM, Victor Stinner
wrote:
> Hi,
>
> Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
> results in depth (up to the hardware and kernel drivers!), I wrote new
> tools and enhanced existing tools.
This is a massive contribution. Thanks!
> All thes
Hi Victor
Despite the fact that I was not able to find time to run your stuff
yet, thanks for all the awesome work!
On Thu, Oct 20, 2016 at 12:56 PM, Victor Stinner
wrote:
> Hi,
>
> Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
> results in depth (up to the hardware and k
Are you on the 2.7 branch or the default branch?
You might try to cleanup your checkout:
hg up -C -r 2.7
make distclean
hg purge # WARNING! it removes *all* files not tracked by Mercurial
./configure && make
You should also paste the full error message.
Victor
2016-10-20 13:47 GMT+02:00 Skip M
On Thu, Oct 20, 2016 at 6:47 AM, Skip Montanaro
wrote:
> Is it possible that the fix wasn't propagated to
> the 2.7 branch? Or perhaps I've fouled up my hg repo relationships?
Either way, I went ahead and opened a ticket:
http://bugs.python.org/issue28487
S
_
I've recently run into a problem building the math and cmath modules
for 2.7. (I don't rebuild very often, so this problem might have been
around for awhile.) My hg repos look like this:
* My cpython repo pulls from https://hg.python.org/cpython
* My 2.7 repo (and other non-tip repos) pulls from
Hi,
Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
results in depth (up to the hardware and kernel drivers!), I wrote new
tools and enhanced existing tools.
* I wrote a new perf module which runs benchmarks in a reliable way
and contains a LOT of features: collect metadata,
14 matches
Mail list logo
