Changes by Palm Kevin :
--
nosy: +palm.kevin
___
Python tracker
<http://bugs.python.org/issue29355>
___
___
Python-bugs-list mailing list
Unsubscribe:
Palm Kevin added the comment:
Ok, but shouldn't it fail earlier?
During "configure" or "make", not on "make install"...
Perhaps with a message like "Unable to compile with pip because dependency zlib
is missing"
--
Palm Kevin added the comment:
Yes. You are right. This solves the problem for me since I don't need pip.
Do you think I should close the issue or rename it into '"make install" fails
with pip when missing zlib dependency' ?
--
_
New submission from Palm Kevin:
It seems that on linux (red hat), the "make install" fails when no zlib support
is available. (I have no zlib installed and I don't want to do so)
I reproduced the problem with both python 3.5.1 and python 3.5.2
The command 'configure
Palm Kevin added the comment:
BTW: Is there a good reason, the folder-of-the-executable is added to the
python-path? I don't see any...
--
___
Python tracker
<http://bugs.python.org/is
New submission from Palm Kevin:
The way the python path is initialized with the embeddable python distribution
makes no sense for me.
If no environment variable PYTHONPATH is set, then the path is initialized like
this:
[python352]\python35.zip;.\DLLs;.\lib;[folder_of_executable
Changes by Palm Kevin :
--
nosy: +palm.kevin
___
Python tracker
<http://bugs.python.org/issue17408>
___
___
Python-bugs-list mailing list
Unsubscribe:
Palm Kevin added the comment:
@ncoghlan: Not PySys_SetPath, but Py_SetPath is causing the problem (you
mentionned PySys_SetPath in your message msg249311)
I discovered PySys_SetPath only last Friday.
In fact, in my case, the usage of PySys_SetPath (after Py_Initialize) instead
of Py_SetPath
Palm Kevin added the comment:
The problem seems still not resolved in Python 3.2.6 :-(
The reason has been found by Debao (msg144244). Isn't there anybody motivated
to fix this bug?
--
title: Can't call Py_SetPath() on pointer returned by Py_GetPath() -> Usage of
API meth
Palm Kevin added the comment:
Issue can be closed. I am not able to reproduce this any more...
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Palm Kevin added the comment:
Reproducible for Py 3.2.5
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue17213>
___
___
Python-bugs-list m
Palm Kevin added the comment:
+1
--
nosy: +palm.kevin
___
Python tracker
<http://bugs.python.org/issue17213>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Palm Kevin :
Added file: http://bugs.python.org/file30494/Makefile.pre.in.patch
___
Python tracker
<http://bugs.python.org/issue18154>
___
___
Python-bug
Changes by Palm Kevin :
Removed file: http://bugs.python.org/file30493/Makefile.pre.in.diff
___
Python tracker
<http://bugs.python.org/issue18154>
___
___
Python-bug
Changes by Palm Kevin :
Added file: http://bugs.python.org/file30493/Makefile.pre.in.diff
___
Python tracker
<http://bugs.python.org/issue18154>
___
___
Python-bugs-list m
Changes by Palm Kevin :
Removed file: http://bugs.python.org/file30492/Makefile.pre.in.diff
___
Python tracker
<http://bugs.python.org/issue18154>
___
___
Python-bug
Palm Kevin added the comment:
fixing patch attached
--
keywords: +patch
Added file: http://bugs.python.org/file30492/Makefile.pre.in.diff
___
Python tracker
<http://bugs.python.org/issue18
New submission from Palm Kevin:
On Solaris, make install fails on target altbininstall.
This is due to the fact than on Solaris you man not create a symlink using `ln
-sf` -> You have to use `ln -f -s`.
(SunOS sol1 5.10 Generic_147440-09 sun4u sparc SUNW,Sun-Fire-V240)
--
compone
Palm Kevin added the comment:
The `-lintl` fix did not work in my case.
But I succeeded to compile Python using the CC compiler (/usr/bin/cc) instead
of GCC compiler.
(cc: Sun C 5.12 SunOS_sparc 2011/11/16)
--
nosy: +palm.kevin
___
Python tracker
Palm Kevin added the comment:
I embed Python into an existing, external C application. In addition to this I
extend Python to access that app from Python.
I do never set explicitly set the standard input to NULL. I guess that the
external C application does this
Changes by Palm Kevin :
--
components: +IO
type: -> crash
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue11709>
___
___
Python-bugs-lis
New submission from Palm Kevin :
The interactive help-method provided by python crashes when no stdin-stream is
available (sys.stdin == None).
Exception:
Traceback (most recent call last):
File "MyScript", line 4, in
File "C:\Python32\lib\site.py", line 457, in _
Palm Kevin added the comment:
As for this error:
Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: no codec search functions registered: can't find encoding
It seems to me that this error appears if the path passed to Py_SetPath does
not point to a
Palm Kevin added the comment:
Furthermore I would propose to rename this issue: The problem is not that
Py_SetPath cannot be called on pointer returned by Py_GetPath. I think that the
problem is more general: Calling Py_SetPath NEVER works.
--> I get the same exception as documented in
Palm Kevin added the comment:
Antoine,
Your guess that my issue initially wasn't related to virtualenv is correct
(I've never heard about that project before posting this issue...)
As for passing the output of Py_GetPath directly to Py_SetPath: You are right,
there is no point in
Palm Kevin added the comment:
@Sridhar: Could you please provide input for the question asked by Antoine?
I'd love to have this issue fixed for next Python release.
--
___
Python tracker
<http://bugs.python.org/is
Palm Kevin added the comment:
@Barry: Yes python runs correctly.
The problem arises when you embed python in a C application when calling the
Py_SetPath-method (see the follow up issue #11320)
--
___
Python tracker
<http://bugs.python.
Changes by Palm Kevin :
--
versions: +Python 3.1
___
Python tracker
<http://bugs.python.org/issue11321>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Palm Kevin :
Please have a look to the following app:
#include "Python.h"
main(int argc, char **argv)
{
int i;
printf("START\n");
for(i = 0; i < 20; i++){
Py_Initialize();
printf("Try import #%i ...", i);
PyR
Palm Kevin added the comment:
Done: #11320
--
___
Python tracker
<http://bugs.python.org/issue10743>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Palm Kevin :
The new API method Py_SetPath seems bugged. When executing the following code,
then the application crashes on Py_Initialize()-call:
#include "Python.h"
main(int argc, char **argv)
{
Py_SetPath(Py_GetPath());
printf("Init\n");
Py_In
Palm Kevin added the comment:
Please find here a small C app embedding python that shows how to reproduce
the problem (It turned out that the problem is caused by the new method
"Py_SetPath"):
#include "Python.h"
main(int argc, char **argv)
{
Py_SetPath(Py_GetPath(
Palm Kevin added the comment:
I think that this issue needs to be reopened... since it never has been
resolved...
I just downloaded the new version of Python 3.2 and tried to compile, install
and use it on Redhat Linux.
Installation went fine (configure with --prefix=/usr/mysoft/python32
Palm Kevin added the comment:
I applied the patch proposed by slanger. This one is working.
Now, I'm executing this instruction to build my extension:
"%pythonRoot%\python.exe" setup.py build_ext --include-dirs "C:\MyApp\include"
--library-dir "C:\MyApp\lib&quo
Palm Kevin added the comment:
This one is really annoying. Could you please consider fixing this one for the
next release? (=lightweight change)
--
nosy: +palm.kevin
___
Python tracker
<http://bugs.python.org/issue1326
35 matches
Mail list logo
