Re: [elm-discuss] Structuring Http.request for HTTP DELETE Request

2017-03-05 Thread brian
What error are you getting? It looks like you're asking Elm to decode a player when you know you're not going to be getting one. > On Mar 6, 2017, at 12:19 AM, Long Nguyen wrote: > > Hello, > > I have the following helper functions to trigger the DELETE request of a >

[elm-discuss] Structuring Http.request for HTTP DELETE Request

2017-03-05 Thread Long Nguyen
Hello, I have the following helper functions to trigger the DELETE request of a resource. deletePlayer : Player -> Cmd Msg deletePlayer player = restRequest (hostUrl ++ "/players/" ++ (toString player.id)) (playerEncode player) playerDecoder DELETE |>

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

2017-03-05 Thread Martin Bailey
Hi Francesco, thanks for sharing the example. I agree that's a good structure for different sections of an app. I oversimplified the first example to show the current necessity of updater functions. The more painful part is deeply nested records such as in my last Geocode example. I feel it

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

2017-03-05 Thread Francesco Orsenigo
Hi Martin, I wonder if for your case a different way to organise your code would be viable: -- Family.elm updateFamily msg family = case msg of ChangeName newName -> ( { family | name = newName }, Cmd.none ) Save -> ( model, saveFamily family ) selectedView family = UI.form

[elm-discuss] Re: Post Examples of Painful Record Updates Here!

2017-03-05 Thread Martin Bailey
Here are some real world examples of record updates that could be streamlined at the language level, including attempts to simplify UI code defining record updates. -- Update.elm update : Msg -> Model -> ( Model, Cmd Msg ) update msg model = case msg of Update updater ->

Re: [elm-discuss] Linear algebra (matrix, vectors, ...) in the context of image processing

2017-03-05 Thread Ian Mackenzie
I also wonder how memory efficient a pure Elm solution could be, as currently there's no support for binary or packed data representation. That alone might argue for keeping the image data itself on the JavaScript side where you (or the libraries you use) can pull all sorts of tricks with typed