Leszek Gruchała leszekgruchala

Around 2006-2007, it was a bit of a fashion to hook lava lamps up to the build server. Normally, the green lava lamp would be on, but if the build failed, it would turn off and the red lava lamp would turn on.

By coincidence, I've actually met, about that time, (probably) the first person to hook up a lava lamp to a build server. It was Alberto Savoia, who'd founded a testing tools company (that did some very interesting things around generative testing that have basically never been noticed). Alberto had noticed that people did not react with any urgency when the build broke. They'd check in broken code and go off to something else, only reacting to the breakage they'd caused when some other programmer pulled the change and had problems.

Scala's "type T in class C as seen from a prefix type S" with examples

Introduction

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.

As Seen From

Let's quote the Scala spec for As Seen From (ASF) rules numbered for an easier reference:

Explaining Miles's Magic

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

Applied Functional Programming with Scala - Notes

1. Mastering Functions

A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.

val square : Int => Int = x => x * x

	//sql
	create or replace function naturalsort(text)
	returns bytea language sql immutable strict as
	$f$ select string_agg(convert_to(coalesce(r[2],length(length(r[1])::text) \|\| length(r[1])::text \|\| r[1]),'SQL_ASCII'),'\x00')
	from regexp_matches($1, '0*([0-9]+)\|([^0-9]+)', 'g') r; $f$;



	//author: github.com/RhodiumToad

	package sample;

	import java.io.ByteArrayOutputStream;
	import java.io.IOException;

	import java.security.MessageDigest;
	import java.security.SecureRandom;

	import java.text.DateFormat;
	import java.text.SimpleDateFormat;

	scala> class Foo { self: Singleton => }
	defined class Foo

	scala> class Bar extends Foo
	<console>:12: error: illegal inheritance;
	self-type Bar does not conform to Foo's selftype Foo with Singleton
	class Bar extends Foo
	^

	scala> object Bar extends Foo

	{-# LANGUAGE DeriveFunctor #-}
	{-# LANGUAGE TypeOperators #-}
	{-# LANGUAGE MultiParamTypeClasses #-}
	{-# LANGUAGE FlexibleInstances #-}
	{-# LANGUAGE FlexibleContexts #-}
	{-# LANGUAGE OverlappingInstances #-}

	module Main where

	import Control.Monad.Free

	case class IO[A](unsafePerformIO: () => A) {
	def map[B](ab: A => B): IO[B] = IO(() => ab(unsafePerformIO()))
	def flatMap[B](afb: A => IO[B]): IO[B] =IO(() => afb(unsafePerformIO()).unsafePerformIO())
	def tryIO(ta: Throwable => A): IO[A] =
	IO(() => IO.tryIO(unsafePerformIO()).unsafePerformIO() match {
	case Left(t) => ta(t)
	case Right(a) => a
	})
	}
	object IO {

	1. Setup a project

	2. Add groovy SDK support:
	https://www.bonusbits.com/wiki/HowTo:Add_Groovy_SDK_to_IntelliJ_IDEA

	3. Download http://(yourjenkinsurl)/job/(yourpipelinejob)/pipeline-syntax/gdsl
	- this will give you the .gdsl file - download this to the src folder of your project.

	4. Finally follow this step - right click on the src folder -> Mark directory as -> Sources Root