Ansuz

自分のドキュメントクラスを作ろう

LaTeXで文書を書いてなら、時々すべてに体裁を指せたいです。

たとえば僕の仕事で、アナログシンサーのマニュアルを書いて、いつも同じの体裁が欲しいです。

LaTeXのデフォルトは普通過ぎます。 個性的な体裁を書きたいです。 でも全部のNorth Coast Synthesisユーサーマニュアルは、同じの体裁が必要です。 だから、自分のLaTeXクラスファイルを作りました。

Neural networks and the Unix philosophy

There are a number of directions from which we can look at current developments in deep neural networks and the issues I raised in my streamed comments on pirate AI. Here's a summary of the implications I see from the perspective of the Unix philosophy.

On language modelling and pirate AI (transcript)

I've been thinking a lot recently about the current developments in deep neural network generative models, and how they implicate free software issues. I went into a lot of this stuff in my July 25 Twitch stream, and although I'd also like to write up some of my thoughts in a more organized way, the transcript of the relevant video content is a pretty decent introduction in itself, so I thought I'd post it here.

This is an automatically generated transcript (by another of these models!), with a fair bit of manual editing - so it's spoken English written down, not the usual standard form of written English. The video itself will go online eventually, but it may be a long time before that happens, because my video archive server is at capacity now and I probably won't expand it until the Twitch stream gets enough viewers I can sell some subscriptions to pay the bills.

Visible ontologies

Web services expose their underlying data models throughout their interfaces, much more so than we might expect, and they're all different. Two services that seem to be direct competitors will have importantly different ontologies of the data, and this affects all aspects of how they feel to users.

MakeでLaTeX言語のビルドしましょう

今日MakeでLaTeX言語のビルドしましょう。

これは「TeX & LaTeX Advent Calendar 2021」の17日目の記事です。 （16日目はCareleSmith9さん、18日目はSpark Hiroさんです。） 悪い日本語でごめんなさい。 練習ので、一年に一つの記事を書いています。 早く流暢になりますかな？

Fixing cut-off margins and bad paper size in Okular printing

Ever since a recent "upgrade," the Okular PDF reader on my Slackware Linux system has been printing pages with incorrect margins, adding extra blank space at the bottom of every page and subtracting it at the top in such a way as to cut off part of the print at the top. No configuration changes seemed able to resolve the issue, and it was hard to get any useful debugging information. Searches on the Net found many instances of people having similar problems, but no convincing solutions - and the KDE development team has a history going back at least 13 years of never ever acknowledging or fixing any problems with printing options, always blaming it on the users and erecting unreasonable procedural barriers to bug reporting. Here are some notes on how I was able to fix my problem; it's an ugly fix and may not be useful to everyone with similar issues, but the notes may still be of some use.

Tsukurimashou 0.11 release

I've just posted the version 0.11 release of the Tsukurimashou Project - my parameterized font family for English, Japanese, and Korean, now with 2912 kanji including all those taught in the Japanese school system through Grade Five and more than half of Grade Six. This is the first release of the full project since November 2017, and the project began in 2010 - so it's kind of a big deal.

qrcodeのパッケージもスゴイ

毎年日本語の練習のためにTeX & LaTeXのブログを書きます。 今年に#texadvent2020のテーマは「このパッケージもスゴイ！」とです。 さて、僕はqrcodeのパッケージがそれものです。 なぜと思いましょう。

Apache, PHP-FPM, chroot jails, MediaWiki, MySQL, and so on

These are some notes on configuring Apache httpd to run large PHP applications via PHP-FPM in separate chroot jails. I recently had occasion to do that, and I had to find bits and pieces of information about it in many different places around the Net, so I'm compiling these notes both for my own future use and for anyone who's contemplating a similar project. There are a number of subtle details needed to do things like get TeX working (needed for MediaWiki math), configure process-pool policy, and so on. I'm not going to go into much detail on why someone would want to do this, nor background systems administration concepts like "What is a chroot jail?".

pgfornamentとTsukurimashouでディングバットを書いて

古風な活字とき、ページがよく飾られました。 いろいろのディングバットありました。 LaTeXでその活字をしましょう。

これは「TeX and LaTeX Advent Calendar 2019」の13日目の記事です。 12日目はMahito TANNOさんです。 14日目はhak7a3さんです。 外の年も記事を書きました。 2014 2015 2016 2017 2018

TeXLiveからMediaWikiのために最小のインストールは何ですか？

MediaWikiは有名とポピュラーなソフトです。 もちろんWikipediaがMediaWikiを使っています。 その上、多数のサイトはMediaWikiを使っています。 たとえば、僕のタロットサイト「edifyingfellowship.org」でMediaWikiが使われます。 MediaWikiはLaTeXのプラグインあります。 プラグインとLaTeXのインストール時Wikiで数学の植字が出来ます。 でもTeXLiveの全部インストールなら5.7Gが使われます。 小さいウェブサーバのでTeXLiveが大き過ぎるのようです。 このブログでMediaWikiのためにTeXLiveの最小のインストールを考えましょう。

これは「TeX and LaTeX Advent Calendar 2018」の13日目の記事です。 12日目はkn1chtさんです。 14日目はMizukiSonokoさんです。 外の年も記事を書きました。 2014 2015 2016 2017

Live video streaming with free tools (A Gruesome Orgy Of Yak Shaving!)

I recently set up my own server for streaming live video over the Web. That was complicated and difficult, and although I found some useful resources on the Web, none of them were complete and many of them were out of date. So here are my notes on what worked, both for my own reference and in the hope they may be useful to others.

Technologies covered here, more or less in order of signal flow from the origin of the video content to the viewer's screen: OBS Studio for generating the video signal; FFmpeg for encoding it; OpenSsh for securely transmitting the signal to the "repeater" machine that serves it to the users; HLS stream formatting; the Apache Web server; and the VideoJS HLS Javascript-based video player for displaying the stream in the viewer's browser.

These notes are current as of late January 2018. Pay attention to the date on these notes or any other information sources about this topic, because the relevant technologies change over time and there's a lot of outdated information out there.

tikzpeopleで新しいキャラ

これは TeX ＆ LaTeX Advent Calendar 2017 の 13 日目の記事です。 昨日は tattsan さんでした。 明日は p_typo さんです。 外の年も記事を書きました。 2014 2015 2016

Nils Fleishhacker さんからのパケージ『tikzpeople』は、 人のノードを書きできます。 マイクロソフトビジオのようを持ちます。 たとえば暗号プロトコルので便利です。 だから Alice と Bob の名前あります。

今日新しいキャラを上げましょう。 トトロとカッパと四人の JK です。

Circuit-Macrosで回路図を書いて

僕の新しい仕事がアナログシンセのデザインです。 LaTeXでユーザーマニュアルを作りたいです。 ドキュメントの中で回路図を書きたいです。 今日、Circuit-Macrosで回路図を書き方の勉強しましょう。 よろしくお願いします。

これはTeX & LaTeX Advent Calendar 2016に僕の寄贈です。昨日はmarimo-nekomimiさんの日です。 明日、Yasuhide Minodaさんの日です。

LaTeXで文章の空白の植字をしましょう

日本語が分かっても、時々英語で植字をしなければならないです。 英語では文章と言葉の中で、いつも空白あります。 LaTeXを使えば、もしかしたら文章と言葉の空白が難しいです。 今日本件の勉強をしましょう。

これはTeX & LaTeX Advent Calendar 2015に僕の寄贈です。

Mountain-climbing addresses for code lines

I found an interesting problem while working on a test case generator for the Tsukurimashou Project. The thing is that I'd like to assign an identifying code, which I will call an address, to each line of code in a code base. It's to be understood that these addresses have nothing to do with machine memory addresses, and they need not be sequential; they are just opaque entities that designate lines of code. Anyway, I would like lines of code to keep the same addresses, at least probabilistically, when the program is modified, so that when I collect test information about a line of code I can still keep most of it after I update the software.

lilypond-bookとLaTeXで音楽の植字

数学と理学ではLaTeXが有名です。 論文を書ければいつもLaTeXを使っています。 でもLaTeXではいろいろな文書ができます。 今日LaTeXとlilypond-bookで音楽の書くことを見ましょう。

これはTeX & LaTeX Advent Calendar 2014に僕の寄贈です。

TikZでマック・ペイントの床しいタイリングを描きましょう

TeXとLaTeXで画を書いたらTikZは便利とポピュラーです。 みんなはきれいなグラフィクスを作っています。 たとえば、これがtexample.netから一つのクリスマスツリーです。

しかし、ただのグラフィクスには興味ありません。 今日は１９８４年からノスタルジックの画を書きましょう。 マック・ペイントを思い出しませんか？ そう…

プリティプリントの試作

今年「TeX & LaTeX Advent Calendar」に入りました。 １４日に私の書き込みを書きます。 それ前このサーバにGeSHiと言うプリティプリントソフトを備え付けています。 この書き込みはGeSHiのテスト・ポストです。

Removing things from Firefox's location bar NO REALLY

The Firefox GUI becomes more annoying with each "upgrade." I don't know if they're taking bribes from Chrome, or if they took advice from the same "professional" UI designer who broke GIMP, or what, but it's really become a problem. For those who haven't given up on Firefox yet, however, and for my own future reference, here's something useful I managed to figure out after a lot of hair-tearing.

You start typing a partial URL into the location bar, and the drop-down list of suggestions appears. But there's a URL on that list that should not be there. Maybe it's something embarassing you don't want other users of your browser to see; maybe it's merely a site other than the one you want to be the match for the few characters you typed, and yet for some reason it keeps coming up as the preferred suggestion.

Kleknev: a coarse-grained profiler for build systems

When I was preparing the Tsukurimashou 0.7 release, I had to build the entire package several times from scratch, to verify that all the necessary pieces really were included in what I was preparing to ship. When I run the build on my development machine it normally re-uses a lot of previously-built components, only updating the parts I have recently changed. That kind of incremental compilation is one of the main functions of GNU Make. But if I'm shipping a package for others to use, it has to work on their systems which don't have a previous history of successful builds; so I need to verify that it will actually build successfully in such an environment, and verifying that means copying the release-candidate package into a fresh empty directory on my own system and checking that the entire package (including all optional features) can build there.

Tsukurimashou is a big, complicated package. It's roughly 92,000 lines of code, which may not sound like so much. For comparison, the current Linux kernel is about 15,000,000. Tsukurimashou's volume of code is roughly equivalent to an 0.99 version of Linux (not clear which one - I couldn't find numbers I trusted on the Web just now, and am not motivated to go downloading old kernel sources just to count the lines). However, as detailed in one of my earlier articles, Tsukurimashou as a font meta-family is structured much differently from an orthodox software package. Things in the Tsukurimashou build tend to multiply rather than adding; and one practical consequence is that building from these 92,000 lines of code, when all the optional features are enabled, produces as many output and intermediate files and takes as much computation as we might expect of a much larger package. A full build of Tsukurimashou maxes out my quad-core computer for six or eight hours, and fills about 4G of disk space.

So after a few days of building over and over, it occurred to me that I'd really like to know where all the time was going. I had a pretty good understanding of what the build process was doing, because I created it myself; but I had no quantitative data on the relative resource consumption of the different components, I had no basis to make even plausible guesses about that, and quantitative data would be really useful. In software development we often study this sort of thing on the tiny scale, nanoseconds to milliseconds, using profiling tools that measure the time consumption of different parts of a program. What I really wanted for my build system was a coarse-grained profiler: something that could analyse the eight-hour run of the full build and give me stats at the level of processes and Makefile recipes.

I couldn't find such a tool ready-made, so I built one.

Arch installation thoughts

I had a request for some comments on Arch Linux, now that I've been using it a few days, and in particular the question of whether it is easy to install.

Testing with Autotools, Valgrind, and Gcov

I only have limited faith in software testing, partly because of my lack of faith in software engineering in general. Most professionally-written code is crap, and the more people use "methodologies," the worse their code seems to be. I'm inclined to think that the best way to remove bugs from code is to not put them in in the first place. Nonetheless, writing tests is fun. It's an interesting way to avoid doing real work, and some of you might enjoy reading about some test-related things I tried on a couple of my recent projects.

Distributed version control is not my favourite technology

Not too long ago a free software project I'm peripherally involved in decided it was time to replace its old and not broken version control system with something new and broken, and the lead maintainer conducted a straw poll of what the new system should be. My suggestion of "anything, as long as it's not distributed" was shouted down by the chorus of "anything, as long as it's distributed." Having lost the argument in that forum, I'm going to post my thoughts on why distributed version control sucks here in my own space where it's harder for me to be shouted down.

Ideographic Description Sequences: some thoughts

I went through a bit of a crunch to get Tsukurimashou 0.5 out the door before my year-end vacation. With that done, and at least 99 kanji to do before the next planned release, I have a chance to sit back and think about some longer-term and spin-off projects. Here are some ideas on kanji searching.

UPDATE: A prototype implementation of the system described here now exists as part of the Tsukurimashou project, and you can check it out via SVN from there. Packaged releases will be available eventually.

Building a build for something weird

Here are some thoughts on the Tsukurimashou build system. You can find the code, and some documentation of how to use the build system, in the package, but this posting is meant to look more generally at some of the issues I encountered while building a build for something weird.

The thing is, Tsukurimashou isn't a piece of software in the normal sense, but a package of fonts. It's written sort of like software, using programming languages, but the data flow during build doesn't look much like the data flow during build of the usual kind of software package. As a result, although it seemed like using Make was the thing I wanted to do, the way I've written my Makefile doesn't look much like what we might expect on a more typical software project. Working on it has forced me to see the structure of the project quite differently from the way I'd usually look at software, and maybe some of the ideas from that can be applied to other things.

Astrolabe announces change in business: was astrology, now copyright trolling

The Unix time-zone database - necessary to the operation of Linux-based computers and many other systems around the world as well - has been withdrawn from distribution because of a lawsuit filed by Astrolabe Inc. I'm really saddened to hear of this, because I liked Astrolabe. They've been in the business of selling astrological software for a long time, and they make many popular products, some of which I have used and recommended. But now I can't give them any more money nor can I recommend that others do so, because they have attacked the basic infrastructure of global computing. The word "terrorism" is so overused now as to be practically worthless, but attacks on infrastructure are often mentioned when people try to define it. Shame on you, Astrolabe.

A XeLaTeX flavour for LaTeX-make

I like using Danjean and Legrand's latex-make package to handle automated compilation of my LaTeX documents. Unfortunately, there are several other packages with very similar names and functions, and this isn't the most popular one, so it's often hard to find on the Net when I want to install it on a new computer or recommend it to collaborators. In fact, I've ended up checking a copy into my own SVN repository so I can just check out from there when I want to create a new installation. Another gotcha is that it doesn't know about XeLaTeX, which has become an issue now that I'm using XeLaTeX for a lot of my newer documents (to achieve Japanese/Unicode and OpenType font support).

Below the cut: a Makefile fragment to add XeLaTeX support to latex-make. This can be used instead of the one-line default Makefile for a directory full of LaTeX document stuff, to replace the default invocation of pdflatex with xelatex.

Fixing Alpine's broken subject sort

I use the Alpine email software, which is successor to Pine. I mostly like it, but its implementation of "sort by subject" is broken and annoying.

It is documented that Alpine will strip "Re: " and variations from the start of a subject line before sorting, and that seems like something I would reasonably want: replies end up getting sorted with the things they are replies to, instead of all being grouped confusingly under "R". However, what is undocumented and unwelcome is that Alpine will also look for and remove strings enclosed in square brackets, which are typically used to identify mailing list messages. I subscribe to several mailing lists that identify themselves by square-bracketed tags at the start of the subject line while leaving the From: headers unchanged (messages are from the person who sent them instead of from the list). If subject sort worked, then as a natural consequence of how string sorting works, I could group all messages from the list together, sorted within the group by the rest of the subject. But because square-bracketed tags are silently ignored, I can't do that, and there is no way to group the mailing list messages together. There is no option to make subject sort sort on the actual subject, no really, the string that is in the Subject: header and not a munged version.

Fixed by deleting lines 4562 to 4565 of imap/c-client/mail.c in the Alpine 2.00 distribution, which check for square brackets and invoke mail_strip_subject_blob().

The Terrible Secret of OpenType Glyph Substitution

I was up until 3 this morning trying to figure out how to make OpenType glyph substitution work. That, in itself, is not news. Anyone who has tried to write substitution rules for OpenType fonts has probably gone through something similar. What is unusual, though, is that I not only succeeded, but also figured out the undocumented underlying principle so that I can predictably succeed in the future; as far as I can tell, the more usual practice is to just try things at random until one eventually either gets it working by accident, or gives up, without having learned anything useful either way.

The purpose of this entry is to provide the important information that I wasn't able to find on the Net and wish I had had. There is one important point I call the Terrible Secret, which makes all the difference to getting it to work; but rather than jump to that immediately I'm going to give the needed background first. I'll be using the terms that make sense to me, rather than the "easy" but uselessly vague simplified style used by all existing documentation I found.

Disabling Ctrl-Shift-Underscore font resize in Konsole

Why is it that all my KDE-related postings seem to be about disabling annoying user interface misfeatures?

Today's has to do with the Ctrl-Shift-Underscore (Ctrl-Shift-_) key combination. This is used for "undo" in EMACS-derived text editors, including JOE. In recent KDE versions, Konsole has started trapping this key combination for "reduce font size." So you're merrily editing away, you try to use the undo command, and suddenly your font has become smaller. To make matters worse, it is a known bug that the key combination Ctrl-Shift-+, which is supposed to be "enlarge font size," doesn't work. So not only can you not undo editing changes anymore, but you can't undo the font size change either. Solution below.

Typesetting astrology with LaTeX

This entry gathers together information on using TeX and LaTeX for astrological documents, including both software I've released myself, and links to other resources. This is the master entry, which will be updated from time to time; I may also post brief announcements linking back to it as things get updated and changed.

Disabling search type changes in kiten

The Japanese-English dictionary program "kiten" has an annoying misfeature whereby if you do a search that has no results, instead of saying there are no results it will automatically change the search type to try to get more results for you. For instance, an "Exact Match" search might be changed to a "Match Anywhere" search. Google does that sometimes (for instance, changing phrase searches to bag-of-words searches) and that's annoying too, but at least Google warns you when it does it, and the stateless nature of Google searches means that the change is local to a single search. With kiten, the search type change is permanent (even saved in the config file when you exit). That's a problem if you are doing many searches successively, for instance during translation, and you have to keep resetting the search type. It's an even bigger problem if you have the ill-advised, but default and encouraged, "Automatically Search Clipboard Selections" feature turned on: because then just selecting text in some other application can permanently change your kiten configuration.

Disabling huge-ass panel tooltips in KDE4

Big news! I've finally achieved one of my most-wanted misfeature fixes with KDE4: disabling the ugly huge-ass animated tooltips in the panel. I think a lot of others wanted this as well, so I'm hoping they'll link here.

Fixing the JED dealbreakers

There are many things I like about the JED text editor, and for a number of years it has been my preferred editor for working on C code. However, it has a number of misfeatures that make it unacceptable for other tasks for which I need a text editor, so I have generally been using JED only for C code, and JOE for most other things (including, notably, English-language writing of both fiction and nonfiction in LaTeX and flat text). Just recently I had occasion to try to edit some C code on my laptop, which had a fresh default installation of JED, and it was a horrible experience, and I realized that I had, years ago, made a number of customizations to JED that I'd long since forgotten about.

For my own future reference, and anyone who might be facing a similar situation, here are some notes on changes I made. I decided while I was at it to try to not only bring the laptop's installation up to the desktop's standard so I could use it for C, but also fix as many as possible of the issues keeping me from using JED for other things on both installations, so that I could at least consider adopting it as my general editor instead of mostly using JOE. It remains to be seen whether JED will be able to serve as my all-purpose editor, but so far I've been liking it once I sorted out these issues.

Disabling the "same directory as current tab" brain damage of KDE's konsole terminal emulator

So, you have a new laptop computer. You install the latest and greatest Slackware Linux on it, and it naturally comes with a newer version of KDE than what's on your desktop machine. You open the "konsole" terminal emulator as usual, work for a while, and then when you're ears-deep in /etc/acpi/events or somewhere, you open another tab and Whoa! you aren't in your home directory as you expected, your new tab is ears-deep in /etc/acpi/events or some such Godforsaken place.

Well, the first time you figure you just made a weird mistake and typed cd /etc/acpi/events/or/some/such/Godforsaken/place without realizing it (and then, fnord-like, didn't see the command in the terminal window), and you automatically type cd again to go where you meant to be and you carry on. But then it happens again.

So you resolve to lay off the crack pipe for a few days, grit your teeth and type "cd" again, and so it is only on the third time it happens that you finally decide maybe it's not just you, and you make appropriate experiments and discover the horrible truth: the KDE developers inflicted this on you as a deliberate feature! When you open a new tab it will pry into your bash process, figure out where you are, and put the new tab there to prevent your escape. Heaven help you if you weren't using bash.

That ought to be the end of the story, since they at least had the decency to put a check box for it on the "Edit profile" configuration dialog. Below the fold, what happens if you uncheck that box...

The whiteboard salesman

I do not fully understand how the whiteboard salesman became what he was. It's one of those jobs, like laboratory technician or the actuarial profession, that little kids never want to be when they grow up. I don't mean that it's low status, because kids don't care about that. Who of us doesn't remember a kindly garbage collector from our formative years, which of us never wanted to do that? But the whiteboard salesman's job was just not visibly important. If he ever told anyone why he chose the career he did, then that person never told me.