This article was originally written in Japanese and translated into English with AI assistance. Please note that some expressions may carry nuances from the original Japanese.
🇯🇵 日本語版はこちら / Japanese version
Series: utf8conv Development Journal (Part 8)
At the end of the last article, I lined up the milestones from “it works” to “it can be distributed” in four lines. “It works” is the first of them.
At least at the time the original article was written, around March, my understanding was that this program “works (on my own computer).”
In reality, I had never once tested running a conversion from the screen (the GUI),
but at the point when I wrote “it works” in March, I was treating it as done, including the part where the screen is connected.
The “never once” in this article refers to the period from that March until midday on September 14, 2026.
Inside the single word “works,” there were several separate things, and the ones that held and the ones that did not had been rounded off into that one word. This time is the story of untangling what was inside.
The Three Scenes Inside “It Works”
First, let me set out the three scenes, in order.
March 2026: I Ran a Dry Run
The first scene is March 2026. As I wrote in the third installment of this series, the one where I completed the MVP, I ran utf8conv against my own folder. The way I ran it was a Dry Run.
The target was 51 files, and all 51 were judged to be UTF-8, judged to be files with no need for conversion. Since it was a Dry Run, nothing was written to the files, and the number of files converted was zero.
(The conversion itself, from around this time, I had been running inside the tests. Not a human operating it with a mouse, but a form where it is left to the test tooling and run automatically. A state of not going through the screen, in other words.)
Late Night on September 5: The Tests and the Conversion Passed
The second scene is half a year later, late at night on September 5, 2026.
Last time, I wrote that I had run an inspection of the state of the product candidates; this is from when the inspection of utf8conv was done. This inspection was something AI ran automatically while I was asleep.
Of the inspection, the tests and the conversion passed. The tests: 426 collected, 354 passed. The remaining 72 are skips. The character encoding conversion, too, actually went through.
However, the screen was not opened, and the result of the inspection said the following.
★ Passed by calling the
corefunctions directly, not the GUI. Via the GUI is unconfirmed.
The GUI is that screen, the one with the windows and buttons. core is the part behind that screen that actually determines the character encoding and converts it. What AI did was an inspection that said, “Without going through the screen, I called the part behind it directly and confirmed that the conversion goes through.”
Because the tests can be run automatically, the practice was to start the tests when going to bed and check after waking up. For this reason, there was never any occasion to look at the screen in the first place.
Midday on September 14: Only the Heading Lines Came Out
The third scene is midday on September 14, 2026.
On my own computer, I opened the utf8conv screen and pressed the run button. The way I ran it was a Dry Run.
Only the first few lines, the lines that serve as the heading of the run log, came out, and after that not a single line appeared. The run button stayed gray, in a state where it could not be pressed, and did not come back, and the progress bar did not move either.
At this point, the state was, “I cannot really tell whether it is running or not. Has it hung up??”
Lining Them Up
When the three scenes are lined up, the contents of “it works” come to this.
- March 2026: I ran a Dry Run. All 51 files were UTF-8, and the number of files converted was zero
- Late night on September 5: the conversion passed. The screen was not opened
- Midday on September 14: I ran it from the screen. Only the heading lines came out, and nothing after that. It also looked as if it had hung up.
None of them is something you could not call “it works.” But a scene where a file was converted from the screen and succeeded — that is, a situation confirming that file conversion is achieved along the entire path a user goes through when using this program — there was not one among these.
The Same Line Dropped Out Every Time Things Were Summarized
Then where did the first milestone line, “it works (on my own computer),” come from?
Following the records, inside the inspection record files, the one line “the screen is unconfirmed” had dropped out twice.
The first is the inspection result file.
In the body of the result file, it was properly written.
In the field for checking startup: “GUI unconfirmed (an environment with no screen).”
In the field where conversion was tried: “Via the GUI is unconfirmed.”
In the list of things that could not be confirmed: “Starting the GUI and converting via the GUI (because the environment has no screen).”
Yet at the very top of the same file, in the field where the conclusion is written in one line, it says this.
Partially works. The tests and the main features passed completely, but there is not a single procedure in the repository for building a distributable.
While the strong expression “passed completely” is there, not a word about the GUI is included. Within the same file, only the one summarizing line had dropped it.
The second is the summary of the whole inspection.
This is the inspection result files for each development project, folded into a single document in order to confirm where the projects stand as a whole. Here too, the preface says that for products with a screen, startup and the main features cannot in principle be confirmed. In the utf8conv row of the overview table, too, “⬜ GUI unconfirmed” remains.
Yet in the field that lines up a one-line comment per product, there is a line that begins like this.
UC/utf8conv ★ The contents are good (426 tests passed, and the main features passed too), but (the rest omitted)
Here too, the GUI has dropped out. What is more, what had been three numbers side by side in the result file — 426, 354 passed, 72 skipped — had become “426 tests passed.”
Put the two side by side, and the way they dropped it is the same. Where things are written in detail, it is properly there every time, but the moment things are summarized briefly, everything other than the conspicuous achievements drops out, every time. In two separate documents, both times, it dropped out in the same way.
One of the causes of this kind of phenomenon lies partly in the way these blog articles are written. I have AI record the development log, then have AI shape an article based on its contents, and then I read it through, scrutinize it, and correct it — that is the practice.
It was AI that ran the inspection and wrote the result file, and AI that wrote the summary. Presumably, I would guess, this was because when AI referred to the materials, it referred only to the briefly summarized parts and did not check as far as the body.
Still, the one who read the draft produced by that practice and let the line “it works (on my own computer)” through as it was, was me.
September 14: What Did Not Reach the Screen
Back to the story of midday on September 14.
Inside utf8conv, the job of drawing the screen and the job of converting files proceed at the same time, in separate flows (threads of work that proceed side by side within the program). In the third installment of this series, I had written about that mechanism like this.
The conversion flow doesn’t touch the screen directly; instead, using the form
self.after(0, ...), it asks the main flow, “Please display this.” The side that was asked carries it out when it has a free moment.
I wrote it as a safe practice, but there was an oversight. In the tool that builds the screen (tkinter), the only flow allowed to touch the screen’s parts is the flow that created them (the main flow), and what happens when they are touched from another flow was never guaranteed in the first place. And the act of asking with self.after(0, ...) was itself one of the operations that touch the screen’s parts.
A way with no guarantee reaches in some environments and does not reach in others. At midday on September 14, with the Python that was on my own computer it did not reach, and with a different Python it had been reaching.
The log lines that did not come out at midday, the progress bar, and the notice that it had finished — all of them were things asked for with that unguaranteed way of asking. The reason only the heading lines came out is that those were written in the program within the main flow.
That afternoon, I ran a small test that AI had prepared, on my own computer. A small window appears for an instant, and it finishes in a few seconds. Running it actually showed the following.
Requests from the main flow reach.
Requests from the conversion flow are being silently discarded, raising no exception (notice of an error) and not being made to wait. The conversion flow itself has not stopped.
Judging from this test, I assume that in the midday run as well, the conversion processing had proceeded to the end, and it was simply that I could not see it. Since it was a Dry Run, nothing had been written to the files either, so it was a state in which I could not even tell whether the processing had finished.
As for how to fix this state: stop this way of asking, and that is all.
The conversion flow only puts what it wants to convey into a queue (a box where things are stacked in order). The main flow goes to look at the box every 0.1 seconds and puts what has accumulated onto the screen itself. I changed it from asking to picking up what has been stacked.
Why it reaches in some environments and not in others remains unconfirmed. The fix is the same either way.
The Evening of September 14
After the fix, on my own computer, I ran it again from the screen.
First, I ran the folder I had prepared for checking, the one containing 10 files, as a Dry Run. The 「対象ファイル数」 (number of target files) line that had not come out at midday came out as 「対象ファイル数: 10 件」 (number of target files: 10), and all the lines after it came out too. The progress bar went all the way to full, and the run button returned to a state where it could be pressed.
Next, I ran a folder containing 2,000 files, likewise as a Dry Run. Information on the processed files was displayed one after another in the log display area, and I could also see the progress bar partway along.
Then, with the first folder, I set it not to include subfolders, turned off Dry Run, and ran it. The targets were the 6 files directly inside. 2 skipped, 4 converted. The ones converted were the 4 files index.html, top.html, tool.py, and common.css.
On the evening of September 14, 2026, for the first time, the files in the folder I had prepared for checking were converted from the screen. At last, a test had been run in a form that follows the path a user takes.
Next time, I will write about what was happening on the judging side before this fix was judged to have “passed.”
About Soul Resonant Works
Soul Resonant Works is a solo venture developing seven local AI systems.
Starting from zero programming experience, the development is progressing through collaboration with AI.
🌐 Soul Resonant Works:
→ https://sr-works.net/en/index.html
📝 This blog publishes the entire development process as a serialized journal.
CubePlot (free version available)
CubePlot is the first product from Soul Resonant Works — it turns a CSV into a 3D scatter plot you can rotate and zoom. No install, no sign-up: it’s a single HTML file you open in your browser, and it works offline. CubePlot itself does not send the data you load outside your machine — external network traffic is blocked at the browser level (CSP). Start with the free version.
▶ Product page: https://sr-works.net/en/cubeplot/
▶ Get it (commercial license, USD $39 + tax where applicable): https://soulworks8.gumroad.com/l/pzcij
If you found this article useful, please share it.
Leave a Reply