Rahul Muttineni
Rahul Muttineni
This issue is to discuss the refinements to the `etlas.dhall` format to make it more concise and readable than it already is as we get closer to releasing Etlas v1.6.0.0...
We can support stockage build plans by extending the sandbox mechanism `etlas sandbox ...` to support specifying a build plan and then automatically adding the info from the build plan...
This issue is there so that people can subscribe to it and get updates on the progress of the Maven plugin. If Maven support is a huge blocker for you...
All the functionality described here: https://ryanglscott.github.io/2017/04/12/improvements-to-deriving-in-ghc-82/ Should be backported to Eta at some point. Most notably, the `hedgehog` package requires these which otherwise requires a lengthy patch.
We should implement this GHC Trac ticket at some point: https://gitlab.haskell.org/ghc/ghc/issues/7647 Compact data layouts are essential for performance at times via reduction in cache misses.
Laziness is a particularly tricky topic, but once you get a handle on it, it's just as easy to fix laziness bugs as it is to fix memory leak issues...
Java arrays are currently mutable by default but it makes them awkward to work with. As suggested by @GordonBGood, it makes sense to adopt an interface similar to the `array`...
A list field that can store paths to folders or jar files. Will be sent straight to `javac` and also be used for verification purposes.
`etlas update --patches-only` Will update *just* the patches for cases where you don't want to query the package repository.