I follow Carl Claunch's Rescue1130 blog. Besides enjoying the technology he writes about, I have admired his persistence in blogging daily, often 7 days a week. He has a full-time job that involves frequent travel, plus volunteer work at the Computer History Museum, and this absorbing hobby of restoring the 1130, yet he has been posting something every day.
Well, this week he has suddenly went silent. He posted Friday, but not Saturday or Sunday or... wait, that's it. Today is Monday. I found myself actually worried; is he well? Which is stupid, the man has probably just taken a weekend off (no doubt to the relief of his long-suffering family).
Then I realized with some guilt, that after a fair spell of posting most weekdays, I went silent. What about my loyal readers? Are they concerned for my health, or irked at my laziness? Blogging is a responsibility!
Right, so the most significant thing I've been doing the past week is contributing, in a clumsy and halting way, to the PyInstaller project. After a long period of relative quiescence, it suddenly sprang to vigorous life in the past month. Several contributors began posting issues and pull requests to fix their issues. The lead maintainer, Hartmut, became extremely active in response, commenting on the issues and pull requests, rejecting some, accepting others. Most importantly, he did the job of rebasing the dormant Python3 branch onto the current Develop head, so it picked up the maintenance it had missed.
So I tried to use it, and found several minor bugs which I fixed and got a complete working PPQT2 bundle for both Mac OS and for Ubuntu 14.10 (32-bit and 64-bit).
Then I put those fixes into a pull request, but it wasn't right, so Hartmut very patiently directed me in how to make it right, and after maybe three tries, it worked and those fixes are now in the official Python3 branch of PyInstaller, yay me.
Only bundling for Windows remains and I can announce an alpha version of PPQT2. The Windows bundle was a major hurdle for V1, mainly because PPQT requires the Hunspell spell checker. Unlike the other packages PPQT needs (regex, natsort, sortedcontainers) which are pure Python, pyhunspell is a Python-to-C++ wrapper over the API to the Hunspell library. Which means its main component is a C++ source that has to differ between Python2 and Python3, because the Python-to-C API changed between versions. There's a user-patch that supposedly does that; but it is not at all clear whether that patch applies to the current source. And then the source has to be compiled with MSVC at a particular level (2010, 64-bit) to match the level used to compile the official Python 3.4 release. I understand all these words but have zero experience doing anything like this.
What I did for V1 was to go on elance and hire it done. Money very well spent. And I'm doing exactly that again; I posted the elance job this morning and have one inquiry already. This time I will make sure that the updated code and the DLL get sent to the maintainer so others can use them.
When that's all wrapped up, hopefully by mid-week, I should be able to run PyInstaller on Windows 7 and get a clean bundle of PPQT2.
Meantime, I need to get to work on the remaining functionality. That means, for comfort and convenience, being able to code on my laptop. Much as I love my 27-inch iMac, I can't take it to a coffee shop. The laptop had fallen behind the desktop system in Qt and PyQt versions. So what else I've been doing this morning is installing Qt5.4.1, and the latest SIP, and PyQt5.4.1, on this laptop. The very lengthy PyQt make is chugging away as I write.
Last week the task of editing the V2 "suggested workflow" document brought me face to face with a flock of usage issues I had been postponing. My intent is that PPQT2 will be a front end that works smoothly with the "Ppgen" markup system that is becoming popular at the U.S. PGDP site, and with the "Fpgen" markup convention that is used by DP Canada. And that means looking ahead and asking myself, how do those markup systems handle things like block quotes, right-aligned strings, blocks of centered lines, and tables? Because I don't want to direct my users into doing things that would cause conflicts, if they decide to move to one of those markups. OTOH, I want to get the users to use a syntax that will be easy to code in the Translators that will convert to those markups -- or directly to ASCII or HTML, if they use the direct Translators I will provide.
That's been an interesting exercise and is not complete yet. It's kind of an annoying task for a couple of reasons. One is it forces me to deal with these systems that are accomplishing exactly the same damn results, but could they use any kind of standard markup to do it? Oh no of course not; they had to invent their own bloody markup language.
Another is that those markups are not superbly well documented. I was a professional technical writer and naturally have high standards for this. So I have to bind and gag my inner editor so I can just read the damn stuff and not waste time trying to rewrite it as I go.
No comments:
Post a Comment