Develop Reference

Installing gr-gsm with PyBombs

So I've been using the guide found here to install gr-gsm for GNU Radio with pybombs on Arch Linux. However, when I get to the line for installing gr-gsm, I get the following error:
[josh#localhost ~]$ pybombs install gr-gsm
PyBombs.DepManager - ERROR - Package does not exist: ssl (declared as dependency for package libevent)
According to the guide, it should install dependencies by itself. I've gone through the documentation for pybombs to see if I'm doing something incorrectly and couldn't find anything. I double checked the configuration as well.
If I go into Python and import ssl, it's there.
EDIT:
Checking the recipe list, ssl is in there:
[josh#localhost build]$ pybombs recipes list
...
ssl ~/.pybombs/recipes/gr-recipes/ssl.lwr
and yet, I get the same error:
[josh#localhost build]$ pybombs install gr-gsm
PyBombs.DepManager - ERROR - Package does not exist: python (declared as dependency for package mako)

It can not find the package. Actually it's the same on Void. It's a pitfall of all these wrap arounds. Because the package managers of Arch (fixed by now if I read the sources of Pybombs correctly), Void are not coded ...
You can edit ~/.pybombs/recipes/gr-recipes/ssl.lwr and add a check yourself. If you add a new key then the code also needs changing if it is not considered in the sources.
But first check if you have SSL installed locally, e.g. using pkg-config openssl --version.
You can also flag the SSL check as optional during dependency check and then make sure it really exists and that it will be found by the compiler (which is invoked later).
Though for Arch this should be fixed by now.
[A nicer way for Arch instead of such wrappers like pybombs are PKGBUILDS - the same is true for Void who uses almost same format templates as Arch. A cross platform system like 0install might also help.]
Edit: GNURadio exists as Arch package already, see https://wiki.archlinux.org/index.php/GNU_Radio

PostgreSQL unable to create plpythonu extension

I'm trying to write a function in PostgreSQL on Windows with a Python script in the body and i'm running into an error message when trying to create the plpythonu extension. The command I'm running is:
CREATE EXTENSION plpythonu;
Which produces the following error message:
ERROR: could not access file "$libdir/plpython2": No such file or directory
SQL state: 58P01
I also tried running:
CREATE EXTENSION plpython3u;
which results in this error:
ERROR: could not load library "C:/Program Files (x86)/PostgreSQL/9.2/lib/plpython3.dll": The specified module could not be found.
SQL state: 58P01
The plpython3.dll file exists at this location, but apparently is missing some critical dependency. I've searched everywhere and found nothing helpful on this. I have both Python 2 and 3 installed on the machine...

The newest (9.4 or later) binary installations from EnterpriseDB contain only plpython3u.dll. In versions 9.4 to 9.6 I had to install python 3.3 to get plpython3u run.
You can check which version of Python is needed by plpython3u.dll using Dependency Walker.

A full answer can be found:
https://postgresrocks.enterprisedb.com/t5/PostgreSQL/unable-to-install-pl-python-extension/m-p/4090
It assumes you have used stackbuilder to install the edb language pack.
Do check the commands for correctness in your installation.
E.g. path to postgresql data, install path of edb and python version.
When you use depency walker (depends.exe), only pay attention to the pythonxx.dll. With older PG versions, this may or may not agree to the version installed by the EDB languages package. For version 10.7, version 3.4 Python is required. For windows, the later 3.4 Python versions do not appear to have a msi installer. You may have to install 3.4.4, or try to upgrade PG 10 to the latest version (10.11) first. This version requires python 3.7, so then you can use the EDB download.
But the python version may already exist and be found.
could not load library plpython3.dll (here on stackoverflow) was somewhat close, but did not detail the environment vars needed.
the solution proposed does not require you to change env vars permanently, which is a great help when using several python installations.

Matplotlib error: libfreetype.6.dylib

I'm trying to run the following python script (I'm using Vim):
import numpy as np;
import scipy as sp;
from scipy import misc;
import matplotlib.pyplot as plt;
image = misc.imread('test_image.jpg');
np.fliplr(image);
plt.imshow(image);
When I do, I get the following:
Traceback (most recent call last):
File "test.py", line 4, in <module>
import matplotlib.pyplot as plt;
File "/Library/Python/2.7/site-packages/matplotlib/pyplot.py", line 24, in <module>
import matplotlib.colorbar
File "/Library/Python/2.7/site-packages/matplotlib/colorbar.py", line 29, in <module>
import matplotlib.collections as collections
File "/Library/Python/2.7/site-packages/matplotlib/collections.py", line 23, in <module>
import matplotlib.backend_bases as backend_bases
File "/Library/Python/2.7/site-packages/matplotlib/backend_bases.py", line 50, in <module>
import matplotlib.textpath as textpath
File "/Library/Python/2.7/site-packages/matplotlib/textpath.py", line 11, in <module>
import matplotlib.font_manager as font_manager
File "/Library/Python/2.7/site-packages/matplotlib/font_manager.py", line 53, in <module>
from matplotlib import ft2font
ImportError: dlopen(/Library/Python/2.7/site-packages/matplotlib/ft2font.so, 2): Library not loaded: #loader_path/../../../libfreetype.6.dylib
Referenced from: /Library/Python/2.7/site-packages/matplotlib/ft2font.so
Reason: image not found
shell returned 1
I tried reinstalling brew, reinstalling freetype, matplotlib, and numpy in brew, and I uninstalled MacPorts with no change in the error. Suggestions?
EDIT: After uninstalling MacPorts and then doing another reinstall of brew, I now get this error instead.
Fatal Python error: PyThreadState_Get: no current thread
Command terminated
The error only appears when I import matplotlib, so I'm guessing the issue is with matplotlib. I will try to reinstall it with brew.
EDIT2: I've been trying from this page to no avail, but I think my error is probably related to that one.

[MacOS X] Ran into the same problem after installing graphviz (to visualize decision tree). Without carefully isolating environment, this new package appears to have put its own favorite version of freetype into my default python runtime library path. Then when doing a simple import import matplotlib.pyplot as plt, I got error messages:
ImportError: dlopen(/Users/shandou/anaconda3/lib/python3.6/site-
packages/matplotlib/ft2font.cpython-36m-darwin.so, 2): Library not
loaded: #rpath/libfreetype.6.dylib
Referenced from: /Users/shandou/anaconda3/lib/python3.6/site-
packages/matplotlib/ft2font.cpython-36m-darwin.so
Reason: Incompatible library version: ft2font.cpython-36m-darwin.so
requires version 22.0.0 or later, but libfreetype.6.dylib provides
version 21.0.0
At first, I could not understand what #rpath is really pointing to. Checked with locate libfreetype and it looks like for my default python environment, I have (1) /Users/shandou/anaconda3/lib/libfreetype.6.dylib and (2) /Users/shandou/anaconda3/pkgs/freetype-2.8.1-0
I tried the following two fixes. The first one solved the immediate need of making matplotlib import work, but later caused problems in sphinx auto doc generation. The second one is a cleaner fix that made both work.
Fix 1: conda uninstall and then pip install matplotlib
Context: I use anaconda python distribution and use conda as my main package manager
Spoiler alert: temporarily fixed import problem, but got me into trouble later when using sphinx
Takeaway: mixing pip and conda installation for major libraries can be problematic
Following #Robbie Capps's suggestion above, I uninstalled matplotlib originally installed with conda and reinstalled it with pip instead. Afterwards matplotlib import works okay and I was able to continue working until later I ran into errors when running sphinx for documenting codes:
File "/Users/shandou/anaconda3/lib/python3.6/site-
packages/matplotlib/backends/backend_macosx.py", line 17, in <module>
from matplotlib.backends import _macosx
RuntimeError: Python is not installed as a framework. The Mac OS X
backend will not be able to function correctly if Python is not
installed as a framework. See the Python documentation for more
information on installing Python as a framework on Mac OS X. Please
either reinstall Python as a framework, or try one of the other
backends. If you are using (Ana)Conda please install python.app and
replace the use of 'python' with 'pythonw'. See 'Working with
Matplotlib on OSX' in the Matplotlib FAQ for more information.
That looks hairy, but if I read this correctly, the gist of the message is: sphinx is not happy about me mixing conda and pip install.
So I ended up reverting matplotlib back to conda installation. Sadly the original libfreetype error immediately returns and I was unable to do basic matplotlib import (darn...)
Fix 2: Update freetype library located in runtime path (#rpath in the error message)
Context: I tried updating freetype, libpng, and matplotlib--basically anything that the web would suggest
Spoiler alert: If runtime path library is not updated, I am left with the same error message about incompatible libfreetype
[Step 1] Brew install freetype library:
$ brew install freetype
$ brew link --overwrite freetype
When checking the library version in /usr/local/Cellar/freetype/2.9/lib/, I get output as below:
$ otool -L libfreetype.6.dylib | head -n 2
libfreetype.6.dylib:
/usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 23.0.0, current version 23.0.0)
This is version 21+, so we are one step closer to solve the problem
[Step 2] Copy /usr/local/Cellar/freetype/2.9/lib/libfreetype.6.dylib to python runtime library path
It turns out even after updating freetype library with conda, the runtime library is not updated. The final solution that works for me is to force copy newer freetype lib to the runtime path:
$ cd /Users/shandou/anaconda3/lib/
$ sudo cp /usr/local/Cellar/freetype/2.9/lib/libfreetype.6.dylib .
Only then, the freetype library version incompatibility problem is gone, and both matplotlib import and sphinx are happy
Bottom line: Fix 2 is the cleaner way to go.

It sounds like you already (at least partially) answered your own question, but I solved this same error, in a somewhat different fashion. Summary: I used otool and install_name_tool to manually change the linkage from the *.so file to a different *.dylib. I'm posting it here mostly as an illustration of how build systems can quickly turn into rat's nests if you're not careful.
Background
I am using conda to manage the virtual environment for a software project I am trying to compile from source (GNU Radio). In order to build the graphics submodule of this project (gr-qtgui) natively on my Mac, I believe I committed some pretty heinous crimes against nature -- more on this below.
My basic strategy to avoid build problems is to rely on a single package manager as much as possible. In this case, the honor went to conda, though some of it required brew and pip. As I'm writing this, I'm now wondering whether I should have linked against the Mac frameworks for Qt4, but what I ended up doing was linking against libQtCore.dylib et al. installed by conda in ~/miniconda3/envs/gr/lib.*
Graphics issues & Resolution
After getting GNU Radio to compile, I then conda install'd matplotlib in this virtual environment. I was initially getting a similar error as OP originally mentions:
ImportError: dlopen(/Users/strotmc1/miniconda3/envs/gr/lib/python2.7/site-packages/matplotlib/ft2font.so, 2): Library not loaded: #rpath/libfreetype.6.dylib
Referenced from: /Users/strotmc1/miniconda3/envs/gr/lib/python2.7/site-packages/matplotlib/ft2font.so
Reason: Incompatible library version: ft2font.so requires version 21.0.0 or later, but libfreetype.6.dylib provides version 14.0.0
I solved it by navigating to the offending shared object's directory and inspecting it:
>> cd ~/miniconda3/envs/gr/lib/python2.7/site-packages/matplotlib
>> otool -L ft2font.so
ft2font.so:
#rpath/libfreetype.6.dylib (compatibility version 21.0.0, current version 21.0.0)
#rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
>> otool -l ft2font.so
...
Load command 9
cmd LC_LOAD_DYLIB
cmdsize 56
name #rpath/libfreetype.6.dylib (offset 24)
time stamp 2 Wed Dec 31 19:00:02 1969
current version 21.0.0
compatibility version 21.0.0
...
Load command 12
cmd LC_RPATH
cmdsize 272
path /Users/strotmc1/miniconda3/envs/gr/lib (offset 12)
...
In other words, it's linking to the libfreetype.dylib located inside the virtual environment, not on the system. Sort of makes sense as an error, because pyplot is also trying to access the graphics libraries, which were already strangely configured. My solution was to switch to linking against the homebrew version of freetype:
>> install_name_tool -change #rpath/libfreetype.6.dylib /usr/local/Cellar/freetype/2.9/lib/libfreetype.6.dylib ft2font.so
and now matplotlib works!
Moral of the story
I said from the beginning that this story is ugly. After finishing writing this up, I'm left with the following conclusions:
Despite being able to compile large software projects, I still don't really know what the hell I'm doing.
Given the difficulty of writing general-purpose libraries, and how much variation can exist across platforms, and that all users set up their systems differently, I'm amazed that anything ever works.
On the other hand, is this really the best we can do? It seems like complexity is the source of the problem. Does any tool sophisticated enough to manage the complexity necessarily introduce more complexity into the system, and thus more opportunities for failure?
Sorry this turned into more of a musing than an answer -- perhaps someone would be so kind to suggest a better place for this type of rambling answer?
*To be completely frank, I never even considered trying to link against the Qt frameworks located in /Library/Frameworks. I'm not sure if the build tools (here, cmake) are smart enough to find these Frameworks, because I haven't tried. I will consider posing this question to the community.

Fixed it... sort of.
Fixed it.
I uninstalled with brew uninstall matplotlib and then installed with pip install matplotlib. The pip version now works. although I think something is wrong with my code because I don't get an image output.
I uninstalled all of my installations of python and then installed ipython, which worked fine. Also, I was forgetting to add plt.show(); after my imshow(); commands... :-( .... but at least someone else has made this mistake before me ...
Refer to this page for very thorough help with any matplotlib imshow issues:
matplotlib does not show my drawings although I call pyplot.show()

You can try to run python with Anaconda and check the version of freetype in your conda environment.
I got the same type of error when I try to install opencv in conda. And finally it was solved by one command:
conda update freetype

Two steps to solve the problem:
Step 1: Updating freetype and coping the .dylib to the anaconda lib folder:
brew upgrade freetype
cp /usr/local/Cellar/freetype/2.10.4/lib/libfreetype.dylib ~/opt/anaconda3/lib/
Step 2: Following the import sequence as below:
import matplotlib
matplotlib.use('PS')
import matplotlib.pyplot as plt

Found one immediate solution that worked for me.
Due to multiple projects in same environment, my matplotlib was not supporting new changes.
pip3 uninstall matplotlib
pip3 install matplotlib

Check path tou your image (and doublecheck)
This is in your traceback:
"Reason: image not found"
Also there is no need to use ';' in python.

ImportError: Permission Denied while using LXML

I've been having a ton of trouble using LXML, after installing it from https://pypi.python.org/pypi/lxml/3.2.1 using Easy_Install-2.7. I installed it on Windows using cygwin, and at first the package seemed to be okay. However upon further testing I ran into problems.
When I run code with:
import lxml
it works completely fine. But as soon as I try:
import lxml.etree
I get this error:
Traceback (most recent call last):
File "D:\Nick_Code\NewsScraper\testdummy.py", line 7, in <module>
import lxml.etree
File "/usr/lib/python2.7/site-packages/lxml-3.2.0-py2.7-cygwin-1.7.20-i686.egg/lxml/etree.py", line 7, in <module>
__bootstrap__()
File "/usr/lib/python2.7/site-packages/lxml-3.2.0-py2.7-cygwin-1.7.20-i686.egg/lxml/etree.py", line 6, in __bootstrap__
imp.load_dynamic(__name__,__file__)
ImportError: Permission denied
I've been trying to find information/work arounds for quite a while but no success. Please let me know if you have any insight or need information.
Thanks!
Michael

This is not a solid answer. But I will highlight several of the problems involved for obtaining a solution. Most likely the problem above, is like a cancer caused by several factors acting catastrophically together.
I have the same exact problem as in the OP, when attempting to use the native Cygwin supplied Python packages on my Windows Vista machine. Being new to Python I have spent several days in trying to get this to work, and understand why it is not working. But all my Google-fu returned nothing but countless dead ends. So here's my take on this.
There are many reasons why Python could have trouble under Cygwin, some which you can do something about and some which are beyond most peoples control. What it boils down to, are the following key issues:
Windows is a complete mess when it comes to file permissions, and Cygwin cannot handle windows file permissions very well. So what you see in Cygwin is far from the whole story.
Windows is shamefully character case-independent which causes loads of trouble, especially when you need to (cross)compile anything that was originally developed under *nix based system (i.e. everything). In fact, if you attempt extracting any archive that contains files whose names differ only in capitalization. (I.e. "makefile" vs "Makefile" etc.) files under Windows or Cygwin, you loose all but one of the files. in case their You need to enable case-sensitivity to do anything more than "hello world" *nix compilations.
Windows handles symlinks completely different than Cygwin. And if your ZIP, TAR etc. archives contain any symlinks, they will be broken after extraction to Windows environment.
Sloppy code practices, where developer have not properly tested their creations on various environments, or carefully set proper file permissions to their *.tar.gz collections. Including correct dependency specifications, or mentioning whether or not binaries has been statically linked etc.
For the full gory details and further (Win-Cygwin) issues, look HERE.
At first I tried to use Cygwin's own Python without any additional packages, and nstalling lxml using PIP and easy_install. Then I tried to use Cygwin's own libxml2, libxslt and xml python packages, and I had the same problems.
At first, after installing the static windows binaries (as suggested elsewhere),
I got this error:
File "/usr/lib/python2.7/site-packages/lxml-3.2.4-py2.7-cygwin-1.7.24-i686.egg/lxml/etree.py", line 6, in __bootstrap__
imp.load_dynamic(__name__,__file__)
ImportError: Permission denied
Aborted (core dumped)
Then I investigated the file permissions and changed those with: chmod -R 755 /usr/lib/python2.7/
I got one step further to isolate problem to an apparently missing file.
And enabling verbose and diagnostic mode's didn't help much either.
File "/usr/lib/python2.7/site-packages/lxml-3.2.4-py2.7-cygwin-1.7.24-i686.egg/lxml/etree.py", line 6, in __bootstrap__
imp.load_dynamic(__name__,__file__)
ImportError: No such file or directory
Aborted (core dumped)
HERE is the exact statement specification:
Load and initialize a module implemented as a dynamically loadable shared
library and return its module object. If the module was already initialized, it
will be initialized again. Re-initialization involves copying the __dict__
attribute of the cached instance of the module over the value used in the module
cached in sys.modules. The pathname argument must point to the shared library.
The name argument is used to construct the name of the initialization function:
an external C function called initname() in the shared library is called. The
optional file argument is ignored. (Note: using shared libraries is highly
system dependent, and not all systems support it.)
So I started reading on the lxml website which clearly state lxml's dependencies on both libxml2 and libxslt, and unless they are statically linked, they also depend on iconv and zlib. So you're lead to believe you need to install all of these. Don't! Continue reading. But if you're going to build from sources (as easy_install may try to do) you'll need everything, including the development header libraries: libxml2-devel, libxslt-devel. Another place states that you also need Cython and install with:
easy_install lxml==dev
The dependencies are shown in this picture from HERE:
So you think you may get away with something like:
STATIC_DEPS=true pip install lxml
But that doesn't do it either. Probably because the libraries used to compile Cygwin's Python have to be the same as those for compiling lxml. But I don't know. Notice how the lxml package refers to Cygwin "1.7.24". My Cygwin is already "1.7.25" and you can check this with uname -a. Then you can check your static python executable with file and ldd. Then you understand that this also depend on the C-compiler used for building python/cygwin under Windows or *nix. Smelling a nightmare I decided that building my own was not the way to go. So next I tried to install the Python libraries (supplied as
executables) meant for Windows Python. This didn't work since I never had windows native Python installed, and I was greeted with an error that the installed could not find Python in my registry. I could of course just extract the executable, but I wouldn't know where to put the binaries without the installer. So I had another idea...
There are 3 possible solutions to getting this to work, as far as I can see.
The easy way of installing a Windows native Python interpreter. You loose some native Cygwin functionality, unless you install in correct place: /usr/lib/python2.7 and make sure Cygwin can find it and use it. This also uses a different file-permissions, case-sensitivity and character set (UTF-16LE) than Cygwin (UTF-8), potentially creating many other issues down the line! Difficulty: Easy
Continue hacking the Cygwin's Python, to make it work with the binary libraries used in (1). But this requires:
a) Uninstall and remove all Cygwin Python packages, except bare Python interpreter.
b) Remove all PIP and easy install traces.
c) Hacking the Windows registry to pretend to have Python27 installed:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath C:\Python27\
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk
HKEY_CLASSES_ROOT...
d) Install the Windows binary libraries.
e) All the rest should now hopefully work with PIP or easy_install. Difficulty: Medium!
Doing it properly by compiling Python and all libraries from scratch. Difficulty: Hard!
I successfully did (1), but I still think (2) is the smarter way of doing it, but I have not tested it, which is why I don't consider this as a good answer. BTW. One more quirk, I have to run the interpreter with: python.exe -E to avoid an annoying: "SyntaxError: invalid syntax" when hitting return!
Conclusion:
Apparently, you don't need the libxml2 and libxslt python packages to use lxml!
In my case I needed Scrapy, so I also had to install a few other packages.
$ pip.exe list
cssselect (0.9.1)
lxml (3.2.4)
pip (1.4.1)
pyOpenSSL (0.11)
pywin32 (218)
queuelib (1.1.1)
Scrapy (0.20.0)
setuptools (1.4.1)
six (1.4.1)
Twisted (13.2.0)
w3lib (1.5)
zope.interface (4.0.5)
$ll /cygdrive/c/Python27/Lib/site-packages/
adodbapi
cssselect
isapi
lxml
OpenSSL
pip
pythonwin
pywin32_system32
queuelib
scrapy
twisted
w3lib
win32
win32com
win32comext
zope
cssselect-0.9.1-py2.7.egg-info
lxml-3.2.4-py2.7.egg-info
pip-1.4.1-py2.7.egg-info
queuelib-1.1.1-py2.7.egg-info
Scrapy-0.20.0-py2.7.egg-info
six-1.4.1-py2.7.egg-info
Twisted-13.2.0-py2.7.egg-info
w3lib-1.5-py2.7.egg-info
zope.interface-4.0.5-py2.7.egg-info
PyWin32.chm
setuptools-1.4.1-py2.7.egg
pyOpenSSL-0.11-py2.7.egg-info
pywin32-218-py2.7.egg-info
easy-install.pth
pywin32.pth
setuptools.pth
zope.interface-4.0.5-py2.7-nspkg.pth
pythoncom.py
six.py
pythoncom.pyc
six.pyc
pythoncom.pyo
pywin32.version.txt
README.txt
Useful References:
HERE
HERE
HERE HERE HERE HERE
HERE

Error when importing cx_Oracle module [Python]

I use Windows 7 64 bit and Oracle 10g. I have installed python-2.7.2.amd64 and cx_Oracle-5.1-10g.win-amd64-py2.7.
When I importing cx_Oracle module I get this error:
Traceback (most recent call last):
File "C:\Osebno\test.py", line 1, in
import cx_oracle
ImportError: No module named cx_oracle
Can someone please tell me what is wrong?

Have you tried import cx_Oracle (upper-case O) instead of import cx_oracle?

I had this same issue under Windows.
I used Dependency Walker to open up the cx_Oracle.pyd file in C:\Python\Libs\site-libraries\ and reviewed the findings that dependency walker gave.
Dependency Walker showed me that in this case I had the x86 version of Python 2.7.2 installed and x64 version of the Oracle client & client DLL (oci.dll) and was trying to use the x64 version of the cx_Oracle module. With that knowledge I installed Python 2.7.2 x86_64 for Windows and everything was right as rain.
The alternative was to install the x86 version of the Oracle client & cx_Oracle which is much more of a PITA than installing a new Python interpreter.
Also, as this was news to me, you must have the Oracle client installed as well as it provides the 'OCI.dll' client library that cx_Oracle uses. It's located here: Oracle Client Installer Windows x64. Probably helps if one reads the documentation. ;)
Either way, Dependency walker could give you a big clue as to what your issue is if you're having import errors. Unfortunately on-import error messages can be quite ambiguous. I received the same error you referenced and number of other less than specific errors as well.

after installing the cx_Oracle download the instant client form oracle owth all DLLs , then copy then in the same directory of cx_Oracle.pyd , it will work directly
tried and worked for me.

It's not finding the module.
Things to investigate: Do you have several python installations? Did it go to the right one? Do a global search for cx_oracle and see if it's in the correct place. Check your PYTHONPATH variable. Check Python's registry values HKLM\Software\Python\Pyhoncore. Are they correct?

See this answer: https://stackoverflow.com/a/19552263/496289
ignore this.... making up other 17 bytes that're needed to make this post long enough...