Why doesn't our Makefile supply that flag with the make parallelism level
in the sharedmods step?
On Sat Jan 24 2015 at 2:25:45 PM Antoine Pitrou wrote:
> On Sat, 24 Jan 2015 21:53:06 +0100
> "M.-A. Lemburg" wrote:
> >
> > BTW: Parallel execution, cross compilation can be added
> > to setup.py.
But you can remove Python/graminit.c and "make clean && make" works, right?
On Sat, Jan 24, 2015 at 11:00 PM, Nick Coghlan wrote:
>
> On 25 Jan 2015 01:09, "Benjamin Peterson" wrote:
> >
> >
> >
> > On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:
> > > On 20 January 2015 at 10:53, Benjamin
On 25 Jan 2015 01:09, "Benjamin Peterson" wrote:
>
>
>
> On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:
> > On 20 January 2015 at 10:53, Benjamin Peterson
> > wrote:
> > >
> > >
> > > On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:
> > >> I was also wondering why files like Python/gramin
Thanks, I had tried it and got the ambiguities, but I wasn't sure if those
would disappear with editing some peripheral file.
Yes, you're right about the set branch.
Thank you,
Neil
On Sat, Jan 24, 2015 at 10:29 PM, Guido van Rossum wrote:
> Have you tried it yet?
>
> I think you have to inli
Have you tried it yet?
I think you have to inline dictpopulator, because dictpopulator can start
with the same tokens as test, and the parser doesn't backtrack. So it
wouldn't know how to decide whether to take the dictpopulator branch or the
set branch. If you inline it, the parser will know, bec
Closer.
make && make install ran successfully; however running the newly
installed binary results in the same error.
On Sat, Jan 24, 2015 at 5:08 PM, Frank, Matthew I
wrote:
> Android's dlopen() works slightly differently than the normal Unix dlopen()
> in at least two different ways. I haven'
To finish PEP 448, I need to update the grammar for syntax such as
{**x for x in it}
and
{1:2, 3:4, **a}
It's been a long time since I've looked at grammars and I could really use
the advice of an expert. I'm considering replacing:
dictorsetmaker: ( (test ':' test (comp_for | (',' test ':' te
Replies in body of message for clarity:
On Sat, Jan 24, 2015 at 5:08 PM, Frank, Matthew I
wrote:
> Android's dlopen() works slightly differently than the normal Unix dlopen()
> in at least two different ways. I haven't seen your particular problem, but
> that's probably because I'm cross-build
Android's dlopen() works slightly differently than the normal Unix dlopen() in
at least two different ways. I haven't seen your particular problem, but
that's probably because I'm cross-building CPython (building everything I need
on a Linux machine, and then copying the install directory to th
On Sat, 24 Jan 2015 21:53:06 +0100
"M.-A. Lemburg" wrote:
>
> BTW: Parallel execution, cross compilation can be added
> to setup.py. I don't think parallel execution is all
> that important,
$ ./python setup.py build_ext --help
[...]
--parallel (-j) number of parallel build jobs
Regards
On Sat, Jan 24, 2015 at 2:23 PM, Zachary Ware wrote:
> On Saturday, January 24, 2015, Brett Cannon wrote:
>>
>> On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith wrote:
>>>
>>> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg wrote:
On 23.01.2015 19:48, Matthias Klose wrote:
> On
On Saturday, January 24, 2015, Brett Cannon wrote:
> On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith > wrote:
>
>> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg > > wrote:
>>
>>> On 23.01.2015 19:48, Matthias Klose wrote:
>>> > On 01/23/2015 06:30 PM, Cyd Haselton wrote:
>>> >> Related to my
On 24.01.2015 21:23, Zachary Ware wrote:
> On Saturday, January 24, 2015, Brett Cannon wrote:
>
>> On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith > > wrote:
>>
>>> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg >> > wrote:
>>>
On 23.01.2015 19:48, Matthias Klose wrote:
> On 01/23/201
On Sat, Jan 24, 2015 at 11:11 AM, Maciej Fijalkowski
wrote:
> Hi Guido.
>
> I *think* part of the reason why our implementation works is that
> machines are significantly different than at the times of Knuth.
> Avoiding cache misses is a very effective way to improve performance
> these days.
>
Hi Guido.
I *think* part of the reason why our implementation works is that
machines are significantly different than at the times of Knuth.
Avoiding cache misses is a very effective way to improve performance
these days.
Cheers,
fijal
On Sat, Jan 24, 2015 at 7:39 PM, Guido van Rossum wrote:
>
On Sat, Jan 24, 2015 at 3:50 AM, Maciej Fijalkowski wrote:
> I would like to point out that we implemented rhettingers idea in PyPy
> that makes all the dicts ordered by default and we don't have any
> adverse performance effects (in fact, there is quite significant
> memory saving coming from it)
On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith wrote:
> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg wrote:
>
>> On 23.01.2015 19:48, Matthias Klose wrote:
>> > On 01/23/2015 06:30 PM, Cyd Haselton wrote:
>> >> Related to my earlier question regarding building Python on Android
>> >> and a
Wow, very cool. When I implemented the very first Python dict (cribbing
from an algorithm in Knuth) I had no idea that 25 years later there would
still be ways to improve upon it! I've got a feeling Knuth probably didn't
expect this either...
On Sat, Jan 24, 2015 at 2:51 AM, Maciej Fijalkowski
wr
> On Jan 24, 2015, at 10:17 AM, Donald Stufft wrote:
>
> Or you have things like pdb++ which needs to replace the pdb import
> because a lot of tools only have a flag like —pdb and do not provide
> a way to switch it to a different import. The sys.path ordering means
> that pdb++ has to do hacks
> On Jan 24, 2015, at 2:57 AM, Nick Coghlan wrote:
>
> On 15 January 2015 at 07:35, Donald Stufft wrote:
>>
>> On Jan 14, 2015, at 4:19 PM, Brett Cannon wrote:
>>
>> But as Guido pointed out, we _like_ it being difficult to do because we
>> don't want this kind of substitution happening as c
On Sat, Jan 24, 2015, at 03:00, Nick Coghlan wrote:
> On 20 January 2015 at 10:53, Benjamin Peterson
> wrote:
> >
> >
> > On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:
> >> I was also wondering why files like Python/graminit.c are in the
> >> respository? They generate spurious merge conf
On Fri, Jan 23, 2015 at 12:48 PM, Matthias Klose wrote:
> On 01/23/2015 06:30 PM, Cyd Haselton wrote:
>> Related to my earlier question regarding building Python on Android
>> and an undefined reference to dlopen error...I have the following
>> question: Is it possible to build and install Python
On Fri, Jan 23, 2015 at 12:48 PM, Matthias Klose wrote:
> On 01/23/2015 06:30 PM, Cyd Haselton wrote:
>> Related to my earlier question regarding building Python on Android
>> and an undefined reference to dlopen error...I have the following
>> question: Is it possible to build and install Python
On Sat, Jan 24, 2015 at 12:50 PM, Maciej Fijalkowski wrote:
> Hi
>
> I would like to point out that we implemented rhettingers idea in PyPy
> that makes all the dicts ordered by default and we don't have any
> adverse performance effects (in fact, there is quite significant
> memory saving coming
Hi
I would like to point out that we implemented rhettingers idea in PyPy
that makes all the dicts ordered by default and we don't have any
adverse performance effects (in fact, there is quite significant
memory saving coming from it). The measurments on CPython could be
different, but in principl
On 20 January 2015 at 10:53, Benjamin Peterson wrote:
>
>
> On Mon, Jan 19, 2015, at 19:40, Neil Girdhar wrote:
>> I was also wondering why files like Python/graminit.c are in the
>> respository? They generate spurious merge conflicts.
>
> Convenience mostly.
It also gets us a round a couple of
26 matches
Mail list logo
