Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 23 01:19
    cquiroz commented #925
  • Oct 22 19:43
    julien-truffaut commented #925
  • Oct 22 19:43
    julien-truffaut reopened #925
  • Oct 22 19:32

    julien-truffaut on master

    Crosscompile core to dotty (#92… (compare)

  • Oct 22 19:32
    julien-truffaut closed #928
  • Oct 22 19:32
    julien-truffaut closed #925
  • Oct 22 19:32
    julien-truffaut commented #928
  • Oct 22 15:25
    cquiroz opened #928
  • Oct 22 13:21
    cquiroz assigned #925
  • Oct 22 07:20
    julien-truffaut commented #913
  • Oct 22 07:19
    julien-truffaut edited #927
  • Oct 22 07:19
    julien-truffaut edited #927
  • Oct 22 07:18
    julien-truffaut edited #913
  • Oct 22 07:18
    julien-truffaut edited #913
  • Oct 22 07:17
    julien-truffaut opened #927
  • Oct 22 07:15
    julien-truffaut opened #926
  • Oct 22 07:14
    julien-truffaut opened #925
  • Oct 21 12:04
    julien-truffaut commented #913
  • Oct 21 12:00

    julien-truffaut on gh-pages

    Deploy website Deploy website … (compare)

  • Oct 21 11:55

    cquiroz on master

    Update sbt-mdoc to 2.2.10 (#920) (compare)

Zsolt Donca
@zsolt-donca
this is since I upgraded from the 1.x line to the version 2.1.0
this is a major issue for me since I am on -Xfatal-warnings
Julien Truffaut
@julien-truffaut
hum it sounds like we have an unused import with the Lenses macro
Zsolt Donca
@zsolt-donca
do you have any idea on how to investigate this further? maybe how to find a workaround?
Julien Truffaut
@julien-truffaut
It would be useful if we could print the code produced by the macro, there must be some tools for this.
ritschwumm
@ritschwumm
"-Ymacro-debug-lite" would help i guess
i tend to avoid imports in macros, and use fully qualified names instead. this fixes shadowing issues, too...
nafg
@nafg
Actually the code I was looking at is more tricky
Zsolt Donca
@zsolt-donca
I already tried with "-Ymacro-debug-lite", but it gave me a mindnumbingly large output, because my project is quite large... and so far my attempts of reproducing this issue in an isolated environment have been futile
I'm still working on it, and will get back once I figure out something useful
nafg
@nafg
There are two fields of type String, and there's some other type that I'm using to set one field and in some cases the other field. I can't really build an instance of that type from the case class though
Gabriel Volpe
@gvolpe
@zsolt-donca try -Wmacros:after just in case, not sure if that could help
nafg
@nafg
The fields are a full address string, and a summary string (the neighborhood or just the street name). The other type is an Address class obtained from a geocoding API
Maybe I'm asking for a square circle, but on the one hand I want to decouple the UI for each field then compose them together, but on the other hand the UI for the first field potentially affects the second field
Zsolt Donca
@zsolt-donca
@gvolpe it gave me bad option: '-Wmacros:after' :(
I am on Scala 2.12.10
Zsolt Donca
@zsolt-donca
I've found this alternative: -Ywarn-macros:after, which the compile accepts, but produces the same thing
and the option -Ywarn-macros:none actually makes the compilation pass... this seems like a reasonable workaround
does anybody know of any downside of using -Ywarn-macros:none?
Zsolt Donca
@zsolt-donca
FYI I've already found some downsides to -Ywarn-macros:none: it messes with the compiler's ability to detect whether symbols such as local variables are parameters are used inside macros (such as logger.info statements of com.typesafe.scalalogging), and it gives me plenty of false-positives, stating that things aren't used while they are used inside logger statements...
Zsolt Donca
@zsolt-donca
thanks everybody for your help! using -Ymacro-debug-lite I was able to see that the only imports inside the generated code were not even related to Monocle, and they were in fact caused by some methods in the companion object being transformed by the compiler plugin https://github.com/augustjune/context-applied
I don't understand why the warning was given to me on the line of the @Lenses annotation
Julien Truffaut
@julien-truffaut
@zsolt-donca glad you managed to go to the bottom of it.
nafg
@nafg
Here's a thought about how to achieve what I was after above
I use scalajs-react StateSnapshot's ability to "zoom in" via a Lens, quite a lot
However often setting one field in a case class should result in modifying another field
Not a monocle-specific question, is there a principled way of defining, or at least thinking about, such relationships between fields
One example I have right now is that when field A is set, if field B has not been set it should get a default value based on what A is being set to
Has anyone invented some first-class abstraction for such inter-field dependencies?
I suppose I could factor it differently -- maybe there should be one field that is (A, inferredB) and another that is Option(explicitlySetB), and then actualB is simply calculated as maybeExplicitlySetB.getOrElse(inferredB)
Alternatively it should never use the inferred value automatically, but the B field could have a button to populate it by inferring it from A
There are two fields of type String, and there's some other type that I'm using to set one field and in some cases the other field. I can't really build an instance of that type from the case class though
The fields are a full address string, and a summary string (the neighborhood or just the street name). The other type is an Address class obtained from a geocoding API
Maybe I'm asking for a square circle, but on the one hand I want to decouple the UI for each field then compose them together, but on the other hand the UI for the first field potentially affects the second field
Basically I could make an intermediate data type that more cleanly separates the two things
So in addition to the original form, (fullAddressString, areaString),
there is another form, ((fullAddressString, computedAreaString), explicitlyProvidedAreaString)
Then, I could make a lens from the first for to the second
nafg
@nafg
where get sets computedAreaString to either nothing or areaString, not sure if it matters, and explicitlyProvidedAreaString to areaString. It might be an Option type in which case "" becomes None
And set will set areaString to either explicitlyProvidedAreaString if it is defined, otherwise computedAreaString
and of course fullAddressString to its namesake
Then I can "zoom" the original state to the more-cleanly-separated state, and then the UI can easily map each field of the tuple to a separate bit of UI
Julien Truffaut
@julien-truffaut
I am not entierly sure I follow, if you could make a gist it would be very useful.
nafg
@nafg
@julien-truffaut which part?
I haven't written it yet, I just thought of it now
The UI abstraction isn't the point, you can ignore that really
I guess the lens bit would be something like
    case class Original(full: String, area: String)
    case class SimplifiedGeoAddress(full: String, areaFromGeoAddress: String)
    case class Separated(simplied: SimplifiedGeoAddress, explicitArea: String)
nafg
@nafg
val get: Original => Separated = original => Separated(SimplifiedGeoAddress(original.full, original.area), original.area)
val set: Separated => Original => Original =
  s => o =>
    Original(s.simplified.full, s.explicitArea.trim match { case "" => o.area  case a => a })
val lens = Lens(get)(set)
val tupleIso: Iso[Separated, (SimplifiedGeoAddress, String)] = GenIso.fields[Separated]
val separatedState = originalState.zoomStateL(lens)
val addressAutocompleteState: StateSnapshot[SimplifiedGeoAddress] = separatedState.zoomStateL(fields.first)
val areaTextFieldState: StateSnapshot[String] = separatedState.zoomStateL(fields.second)
nafg
@nafg
The actual code would be slightly different since it would use something slightly different from StateSnapshot but that's not important
What's important is now the address autocomplete UI doesn't need to worry about when to overwrite the actual area field; it always sets areaFromGeoAddress, unconditionally
And of course the area input only deals with the String and string setter that update explicitArea
The concern of when to overwrite the area field is handled at a higher layer, in val lens above
I called it SimplifiedGeoAddress because it's a simplified version of what the TomTom API actually returns, which I model like this:
case class Address(streetNumber: Option[String],
                   streetName: Option[String],
                   municipality: Option[String],
                   countrySecondarySubdivision: Option[String],
                   countrySubdivision: Option[String],
                   countrySubdivisionName: Option[String],
                   postalCode: Option[String],
                   extendedPostalCode: Option[String],
                   countryCode: String,
                   country: String,
                   countryCodeISO3: String,
                   freeformAddress: String,
                   localName: Option[String])
nafg
@nafg
I can't construct one of those from Original so I need a diluted version of it so I can go in both directions