I would like to get rid of the for-loop and construct such a dictionary at once. I wrote a dict-derived class to do that, but it can do even more. But first, here is how I would do the above:

That’s it!

Notice how it takes a function as its first parameter. This is similar to how defaultdict takes a callable, but instead of taking a 0-arity callable, AccumulationDict takes a binary function. Whenever it “accumulates” a key-value for a key that already exists, the existing value and new value are sent to this function, and the result is what is set as the new value in the dictionary. This function will most likely be addition (rather than the lambda expression one could use operator.add), but it could be anything. Say you’re calculating probabilities of multiple events, you could use operator.mul.

I did not want to break KeyErrors, so accumulating is separate from getting and setting. This means you can still use __setitem__() and update() to reset the values of keys. Accumulation happens in the constructor, in dictionary addition, and with a new accumulate() function. accumulate() is identical to update() in interface, but uses the provided accumulator function to “merge” values when there are key collisions.

The code is below, but it represents a proof-of-concept and could be improved:

When Kimmo Koskenniemi worked out two-level morphology, generative phonology via context-sensitive rewrite rules were the common way of describing morphological systems. These kinds of rules were fairly expressive in generating surface forms from lexical forms, but were nearly useless in lexical analysis, and furthermore were computationally expensive. Johnson 1972, and later Kay and Kaplan in “Phonological Rules and Finite-State Transducers”, 1981, showed that these rules were insufficient and proposed finite-state transducers as cascading rules applied to lexical forms, and further that the sequence of FSTs could be collapsed to a single, very-expressive (and large) FST. In this context, Koskenniemi’s proposed a two-level system where smaller FSTs were applied in parallel instead of in sequence.

Aside from the computationally tractable benefits of two-level morphology, from what I could tell it only addresses the morphophonological changes to a lexical item. For instance, it may define a rule that inserts an e after a consonate-y sequence and before a (morpheme-boundary)-s sequence (as in the English plural “spy” -> “spies”; a separate rule handles the y->i conversion):

I don’t see how the “spy0+s” lexical form gets created, but the generality of +s being plural for all inflectional patterns is convenient. Also, I don’t see how long distance restrictions are modeled, as the rules appear to be limited to immediately-adjacent contexts.

I also found some articles by Koskenniemi (here and here) and Karttunen, Kaplan, Zaenen (here), but I haven’t yet read or written about them.

• to compile the whole thing (after uncommenting the avms)
• do some reading, then write the background/previous-work section
• Koskenniemi’s 2-level automata
• Beesly and Karttunen’s flag diacritics

I added line wrapping and indenting so users don’t have to manually put in line-breaks to get nicer looking outputs, but there is the drawback that it makes the output harder to grep. Perhaps I should add an option to disable the line wrapping.

Here is a longer example with some simple option parsing (apologies for using getopt; I’m currently looking for a better solution).

Once I figured out how to set it up (not too hard, but more work than usual), it’s been my favorite application for playing music. While GUI clients exist, I’ve been enjoying the command-line client MPC, as I can do things like this:

…which greps my whole music library for files with “Sigur” in the title, then adds them to the current playlist.

I also wanted to set up some key combos, so I didn’t have to execute commands in a terminal all the time. I used XBindKeys to bind some keys to mpc commands. For instance, the following commands toggles play/pause status (with Ctrl + the multimedia play button), skips to the next song (with Ctrl + multimedia next button), stops playback (with Ctrl + Alt + multimedia play button), and shows the currently playing song in a notification window (with Super + multimedia play button):

And what about memory usage? It’s currently playing a song and only using 8Mb. For comparison, I just fired up Rhythmbox and while idle it uses 47Mb.

Note-sharing is not a new idea, but it seems to have not been implemented yet. The basic ideas are that users of Tomboy should be able to get notes from others, give others their own notes, possibly sync them, resolve conflicts (as with synchronization), and be able to limit what notes are shared. Nobody seems to have mentioned real-time collaborative editing, but I don’t think it’s a good idea at this point, either.

I think there is not all that much that needs to be changed to allow sharing. Essentially, one must be able to synchronize subsets of notes, rather than all notes, and synchronize them in different locations (perhaps multiple). notebooks have been implemented, and they do a decent job of grouping notes, but they don’t add all that much functionally. I think users should be able to sync single notes, notebooks, or all notes with various locations. By doing so, I could keep all of my notes synchronized with my Ubuntu One account, and also sync my notebook for course notes to another server. My classmates can have an account with this other server, and by syncing with it we are sharing notes. If there’s a conflict, Tomboy should solve it in the simplest way possible (maybe prefix the conflicting lines with the username of the author?), or allow a user to launch an external diffing tool, such as Meld or WinDiff.

I’m sure there are issues I haven’t thought about too hard, such as how to deal with links to notes that don’t exist (e.g. outside of a shared notebook), what happens when users change, say, notebook names, Tomboy version or plugin mismatches, etc. But on the surface it seems that expanding synchronization to allow for syncing subsets of notes will allow for simple sharing.

I found, however, that there is another (and perhaps the intended) way to do it! You can create a command for each individual CJK environment you will need, and use them as needed. For example:

The \zht command is for traditional chinese characters, the \zhs is for simplified, and the \zh uses both (eg to define a word using both variants in hanzi, a transliteration, and a gloss). For example,

will produce

藝術/艺术 (yì shù) “art”

This works great, except that you have to use one of these tags every time you want to switch to a different character set.

NB: When using this method the very first line is not displayed. I got around this by having a dummy line near the top of the document. For example: