Mark Florisson added the comment:
> Ok. This would only be done in buffered mode, though, so your fwrite.py
> example would have to be changed slightly (drop the ",0" in fdopen()).
Indeed, good catch. So apparently file.write (in buffered mode) is also
"i
Mark Florisson added the comment:
I think this sums it up:
file.write, on EINTR, could decide to continue writing if no Python signal
handler raised an exception.
Analogously, file.read could decide to keep on reading on EINTR if no Python
signal handler raised an exception
Mark Florisson added the comment:
Here is fread.py (why can you only attach one file at a time? :P)
--
Added file: http://bugs.python.org/file20463/fread.py
___
Python tracker
<http://bugs.python.org/issue10
New submission from Mark Florisson :
In both Python versions EINTR is not handled properly in the file.write and
file.read methods.
- file.write -
In Python 2, file.write can write a short amount of
bytes, and when it is interrupted there is no
Changes by Mark Florisson :
Removed file: http://bugs.python.org/file19857/libpython_patch.diff
___
Python tracker
<http://bugs.python.org/issue10566>
___
___
Python-bug
Mark Florisson added the comment:
I forgot to remove a tempfile and reverted the Cython note at the top. A diff
is provided (that should be applied upon the previously submitted patch). It's
a diff because I don't have commit rights and svn does not support local
commits.
--
Mark Florisson added the comment:
Ok I attached a new patch that solves the things you mentioned. It can debug
Python inferiors with versions 2.6+. Execution control commands (py-{run, cont,
finish, step, next}) and py-exec need gdb 7.2+, py-break works with 7.1+.
It now also "sup
Mark Florisson added the comment:
Indeed, I'm trying to make the code Python 2 and Python 3 (for the inferior)
compatible, it's not really hard but indeed, the 'u' (Python 2) and 'b' (Python
3) stuff need special casing. Python 2 compatibility was also the reason
Mark Florisson added the comment:
I forgot to mention, this patch works with gdb 7.2 or higher, but it does not
prevent using other libpython functionality with gdb 7.1 or running the tests
with gdb 7.1.
--
___
Python tracker
<h
New submission from Mark Florisson :
Attached is a patch that adds a few features to the Python debugging support
for gdb:
- listing of globals
- python breakpoints
- python stepping/stepping over/finishing of frames/running/continuing
- python code execution in the most recent Python frame
New submission from Mark Florisson :
>>> list(*('boo' for x in [1]))
['b', 'o', 'o']
>>> list(*(range('error') for x in [1])) # notice the erroneous error
message
Traceback (most recent call last):
File "", line 1,
New submission from Mark Florisson :
As you can see, when a local trace function sets f_lineno, f_lineno
doesn't get updated on subsequent lines. Otherwise it works fine.
$ python tracer_testca
New submission from Mark Florisson :
>>> f = open('foo', 'wt+', encoding='UTF-16')
>>> f.write('spam ham eggs')
13
>>> f.seek(0)
0
>>> f.read()
'spam ham eggs'
>>> f.seek(0)
0
>>> f.read()
&#
New submission from Mark Florisson :
As signals are only delivered to the main thread, what should happen
when the main thread dies? Currently, the signal mask is not unset in
any other thread, so when the main thread dies, all signals set in the
mask are simply ignored. Perhaps an other thread
New submission from Mark Florisson :
>>> '{0[0](10)}'.format([None])
Traceback (most recent call last):
File "", line 1, in
SystemError: error return without exception set
--
components: Interpreter Core
messages: 88198
nosy: eggy
severity: normal
s
New submission from Mark Florisson :
The load method, which is also called from the initializer if input is
provided, doesn't create Morsel objects for things other than strs,
because it calls self.update(rawdata), which does not invoke the custom
__setitem__.
The documentation states that
New submission from Mark Florisson :
sys.exit() exits the program when non-daemonic threads are still
running, in versions >= 2.5.
Test included. A demonstration here: http://paste.pocoo.org/show/95766/
(On debian GNU/Linux)
--
components: None
files: foo.py
messages: 77978
nosy: e
Mark Florisson <[EMAIL PROTECTED]> added the comment:
Perhaps it's linux specific then. I'm on debian lenny (2.6.26-1-amd64).
___
Python tracker <[EMAIL PROTECTED]>
<http://
Mark Florisson <[EMAIL PROTECTED]> added the comment:
s/actual/operation/
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4579>
___
__
Mark Florisson <[EMAIL PROTECTED]> added the comment:
Actually, I wouldn't expect it to fail like that, because it's not a bad
file descriptor, it's an actual that doesn't agree with the (userspace)
file mode. What I'd expect is probably a TypeError. Although an IO
New submission from Mark Florisson <[EMAIL PROTECTED]>:
>>> f = os.fdopen(os.open('spam!', os.O_TRUNC|os.O_CREAT|os.O_RDWR), 'w')
>>> f.read()
''
>>> f.readline()
Traceback (most recent call last):
File "", lin
New submission from Mark Florisson <[EMAIL PROTECTED]>:
The docstring of os.setpgrp says 'Make this process a session leader.',
but that's not what setpgrp does. setpgrp() is the same as setpgid(0,
0), which sets the pgid of the calling process to the pid of the calling
proc
22 matches
Mail list logo
