Welcome to the Vancouver technology entrepreneurship scene

Posted by Jim DeLaHunt on 30 Nov 2017 | Tagged as: British Columbia, Vancouver, meetings and conferences

Welcome to Vancouver, B.C. You want to get involved in the entrepreneurial technology startup “scene” here? That is wonderful. Here is my current list of activities and organisations that form good entry points into the entrepreneurship community in Vancouver. Check them out. Participate in what interests you. Ask at these events for further suggestions. Enjoy!

Note that I am not an authority on the totality of entrepreneurship in this area. I am just an ordinary participant. This is my worm’s-eye view. It’s probably incomplete. Perhaps others will post in the comments the wonderful events and orgs that I missed. But this at least will get you started. Continue Reading »

When I run “ffmpeg” in the background, how do I prevent “suspended (tty output)”?

Posted by Jim DeLaHunt on 04 Nov 2017 | Tagged as: robobait, software engineering

I recently had a problem, “When I run ffmpeg in the background, how do I prevent suspended (tty output)?”. I solved it. Here is my solution, in the hopes that it will help others seeing the same problem.

I have a sh script which calls ffmpeg on several files. When I try to run this script in the background, redirecting output to a file, the job starts but then immediately suspends:

% bin/mp3convert.sh path/a/b &> ~/tmp/log.txt &
[1] 93352
% [1]  + suspended (tty output)  bin/mp3convert.sh path/a/b &>

Continue Reading »

Universal Acceptance of non-Latin email addresses and domain names: how does your framework rate? (IUC41 presentation)

Posted by Jim DeLaHunt on 31 Oct 2017 | Tagged as: Unicode, i18n, meetings and conferences, multilingual, web technology

One of my treats each year is to attend the Internationalization and Unicode Conference. This year was the 41st conference, or IUC41.  As I often do, I made a presentation. This year, the title was, Universal Acceptance of non-Latin email addresses and domain names: how does your framework rate? I’d like to share my slides. Continue Reading »

CD storage and the 25cm x 15cm box

Posted by Jim DeLaHunt on 30 Sep 2017 | Tagged as: culture, music, robobait

I guess I’m exactly the right age to have this problem: hundreds of liner notes from CD albums, stripped from their jewel cases and also CD boxed-sets and many different CD gatefold cases. If I were any younger, I’d be subscribing to some music streaming service, or downloading pirated albums as MP3 files. If I were any older, I’d be building elaborate shelf units to store the hundreds of intact jewel cases, and keeping a multi-disc CD player running to play the music.  But here I am, old enough to buy CDs as a way to pay the artists for their work, but young enough to want to rip the CDs into music files, upload them to a file server, and play them via computer or from my smartphone.

All of this leaves me with a problem: having put the ripped CDs onto nice compact 100-disc spindles, where do I put the liner notes and booklets so that I have access to them if I want ?  I can throw out the regular or the 2-disc jewel cases, because those are generic. But the artwork is indispensable.  On the other hand, I don’t need to keep it out on a open shelf to browse. It’s fine for me to put it away, and retrieve it only when I need it.  And now I am happy to report a solution: a box, of just the right size to hold liner notes or CD box-sets or gatefold cases efficiently, easily available from shipping materials suppliers, and very affordably priced. I post this in the hopes of helping some else who is trying to solve the same problem. Continue Reading »

Communications for the Canadian Paragliding Nationals, 2017

Posted by Jim DeLaHunt on 31 Jul 2017 | Tagged as: Paragliding, aviation

I have just returned from the Canadian Paragliding Nationals of 2017, held this past week in Pemberton, B.C. Organised by Guy Herrington of Sea to Sky Paragliding, the event went very well. My role was to organise VHF radio communications for the event. Some other time I want to tell the backstory of how we chose commercial VHF frequencies over amateur radio frequencies for the comp. But here, I wish to lay out the range of communications tools we used. This forms a record, and may be a useful reference for others planning free flight competitions. Continue Reading »

The Radiogram Game

Posted by Jim DeLaHunt on 30 Jun 2017 | Tagged as: Vancouver, community, radio

This is a description of the Radiogram Game, a skill-building activity for amateur radio emergency preparedness groups to conduct on their radio nets.

Many amateur radio operators love us our emergency preparedness. The Canda-based Radio Association of Canada (RAC) has an Amateur Radio Emergency Service (ARES) activity. The US-based Amateur Radio Relay League (ARRL) has an entire National Traffic System™, a structure of procedures and organisations and schedules and routings. I personally am a member of VECTOR, a amateur radio group affiliated with the city of Vancouver, B.C.. VECTOR operates a weekly radio net. It operates according to formal radio procedures of the sort we would use in an disaster, so just checking in following the right procedure is good training. But the organisation is looking for more ways to train its members. Anytime you can turn training into a game, it makes people more eager to participate. The Radiogram game is a skill-building activity disguised as a fun game.

A radiogram is a structure for short messages, designed to be sent by amateur radio volunteers during a disaster, when other communication links are down. Knowing how to hear a radiogram message over the air, and transcribe it correctly, and use the right forms and handling instructions, is a useful skill for the emergency preparedness volunteer. The ARRL’s National Traffic System publishes a radiogram form (fillable PDF, 2-up letter size, 71kB). (There is also a simpler but bulkier 1-up radiogram form; PDF, 442kB). See the NTS’s manual for instructions on how to use it as part of the NTS, especially in chapter 1, The ARRL Message Format, of the NTS Methods and Practices Guidlines.

Here’s how the game works.

The club announces the game to its members in advance. At the radio net on such and such a date, a radiogram will be sent. Any member of the club is encouraged to transcribe the radiogram, and submit it back to the club for points. Draw up a scoring list: so many points for transcribing the message, with deductions for errors; so many points for correct routing information; so many points for submitting it in person at the next club meeting, and so on.  See below for a possible scoring list. It helps to award points for both fun and amusing activities as part of the scoring; maybe you want to award points for the best dramatic reading of the radiogram at the next club meeting.  Designate the proper way to turn in completed radiograms (in person?  by email?). Don’t forget to designate the deadline.

The club picks someone to be the radiogram author and reader. The challenge for the author is to make the message concise but interesting and amusing. Maybe embed a joke or puzzle in the message. Maybe have the message parody local events.  The goal is both to help the participant learn a bit more about radiogram use, and reward them with a chuckle.

It might be nice for the club to clear with the operator of the radio net that the radiogram game will be played, so that they aren’t surprised by it!

During the radionet, at the appointed stage in the proceedings, Net Control turns the frequency over to the game’s reader. The reader sends the radiogram using correct methods and practices, getting the listeners accustomed to hearing radiogram delivery in its full glory. Listeners who care to participate by transcribing the message, and submitting it as directed. The reader reminds listeners of what those directions are, and what is the deadline for submission.

The ringleader for the radiogram game collects the submitted radiograms, and awards points.  The winner can be announced at the next club meeting. All participants should be thanked for taking part, and given their score. Personally I think they should be notified by email even if they aren’t at the meeting in person. This interaction is also a great time for a more experienced member to coach the participant on how well they did, and to answer questions. The interaction then also becomes a touch point which builds relationships within the club.

The game will be more effective with repetition over time. At first, many people won’t hear about the game in advance. They won’t be prepared. They won’t know what to make of it. But over time, especially if it sounds fun, more and more people should take part.

Here’s a sample message: TWO HAMS MARRIED X COMBINED THEIR ANTENNAS X CEREMONY WASNT MUCH BUT RECEPTION WAS SPECTACULAR . Sure, it’s a lame joke. But it fits in the radiogram form, and will give people a chuckle.

Here’s a sample scoring list:

Message body: 50 points if fully correct, 1 point off for each wrong word.

Handling: total 10 points, 5 points if handling information fully correct. 5 points for the receiving station’s information.

Procedures: 20 points for recording message on an ARRL Radiogram form (printed from ARRL web site OK). 10 points for writing it legibly on any other medium. (The point being to make people familiar with the radiogram form.)
Delivery: 10 points for submitting message by correct method, on time.  6 points if method is nearly correct, or missed deadline by less than 72 hours.

Having fun with it: 10 points for best dramatic reading of the radiogram at the next club meeting. 5 points for others who try the dramatic reading.

Total: 100 points.

Judges can award bonus points for any variation which makes the game more fun or more educational.

I have come up with a message for the radiogram game. I can’t wait to try it out on my club.  The above are the guidelines I came up with. I have no doubt that others will improve them. I wouldn’t be surprised to find I’ve reinvented something someone else has already done.  If you try this game, please comment below about how it went for you!

To my MP: vote in favour of Electoral Reform Committee report

Posted by Jim DeLaHunt on 31 May 2017 | Tagged as: Canada, Democratic Reform, government, politics

Today, 31. May, 2017, the Parliament of Canada held a vote which was last hope for national electoral reform for now. The vote was formally to “concur in” the report of the Special Committee on Electoral Reform (ERRE). A Yes vote would have meant that Parliament supported the ERRE recommendations, which included proportional representation (PR) in national elections.

As it turns out, that vote went against electoral reform: Yeas 146, Nays 159. I don’t yet know how my MP voted. I expect that the Parliamentary records will make it clear on 1. June or shortly after.

But, for the record, here is what I wrote to my MP, Dr Hedy Fry:

Continue Reading »

Labour, symbols, and free: the gate to digital-based music-making

Posted by Jim DeLaHunt on 05 Apr 2017 | Tagged as: Keyboard Philharmonic, culture

(Background: I was asked recently for a writing sample, and I took the opportunity to restate, more concisely, what I’m trying to do with Keyboard Philharmonic.)

Musicians performing classical music and opera, and teachers and students of this music, are on the cusp of a transformation from printed music scores to digital scores. This will be as significant as the shift of text communication from printed books and magazines, to web articles, blogs, emails, and tweets.

I believe a particular model is the right next step. I call it, “Labour, symbols, and free”. It is a policy package for a music score transcription effort. It fills a gap in the present situation, and opens a gate to move forward. I will also describe the strategic context. Continue Reading »

Open Data Day 2017, Team Meta, and a Prize!

Posted by Jim DeLaHunt on 31 Mar 2017 | Tagged as: Vancouver, government, meetings and conferences, web technology

Open Data Day was celebrated here on Sunday, 4. March 2017. The Open Data Society of B.C. sponsored a buzzing, successful hackathon, with participants from several communities in the Lower Mainland, Vancouver Island, and even Washington State.

I plunged back into my continuing project for Vancouver Open Data Day, to make a language census of Vancouver’s Open Data Catalogue. You can check out our Team Meta #VODay hackathon report as submitted via github. I’ve summarised it below.  I was very pleased to be awarded the City of Vancouver Focus Challenge Prize for the work we accomplished that day. Continue Reading »

Python multi-line doctests, and “Got nothing” message

Posted by Jim DeLaHunt on 31 Jan 2017 | Tagged as: Python, robobait, software engineering

Recently I was writing a Python-language tool, and some of my doctests (text fixtures, within module comments) were failing. When I tried to import the StringIO module in my test, I got a quite annoying message, “Got nothing”, and the test didn’t work as I wanted. I asked StackOverflow. User wim there gave me a crucial insight, but didn’t explain the underlying cause of my problem. I read the doctest code, and came up with an explanation that satisfied me. I am posting it here, as an aid to others. The gist of the insight: What looks like a multi-line doctest fixture is in fact a succession of single-line doctest “Examples”, some which return no useful result but which set up state for later Examples. Each single-line Example should each have a >>> prefix, not a prefix. But, there are Examples that require the prefix. The difference lies in Python’s definition of an Interactive Statement.

The Question

I posted a question much like this to StackOverflow:

Why is importing a module breaking my doctest (Python 2.7)?

I tried to use a StringIO instance in a doctest in my class, in a Python 2.7 program. Instead of getting any output from the test, I get a response, “Got nothing”.

This simplified test case demonstrates the error:

#!/usr/bin/env python2.7
# encoding: utf-8

class Dummy(object):
    ”’Dummy: demonstrates a doctest problem
    >>> from StringIO import StringIO
    … s = StringIO()
    … print(”s is created”)
    s is created

if __name__ == “__main__”:
    import doctest

Expected behaviour: test passes.

Observed behaviour: test fails, with output like this:

% ./src/doctest_fail.py
File "./src/doctest_fail.py", line 7, in __main__.Dummy
Failed example:
    from StringIO import StringIO
    s = StringIO()
    print(”s is created”)
    s is created
Got nothing
1 items had failures:
    1 of 1 in __main__.Dummy
***Test Failed*** 1 failures.

Why is this doctest failing? What change to I need to make in order to be able to use StringIO-like functionality (a literal string with a file interface) in my doctests?

(I had originally suspected the StringIO module of being part of the problem. My original question title was, “Why is use of StringIO breaking my doctest (Python 2.7)”. When I realised that suspicion was incorrect, I edited the question on StackOverflow.)

The Answer

StackOverflow expert wim was quick with the crucial insight: “It’s the continuation line syntax () that is confusing doctest parser.” Wim then rewrote my example so that it functioned correctly. Excellent!  Thank you, wim.

The Explanation

I wasn’t satisfied, however. I know from  didn’t explain the underlying cause of my problem. I read the doctest code, and came up with an explanation that satisfied me. Below is an improved version of the answer I posted to StackOverflow at the time.

The example fails, because it uses the PS2 syntax (...) instead of PS1 syntax (>>>) in front of separate simple statements.

Change ... to >>>:

#!/usr/bin/env python2.7
# encoding: utf-8

class Dummy(object):
    ”’Dummy: demonstrates a doctest problem
    >>> from StringIO import StringIO
    >>> s = StringIO()
    >>> print(”s is created”)
    s is created

if __name__ == “__main__”:
    import doctest

Now the corrected example, renamed doctest_pass.py, runs with no errors. It produces no output, meaning that all tests pass:

% ./src/doctest_pass.py

Why is the >>> syntax correct? The Python Library Reference for doctest, How are Docstring Examples Recognized? should be the place to find the answer, but it isn’t terribly clear about this syntax.

Doctest scans through a docstring, looking for “Examples”. Where it sees the PS1 string >>>, it takes everything from there to the end of the line as an Example. It also appends any following lines which begin with the PS2 string ... to the Example (See: _EXAMPLE_RE in class doctest.DocTestParser, lines 584-595). It takes the subsequent lines, until the next blank line or line starting with the PS1 string, as the Wanted Output.

Doctest compiles each Example as a Python “interactive statement”, using the compile() built-in function in an exec statement (See: doctest.DocTestRunner.__run(), lines 1314-1315).

An “interactive statement” is a statement list ending with a newline, or a Compound Statement. A compound statement, e.g. an if or try statement, “in general, […spans] multiple lines, although in simple incarnations a whole compound statement may be contained in one line.” Here is a multi-line compound statement:

if 1 > 0:
    print(”As expected”)
    print(”Should not happen”)

A statement list is one or more simple statements on a single line, separated by semicolons.

from StringIO import StringIO
s = StringIO(); print("s is created")

So, the question’s doctest failed because it contained one Example with three simple statements, and no semicolon separators. Changing the PS2 strings to PS1 strings succeeds, because it turns the docstring into a sequence of three Examples, each with one simple statement. Although these three lines work together to set up one test of one piece of functionality, they are not a single test fixture. They are three tests, two of which set up state but do not really test the main functionality.

By the way, you can see the number of Examples which doctest recognises by using the -v flag. Note that it says, “3 tests in __main__.Dummy“. One might think of the three lines as one test unit, but doctest sees three Examples. The first two Examples have no expected output. When the Example executes and generates no output, that counts as a “pass”.

% ./src/doctest_pass.py -v
    from StringIO import StringIO
Expecting nothing
    s = StringIO()
Expecting nothing
    print(”s is created”)
    s is created
1 items had no tests:
1 items passed all tests:
    3 tests in __main__.Dummy
3 tests in 2 items.
3 passed and 0 failed.
Test passed.

Within a single docstring, the Examples are executed in sequence. State changes from each Example are preserved for the following Examples in the same docstring. Thus the import statement defines a module name, the s = assignment statement uses that module name and defines a variable name, and so on. The doctest documentation, What’s the Execution Context?, obliquely discloses this when it says, “examples can freely use … names defined earlier in the docstring being run.”

The preceding sentence in that section, “each time doctest finds a docstring to test, it uses a shallow copy of M’s globals, so that … one test in M can’t leave behind crumbs that accidentally allow another test to work”, is a bit misleading. It is true that one test in M can’t affect a test in a different docstring. However, within a single docstring, an earlier test will certainly leave behind crumbs, which might well affect later tests.

But there is an example doctest, in the Python Library Reference for doctest, How are Docstring Examples Recognized?, which uses ... syntax. Why doesn’t it use >>> syntax? Because that example consists of an if statement, which is a compound statement on multiple lines. As such, its second and subsequent lines are marked with the PS2 strings.  It’s unfortunate that this is the only example of a multi-line fixture in the documentation, because it can be misleading about when to use PS1 instead of PS2 strings.

« Prev - Next »