tensorflow
Export the key signature to MusicXML
We currently detect the key signature and use it to determine the note pitches, but then throw it out. It needs to be stored in the Score proto (IR), so it can be exported to MusicXML. We can use the KeySignature proto from Magenta in the IR. We should add it to the Glyphs in the Page as we process them--maybe SHARP or FLAT Glyphs can have a KeySignature added if they make up a key signature, like we do with NoteSequence.Note for noteheads. This might require repeating the same KeySignature on multiple accidentals, or only storing it in the first accidental in the key signature.
Then, MusicXML export should just look for any KeySignature on any glyph in each measure, and set the key signature on the measure if present.
As we recently introduced an overlay for htop and I think that there will be many overlays created in the future (see termux packages and their patches)
I've looked through a couple of dozens of them, and I got the impression that most of their patches aren't relevant for us, they are for fighting bionic/NDK pecularities. So, I'm not exactly sure that we'll have too many.
We could use aarch64 build machine like those provided by travis-ci or github workflow to build these packages.
I actually liked how you did it with travis and cross-compilation. Large builds might require manual pushes, but small changes and small builds like htop should be within sane limits. And it auto-pushes what it has already built, so it will get through eventually.
In the htop overlay I pinned the nixpkgs version.
Yes. I was puzzled at first, but I concede that it makes sense: nixpkgs can move forward and break our patches, while a pinned old version of htop that you have to compile yourself is still infinitely better than a guaranteed broken one.
What do you think? Are there any problems I missed out?
Your reasoning is fine. Configuring CI for native compilation will be a big one-off investment. Updating pinned nixpkgs will be required from time to time, but having the packages compiled and cached will allow to reduce the period.
Patching packages that were half-broken is another story, and we'll have to expose the choice to the user: fresh package or fixed package. But it's thinking too much ahead, we don't even have them at this point =)
Large builds might require manual pushes
A side note: travis has a timeout of an hour, github workflow has a timeout of 6 hours.
I try to build a prototype which builds ci.nix and all packages with overlays and push them to cachix. Furthermore I will write a workflow to update the nixpkgs version if all builds succeed, should be fairly straight forward :)
Unfortunately, it is not really easy to pull off a working github workflow as it does not support aarch64. I could try travis for this purpose, but I don't think the one hour limit will work for us.
Thats a valid point. As long as the count of overlays is low it should work.
If we update them one-by one, it's not the count that matters, but the duration of the rebuilds. Or even of a single derivation, if we're willing to retrigger timeouts.
Which reminded me that I wanted to fix typespeed for quite a while already, I'll try my hand at it...
I've pushed 8e97da4 with a fix for typespeed, but deliberately didn't push the resulting binaries to cachix. It's also not a big package.
Short update on this topic. I managed to pull off a complete CI job (install nix, setup cachix, build stuff, push to cachix) on github actions for aarch64 systems in my nix-config repo: https://github.com/Gerschtli/nix-config/blob/master/.github/workflows/ci.yml
It is not that complicated, maybe it is worth a try for nix-on-droid :)