-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"could not find Lazy implicit value" on incremental compile #38
Comments
Hi, thanks for reporting. I think this is more a problem of the way the incremental build works, though… |
Hi, as I experienced lately, the problem also occures in full rebuilds, but after 2 or 3 tries usually succeeds to build it. Is there some kind of nondeterministic algorithm in the build process? |
According to this discussion with Miles: https://gitter.im/milessabin/shapeless?at=57c7f646d52261ec34463b0a |
Thanks, I have tried the typelevel scala compiler.
Compilation in activator seems to work, at least I could not reproduce the problem. |
Do you also have the problem when you compile from activator without using typelevel/scala? |
Well, I tried to compile with activator on a linux machine and the problem also occures with typelevel compiler:
|
Can you share a minimal test case that reproduces the problem? |
I'm running into what seems to be the same issue even after switching to the typelevel compiler. Going to try to create a simple standalone repo that reproduces the issue and if I'm successful will post a link to it here. |
I would be grateful if you could make a test case. I tried to isolate the problem, but unfortunately the problem disappeared when I made the application simpler. I suspect that the problem is related to the complexity of other codes that might influence the order/mode of compilation of the Json macros. Some additional info in my case: I use play Json formatter and the derived codecs mixed, and the case classes (that are converted to Json) are spread in multiple source files. Usually two or three tries of compiling make the problem go away. |
@akitaylor I stopped getting this error when I completely eliminated Play And now I'm having trouble reproducing the issue even when I start incrementally reverting from |
Hi, Anyone had any luck solving this issue? Thanks! |
Unfortunatelly I could not create a test case to reproduce the problem,
as it only seems to occur in complex compilation process (eg. more than
200 source files). The problem is still present after migration to Play
2.6, but only after cleaning the project. The second compilation is
usually succeessful.
Regards,
Akos
2018. 02. 20. 17:07 keltezéssel, yarondav írta:
…
Hi,
Anyone had any luck solving this issue?
We're also running into this with v4.0.0 version alongside Play 2.6.x.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#38 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHryV4eHl0Vo0PUOep2wh-5lakT0NR_Mks5tWu3DgaJpZM4Ji2k8>.
|
Strange issue. Just get across to it. I'll see what I can do for it. |
I found that |
And also remember to put every |
Hi Wayne! Thanks for the investigation. In our system the attached file is the trigger of the problem. As you can see we use sealed abstract classes and case classes inherit these. It is strange that the problem only occurs after SBT clean, the second compilation is usually successful. It is also an important circumstance, that the project contains 200+ scala classes, it might not show up in smaller projects. Here is what we get: |
I'm not sure. But firstly you can try seperating each Secondly you can try to make every And also the sequence of My problem is solved. But I don't have enough |
Hi!
I'm facing a strange problem, namely the following problem occures sometimes on inctremental build, but usually a full rebuild solves it:
Anyway thanks for the great library.
Regards,
Akos
The text was updated successfully, but these errors were encountered: