I recently started a love affair with the Sublime Text 2 text editor. Looking around the web, I’m certainly not alone, and there are many great tips and tricks posts. I probably can’t write anything better than what’s already out there, so this post is really just an attempt to document for my future self my own customization decisions and the logic behind my choices.
After remembering it yet again last night, I decided enough was enough, filed the roughest edges off of it, and posted it:
It is very unlikely that I will be an admin for a TestLink install again for a while. This post is intended to put a period on my involvement in TestLink.
There are not many good examples floating around of Perl clients for TestLink’s XMLRPC API. There are two examples included with the 1.9.3 source, but they are very brief. I wrote two scripts to support a first-blush attempt at automated test running, and while they will get a lot more refinement over time, I thought abstracted versions of them might be beneficial for others trying to write Perl clients (or in any language – they perl samples were so sparse I largely based my script on the python example).
It’s bugged me for a while that my WordPress posts would often have an extra space at the beginning of a line. It would only happen when it was a new sentence, and after a while I realized it was related to my habit of typing two spaces after a period.
I have finally come to terms with the TestLink API and have bashed out an automated test runner written in perl (which I hope to clean up and post in the next few days, there don’t seem to be many (or any) examples of this in the wild).
After getting nightly automated testing running, I wanted a very simple script which would, for each test case in a given test plan, compare the last and the second to last result and print a warning if they were different. Long term I will have better automated reporting, but our test script library is still so new that it’s not really news that a lot of them are failing. What would be news is if a specific test case passed two nights ago but failed last night.
I had to debug an expect script that would not run in a specific environment today, and the solution was so frustrating that I had to write it down.
In short, expect’s [exec] functionality requires SIGCHLD to be functional to work correctly. If you have ignored the signal, you get a very nice explanation of why your script has just died. For instance:
Update 2018-11-06: If you came here because of the announcement about version 20181104.0, the wrong URL was used in the announcement. The correct location for the new release is https://www.jetmore.org/john/blog/2018/11/swaks-release-20181104-0-available/
A new version of swaks is currently available for download.
- Project Page: http://jetmore.org/john/code/swaks/
- v20120320.0 distribution: http://jetmore.org/john/code/swaks/swaks-20120320.0.tar.gz
- v20120320.0 script only: http://jetmore.org/john/code/swaks/swaks-20120320.0/swaks
- v20120320.0 reference: http://jetmore.org/john/code/swaks/swaks-20120320.0/doc/ref.txt
- v20120320.0 changelog: http://jetmore.org/john/code/swaks/swaks-20120320.0/doc/Changes.txt
Some day I hope to do something with hardware worth writing about in its own right. For now though I am stuck documenting the absurdity of my learning experiences.
I can’t include code in this post because I don’t own it, but I think I can discuss the concept, which I found really interesting.
A coworker had the idea to extend the PDO
prepare() method to aid in debugging. I’m not sure if he implemented something he found on the net or it was an original idea, but I really like the results. It prepends, to every query executed, an SQL comment (ala “
/* comment */“) including the username of the logged in user and the URL of the current request. This usually makes no difference, but if you’re in a really tough spot in debugging you can turn on mysql general_log, run the session that is having problems, and easily see every query that the was executed on behalf of the user having problems.