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
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:
http://www.python.org/dev/buildb
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 has
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
__
modulefin
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 d
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 impor
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
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
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
[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
[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.,
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
Python-Dev@python
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
> > 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,
> acces
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. T
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
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 'decimal-c/new_dt/roun
> 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 fi
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 _
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, me
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 pr
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 co
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 approp
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 mo
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
On 11/6/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> tomer filiba wrote:
> > cool. first time i build the entire interpreter, 'twas fun :)
> > currently i "retained" support for __members__ and __me
25 matches
Mail list logo
