New submission from Nir <[EMAIL PROTECTED]>:
Interpreter error results in erroneous exception when running a script
under debugger control.
Full repro description:
On Windows System, try to run idle.py under the inspection of pdb.py.
Note that you must set a breakpoint somewhere otherwi
Nir added the comment:
First patch, please forgive long comment :)
I submit a small patch which speeds up readline() on my data set - a
74MB (5MB .gz) log file with 600K lines.
The speedup is 350%.
Source of slowness is that (~20KB) extrabuf is allocated/deallocated in
read() and _unread
New submission from Nir Soffer:
In http://docs.python.org/lib/about.html, the link to "Python Bug Tracker"
point to the old close tracker in sourceforge.net. Should be replaced to
bugs.python.org.
--
components: Documentation
messages: 55253
nosy: nirs
severity: normal
st
New submission from Nir Soffer:
In http://docs.python.org/lib/message-objects.html, getheader doc say:
"Like getrawheader(name), but strip leading and trailing whitespace.
Internal whitespace is not stripped. The optional default argument can
be used to specify a different default
New submission from Nir Soffer:
The css uses font-size of 13px. This is way too small and hard to read
specially on high resolution screens used typically on laptops.
Font size for body text should be 100%. A user can select the preferred
font size using the browser.
Python 2.x documentation
Nir Soffer added the comment:
The body font size is good now, but now lot of elements are too big.
Here are list of issues in typical pages related to the font change:
Module page: (e.g. http://docs.python.org/dev/library/bisect.html)
- content headings
- the bread-crumbs navigation flow to
New submission from Nir Soffer:
http://docs.python.org/dev/search.html
In Safari:
- does not find anything. e.g. search for print.
- The sections selection do not remember the user selection. e.g. select
Language Reference, search, the page comes out with Language Reference
deselected.
- The
New submission from Nir Soffer:
>>> b'foo bar'.split()
Traceback (most recent call last):
File "", line 1, in
TypeError: split() takes at least 1 argument (0 given)
>>> b'foo bar'.split(None)
Traceback (most recent call last):
File "
Nir Soffer added the comment:
typo in the title
--
title: split(None, maxplit) does not strip whitespace correctly -> split(None,
maxsplit) does not strip whitespace correctly
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
New submission from Nir Soffer:
string object .split doc say (http://docs.python.org/lib/string-
methods.html):
"If sep is not specified or is None, a different splitting algorithm
is applied. First, whitespace characters (spaces, tabs, newlines,
returns, and formfeeds) are stripped
Nir Soffer added the comment:
set type
--
type: -> behavior
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1123>
__
___
Python-bugs-list mailing li
New submission from Nir Soffer:
The docs (http://docs.python.org/dev/3.0/library/stdtypes.html#sequence-
types-str-bytes-list-tuple-buffer-range) warn that .fileno and .istty
should not be implemented by a file like object.
This require client to check if the file object has the attribute
Nir Soffer added the comment:
Why bytes should not use a default whitespace split behavior as str?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1125>
__
___
Nir Soffer added the comment:
Addionally, if the default value is empty string, you expect it work with
empty string. If a non empty value is needed, it would use None as the
default.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Nir Soffer added the comment:
set type
--
type: -> rfe
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1125>
__
___
Python-bugs-list mailing list
Uns
Nir Soffer added the comment:
I did not look into the source, but obviously there is striping of
leading and trailing whitespace.
When you specify a separator you get:
>>> ' '.split(' ')
['', '', '']
>>> ' a b
Nir Soffer added the comment:
There is a problem only when maxsplit is smaller than the available
splits. In other cases, the docs and the behavior match.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Nir Soffer added the comment:
I quoted str.split docs:
- http://docs.python.org/lib/string-methods.html
- http://docs.python.org/dev/library/stdtypes.html
- http://docs.python.org/dev/3.0/library/stdtypes.html
string.split doc does it explain this:
>>> ' a b '.spli
Changes by Nir Aides :
--
assignee: niemeyer -> nirai
___
Python tracker
<http://bugs.python.org/issue1625>
___
___
Python-bugs-list mailing list
Unsubscri
Nir Aides added the comment:
Hi, I attach a patch to Python 3.3 Lib/bz2.py with updated tests:
cpython-bz2-streams.patch
--
keywords: +needs review
stage: needs patch -> patch review
Added file: http://bugs.python.org/file22087/cpython-bz2-streams.pa
Nir Aides added the comment:
Wait, the tests seem wrong. I'll post an update later today.
--
___
Python tracker
<http://bugs.python.org/issue1625>
___
___
Nir Aides added the comment:
False alarm; go ahead with the review. I took a look too early in the morning
before caffeine kicked in.
Note Lib/test/test_bz2.py was directly upgraded from bz2ms.patch.
A note on bz2 behavior: A BZ2Decompressor object is only good for one stream;
after that
Nir Aides added the comment:
Right! I updated the patch and added a test for the aligned stream/buffer case.
--
Added file: http://bugs.python.org/file22114/cpython-bz2-streams.patch
___
Python tracker
<http://bugs.python.org/issue1
Changes by Nir Aides :
Removed file: http://bugs.python.org/file22087/cpython-bz2-streams.patch
___
Python tracker
<http://bugs.python.org/issue1625>
___
___
Python-bug
Nir Aides added the comment:
Well, I ping my view that we should:
1) Add general atfork() mechanism.
2) Dive into the std lib and add handlers one by one, that depending on case,
either do the lock/init thing or just init the state of the library to some
valid state in the child.
Once this
Nir Aides added the comment:
> I believe that the comp.programming.threads post from
> David Butenhof linked above explains why adding atfork()
> handlers isn't going to solve this.
In Python atfork() handlers will never run from signal handlers, and if I
understood corr
Nir Aides added the comment:
> - what would be the API of this atfork() mechanism (with an example of how it
> would be used in the library)?
The atfork API is defined in POSIX and Gregory P. Smith proposed a Python one
above that we can look into.
http://pubs.opengroup.org/onli
Nir Aides added the comment:
> Sorry, I fail to see how the "import graph" is related to the correct
> lock acquisition order. Some locks are created dynamically, for
> example.
Import dependency is a reasonable heuristic to look into for inter-module
locking order
Nir Aides added the comment:
> Would you like to work on a patch to add an atfork mechanism?
I will start with an attempt to generate a summary "report" on this rabbit hole
of a problem, the views and suggestions raised by people here and what we may
expect from atfork
Changes by Nir Aides :
--
title: threading module can deadlock after fork -> malloc
___
Python tracker
<http://bugs.python.org/issue874900>
___
___
Python-
Changes by Nir Aides :
--
title: malloc -> threading module can deadlock after fork
___
Python tracker
<http://bugs.python.org/issue874900>
___
___
Python-
Nir Aides added the comment:
Well, my brain did not deadlock, but after spinning on the problem for a while
longer, it now thinks Tomaž Šolc and Steffen are right.
We should try to fix the multiprocessing module so it does not deadlock
single-thread programs and deprecate fork in multi
Nir Aides added the comment:
Here is a morning reasoning exercise - please help find the flaws or refine it:
5) Sanitizing worker threads in the multiprocessing module
Sanitizing a worker thread in the context of this problem is to make sure it
can not create a state that may deadlock
Nir Soffer added the comment:
The idea is good, but seems that error handling should be inlined into
initiate_send.
Also those 3 special exceptions should be defined once in the module instead of
repeating them.
--
nosy: +nirs
___
Python tracker
Nir Aides added the comment:
> then multiprocessing is completely brain-damaged and has been
> implemented by a moron.
Please do not use this kind of language.
Being disrespectful to other people hurts the discussion.
--
___
Python tracker
Nir Aides added the comment:
> (BTW: there are religions without "god", so whom shall e.g. i praise for the
> GIL?)
Guido? ;)
--
___
Python tracker
<http://bugs.p
Nir Aides added the comment:
Hi Gregory,
> Gregory P. Smith added the comment:
> No Python thread is ever fork safe because the Python interpreter itself can
> never be made fork safe.
> Nor should anyone try to make the interpreter itself safe. It is too complex
>
Nir Aides added the comment:
For the record, turns out there was a bit of misunderstanding.
I used the term deprecate above to mean "warn users (through documentation)
that they should not use (a feature)" and not in its Python-dev sense of
"remove (a feature) after a period
Nir Aides added the comment:
I think patch may be simplified. Instead of keeping track of CRC offset, invoke
it directly on the 'data' variable being added to _readbuffer.
Also the call to _update_crc() before the return from read1() looks redundant.
Finally, is it possible to det
Nir Aides added the comment:
But you answered my question with code :) self._file_size is now unused and may
be removed.
--
___
Python tracker
<http://bugs.python.org/issue7
Nir Aides added the comment:
Hi Antoine,
BufferedIOBase is not documented to have peek():
http://docs.python.org/dev/py3k/library/io.html
Small note about patch:
1) IOError string says "read() on write-only...", should be "peek() on
write-only..." ?
2) Should be min
Nir Aides added the comment:
Should be min(n, 1024) instead of max(...)
--
___
Python tracker
<http://bugs.python.org/issue9962>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
Right, I missed the change from self.max_read_chunk to 1024 (read_size). Should
not peek() limit to self.max_read_chunk as read() does?
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue10037>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue1625>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue9504>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue11743>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue9971>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue6721>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Nir Aides added the comment:
Hi,
There seem to be two alternatives for atfork handlers:
1) acquire locks during prepare phase and unlock them in parent and child after
fork.
2) reset library to some consistent state in child after fork.
http://pubs.opengroup.org/onlinepubs/009695399
Nir Aides added the comment:
I think that generally it is better to deadlock than corrupt data.
> 2) acquiring locks just before fork is probably one of the best way to
> deadlock (acquiring a lock we already hold, or acquiring a lock needed
> by another thread before it releases its
Nir Aides added the comment:
Is it possible the following issue is related to this one?
http://bugs.python.org/issue10037 - "multiprocessing.pool processes started by
worker handler stops working"
--
___
Python tracker
<http://bu
Nir Aides added the comment:
Steffen, can you explain in layman's terms?
On Sun, May 15, 2011 at 8:03 PM, Steffen Daode Nurpmeso
wrote:
>
> @ Charles-François Natali wrote (2011-05-15 01:14+0200):
>> So if we really wanted to be safe, the only solution would be to
>> f
Nir Aides added the comment:
> I do not find the existing phrasing in the IO docs ambiguous, but since
> it is obviously possible to misinterpret it it would be good to clarify
> it. Can you suggest an alternate phrasing that would be clearer?
Replace 'may' with 'wil
Nir Aides added the comment:
Uploaded an updated patch with read() which calls underlying stream enough
times to satisfy required read size.
--
Added file: http://bugs.python.org/file15941/zipfile_7610_py27_v5.diff
___
Python tracker
<h
Nir Aides added the comment:
Right, removed MAX_N from read(); remains in read1().
If good, what versions of Python is this patch desired for?
--
Added file: http://bugs.python.org/file15949/zipfile_7610_py27_v6.diff
___
Python tracker
<h
Changes by Nir Soffer :
--
nosy: +nirs
___
Python tracker
<http://bugs.python.org/issue1068268>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nir Aides added the comment:
The related scenario is a system without zlib. How do you suggest simulating
this in test?
--
___
Python tracker
<http://bugs.python.org/issue7
Nir Aides added the comment:
Unconsumed data is compressed data. If the part which handles unconsumed data
does not work when zlib is available, then the existing tests would fail. In
any case the unconsumed buffer is an implementation detail of zipfile.
I see a point in adding a test to
Nir Aides added the comment:
I actually meant how would you simulate zlib's absence on a system in which it
is present?
--
___
Python tracker
<http://bugs.python.org/i
Changes by Nir Aides :
--
nosy: +nirai
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Nir Aides added the comment:
I tried Florent's modification to the write test and did not see the effect on
my machine with an updated revision of Python32.
I am running Ubuntu Karmic 64 bit.
7s - no background threads.
20s - one background thread.
According to the following document
Nir Aides added the comment:
I updated the patch with a small fix and increased the ticks
countdown-to-release considerably. This seems to help the OS classify CPU bound
threads as such and actually improves IO performance.
--
Added file: http://bugs.python.org/file16570/linux-7946
Nir Aides added the comment:
I upload bfs.patch
To apply the patch use the following commands on updated python 3.2:
$ patch -fp1 < bfs.patch
$ ./configure
The patch replaces the GIL with a scheduler. The scheduler is a simplified
implementation of the recent kernel Brain F**k Scheduler
Nir Aides added the comment:
I upload an updated bfs.patch. Apply to updated py32 and ignore the error with:
$ patch -fp1 < bfs.patch
$ ./configure
> Please give understandable benchmark numbers, including an explicit
> comparison with baseline 3.2, and patched 3.2 (e.g. gilin
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16634/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16567/linux-7946.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
Nir Aides added the comment:
> Ouch. CLOCK_THREAD_CPUTIME_ID is not a required part of the standard. Only
> CLOCK_REALTIME is guaranteed to exist.
Right, however the man page at kernel.org says the following on
CLOCK_THREAD_CPUTIME_ID:
"Sufficiently recent versions of glibc an
Nir Aides added the comment:
> It's a dual-core Linux x86-64 system. But, looking at the patch again, the
> reason is obvious:
>
> #define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate
> >tick_counter % 1000 == 0))
>
> `tstate->tick_counter % 10
Nir Aides added the comment:
Well, on initial check the scheduler seems to work well with regular
gettimeofday() wall clock instead of clock_gettime().
:)
/* Return thread running time in seconds (with nsec precision). */
static inline long double get_thread_timestamp(void) {
return
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16644/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
Uploaded an updated bfs.patch
The latency problem was related to the --with-computed-gotos flag. I fixed it
and it seems to work fine now.
I also switched to gettimeofday() so it should work now on all Posix with high
resolution timer.
--
Added file
Nir Aides added the comment:
> But on a busy system, won't measuring wall clock time rather than CPU time
> give bogus results?
This was the motivation for using clock_gettime(). I tried the wall clock
version under load (including on single core system) and it seems to beha
Nir Aides added the comment:
gilinter.patch has good IO latency in UDP test on my system when built with
--with-computed-gotos:
In [34]: %timeit -n3 client.work()
0.320 seconds (32782026.509 bytes/sec)
0.343 seconds (30561727.443 bytes/sec)
0.496 seconds (21154075.417 bytes/sec)
0.326 seconds
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16663/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
I update bfs.patch. It now builds on Windows (and Posix).
--
Added file: http://bugs.python.org/file16679/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16679/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Changes by Nir Aides :
Added file: http://bugs.python.org/file16680/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16680/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
I upload a new update to bfs.patch which improves scheduling and reduces
overhead.
--
Added file: http://bugs.python.org/file16710/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16710/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
Uploaded an update.
--
Added file: http://bugs.python.org/file16830/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16830/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
I uploaded an update to bfs.patch which improves behavior in particular on
non-Linux multi-core (4+) machines.
Hi Charles-Francois, Thanks for taking the time to review this patch!
> - nothing guarantees that you'll get a msec resolution
Right, the cod
Nir Aides added the comment:
> the scheduling function bfs_find_task returns the first task that
> has an expired deadline. since an expired deadline probably means
> that the scheduler hasn't run for a while, it might be worth it to
> look for the thread with the oldest d
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16947/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Changes by Nir Aides :
Added file: http://bugs.python.org/file16967/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
Yet another update to bfs.patch.
I upload a variation on Florent's write test which prints progress of
background CPU bound threads as: thread-name timestamp progress
Here are some numbers from Windows XP 32bit with Intel q9400 (4 cores). Builds
produced wi
Nir Aides added the comment:
Dave, there seems to be a bug in your patch on Windows XP. It crashes in
ccbench.py with the following output:
>python_d.exe y:\ccbench.py
== CPython 3.2a0.0 (py3k) ==
== x86 Windows on 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' ==
--- Throu
Nir Aides added the comment:
On Tue, Apr 27, 2010 at 12:23 PM, Charles-Francois Natali wrote:
> @nirai
> I have some more remarks on your patch:
> - /* Diff timestamp capping results to protect against clock differences
> * between cores. */
> _LOCAL(long double) _bfs_diff_ts(
Nir Aides added the comment:
On Wed, Apr 28, 2010 at 12:41 AM, Larry Hastings wrote:
> The simple solution: give up QPC and use timeGetTime() with
> timeBeginPeriod(1), which is totally
> reliable but only has millisecond accuracy at best.
It is preferable to use a high precision
Nir Aides added the comment:
Dave, there seems to be some problem with your patch on Windows:
F:\dev>z:\dabeaz-wcg\PCbuild\python.exe y:\ccbench.py -b
== CPython 3.2a0.0 (py3k) ==
== x86 Windows on 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' ==
--- I/O bandwidth ---
Backgr
Nir Aides added the comment:
On Thu, Apr 29, 2010 at 2:03 AM, David Beazley wrote:
> Wow, that is a *really* intriguing performance result with radically
> different behavior than Unix. Do you have any ideas of what might be causing
> it?
Instrument the code and I'll se
Nir Aides added the comment:
Dave,
The behavior of your patch on Windows XP/2003 (and earlier) might be related to
the way Windows boosts thread priority when it is signaled.
Try to increase priority of monitor thread and slice size. Another thing to
look at is how to prevent Python CPU
Changes by Nir Aides :
Added file: http://bugs.python.org/file17194/nir-ccbench-xp32.log
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list m
Changes by Nir Aides :
Removed file: http://bugs.python.org/file16967/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
I updated bfs.patch with improvements on Windows XP.
The update disables priority boosts associated with the scheduler condition on
Windows for CPU bound threads.
Here is a link to ccbench results:
http://bugs.python.org/file17194/nir-ccbench-xp32.log
Summary
Changes by Nir Aides :
Removed file: http://bugs.python.org/file17195/bfs.patch
___
Python tracker
<http://bugs.python.org/issue7946>
___
___
Python-bugs-list mailin
Nir Aides added the comment:
Duck, here comes another update to bfs.patch.
This one with some cleanups which simplify the code and improve behavior (on
Windows XP), shutdown code, comments, and "experimental" use of TSC for
timestamps, which eliminates timestamp reading overhead.
Nir Soffer added the comment:
Updating python version, this is not relevant to 3.6 now.
On linux users can use "sync --file-system /path" but it would be nice if we
have something that works on multiple platforms.
--
nosy: +nirs
versions: +Python 3.11 -
1 - 100 of 228 matches
Mail list logo
