evancz Mar 23, 2017 00:43
Just so folks are aware, one of the hard things about having ports just be a Task is the following. Right now, a Task is guaranteed to terminate with an error or a result.
The only way it could be otherwise is if you have something of type Task Never Never
Now, if you are calling out to random JS that is written by anyone, that guarantee goes away.
You have to call some callback to give the value back to Elm, but what if that is never called?
Maybe there's an error, maybe there is a weird code path.
Now Elm code can "leak" tasks that never get completed because of problems in JS code.
One way to protect against this is to have timeouts, such that there is some guaranteed end.
My point here is just that it is more complicated than "what if it was a task?" and then everything would be nice.
alpacaaa
/ Explanation.md
Last active
December 2, 2021 08:00
Hard things about ports being Tasks in Elm
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| module Main exposing (main) | |
| import MyHtml exposing (program, text, a, onClick, div) | |
| type Msg | |
| = Inc | |
| | Dec | |
maxjacobson
/ Dockerfile
Last active
September 7, 2018 13:31
elm dev environment dockerfile -- doesn't copy code into the image (which means it wouldn't be useful in production), you're expected to use it by volume-mounting your source code into `/elm-code`
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| FROM node:10.9.0-jessie | |
| WORKDIR /elm-code | |
| ENV NPM_CONFIG_PREFIX=/home/node/.npm-global | |
| RUN apt-get update && \ | |
| apt-get upgrade --yes && \ | |
| apt-get install --yes \ | |
| wget && \ |
rlefevre
/ elm-linux-x64-static-0.19.1.md
Last active
November 22, 2021 15:27
How to build an elm 0.19.1 binary statically linked to musl libc using docker
This document describes how to build a statically linked binary of Elm 0.19.1 for Linux x64 using docker. The binary is built using Alpine Linux in order to easily link it statically to musl libc. This is how the official Elm 0.19.1 Linux binary is built.
Elm is currently distributed using npm. For Linux x64 (but this applies to any architecture), this requires to have a single x64 binary that works on all Linux x64 distributions. This is considerably easier to achieve by building a statically linked binary that will only depend on the Linux kernel ABI and System Call Interface but not on userpace libraries (see here for a compatibility survey of a dynamically built executable).
There's a lot of type terminology and jargon going around when discussing types in Elm. This glossary attempts to list some of the most common type terms along with synonyms, terms from other language communities, examples, and links to more detailed articles on each topic.