import kafka.server.KafkaConfig;
import kafka.server.KafkaServer;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.Properties;
View ammonite-shapeless
> runMain ammonite.repl.Repl
[info] Running ammonite.repl.Repl
Loading Ammonite Repl...
@ load.ivy("com.chuusai" %% "shapeless" % "2.1.0")
@ import shapeless._
import shapeless._
@ 1 :: "lol" :: List(1, 2, 3) :: HNil
import java.util.function.*;
import java.util.*;
// this contract is mainly for library implementors, not that much for
// users. Well, this can be argued :-). Another side-effect of this
// approach is that code using the RDF interface would create and see
// the actual types/classes being manipulated, not the common
// interfaces.
interface RDF<Graph, Triple, RDFTerm, BlankNodeOrIRI, IRI, BlankNode, Literal> {
View scalaz.irclog
<RaceCondition> can I use Scalaz to get exhaustion checks when matching on numeric values? Scala obviously doesn't do that
<RaceCondition> ! 1.1 match { case x if 0.0 <= x && x < 0.5 => "bad"; case x if 0.5 <= x && x <= 1.0 => "good" }
<dibblego> doubt it
<multibot_> scala.MatchError: 1.1 (of class java.lang.Double)
<multibot_> ... 38 elided
<dibblego> use types though?
<RaceCondition> wdym?
<dibblego> use a type to note each range
<dibblego> you want a floating-point between 0.0 and 1.0?
<RaceCondition> wouldn't that just move the problem to a different stage?
View ld-patch.jsonld
"@context": {
"@base": "",
"@vocab": "",
"patch": "",
"ops": { "@container": "@list" },
"op": { "@type": "@id" },
"predicate": { "@type": "@id" },
"var": { "@type": "@id" },
"path": { "@type": "patch:path" },
View sports195-coding-challenge
object~extends Application{case class T(n:String,r:Double){def+(t:T)={val p=t.r/(r+t.r);val(w,l)=if(p>0.5||(p==.5&&n<t.n))(this,t)else(t,this);w.copy(r=r+(w.r-r)/5)}
case class R(r:Int,a:T,b:T,w:T){override def toString=s"$r,${a.n},${b.n},${w.n}"}
def g(l:List[T]):List[(T,T)]=l match{case a::b::l⇒(a,b)::g(l);case _⇒Nil}
def p(l:List[(T,T)],r:Int,a:Seq[R]):Seq[R]{case(a,b)⇒val(c,d)=a|b;R(r,c,d,a+b)}match{case m::Nil⇒a:+m;case e⇒p(g(,r+1,a++e)}
println(p(",")).sortBy(_(5)).sortBy(_(4)).map{case Array(a,b,c,d,_,_)⇒(T(a,b.toDouble),T(c,d.toDouble))},1,Seq()).mkString("\n"))}
View gist:6713876
# TimBL's removes his certificate informations
AT ca:i / cert:key DELETE .
# TimBL removes the certificate exponent from his certificate
AT ca:i / cert:key / cert:exponent DELETE .
# TimBL update his certificate informations
AT ca:i / cert:key UPDATE [
rdf:type cert:RSAPublicKey;
cert:exponent 65537;
View gist:6684747

The Graph Literal section says the following

Concrete syntaxes MAY support simple literals, consisting of only a lexical form without any datatype IRI or language tag. Simple literals only exist in concrete syntaxes, and are treated as syntactic sugar for abstract syntax literals with the datatype IRI

In practice, it appears that both Jena and Sesame are broken in their handling of RDF Literals. They also break graph isomorphism for the same reasons.

View select.scala
* "Select" off the first future to be satisfied. Return this as a
* result, with the remainder of the Futures as a sequence.
* @param fs a scala.collection.Seq
def select[A](fs: Seq[Future[A]])(implicit ec: ExecutionContext): Future[(Try[A], Seq[Future[A]])] = {
def stripe(p: Promise[(Try[A], Seq[Future[A]])],
heads: Seq[Future[A]],
View gist:1406559
Hi Donald (and Martin),
Thanks for pinging me; it's nice to know Typesafe is keeping tabs on this, and I
appreciate the tone. This is a Yegge-long response, but given that you and
Martin are the two people best-situated to do anything about this, I'd rather
err on the side of giving you too much to think about. I realize I'm being very
critical of something in which you've invested a great deal (both financially