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
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
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
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
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
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
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 fi
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
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
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
> > 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
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
Python-Dev@python
[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 impor
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
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
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
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
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
25 matches
Mail list logo
