I am trying to set up my machine to use PyOpenGL with freeglut. I have Python version 3.5.2 and a 64 bit copy of Windows 8.
I have downloaded PyOpenGL using pip, then downloaded freeglut and placed the include\ and lib\ folders at C:\Program Files\Common Files\MSVC\freeglut. I have also placed a link to the 64 bit freeglut.dll file in the environment variables linking to C:\Work\freeglut.dll
As I do not know any OpenGL yet I am simply trying to run the code from this page to see if my setup is functional http://www.de-brauwer.be/wiki/wikka.php?wakka=PyOpenGLSierpinski. When run I receive the error message
Traceback (most recent call last):
File "sier_tri.py", line 35, in <module>
glutInit()
File "C:\Users\Dylan\AppData\Local\Programs\Python\Python35-32\lib\site-packag
es\OpenGL\GLUT\special.py", line 333, in glutInit
_base_glutInit( ctypes.byref(count), holder )
File "C:\Users\Dylan\AppData\Local\Programs\Python\Python35-32\lib\site-packag
es\OpenGL\platform\baseplatform.py", line 407, in __call__
self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function glutInit,
check for bool(glutInit) before calling
Does anyone know what is causing this/how to fix it?
place the glut32.dll next to the py file.
Check this link
I fixed this by switching to the 32 bit freeglut.dll file. I thought that the 32bit vs 64bit was dependent on your operating system but it's actually dependent on which kind of Python you have, as I have 32 bit Python I need the 32 bit dll.
Related
I'm using PyGObject/GTK+ with Python3.7 on Windows and is worried about how to package my app. With official Python ecosystem, it's easy to use freezers and venvs. However, the PyGObject and GTK+ on Windows requires the MingW environment to run.
Does this mean that I have to package the entire MingW, along with GTK+?
How should I freeze the app?
Since no one cares soon enough, I'll report my findings here. The short answer, as of the date I write this post, is: The PyGObject eco-system is not commercial-ready on Windows, although nothing stops you from shipping a functional app.
The deal-breaker is the lack of functional freezers on Windows for PyGOBject. So you can't really ship a closed-source commercial product with it (although one could argue that the entire Python eco-system is not made for that). The freezers that I tried:
The officially recommended PyInstaller right now does not install with the officially recommended msys/MingGW universe; Even after building PyInstaller from source, the frozen .exe crashes with complaints about missing modules. Below is the crash report from a hello-world app.
$ app.exe
[8340] mod is NULL - structTraceback (most recent call last):
File "C:/Apps/msys64/mingw64/lib/python3.7/struct.py", line 13, in <module>
from _struct import *
ModuleNotFoundError: No module named '_struct'
[8340] mod is NULL - pyimod02_archiveTraceback (most recent call last):
File "C:/Apps/msys64/mingw64/lib/python3.7/site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyimod02_archive.py", line 28, in <module>
import struct
ModuleNotFoundError: No module named 'struct'
[8340] mod is NULL - pyimod03_importersTraceback (most recent call last):
File "C:/Apps/msys64/mingw64/lib/python3.7/site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyimod03_importers.py", line 24, in <module>
from pyimod02_archive import ArchiveReadError, ZlibArchiveReader
ModuleNotFoundError: No module named 'pyimod02_archive'
Traceback (most recent call last):
File "site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyiboot01_bootstrap.py", line 15, in <module>
ModuleNotFoundError: No module named 'pyimod03_importers'
[8340] Failed to execute script pyiboot01_bootstrap
cx_Freeze, another prominent alternative, does not build/install on MingW, either. You end up with gcc woes, no matter how many gcc variants you install.
py2exe is now abandonware since Python 3.4.
Since a PyGObject app still runs with MinGW python, it's not impossible to ship such an app for Windows. But that means you'll go with the big baggage and figure out a way to pack everything yourself. Let alone maintain the whole mess. Mind you that the procedure will be different on Mac if your app is cross-platform. PyInstaller works on Mac according to my test.
QuodLibet provides an example of how to ship an open-source software based on PyGObject. Unfortunately, as of today, the upstream's packaging procedure fails at the build.sh run on my Windows 10:
copying data/quodlibet.zsh -> E:\_dev\quodlibet\win_installer\_build_root\mingw64\share\zsh\vendor-completions\_quodlibet
Traceback (most recent call last):
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 141, in <module>
main(sys.argv)
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 130, in main
libs = get_things_to_delete(sys.prefix)
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 108, in get_things_to_delete
for lib in get_dependencies(path):
File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 66, in get_dependencies
data = data.decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position 72: invalid start byte
This turns out to be an easy fix: locale issue on non-UTF8 Windows.
A trivial patch would be replacing "utf-8" with locale.getdefaultlocale(). After that, the build succeeds.
However, the global distribution issues remain challenging:
Bloated pipeline: The officially recommended msys2 build system basically drags the entire GNOME universe and much of the Python universe to your machine, while you may already have a Python environment on your native Windows. It proves hard to cherry-pick the necessary dependencies among this whole pile of stuff.
Extra C pipeline required to build the executable. To build a Windows executable without a freezer, you must create your app as a Python package (big hassle), install it to your msys2-Python site-packages (another setup.py hassle), and then build a wrapper C application using the Python C API (opaque hassle). The process is not transparent, especially when Python packaging system is sensitive to working directory and path differences. Launching the executable can easily go wrong without much debug info.
Manual stripping. As mentioned above, you must manually cherry-pick dependencies or your app would be shipped with basically the entire msys2/MinGW universe that's worth 100MB+ for a hello-world app.
I'm trying to generate a pdf417 barcode in python using treepoem but pycharm keeps giving me the following error:
Traceback (most recent call last):
File "C:/Users/./Documents/barcodes.py", line 175, in
image = generate_barcode(barcode_type="pdf417",data=barcode, options=dict(eclevel=5, rows=27, columns=12))
File "C:\Users.\AppData\Local\Programs\Python\Python36-32\lib\site-packages\treepoem__init__.py", line 141, in generate_barcode
bbox_lines = _get_bbox(code)
File "C:\Users.\AppData\Local\Programs\Python\Python36-32\lib\site-packages\treepoem__init__.py", line 81, in _get_bbox
ghostscript = _get_ghostscript_binary()
File "C:\Users.\AppData\Local\Programs\Python\Python36-32\lib\site-packages\treepoem__init__.py", line 108, in _get_ghostscript_binary
'Cannot determine path to ghostscript, is it installed?'
treepoem.TreepoemError: Cannot determine path to ghostscript, is it installed?
I've tried to install ghostcript, using both the .exe I found online and using pip install ghostscript (successfully completed the first time, and now tells me the requirement is satisfied), yet I still keep getting this error. Any ideas on how to fix it?
You are installing on Windows, the Windows binary differs in name from the Linux binaries and indeed differs depending whether you installed the 64 or 32-bit version.
On Linux (and MacOS) the Ghostscript binary is called 'gs', on Windows its 'gswin32' or 'gswin64' or 'gswin32c' or 'gswin64c' depending on whether you want the 32 or 64 bit version, and the command line or windowed executable.
My guess is that your script is looking for simply 'gs' and is probably expecting the path to be in the $PATH environment variable, its not clear to me what its expecting.
You could probably 'fix' this by making sure the installation path is in the $PATH environment variable and copying the executable to 'gs.exe' in that directory.
Other than that you'll need someone who can tell you what the script is looking for. Quite possibly you could just grep it.
Another solution is to edit the C:\Users\Windows.UserName\AppData\Local\Programs\Python\Python37\Lib\site-packages\treepoem__init__.py
the script is looking for gs.exe, change to gswin32.exe as shown below.
Then add the GhostScriptInstallDir\bin in the PATH in windows.
def _get_ghostscript_binary():
binary = "gswin32" # changed from 'gs' to 'gswin32'
if sys.platform.startswith("win"):
binary = EpsImagePlugin.gs_windows_binary
if not binary:
raise TreepoemError(
"Cannot determine path to ghostscript, is it installed?"
)
return binary
I'm trying to run a Python script that involves ARP sniffing and is apparently dependent on the Scapy library being present. I have absolutely no idea what I'm doing but I'm reasonably good at Googling, following directions, and copying/pasting. I have it up and running on my Mac, but I'm stuck on what I hope is the last hurdle in getting Scapy working on my Windows computer (which is ultimately the one that needs to be running this script).
I followed all of the instructions at http://www.secdev.org/projects/scapy/doc/installation.html#windows, except that I chose Python 2.7 and used the newer 2.7-compatible versions of everything listed there. I used “python setup.py install” (successfully, as best I could tell) on all installs except Pypcap and Libdnet, which I installed via the Exe as an Administrator as instructed.
Unfortunately, when I type "scapy" into the command prompt to test if it works, I get the following information & error message:
C:\scapy-2.3.1>scapy
INFO: Can't import python gnuplot wrapper . Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
Traceback (most recent call last):
File "C:\Python27\Scripts\\scapy", line 25, in <module>
interact()
File "C:\Python27\lib\site-packages\scapy\main.py", line 278, in interact
scapy_builtins = __import__("all",globals(),locals(),".").__dict__
File "C:\Python27\lib\site-packages\scapy\all.py", line 16, in <module>
from arch import *
File "C:\Python27\lib\site-packages\scapy\arch\__init__.py", line 79, in <module>
from windows import *
File "C:\Python27\lib\site-packages\scapy\arch\windows\__init__.py", line 214, in <module>
ifaces.load_from_dnet()
File "C:\Python27\lib\site-packages\scapy\arch\windows\__init__.py", line 173, in load_from_dnet
self.data[i["name"]] = NetworkInterface(i)
File "C:\Python27\lib\site-packages\scapy\arch\windows\__init__.py", line 93, in __init__
self.update(dnetdict)
File "C:\Python27\lib\site-packages\scapy\arch\windows\__init__.py", line 107, in update
self._update_pcapdata()
File "C:\Python27\lib\site-packages\scapy\arch\windows\__init__.py", line 118, in _update_pcapdata
win_name = pcapdnet.pcap.ex_name(guess)
AttributeError: 'module' object has no attribute 'ex_name'
Can anyone help me out? If you need more information please let me know.
I am running Windows 10.
Thanks in advance,
- Ethan
I had same problem.
To solve it, i downloaded dnet-1.12.win32-py2.7.exe
and pcap-1.1.win32-py2.7.exe.
You might want to try with Scapy's current development version (from the Github repository). Support for Windows has been updated recently and should work without the need of Libdnet.
If that's not the case, you should probably open an issue.
Try it with scapy3k. Install python3 (e.g. I use Anaconda 3.5), and WinPcap driver. You do not need dnet or pypcap. Install using pip install scapy-python3 or from http://github.com/phaethon/scapy
I get a warning message while trying to create exectable file using pyinstaller. This warning appeared after installing Pillow. Previously i nevre got any warnings and was able to make it through.
the warning i get by pyinstaller is:
7314 INFO: Analyzing main.py
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyInstaller-2.1.1dev_-py2.7.egg/PyInstaller/hooks/hook-PIL.Image.py:14: RuntimeWarning: Parent module 'PyInstaller.hooks.hook-PIL' not found while handling absolute import
from PyInstaller.hooks.shared_PIL_Image import *
Also when i tried to run the executable's exe/consol version of my code that lies inside the dist folder created by the pyinstaller (dist/main/main), these are displayed..
Traceback (most recent call last):
File "<string>", line 26, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyInstaller-2.1.1dev_-py2.7.egg/PyInstaller/loader/pyi_importers.py", line 276, in load_module
exec(bytecode, module.__dict__)
File "/Users/..../build/main/out00-PYZ.pyz/PIL.PngImagePlugin", line 40, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyInstaller-2.1.1dev_-py2.7.egg/PyInstaller/loader/pyi_importers.py", line 276, in load_module
exec(bytecode, module.__dict__)
File "/Users/..../build/main/out00-PYZ.pyz/PIL.Image", line 53, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyInstaller-2.1.1dev_-py2.7.egg/PyInstaller/loader/pyi_importers.py", line 276, in load_module
exec(bytecode, module.__dict__)
File "/Users/..../build/main/out00-PYZ.pyz/FixTk", line 74, in <module>
OSError: [Errno 20] Not a directory: '/Users/.../dist/main/tcl'
logout
[Process completed]
so, i tried by uninstalling pillow, installing tk tcl dev version. And then installed pillow. Even that didnt helped.
I also tried reinstalling pyinstaller,. didnt help too
Update 1:
It seems Pyinstaller.hooks.hook-PIL.py file was missing in the Pyinstaller/hooks directory. And it was missing on all platforms(Mac, windows and linux). This is the warning/error message that i get on windows, which is the same i got on mac and on linux.
Later i found a link which said, its just to need Python import machinery happy. so i created as said so. Then i dont get the same error on all platforms, But on mac i still get the PILImagePlugin,Image and FixTk errors
Solution for tcl:
I found what was going wrong,.. Every problem that i faced on OSX was the OS itself(exactly the macport). Python by default comes with the mac OS. And this version of python may be useful for just learning basic python, but is not suitable for Development purpose.
Installing brew's python helped. I followed this SO link. After doing these i was still getting errors. Later i had to change the paths on /etc/paths. Basically rearranging them should work. But still then i wasn't getting it right.
Then i had to change the .bash_profile, which worked for most users, But still i was getting mac's version of python and pip, not the brews version of python.
Finally i had to restart the machine for a couple of times and do the /etc/paths and .bash_profile steps repeatedly to get the system wide effect to accept brews version of python and pip
Solution for PIL:
just adding a file called hook-PIL.py with an empty content would serve the purpose. I found a link which was having the hook files content of pyinstaller.
The location to create
for mac : /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyInstaller-2.1.1dev_-py2.7.egg/PyInstaller/hooks/ Actually for mac this step wouldn’t be required. When we install python through brew and change the path, everything that you try to install later either through pip install or from source packages tend to choose a different path. And everything will be taken care of.
for windows:C:\Python27\lib\site-packages\PyInstaller-2.1.1.dev0-py2.7.egg\PyInstaller\hooks
**Please check if this is a valid path on your machine before creating the file and then create the file. And im not sure or i don't know if just adding an empty file is the right way. But it worked for me
I am trying to follow the installation guide for PySWIP in Windows, which first asks to install a 32 bit version of SWI-Prolog first and include its bin in PATH, which I did. Then I installed the 64 bit version of PySWIP since my Python-2.7 is 64 bit Anaconda version. But it doesn't work (see error below).
As suggested by some elsewhere, I also made of copy of libswipl.dll (in C:\Program Files (x86)\pl\bin ) as libpl.dll and of swipl.ico (in C:\Program Files (x86)\pl ) as pl.ico but no luck.
The error that I am getting (in Spyder and EclipsePyDev IDEs using Anaconda interpreter) when I enter the first line below is:
>>> from pyswip import Prolog
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\XXX\Anaconda\lib\site-packages\pyswip\__init__.py", line 29, in <module>
from pyswip.prolog import Prolog
File "C:\Users\XXX\Anaconda\lib\site-packages\pyswip\prolog.py", line 29, in <module>
from pyswip.core import *
File "C:\Users\XXX\Anaconda\lib\site-packages\pyswip\core.py", line 360, in <module>
_lib = CDLL(_path)
File "C:\Users\XXX\Anaconda\lib\ctypes\__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 193] %1 is not a valid Win32 application
How to fix this?
Background: I am working through the first order logic programming of natural language semantics of NLTK book, and I thought it would be nice to have a logic program that can do constraint programming (specifically, solve for equality logical constraints)
Found my answer - it was that I should have installed a 64 bit (instead of 32 bit) version of SWI-Prolog for it to work with 64 bit PySWIP and Python (even though the installation guide at PySWIP specifically mentioned 32 bit SWI-Prolog). Its working now.
PS: I didn't find the need to rename libswipl.dll or swipl.ico