Reuben Morais

Hm, looks like the Java buildpack on Heroku does not expose the `mvn` executable to the worker :(

I found some relevant information from the Scala community: https://medium.com/rahasak/publish-scala-library-project-to-maven-central-with-sonatype-d7edaa67d275 https://github.com/xerial/sbt-sonatype

Also https://proandroiddev.com/publishing-existing-libraries-to-maven-central-1d08ae5d8f1

It looks like building a fat binary for x86_64 and arm64 is not useful because you still need two separate frameworks for device and simulator, as they use different SDKs....

Some initial tests on device (iPhone Xs), averaged across 3 runs, with the 0.7.4 models: no scorer, cold cache: RTF 0.60x no scorer, warm cache: RTF 0.48x with scorer, cold...

@lissyx could you give me a quick overview of what it would take to test changes to macOS workers in an isolated environment? Like, say, adding a macos-heavy-b worker type...

My probably incomplete idea: 1. Make PR against https://github.com/mozilla/community-tc-config/blob/master/config/projects/deepspeech.yml adding new worker instance with -b type. 2. Wait for it to be landed and deployed. 3. Make a copy of...

> You'd have to use the script that is on the worker #1 `prov.sh`, and you'd have to update the base image prior to that because I have not done...

> Be aware the existing workers if you copy them to your system are meant for VMWare Fusion Pro Ah, yes, that was also one of the complications. OK, thanks.

(Hopefully) finished wrapping the C API, now moving on to CI work. Wrapper is here if anyone wants to take a quick look and provide any suggestions: https://github.com/mozilla/DeepSpeech/blob/ios-build/native_client/swift/deepspeech_ios/DeepSpeech.swift