A common and reliable pattern in service unit files is thus:
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
DevicePolicy=closed
ProtectSystem=strict
#!/usr/bin/env bash | |
set -Eeuo pipefail | |
trap cleanup SIGINT SIGTERM ERR EXIT | |
script_dir=$(cd "$(dirname "${BASH_SOURCE[0]}")" &>/dev/null && pwd -P) | |
usage() { | |
cat <<EOF | |
Usage: $(basename "${BASH_SOURCE[0]}") [-h] [-v] [-f] -p param_value arg1 [arg2...] |
def buildFiles(b: File) = ((b * "*.sbt") +++ ((b / "project") ** ("*.scala" | "*.sbt")) filter (_.isFile)) | |
def genBuildFilesHashesAt(base: File) = buildFiles(base).get.map(f => f -> (Hash toHex Hash(f))).toMap | |
def genBuildFilesHashes(units: Map[URI, LoadedBuildUnit]) = | |
(units.values flatMap (_.defined) map (_._2.base) flatMap genBuildFilesHashesAt).toMap.## | |
val buildFilesHashes = settingKey[Int]("") in Global | |
buildFilesHashes := genBuildFilesHashes(loadedBuild.value.units) | |
shellPrompt in Global := (s => |
// originally by @SethTisue, see http://stackoverflow.com/questions/40622878/how-do-i-tell-sbt-to-use-a-nightly-build-of-scala-2-11-or-2-12/40622879#40622879 | |
resolvers += "nightlies" at "https://scala-ci.typesafe.com/artifactory/scala-release-temp/" | |
scalaVersion := { | |
val propsUrl = new URL("https://scala-ci.typesafe.com/job/scala-2.12.x-integrate-bootstrap/lastSuccessfulBuild/artifact/jenkins.properties/*view*/") | |
val props = new java.util.Properties | |
props.load(propsUrl.openStream) | |
props.getProperty("version") | |
} | |
scalaBinaryVersion := "2.12" |
This is my attempt to give Scala newcomers a quick-and-easy rundown to the prerequisite steps they need to a) try Scala, and b) get a standard project up and running on their machine. I'm not going to talk about the language at all; there are plenty of better resources a google search away. This is just focused on the prerequisite tooling and machine setup. I will not be assuming you have any background in JVM languages. So if you're coming from Python, Ruby, JavaScript, Haskell, or anywhere… I hope to present the information you need without assuming anything.
Disclaimer It has been over a decade since I was new to Scala, and when I was new to Scala, I was coming from a Java and Ruby background. This has probably caused me to unknowingly make some assumptions. Please feel free to call me out in comments/tweets!
One assumption I'm knowingly making is that you're on a Unix-like platform. Sorry, Windows users.
Miles Sabin recently opened a pull request fixing the infamous SI-2712. First off, this is remarkable and, if merged, will make everyone's life enormously easier. This is a bug that a lot of people hit often without even realizing it, and they just assume that either they did something wrong or the compiler is broken in some weird way. It is especially common for users of scalaz or cats.
But that's not what I wanted to write about. What I want to write about is the exact semantics of Miles's fix, because it does impose some very specific assumptions about the way that type constructors work, and understanding those assumptions is the key to getting the most of it his fix.
For starters, here is the sort of thing that SI-2712 affects:
def foo[F[_], A](fa: F[A]): String = fa.toString
Recently, I found myself in need to precisely understand Scala's core typechecking rules. I was particulary interested in understanding rules responsible for typechecking signatures of members defined in classes (and all types derived from them). Scala Language Specification (SLS) contains definition of the rules but lacks any examples. The definition of the rules uses mutual recursion and nested switch-like constructs that make it hard to follow. I've written down examples together with explanation how specific set of rules (grouped thematically) is applied. These notes helped me gain confidence that I fully understand Scala's core typechecking algorithm.
Let's quote the Scala spec for As Seen From (ASF) rules numbered for an easier reference:
#!/bin/bash | |
# very simple script to generate a tar of dependencies in ivy cache for extraction in TravisCI. | |
# usage: ./.create-travis-cache.sh <sbt-command>* | |
# | |
# By Default this will run `sbt update` with a clean cache directory and | |
# generate a .tar.bz2 with all the artifacts. This file can be pushed into | |
# dropbox and expanded in your TravisCI server later for a slight improvement | |
# in resolution times. |