lamdor

package eg

import org.apache.avro._
import generic.{GenericDatumWriter}
import reflect.{ReflectDatumWriter}
import specific.{SpecificDatumWriter}
import io.{BinaryEncoder, JsonEncoder}

import java.io.ByteArrayOutputStream
import java.lang.reflect.{Method => JMethod}

rajish

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" [
    <!-- provide ID type information even for parsers which only read the internal subset -->
    <!ATTLIST xs:schema id ID #IMPLIED>
    <!ATTLIST xs:complexType id ID #IMPLIED>
    <!ATTLIST xs:complexContent id ID #IMPLIED>
    <!ATTLIST xs:simpleContent id ID #IMPLIED>
    <!ATTLIST xs:extension id ID #IMPLIED>
    <!ATTLIST xs:element id ID #IMPLIED>
    <!ATTLIST xs:group id ID #IMPLIED>

paulp

Hello scala, my old friend
I've come to take you home again
Because a feature slowly creeping
left me plagued with doubts and weeping
and the version that was tagged in the repo
just has to go
it lacks the signs of soundness

On sleepless nights I hacked alone
applying ant and other tools of stone

lelandbatey

Description

This simple script will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.

The script is here:

#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"

Results

munificent

You appear to be advocating a new:

[ ] cloud-hosted [ ] locally installable [ ] web-based [ ] browser-based [ ] language-agnostic
[ ] language-specific IDE. Your IDE will not succeed. Here is why it will not succeed.

You appear to believe that:
[ ] Syntax highlighting is what makes programming difficult
[ ] Garbage collection is free
[ ] Computers have infinite memory
[ ] Nobody really needs:

djspiewak

Introduction to scalaz-stream

Every application ever written can be viewed as some sort of transformation on data. Data can come from different sources, such as a network or a file or user input or the Large Hadron Collider. It can come from many sources all at once to be merged and aggregated in interesting ways, and it can be produced into many different output sinks, such as a network or files or graphical user interfaces. You might produce your output all at once, as a big data dump at the end of the world (right before your program shuts down), or you might produce it more incrementally. Every application fits into this model.

The scalaz-stream project is an attempt to make it easy to construct, test and scale programs that fit within this model (which is to say, everything). It does this by providing an abstraction around a "stream" of data, which is really just this notion of some number of data being sequentially pulled out of some unspecified data source. On top of this abstraction, sca

djspiewak

Collections Redesign Proposal

I'm going to start off by motivating what I'm doing here. And I want to be clear that I'm not "dissing" the existing collections implementation or anything as unproductively negative as that. It was a really good experiment, it was a huge step forward given what we knew back in 2.8, but now it's time to learn from that experiment and do better. This proposal uses what I believe are the lessons we can learn about what worked, what didn't work, and what is and isn't important about collections in Scala.

This is going to start out sounding really negative and pervasively dismissive, but bear with me! There's a point to all my ranting. I want to be really clear about my motivations for the proposal being the way that it is.

Problems

Generic Interfaces