Steffen Daode Nurpmeso added the comment:
@ Nir Aides wrote (2011-05-16 20:57+0200):
> Steffen, can you explain in layman's terms?
I am the layman here.
Charles-François has written a patch for Python which contradicted
his own proposal from msg135079, but he seems to have tested a lot
Steffen Daode Nurpmeso added the comment:
Thank you, thank you, thank you.
I'm a bit irritated that a french man treats a "wet-her" as a typo!
What if *i* like it?? In fact it is a fantastic physical backing
store. Unbeatable.
Well and about dropping the fsync() in case th
Steffen Daode Nurpmeso added the comment:
I've dropped wet-her!
I hope now you're satisfied!
So the buffer cache is all which remains hot.
How deserted!
> And you could also add a test (I guess that just calling fsync
> with full_sync=True on a valid FD would be enough.
I
Changes by Steffen Daode Nurpmeso :
Removed file: http://bugs.python.org/file21986/11877.8.diff
___
Python tracker
<http://bugs.python.org/issue11877>
___
___
Python-bug
Steffen Daode Nurpmeso added the comment:
Excusing myself seems to be the only "probates Mittel".
@Antoine Pitrou: It was a real shame to read your mail.
(It's sometimes so loud that "i don't even hear what i write".)
--
___
Steffen Daode Nurpmeso added the comment:
@ rion wrote (2011-05-18 12:39+0200):
> just document it or fix.
Hello, zion, Victor, i'm proposing a documentation patch.
It applies to 2.7 and 3.3 (from yesterday).
--
keywords: +patch
Added file: http://bugs.python.org/file22020
Steffen Daode Nurpmeso added the comment:
@ STINNER Victor wrote (2011-05-18 14:33+0200):
> I don't think that Python should guess what the user expects
> (i.e. Python should not sync the file *implicitly*).
Before i've found F_FULLFSYNC i indeed have had a solution which
track
Steffen Daode Nurpmeso added the comment:
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -810,6 +810,35 @@
Availability: Unix, and Windows.
+.. function:: fullfsync(fd)
+
+ The POSIX standart requires that :c:func:`fsync` must
Steffen Daode Nurpmeso added the comment:
(This was an attachment to an empty mail message.)
--
Added file: http://bugs.python.org/file22046/11877-standalone.1.diff
___
Python tracker
<http://bugs.python.org/issue11
Steffen Daode Nurpmeso added the comment:
Looked at it again and i think it's much better english with an
additional ..to ensure "that" local...
@Ross, aren't you a native english speaker? What do you say?
--
Added file: http://bugs.python.org/fi
New submission from Steffen Daode Nurpmeso :
I'm using the en_GB.UTF-8 locale and thus the entire I/O layer defaults to use
UTF-8 encoding. Perfect.
The problem is that mailboxes are *not* and *never* in UTF-8, generally
speaking, according to RFC mail standards!
So i suggest that mailb
Steffen Daode Nurpmeso added the comment:
Re-New to Python - Re-Started with Py3K in 2011.
'Found myself in a dead-end after 10 days of work because a KOI8-R spam mail
causes the file I/O decoding process to fail -
and there is NO WAY TO HANDLE THIS with mailbox.py!
(Went to pytho
Steffen Daode Nurpmeso added the comment:
This message will not help anyone.
And it's not a chat, but because it seems i really made the horses gone
grazy (direct translation of a german proverb):
- msg127002: RDM, i didn't know all of that and i am really sorry.
Now I am looking
New submission from Steffen Daode Nurpmeso :
This bug may be based on same problem as Issue 6203.
- My system locale is en_GB.UTF-8.
- Given a latin1 text file, open()+ will fail with
'UnicodeDecodeError: 'utf8' codec can't decode byte 0xf6...'
- Using locale.setl
Changes by Steffen Daode Nurpmeso :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue11022>
___
___
Python-bugs-list mailing list
Unsubscri
Steffen Daode Nurpmeso added the comment:
> Anyway, I don't know understand why do you change your locale,
> because you know that your file encoding is Latin1. Why don't you
> use directly: open(filename, encoding='latin1')?
Fortunately Issue 9124 is being solve
Steffen Daode Nurpmeso added the comment:
After cloning branches/py3k (i now have three different detached repo snakes in
my arena (2.7,3.1,py3k), by the way - not bad for a greenhorn, huh?).
I've applied RDMs patch from msg127245.
Note: the test mails are *malformed*!
Stuff in brackets a
New submission from Steffen Daode Nurpmeso :
I always hated GNU Autoconf and M4.
After cloning branches/py3k today i needed two and a half hour to build and
compile a Python which includes the readline module.
I'll attach a primitive setup.py patch which should better not make it i
Steffen Daode Nurpmeso added the comment:
Indeed i tried to create tracebacks (even with "import traceback"), but these
all end up in my code (and all the time). I have not yet figured out how to
create tracebacks which leave my code and reach the source, which surely must
be so
Steffen Daode Nurpmeso added the comment:
Ok, thanks. Mac/README is not for me, though, i'm only a simple Ex-FreeBSD
user which buyed good hardware with the wrong operating system. All these
mysterious frameworks and AvailabilityMacros.h really make you weird ;-)
There are i
Steffen Daode Nurpmeso added the comment:
You're indeed right, i've overseen a try..catch!
I'll even be able to give you some fast code hints now
(and i'll be offline the next few hours - the mails are simply mails with
illegal charsets, say):
Traceback (most recent call l
Steffen Daode Nurpmeso added the comment:
Thank you, RO, exactly that very line would be great as an add-on for the
mentioned file - and (better: but - i'm lazy) it would be even better if that
hint would appear somewhere in 'configure --help'! That would make the apple
Steffen Daode Nurpmeso added the comment:
> What is the data type returned by your get_msg? I bet it is string,
> and email can't handle messages in string format that have non-ASCII
> characters
(Now i see that the local names 'box', 'mbox' and 'm
Steffen Daode Nurpmeso added the comment:
I missed your mailbox3.patch, but now i've merged it in.
One error changed, it now happens when a re.search is applied to a header value
and thus seems to match what you say. I'm not able to understand this error
this evening, but i will
Steffen Daode Nurpmeso added the comment:
RDM: it seems i was too tired to get your messages right last evening!
Indeed it's now completely my fault, i should inspect the content further in
respect to the str/bytes etc. stuff! Thus - i will now need three or four days
to cleanup my
Steffen Daode Nurpmeso added the comment:
Let me summarize this thread:
- For darwin/MacOS X there exists an undocumented MACOSX_DEPLOYMENT_TARGET
switch, which makes its way all through the build-system and the 'sysconfig'
module. Even though 'configure' auto-detects
Changes by Steffen Daode Nurpmeso :
Removed file: http://bugs.python.org/file20575/DIFF
___
Python tracker
<http://bugs.python.org/issue11046>
___
___
Python-bugs-list m
Changes by Steffen Daode Nurpmeso :
Removed file: http://bugs.python.org/file20582/DIFF
___
Python tracker
<http://bugs.python.org/issue11046>
___
___
Python-bugs-list m
New submission from Steffen Daode Nurpmeso :
... because i don't know where to place this message, i do place it here.
Whatever has happened in the last 90 minutes, cloning from code.python.org/hg
results in mercurial panics!
Please see http://mercurial.selenic.com/bts/issue2239 for mo
Steffen Daode Nurpmeso added the comment:
MAN!! Forget it - it's ok again; it's maybe really a mercurial non-atomicity
failure.
--
___
Python tracker
<http://bugs.python.o
Changes by Steffen Daode Nurpmeso :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11059>
___
___
Python-bugs-list mailing list
Un
Steffen Daode Nurpmeso added the comment:
Nope. In the meanwhile i've accomplished to clone py3k once again, but
branches/release2.7-maint fails over and over again. I've added another
message to http://mercurial.selenic.com/bts/issue2239.
Have a ni
Steffen Daode Nurpmeso added the comment:
Also in respect to Issue 6203 i could talk about a project which did not link
against anything in the end, only ld(1) and syscalls and the undocumented third
'char **envp' arg to UNIX main()s.
Thus: all of you should be *very* happy about th
Steffen Daode Nurpmeso added the comment:
User lemburg pointed me to this, but no, i've posted msg127416 to Issue 11022.
--
nosy: +sdaoden
___
Python tracker
<http://bugs.python.org/i
Steffen Daode Nurpmeso added the comment:
'Had to look on a sunday once again, and it is still impossible to clone
branches/release2.7-maint.
In the meanwhile the Mercurial people from <http://mercurial.selenic.com>
reacted - they play the ball back to python.org.
*However*: ther
Steffen Daode Nurpmeso added the comment:
<http://mercurial.selenic.com/bts/issue2595> says "code.python.org/hg often
seems unstable.", so it seems to be a well known thing. I leave this issue now
open nevertheless, and let some experienced Python.org user decide wha
Steffen Daode Nurpmeso added the comment:
Most of this is much too loud for a newbie who is about to read PEP 7 anyway.
And if this community has chosen to try (?!?) not to break compatibility with
code which does not have a notion of a locale setting (i.e. naively uses other
code in that
New submission from Steffen Daode Nurpmeso :
Following Issue 9124 discussion: it took longer than i thought, but now i could
rework my thing and got errors. I've also tried Lib/test/test_mailbox.py, and
that produces 0xA errors and 0xA failures. I'll attach the entire tracebacks
Steffen Daode Nurpmeso added the comment:
Oops - please be aware that these outputs were saved at the end of a
frustrating session. I'm doing things to show *you* what's passed around and
the like, i.e. that the message is indeed a mboxMessage etc. The error which
occurs
Steffen Daode Nurpmeso added the comment:
This simplemost patch (email_header.patch) seems to work at first glance. It
heals *everything* (except for babyl format, see issue 11062). (I feel a bit
like Charlie Chaplin and i think you know what i mean.)
--
keywords: +patch
Added file
Changes by Steffen Daode Nurpmeso :
Removed file: http://bugs.python.org/file20673/email_mbox.txt
___
Python tracker
<http://bugs.python.org/issue6>
___
___
Python-bug
Changes by Steffen Daode Nurpmeso :
--
title: mailbox and email errors -> (mailbox and) email (errors) -> patch
___
Python tracker
<http://bugs.python.org/i
Steffen Daode Nurpmeso added the comment:
You're right, the python3 executable is indeed
20:05 ~/tmp $ python3 -V
Python 3.2rc1+
The relevant .py files (mailbox.py, email/*.py, (email/mime/*.py),
test/test_mailbox.py are symlinked to the repo files.
(And, different to this morning -
Steffen Daode Nurpmeso added the comment:
P.S.: it's that messed UNIX with the nice user-experience *G*UI. And the
__pycache__ files state 'cpython-32'.
--
___
Python tracker
<http://bugs.pyt
Steffen Daode Nurpmeso added the comment:
Dear RDM, now i'm really ashamed. To be absolutely sure that i am up-to-date
if diff'd and found that test_mailbox.py contained a sys.exit(1) i've inserted
this - it was the lunch break, really!
Forget everything i've posted
Steffen Daode Nurpmeso added the comment:
I thought about it. It's worse. You did a good job and i was not even able to
create symlinks the way it should have been done. This is a real shame - for
me.
--
___
Python tracker
Steffen Daode Nurpmeso added the comment:
However, as a last peep from me before i'll burn to ashes, and now with all
fresh Python 3.2rc2+ all through, i do want to ask a question.
I'm still not finished with my broken thing, so the usual exception still
occurs in respect to the
Steffen Daode Nurpmeso added the comment:
Well, here is the long-asked-for 'fp_mailbox.py' test thing.
Note: it generates a 'test.mbox' in CWD!
print("USAGE: fp_mailbox.py 0|1|2",
" 0 = use raw UTF-8 string",
"
Steffen Daode Nurpmeso added the comment:
ronaldoussoren: thanks for the MACOSX_DEPLOYMENT_TARGET=10.5 hint!! I did Py3K
yesterday, and it was a matter of 'configure --prefix=x YZ && make && make
install' as if it were a real UNIX!
I *really* think there should b
Steffen Daode Nurpmeso added the comment:
Thanks for spending your free time, almost alone in such a widespread area like
this.
--
___
Python tracker
<http://bugs.python.org/issue11
Steffen Daode Nurpmeso added the comment:
Shay.Rojansky: because of the fact that i needed a free last saturday for just
having the time to click around a bit to find the relevant docs in the
python.org jungle ...
<http://wiki.python.org/moin/Email%20SIG> and *especially*
Steffen Daode Nurpmeso added the comment:
I have not tried 3.2 yet, but Issue 11046 may be of interest for you!
Try the undocumented:
configure ...[other args]... MACOSX_DEPLOYMENT_TARGET=10.5
in the meanwhile - it may help you out.
--
nosy: +ronaldoussoren, sdaoden
Steffen Daode Nurpmeso added the comment:
Ooops. In fact 3.2 did well with that undocumented thing either.
--
___
Python tracker
<http://bugs.python.org/issue11
Steffen Daode Nurpmeso added the comment:
Aeh, your patch does it.
You may be interested of all Mac OS X compilation notes??
/usr/bin/ranlib: file: libpython3.2m.a(dynamic_annotations.o) has no symbols
/usr/bin/ranlib: file: libpython3.2m.a(pymath.o) has no symbols
ranlib libpython3.2m.a
New submission from Steffen Daode Nurpmeso :
Hy David, while hacking a bit on my thing i've found two places where
header.Header needs to be explicitely converted via str().
Have a nice weekend.
--
files: email_message.patch
keywords: patch
messages: 128782
nosy: r.david.m
Steffen Daode Nurpmeso added the comment:
(Will get that tracker right as time goes by.)
--
type: -> behavior
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issu
Steffen Daode Nurpmeso added the comment:
We all know EMail 6.0 will blow them off the streets in the end.
--
components: +Library (Lib)
___
Python tracker
<http://bugs.python.org/issue11
Steffen Daode Nurpmeso added the comment:
P.S.: maybe this completes the byte.
Have a nice weekend nevertheless - if you can.
Traceback (most recent call last):
File "/Users/steffen/usr/bin/s-postman.py", line 1419, in _walk
self._tickets.extend(Ticket.process_m
Steffen Daode Nurpmeso added the comment:
I also got this now, it happens with and without the str() patch stuff. (Note
that message.py line numbers are off by 1-2 lines ..). I don't know more about
that in the moment, but the only thing that's changed is that i do:
a
Steffen Daode Nurpmeso added the comment:
The latter one was my fault, i did LIST.append(name, HEADER.append(xy)),
assuming that HEADER.append() returns self though it doesn't. Sorry. However
- shouldn't Message.__setitem__ check for valid arguments (see msg128846 code
snippet)?
Steffen Daode Nurpmeso added the comment:
However, maybe that 5.1 message.py thing doesn't like header.Header instances.
Also extending msg128846, this one is related to the str() issue - added an
extended email_message.2.patch.
Traceback (most recent call last):
File "/Use
Changes by Steffen Daode Nurpmeso :
Removed file: http://bugs.python.org/file20784/email_message.patch
___
Python tracker
<http://bugs.python.org/issue11243>
___
___
Pytho
Steffen Daode Nurpmeso added the comment:
David, i'm going down now. I'll raise the type to 'crash', because, in fact,
EMail 5.1 doesn't really take care of header.Header objects in message.Message
headers, which doesn't sound pretty useful to me! The patc
Steffen Daode Nurpmeso added the comment:
... as a last though of mine, here is a header of the well known spam mail:
>From MAILER-DAEMON Sat Feb 19 15:58:47 2011
Date: =?latin1?q?Tue=2C_4_Jan_2011_17=3A37=3A26_+0100_=28CET=29?=
From: =?latin1?q?=22SAJATNAPTAR=2ECOM=22_=3Cinfo=40sajatnap
Steffen Daode Nurpmeso added the comment:
(Of course you're right. It just reads, passes around and spits out that ...
of a mail just the same it came in. Performance is very well, too, just about
1.5 seconds - some two weeks ago it took about 1.1 seconds, but with Python 2.7
- so!
Steffen Daode Nurpmeso added the comment:
'Have no glue, but Ned Daily's patch (msg129011) seems to be required for
adler, too. (You know...)
--
nosy: +sdaoden
___
Python tracker
<http://bugs.python.o
Steffen Daode Nurpmeso added the comment:
Wait a few minutes, i'll write this simple patch for adler and crc. But
excessive testing and such is beyond my current capabilities.
--
___
Python tracker
<http://bugs.python.org/is
Steffen Daode Nurpmeso added the comment:
File: issue11277.patch.
Hmm. Two non-register constants and equal code on 32 and 64 bit. Does Python
has a '64 bit' switch or the like - PY_SSIZE_T_MAX is not preprocessor-clean, i
would guess.
--
keywords: +patch
Added
Changes by Steffen Daode Nurpmeso :
Removed file: http://bugs.python.org/file20836/issue11277.patch
___
Python tracker
<http://bugs.python.org/issue11277>
___
___
Pytho
Steffen Daode Nurpmeso added the comment:
Sorry - that was a mess.
--
Added file: http://bugs.python.org/file20837/issue11277.patch
___
Python tracker
<http://bugs.python.org/issue11
Steffen Daode Nurpmeso added the comment:
R. David Murray wrote [2012-03-17 03:51+0100]:
> Thanks for the patch, Steffen.
Warm to the cleanroom-squatters!
(I count this as the promised petit glass of red wine.)
--steffen
Forza Figa!
--
___
Pyt
Steffen Daode Nurpmeso added the comment:
Salut!, amis français! (Und auch sonst so, natürlich.)
POSIX has recently standardized a NSIG_MAX constant in [1]:
The value of {NSIG_MAX} shall be no greater than the number of signals that
the sigset_t type (see [cross-ref to ]) is capable of
301 - 372 of 372 matches
Mail list logo
