assp1r1n3

#include <stdint.h>
#include <stddef.h>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
uint64_t builtin_popcnt(const uint64_t* buf, size_t len){
  uint64_t cnt = 0;
  for(size_t i = 0; i < len; ++i){
    cnt += __builtin_popcountll(buf[i]);
  }

zmagg

omg julia,

Today I learned something about the buffer pool in MySQL that made it seem less like performance black magic! So, before today I knew that the buffer pool was an in-memory cache for MySQL that let you do super fast lookups (especially PK lookups, but maybe only PK lookups (? uncertain on that one)), like, our PK lookups with the BP turned on take microseconds, and they did so even before we moved to SSDs for all our databases [1]. I didn't know ANYTHING about how the buffer pool worked though, other than like, "caching: it makes things faster".

So, today we were doing a routine schema change truncating some old tables. We did a TRUNCATE operations live with all the databases still in configuration serving live traffic [2], because a TRUNCATE essentially does a DROP/CREATE at the table level, instead of row by row (since MySQL 5.1, we're on 5.5), so it's usually reasonably high performance. TURNS OUT, it also does some really not-so-performant cache invalidation on the buffer pool! This

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

mattes

# using VirtualBox version $VBOX_VERSION

FROM boot2docker/boot2docker
RUN apt-get install p7zip-full

RUN mkdir -p /vboxguest && \
    cd /vboxguest && \
    curl -L -o vboxguest.iso http://download.virtualbox.org/virtualbox/$VBOX_VERSION/VBoxGuestAdditions_$VBOX_VERSION.iso && \
    7z x vboxguest.iso -ir'!VBoxLinuxAdditions.run' && \
    sh VBoxLinuxAdditions.run --noexec --target . && \

staticfloat

Julia Debugging Procedures

So you managed to break Julia. Congratulations! Collected here are some general procedures you can undergo for common symptoms encountered when something goes awry. Including the information from these debugging steps can greatly help the maintainers when tracking down a segfault or trying to figure out why your script is running slower than expected.

If you've been directed to this page, find the symptom that best matches what you're experiencing and follow the instructions to generate the debugging information requested. Table of symptoms:

• Segfaults during bootstrap (sysimg.jl)

• Segfaults when running a script

darius

(Superseded by https://github.com/darius/regexercise )

Some coding exercises, working up to matching regular expressions with Thompson's algorithm.

I'm assuming you know what a regular expression is and you're a fairly experienced programmer. I don't know if these exercises are either fun or effective -- please comment or fork here or email withal@gmail.com to help me improve them.

The problems

haberman

// On my system:
//   virtual call time: 4.340
//   non-virtual call time: 3.970
//   virtual call overhead 9.32%

#include <stdlib.h>
#include <time.h>
#include <stdio.h>

#define NOINLINE __attribute__ ((noinline))

zachallaun

# time
# ====

macro time(ex)
    quote
        local t0 = time_ns()
        local val = $(esc(ex))
        local t1 = time_ns()
        println("elapsed time: ", (t1-t0)/1e9, " seconds")
        val

bradfitz

#!/usr/bin/perl
#
# Brad's el-ghetto do-our-storage-stacks-lie?-script
#

sub usage {
    die <<'END';
Usage: diskchecker.pl -s <server[:port]> verify <file>
       diskchecker.pl -s <server[:port]> create <file> <size_in_MB>
       diskchecker.pl -l [port]

tqbf

0e3647e8592d35514a081243582536ed3de6734059001e3f535ce6271032
334b041de124f73c18011a50e608097ac308ecee501337ec3e100854201d
40e127f51c10031d0133590b1e490f3514e05a54143d08222c2a4071e351
45440b171d5c1b21342e021c3a0eee7373215c4024f0eb733cf006e2040c
22015e420b07ef21164d5935e82338452f42282c1836e42536284c450de3
043b452e0268e7eb005a080b360f0642e6e342005217ef04a42f3e43113d
581e0829214202063d70030845e5301f5a5212ed0818e22f120b211b171b
ea0b342957394717132307133f143a1357e9ed1f5023034147465c052616
0c300b355c2051373a051851ee154a023723414c023a08171e1b4f17595e
550c3e13e80246320b0bec09362542243be42d1d5d060e203e1a0c66ef48