Skip to content

Instantly share code, notes, and snippets.

Avatar
😱
I might take a week to respond. Or a month.

Jakub Kozłowski kubukoz

😱
I might take a week to respond. Or a month.
View GitHub Profile
View stackoverflow.txt
error: can't decompile /Users/kubukoz/dev/scala-scripts/.bloop/root/bloop-bsp-clients-classes/classes-Metals-nKCKEcyTSeqo2gMsi6lw1w==/META-INF/semanticdb/src/main/scala/com/kubukoz/ForceActivate.scala.semanticdb
java.lang.StackOverflowError
at scala.runtime.Statics.anyHash(Statics.java:127)
at scala.collection.mutable.HashMap.get(HashMap.scala:78)
at scala.meta.internal.metap.SymbolInformationPrinter$InfoNotes.visit(SymbolInformationPrinter.scala:377)
at scala.meta.internal.metap.SymbolInformationPrinter$InfoPrinter.pprint(SymbolInformationPrinter.scala:267)
at scala.meta.internal.metap.SymbolInformationPrinter$InfoPrinter.pprintRef(SymbolInformationPrinter.scala:254)
at scala.meta.internal.metap.SymbolInformationPrinter$InfoPrinter.prefix$1(SymbolInformationPrinter.scala:187)
at scala.meta.internal.metap.SymbolInformationPrinter$InfoPrinter.normal$1(SymbolInformationPrinter.scala:247)
at scala.meta.internal.metap.SymbolInformationPrinter$InfoPrinter.$anonfun$pprint$25(SymbolInformationPrinter.scala:2
@kubukoz
kubukoz / showProcessedCount.scala
Created Mar 15, 2021
Periodically show the amount of elements produced by an fs2 stream
View showProcessedCount.scala
def showProcessedCount[F[_]: Concurrent: Timer, A]: Pipe[F, A, A] = stream =>
fs2.Stream.eval(Ref[F].of(0)).flatMap { count =>
stream.chunks
.evalMap { chunk =>
count.update(_ + chunk.size).as(chunk)
}
.flatMap(fs2.Stream.chunk)
.concurrently(
fs2.Stream
@kubukoz
kubukoz / semiauto-vs-auto.md
Created Oct 5, 2021
Semiauto vs auto derivation
View semiauto-vs-auto.md

You mention that you would only use circe auto derivation in only a few limited cases - may I ask why? It looks like you are using semi-auto derivation instead. Why is this better/more stable?

The difference is where the derivation happens - in semiauto, you only have one place where a codec for a given type will be derived: at definition site, which is usually the companion object (it's the companion object in our case, but it could be anywhere really - point still stands that it's easier to track). In auto derivation, codecs are derived as needed by the usage - e.g. in the endpoint definitions or in a controller (depending on the tech stack you use). The problem here is that you need all the codecs of all the fields and all their fields (...and so on...) to be available there.

The centralization of the codecs in Semiauto mode allows us to switch to a different format at any time, while keeping the representation consistent across all usages of it. Additionally, it allows us to test the codec logic witho

View foo.sc
//> using scala "3.1.1"
//> using option "-Xfatal-warnings"
enum Foo { case Bar, Baz }
val x: Foo = ???
val y = x match { case Foo.Bar => 42 }
View eithert-scala3.scala
//>using scala "3.1.1"
//>using lib "org.typelevel::cats-core:2.7.0"
//>using lib "org.typelevel::cats-effect:3.3.9"
sealed trait Error extends Product with Serializable
object Error {
case object C extends Error
}
object demo {
View with-custom-daemon.txt
# scala-cli --bloop-daemon-dir $(pwd)/./bloop-socket --bloop-bsp-socket $(pwd)/./bloop-socket/socket --bloop-bsp-protocol local -v -v -v -v . .txt
Checking for a running Bloop server at /Users/kubukoz/projects/playground/./bloop-socket ...
Attempting to connect to Bloop server /Users/kubukoz/projects/playground/./bloop-socket ...
Connection attempt result: None
Checking for a running Bloop server at /Users/kubukoz/projects/playground/./bloop-socket ...
Attempting to connect to Bloop server /Users/kubukoz/projects/playground/./bloop-socket ...
Connection attempt result: None
Bloop daemon status: not running
Starting Bloop 1.4.19 at /Users/kubukoz/projects/playground/./bloop-socket using JVM /Users/kubukoz/Library/Caches/Coursier/arc/https/github.com/adoptium/temurin17-binaries/releases/download/jdk-17%252B35/OpenJDK17-jdk_x64_mac_hotspot_17_35.tar.gz/jdk-17+35/Contents/Home/bin/java
View scala-cli -v -v -v -v . .txt
Checking for a running Bloop server at /Users/kubukoz/Library/Caches/ScalaCli/bloop/daemon ...
Attempting to connect to Bloop server /Users/kubukoz/Library/Caches/ScalaCli/bloop/daemon ...
Connection attempt result: None
Checking for a running Bloop server at /Users/kubukoz/Library/Caches/ScalaCli/bloop/daemon ...
Attempting to connect to Bloop server /Users/kubukoz/Library/Caches/ScalaCli/bloop/daemon ...
Connection attempt result: None
Bloop daemon status: not running
Starting Bloop 1.4.19 at /Users/kubukoz/Library/Caches/ScalaCli/bloop/daemon using JVM /Users/kubukoz/Library/Caches/Coursier/arc/https/github.com/adoptium/temurin17-binaries/releases/download/jdk-17%252B35/OpenJDK17-jdk_x64_mac_hotspot_17_35.tar.gz/jdk-17+35/Contents/Home/bin/java
Fetching List(io.github.alexarchambault.bleep:bloop-frontend_2.12:1.4.19)
Found 119 artifacts:
View http4scors.scala
// using lib org.http4s::http4s-ember-server:0.23.7
// using lib org.http4s::http4s-blaze-server:0.23.7
// using lib org.http4s::http4s-circe:0.23.7
// using lib org.http4s::http4s-dsl:0.23.7
// using scala 2.13.7
// using options -Xsource:3.0 -Wunused:imports -deprecation
import cats.effect.IO
import cats.effect.IOApp
import io.circe.Decoder
import org.http4s.HttpRoutes
View httpcirce.scala
// using lib org.http4s::http4s-ember-server:0.23.7
// using lib org.http4s::http4s-circe:0.23.7
// using lib org.http4s::http4s-dsl:0.23.7
// using scala 2.13.7
// using options -Xsource:3.0 -Wunused:imports -deprecation
import cats.effect.IO
import cats.effect.IOApp
import io.circe.Decoder
import org.http4s.HttpRoutes
import org.http4s.circe.CirceEntityCodec._
View on tf and zio in 2021.md

Why you prefer cats instead of zio? TF? It’s looks like zio ecosystem more widely and zio 2.0 has better performance What do you think?

Great question!

Performance-wise, it really depends on what you're doing. The problem with benchmarks (including the ones posted for ZIO and Cats Effect) is that they apply only to abstract situations, which are often nothing like what you see in real applications. A great write-up on this problem by Daniel Spiewak here, he wrote it better than I ever could: https://gist.github.com/djspiewak/f4cfc08e0827088f17032e0e9099d292

Also, this is not an app meant for production - I don't care that much about performance under load because there will be no load. And individual operations will often be bounded by I/O anyway, so the efficiency of the underlying runtime is likely not going to make a noticeable difference in use. Then again, both the client and server are JVM apps, so even the start-up penalty of the client will slow us down than picking even the least efficient e