renatoalencar

FROM alpine

RUN apk add opam git musl-dev make m4 gcc bubblewrap bash coreutils pkgconfig openssl-libs-static openssl-dev
RUN opam init --disable-sandboxing
RUN opam install -y ocaml-base-compiler lambda-runtime dune

WORKDIR /app

COPY . .

nikeasyanzi

-- Thank @sbengo to figure out foreign_keys constraints is defaults to false in sqlite
-- Enable to delete logs by cascading delete
PRAGMA foreign_keys = ON;

WITH n_build_ids_per_repo as (
  SELECT build_id
  FROM (
    SELECT
      build_id,
      build_repo_id,

Kestrer

How to Write Hygienic Rust Macros

Macro hygiene is the concept of macros that work in all contexts; they don't affect and aren't affected by anything around them. Ideally all macros would be fully hygienic, but there are lots of pitfalls and traps that make it all too easy to accidentally write unhygienic macros. This guide attempts to provide a comprehensive resource for writing the most hygienic macros.

Understanding the Module System

First, a little aside on the details of Rust's module system, and specifically paths; it is

Raynos

/**
 * A PromiseLock like object.
 *
 * Used to ensure that we only do one thing at a time on a shared resource.
 *
 * For example, with async iterator:
 *
 * this.readLock = new Mutex()
 * this.readLock.do(async () => {
 *    const data = await itr.next();

eliseumds

export function serializeServerDataToJsonString(data: Object): string {
  const jsonString = JSON.stringify(data);

  return jsonString
    .replace(/<\/script/gim, '</_escaped_script')
    .replace(/<!--/gm, '\\u003C!--')
    .replace(new RegExp('\u2028', 'g'), '\\u2028')
    .replace(new RegExp('\u2029', 'g'), '\\u2029')
    .replace(/\\/g, '\\\\')
    .replace(/\n/g, '\\n')

david-zw-liu

-- Thank @sbengo to figure out foreign_keys constraints is defaults to false in sqlite
-- Enable to delete logs by cascading delete
PRAGMA foreign_keys = ON;

WITH n_build_ids_per_repo as (
  SELECT build_id
  FROM (
    SELECT
      build_id,
      build_repo_id,

dlaehnemann

Flamegraphing in Rust can now be done with a new cargo subcommand. Please check this out before embarking on the legacy journey below: https://github.com/flamegraph-rs/flamegraph

flamegraphing rust binaries' cpu usage with perf

One-time setup

1. Install perf, using Brendan Gregg's guide: http://www.brendangregg.com/perf.html#Prerequisites
2. Install flamegraph from repo:

bvaughn

// This is an advanced example! It is not typically required for application code.
// If you are using a library like Redux or MobX, use the container component provided by that library.
// If you are authoring such a library, use the technique shown below.

// This example shows how to safely update subscriptions in response to props changes.
// In this case, it is important to wait until `componentDidUpdate` before removing a subscription.
// In the event that a render is cancelled before being committed, this will prevent us from unsubscribing prematurely.

// We also need to be careful about how we handle events that are dispatched in between
// `getDerivedStateFromProps` and `componentDidUpdate` so that we don't put stale values into the `state`.

djspiewak

Quick Tips for Fast Code on the JVM

I was talking to a coworker recently about general techniques that almost always form the core of any effort to write very fast, down-to-the-metal hot path code on the JVM, and they pointed out that there really isn't a particularly good place to go for this information. It occurred to me that, really, I had more or less picked up all of it by word of mouth and experience, and there just aren't any good reference sources on the topic. So… here's my word of mouth.

This is by no means a comprehensive gist. It's also important to understand that the techniques that I outline in here are not 100% absolute either. Performance on the JVM is an incredibly complicated subject, and while there are rules that almost always hold true, the "almost" remains very salient. Also, for many or even most applications, there will be other techniques that I'm not mentioning which will have a greater impact. JMH, Java Flight Recorder, and a good profiler are your very best friend! Mea

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).