tmm1

atuin.sh

So the --headless=new doesn't work on any released version of Chrome yet?

What was used to author/render these docs?

Check out Channels DVR

Thanks for sharing this! I tried it and indeed it works quite well.

This will be much simpler/easier than gfortran+dragonegg, and removes some roadblocks preventing me from using the latest emscripten/llvm.

You can switch to text boxes via the gear at the top right.

In 2014, the Policy Simulation Library [1] added a model called Tax-Simulator [2], which is a Python reimplementation of TAXSIM [3][4]. It is available as open-source [5], and designed to let researchers both change existing policy variables and implement new tax reforms in Python.

[1] https://pslmodels.org/

[2] https://taxcalc.pslmodels.org/

[3] https://taxcalc.pslmodels.org/about/history.html

[4] https://github.com/PSLmodels/Tax-Calculator/blob/master/taxc...

[5] https://github.com/PSLmodels/Tax-Calculator

From the abstract of NBER paper I mentioned [1]:

Each year Americans spend over two billion hours and $30 billion preparing individual tax returns, and these filing costs are regressive. To lower and redistribute the filing burden, some commentators have proposed having the IRS pre-populate tax returns for individuals. We evaluate this hypothetical policy using a large, nationally representative sample of returns filed for the tax year 2019. Our baseline results indicate that between 62 and 73 million returns (41 to 48 percent of all returns) could be accurately pre-populated using only current-year information returns and the prior-year return. Accuracy rates decline with income and are higher for taxpayers who have fewer dependents or are unmarried. We also examine 2019 non-filers, finding that pre- populated returns tentatively indicate $9.0 billion in refunds due to 12 million (22 percent) of them.

[1] https://www.nber.org/system/files/working_papers/w30008/w300...

Not removed: https://github.com/apache/logging-log4j2/commit/d82b47c6fae9...

git clone --local will hardlink the existing git objects from the first checkout so no extra space is required.

There's a patchset for this feature being discussed on the mailing list:

http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/18953...

Yes, much of GitHub's core infrastructure is written in C.

test-queue supports minitest too, and follows the same basic design outlined in this article: a central queue sorted by slowest tests first, with test runners forked off either locally or on other machines to consume off the queue.

We use test-queue in a dozen different projects at GitHub and most CI runs finish in ~30s. The largest suite is for the github/github rails app which runs 30 minutes of tests in 90s.

The https://github.com/simeonwillbanks/busted gem provides some nice helpers around RubyVM.stat for finding cache invalidations. It can also take advantage of the dtrace/systemtap probes that shipped with ruby 2.1 (http://tmm1.net/ruby21-method-cache) which can be used as an alternative to the ftrace technique described in the blog post.

Before the release of 2.1.0, funny_falcon, samsaffron and I developed a patch that removes the global method cache in favor of a local method cache inside each class. (This was originally proposed for upstream inclusion in https://bugs.ruby-lang.org/issues/9262).

The patch has been running in production on GitHub's servers for over a year, and provides the benefits of a high cache-hit rate without the need for manual tuning. I recently ported this patch to ruby 2.2 as well and it is available in this squashed commit: https://github.com/github/ruby/commit/bd002fc9fc3c7236395df2...

Copying `/usr/bin/gdb` and `/usr/libexec/gdb/gdb-i386-apple-darwin` from an OSX Lion installation is one way to get a functional gdb on Mountain Lion or Yosemite.

We implement preload_all, which loops over app/{models,controllers}/ and requires everything. This method is generally called from config.ru, and happens in the unicorn master before it forks off workers.

I recently upstreamed a warmup method for Rack::Builder you can also use for this purpose: https://github.com/rack/rack/pull/617

Unicorn pre-forks workers upfront. New processes are not created per request.

posix-spawn is also only useful for fork+exec, where the new process starts executing a new binary. This is not the case in unicorn or resque, where the child processes actually need to be copies of the parent.

We're currently using posix-spawn in albino and grit, which execute external commands like `pygmentize` and `git`

This is a great article. I came across it while hacking on posix-spawn and it was quite useful.

The reason fork is so slow on Linux is because the default page size is 4k. This means for a 300MB process, 76800 page table entries have to be copied during the fork.

There are ways to enable HugeTBL on linux to increase the page size, which can improve fork performance as well. See http://stackoverflow.com/questions/2731531/faster-forking-of..., http://linuxgazette.net/155/krishnakumar.html and http://sourceforge.net/projects/libhugetlbfs/

Does anyone know how fork is implemented on BSD/OSX and why it doesn't exhibit the same characteristics?

Here's the full announcement: https://gist.github.com/e0d36c881e6efc57514b

A FIFO might work. Do you know how big the buffers associated with FIFOs on OSX are?

rbtrace is built on ruby's event hook api, which provides events when ruby and C extension methods are called, and when they return.

python offers a very similar event hook api: http://www.doughellmann.com/PyMOTW/sys/tracing.html

If you tried it, you would understand. Ruby programs make a _LOT_ of method calls.

Unfortunately the firehose doesn't work too well on OSX, because the unix message queue API I'm using (msgget(2)) is capped in the kernel to 2048 bytes and 40 messages per queue.

Yes it is.

http://dl.dropbox.com/u/635/gc-export.pdf

GC tuning is easy with REE, you can set environment variables to change the behavior of the mark and sweep collector. See slides 50-53 for more info.

"Now you know, and knowing is half the battle."

You're right, there's about 90k NEWLINE nodes on the heap, and at 40 bytes a piece that's taking up about 3.6mb of slots on the heap that could be used by other ruby objects instead.

Unfortunately, removing newlines from your codebase will not help since NODE_NEWLINE is used for separators like semicolons as well.

Ruby 1.9 gets rid of NODE_NEWLINE altogether by adding a NEWLINE flag to the next node instead. A similar patch will be in the next release of REE.

This a new presentation specifically about the MRI GC, but it covers some of the same tools mentioned in our Debugging Ruby and Threaded Awesome talks