ScalaCheck 1.14.0 was just released with support for deterministic testing using seeds. Some folks have asked for examples, so I wanted to produce a Gist to help people use this feature.
These examples will assume the following imports:
#!/bin/bash | |
# bash generate random alphanumeric string | |
# | |
# bash generate random 32 character alphanumeric string (upper and lowercase) and | |
NEW_UUID=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1) | |
# bash generate random 32 character alphanumeric string (lowercase only) | |
cat /dev/urandom | tr -dc 'a-z0-9' | fold -w 32 | head -n 1 |
I'm going to do something that I don't normally do, which is to say I'm going to talk about comparative benchmarks. In general, I try to confine performance discussion to absolute metrics as much as possible, or comparisons to other well-defined neutral reference points. This is precisely why Cats Effect's readme mentions a comparison to a fixed thread pool, rather doing comparisons with other asynchronous runtimes like Akka or ZIO. Comparisons in general devolve very quickly into emotional marketing.
But, just once, today we're going to talk about the emotional marketing. In particular, we're going to look at Cats Effect 3 and ZIO 2. Now, for context, as of this writing ZIO 2 has released their first milestone; they have not released a final 2.0 version. This implies straight off the bat that we're comparing apples to oranges a bit, since Cats Effect 3 has been out and in production for months. However, there has been a post going around which cites various compar
Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.
(credit here is very much due to Fabio Labella, who's incredible Scala World talk describes these ideas far better than I can)
Consider the following three functions
Tageless Final interpreters are an alternative to the traditional Algebraic Data Type (and generalized ADT) based implementation of the interpreter pattern. This document presents the Tageless Final approach with Scala, and shows how Dotty with it's recently added implicits functions makes the approach even more appealing. All examples are direct translations of their Haskell version presented in the Typed Tagless Final Interpreters: Lecture Notes (section 2).
The interpreter pattern has recently received a lot of attention in the Scala community. A lot of efforts have been invested in trying to address the biggest shortcomings of ADT/GADT based solutions: extensibility. One can first look at cats' Inject
typeclass for an implementation of [Data Type à la Carte](http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesA
git checkout --orphan temp_master | |
git rm -rf . | |
git commit --allow-empty -m 'Make initial root commit' | |
git rebase --onto temp_master --root master | |
git branch -D temp_master |
Copyright © 2016-2018 Fantasyland Institute of Learning. All rights reserved.
A function is a mapping from one set, called a domain, to another set, called the codomain. A function associates every element in the domain with exactly one element in the codomain. In Scala, both domain and codomain are types.
val square : Int => Int = x => x * x
## Override config for setting CRT resolutions per core or per game. | |
## Place this in $rgui_config_directory/[Core Name]/[Core Name].cfg or $rgui_config_directory/[Core Name]/[Content Filename].cfg to have it loaded automatically when override loading is enabled | |
## e.g $rgui_config_directory/MAME/mslug.cfg or $rgui_config_directory/Mednafen PSX/Mednafen PSX.cfg | |
# Fullscreen resolution. Resolution of 0 uses the resolution of the desktop. | |
# Note, you must create the modeline in your OS video driver settings for this to work. | |
video_fullscreen_x = 3840 | |
video_fullscreen_y = 480 | |
# Refresh rate of the resolution mode. |
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.