I’ve yet to use it personally, but renv [1] seems to try to solve the reproducible builds problem in a way more similar to other modern package managers (e.g. by generating a lockfile).

This approach enables stricter validations against tampering with the package repositories as a hash of the package can be stored in the lockfile, however it is obviously a bit more complex to use than the groundhog approach.

[1]: https://github.com/rstudio/renv

Agreed that renv is a better solution here. Even the example code for Groundhog is not written in idiomatic R which does not inspire confidence. Simonssohn is a legend in transparent research but not primarily a coder or software tool contributor (take a look at the source for p-curve if you want to see what I mean) and I think a secondary threat to reproducibility is relying on tools that end up abandoned or deprecated or for which bugs never get fixed.

>Even the example code for Groundhog is not written in idiomatic R which does not inspire confidence.

Not to mention the given example for irreproducibility in base R looks at code that would be a bug in the script for 3.6. It's only useful to keep this reproducible if I'm debugging the script.

And, in this case, anyone who's proficient with R would recognize this problem from personal experience or the many warnings in tutorials. I usually wouldn't shoot down a given example as though it disproved the existence of any example, but I don't know if there is another example. Unless old code relied on undocumented or contrary-to-documented behavior.

I came here to say this.

This seems like a non-issue given renv. And renv gives a more reproducible, I think, solution as it pins to versions, not dates.

I had some issues with this a few months back, and was in contact with apple dev support about it. They investigated the issue and since then it has worked for me.

Some people, me included, very much do. :)

Edited to add some background:

I feel it gives the tracks more context, especially as for many artists an album isn't just an unordered set of independent tracks but a carefully designed listing experience.

That said, I still like my playlists as well. ;)

I can't encourage people enough to actually set up their zsh manually instead of running a configuration framework.

I spent a few hours on this about a year back and went from over 2s to about 0.15s for a full run of an interactive login shell (`time zsh -l -i -c 'echo "test"'`). No functionality lost, at least none that I actually used and cared about.

Definitely one of the best quality of life improvements I've made to my setup in recent years.

Couldn't agree more. I did the same. Big improvement in performance and I have a better idea of how to customize as per my preference.

I was also worried about random code getting downloaded to my machine and getting executed.

Thanks for showing us how to test that. My standard ohmyzsh takes 0.185 seconds.

  ~ time zsh -l -i -c 'echo "test"'

test zsh -l -i -c 'echo "test"' 0.09s user 0.07s system 86% cpu 0.185 total ~

I second this, world wide release would be nice. It's a shame how many "locale neutral" apps end up walled in on the US app store.

Is there any specific reason why this happens, just seems to me like you get worse reach and no benefits? Especially for a marketing stunt like this.

Crypto export restrictions, I believe

I remember testing Oj a few years back and finding that yajl where still faster for some cases, I believe it was very large arrays of thousands of objects.

I did some impromptu benchmarking now, and couldn't find a case where Oj performed worse than yajl. Impressive!

Larger files to store and upload to iTunes Connect mostly. I don't think bitcode is ever transferred to development devices.

I guess there is also a risk that the compilation process generating 3x larger files could also be slower as more work are being done - but that's just speculation.

That's troubling. :( Same for both swift and objC?

Would be interesting to see numbers for the compiled, stripped and thinned binary the end user will download from the App Store (they are in the details view for the app build on iTunes Connect). My guess is that at least most of the change should go away there.

With bitcode, app thinning and what not in the mix the Xcode build artifact is so much different from what's actually being downloaded it's hard to tell if this radar has real world implications for anyone but the developer uploading the build to apple. Still interesting, and potentially annoying though.

The Apple bug report was filed by my colleague, JP, after we noticed that the built size of Realm's frameworks dramatically increased after updating to Xcode 8.3. We pay attention to the built size of our frameworks as we distribute precompiled versions of them (https://github.com/realm/realm-cocoa/releases), and a signifiant size increase inconveniences our users. We've not tested the impact of the size on an app installed via the App Store, but since the increase is limited to the bitcode portion of the binary we have no reason to think it will be affected.

Food tracking is an important part of many services, ranging from fitness/calorie tracking style apps to diabetes management.

However, keeping and maintaining an accurate food database is a big, costly, task that makes adopting new markets harder and obviously adds a substantial maintenance cost for each market.

Projects like this makes more markets accessible, especially small ones as cost per potential user is higher, and lay the foundation for cross-service-collaborations (i.e. log in your fitness app and the data shows up in your diabetes app as well).

Incidentally, I run a startup - Tummy Lab [1] - that tracks food intake and analyzes the data for co-relations between food and stomach issues.

If someone is looking for partnerships with regards to keeping food databases, feel free to contact us!

[1]: https://www.tummylab.com - swedish only, sry :/

That is probably the cutest startup name I've come across.