Nick Coghlan writes:
> I'll stick with named branches until MQ becomes a builtin Hg
> feature that better integrates with other tools.
AFAIK MQ *is* considered to be a *stable, standard* part of Hg
functionality that *happens* (for several reasons *not* including
"it's not ready for Prime Time"
>
> Eli, the use pattern I was referring to is when you read in chunks,
> and and append to a running buffer. Presumably if you know in advance
> the size of the data, you can readinto directly to a region of a
> bytearray. There by avoiding having to allocate a temporary buffer for
> the read, and
> On Thu, 24 Nov 2011 20:53:30 +0200
> Eli Bendersky wrote:
> >
> > Sure. Updated the default branch just now and built:
> >
> > $1 -m timeit -s'import fileread_bytearray'
> 'fileread_bytearray.justread()'
> > 1000 loops, best of 3: 1.14 msec per loop
> > $1 -m timeit -s'import fileread_bytearray'
On Fri, Nov 25, 2011 at 12:07 PM, Antoine Pitrou wrote:
> On Fri, 25 Nov 2011 12:02:17 +1100
> Matt Joiner wrote:
>> It's my impression that the readinto method does not fully support the
>> buffer interface I was expecting. I've never had cause to use it until
>> now. I've created a question on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/11/11 18:08, Éric Araujo wrote:
>> I have a question and I would rather have an answer instead of
>> actually trying and getting myself in a messy situation.
> Clones are cheap, trying is cheap!
I would need to publish another repository onlin
On 25/11/2011 00:20, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When mailing there, I get this error. Not sure where to report.
The address works fine. It would be nice if someone fixed the annoying
bounce however. :-)
Michael
"""
Final-Recipient: rfc822; sdr...@sdrees
On Fri, 25 Nov 2011 12:02:17 +1100
Matt Joiner wrote:
> It's my impression that the readinto method does not fully support the
> buffer interface I was expecting. I've never had cause to use it until
> now. I've created a question on SO that describes my confusion:
>
> http://stackoverflow.com/q/
It's my impression that the readinto method does not fully support the
buffer interface I was expecting. I've never had cause to use it until
now. I've created a question on SO that describes my confusion:
http://stackoverflow.com/q/8263899/149482
Also I saw some comments on "top-posting" am I gu
Eli,
Example coming shortly, the differences are quite significant.
On Fri, Nov 25, 2011 at 9:41 AM, Eli Bendersky wrote:
> On Fri, Nov 25, 2011 at 00:02, Matt Joiner wrote:
>>
>> What if you broke up the read and built the final string object up. I
>> always assumed this is where the real gain
On 11/24/2011 5:02 PM, Matt Joiner wrote:
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
If a pure read takes twice as long in 3.3 as in 3.2, that is a concern
regardless of whether there is a better way.
-
On Thu, 24 Nov 2011 20:53:30 +0200
Eli Bendersky wrote:
>
> Sure. Updated the default branch just now and built:
>
> $1 -m timeit -s'import fileread_bytearray' 'fileread_bytearray.justread()'
> 1000 loops, best of 3: 1.14 msec per loop
> $1 -m timeit -s'import fileread_bytearray'
> 'fileread_byt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When mailing there, I get this error. Not sure where to report.
"""
Final-Recipient: rfc822; sdr...@sdrees.de
Original-Recipient: rfc822;webmas...@python.org
Action: failed
Status: 5.1.1
Remote-MTA: dns; stefan.zinzdrees.de
Diagnostic-Code: smtp; 550
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trying to clear the licensing issues surrounding my DTrace work
(http://bugs.python.org/issue13405) I am contacting Sun/Oracle guys.
Checking documentation abut the contributor license agreement, I had
encounter a wrong HTML link in http://www.python.
On Fri, Nov 25, 2011 at 7:46 AM, Xavier Morel wrote:
> On 2011-11-24, at 21:55 , Nick Coghlan wrote:
>> I've never been able to get the Create Patch button to work reliably with
>> my BitBucket repo, so I still just run "hg diff -r default" locally and
>> upload the patch directly.
> Wouldn't it b
On Fri, Nov 25, 2011 at 7:23 AM, "Martin v. Löwis" wrote:
> Am 24.11.2011 21:55, schrieb Nick Coghlan:
>> I've never been able to get the Create Patch button to work reliably
>> with my BitBucket repo, so I still just run "hg diff -r default" locally
>> and upload the patch directly.
>
> Please su
On Fri, Nov 25, 2011 at 00:02, Matt Joiner wrote:
> What if you broke up the read and built the final string object up. I
> always assumed this is where the real gain was with read_into.
>
Matt, I'm not sure what you mean by this - can you suggest the code?
Also, I'd be happy to know if anyone e
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
On Nov 25, 2011 5:55 AM, "Eli Bendersky" wrote:
> On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou wrote:
>
>> On Thu, 24 Nov 2011 20:15:25 +0200
>> Eli Bendersky wr
On 2011-11-24, at 21:55 , Nick Coghlan wrote:
> I've never been able to get the Create Patch button to work reliably with
> my BitBucket repo, so I still just run "hg diff -r default" locally and
> upload the patch directly.
Wouldn't it be simpler to just use MQ and upload the patch(es) from the se
Am 24.11.2011 21:55, schrieb Nick Coghlan:
> I've never been able to get the Create Patch button to work reliably
> with my BitBucket repo, so I still just run "hg diff -r default" locally
> and upload the patch directly.
Please submit a bug report to the meta tracker.
> It would be nice if I cou
I've never been able to get the Create Patch button to work reliably with
my BitBucket repo, so I still just run "hg diff -r default" locally and
upload the patch directly.
It would be nice if I could just specify both the feature branch *and* the
branch to diff against rather than having to work
On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou wrote:
> On Thu, 24 Nov 2011 20:15:25 +0200
> Eli Bendersky wrote:
> >
> > Oops, readinto takes the same time as copying. This is a real shame,
> > because readinto in conjunction with the buffer interface was supposed to
> > avoid the redundant copy
On Thu, 24 Nov 2011 20:15:25 +0200
Eli Bendersky wrote:
>
> Oops, readinto takes the same time as copying. This is a real shame,
> because readinto in conjunction with the buffer interface was supposed to
> avoid the redundant copy.
>
> Is there a real performance regression here, is this a well
Hi there,
I was doing some experiments with the buffer interface of bytearray today,
for the purpose of quickly reading a file's contents into a bytearray which
I can then modify. I decided to do some benchmarking and ran into
surprising results. Here are the functions I was timing:
def justread(
Hi,
> I have a question and I would rather have an answer instead of
> actually trying and getting myself in a messy situation.
Clones are cheap, trying is cheap!
> Let say we have the following scenario:
>
> 1. A programer clones hg.python.org.
> 2. Programer creates a named branch and start t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a question and I would rather have an answer instead of
actually trying and getting myself in a messy situation.
Let say we have the following scenario:
1. A programer clones hg.python.org.
2. Programer creates a named branch and start to deve
On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski wrote:
> The problem is not with maintaining the modified directory. The
> problem was always things like changing interface between the C
> version and the Python version or introduction of new stuff that does
> not run on pypy because it relie
On Wed, Nov 23, 2011 at 11:13 PM, Philip Jenvey wrote:
>
> On Nov 22, 2011, at 12:43 PM, Amaury Forgeot d'Arc wrote:
>
>> 2011/11/22 Philip Jenvey
>> One reason to target 3.2 for now is it's not a moving target. There's
>> overhead involved in managing modifications to the pure python standard l
27 matches
Mail list logo
