[issue31754] Documented type of parameter 'itemsize' to PyBuffer_FillContiguousStrides is incorrect.

2017-10-10 Thread Robert Snoeberger

New submission from Robert Snoeberger <robert.snoeber...@me.com>:

The signature for PyBuffer_FillContiguousStrides in the documentation shows 
that the type of parameter 'itemsize' is Py_ssize_t [1]. This is different from 
the signature in Include/abstract.h which shows that the type as int [2].


[1] https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_FillContiguousStrides
[2] 
https://github.com/python/cpython/blob/49b2734bf12dc1cda80fd73d3ec8896ae3e362f2/Include/abstract.h#L559-L563

--
assignee: docs@python
components: Documentation
messages: 304096
nosy: docs@python, snoeberger
priority: normal
severity: normal
status: open
title: Documented type of parameter 'itemsize' to 
PyBuffer_FillContiguousStrides is incorrect.
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31754>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



Options for stdin and stdout when using pdb debugger

2016-11-24 Thread Robert Snoeberger
I would like to use pdb in an application where it isn't possible to use 
sys.stdin for input. I've read in the documentation for pdb.Pdb that a file 
object can be used instead of sys.stdin. Unfortunately, I'm not clear about my 
options for the file object. 

I've looked at rpdb on PyPI, which re-routes stdin and stdout to a socket 
handler. I can connect to the socket with telnet. This works well. 

I'm just curious if there are other options?

Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Embedding Python into C set up issues

2016-03-14 Thread robert . snoeberger
> 
> However, I am having great trouble getting Py_Initialize() to work in the 
> both CDT and Visual Studio 2015. I have as a starting point a simple C 
> program that prints hello world then calls py_initialize and then prints 
> another line of text to the screen. Calling Py_initialize causes the script 
> to exit with exit code 1. I am at a loss as to why this is happening. I have 
> read the documentation about Py_Initialize() calling exit when it should 
> raise an error so I understand it may be difficult to debug this issue.
> 

The documentation for Py_Initialize says, "There is no return value; it is a 
fatal error if the initialization fails." Initialization is failing in your C 
program, probably because it isn't able to locate a module needed for startup, 
such as site or encodings.

Py_Initialize doc: https://docs.python.org/2/c-api/init.html#c.Py_Initialize

You probably need to specify the "home" directory, either with the environment 
variable PYTHONHOME or with Py_SetPythonHome. For your system, the directory 
should be C:\Python27.
-- 
https://mail.python.org/mailman/listinfo/python-list


ABI name tag for libpython

2016-03-14 Thread Robert Snoeberger
On Debian, the shared library, libpython3.4m.so, is ABI version tagged with an 
“m.” I’m assuming that this is the ABI version tag specified in PEP 3149. The 
PEP give an example of using sysconfig.get_config_var to get the name tag.

>>> sysconfig.get_config_var('SOABI')
'cpython-34m'

I’ve also noticed that the configure variable ‘LDVERSION' gives the ‘3.4m’ bit 
in the library name.

>>> sysconfig.get_config_var('LDVERSION')
‘3.4m'

My question is, are these configure variables a reliable way to determine the 
name tag of the python shared library? I’m trying to use 
ctypes.util.find_library to find libpython.

Thank you!
-- 
https://mail.python.org/mailman/listinfo/python-list


[issue23110] Document if argument to Py_SetPath requires static storage.

2014-12-24 Thread Robert Snoeberger

New submission from Robert Snoeberger:

The documentation for the Py_SetPath API does not indicate if the argument 
should point to a wide character array in static storage. However, the 
documentation for Py_GetPath says, The returned string points into static 
storage; the caller should not modify its value. This leads me to believe that 
static storage is required for Py_SetPath.

The documentation for similar API functions, Py_SetPythonHome and 
Py_SetProgramName, indicates, The argument should point to a zero-terminated 
wide character string in static storage whose contents will not change

--
assignee: docs@python
components: Documentation
messages: 233081
nosy: docs@python, snoeberger
priority: normal
severity: normal
status: open
title: Document if argument to Py_SetPath requires static storage.
type: enhancement
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23110
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22238] fractions.gcd results in infinite loop when nan or inf given as parameter.

2014-08-20 Thread Robert Snoeberger

New submission from Robert Snoeberger:

 import fractions
 fractions.gcd(16, float('inf'))
Traceback (most recent call last):
  File pyshell#1, line 1, in module
fractions.gcd(16, float('inf'))
  File C:\Python34-32bit\lib\fractions.py, line 24, in gcd
a, b = b, a%b
KeyboardInterrupt
 fractions.gcd(16, float('nan'))
Traceback (most recent call last):
  File pyshell#2, line 1, in module
fractions.gcd(16, float('nan'))
  File C:\Python34-32bit\lib\fractions.py, line 24, in gcd
a, b = b, a%b
KeyboardInterrupt
 

With the iterative algorithm that is used 

a, b = b, a%b

b converges to float('nan'). It will never become 0 to break out of the loop. 
It might be nice to error when the iteration has converged b to a value other 
than 0.

--
components: Library (Lib)
messages: 225576
nosy: snoeberger
priority: normal
severity: normal
status: open
title: fractions.gcd results in infinite loop when nan or inf given as 
parameter.
type: enhancement
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22238
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21563] Segv during call to builtin_execfile in application embedding Python interpreter.

2014-05-26 Thread Robert Snoeberger

Robert Snoeberger added the comment:

I created a patch to add a check for NULL globals or locals. The file 
execfile.patch is attached. A system error is set with the message globals and 
locals cannot be NULL if either is NULL.

An open question I have is how should I create tests for this patch? I verified 
that the crash doesn't occur when I run the attached execfile_invoke.c program.

--
keywords: +patch
Added file: http://bugs.python.org/file35372/execfile.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21563
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



how to create a frame object when embedding python?

2014-05-23 Thread Robert Snoeberger

Hi python-list,

I'm embedding Python in an application and I have encountered two crashes while 
calling built-in functions that expect a top-level frame. See the following bug 
reports: http://bugs.python.org/issue21563 and 
http://bugs.python.org/issue21418. The problem is that the workflow for 
embedding the Python interpreter does not involve creation of a frame. 
RubyPython, a language interface to call Python from Ruby, has the same 
problem, http://rubypython.rubyforge.org/#known-problems. Since there is not a 
top-level frame object, some built-in functions do not work properly. In most 
cases, this problem is easily worked-around because globals and locals can be 
passed as optional arguments. The crashes, however, are more unfortunate. 

As an example, I can crash RubyPython by calling the built-in function execfile 
with a single argument.

irb(main):001:0 require('rubypython')
C:/Ruby200-x64/lib/ruby/gems/2.0.0/gems/blankslate-3.1.2/lib/blankslate.rb:51: 
warning: undefining `object_id' may cause serious problems
= true
irb(main):002:0 RubyPython.start
= true
irb(main):003:0 binmod = RubyPython.import('__builtin__')
= module '__builtin__' (built-in)
irb(main):004:0 binmod.execfile('foo.py')

The fourth line crashed the ruby interpreter. This is an example where an 
application might want to give full access to the functions in a Python module. 
It would be nice to find a way to prevent the crash without restricting the API.

I am curious if anyone has suggestions for creating a top-level frame?

Thank you,
Rob  



-- 
https://mail.python.org/mailman/listinfo/python-list


[issue21563] Segv during call to builtin_execfile in application embedding Python interpreter.

2014-05-23 Thread Robert Snoeberger

New submission from Robert Snoeberger:

While embedding the Python 2.7 interpreter in an application, I have 
encountered a crash when the built-in function 'execfile' is invoked with one 
argument.

A file is attached, execfile_invoke.c, that reproduces the crash. The 
reproduction steps on my machine are the following:

% gcc -o execfile_invoke execfile_invoke.c -I/usr/include/python2.7 -L/usr/lib 
-lpthread -ldl -lutil -lm -lpython2.7 -Xlinker -export-dynamic
% ./execfile_invoke
Call execfile with one argument...
Segmentation fault
% 

I am using the following version of Python.

Python 2.7.3 (default, Mar 13 2014, 11:03:55) 
[GCC 4.7.2] on linux2

The crash appears to occur because a call to PyEval_GetGlobals returns a NULL 
PyObject*,

globals = PyEval_GetGlobals();

and PyDict_GetItemString is called before a NULL check is performed.

In the Python 3 function builtin_exec, globals and locals are checked for NULL. 
If either is NULL, an exception with message globals and locals cannot be 
NULL is set.

if (!globals || !locals) {
 PyErr_SetString(PyExc_SystemError,
globals and locals cannot be NULL);
   return NULL;
}

--
files: execfile_invoke.c
messages: 218988
nosy: snoeberger
priority: normal
severity: normal
status: open
title: Segv during call to builtin_execfile in application embedding Python 
interpreter.
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file35329/execfile_invoke.c

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21563
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue21418] Segv during call to super_init in application embedding Python interpreter.

2014-05-02 Thread Robert Snoeberger

New submission from Robert Snoeberger:

While embedding the Python interpreter in an application, I have encountered a 
crash when the built-in function 'super' is invoked with no arguments. The 
crash occurs during a call to PyObject_Call.

A file is attached, super_invoke.c, that reproduces the crash. The reproduction 
steps on my machine are the following:

% gcc -o super_invoke super_invoke.c -I/path_to_py/include/python3.5m 
-L/path_to_py/lib -lpthread -ldl -lutil -lm -lpython3.5m -Xlinker 
-export-dynamic 
% ./super_invoke 
Call super with no arguments...
Segmentation fault
% 

The crash appears to occur in the function super_init contained in the file 
Objects/typeobject.c. The code path enters the if statement that checks for no 
input arguments. The following two lines cause the crash.

PyFrameObject *f = PyThreadState_GET()-frame;
PyCodeObject *co = f-f_code;

The PyFrameObject pointer 'f' is NULL.

--
files: super_invoke.c
messages: 21
nosy: snoeberger
priority: normal
severity: normal
status: open
title: Segv during call to super_init in application embedding Python 
interpreter.
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file35131/super_invoke.c

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21418
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com