Talking directly to in-process tcl/tk
I recently saw a post on a blog about using wish as a subprocess of Python, as a way to access tk without the complexity of tkinter.
To be clear the original post also calls out the situation where the tkinter part of python is not installed by default, and my technique would not be applicable there.
So what do you do if you like Tk but don't care for the high level abstraction provided by Tkinter? Well, you can import _tkinter and create a tkapp object with _tkinter.create().
The _tkinter module and the tkapp object is largely undocumented, but in Python 3.11 here are some useful methods:
- tkapp.createcommand: Create a callback into Python code. Takes a string and a callable. Creates a Tcl command with that name, that calls back into Python code: app.createcomand("cb", lambda *args: print("cb", args))
- tkapp.eval: Takes a command and evaluates it. Call it with a single string: app.eval("button .b -text HI -command {cb arg1 arg2}")
- tkapp.call: Takes a series of arguments, does proper Tcl quoting, and evaluates it: app.call("pack", ".b")
Python 3.11.2 (main, Aug 26 2024, 07:20:54) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _tkinter
>>> app = _tkinter.create()
>>> app.createcommand("cb", lambda *args: print("cb", args))
>>> app.eval("button .b -text HI -command {cb arg1 arg2}")
'.b'
>>> app.call("pack", ".b")
''
>>> # Now I click the button several times ...
>>> cb ('arg1', 'arg2')
cb ('arg1', 'arg2')
cb ('arg1', 'arg2')
DragonBoard™ 410c with rt-preempt failure
I was excited to obtain a DragonBoard, an affordable 64-bit ARM single-board computer, but unfortunately it hasn't lived up to my hopes.
First of all, it shipped with one terrible problem, making it useless for headless development: The onboard wireless doesn't receive multicast traffic, including ARP requests! And their kernel doesn't provide many modular drivers, so adding any old USB wireless dongle doesn't work until you rebuild the kernel. As of this writing, there is no useful workaround.
And that's when I hit the second show-stopper problem. I planned to build kernels for this thing anyway, because the goal is to run LinuxCNC on it with rt-preempt realtime. So I stuck in a large capacity micro-sd card, obtained the kernel source, built it, and rebooted with my new kernel.
(incidentally, testing kernels is a PITA. You have two choices: one, flash the one and only boot area with your new and untested kernel and hope for the best; two, tether to a PC (losing USB keyboard and mouse on the dragonboard!) and use fastboot every time you boot. ugh)
.. but the new kernel just didn't work. It scrolled kernel messages, but got stuck partway through booting. dmesg implicated the wireless card. This one at least has a workaround: cherry-pick a certain commit from their kernel git. As I understand it, this bug is triggered by using the compiler on the dragonboard, and not encountered with the linaro cross-compiler running on a traditional x86 desktop.
Anyway, having found out about this I was briefly celebratory. I booted with my own kernel and had a working USB dongle. Unfortunately, that celebration was short-lived. The USB dongle hasn't been terribly reliable either, particularly under high CPU load.
I soldiered on and patched the linaro 4.0 kernel with the 4.0-rt5 patchset. There were a few minor conflicts which I believe I resolved correctly. Unfortunately, the LinuxCNC latency-test readily encounters latencies above 15ms (15000us). LinuxCNC really would like sub-100us max latencies.
I briefly enabled tracers, and have traces that seem to implicate a variety of subsystems: networking, usb, and video *all* figure. More experienced developers than I will have to be the ones to sort out RT on 64-bit ARM.
Proven Delights (and what are proofs anyway)
I won a copy of the book Hacker's Delight from John Regehr for my entry in his nibble sort contest earlier this year.
In that thread I had heard about the CBMC Bounded Model Checking software, and it gave me the idea to combine the two: a project to take implementations of the algorithms from Hacker's Delight and prove the algorithms' properties with CBMC.
I have a modest start on github, which I am calling "Proven Delights":
Better pasting for irssi in X
While it's otherwise an excellent irc client, I've been frustrated by pasting in irssi. There are two main problems:
mailpie moves to github
My e-mail full text search software mailpie is now hosted at github: https://github.com/jepler/mailpie
SNTP from Python: getting server's esimate of time quality
Anders Wallin recently discussed generating graphs of server time error using a timestamp from the Date: header of an http request.
NTP servers themselves have estimates of time error, and it's possible to get the local server's idea of the error by sending SNTP packets to the local machine. You can also see the last time this NTP server successfully communicated with a peer or upstream, and see whether the server considers itself desynchronized by checking the stratum and leap second fields.
Based on my tinkering, the root_dispersion field or the derived LAMBDA value is the easiest to look at for estimating how bad the NTP time is. Between communications with a peer, root_dispersion and LAMBA increase at a rate of 15µs/s, ntp's arbitrary estimate of the accuracy of the local undisciplined clock. (YMMV and you can appaerntly tweak CLOCK_PHI in your NTP configuration file)
The attached program is a basic Python SNTP client which by default polls the local server every 5 seconds and prints some information. License: GPLv2+
Typical output:
12:25:58 0.06233 228.95875 ST-SYNCH LI-SYNCH 12:26:03 0.06241 233.96404 ST-SYNCH LI-SYNCH 12:26:08 0.06247 238.96745 ST-SYNCH LI-SYNCH 12:26:13 0.06255 243.97141 ST-SYNCH LI-SYNCH 12:26:18 0.06262 248.97673 ST-SYNCH LI-SYNCH 12:26:23 0.06270 253.98213 ST-SYNCH LI-SYNCH 12:26:28 0.06277 258.98746 ST-SYNCH LI-SYNCH
Files currently attached to this page:
| ntpsynch.py | 4.9kB |
GNU 30th—Celebrating 30 years
The GNU project and the Free Software movement are two of the most important computer-related things in my life. At $DAY_JOB we depend critically on many pieces of GNU software (such as gcc). This blog is hosted on a system with a GPL kernel and a GNU userspace, and the blog software itself is covered by the GPL license. My everyday computer is a GNU/Linux system, and my cellphone and tablet have GPL-licensed major components, such as the operating system kernel.
I personally have contributed thousands of unpaid hours developing GPL-licensed software, which is my way of repaying everyone else who has developed Free software.
On the other hand, we haven't come as far as one might wish. My everyday computer doesn't function as well without proprietary drivers, and many devices that should be general purpose computers don't ship in a mode that allows their owners to install the software of their choice. Careful choices are still necessary when buying hardware, particularly if you insist on an operating system that consists only of Free software.
Here's hoping that the next 30 years bring more gains for Free software and the GNU system. Either way, we'll still be here.
Debugging realtime components in UBC3
Here's how to run the debugger on realtime code in the "unified-build-candidate3" branch from linuxcnc.org. This assumes you are using a run-in-place tree with a userspace realtime model, and that you understand the basics of gdb.
Rotary Delta Kinematics
I hope my kfreebsd box is still bootable...
Adventures in localization
Online Anagrammer with AJAX
The growth of Unicode over time
Hash saturation calculator
Screen-scrape ting device usage
New hardware
All older entries
Website Copyright © 2004-2024 Jeff Epler