betehess

import kafka.server.KafkaConfig;
import kafka.server.KafkaServer;

import java.io.File;
import java.io.FileNotFoundException;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.Properties;

betehess

> 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

betehess

import java.util.stream.*;
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> {

betehess

<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?

betehess

{
  "@context": {
    "@base": "http://example.org/timbl",
    "@vocab": "http://www.w3.org/ns/ldpatch#",
    "patch": "http://www.w3.org/ns/ldpatch#",
    "ops": { "@container": "@list" },
    "op": { "@type": "@id" },
    "predicate": { "@type": "@id" },
    "var": { "@type": "@id" },
    "path": { "@type": "patch:path" },

betehess

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)}
def|(o:T)=if(r>o.r||r==o.r&&n<o.n)(this,o)else(o,this)}
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]=l.map{case(a,b)⇒val(c,d)=a|b;R(r,c,d,a+b)}match{case m::Nil⇒a:+m;case e⇒p(g(e.map(_.w)),r+1,a++e)}
println(p(io.Source.stdin.getLines.toList.map(_.split(",")).sortBy(_(5)).sortBy(_(4)).map{case Array(a,b,c,d,_,_)⇒(T(a,b.toDouble),T(c,d.toDouble))},1,Seq()).mkString("\n"))}

betehess

# 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;

betehess

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 http://www.w3.org/2001/XMLSchema#string.

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.

betehess

 /**
   * "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]])] = {
    @tailrec
    def stripe(p: Promise[(Try[A], Seq[Future[A]])],
               heads: Seq[Future[A]],

betehess

Originally:
https://gist.github.com/7565976a89d5da1511ce

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