Friday, November 14. 2008
I recently had the task of building Python Eggs on Windows that had C extensions. I did the usual googling, and found a few HOWTOs, but nothing I could find was very concise and straightforward. So, I present to you a very concise, very straightforward guide.
Setting up the Build Environment
We are assuming all installers are allowed to install to their default locations.
Download and install Python 2.5 and/or Python 2.4 from python.org. You may have to use Python 2.4.4 since that was the latest 2.4 series to have an installer at time of writing. Whichever you want associated with .py files, install last.
Download and install SetupTools for Python (both 2.4 and 2.5) here.
MingW files are here. Download and run the latest version of "Automated MinGW Installer." You only need to install g++, and maybe not even that. When it prompts you for old/current/preview version of the MinGW system, select current.
Download and run the current version of "MSYS Base System."
Open up the MinGW shell, and execute these commands:
cd / mkdir mingw mkdir code #Convenience, if you want to mount your code's dir at an "easy" spot echo "c:/MinGW /mingw c:/path/to/code /code" > /etc/fstab
Create the file c:\PythonNN\Lib\distutils\distutils.cfg and put the following in it, where NN is replaced with 24 or 25, depending on version::
[build]
compiler = mingw32
Do this for each version installed.
Building the Eggs
MinGW mounts your drives on the root directory, so your C: drive will be at /c, D: drive at /d, and so on. Open up a MinGW shell, and:
cd /code # or /c/path/to/code, if you didn't mount /code # Depending on which package you're building, you'll either use setup.py # or extended_setup.py. I'm using setup.py here as a placeholder. Replace as appropriate. # Python 2.4: /c/python24/python setup.py build_static # if needed /c/python24/python setup.py bdist_egg
# Python 2.5: /c/python25/python setup.py build_static # if needed /c/python25/python setup.py bdist_egg
You'll now have eggs for your architecture and OS. Enjoy!
Wednesday, November 12. 2008
It's amazing the things that can cause a lump in your throat. Say, for instance, your computer not booting.
Tonight I was trouble-shooting a trackball I thought to be dead, and I went to plug it in to a USB port on the front of my work computer. I had not properly grounded myself first, and this being Alaska in the winter, and me wearing sweats, and my chair's cushions being very much made out of polyester, I had acquired quite the static potential.
As soon as the trackball's USB plug contacted the metal around the computer's USB port, there was a nice "pop" and the power on the computer dropped hard. No graceful shutdown, just went black.
Oops. So I pressed the power button. The fans started, but nothing else. Shut it off, tried again. Still nothing after a couple more attempts. Now, I'm a little nervous for a few reasons: 1) This is my work computer 2) The computer is on loan; 3) I have no spare; 4) I just started a new job three days prior and calling in with a sick computer the next day was not going to look good.
So after a little consternation, and some prayer (this is my livelihood we're talking about after all), I remembered a little peculiarity I'd run into in the past. Computers, being electronic devices, often contain capacitors, whether those capacitors be in the power supply, or on the motherboard. Since most computers these days never truly turn off (it's a "soft" power switch) those capacitors might not fully drain. Somehow, in certain situations, the system gets "wedged" due to various reasons (a static discharge, for instance).
So, the fix was thus: 1) unplug computer, 2) hold down power button for a while (I did a minute, I think I've heard 30 seconds will work). This drains the capacitors fully. 3) Plug computer back in and press the power button. It's Aliiiiiive! And working fine.
That's enough excitement for the night, thanks!
P.S. Anyone care to enlighten me as to why the capacitor drain trick works?
UPDATE: Some interesting discussion of this on Reddit
Note to xzxzzx: Sorry that you couldn't link. I thought I had those enabled.
Sunday, November 9. 2008
After being out of full-time work for 17 business days, I'm starting up a full time job! I'm going to be doing, as I have been for the past 2.5 years, programming and system administration. My title is still in flux, but my duties will be a combination of two jobs I applied for with this company, which were "Linux Web Application Server Architect" and "Python/Adobe Flex Programmer." For the first couple months (or less) I'm basically on as a contractor. Then, if we like each other, we'll negotiate for a full-time hire.
The company in question is called WordStream, "a venture-backed startup engaged in providing search engine marketing software solutions for PPC/SEM [pay-per-click/search engine marketing] and SEO [search engine optimization]," among other things. Basically, they help advertisers get the best deal and exposure for their dollar.
They do have a product they've released, but they're still very much in startup mode, so I'm sure it will be fast and furious. Not quite the low-key environment I was used to with S&K Aerospace. Financially, they're quite sound, having recently landed USD4 million in Series A funding from Sigma Partners, a very strong and stable venture capitalist group which currently has over USD2 billion under management.
So, off we go. Sounds like it's going to be lots of fun!
Oh, yes, I'll still be working from home. No relocation required.
Wednesday, November 5. 2008
Cilk Arts is very close to releasing their multi-core programming library called Cilk++, and with it, a new license, the Cilk Arts Public License. Using this license, they attempt to close the "IDO [Internal Development Organizations] loophole" they believe exists with the current GPL. Namely: an organization can take a piece of GPL code, create a derivative work, and, if they do not distribute it outside their organization, they do not have to give it back to the community.
Cilk Arts' new license seeks to prevent this, basically, be redefining "distribution" to mean within the company as well:
If you are an IDO building applications for use by others but not "distributed" under the existing open source definitions (e.g., GPL) and you want to keep your Cilk++-based derivative work proprietary, then there is an impact. The CAPL requires you to make a fair exchange in order to use Cilk++. If you share your software with everyone, we share ours with you. If you do not wish to share, you can give back to the project by purchasing a commercial license.
I believe,that while a laudable goal, this will at best be ineffective, and at worst, stymie, or at least slow, the adoption of Cilk++; and yes, I have reasons.
There are, at least, three types of Open Source consumers:
- Those who have full intention to give back
- Those who have no intention to give back, and don't, despite the legal obligation to do so. See the archives of GPL Violations for plenty of examples.
- Those who don't initially have an intention to give back, but after using the library, decide that they'd like to, or can, give back.
The first two types of consumers will not be affected by this license. The givers will give, and the keepers will keep. It is the third type of consumer where Cilk++ will lose out: the "potential givers" (PG) category.
When a PG is evaluating various libraries to use for their new multi-core program, their license and distribution model (even internally) may be in doubt. They may even have a (wrong headed) policy about giving back to open source programs. Thus, when they see "you can't distribute derivative works (even internally)" it may completely turn them off, and they'll go on to the next library. Which would be sad; I've not personally reviewed Cilk++, but as it is coming out of an MIT project, I would assume it to be created by some rather bright people. So, the PG will completely pass over the chance to use this library without any further evaluation. Cilk++ will lose in this case. If the PG would have decided not to give back, Cilk++ would have not lost or gained either way. However, if the PG would have decided to give back down the line (say, enough internal rumbling by developers, or management changing policy), then Cilk++ will have gained a contributor. But, because they say off the top that you have to give back, they will have lost everybody in the "potential giver" category. In addition, they may also lose out on a possible license sale by those who want to try the library, and then end up buying a commercial license because they wish to distribute their application as closed-source.
So, my feedback to Cilk Arts is: go with the standard GPL (or even BSD license). Those who want to give back will, those who don't, won't, and those who might will give you a try and possibly become a contributor (with code or money) when they might not have otherwise.
Your thoughts?
|