paulp

// Quasiquoted excerpt 

  def cdef = q"""
    class $ClassName[..$classTypeParams](..$primaryParams) extends ..$classParents {
      ..$primaryAccessors

      def get = this
      def isEmpty = ${quasi.isEmpty}
      def copy(..$primaryWithDefaults) = $ObjectName(..$primaryNames)

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

mucaho

// After that we just create the GUI Actors with a Props with the correct dispatcher set:
val javaFxActor = context.actorOf(Props[JavaFxActor].withDispatcher("javafx-dispatcher"), "javaFxActor")
val swingActor = context.actorOf(Props[SwingActor].withDispatcher("swing-dispatcher"), "swingActor")

// Done! Now all messages processed by the new actor will be executed by the Swing/JavaFX Event Dispatch Thread, enjoy!

kevin-smets

Default

Powerlevel10k

edsu

var w = new EventSource("https://wikipedia-edits.herokuapp.com/sse");
w.onmessage = function(event) {
  change = JSON.parse(event.data);
  console.log(change);
}

pchiusano

When creating streams from an asynchronous process, the idiomatic thing is to create a stream from that process at the earliest possible stage, rather than using a queue to invert control after the fact. See the creating streams examples - generally, you just use the Process.eval and Process.repeatEval functions to build a stream by running some asynchronous task repeatedly.

That said, if you have some existing logic that you need to bind to that's already based on callbacks and side effects, you can use the functions in scalaz.stream.async. Here's an example, using a queue to invert control:

import scalaz.stream.async

val (q, src) = async.queue[Int]

// Thread 1

fancellu

package com.felstar.xqs.example

import com.felstar.xqs.XQS._
import com.felstar.xqs.XQS.AllImplicits._
import xml.PrettyPrinter

import com.xqj2.XQConnection2

object BaseXEmbeddedXQS extends App {

ScalaWilliam

<Human>
  <title>Mr.</title>
  <name>Johnny</name>
  <coats>
    <Coat>
      <brand>BOSS</brand>
    </Coat>
    <Coat>
      <brand xsi:nil="true"/>
    </Coat>

fancellu

package com.barclays.buyit.mgs

import java.util.Date
import com.espertech.esper.client._
import scala.beans.BeanProperty

object EsperTest extends App {

  
case class Tick(@BeanProperty symbol:String,@BeanProperty price:Double,@BeanProperty timestamp:Long=System.currentTimeMillis) 

ato

package pavo;

import java.io.*;
import java.util.*;
import javax.script.*;

public class ERB {
    
    static ScriptEngine jruby = initializeJRuby();