僕の新しい仕事がアナログシンセのデザインです。 LaTeXでユーザーマニュアルを作りたいです。 ドキュメントの中で回路図を書きたいです。 今日、Circuit-Macrosで回路図を書き方の勉強しましょう。 よろしくお願いします。
日本語が分かっても、時々英語で植字をしなければならないです。 英語では文章と言葉の中で、いつも空白あります。 LaTeXを使えば、もしかしたら文章と言葉の空白が難しいです。 今日本件の勉強をしましょう。
これはTeX & LaTeX Advent Calendar 2015に僕の寄贈です。
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.
数学と理学ではLaTeXが有名です。 論文を書ければいつもLaTeXを使っています。 でもLaTeXではいろいろな文書ができます。 今日LaTeXとlilypond-bookで音楽の書くことを見ましょう。
これはTeX & LaTeX Advent Calendar 2014に僕の寄贈です。
I have just posted Tsukurimashou 0.9, the latest version of my Japanese-language font project. After almost a year in development since the last version, this one contains 1754 kanji, including all through Grade Four and 100 from Grade Five (a little more than half of the 185 assigned to that grade). This version also includes extensive infrastructure changes, most notably a bundled interpreter for the FontForge native scripting language, intended to provide insurance of future support as mainline FontForge moves further and further away from that language.
The future of Tsukurimashou development may be tangled, as my commitments and priorities change with my upcoming move to Denmark. This 0.9 release was produced in a bit of a rush to get something out the door before I pack up my computer for shipment. I don't know when I will next get a change to work on it more, but that will be at least two months from now. You can do your bit to support continued work on Tsukurimashou by building it, using it, and above all by writing about it. What the project needs most of all is attention.
FontAnvil is a script language interpreter for manipulating fonts. FontAnvil is substantially compatible with the PfaEdit/FontForge native scripting language, but FontAnvil is intended for non-interactive use; for instance, invocation from the build systems of font packages like Tsukurimashou. To better serve font package build systems in general and Tsukurimashou in particular, FontAnvil has no GUI and, to a reasonable extent, avoids dependencies on external packages.
TeXとLaTeXで画を書いたらTikZは便利とポピュラーです。 みんなはきれいなグラフィクスを作っています。 たとえば、これがtexample.netから一つのクリスマスツリーです。
しかし、ただのグラフィクスには興味ありません。 今日は１９８４年からノスタルジックの画を書きましょう。 マック・ペイントを思い出しませんか？ そう…
PROBLEM: Since just before the Twitter IPO, when they changed their site code, mouse copy-and-paste no longer works on Twitter's Web site viewed in Firefox. Where before one could highlight text with the mouse and then middle-button click to paste it somewhere, now that either causes the former contents of the clipboard to be pasted, or the string "witter.com". Copy and paste still works if and only if once uses explicit "copy" and "paste" commands with the keyboard or menu bar, but that is much less convenient, and is annoying to discover on the fly. Observed in several versions of Firefox under Linux; similar problems have been reported with other browser and other operating systems. Problem is specific to Twitter.
SOLUTION: In "about:config," set "dom.event.clipboardevents.enabled" to "false." Explanation below the cut.
I've posted Tsukurimashou 0.8, the latest version of my Japanese-language font project. This version contains 1502 kanji, including all through Grade Four. There are relatively few infrastructure changes for the fonts in this version, but Kleknev is new in this release (still at alpha status) and IDSgrep 0.4, released a few days ago and included in this package, contains some new and exciting speed enhancements.
UPDATE: I presented Tsukurimashou at TUG 2013 in Tokyo this October. You can read my slides (PDF file) on the conference Web site, and see some photos from my trip in my photo gallery. The paper will appear in TUGboat 2013.3, which will be posted on TUG's Web site (initially members-only, eventually open-access, or visit your library) in the near future.
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.
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.
I'm very happy to announce the release of version 0.7 of Tsukurimashou, my Japanese-language font project. That is a link to the release page for the source code package on SourceForge.JP; see also the complete list of downloadable files and the project home page. This has been almost nine months in the making, and as I said on Twitter, the yak hair is thick on the floor. Release notes below the cut.
The title is a song lyric; it means "the story that starts now," and that's more or less where I feel I'm at. A lot has happened between mid-November and now, and I'm hoping that this will mark a boundary or change in the conditions around me.
I've decided to stop using Arch Linux, because I believe in The Arch Way. I'm tempted to leave it at that, but more detail is below the cut.
I recently updated my OCR and Genjimon font packages, a process which included merging them into the Tsukurimashou Project's build system as what I'm calling "parasite" packages (IDSgrep has also become such). They now come included automatically (but not built by default) when you download the full Tsukurimashou package, or they can each be downloaded as a separate distributed package. Some bugs are fixed, and Genjimon has two new styles added, one of which is shown below.
Having the OCR package listed as a download on the Sourceforge.JP site immediately boosted Tsukurimashou's rankings, because 15 or 20 people download it every day. I'm happy to have the added visibility, but I wish that visibility could be coming from popularity of the main Tsukurimashou project instead of this minor spinoff.
As part of my efforts to be ready for wherever my next employment takes me, I've shifted my email home. For a long time my usual practice has been for email to end up delivered to my home computer, which I log into remotely from wherever I am. The way I see it is that my personal email is mission-critical, and I don't want my email home to be on any computer I don't control, especially not one belonging to an employer or to Google. I have had content in my email subject to a court case before, the other side in that case wasn't able to interrupt my email because they had no right to and it was all routed through systems controlled by people who understood that, and I'd like to keep things that way.
Running my own email service requires my home computer to be accessible on the Net at all times, and I've now had a couple of adventures in which it or its Net connection stopped working while I was away from home and I had to switch to less useful backup systems. So, as of today, my email is now going to a leased server elsewhere on the Net. I can connect to it remotely from wherever I have a good connection, even if my home computer doesn't. This may be especially useful if, as seems quite possible, my current home computer goes into storage for a while and I end up spending a lot of time without an operational home computer of my own at any fixed location.
I posted version 0.3 of IDSgrep last night; follow the link to download it from SourceForge.JP. As you may recall, IDSgrep is my kanji structural-query software. Some of the ideas behind it were discussed on this Web log back in December. The general idea is that this is software to answer queries about layout and visual components of Han-script (Japanese, Chinese, etc.) characters.
The main new things in version 0.3 are support for regular expression searches; the inclusion of a bundled dictionary (based on the IDS decompositions of the CHISE project); and a "cooked" output mode.
At this point I think IDSgrep as such - the search program - is basically finished. As bug reports and practical experience accumulate, there may eventually be a 0.4 or 1.0 release, but all the features I think it needs to have are now in place and it seems to serve pretty well the original purpose for which I needed to develop it.
I'm switching this Web site's underlying software again, mostly due to security, reliability, and performance concerns related to PivotX. I'm trying to do this stepwise without breaking too much, but you may notice some features added, removed, or different over the next few weeks. I think comments here should continue to work, but if not, email me with any problems you notice.
At long last, I've completed the 0.6 release of the Tsukurimashou fonts (project home page). This one contains 1110 kanji, including all those taught in the Japanese school system through Grade Three. Also new in this release are experimental italics and integration with my IDSgrep structural-query software (which has its own, separate release series). Downloads: source code; precompiled fonts; demo PDF files.
Here is an actual quotation that I did not make up, from Microsoft's recommendations on how software should communicate with users:
Use the second person (you, your) to tell users what to do.
Here's one of my own:
Don't tell users what to do.
I have forked the GNU Image Manipulation Program, and you can download my version from this GitHub project. See my earlier posting for discussion of why. In few words: mainline GIMP is an XCF editor, not an image editor. My version is an image editor.
A few days ago, I ran Arch Linux's update process and it pulled down and installed a new version of GIMP, version 2.8. This version incorporates some changes in the user interface which apparently were under development for a long time, but only very recently finally put into the "stable" distribution stream.
The one that interests me may appear on the surface to be very small, but it is and is meant to be a really significant shift in the entire definition of what GIMP is. GIMP used to be, as the name "GNU Image Manipulation Program" implies, an image editor. With version 2.8, GIMP has become an XCF file editor with the ability to read and write other formats.
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.
I took the plunge and created an account on the world's worst Internet dating site. This is mostly so that I can participate in the KanjiVG project, which has decided to host there; git and thereby Github remain not my favourite systems. However, I've established a mirror of Tsukurimashou in my new Github space, so people who do like git and Github can find it there now too.
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.
I've just released the first packaged version of IDSgrep, which is an implementation of the ideas I posted last month about Ideographic Description Sequences. It's meant to bring the user-friendliness of grep to kanji dictionaries. Compiling it will require the usual Unix tools, and using it effectively will require a copy of KanjiVG, but you can look at the screenshot of it in action on the SF.JP site.
It'd be really nice if I could publish a paper about this. I'm looking at some academic-type computer science conferences, but it might actually be more on-topic for the more industrial or open-source type of meeting. If any readers have suggestions on what might be a good venue, I'd like to hear them.
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.
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.
This is an archived old announcement, for a version of Tsukurimashou that is no longer the latest. You can find the latest version in the Tsukurimashou project on Sourceforge Japan.
I've released a new version of the Tsukurimashou fonts (project home page). This one contains 776 kanji, including all those taught in the Japanese school system through Grade Two and half of Grade Three. The bigger news, however, is that I've also added a set of fonts for the Korean hangul writing system. Those should now be beta quality - you should now be able to write the standard modern Korean language in its entirety. Downloads: source code; precompiled fonts; demo PDF files.
These fonts are far enough along now that I'd really like to create a bit of "buzz" around them; that's part of the sneaky plan behind my recent technical postings about my experiences building the fonts. I'm hoping that a lot of people will read those, and, especially, share them on systems like Twitter and the other one. In the new year, after I've posted a couple more (I'm aiming for weekly technical postings), I'll evaluate whether they are attracting third-party traffic and whether I want to continue them. They take up time I could be spending on writing code, but having people use the software is important too.
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.
Posting this for the benefit of people who may have the same problem, and for my own future reference if it happens to me again.
The problem: Xorg (new name for XFree86) installation, configured with SCIM-anthy for Japanese-language input, and I want to also use the Windows keys as Compose keys when not in Japanese input mode. Compose and Japanese input both work in GTK applications, but in QT applications (notably, Konsole), Japanese input works and the Compose key doesn't. The Compose key is properly configured in KDE, xorg.conf (XkbOptions setting and UTF-8 locale), and xmodmap. If I disable SCIM entirely, then Compose works everywhere, but I lose Japanese input everywhere also.
This is an announcement for an outdated version. More recent versions are available; see the Sourceforge project for the latest one.
I'm very happy to announce a new release of the Tsukurimashou font project, version 0.4. See files from this release on the Sourceforge releases page, and the summary for the project. The current glyph counts are 2021 overall, 573 kanji; this version now includes all the grade-school kanji through Grade Two. あなたもは、７歳みたく書きことができますよ！ (You, too, can write like a seven-year-old!)
Now, somebody restrain me before I add the 11172 Korean hangul syllables.
Folks, we had a break-in on this Web server. I think it's cleaned up now, but if you have created a "visitor" account (I think very few people have) it would be wise to change your password just to be on the safe side. Discussion below.
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.
This entry summarizes the current status of the MetaPost serial-number bug. This bug is relevant to the Tsukurimashou project, and I need a consistent URL to link to in the documentation when I discuss this issue. I'll update this entry from time to time with the latest news.
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.
Today, after years of suffering, I finally managed to find a workaround for one of the several problems I'd been having with printing from GTK+ applications, in particular Firefox. Here are some notes for the benefit of others who may encounter the same thing.
BASIC SYMPTOMS: Every time I try to print something on my laser printer using a GTK+ application, I get inappropriate default settings (namely one-sided printing on card stock from the multi-purpose tray). If I don't change these defaults, the printer stops and waits for user intervention to insert card stock in the multi-purpose tray. Others reporting similar problems have often complained about letter-sized or A4 paper being the default when they wanted the other - sometimes adding a layer of chauvinistic slurs at countries following the other standard - but in fact I haven't had that particular problem myself.
This is the announcement of a now-obsolete version. Check out the latest progress of Tsukurimashou at sourceforge.jp!
I've just posted the second release of the Tsukurimashou font family - now with 198 kanji, including the 80 Grade One jouyou kanji. You, too, can write like a six-year-old! Also new in this version is a fancy build system.
More commentary probable at some future date; for the moment I've already used up today's word quota writing the package documentation.
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().
This is the announcement of a now-obsolete version. Check out the latest progress of Tsukurimashou at sourceforge.jp!
I'm pleased to announce the first release of the Tsukurimashou font family. The user's manual and demo is available as a PDF file; so is the complete package in bzipped TAR and ZIP formats. Precompiled OpenType fonts, compatible with all currently-popular typesetting systems, are included in those packages for two styles (Tsukurimashou Kaku and Mincho). Other styles you'll have to compile yourself.
These fonts are released with source code under the GNU GPL version 3 with font-embedding clarification. The current version contains the full repertoire of ISO Latin-1, hiragana, and katakana; more characters are on the way.
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.
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.
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.
When I switched to the new computer I found that a lot of my trickier LaTeX code - including, for instance, the files I use to produce my Japanese-language flash cards - no longer worked with the TeX/LaTeX installation that came with the new Slackware, and I was faced with a choice of going forward (converting all my code to work with some new installation, whether that or another), or going back (and restoring the entire TeX/LaTeX installation from the old machine). I decided to go forward. As a result I've spent a fair bit of time in the last few days tweaking different pieces of software. The astrological chart service is probably still down, though I'm getting closer to having it work again; I couldn't get CJK and its associated packages to work at all in the amount of time I was willing to spend, so I ended up taking "grendelkhan"'s suggestion and switching to XeTeX for my Asian-language typesetting. I ended up also switching the book manuscript to XeTeX for other reasons, and that was an adventure because of compatibility between XeTeX, the sffms class, and the commercial font I wanted to use.
The news, however, is this: I just got mail from Anthony Owen, the designer of the Starfont astrological fonts, and he confirms that he has released them to the public domain. Yay! There had formerly been some uncertainty and people were hesitant to use or distribute the fonts for that reason. So it's now on my list to put together a new version of the LaTeX package I wrote - but of course I also want to go in and add all the updates and fixes that have come up in the years since I last updated it, so there'll be some nontrivial work involved beyond just changing the licensing notes.
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.
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.
KDE4 introduced a stupid useless icon that you can't get rid of, in the upper right corner of the desktop. The developer of the relevant code has adamantly refused to introduce any possibility of making it optional; but a civic-minded third party created the "I Hate the Cashew!" "plasmoid" to make it go away. That's all well and good.
The bad news is that "I Hate the Cashew" is no longer maintained, and doesn't work anymore with the current version of KDE, 4.5.1 as I write this. The good news is that with some digging, I found a solution in a Web log comment from someone using the name "Newar," and that works. The trick: you can now move the cashew to your choice of corner. So move the panel out of the way temporarily (for instance to the left edge of the screen), move the cashew to a corner that will be covered by the panel (lower right), and then move the panel back to its usual location. The cashew is still theoretically there, but at least it's no longer all up in your face. Thank you, Newar!
I'm not planning to post further continuous updates on my move to the new computer, but at least one correspondent commented that she hadn't seen any further updates in a while and hoped the new machine was working, so I thought I'd better wrap up some loose ends.
The new machine works. It will be a long time before I'm fully "settled in" on it, and a lot of software that used to work, doesn't work now because of the change. I will be fixing things as they come up, one at a time. But I've moved over my home directory, email is flowing in both directions, and a snapshot of the old machine at the time of the crash is now archived to DVDs, independent of my other backup measures. I'm basically back in business. A few loose ends and other comments, below.
So, here we are. It's 3:45pm on Wednesday, and I'm home again after a relatively brief trip to Waterloo. I wanted to be there this morning for a meet-n-greet meeting with some new students, but I found that (because of two and a half hours' sleep last night) I wasn't getting any work done, so I left shortly after noon.
As of 6:15am when I departed, the RAID build was in progress and estimated to finish in four hours, so about 10:15. It has certainly finished now. One other thing to report from the intervening time is that I managed to get through on the phone to the fellow from TigerDirect who had called me, and it turned out he wasn't phoning about the RAM RMA after all! It's just that they have some sort of AI that flags customers who look like they might be buying for a business, to get a personal call inviting them to use the company's B2B service. I wasn't a business and so he didn't have much to say to me. He listened politely to my description of the RAM troubles, but that clearly wasn't his department and he didn't and couldn't tell me anything I didn't already know about it.
So I shipped the RAM back to TigerDirect. I'd been holding off until I was able to talk to their representative, in case it was going to turn out that he'd tell me not to ship it back for some reason. It remains to be seen how much of it they'll reimburse.
Now, as the lady said to the tinker, let's have another round.
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.
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...
So, you've got an audio signal contaminated with a continuous tone at about 233 Hz, with a really strong second harmonic at 465 and some others throughout the audio spectrum. It sounds like a swarm of angry bees and makes the main signal hard to listen to. You can notch it out - that means applying a filter that simply removes the frequencies in question - but since 465 Hz is right in the important part of the speech band, the result is going to sound really bad. Any simple frequency-notch filter that blocks the interference is going to destroy things you want to keep, too. Look around the Net these past few days and you can read a lot of broadcast audio people complaining about this issue.
It became necessary for work-related reasons that I should attempt to install Skype on my home computer, so I made the attempt.
This is for my own future reference, since it was hard to find in the documentation and I'll probably need it again in the future.
The things you can create that collect together commonly-used sets of printer options, to be used with the slash modifier to the printer name on the command line, are called instances. Global instances are set up in /etc/cups/lpoptions and per-user instances in ~/.cups/lpoptions. Per-user settings (including choice of a default instance to use instead of the per-printer default) will override the global ones. Beware the lpoptions command, which likes to store your selections permanently in your per-user config file so that subsequent global changes will not be visible to you. Some per-user default settings also appear to silently override per-job settings given on the command line.
I am typing this into a local installation of PivotX on my home machine. My plan is that if I can get it whipped into acceptable shape, I will upload this installation to the Web server and have it replace my existing Web site. At this point I think it's likely I will go through with that; however, there are some annoyances I'd like to mention.