[elm-discuss] Re: [early prototype] Elm-Data: a server loading code generator

[Max Goldstein]

Rupert,

I've been doing something very similar and it is proving very worthwhile, 
> so I would encourage you to pursue this.
>

Thanks (:
 

> For Elm, I output one (big) file called Model.elm, that gives me the data 
> model mapped onto Elm, and encoders and decoders for it. Then for each 
> grouping of endpoints (each service implemented in Java provides the 
> grouping) I generate one Elm file that implements the Http logic for the 
> service.
>

I've come to the same file structure, because JSON API allows for included 
resources. For example, articles can include their author an vice versa, 
which means those decoders have to be defined in a common file. I'm trying 
to wrap them in one module per resource, though.
 

> Each service requires a set of callback functions to be passed in - one 
> for each endpoint, plus one for each endpoint when it results in an error, 
> plus a default error handler for cases when the endpoint specific error 
> handler doesn't process the error.
>

I'm taking a different approach. I'm using the RemoteData library to track 
the (possibly error) state of each ID'd resource, so if there's an error, 
it's just stored. You won't know until you try to get that ID and you wind 
up with the Failure case of the RemoteData type. I'm also planning on 
having an error log that's written to in opaque events and exposed 
read-only through an API. 
 

> Another possibility would be to use an API description meta-data such as 
> Swagger. A Swagger codegen for Elm could easily output something useable.
>

I've used both Swagger and JSON API before, and I'll say that JSON API has 
almost no downsides but Swagger is much more an engineering tradeoff. An 
Elm swagger codegen is something that should exist but I'm taking a 
different approach.
 

> I think Elm will be well suited to writing code generators - in a manner 
> similar to how it 'codegens' Html. You can design a set of functions for 
> constructing the component parts of the output language you are working 
> with. Elm is good for doing complex AST manipulation and it can be set up 
> to guarantee correctly formed output. Code generation of Elm in Elm will be 
> a mind bender.
>

I'm hesitant to rely on server-side rendering Elm when it's not officially 
supported (I say that as the co-author of Elm test and Richard's shell 
utility for it does exactly that, so maybe I'm not being consistent). I'm 
also a little less concerned with well-formed output, since elm-format can 
smooth over a lot of bumps in a hacked-together system. I'm more 
comfortable in Ruby but Noah Hall has written some JSON tools in Python 
that I'd like to build on if it makes sense to do so (he's left NRI so 
maybe not?).

Thanks again for your encouragement! 

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] State of Elm Survey 2017 is live

[Nick H]

>
> The same would apply to people working alone as freelancers.
>

I just put in 10 :-)

On Wed, Jan 18, 2017 at 3:48 PM, Matthieu Pizenberg <
matthieu.pizenb...@gmail.com> wrote:

> Hey, I just participated in the survey :)
> A few remarks before forgetting:
> - I am not sure large scale notations (0->10) with only indications of
> what the 2 ends are, are a good thing in surveys. 0 to 3 is very often
> enough (not at all / small / medium / high )
> - The question "What is your level of influence within your team?" may
> not apply to everyone. I am currently a PhD student in image processing, so
> I can't really say "let's use elm" ^^. The same would apply to people
> working alone as freelancers.
>
> On Wednesday, January 18, 2017 at 9:15:35 PM UTC+1, Brian Hicks wrote:
>>
>> You're right that there are a large number of people using Elm for side
>> projects. I'm still interested in their professional experiences. We want
>> to reduce the activation energy to go from hobby to production.
>>
>> There are about a hundred responses so far! Keep them coming!
>>
>> Also for those curious, here are the results from last year:
>> https://www.brianthicks.com/post/2016/04/22/state-of-elm-2016-results/ Forgot
>> to include that before!
>>
>> On Jan 18, 2017, 1:57 PM -0600, Martin DeMello ,
>> wrote:
>>
>> the survey seemed overly focused on people whose day job was web
>> development. i'm guessing a significant fraction of the elm community are
>> people developing side projects.
>>
>> martin
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] State of Elm Survey 2017 is live

[Matthieu Pizenberg]

Hey, I just participated in the survey :)
A few remarks before forgetting:
- I am not sure large scale notations (0->10) with only indications of what 
the 2 ends are, are a good thing in surveys. 0 to 3 is very often enough 
(not at all / small / medium / high )
- The question "What is your level of influence within your team?" may not 
apply to everyone. I am currently a PhD student in image processing, so I 
can't really say "let's use elm" ^^. The same would apply to people working 
alone as freelancers.

On Wednesday, January 18, 2017 at 9:15:35 PM UTC+1, Brian Hicks wrote:
>
> You're right that there are a large number of people using Elm for side 
> projects. I'm still interested in their professional experiences. We want 
> to reduce the activation energy to go from hobby to production.
>
> There are about a hundred responses so far! Keep them coming!
>
> Also for those curious, here are the results from last year: 
> https://www.brianthicks.com/post/2016/04/22/state-of-elm-2016-results/ Forgot 
> to include that before!
>
> On Jan 18, 2017, 1:57 PM -0600, Martin DeMello  >, wrote:
>
> the survey seemed overly focused on people whose day job was web 
> development. i'm guessing a significant fraction of the elm community are 
> people developing side projects. 
>
> martin
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Image lazy-loading?

[Maxwell Gurewitz]

You'll have to have use keyed elm nodes to get this to work.

On Tuesday, January 17, 2017 at 9:10:22 AM UTC-8, Tomáš Znamenáček wrote:
>
> Now that I think of it, this is even more tricky, right? Because the Elm 
> runtime juggles the DOM nodes as it sees fit, easily making them go out of 
> sync with the Echo.js library. So what should I do to make images 
> lazy-load? Thank you,
>
> T.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] I gave an Elm Talk before the Haskell User Group Frankfurt

[alipasha]

Hi there,

on Monday I gave a Talk on Elm and FRP (I know!) before the Haskell User 
Group in Frankfurt Germany and it went very well. I'd like to share my 
experience. 

The Introduction of Syntax, Types, Union Types, Pattern Matching went with 
ease, that will certainly be different in front of a JavaScript crowd. I 
need less time for that part.

As I was showing different examples people kept mentioning "the Actor 
Model". 

The FRP issue is a great conversation topic and as I talked about the 
removal of the signals in 0.17, questions were raised on how time-sensitive 
modelling will happen in Elm now.
I do need to study more libraries and especially the edge cases to prepare 
for those kind of issues. 

The Questions kept being asked regarding Html:

1. How realistic is it to put everything in ONE Model. I tried to explain 
composition, but bringing up a real complex example would be nice. I did 
mention NoRedInk though. 

2. We need more "beautiful" Html examples, even though it's about 
simplicity, people assume the lack of effort in getting the Counter, the 
Dice and other examples that look more appealing questions if Elm is able 
to deal with messy CSS and browser stuff in practice.

Now, I REALLY have to get deep into CSS. :(

3. Next time I will prepare more PORT examples. Many questions if Bootstrap 
or a calendar widget could be combined easily in a complex web page.

Last but certainly not least:

4. Everyone seemed to know that Elm does not support Haskell like Type 
Classes and this added 
to the doubts if Elm could handle serious big problems. One person 
mentioned bio-informatics but I did mot understand the details of the 
problem.

One last thing:

The compiler messages and the new debugger made a great impression. 

JavaScript has not a lot of friends in the Haskell Community, but my 
impression was that python is less popular.

All in all everyone liked Elm and there will be future sessions comparing 
solutions to problems in Haskell with Elm. I am looking forward to that.

Some remarks as I was preparing for the Talk:

The Jump from 0.16 to 0.17 is huge, it's really huge; in terms of 
explaining Elm, in terms of thinking in Elm.

The Language-Level Reactivity with Elm Article by Richard Feldman helped a 
lot with my preparations.
https://www.infoq.com/articles/language-reactivity-with-elm

I personally believe the way Evan is evolving Elm is way more impressive 
than the invention of Elm itself. 

This is a great journey. I love it so far and I need to learn a lot more.

In case anyone is interested here are my slides, but nothing special for 
this group I guess.

https://github.com/1use/elm-presentation-haskell-ug-frankfurt-01-2017

Thanks for this great community

A.P.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] State of Elm Survey 2017 is live

[Brian Hicks]

You're right that there are a large number of people using Elm for side 
projects. I'm still interested in their professional experiences. We want to 
reduce the activation energy to go from hobby to production.

There are about a hundred responses so far! Keep them coming!

Also for those curious, here are the results from last year: 
https://www.brianthicks.com/post/2016/04/22/state-of-elm-2016-results/ Forgot 
to include that before!

On Jan 18, 2017, 1:57 PM -0600, Martin DeMello , wrote:
> the survey seemed overly focused on people whose day job was web development. 
> i'm guessing a significant fraction of the elm community are people 
> developing side projects.
>
> martin

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] State of Elm Survey 2017 is live

[Martin DeMello]

the survey seemed overly focused on people whose day job was web
development. i'm guessing a significant fraction of the elm community are
people developing side projects.

martin

On Wed, Jan 18, 2017 at 10:28 AM, Brian Hicks  wrote:

> The State of Elm Survey is live. Please take it and share with your
> colleagues. The survey will run from today until the 24th of February (a
> Friday.)
>
> https://www.brianthicks.com/state-of-elm/2017/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[OvermindDL1]

On Wednesday, January 18, 2017 at 9:53:31 AM UTC-7, Rupert Smith wrote:
>
> In my view, this also provides very good justification for not allowing 
> native code into packages.elm-lang.org. Porting Elm to another platform 
> in this way is manageable.
>

Entirely yeah, native code even in core elm is buggy.  In my translations I 
wrote very thin FFI calls to the base-most javascript calls (mostly DOM 
stuff), fully typed, then built everything on those typed interfaces (it is 
very typescript'y/purescript'y at that point), but I've had no undefined's, 
no oddities like that at all, and the old 'native' parts were entirely in 
OCaml this time, just bound to those very few fully typed FFI calls (which 
I need to clean them up too, newer versions of bucklescript has simplified 
making them since I wrote this file).  For example, here is the web element 
node interaction FFI l made (slightly older version as the one at work has 
a bit more and is a bit more clean), these are the kind of things user code 
should not write, and indeed an Elm->OCaml compiler should not have such 
functionality exposed but rather should call to things exposed from OCaml 
that may use things like this: 
 
https://github.com/OvermindDL1/bucklescript-testing/blob/master/src/web_node.ml 
(and ignore the polyfill at the bottom, I later converted that to pure 
OCaml/Bucklescript as well)

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

['Rupert Smith' via Elm Discuss]

On Tuesday, January 17, 2017 at 4:27:36 PM UTC, OvermindDL1 wrote:
>
> On Tuesday, January 17, 2017 at 4:25:08 AM UTC-7, Rupert Smith wrote:
>
>> An alternative might be to re-write the Native modules in the Elm core in 
>> OCaml. There isn't a huge amount of it.
>>
>
> Precisely this, I've already done quite a large chunk of it as a test and 
> it translates very easily (and becomes type safe, which Elm's is not as 
> I've hit 'undefined's in pure elm code before (already in the bug tracker, 
> but why did they happen at all?!)).  I kept it identical to the Elm API as 
> well, though if I broke Elm's API in a couple of minor ways then I could 
> *substantially* reduce the number of allocations done...  But yes, I've 
> rewrote most of Elm's native Core code as well as some third-party 
> libraries like navigation, all without a touch of javascript and all of it 
> type safe the whole way, mostly playing around but we ended up using a lot 
> of it at work anyway (I still need to get around to cleaning it up and 
> releasing it...).
>

In my view, this also provides very good justification for not allowing 
native code into packages.elm-lang.org. Porting Elm to another platform in 
this way is manageable.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Brian Hicks]

This will be part of the State of Elm survey. It goes live this week, and I'll 
post a new thread here when it does. It doesn't go into quite as much detail as 
your post because we're already pushing the length limit. That said, this is 
what I've got for this:

> Which of the following do you read / contribute to?
>
> - Elm Slack
> - elm-discuss mailing list
> - elm-dev mailing list
> - Twitter discussions
> - Facebook groups
> - Elm subreddit
> - Elm weekly newsletter
> - Elm town podcast

On Jan 18, 2017, 8:19 AM -0600, Matthieu Pizenberg 
, wrote:
> Hi again, since this is not the first time that this matter is discussed, and 
> since this time Evan launched it, it means that it is an important matter for 
> the community and it's going to evolve anytime soon ^^. So, instead of 
> discussing it here with passion and obvious bias since we are on the mailing 
> list, what would you think of asking the questions to all the community in a 
> more objective way?
>
> What I think of is for example a google form like the one below, that would 
> be accessible from all the community entry points (slack, reddit, mailing 
> list, ...). Please tell if you like the idea, or not. (sorry for the long 
> post XD)
>
>
> # Community Checkpoint Form
>
> --- PROFILE
>
> What is your experience with elm ?
>  - New here
>  - Not so much experience (1-2 completed projects)
>  - Start feeling confident (understand most of it, multiple successful 
> projects)
>  - Total expert (yeah I even master effect managers, native code, etc.)
>
> Are you familiar with functional programming?
>  - What is that?
>  - I know the basics
>  - Yes I use it regurlarly
>  - Peace of cake, I'm currently doing a PhD on homotopy type theory for 
> functional programming
>
> --- COMMUNITY
>
> Some description here to introduce the dilemna between Reddit, Google Groups 
> (alias mailing list), and something else dedicated (let's say a Discourse).
>
> Did you know about:
>  o The elm Reddit?
>  o The elm Slack?
>  o The elm discussion group (mailing list)?
>
> Are you currently a Reddit user?
>  - No
>  - Yes, sometimes
>  - Yes, everytime
>
> Are you currently a Google Groups user?
>  - No
>  - Yes, sometimes
>  - Yes, everytime
>
> Are you currently using a Discourse forum?
>  - No
>  - Yes, sometimes
>  - Yes, everytime
>
> Rank your preferences between those:
>  1. elm Reddit
>  1. elm discussion group (mailing list)
>  1. elm Discourse
>
> (If you ranked first Reddit) would you volunteer to help with the moderation?
>  - yes/no
> (If you ranked first the mailing list) would you volunteer to help with the 
> moderation?
>  - yes/no
> (If you ranked first Discourse) would you volunteer to help with the 
> creation, funding of the server, or moderation of this forum?
>  - yes/no
>
> (If you answered yes to one of the previous volunteering questions) please 
> give us details of what you would like to do and a way to contact you in case 
> this might go further:
> 
> |        |
> 
>
> Anything you would like to add?
> 
> |        |
> 
>
> On Tuesday, January 3, 2017 at 2:51:05 AM UTC+1, Evan wrote:
> > I recently talked with folks who moderate the various Elm discussion forums 
> > about the challenges that come up and how we can do better.
> >
> > The short version is: we should start migrating more discussion to /r/elm.
> >
> > Now the long version!
> >
> >
> > How Things Are Now
> >
> > Long-form discussion is split between elm-discuss and /r/elm. There are a 
> > lot of regulars that spend more time on elm-discuss, but I think it's fair 
> > to say that /r/elm is much more easily accessible and "public facing" for 
> > newcomers. This creates some problems.
> >
> > Problems with elm-discuss:
> >
> > • Threads are linear, so it's hard for people to branch off into 
> > sub-discussions.
> > • There's no voting mechanism in elm-discuss, so topics are sorted by "are 
> > people posting?" not by "do people care?"
> > • Moderation to avoid spam is more difficult. All new users are moderated 
> > by default to avoid those awful spam robots that Google Groups does not 
> > catch.
> > • It goes to people's already full inboxes. If you change this, you use the 
> > online interface, which is not amazing.
> >
> > Problems from having two long-form forums:
> >
> > • Lots of valuable expertise only lives on elm-discuss. When new folks come 
> > to /r/elm, there are not as many folks with as much production experience.
> > • Blog posts (frequently shared on /r/elm) miss out on a lot of valuable 
> > feedback.
> >
> >
> > How Things Could Be
> >
> > Right now I'm just suggesting that folks who are regulars here get on 
> > /r/elm and see if you like it. I'd like to start by shifting the center of 
> > gravity for community discussion.
> >
> > Longer term though, things could look more like how Rust does it. It seems 
> > like /r/rust is the center of 

[elm-discuss] Re: POST Http.request in Elm 0.18

[Matthieu Pizenberg]

Hi, in case it may be of help, I just did a small test elm project using 
web api which is available at this repo 
.
Basically it was to test a way to use api (and authentified api using JWT) 
that I adapted from a 0.17 tutorial available on the Auth0 website 
.

On Wednesday, January 18, 2017 at 3:22:23 PM UTC+1, bey...@gmail.com wrote:
>
> I'm trying to use elm-lang/http without success so far. I want to address 
> an API with a POST request via JSON. All my efforts so far result in having 
> the wrong headers.
>
> There are two things I've tried in the following: in both cases the server 
> tells me that it wasn't a POST request but OPTIONS.
>
> I've tried using "Http.post":
>
> jsonify : String -> Http.Body
> jsonify str =
> Http.jsonBody <| Encode.object [("sentiment", Encode.string str)]
>
>
> decodeJson : Decode.Decoder String
> decodeJson =
> Decode.map2 (\classification status -> classification)
> (Decode.field "classification" Decode.string)
> (Decode.field "status" Decode.int)
>
>
> fetchSentiment : String -> Cmd Msg
> fetchSentiment sentiment =
> Http.send Fetch (Http.post (jsonify sentiment) decodeJson)
>
> and a custom request:
>
> fetchSentiment : String -> Cmd Msg
> fetchSentiment sentiment =
> Http.send Fetch (postSentiment sentiment decodeJson)
>
> postSentiment : String -> Decode.Decoder String -> Http.Request String
> postSentiment sentiment decoder =
> Http.request
> { method = "POST"
> , headers = [(Http.header "Content-Type" "application/json")]
> , url = "http://127.0.0.1:5000/sentiment;
> , body = (jsonify sentiment)
> , expect = Http.expectJson decoder
> , timeout = Nothing
> , withCredentials = False
> }
>
> Is my problem related to the code above, and if so, how can I fix it?
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] POST Http.request in Elm 0.18

[Duane Johnson]

It sounds like you might be trying to do a "cross-domain" post, i.e. are
you running your elm app on one port, and attempting to POST to another
port? If so, this is considered "cross-domain". (Of course, if you have an
IP address or domain that's different, that's "cross-domain" as well).

If this is the case, then you need to enable CORS requests on the receiving
domain. CORS is a way of negotiating access on a server at another "domain"
(or port) so that the server can be responsible for accepting or denying
AJAX requests from around the internet. One of the steps that occurs during
that negotiation is an OPTIONS header request.

Does that help?

Duane

On Wed, Jan 18, 2017 at 1:33 AM,  wrote:

> I'm trying to use elm-lang/http without success so far. I want to address
> an API with a POST request via JSON. All my efforts so far result in having
> the wrong headers.
>
> There are two things I've tried in the following: in both cases the server
> tells me that it wasn't a POST request but OPTIONS.
>
> I've tried using "Http.post":
>
> jsonify : String -> Http.Body
> jsonify str =
> Http.jsonBody <| Encode.object [("sentiment", Encode.string str)]
>
>
> decodeJson : Decode.Decoder String
> decodeJson =
> Decode.map2 (\classification status -> classification)
> (Decode.field "classification" Decode.string)
> (Decode.field "status" Decode.int)
>
>
> fetchSentiment : String -> Cmd Msg
> fetchSentiment sentiment =
> Http.send Fetch (Http.post (jsonify sentiment) decodeJson)
>
> and a custom request:
>
> fetchSentiment : String -> Cmd Msg
> fetchSentiment sentiment =
> Http.send Fetch (postSentiment sentiment decodeJson)
>
> postSentiment : String -> Decode.Decoder String -> Http.Request String
> postSentiment sentiment decoder =
> Http.request
> { method = "POST"
> , headers = [(Http.header "Content-Type" "application/json")]
> , url = "http://127.0.0.1:5000/sentiment;
> , body = (jsonify sentiment)
> , expect = Http.expectJson decoder
> , timeout = Nothing
> , withCredentials = False
> }
>
> Is my problem related to the code above, and if so, how can I fix it?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] POST Http.request in Elm 0.18

[beyeran]

I'm trying to use elm-lang/http without success so far. I want to address 
an API with a POST request via JSON. All my efforts so far result in having 
the wrong headers.

There are two things I've tried in the following: in both cases the server 
tells me that it wasn't a POST request but OPTIONS.

I've tried using "Http.post":

jsonify : String -> Http.Body
jsonify str =
Http.jsonBody <| Encode.object [("sentiment", Encode.string str)]


decodeJson : Decode.Decoder String
decodeJson =
Decode.map2 (\classification status -> classification)
(Decode.field "classification" Decode.string)
(Decode.field "status" Decode.int)


fetchSentiment : String -> Cmd Msg
fetchSentiment sentiment =
Http.send Fetch (Http.post (jsonify sentiment) decodeJson)

and a custom request:

fetchSentiment : String -> Cmd Msg
fetchSentiment sentiment =
Http.send Fetch (postSentiment sentiment decodeJson)

postSentiment : String -> Decode.Decoder String -> Http.Request String
postSentiment sentiment decoder =
Http.request
{ method = "POST"
, headers = [(Http.header "Content-Type" "application/json")]
, url = "http://127.0.0.1:5000/sentiment;
, body = (jsonify sentiment)
, expect = Http.expectJson decoder
, timeout = Nothing
, withCredentials = False
}

Is my problem related to the code above, and if so, how can I fix it?

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Emphasizing /r/elm more

[Matthieu Pizenberg]

Hi again, since this is not the first time that this matter is discussed, 
and since this time Evan launched it, it means that it is an important 
matter for the community and it's going to evolve anytime soon ^^. So, 
instead of discussing it here with passion and obvious bias since we are on 
the mailing list, what would you think of asking the questions to all the 
community in a more objective way?

What I think of is for example a google form like the one below, that would 
be accessible from all the community entry points (slack, reddit, mailing 
list, ...). Please tell if you like the idea, or not. (sorry for the long 
post XD)


# Community Checkpoint Form

--- PROFILE

What is your experience with elm ?
 - New here
 - Not so much experience (1-2 completed projects)
 - Start feeling confident (understand most of it, multiple successful 
projects)
 - Total expert (yeah I even master effect managers, native code, etc.)

Are you familiar with functional programming?
 - What is that?
 - I know the basics
 - Yes I use it regurlarly
 - Peace of cake, I'm currently doing a PhD on homotopy type theory for 
functional programming

--- COMMUNITY

Some description here to introduce the dilemna between Reddit, Google 
Groups (alias mailing list), and something else dedicated (let's say a 
Discourse).

Did you know about:
 o The elm Reddit?
 o The elm Slack?
 o The elm discussion group (mailing list)?

Are you currently a Reddit user?
 - No
 - Yes, sometimes
 - Yes, everytime

Are you currently a Google Groups user?
 - No
 - Yes, sometimes
 - Yes, everytime

Are you currently using a Discourse forum?
 - No
 - Yes, sometimes
 - Yes, everytime

Rank your preferences between those:
 1. elm Reddit
 1. elm discussion group (mailing list)
 1. elm Discourse

(If you ranked first Reddit) would you volunteer to help with the 
moderation?
 - yes/no
(If you ranked first the mailing list) would you volunteer to help with the 
moderation?
 - yes/no
(If you ranked first Discourse) would you volunteer to help with the 
creation, funding of the server, or moderation of this forum?
 - yes/no

(If you answered yes to one of the previous volunteering questions) please 
give us details of what you would like to do and a way to contact you in 
case this might go further:

||


Anything you would like to add?

||


On Tuesday, January 3, 2017 at 2:51:05 AM UTC+1, Evan wrote:
>
> I recently talked with folks who moderate the various Elm discussion 
> forums about the challenges that come up and how we can do better.
>
> The short version is: *we should start migrating more discussion 
> to /r/elm .*
>
> Now the long version!
>
>
> How Things Are Now
>
> Long-form discussion is split between elm-discuss and /r/elm 
> . There are a lot of regulars that spend 
> more time on elm-discuss, but I think it's fair to say that /r/elm is much 
> more easily accessible and "public facing" for newcomers. This creates some 
> problems.
>
> Problems with elm-discuss:
>
>- Threads are linear, so it's hard for people to branch off into 
>sub-discussions.
>- There's no voting mechanism in elm-discuss, so topics are sorted by 
>"are people posting?" not by "do people care?"
>- Moderation to avoid spam is more difficult. All new users are 
>moderated by default to avoid those awful spam robots that Google Groups 
>does not catch.
>- It goes to people's already full inboxes. If you change this, you 
>use the online interface, which is not amazing.
>
> Problems from having two long-form forums:
>
>- Lots of valuable expertise *only* lives on elm-discuss. When new 
>folks come to /r/elm, there are not as many folks with as much production 
>experience.
>- Blog posts (frequently shared on /r/elm) miss out on a lot of 
>valuable feedback.
>
>
> How Things Could Be
>
> Right now I'm just suggesting that folks who are regulars here get on 
> /r/elm and see if you like it. I'd like to start by shifting the center of 
> gravity for community discussion.
>
> Longer term though, things could look more like how Rust does it. It seems 
> like /r/rust  is the center of gravity 
> for community discussion. See their sidebar! They moderate content well and 
> have 
> some laughs 
> . 
> (I personally think it's very important for moderators to be active in 
> guiding people towards *friendly* discussion! That's super hard on 
> elm-discuss.)
>
> They also have an interesting approach to answering beginner questions 
> 
>  that 
> I think it'd be good to try out!
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" 

[elm-discuss] Re: OK, or very very wrong?

[Joel Clermont]

Here is some pretty direct guidance in the elm-sortable-table docs 


One of the core rules of The Elm Architecture is never put functions in 
your Model or Msg types. It may cost a little bit of extra code to model 
everything as data, but the architecture and debugging benefits are worth 
it.

On Tuesday, January 17, 2017 at 9:24:10 PM UTC-6, Marshall handheld Flax 
wrote:
>
> Is it wrong for Cmds to contain functions (as opposed to data within 
> constructors)?  If it is a reasonable practice, it would allow for more 
> functional component-like modules, but does this violate the Elm 
> architecture?  If it does, is it explicitly mentioned in the docs -- I 
> don't remember seeing it. Here's http://elm-lang.org/examples/buttons 
> rewritten in the Cmd-contains-functions style. Thank you!
>
> module Main exposing (..)
>
> import Html exposing (beginnerProgram, div, button, text)
> import Html.Events exposing (onClick)
>
> main =
> beginnerProgram { model = 0, view = view, update = update }
>
> type Msg
> = Transform (Int -> Int)
>
> view model =
> div []
> [ button [ onClick (Transform ((+) -1)) ] [ text "-" ]
> , div [] [ text (toString model) ]
> , button [ onClick (Transform ((+) 1)) ] [ text "+" ]
> ]
>
> update msg model =
> case msg of
> Transform xform ->
> xform model
>
>
>
On Tuesday, January 17, 2017 at 9:24:10 PM UTC-6, Marshall handheld Flax 
wrote:
>
> Is it wrong for Cmds to contain functions (as opposed to data within 
> constructors)?  If it is a reasonable practice, it would allow for more 
> functional component-like modules, but does this violate the Elm 
> architecture?  If it does, is it explicitly mentioned in the docs -- I 
> don't remember seeing it. Here's http://elm-lang.org/examples/buttons 
> rewritten in the Cmd-contains-functions style. Thank you!
>
> module Main exposing (..)
>
> import Html exposing (beginnerProgram, div, button, text)
> import Html.Events exposing (onClick)
>
> main =
> beginnerProgram { model = 0, view = view, update = update }
>
> type Msg
> = Transform (Int -> Int)
>
> view model =
> div []
> [ button [ onClick (Transform ((+) -1)) ] [ text "-" ]
> , div [] [ text (toString model) ]
> , button [ onClick (Transform ((+) 1)) ] [ text "+" ]
> ]
>
> update msg model =
> case msg of
> Transform xform ->
> xform model
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] OK, or very very wrong?

[Marshall handheld Flax]

Even worse, it blocks the import/export feature of the time-travelling 
debugger -- 
see ./elm-stuff/packages/elm-lang/virtual-dom/2.0.3/src/VirtualDom/Overlay.elm 
which emits the error "type of your program cannot be reliably serialized 
for history files." 

I'm wondering: should the compiler issue a warning if I do something this 
wrong?

Thanks!

Marshall

On Wednesday, January 18, 2017 at 2:37:00 AM UTC-5, Nick H wrote:
>
> Your particular example can be rewritten easily to not use functions (and 
> with even less duplication):
>
> type Msg
> = Add Int
>
> view model =
> div []
> [ button [ onClick (Add -1) ] [ text "-" ]
> , div [] [ text (toString model) ]
> , button [ onClick (Add 1) ] [ text "+" ]
> ]
>
> update msg model =
> case msg of
> Add delta ->
> model + delta
>
>
> On Tue, Jan 17, 2017 at 11:31 PM, Nick H  > wrote:
>
>> I would come down on the side of very very wrong. Functions can't be 
>> converted into strings, and they can't be checked for equality. So if you 
>> need to debug your program (say, with the interactive debugger), There is 
>> no way to examine the data being passed in your commands.
>>
>>
>> On Tue, Jan 17, 2017 at 7:24 PM, Marshall handheld Flax <
>> m.droi...@gmail.com > wrote:
>>
>>> Is it wrong for Cmds to contain functions (as opposed to data within 
>>> constructors)?  If it is a reasonable practice, it would allow for more 
>>> functional component-like modules, but does this violate the Elm 
>>> architecture?  If it does, is it explicitly mentioned in the docs -- I 
>>> don't remember seeing it. Here's http://elm-lang.org/examples/buttons 
>>> rewritten in the Cmd-contains-functions style. Thank you!
>>>
>>> module Main exposing (..)
>>>
>>> import Html exposing (beginnerProgram, div, button, text)
>>> import Html.Events exposing (onClick)
>>>
>>> main =
>>> beginnerProgram { model = 0, view = view, update = update }
>>>
>>> type Msg
>>> = Transform (Int -> Int)
>>>
>>> view model =
>>> div []
>>> [ button [ onClick (Transform ((+) -1)) ] [ text "-" ]
>>> , div [] [ text (toString model) ]
>>> , button [ onClick (Transform ((+) 1)) ] [ text "+" ]
>>> ]
>>>
>>> update msg model =
>>> case msg of
>>> Transform xform ->
>>> xform model
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: YAML lib for Elm?

[Jan Tojnar]

> Indeed, latest YAML spec is 84 pages long =(   silent screaming).
>
 
Maybe it would be easier to send a pull request adding support for JSON 
output to commentit.io. It is open source after all.

https://github.com/guilro/commentit

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.