On 7Nov 2006, at 12:20 AM, Greg Ewing wrote:
Also, if we do our own directory caching, the question
is when to invalidate the cache.
I think I'd be happy with having to do that explicitly.
I expect the vast majority of Python programs don't
need to track changes to the set of importable
On Tuesday 07 November 2006 19:00, Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
Sounds fine to me! Less magic under the hood is less magic, and that's always
a good thing. The use case for it seems completely
You want to disable the obmalloc module when using valgrind, as I have when
using Rational Purify.
obmalloc does some evil stuff to recocnize its memory.
You also want to disable it so that you get verification on a per-block level.
Actually, obmalloc could be improved in this aspect. Similar
Neal Norwitz schrieb:
at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
Note that the free is inside qsort. The memory freed under qsort
should definitely not be the bases which we allocated under
PyType_Ready. I'll file a bug report with valgrind to help determine
if this is a problem
On Tue, 7 Nov 2006, Tim Peters wrote:
When PyObject_Free is handed an address it doesn't control, the arena
base address it derives from that address may point at anything the
system malloc controls, including uninitialized memory, memory the
system malloc has allocated to something, memory
okay, everything's fixed.
i updated the patch and added a small test to:
Lib/test/test_builtins.py::test_dir
-tomer
On 11/7/06, Nick Coghlan [EMAIL PROTECTED] wrote:
tomer filiba wrote:
cool. first time i build the entire interpreter, 'twas fun :)
currently i retained support for
as well as updating the documentation in various
places (the dir and PyObject_Dir documentation, obviously, but also the list
of magic methods in the language reference).
oops, i meant everything except that
-tomer
On 11/7/06, tomer filiba [EMAIL PROTECTED] wrote:
okay, everything's fixed.
Hi,
I'm having problems with updating the sandbox.
ilithien:~/Python/sandbox-trunk ronald$ svn cleanup
ilithien:~/Python/sandbox-trunk ronald$ svn up
Aimport_in_py/mock_importer.py
Uimport_in_py/test_importer.py
Uimport_in_py/importer.py
svn: Failed to add file
Herman Geza schrieb:
So figure out which line of code valgrind is complaining about
(doesn't valgrind usually produce that?). If it's coming from the
expansion of Py_ADDRESS_IN_RANGE, it's not worth more thought.
Hmm. I don't think that way. What if free() does other things?
It can't, as
Ronald Oussoren schrieb:
This is on a 10.4.8 box with a recent version of subversion. It turns
out this is caused by a testcase file: decimal-c/new_dt contains both
remainderNear.decTest and remaindernear.decTest (the filenames differ by
case only). It this intentional?
I don't think so. The
For example
if free(addr) sees that the memory block at addr is the last block then it
may call brk with a decreased end_data_segment.
It can't. In brk, you can only manage memory in chunks of one page
(i.e. 4kiB on x86). Since we only access memory on the same page,
access is
Herman Geza schrieb:
It can't. In brk, you can only manage memory in chunks of one page
(i.e. 4kiB on x86). Since we only access memory on the same page,
access is guaranteed to succeed.
Yes, I'm aware of it. But logically, it is possible, isn't it?
No, it isn't.
At malloc(), libc
Thanks Martin, now everything is clear. Python always reads from the page
where the about-to-be-freed block is located (that was the information
that I missed) - as such, never causes a SIGSEGV.
Geza Herman
___
Python-Dev mailing list
[Kristján V. Jónsson]
...
Actually, obmalloc could be improved in this aspect. Similar code that I
once wrote
computed the block base address, but than looked in its tables to see if it
was
actually a known block before accessing it.
Several such schemes were tried (based on, e.g.,
[Martin v. Löwis]
Thanks for explaining all this! One counterpoint:
Notice that on a system with limited memory, you probably don't
want to use obmalloc, even if it worked. obmalloc uses arenas
of 256kiB, which might be expensive on the target system.
OTOH, Python allocates a lot of small
One of the Pybots buildslaves running x86 Ubuntu Edgy has been failing
the unit test step for the trunk, specifically the test_ucn test.
Here's the error:
test_ucn
test test_ucn failed -- Traceback (most recent call last):
File /home/pybot/pybot/trunk.bear-x86/build/Lib/test/test_ucn.py,
line
Armin Rigo wrote:
It would seem good practice to remove all .pycs
after checking out a new version of the source,
just in case there are other problems such as
mismatched timestamps, which can cause the same
trouble.
My two
cents is that it would be saner to have two separate concepts: cache
Delaney, Timothy (Tim) wrote:
Would it be reasonable to always do a stat() on the directory,
reloading if there's been a change? Would this be reliable across
platforms?
To detect a new shadowing you'd have to stat all the
directories along sys.path, not just the one you think
the file is
On Mon, 6 Nov 2006, Armin Rigo wrote:
I know it's a discussion that comes up and dies out regularly. My two
cents is that it would be saner to have two separate concepts: cache
files used internally by the interpreter for speed reasons only, and
bytecode files that can be shipped and
Martin v. Löwis wrote:
Currently, you can put a file on disk and import it
immediately; that will stop working.
One thing I should add is that if you try to import
a module that wasn't there before, the interpreter will
notice this and has the opportunity to update its idea
of what's on the
Patch / Bug Summary
___
Patches : 430 open ( -4) / 3447 closed (+17) / 3877 total (+13)
Bugs: 922 open ( -7) / 6316 closed (+31) / 7238 total (+24)
RFE : 245 open ( +0) / 241 closed ( +1) / 486 total ( +1)
New / Reopened Patches
__
Greg Ewing schrieb:
One thing I should add is that if you try to import
a module that wasn't there before, the interpreter will
notice this and has the opportunity to update its idea
of what's on the disk.
How will it notice that it wasn't there before? The
interpreter will see that it hasn't
Grig Gheorghiu schrieb:
One of the Pybots buildslaves running x86 Ubuntu Edgy has been failing
the unit test step for the trunk, specifically the test_ucn test.
Something is wrong with the machine. I forced a clean rebuild, and
now it crashes in test_doctest2:
On 11/7/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Neal Norwitz schrieb:
at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
Note that the free is inside qsort. The memory freed under qsort
should definitely not be the bases which we allocated under
PyType_Ready. I'll file a bug
24 matches
Mail list logo
