Den tisdag 30 juni 2015 kl. 01:11:51 UTC+2 skrev Ian:
> On Mon, Jun 29, 2015 at 4:56 PM, Ian Kelly wrote:
> > On Mon, Jun 29, 2015 at 4:39 PM, wrote:
> >> http://jt.node365.se/baseconversion8.html
> >
> > Back of the envelope mental calculation, that appears to be quadratic,
> > not linear. Doub
Hi,
I'm Needing to get python 2.7.10 to cross compile correctly for an ARM
embedded device.
I'm very close, as it does build with warnings, but the result is
defective and I'm not sure how to fix it.
For some odd reason, the interpreter does run -- but I either get random
segfaults -- or if I
On Tue, 30 Jun 2015 04:03:57 +0200, Laura Creighton wrote:
> In a message of 30 Jun 2015 00:56:26 +, Peter Pearson writes:
>>The following code produces a plot with a line running from (9:30, 0) to
>>(10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>>
>>If I use timezone None instead o
On Tue, 30 Jun 2015 12:11:31 +1000, Chris Angelico wrote:
> On Tue, Jun 30, 2015 at 10:56 AM, Peter Pearson
> wrote:
>> The following code produces a plot with a line running from (9:30, 0) to
>> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>>
>> pacific = pytz.timezone("US/Pacific")
>
On Tue, 30 Jun 2015 06:52 am, Randall Smith wrote:
> Not sure why you posted the link. The crc32 checksum is just to check
> for possible filesystem corruption. The system does periodic data
> corruption checks. BTRFS uses crc32 checksums also. Please explain.
The file system can trust that a
On Tue, Jun 30, 2015 at 10:56 AM, Peter Pearson
wrote:
> The following code produces a plot with a line running from (9:30, 0) to
> (10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>
> pacific = pytz.timezone("US/Pacific")
> plt.plot([datetime.datetime(2014, 10, 7, 8, 30, tzinfo=pacific),
In a message of 30 Jun 2015 00:56:26 +, Peter Pearson writes:
>The following code produces a plot with a line running from (9:30, 0) to
>(10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
>
>If I use timezone None instead of pacific, the plot is as desired, but
>of course that doesn't sol
The following code produces a plot with a line running from (9:30, 0) to
(10:30, 1), not from (8:30, 0) to (9:30, 1) as I desire.
If I use timezone None instead of pacific, the plot is as desired, but
of course that doesn't solve the general problem of which this is a
much-reduced example.
If I u
On Sun, 28 Jun 2015 17:07:00 -0700, Ned Batchelder wrote:
> On Sunday, June 28, 2015 at 5:02:19 PM UTC-4, Denis McMahon wrote:
>>
>> string 3
>> string 2
>> string 1
>>
>> Each is just a member of the collection things, the xml does
>> not contain sufficient information to state that i
On 29Jun2015 11:36, Chris Angelico wrote:
On Mon, Jun 29, 2015 at 4:55 AM, Steven D'Aprano wrote:
Try Ctrl-TAB again, and you'll get "raise" instead of "import".
Can anyone else replicate this issue?
Is this a Python issue, a problem with the terminal I am using, or readline
in general?
Co
Ian Kelly writes:
> On Mon, Jun 29, 2015 at 4:56 PM, Ian Kelly wrote:
>> On Mon, Jun 29, 2015 at 4:39 PM, wrote:
>>> http://jt.node365.se/baseconversion8.html
> By the way, I think you have a bug. I did my time testing by
> concatenating the default input number to itself several times. At
>
Den tisdag 30 juni 2015 kl. 01:11:51 UTC+2 skrev Ian:
> On Mon, Jun 29, 2015 at 4:56 PM, Ian Kelly wrote:
> > On Mon, Jun 29, 2015 at 4:39 PM, wrote:
> >> http://jt.node365.se/baseconversion8.html
> >
> > Back of the envelope mental calculation, that appears to be quadratic,
> > not linear. Doub
On Mon, Jun 29, 2015 at 4:56 PM, Ian Kelly wrote:
> On Mon, Jun 29, 2015 at 4:39 PM, wrote:
>> http://jt.node365.se/baseconversion8.html
>
> Back of the envelope mental calculation, that appears to be quadratic,
> not linear. Doubling the length of the input results in an approximate
> quadrupli
On Mon, Jun 29, 2015 at 4:39 PM, wrote:
> http://jt.node365.se/baseconversion8.html
Back of the envelope mental calculation, that appears to be quadratic,
not linear. Doubling the length of the input results in an approximate
quadrupling of the time taken to produce the output.
That noted, this
http://jt.node365.se/baseconversion8.html
--
https://mail.python.org/mailman/listinfo/python-list
On 29/06/2015 21:59, Terry Reedy wrote:
On 6/29/2015 7:17 AM, Terry Reedy wrote:
On 6/29/2015 3:08 AM, Laura Creighton wrote:
In a message of Mon, 29 Jun 2015 02:14:43 +0100, Mark Lawrence writes:
Purely as an exercise I've been converting Grant Jenks' pypatt[1] from
2.7 to 3.4. I've managed
On 6/29/2015 7:17 AM, Terry Reedy wrote:
On 6/29/2015 3:08 AM, Laura Creighton wrote:
In a message of Mon, 29 Jun 2015 02:14:43 +0100, Mark Lawrence writes:
Purely as an exercise I've been converting Grant Jenks' pypatt[1] from
2.7 to 3.4. I've managed to sort out most of the required changes
On 2015-06-29, Randall Smith wrote:
> Same reason newer filesystems like BTRFS use checkusms (BTRFS uses
> CRC32). The storage machine runs periodic file integrity checks. It
> has no control over the underlying filesystem.
True, but presumably neither does it have anything it can do to
recti
On 06/27/2015 01:50 PM, Steven D'Aprano wrote:
On Sun, 28 Jun 2015 03:08 am, Randall Smith wrote:
Though I didn't mention it in the description, the storage server is
appending a CRC32 checksum for routine integrity checks. So by the time
the data hits the disk, it will have added both a 256 b
On 06/28/2015 09:21 AM, Jon Ribbens wrote:
On 2015-06-27, Randall Smith wrote:
Thankyou. Nice points. I do think given the risks (there are always
risks) discussed, a successful attack of this nature is not very likely.
Worse case, something that looks like this would land on the disk.
crc
In a message of Mon, 29 Jun 2015 20:06:05 -, "Devaki Chokshi (dchokshi)" wr
ites:
>Hello,
>
>As per reply received I have begun to use scapy for MGCP.
>
>I started off with reading a .pcap file with MGCP packets.
>
>For example:
>
>from scapy.all import *
>from scapy.utils import *
>from sca
On 6/29/2015 10:03 AM, random...@fastmail.us wrote:
I installed Python 2.1 for historical interest and it associated python
files with the python 2.1 interpreter. I installed 3.4 afterwards (I had
3.3 as my latest python version before) expecting this to fix it, but it
left it alone. Even deletin
On Sunday, 28 June 2015 03:46:56 UTC-4, Stefan Behnel wrote:
> Denis McMahon schrieb am 26.06.2015 um 09:44:
> > xml data is an unordered list, and are trying to assign an order to it.
> >
> > If the xml data was ordered, either each tag would be different, or each
> > tag would have an attribut
I installed Python 2.1 for historical interest and it associated python
files with the python 2.1 interpreter. I installed 3.4 afterwards (I had
3.3 as my latest python version before) expecting this to fix it, but it
left it alone. Even deleting all the Python associations from the
registry and th
On 2015-06-28 22:00, Denis McMahon wrote:
On Sun, 28 Jun 2015 09:46:36 +0200, Stefan Behnel wrote:
Denis McMahon schrieb am 26.06.2015 um 09:44:
xml data is an unordered list, and are trying to assign an order to it.
If the xml data was ordered, either each tag would be different, or
each tag
On 6/29/2015 3:08 AM, Laura Creighton wrote:
In a message of Mon, 29 Jun 2015 02:14:43 +0100, Mark Lawrence writes:
Purely as an exercise I've been converting Grant Jenks' pypatt[1] from
2.7 to 3.4. I've managed to sort out most of the required changes by
checking on what I can see with an AST
On Saturday 27 June 2015 08:27:38 Laura Creighton wrote:
> In a message of Sat, 27 Jun 2015 20:16:47 +1000, Chris Angelico writes:
> >Okay, Johannes, NOW you're proving that you don't have a clue what
> >you're talking about. D-K effect doesn't go away...
> >
> >ChrisA
>
> You need to read the pa
In a message of Mon, 29 Jun 2015 02:14:43 +0100, Mark Lawrence writes:
>Purely as an exercise I've been converting Grant Jenks' pypatt[1] from
>2.7 to 3.4. I've managed to sort out most of the required changes by
>checking on what I can see with an AST pretty printer[2]. So it's
>rather frustr
28 matches
Mail list logo
