Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 05 18:42

    larsrh on development

    remove outdated assets (compare)

  • Jun 05 18:41

    larsrh on development

    remove merchandise section (compare)

  • May 28 14:28

    larsrh on bundler

    (compare)

  • May 28 14:28

    larsrh on development

    Bump nokogiri from 1.11.3 to 1.… Merge pull request #304 from ty… (compare)

  • May 28 14:28
    larsrh closed #304
  • May 26 15:59
    ChristopherDavenport commented #305
  • May 26 15:59
    ChristopherDavenport commented #305
  • May 26 15:59
    ChristopherDavenport commented #305
  • May 26 15:47
    ChristopherDavenport opened #305
  • May 24 20:12
    travisbrown commented #101
  • May 24 19:06
    rossabaker commented #101
  • May 24 07:42
    travisbrown commented #101
  • May 19 04:42
    dependabot[bot] labeled #304
  • May 19 04:42
    dependabot[bot] opened #304
  • May 19 04:42

    dependabot[bot] on bundler

    Bump nokogiri from 1.11.3 to 1.… (compare)

  • May 08 13:36

    tpolecat on tpolecat-patch-1

    (compare)

  • May 08 13:36
    tpolecat closed #303
  • May 08 13:36
    tpolecat commented #303
  • May 08 13:33
    tpolecat synchronize #303
  • May 08 13:33

    tpolecat on tpolecat-patch-1

    Update 2021-05-05-discord-migra… Merge pull request #302 from ty… Merge branch 'development' into… (compare)

Oleg Pyzhcov
@oleg-py
you can still accomplish the same with concrete IO and discipline but it's much too easy to slip into using ffi everywhere
Fabio Labella
@SystemFw
yeah
code written in concrete IO by people that know how to write tagless final code is probably just as nicely separated
but it's another layer of discipline which is nice to avoid if you can
Oleg Pyzhcov
@oleg-py
in concrete IO you can always use IO.apply
mpilquist
@mpilquist:matrix.org
[m]
the problem i have with the discipline argument is that folks can equally use it to justify no IO at all
Fabio Labella
@SystemFw
I wouldn't say "equally", but it's a good point
Oleg Pyzhcov
@oleg-py
but in abstract F you'd run into a fact that now you need to propagate that damn new constraint quite a lot
which at least for me stops and makes me write the code purely cause it's equally painful anyway
Fabio Labella
@SystemFw

I wouldn't say "equally",

at least not if you accept that IO isn't just a marker for "effects here", which is certainly not an easy point to get across at first, although I start my training from that point and the programs-as-values perspective

Oleg Pyzhcov
@oleg-py
pain-driven development
Fabio Labella
@SystemFw

but in abstract F you'd run into a fact that now you need to propagate that damn new constraint quite a lot

eventually I'm going to start playing with some sort of Free structure again and have the best of both worlds. Just have to figure out how to make composition not suck :P (but the thing is, defining something like fs2 or Resource will still need tagless)

Adam Rosien
@arosien
my answers are like rob's (from my book):
  1. Effect polymorphism
    It is now the caller of combineStuff who decides what the effect type will be, not the definition of combineStuff itself. combineStuff may be called with IO arguments, or Future or Option or indeed any Monad. Our method can handle them all, without having to care what their concrete type is.
  2. Error-reduction
    The possible implementations of combineStuff is severely restricted because the types of the arguments are abstract: we only know that e1 and e2 are of type F, and the only methods we can invoke are those provided by the Monad[F] typeclass instance. This reduces the possibilities of errors, because we can’t do anything except what the constraints (typeclass instances) allow. There is literally less that can go wrong.
Fabio Labella
@SystemFw
ultimately there are only two ways to abstract: pass behaviour down (DI, OO, tagless, modules) or return descriptions up (Free, IO if you don't need any deps, Stream, etc), we just bounce back and forth every 3-4 years or so.
Alex Nedelcu
@alexelcu:matrix.org
[m]

@neko-kai: thanks for the link, will explore it 👍 I'm basically interested in Scala 3, as that's the future, although I wouldn't like something that can break in future versions.

I'm also thinking that I could just rely on Scala 3 giving proper import hints. I noticed that it does that, but I have no idea how reliable it is.

Kai
@neko-kai
New goodies ahead of time (maybe) typelevel/kind-projector#188
nafg
@nafg
How do nontrivial scala projects tend to maintain sample projects? (In Slick there's a lot of code in the SBT build dealing with it, which I'd like to simplify or eliminate, and I'm trying to find out what other people do.) For instance, do sample projects each get their own repo or are they subdirectories in the same repo? If the latter, are they part of the main SBT build, do they have their own SBT build, or both? In any case do you automate keeping them up to date, and if so, how?
Rob Norris
@tpolecat
Several of my repos have an examples project that’s just another module (not published). If your sample projects are larger then each could be its own module. I think it’s important to build them all together though so they don’t go stale.
nafg
@nafg
@tpolecat thanks. In Slick it does that but there's a bunch of code there so that sample projects also work as their own build
That is, you could copy the subdirectory to a new project with that being the base directory. (Or, you can cd into it and run sbt from there.)
But somehow that requires a bunch of complexity
I guess a lot of projects have giter8 repos... how do they keep those up to date?
In a way it seems more logical to make sample projects standalone projects, after all that's what they represent, but then as you said how do you keep it from going stale
Then again nowadays we have Scala Steward
nafg
@nafg
I suppose a benefit of the sample being part of the build is the reverse: keeping the project from breaking samples to easily. But that's really what tests are for
Rob Norris
@tpolecat
Yeah I don’t have any g8 templates because they’re impossible to keep up to date.
nafg
@nafg
Why are people dropping 3.0.0-RC3 when they publish 3.0.0, it breaks dependencyUpdates -- if you're on RC3 you don't see the new version, and if you change to 3.0.0 your build breaks and you don't know how to update without finding each library online individually
Seth Tisue
@SethTisue
I think some library maintainers didn't even think about that — it's a fairly subtle point and not a super well-known one. Also, the farther you are from the root of the ecosystem, the harder it can be to maintain that policy without having to complicate your build with version conditionals. At some point it's pretty tempting to just throw up your hands.
A lot of libraries didn't drop RC3 when publishing for 3.0 — so the news on this wasn't all bad.
nafg
@nafg
seems like cats-effect and circe did
Rob Norris
@tpolecat
Circe has never published for more than one Scala 3 version.
nafg
@nafg
anyway it's a milestone release so sbt-updates wouldn't show it anyway I don't think
Seth Tisue
@SethTisue
maybe Travis is a bit out of the loop, like did anyone ever actually ask him to keep two versions? I've been trying to educate people about this one maintainer at a time, but that's a neverending task :-)
nafg
@nafg
@tpolecat (and anyone else) re the question about sample projects, follow-up question: Have you ever wanted the sample to be valid as a standalone build?
Rob Norris
@tpolecat
Hm, no. In that case it seems like a standalone project might work better.
I work on library code so all my examples are really just "how to use feature X" or "how to work around bug Y" as opposed to standalone things that you might want to use a starting point for a project.
You might see what the current story is re: scala-steward + g8. It's possible that ss will keep stuff up to date in g8 projects now. It's been a few years since I looked.
Seth Tisue
@SethTisue
Scala Steward does update g8 templates.
Seth Tisue
@SethTisue
ah, but imperfectly. it's explained at scala-steward-org/scala-steward#1286
Travis Brown
@travisbrown
@SethTisue I don't think I've ever cross-published anything for multiple language pre-releases, and given that the Scala 3 release process for Circe is still manual, I wasn't inclined to start now. Expecting adopters to coordinate updates seems completely reasonable to me (unless they want to pay for not having to do that).
Seth Tisue
@SethTisue
@travisbrown fair enough — that's a reasonable decision for maintainers to make. I'm just encouraging people to at least consider doing two, because often it wasn't even considered
mpilquist
@mpilquist:matrix.org
[m]
FWIW I dropped RC3 when releasing for final
Rob Norris
@tpolecat
same
nafg
@nafg
How come?
Guillaume Martres
@smarter
@djspiewak I believe lampepfl/dotty#12660 might fix the weird issues you saw trying to use the scala 2 version of cats-mtl from scala 3 (huge props to @kubukoz:matrix.org for the minimization!)
Sergey Torgashov
@satorg
hi guys. I'm struggling to figure out or find any examples on how to integrate spec2 and scalacheck-effect. Could you provide me with any hints on that? thanks!
daenyth
@daenyth:matrix.org
[m]
What part? Is it that you need to have your tests returning IO[Assertion] or something like that? I'd check the cats-effect-testing, I know it has specs2 integration
Sergey Torgashov
@satorg
@daenyth:matrix.org indeed, cats-effect-testing-spec2 works fine, but if I use the conversions it provides for specs2 inside one of the specs2's prop block, then each property run gets executed synchronously. On the other hand scalacheck-effect allows to compose all property runs into a single IO (of any other F) and execute the unsafe sync run only once for all property runs.
But seems there's no out-of-the-box integration between scalacheck-effect and specs2
daenyth
@daenyth:matrix.org
[m]
hmm, I'd open a ticket on one of the projects