I’m interested in testing Framebuffers in elm-explorations/webgl, requiring me to fork and rebase the changes from the older elm-community/webgl repo, however I can’t build any of the examples using the edited code, because I can’t import from Elm.Kernel.
So I eventually found a guide called NATIVE/KERNEL MODULES IN ELM 0.19 which essentially suggested that I just symlink my working directory to ~/.elm/0.19.0/package/elm-explorations/webgl/1.1.1
In the end, it didn’t work because the compiled objs.dat, ifaces.dat, and cached.dat files don’t exist, and there is no documentation for generating them.
Further reading suggests that the ``proper’’ way to do this is by actually publishing the application to the package repository, which makes absolutely no sense, because we’re working with experimental builds and experimental code. Even the elm publish command says we shouldn’t be publishing random packages. I have a hard time believing that core developers actually work this way.
I’ve come to the conclusion that contributing has such a high bar that it is simply not possible.
Coming in as essentially an outsider to this language, I think that Elm’s community contribution story is confused. On one hand, you want intelligently designed APIs capable of surviving a transition between compiler targets to aid in delivering a certain user experience, but on the other hand you’ve essentially shut the community out from contributing to the most meaningful parts of the language by making it impossible for them to experiment and work out functioning candidate APIs.
You can take take a look at the script for running the elm/core test code and a nix expression that patches in a bug in elm/core for other ideas about how to do this.
Your solution did not work for my situation, but I did try it out on the elm/core library, and I was able to run elm-test and those tests passed. Really, all I had to do was symlink it into the right package directory, and sometimes delete elm-stuff.
That solution seems to work well for packages with tests, but the packages that I’m interested in, elm/bytes and elm-explorations/webgl don’t have tests. In fact, one of them has an /examples folder with applications in it.
Trying this solution, i.e. compiling with elm make ./crate.elm will result in the error
> Map.!: given key is not an element in the map
> CallStack (from HasCallStack):
> error, called at libraries/containers/Data/Map/Internal.hs:610:17 in containers-0.5.11.0:Data.Map.Internal
Or depending on some inscrutible issues
-- INCOMPATIBLE DEPENDENCIES ------------------------------------------ elm.json
The dependencies in your elm.json are not compatible.
Essentially, the core of the problem is that I want to be able to run applications that depend on packages containing Elm.Kernel code, which is likely to be found in a local directory, because what I’m testing is not the application, but the package.
It’s actually using applications as tests, since it’s primarily a visual inspection.
Are you using Elm 0.19.1? Bug like this was fixed in that version.
I changed to Elm 0.19.1, and unfortunately that didn’t change anything.
The expected flow is to simply go into ./webgl/examples and run elm make crate.elm, which is an application that depends on elm-explorations/webgl so it searches for it in the local package cache, which will be found as a symlink to the parent directory.
This results in the second “Incompatible Dependencies” error which is unfortunately opaque so I don’t know what it thinks is wrong.
Whenever I run into this error, I paste my json.elm into this:
https://www.markuslaire.com/github/elm-dependencies-analyzer/
Not sure if it will work for your use case, but give it a go?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.