[Ann] marching-cubes


I’ve released the marching-cubes library on Hackage today. Here is a repository containing some examples. The marching cubes algorithm is used to construct 3D isosurfaces.

Would you know why the Github actions of this repository are unable to build OpenGLRaw?


The logs say:

OpenGLRaw                    > Cabal-simple_SvXsv1f__3.6.3.0_ghc-9.2.5: Missing dependency on a foreign
OpenGLRaw                    > library:
OpenGLRaw                    > * Missing (or bad) C library: GL
OpenGLRaw                    > This problem can usually be solved by installing the system package that
OpenGLRaw                    > provides this library (you may need the "-dev" version). If the library is
OpenGLRaw                    > already installed but in a non-standard location then you can use the flags
OpenGLRaw                    > --extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
OpenGLRaw                    > library file does exist, it may contain errors that are caught by the C
OpenGLRaw                    > compiler at the preprocessing stage. In this case you can re-run configure
OpenGLRaw                    > with the verbosity flag -v3 to see the error messages.

That means that you need to install the libgl-dev package (that is the name for Ubuntu/Debian). Although I don’t know how to actually do that with GitHub actions.

Thanks. I try with sudo apt-get install --yes libgl-dev. Maybe this will work, but with the Ubuntu OS only of course.

The installation of libgl-dev has worked! But there are other missing libraries, I’m currently trying to install them.

That said, this is for Ubuntu only. How to do for Mac and Windows? Here is my yaml file:

name: Stack-nightly

    branches: [main, master]

          - ubuntu-latest
          - macOS-latest
          - windows-latest

      fail-fast: false

    runs-on: ${{ matrix.runner }}

      - uses: actions/checkout@v3

      - name: Install libgl
        run: |
          sudo apt-get install --yes libgl-dev

      - name: Install mesa-utils
        run: |
          sudo apt-get install --yes mesa-utils

      - name: Install freeglut3
        run: |
          sudo apt-get install --yes freeglut3-dev

      - uses: freckle/stack-action@v3

      - id: stack
        uses: freckle/stack-action@v3
          stack-arguments: --resolver nightly --copy-bins --coverage

      - uses: actions/upload-artifact@v2
          name: coverage-report
          path: ${{ steps.stack.outputs.local-hpc-root }}

Actually the installation works on Windows, but there’s an issue with one of my own modules:

src\Colors\ColorRamp.hs:16:1: error: [-Worphans, -Werror=orphans]
    Orphan instance: instance Unbox a => Unbox (Color4 a)
    To avoid this
        move the instance declaration to the module of the class or of the type, or
        wrap the type with a newtype and declare the instance on the new type.

I never knew how to deal with the “orphan instance” warnings. Would you know? Otherwise, how to change the ghc options in order that it doesn’t throw an error for that?


I found a solution. I put

{-# OPTIONS_GHC -fno-warn-orphans  #-}

at the top of the file.

I use Nix to avoid this kind of problem. You will probably either love or hate it. Here’s an example:

Note that if you have a flake.nix people could run examples from your repo without worrying about dependencies at all with the nix run command like:

nix run git:stla/isosurfaces/OpenGL .#Invader


nix run git:stla/isosurfaces/OpenGL .#Goursat

and a good way to see if it Nix might be right for you (or not) is to go through:


Thanks, that looks amazing. I will take a look more carefully.


Very cool! I always wanted to implement the marching cubes algorithm - I know it would make 13-year-old-me very happy if I ever get a time machine!


I’m going to release marching-cubes2. It is better.


I saw you made another thread for that. In the future, please note the “custom” here would be to just bump the existing thread for such a release.


The “best” solution is to upstream the instance to the package which either declares the class or the data structure. When that’s not possible, some people create an intermediate package whose entire job is to provide these instances.


Is this true? I tend to make a new discussion for all new release of my packages, rather than having one thread per package.


Well in this case, one thread was made only three days after the other. If there was say a six month interval or more, then maybe a different choice would have made sense. Here, one thread hadn’t even fallen out of the top five before the next was made!