EsoErik

Friday, August 29, 2014

 

Running All Of IPython in a Python Debugger

IPython: A tremendously awesome thing that Microsoft supports as a result of some kind of bizarre error or oversight.  I reluctantly pin an award on Microsoft whilest fixing them with intense stink eye and mumbling about war crimes.  "Ok folks, let's give these baby killers a round of applause, they've... uhhhh... wow, this is strange.  They.  Have.  Earned.  It... [2 seconds pass] Alright, that's enough clapping.  Anyone still clapping will be assisted toward more peaceful and citizenly conduct by the Ferguson Police Dept.  Thank you." *drops microphone, ear splitting feedback ensues amidst crackling gunfire and screams*  But, I digress...

IPython: How do I attach a god damned debugger to this thing?  I typically launch it by pressing up in my console three hundred times until I arrive at "ipython", then I press enter.  But this pydbg.py thing accepts a Python script name as a parameter?  And "file `which ipython`" reveals that it's an sh script and not a Python script, so this is never going to work?

Yes, and maybe, depending on how evil the ipython package maintainer for your platform happens to be.  If your package maintainer is a good guy, your IPython launcher script is implemented in Python and looks like this:

#!/usr/bin/python3
# This script was automatically generated by setup.py
if __name__ == '__main__':
    from IPython import start_ipython
    start_ipython()


If it doesn't, paste the above into a something like ~/start_ipython.py.  Then, you can launch IPython in debugger, for example, like so:

python ~/slickedit/resource/tools/pydbgp-1.1.0-1/bin/py3_dbgp.py -d 127.0.0.1:12345 -k slickedit ~/start_ipython.py

Alright, that's it.  Anyone still here thirty seconds ago is trespassing in their own homes and will be gassed, truncheoned, tazered, and shot by the Ferguson Police Dept in "botched" late-night no-knock wrong-address warrantless drug raids that certainly do not represent retaliation of any kind.

Wednesday, August 20, 2014

 

The Dread Error: Error, Distutils Is Too Stupid, Get Another Distutils

You are using Microsoft Visual Studio [inconsistent year/version number/random text string] Gold Ultimate Gentleman's Club With Oak Clusters And Diamonds Edition TEAM ENTERPRISE Edition Edition of the very latest vintage.

Everything is great, save for the user interface, which has adopted the inexplicable metro design language and looks like a piece of trash as a result (the next version will be nothing but a two-toned ribbon bar, if the trend holds).  Also, no Python modules with C components will build:

C:\Users\zplab\Desktop\pyzmq_git>python setup.py build
running build
running build_py
running build_ext
running configure
************************************************
Using bundled libzmq
already have bundled\zeromq
already have platform.hpp
************************************************
building 'zmq.libzmq' extension
error: Unable to find vcvarsall.bat


Uh-huh?  So, I'm looking at that file.  I can see this vcvarsall.bat file.  I'm seeing it, right now.  Why is this god-forsaken piece of trash setup.py garbage pile detritus fucking MOUNTAIN OF SHIT not seeing it?

Because it's looking in a dumb-ass, wrong-ass place.  An excerpt starting at 169 of python/Lib/distutils/msvc9compiler.py:

def get_build_version():
    """Return the version of MSVC that was used to build Python.

    For Python 2.3 and up, the version number is included in
    sys.version.  For earlier versions, assume the compiler is MSVC 6.
    """
    prefix = "MSC v."
    i = sys.version.find(prefix)
    if i == -1:
        return 6
    i = i + len(prefix)
    s, rest = sys.version[i:].split(" ", 1)
    majorVersion = int(s[:-2]) - 6
    minorVersion = int(s[2:3]) / 10.0
    # I don't think paths are affected by minor version in version 6
    if majorVersion == 6:
        minorVersion = 0
    if majorVersion >= 6:
        return majorVersion + minorVersion
    # else we don't know what version of the compiler this is
    return None


This is starting to make sense.  On Windows, distutils wants to build Python extensions with the same compiler that was used to build Python.  I used to have lots of old versions of Visual Blah-dee-blah installed, and building Python extensions always worked when I did.

There are surely some good arguments for building Python extensions with the exact same build # compiler and Microsoft Crappy Runtimes that were used to build the interpreter itself.

Take those arguments, and drop them in the ocean.  It works just fine once you work past this fastidious insistence upon a specific Visual Shitbucket edition.

 def get_build_version():
    """Return the version of MSVC that was used to build Python.

    For Python 2.3 and up, the version number is included in
    sys.version.  For earlier versions, assume the compiler is MSVC 6.
    """
#   prefix = "MSC v."
#   i = sys.version.find(prefix)
#   if i == -1:
#       return 6
#   i = i + len(prefix)
#   s, rest = sys.version[i:].split(" ", 1)
#   majorVersion = int(s[:-2]) - 6
#   minorVersion = int(s[2:3]) / 10.0
#   # I don't think paths are affected by minor version in version 6
#   if majorVersion == 6:
#       minorVersion = 0
#   if majorVersion >= 6:
#       return majorVersion + minorVersion
#   # else we don't know what version of the compiler this is
#   return None
    # All the above is bullshit.  This system has Visual Studio 2013 aka 12.0 and that's all there is to it.
    return 12


Now we can build:

C:\Users\zplab\Desktop\pyzmq_git>python setup.py build
running build
running build_py
running build_ext
running configure
************************************************
Using bundled libzmq
already have bundled\zeromq
already have platform.hpp
************************************************
building 'zmq.libzmq' extension
creating build\temp.win-amd64-3.4
creating build\temp.win-amd64-3.4\Release
creating build\temp.win-amd64-3.4\Release\buildutils
creating build\temp.win-amd64-3.4\Release\bundled
creating build\temp.win-amd64-3.4\Release\bundled\zeromq
creating build\temp.win-amd64-3.4\Release\bundled\zeromq\src
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\amd64\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -DFD_SETSIZE=1024 -DDLL_EXPORT=1 -Ibundled\zeromq\include -IC:\Python34\incl
ude -IC:\Python34\include /Tcbuildutils\initlibzmq.c /Fobuild\temp.win-amd64-3.4\Release\buildutils\initlibzmq.obj /EHsc
initlibzmq.c

Archives

July 2009   August 2009   September 2009   October 2009   November 2009   December 2009   January 2010   September 2010   December 2010   January 2011   February 2011   April 2011   June 2011   August 2011   February 2012   June 2012   July 2012   August 2012   October 2012   November 2012   January 2014   April 2014   June 2014   August 2014   September 2014   October 2014   January 2015   March 2015   April 2015   June 2015   November 2015   December 2015   January 2016   June 2016   August 2016   January 2017   March 2017  

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]