homepage

@haypo: trouble, trouble on the dev-list, as i've seen currently.
Sorry, sorry. (Cannot subscribe, my DynIP's are often blacklisted ;)
Of course my comments were completely wrong, as Ethan has pointed
out correctly.
This is all s**t. These are mmap(2) related issues and should be
tested in Lib/test/test_mmap.py. However that does not use
 with open:
 create sparse file
 materialize
yet so that the Pear OS X sparsefile bug doesn't show up. In fact
it doesn't do a full beam-me-up test at all yet?
> Is the test useful or not? What do we test?
We do test that mmap.mmap materializes a buffer which can be
accessed (readonly) from [0]..[len-1].
And that the checksums that zlib produces for that buffer are
correct. Unfortunately we cannot test 0x80000000+ no more because
Python prevents that such a buffer can be used - that's a shame.
Maybe we could test 0x7FFFFFFF*2 aka 0xfffffffe in two iterations.
> Can you check if the test crashs on Mac OS X on a 32 bits system
> (1 GB buffer) if you disable F_FULLFSYNC in mmapmodule.c? Same
> question on a 64 bits system (2 GB-1 byte buffer)?
Aeh - F_FULLFSYNC was not yet committed at that time in 2.7.
> Can we just remove the test?
If i - choke! - need to write tests, i try to catch corner cases.
The corner cases would be 0,MAX_LEN(-1) and some (rather pseudo)
random values around these and maybe some in the middle.
(Plus some invalid inputs.)
Can we remove it? I would keep it, Apple is preparing the next
major release (uname -a yet states 10.7.0 even though it's
10.6.7), and maybe then mmap() will fail for 0xDEADBEEF.
Who will be the one which detects that otherwise??