Georgi Krastev
Georgi Krastev
That begs the question, have you tried the following? ```scala abstract class AbstractObjectCompanion { type Type def apply(src: Int): Type implicit class Ops(t: Type) { def print = t.toString }...
> p.s. could not name the type parameter Type because it clashed with what the macro expands to :) That's the whole point, if you leave it abstract `Type` will...
But it's not really both causes at the same time - it's the death of one branch causing the interruption of the other. Shouldn't then the result be `Cause.Then` instead...
I still think it would be good to try and fix `zipWithPar` to reflect the true causal relationship (whether parallel or one cause causing the interruption as another).
That sounds better. But I'm still not sure how the API should look like. My only worry is that making it name-based could be too obscure.
Miles solved it in his byname implicits PR scala/scala#6050
Oh yeah, expanding Magnolia macros in parallel is not well defined. Perhaps it would be good to put a disclaimer in the README about Magnolia and Hydra, but we need...
Another option would be to try and use `ThreadLocal` although I'm not sure if Hydra is using raw threads or `Future`s (`ThreadLocal` does not work with `Future`). @einholen do you...
@propensive perhaps we should contact Triplequote to get a free licence for Magnolia and add it to our CI and try to reproduce the problem. WDYT?
@einholen in the meantime you can try out #217 - you can build and publish Magnolia locally to do that. Let me know if you need help with that.