Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 09 2020 17:00
    tindzk commented #37
  • Mar 08 2020 01:03
    raquo commented #37
  • Mar 07 2020 21:19
    raquo edited #37
  • Mar 07 2020 21:15
    raquo edited #37
  • Mar 07 2020 21:12
    raquo edited #37
  • Mar 07 2020 21:12
    raquo edited #37
  • Mar 07 2020 21:11
    raquo edited #37
  • Mar 07 2020 21:10
    raquo opened #37
  • Jul 10 2019 07:26

    tindzk on v0.2.1

    (compare)

  • Jul 10 2019 07:26

    tindzk on master

    Build: Publish v0.2.1 Build: Change version to v0.2.2… (compare)

  • Jul 09 2019 14:59

    tindzk on manual

    (compare)

  • Jul 09 2019 14:59

    tindzk on master

    Manual: Add example for encodin… Merge pull request #36 from spa… (compare)

  • Jul 09 2019 14:59
    tindzk closed #36
  • Jul 09 2019 14:59

    tindzk on scala213

    (compare)

  • Jul 09 2019 14:58

    tindzk on master

    Build: Add support for Scala 2.… Merge pull request #35 from spa… (compare)

  • Jul 09 2019 14:58
    tindzk closed #35
  • Jul 09 2019 14:57

    tindzk on parse-opt-elems

    (compare)

  • Jul 09 2019 14:57

    tindzk on master

    Route: Fix parsing of optional … Merge pull request #34 from spa… (compare)

  • Jul 09 2019 14:57
    tindzk closed #34
  • Jul 09 2019 14:57

    tindzk on redundant-amp

    (compare)

Darren Gibson
@zarthross
we convert to one of two CanFill types, the first has the single arg version and the second has teh multi arg fill
we use the L type parameter to check
something like SOMET :: HNil vs SOMETS :: SOMEOTHERThatsnotHNIL
Tim Nieradzik
@tindzk
Do you mean that we should just make fill take a HList? And provide implicit conversions?
Darren Gibson
@zarthross
leave fill the way it is, but make an 2 extensions on Route based on the ROUTE type, one that takes a fill of 1 arg, the other that takes more than 1 arg.
add limites on the conversion of Route based on teh number of Arg type params
Tim Nieradzik
@tindzk
Hm. That's an interesting idea. So we just decide which fill to take based on the number of arguments in ROUTE?
Darren Gibson
@zarthross
yeah
thats the idea
Tim Nieradzik
@tindzk
Yes, that should work, but I suspect IntelliJ may still complain.
Darren Gibson
@zarthross
its not using a dynamic call
intellij handles implicits just fine
Tim Nieradzik
@tindzk
Even if the implicit itself uses some Shapeless functionality?
Darren Gibson
@zarthross
the implicit conversion is just using an implicit parameter
the idea is, only one of the 2 extension classes will find an implicit parameter depending on how many args their are.
i don't honestly know if it'll work, but its worth a try.
Tim Nieradzik
@tindzk
Ok, I will have to try it out tomorrow. Already spent all day with Shapeless :)
Darren Gibson
@zarthross
haha, yeah.. i spent just half the week figureing out how to get the that L/ARGS type parameter to infer correctly.
and then on how to get ProductArgs to work
*which is why i went with 'fill' instead of 'apply', btw, was a compromise not a design choice.
Tim Nieradzik
@tindzk
Yeah, it's a lot of fun and the code is incredibly concise. The test cases are much longer. :)
Darren Gibson
@zarthross
i used scoverage to try and get my coverage up
Tim Nieradzik
@tindzk
Can we rename fill? The first time I saw it, I didn't know what it was supposed to do.
Darren Gibson
@zarthross
definately
Tim Nieradzik
@tindzk
Can we add Scoverage as an sbt plugin?
Darren Gibson
@zarthross
sure
Tim Nieradzik
@tindzk
Last time I checked it didn't work that well with Scala.js.
Darren Gibson
@zarthross
still doesn't
i just added it to my globals
scoverage/sbt-scoverage#101
since all the tests i was doing was in shared, i just ran them on the JVM
Tim Nieradzik
@tindzk
If we had just one version of fill, we could rename it back to apply.
Darren Gibson
@zarthross
that would be better, we'll see what we can do.
i'll play with the fill/fillN issue tonight, i'll let you know by tomorrow morning my results.
Tim Nieradzik
@tindzk
Awesome, thanks.
What task should we tackle next?
I am wondering whether we should also support parsing URLs like http://a/b/c. I think your split() will misbehave.
We should also allow "a" / "b" (relative paths).
Darren Gibson
@zarthross
Been wondering those 2 things myself.
i was mostly thinking in the terms of what a javascript router would be concerned with, and thats everything after the port in the URL
so, the parse will just ignore the http://host:port/ part
Darren Gibson
@zarthross
I didn't get around to fixing the .fill issue yesterday. I'll have some more time this afternoon so i'll take another look.
Tim Nieradzik
@tindzk
@zarthross I extended the evidence chain to also check the number of route parameters as per your suggestion. As long as fill and fillN have different names, the proofs hold. But if I rename both methods to the same name, it fails with a confusing compilation error. Could you have a look at it?
Tim Nieradzik
@tindzk
Ok, I understand the error now. It selects fill with TP and then cannot prove that ParamsCount != 1, thus it fails. I expected it to fall back to the fill method with a single argument, but it doesn't.
The same happens when I move those two methods to an implicit class.
Tim Nieradzik
@tindzk
I am pretty sure it can be solved with low-priority implicits.
Tim Nieradzik
@tindzk
The problem lies in how the method gets selected. It doesn't seem to ever fall back to the other fill function. The method with Product is chosen because it is more concrete than T.
Lorenzo Gabriele
@lolgab
Hi everyone :)
Is this library maintained? Are PRs reviewed/merged ? Because I'm searching a routing solution for Scala Native and found this :)
Lorenzo Gabriele
@lolgab
In case you do accept PRs I created one to update Scala Native that simplifies the build a bit too: sparsetech/trail#41
Lorenzo Gabriele
@lolgab
Hi @tindzk,
I wanted to update trail to Scala Native 0.4.0 . Scalatest is your favourite testing library or it's used in trail for historical reasons? If it's the latter, which is your favourite testing library?
Because I prefer to migrate your tests instead of updating Scalatest :-D