Re: [elm-discuss] Re: Best practices to create examples for an elm package?

[Noah Hall]

Best practice:

- Use elm-doc-test for examples whereever possible, don't just write
documentation examples. They easily fall out of sync. If your
doc-tests start to look too crazy, it's possible your API could be
simplified.
- Have a test suite. Depending on your problem, your test suite may
need to be large and complex, in order to ensure all edge cases are
matched. If your package is mostly just glue code, there's not so much
need for that.
- If you have views, use elm-html-test. You can now also test events with this.
- If you are exposing something which is browser-dependant, e.g mouse,
touch, event decoders. You should have an integration test set up that
runs your code in a real browser

On Mon, May 8, 2017 at 4:38 PM, Eirik Sletteberg
 wrote:
> Maybe write an example in the form of an integration test - then you know 
> your example will be up to date with the actual code, and it may even 
> discover bugs!
>
> --
> 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] New guidelines for posting on Elm-discuss

[Noah Hall]

Please move this discussion to another thread.

On Sun, May 7, 2017 at 1:29 PM, Rex van der Spuy  wrote:
>
>
> On Sunday, May 7, 2017 at 1:06:14 AM UTC-4, Dave Rapin wrote:
>>
>> The problem with slack is that discussions are lost after you hit their
>> limit (which wasn't terribly high last time I checked). So instead of
>> finding / googling for an answer / question that had previously been
>> covered, you must ask again, which is of course async and therefor more time
>> consuming.
>>
>> I don't mean to seem anti-social, but if I'm in the middle of solving a
>> problem and run into an issue, I reach for Google way before I'd post on
>> Slack. Slack just feels like a black hole where information goes to die.
>
>
> I agree 100%.
> The other problem is that there are so many channels that you never know
> where to post your question.
> And, you have to hope there is someone online at that very moment with the
> skills or interest to help you, otherwise your question scrolls away into
> eternity.
> So far, I've found Reddit to be the best forum for Elm Q - questions
> always net some big fish and petty quibbles get down-voted out of the way.
>
> --
> 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] New guidelines for posting on Elm-discuss

[Noah Hall]

For contrast, consider the Elm community on Slack. Friendly and
welcoming, all kinds of questions get answered. Here, flamewars and
personal attacks happen far too often, and it's really giving Elm a
bad name, despite being a minority of people.

On Sat, May 6, 2017 at 3:37 AM, John Orford  wrote:
> I remember reading that post from Overmind and thinking it v odd.
>
> Maybe I am blind or have rose coloured glasses.
>
> Unsure whether Noah's rule book will help or hinder. But good that he cares.
>
> On Sat 6. May 2017 at 09:01, Mark Marlow  wrote:
>>
>> John,
>>
>> I tend to agree that the discourse isn't a problem. However, one can't
>> help but notice that there is a perception of hostility in this community,
>> e.g.
>>
>> https://elixirforum.com/t/front-end-development-options-2017/3832/2
>>
>> The standard you walk past is the standard you accept, and we all need to
>> take ownership of the community we're a part of.
>>
>> Noah, thanks for pulling this together and hope this is a first step in
>> improving our community.
>>
>> M
>>
>> --
>> 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.

-- 
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] New guidelines for posting on Elm-discuss

[Noah Hall]

Hi Dustin,

Regarding where to post, my personal recommendation is to choose Slack
first. It has the largest community and problems get answered very
quickly. People will also direct you to the right place if you're not
sure. Regarding guidelines, we have discussed this quite a bit, and
this post is the first step in that direction.


Hi John,

This post aims to address problems faced by other members of the
community which made them feel unwelcome. In particular:

- People being aggressive/demanding/generally not nice
- People posting too much info and/or sidetracking discussions

These guidelines are intended to set out the correct things to post
here, and the correct way to post here. Now nobody should be surprised
if they are banned for personal attacks, or if a thread gets locked
when it gets too far off track.

The goal is to have a discussion forum that everyone feels they can
take part in.

On Fri, May 5, 2017 at 10:02 AM, John Orford <john.orf...@gmail.com> wrote:
> I love your work Noah and appreciate the sentiment.
>
> But... I think elm-discuss is quite nice.
>
> I haven't seen anything egregious, and rather free form discussion rather
> than pointing people to the rule book every once in a while.
>
> From my POV almost everyone comes with the right attitude here.
>
>
>
> On Fri 5. May 2017 at 03:33, Noah Hall <enali...@gmail.com> wrote:
>>
>> Hi folks,
>>
>> We've come up with some new rules for posting on elm-discuss. You can see
>> them here. The goal is to have a healthier, happier mailing list, with more
>> people feeling like they want to take part.
>>
>> --
>> 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.

-- 
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] New guidelines for posting on Elm-discuss

[Noah Hall]

Hi folks,

We've come up with some new rules for posting on elm-discuss. You can see 
them here 
. 
The goal is to have a healthier, happier mailing list, with more people 
feeling like they want to take part.

-- 
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] Literature reviews repo

[Noah Hall]

I suggest making this repo part of the elm-community org, if it is to be made.

On Mon, May 1, 2017 at 10:14 AM, Oliver Searle-Barnes  wrote:
> In https://groups.google.com/forum/#!topic/elm-discuss/yHiAJ_wcG3c Max
> proposes that we put together some literature reviews. If we're to
> collaborate on this effort we'll need to consolidate our investigations
> somewhere. Having seen the success of the RFCS repos for Ember and Rust I
> wonder if we could use a similar model. RFCs for those languages are in the
> business of proposing a concrete API (along with supporting evidence) but
> the structure of a literature review could be a template based around the
> questions Max posed.
>
> I believe this would give us an open process that the community can
> contribute to collectively. It would allow newcomers to the language to get
> an overview of what the community is thinking about (saving on the countless
> reruns of feature discussions we have in here) while providing a structure
> and focus that will provide Evan with the information that he needs.
>
> --
> 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] Ports seem contrived when trying to format a value as money

[Noah Hall]

Witold, that's a ridiculous response. Please re-read my reply. Without
fully knowing the context of the problem, you suggested using Native.
This is not something we encourage in the Elm community. There are
valid reasons as to why not. When recommending it, is it best to know
_everything_ about the situtation. Like I said, it should _never_ be
the first thing you reach for. I emphasised this in both my replies.
Please re-read them.

Dwayne, please come get help on Slack. People are helpful there, and
we will help drill down into the best possible solution for your
problem. :)

On Mon, May 1, 2017 at 1:12 AM, Witold Szczerba <witoldsz@gmail.com> wrote:
> Noah is always right. He's just a Elm Rock Star, he knows the best. is that
> realy what be said to me or did I miss the point? I have no idea what I was
> thinking when I dreaded to "lecture" him.
>
> Oh, by the way, Dwayne's attempt to follow those golden rules failed. He
> must have missed something obvious, like reimplementing the formatting in
> Elm by his own.
>
> Dustin is right here. If it's trivial then just go for it, Dwayne, really.
> If it's not simple then... suffer, or do what I did and get the job done,
> just do follow all the FP rules and don't feel "bad" about it all.
>
> 01.05.2017 12:15 AM "Erik Lott" <mrerikl...@gmail.com> napisał(a):
>>
>> Noah is right. You don't want to reach for Native for this type of
>> integration. If this can't be smoothly integrated with ports (we've all felt
>> that pain), the next best option is to write the elements of the plug-in
>> that you need in elm.
>>
>> On Sunday, April 30, 2017 at 1:37:04 PM UTC-4, Noah Hall wrote:
>>>
>>> Witold, with all due respect, I am one of the people who has written
>>> the _most_ Native code. I know a thing or two about it. You do not
>>> need to lecture me, and my warning should be heeded.
>>>
>>> Like I said, there are _some_ cases where a Native binding makes
>>> sense. They are few and far between.  These problems are best
>>> discussed on Slack, where we can drill down into the exact use case.
>>> For example, is it only one currency format? If it is, re-writing in
>>> Elm should be trivial.
>>>
>>> On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba <witold...@gmail.com>
>>> wrote:
>>> > Noah, this is exactly the kind of problem to be solved by native
>>> > binding.
>>> > Dwayne wants to use his formatting library. This is a classic example
>>> > of
>>> > pure function. Nothing is going to crash if you wrap exception in
>>> > Result and
>>> > check types.
>>> >
>>> > Good advices of self reimplementig everything from scratch in Elm or
>>> > using
>>> > subscriptions for pure functions is nothing but making Elm people
>>> > suffer
>>> > instead of getting things done.
>>> >
>>> > Native bindings are not bad per se. Just use it wisely, be pragmatic or
>>> > we
>>> > will read another "Moving on", by Dwayne Crooks" this time.
>>> >
>>> > 30.04.2017 7:07 PM "Noah Hall" <enal...@gmail.com> napisał(a):
>>> >>
>>> >> Witold, this it not the advice that we give to people exploring such
>>> >> problems in Elm. There are many reasons why Native bindings are bad. A
>>> >> single error in your JS will cause the _entire_ application to crash
>>> >> unrecoverably. Wrapping things as a result will not help you catch
>>> >> those errors. Writing carefully thought out and tested code will.
>>> >> While there are cases where a Native function helps out a lot, it
>>> >> should _never_ be the first thing to reach for.
>>> >>
>>> >>
>>> >> Dwayne, I suggest discussing things on the Elm Slack. It will be
>>> >> easier to get to the exact use case you have for your formatting
>>> >> issue.
>>> >>
>>> >>
>>> >> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba <witold...@gmail.com>
>>> >> wrote:
>>> >> > Ports and subscriptions are for executing actions with effects, in
>>> >> > my
>>> >> > opinion. Native bindings for pure functions are nothing bad. Just
>>> >> > keep
>>> >> > away
>>> >> > from exceptions, use Result in case of possible troubles.
>>> >> >
>>> >> > 30.04.2017 4:00 PM &quo

Re: [elm-discuss] Re: Moving on

[Noah Hall]

This thread is too long to be productive. Please make a new thread, if
you wish to continue the discussion here, with a relevant title to the
particular part of this conversation you wish to continue in. When a
thread gets long like this, hitting multiple topics, it's hard for
anyone but those invested in the thread to reply. It's best to keep
things concise and to the point.

-- 
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] Ports seem contrived when trying to format a value as money

[Noah Hall]

Witold, with all due respect, I am one of the people who has written
the _most_ Native code. I know a thing or two about it. You do not
need to lecture me, and my warning should be heeded.

Like I said, there are _some_ cases where a Native binding makes
sense. They are few and far between.  These problems are best
discussed on Slack, where we can drill down into the exact use case.
For example, is it only one currency format? If it is, re-writing in
Elm should be trivial.

On Sun, Apr 30, 2017 at 7:30 PM, Witold Szczerba <witoldsz@gmail.com> wrote:
> Noah, this is exactly the kind of problem to be solved by native binding.
> Dwayne wants to use his formatting library. This is a classic example of
> pure function. Nothing is going to crash if you wrap exception in Result and
> check types.
>
> Good advices of self reimplementig everything from scratch in Elm or using
> subscriptions for pure functions is nothing but making Elm people suffer
> instead of getting things done.
>
> Native bindings are not bad per se. Just use it wisely, be pragmatic or we
> will read another "Moving on", by Dwayne Crooks" this time.
>
> 30.04.2017 7:07 PM "Noah Hall" <enali...@gmail.com> napisał(a):
>>
>> Witold, this it not the advice that we give to people exploring such
>> problems in Elm. There are many reasons why Native bindings are bad. A
>> single error in your JS will cause the _entire_ application to crash
>> unrecoverably. Wrapping things as a result will not help you catch
>> those errors. Writing carefully thought out and tested code will.
>> While there are cases where a Native function helps out a lot, it
>> should _never_ be the first thing to reach for.
>>
>>
>> Dwayne, I suggest discussing things on the Elm Slack. It will be
>> easier to get to the exact use case you have for your formatting
>> issue.
>>
>>
>> On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba <witoldsz@gmail.com>
>> wrote:
>> > Ports and subscriptions are for executing actions with effects, in my
>> > opinion. Native bindings for pure functions are nothing bad. Just keep
>> > away
>> > from exceptions, use Result in case of possible troubles.
>> >
>> > 30.04.2017 4:00 PM "Dwayne Crooks" <dwayne.cro...@gmail.com> napisał(a):
>> >>
>> >> Thanks guys.
>> >>
>> >> I explored Noah's approach to see how the solution would turn out. But
>> >> I
>> >> didn't like it. The code change required to format a list of floats as
>> >> money
>> >> is ridiculous. Here's what I started with
>> >>
>> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
>> >> And here's what I ended up with
>> >>
>> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
>> >>
>> >> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.
>> >>
>> >> P.S. The solution still doesn't quite work because all money receives
>> >> the
>> >> first incoming subscription message causing them to display the same
>> >> formatted value. I didn't bother to fix it because the solution is bad
>> >> enough.
>> >>
>> >> I think we can safely rule out ports. Noah, do you have any thoughts on
>> >> the code? Did I miss anything?
>> >>
>> >> That leaves us with:
>> >>
>> >> Using a Native module. (Looks like the best compromise for my needs in
>> >> the
>> >> short-term.)
>> >> Rewrite in pure Elm. (Looks like the best long-term solution.)
>> >>
>> >> Next step: I will write up a Native solution and see how that goes.
>> >>
>> >> --
>> >> 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

Re: [elm-discuss] Ports seem contrived when trying to format a value as money

[Noah Hall]

Witold, this it not the advice that we give to people exploring such
problems in Elm. There are many reasons why Native bindings are bad. A
single error in your JS will cause the _entire_ application to crash
unrecoverably. Wrapping things as a result will not help you catch
those errors. Writing carefully thought out and tested code will.
While there are cases where a Native function helps out a lot, it
should _never_ be the first thing to reach for.


Dwayne, I suggest discussing things on the Elm Slack. It will be
easier to get to the exact use case you have for your formatting
issue.


On Sun, Apr 30, 2017 at 7:03 PM, Witold Szczerba  wrote:
> Ports and subscriptions are for executing actions with effects, in my
> opinion. Native bindings for pure functions are nothing bad. Just keep away
> from exceptions, use Result in case of possible troubles.
>
> 30.04.2017 4:00 PM "Dwayne Crooks"  napisał(a):
>>
>> Thanks guys.
>>
>> I explored Noah's approach to see how the solution would turn out. But I
>> didn't like it. The code change required to format a list of floats as money
>> is ridiculous. Here's what I started with
>> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-0-start-elm.
>> And here's what I ended up with
>> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1a-useports-elm,
>> https://gist.github.com/dwayne/550341a5b27ba3c03ce7eba92d33873d#file-1b-useports-html.
>>
>> P.S. The solution still doesn't quite work because all money receives the
>> first incoming subscription message causing them to display the same
>> formatted value. I didn't bother to fix it because the solution is bad
>> enough.
>>
>> I think we can safely rule out ports. Noah, do you have any thoughts on
>> the code? Did I miss anything?
>>
>> That leaves us with:
>>
>> Using a Native module. (Looks like the best compromise for my needs in the
>> short-term.)
>> Rewrite in pure Elm. (Looks like the best long-term solution.)
>>
>> Next step: I will write up a Native solution and see how that goes.
>>
>> --
>> 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.

-- 
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] Ports seem contrived when trying to format a value as money

[Noah Hall]

The recommended approach is to rewrite the logic you need into Elm.
Otherwise, what you can do is make your model store the current money,
then pull it back in through a port. Store the input money, as a
placeholder until it has been calculated and recieved back into Elm.
It should look something like this:

type Money = Unformatted String | Formatted String
type alias Model = { currentMoney : Money }

type Msg = OnMoneyInput String | FormattedMoney String

update msg model =
  case msg of
OnMoneyInput money -> ({ model | currentMoney = Unformatted money
}, Format.toMoney money)

FormattedMoney money -> ( { model | currentMoney = Formatted
String }, Cmd.none )

subs model =
  Format.incomingMoney FormattedMoney

view model =
  case model.currentMoney of
Unformatted money -> Html.text money
FormattedMoney money -> Html.text money

main = ...

On Sat, Apr 29, 2017 at 2:26 PM, Dwayne Crooks  wrote:
> I'm porting an application from React/Redux to Elm and I'm having trouble
> figuring out how to format a value as money. In the original application we
> used http://openexchangerates.github.io/accounting.js/. So naturally I
> wanted to make use of that same library when writing the Elm version. Based
> on my reading ports seem to be the solution however when I think through the
> implications it doesn't seem natural to write my code in that way when
> formatting is a presentation concern.
>
> Here's what I came up with:
>
> 1. I created a port module called Format.
>
>> port module Format exposing (..)
>>
>> port asMoney : Float -> Cmd msg
>> port moneyFormats : (String -> msg) -> Sub msg
>
>
> 2. I originally envisioned writing the view as follows:
>
>> viewSales : Float -> Html Msg
>> viewSales amount =
>> viewWidget "Gross Sales (All Time)" (Format.asMoney amount)
>
>
> But obviously, that's out the window since Format.asMoney returns a command.
>
> 3. It means I now have to format in my update function and store the
> formatted data in my model so that my view can access it. I find that very
> inconvenient and I don't want presentation concerns in neither my update
> function nor my model.
>
> Am I thinking through this correctly?
>
> How do I proceed?
>
> Should I consider writing an external library with a Native module like for
> e.g. https://github.com/NoRedInk/elm-moment or
> https://github.com/evancz/elm-graphics?
>
> Any help would be greatly appreciated.
>
> --
> 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] How to get typed-svg into elm-community?

[Noah Hall]

Like I replied in that thread, open an issue at
https://github.com/elm-community/manifesto and we will discuss there.
Looks like one has already been created:
https://github.com/elm-community/Manifesto/issues/69

On Tue, Apr 25, 2017 at 4:45 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> It would be good to get this moved to elm-community provided canadaduane is
> happy with that. I did not realize until I started using it that the
> elm-lang/svg is untyped Strings all the way, so it would seem worth
> re-writing a more strongly typed SVG library with a view to replacing the
> default elm-lang one. I guess elm-lang/svg did not get much love as its a
> big API to cover.
>
> How does one join the elm-community group, fork this project into it, and
> get commit rights to work on 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.

Re: [elm-discuss] Re: Moving on

[Noah Hall]

Open an issue here: https://github.com/elm-community/manifesto and we'll discuss

On Tue, Apr 25, 2017 at 12:36 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> On Monday, April 24, 2017 at 4:59:43 PM UTC+1, Jakub Hampl wrote:
>>
>> Typed SVG is a fantastic and much needed project so I hope somebody takes
>> over. I wonder if elm-community would take it over? I'd be happy to review
>> pull requests and do some other light maintenance work, but unfortunately
>> can't commit any real time to continue development.
>
>
> Exactly what I was thinking - can it be moved to elm-community and work
> continued on it there?
>
> --
> 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] Why `let`?

[Noah Hall]

Two notes:

Let bindings do not have order. Using them in the way suggested
implies order. In this world, they would have to be ordered or
confusion would reign. This is more imperative style.

I've actually really disliked this in CoffeeScript/Ruby, that
implicitly the last item in the block is the thing returned. Makes it
a lot harder to parse mentally.

-1.

On Fri, Apr 14, 2017 at 10:00 PM, Akio Burns  wrote:
> It's not clear to me why Elm uses `let`, instead of simply scoping
> definitions to the expression below them.
>
>
> With `let`:
>
> foo =
> let
> a = 1
> b = 2
> in
> a + b
>
> Scoping definitions to the expression below them:
>
> foo =
> a = 1
> b = 2
>
> a + b
>
>
> I understand that each function must contain a single expression. In Elm,
> although they contain expressions, definitions are not expressions.
>
>
> Visualized:
>
> foo =
> 
>
> foo =
> a + 2 <- EXPRESSION
>
> foo =
> a = 1 <- DEFINITION SCOPED TO THE a + 2 EXPRESSION
> a + 2
>
>
> Another way to demonstrate scope is:
>
> let
> a = 1
> b = 2
> in
> a + b
>
> would become (parenthesis to demonstrate scope):
>
> (
> a = 1
> b = 2
>
> a + b
> )
>
>
> It seems to me that `let` and `in` are unnecessary and verbose. Put another
> way, I think few people would agree that requiring a keyword before variable
> assignment `set a = 1` would be a good idea. The `=` makes the intent
> explicit. Likewise, indentation—or parenthesis—could make scopes explicit,
> and `let` and `in` unnecessary.
>
> Some have argued that without `let`, we could not have arbitrarily nested
> scopes. I don't have significant experience with Elm, but I would guess that
> nesting `let`s today is pretty big code smell. Instead of nesting `let`s to
> reuse variable names, developers should either pick more descriptive
> variable names, or abstract into a function.
>
>
> This could—of course—apply anywhere an expression is expected:
>
> True ->
> x = 0
> y = 0
>
> (x, y)
> ...
>
>
> @rtfeldman on the Slack pointed out that this syntax is more diff friendly:
>
> if I write a view function like
> view model =
> div []
> [ ... lots of other stuff ]
>
> and then I want to introduce a nested constant like so:
> view model =
> let
> foo = ...
> in
> div []
> [ ... lots of other stuff ]
>
> the fact that I indented the final expression makes the VCS diff explode
> this happens to me all the time, and it's pretty annoying
> with [this] idea it wouldn't happen anymore
>
>
> Lastly, here's elm-todomvc with scoped definitions, courtesy of @rtfeldman
> again:
>
> https://github.com/rtfeldman/elm-todomvc/blob/8678c8bcaeb5cb4b3f87dbefb7a01b5fe492dbc7/Todo.elm
>
> --
> 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: Comments on the TEA Components package

[Noah Hall]

Hey folks,

I just want to say, it's really really really hard to reply to these
posts which are both really long and really dense. It's better to
answer in a terse, short format. This is a conversation - not a blog
post. Longer comments and responses are usually better in a blog post,
because it's quite hard to keep all the context in our heads for each
mail on a mailing list.

Regarding how to structure code for large apps, I really recommend
looking at the NRI elm-style-guide.
https://github.com/noredink/elm-style-guide#nri

The "reusable" parts are those prefixed by `Nri`. Here's an example of
what some type signatures might look like:

-- Button.elm
view : msg -> Html msg
view onClick = ...

-- Emoji.elm
type Emoji = Smile | SadFace
view : Emoji -> Html msg
view emoji = ...

-- Leaderboard.elm

type LeaderSettings field = { numberOfPlayers : Int, fields: List field }
view : LeaderSettings field -> (field -> msg) -> Html msg
view settings onFieldChange = ...


I recommend trying out this approach, and see how you like it. It
makes implementing things _so_ simple. I've tried every approach under
the sun, and seen more codebases than I can count. This is the one
that wins for me.

If anyone tries this approach, but fails to get their head around how
to refactor their code to work with it, or fails to see how it's
simpler, hit me up on Slack (eeue56) or at elm-europe or
https://osloelmday.no, and I will guarantee your code will walk away
looking nicer than it did before.

On Wed, Apr 19, 2017 at 8:50 PM, Mark Hamburg  wrote:
> The monster model design is one aspect that leads to the ball of mud code.
> Let's look at the source quote for the term big ball of mud:
>
> A Big Ball of Mud is a haphazardly structured, sprawling, sloppy,
> duct-tape-and-baling-wire, spaghetti-code jungle. These systems show
> unmistakable signs of unregulated growth, and repeated, expedient repair.
> Information is shared promiscuously among distant elements of the system,
> often to the point where nearly all the important information becomes global
> or duplicated. The overall structure of the system may never have been well
> defined. If it was, it may have eroded beyond recognition. Programmers with
> a shred of architectural sensibility shun these quagmires. Only those who
> are unconcerned about architecture, and, perhaps, are comfortable with the
> inertia of the day-to-day chore of patching the holes in these failing
> dikes, are content to work on such systems.
>
> — Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on
> Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois,
> September 1997
>
> When everything starts out in one place with access to everything else, it's
> natural to end up with everything talking to and depending on everything
> else — or at least the dependencies are less likely to be well regulated
> because there is no mechanism doing the regulation. Now, as conservative
> politicians will love to tell you, regulations get in the way and we can be
> more productive without them, so yes, this unregulated environment is
> seemingly more productive. The type system will help in detecting out and
> out errors in making changes but once things get intertwined, they become
> less amenable to significant change. That's often fine for an agile
> development model in which one focuses on small changes but I've seen agile
> teams that could generate lots of small changes but when faced with needing
> to do something big found themselves profoundly stuck. An approach which
> basically seems to advocate building a monolithic, intertwined codebase and
> if that gets to be too much, here are some techniques to break it down after
> the fact will work to an extent but will be fighting to apply order to chaos
> and almost all the time it will be easier for a developer trying to get a
> task done to just add a little more chaos.
>
> As for your specific advice, it includes several useful points and I've
> refactored code using those same techniques, but the distillation of the
> don't use nested TEA argument when people have asked what to do instead has
> tended to be "use functions" which as I've noted doesn't mean much in a
> functional language. (I guess it means use functions rather than types but
> since types are what allow us to make illegal states impossible, I don't
> think it really comes down to just use functions either.) What TEA and
> nested TEA provided was architectural guidance on how to structure things
> for long term evolution. Saying, if your update function gets too big you
> can handle individual cases with separate functions is I guess useful advice
> but something that I would hope would be obvious to most people working in a
> functional language. What sort of calling conventions work well? Which ones
> don't work well and should be avoided? That's the sort of architectural
> advice that can be put into practice early on and 

Re: [elm-discuss] Module intermittently missing from compiler output

[Noah Hall]

Never seen this before. Pop on to elm-dev on slack and I can help out. Will
be afk til Sunday though

On Thursday, April 13, 2017, Kevin Yank  wrote:

> For awhile now, we’ve been seeing intermittent issues with our build,
> where a particular module in our application will occasionally be missing
> from the JavaScript output produced by the Elm compiler. We’ve seen it
> happening both in our CI environment and when building assets for
> production. We have yet to see it happen on a development machine. As our
> codebase has grown, this issue seems to be occurring more and more often,
> so I thought it might be worth checking if anyone else in the community had
> experienced anything like it.
>
> As I said, the problem manifests itself by a build producing a JavaScript
> output file where a particular module is simply missing. We then see an
> error like this one at runtime:
>
> ReferenceError: Can't find variable: _user$project$Dialog$init
> http://localhost:3001/assets/exit-34cc2ad64db7cb8f54fd.bundle.js:172568:83
> ReferenceError: Can't find variable: _user$project$Dialog$init
> http://localhost:3001/assets/exit-34cc2ad64db7cb8f54fd.bundle.js:172568:83
> at http://localhost:3001/assets/exit-34cc2ad64db7cb8f54fd.
> bundle.js:66078
> ReferenceError: Can't find variable: _user$project$Dialog$init
> ReferenceError: Can't find variable: _user$project$Dialog$init
> at http://localhost:3001/assets/exit-34cc2ad64db7cb8f54fd.
> bundle.js:172568
> at http://localhost:3001/assets/exit-34cc2ad64db7cb8f54fd.
> bundle.js:160309 in A2
> …
>
>
> When we repeat the build, we get a JavaScript bundle that works just fine.
> Comparing the contents reveals a chunk of JavaScript corresponding to one
> of our modules is simply missing. Where the Elm compiler seems to normally
> generate a single line of whitespace between two modules’ JavaScript
> output, there is a conspicuous two-line gap at the point where the missing
> code should be. Here’s what this looks like in a diff tool:
>
>
> Obviously this is a very long way from anything like a minimal test case
> that we could submit as a compiler bug, and unfortunately we can’t
> reproduce it reliably enough to be able to narrow it down.
>
> What I’m hoping is that someone else in the community is seeing something
> like this too. Actually, if I’m being honest, I’m hoping one of our friends
> at NoRedInk has experienced this issue and one of them is going to pop in
> and tell me “Oh yeah, that’s been fixed for the eventual release of 0.19.”
>
> Of possible relevance: we’re building our JavaScript bundles using Webpack
> and the elm-webpack-loader
> . We have it configured
> to run only a single instance of the Elm compiler at once, though, so I’m
> not sure how it could be responsible for this issue.
>
> Fingers crossed we’re not alone in this!
>
> --
> Kevin Yank
> Lead Developer
>
> twitter: @sentience
> skype: kevinyank
>
>
> Culture analytics for your company
> www.cultureamp.com
>
> --
> 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 events 2017

[Noah Hall]

Mine is going to be different, and the CFP is open, so I doubt there
will be much duplication :) Luke is also going to be talking in Oslo,
and they're not going to speak at ElmEurope. The goal is to have a
complementary conference to ElmEurope, so people can go to both :).
You can check out the call for papers here if you're interested in
submitting one, too ->
https://docs.google.com/forms/d/e/1FAIpQLSdgMw1ymqiM92UtrYEAVBGisbJBuv9ers8Q36qIAQSga9dX5A/viewform?c=0=1

On Thu, Apr 6, 2017 at 12:58 PM, Richard Wood  wrote:
> Hi Noah
>
> Is Oslo likely to be the same talks as the speakers did at Elm Europe?
> If not I'll come to that as well.
>
> Cheers
> Richard
>
> --
> 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 events 2017

[Noah Hall]

Forgot a link for flatmap: http://2017.flatmap.no/

On Wed, Apr 5, 2017 at 4:50 PM, Noah Hall <enali...@gmail.com> wrote:
> There's a talk about Elm at flatmap by Erik Wendel, and a workshop run
> by me. Also, we're running https://osloelmday.no, a day dedicated to
> Elm talks in Oslo on the 10th of June. The call for papers are open!
>
> On Wed, Apr 5, 2017 at 4:15 PM, Austin Bingham <austin.bing...@gmail.com> 
> wrote:
>> If you're still building this list, I've got an Elm talk at ACCU:
>> https://conference.accu.org/site/stories/2017/sessions.html#XFunctionalProgrammingfortheWebwithElm
>>
>> Also, it looks like there is both an Elm workshop and a talk at NDC Oslo:
>> http://ndcoslo.com/
>>
>> In case you never got an answer to your earlier question about NDC, it
>> doesn't have a specific focus per se, though it does tend to lean quite
>> Microsoft. There are efforts underway to give it a broader perspective, and
>> those seem to be working, though slowly.
>>
>> On Friday, January 6, 2017 at 12:19:39 AM UTC+1, Rupert Smith wrote:
>>>
>>> Thinking of drawing up a list of events, dates and places where Elm will
>>> be on the menu in 2017. Would people be interested in contributing what they
>>> know to build up the list? Also, I have a feeling someone may already have
>>> done this, in which case point me to 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.

Re: [elm-discuss] Re: Elm events 2017

[Noah Hall]

There's a talk about Elm at flatmap by Erik Wendel, and a workshop run
by me. Also, we're running https://osloelmday.no, a day dedicated to
Elm talks in Oslo on the 10th of June. The call for papers are open!

On Wed, Apr 5, 2017 at 4:15 PM, Austin Bingham  wrote:
> If you're still building this list, I've got an Elm talk at ACCU:
> https://conference.accu.org/site/stories/2017/sessions.html#XFunctionalProgrammingfortheWebwithElm
>
> Also, it looks like there is both an Elm workshop and a talk at NDC Oslo:
> http://ndcoslo.com/
>
> In case you never got an answer to your earlier question about NDC, it
> doesn't have a specific focus per se, though it does tend to lean quite
> Microsoft. There are efforts underway to give it a broader perspective, and
> those seem to be working, though slowly.
>
> On Friday, January 6, 2017 at 12:19:39 AM UTC+1, Rupert Smith wrote:
>>
>> Thinking of drawing up a list of events, dates and places where Elm will
>> be on the menu in 2017. Would people be interested in contributing what they
>> know to build up the list? Also, I have a feeling someone may already have
>> done this, in which case point me to 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.

Re: [elm-discuss] Re: Help with Jupyter/IPython notebook kernel for Elm

[Noah Hall]

If you join the https://elmlang.slack.com and join #elm-dev, I can
help you out (eeue56)

On Tue, Mar 28, 2017 at 4:53 PM, Berry Groenendijk
 wrote:
> Hi Austin,
>
> I like Jupyter/iPython a lot as a concept. I did not use it a lot though.
> And Elm seems to be like a natural fit.
>
> My dream would be to have live aka. living documents where static text and
> live code are intermingled. Jupyter is a step in the right direction. But,
> you still need a server.
>
> Just recently I found a thing called Klipse, see:
> http://blog.klipse.tech/javascript/2016/06/20/blog-javascript.html. It looks
> a lot like Jupyter (minus the document editing, but that should be trivial),
> but all the code is executed in the browser! It currently has support for
> clojure, ruby, javascript, python, scheme, es2017, jsx, brainfuck, c++ and
> Lua. Quite impressive. And if javascript works, them Elm should also work.
> Perhaps it is already possible... import elm.js... hmmm... I don't know.
>
> Sorry, if this post isn't directly related to Jupyter and your challenge to
> integrate Elm in Jupyter.
>
> Op maandag 27 maart 2017 20:10:33 UTC+2 schreef Austin Bingham:
>>
>> Hi everyone,
>>
>> I started hacking a bit today on a Jupyter notebook kernel for elm. You
>> can see it here:
>>
>> https://github.com/abingham/jupyter-elm-kernel
>>
>> It doesn't quite work yet, though, and I think I need help from someone
>> who knows javascript/requirejs/web stuff a bit better than me. The proximal
>> problem I'm seeing is that when jupyter tries to run the elm-make-generated
>> javascript, it thinks that 'Elm' is undefined during (I think) some part of
>> the AMD machinery. Jupyter show this as the output for the cell:
>>
>> Javascript error adding output!
>> ReferenceError: Elm is not defined
>> See your browser Javascript console for more details.
>>
>> As far as I can see, Elm *should* be defined, and certainly the generated
>> code looks like any other Elm output I've looked at. So I'm a bit stumped.
>>
>> My approach to the kernel is currently very simple. The kernel is
>> implemented in Python, and it receives a blob of Elm source code. I dump
>> this to a temp file, use a subprocess to run "elm-make" to make the output,
>> read the output, and ship it back to jupyter. As far as I can see, all of
>> that is working properly. I run into problems when jupyter tries to execute
>> the stuff I return. This design may or may not be optimal in the long run,
>> but I want to get the plumbing working first.
>>
>> So if someone feels up to the challenge, I'd love any help I could get.
>> This seems like it should be pretty straightforward, but perhaps I'm being
>> naive and/or missing something obvious.
>>
>> Of course, I'm also happy to discuss other aspects of the kernel (e.g.
>> design, compilation technique, etc.), but my priority is to just get
>> something into an output cell.
>
> --
> 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: 'Native' -> 'Kernel': a msgpack example

[Noah Hall]

> The work around is a native file along the lines of (or see this NoRedInk 
> library):

Sidenote: That is not a NoRedInk library. I do not work at NoRedInk
any more. It's a eeue56 library. It's important to distinct the two.

On Fri, Mar 24, 2017 at 4:19 AM, Martin Bailey  wrote:
> I suggested in elm-dev that adding a BitStream interface in Elm would make
> this kind of JS interop unnecessary. As it stands, one can't implement
> MsgPack in Elm since the only link to the outside world is JSON/String and
> binary data isn't valid UTF-16. I'd like to implement LZ-String in Elm for
> local storage compression but am not sure whether that'll be possible at
> some point. In the meantime, you can still write native/kernel code but just
> can't share it with the ecosystem.
>
> --
> 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] Is a decoder the right level of abstraction for parsing JSON?

[Noah Hall]

Http://json2elm.com. auto generating json "codecs" (decoders and encoders)
has existed for more than a year already.

On Friday, March 17, 2017, Kasey Speakman  wrote:

> Another update. I figured out how to get the encoders and decoders out of
> the ports using a native module. So I no longer have to actually send
> things across ports (still have to declare them). I can also now use Elm's
> Http module.
>
> Here's a gist of what it takes:
>
> https://gist.github.com/kspeakman/3f9521b0921b352c7d656261ec0a8fa6
>
> On Saturday, February 18, 2017 at 2:22:32 AM UTC-6, Kasey Speakman wrote:
>>
>> An update. I'm using the ports approach to deal with JSON (and also
>> sending the HTTP request). For several months, I've had a small but
>> critical app in production using that. Another project in development is
>> too. In the process, I have run across two additional caveats with this
>> approach.
>>
>>1. *Ports don't convert undefined properties to Maybe.Nothing.* It's
>>an open issue from Jan 2016.
>>
>>For a Maybe property, the JSON must have the property present and set
>>to null. Otherwise error. This is particularly annoying when you store the
>>data as JSON and pass it back to the client as-is. To work around this
>>issue, I either have to waste space storing nulls in the database or waste
>>(CPU/response) time server-side to inject nulls in the response.
>>
>>2. *Cmd.map can't be used with this method.*
>>Using Http module, you can use Cmd.map to take some data from the
>>request and give it to the response Msg. Using ports, you can't do that.
>>I've noticed this when the data is easy to provide for a request, but 
>> after
>>the response comes back it is less convenient to dig out of the model 
>> (e.g.
>>behind a case statement).
>>
>> Neither of these are blockers for me, just nuisance issues. It still
>> beats maintaining codecs.
>>
>> I've seen rumblings about tools for code-gen'ing JSON codecs for us (maybe
>> elm-format?  There also
>> exists elm-swagger, but I don't use swagger.). I dunno though. Where
>> possible, I tend to avoid code-gen because it's for handling a really
>> tedious problem. And if the code-gen fails, then I have to handle a really
>> tedious problem. (XSD/WSDL flashbacks.)
>>
>> All it would really take for a profound QoL improvement are a couple of
>> "special" functions on Http that handle data exactly like ports do now...
>> just saying.
>>
> --
> 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] Simple way to screen-share an application written in Elm?

[Noah Hall]

Sure, in that case you just namespace the event by the device it came
from. There's an open-source repo here, containing an implementation
for 0.16 -> https://github.com/eeue56/elm-debugger. It should only
really be used for inspiration.

If you need more help implementing it, then Slack is generally the
best way to get it :)

On Fri, Mar 3, 2017 at 1:09 PM, 'Rupert Smith' via Elm Discuss
<elm-discuss@googlegroups.com> wrote:
> On Friday, March 3, 2017 at 10:55:30 AM UTC, Noah Hall wrote:
>>
>> Like oh-so-many things, I implemented this about 1.5 years ago now. I even
>> gave 2 talks on it. With Elm 0.17, you can implement it in under 30 lines of
>> code, using firebase as a host. Sadly, the recordings of both the talks I
>> gave on it are lost. But you can read it here ->
>> https://github.com/eeue56/talks/tree/master/experiments_in_elm#the-future-of-debugging-with-elm
>
>
> You are oh-so-ahead-of-the-curve! Don't suppose you still have the code for
> it lurking in some github repo by any chance?
>
> I thinking that a straightforward replay of messages across the whole
> application will probably not be a magic solution to writing a multi-user
> collaborative application. For example, in code I am working with currently,
> I render some stuff in a fixed position overlay, and its position will
> depend on how the client window is sized and scrolled - so a straightforward
> replay will likely see things end up in the wrong position. I think for
> collaborative work I would need to look into Operational Transformation
> (https://en.wikipedia.org/wiki/Operational_transformation) which is the
> technique that made Google Wave work. The idea would be to replicate a
> carefully chosen subset of events across all clients, and to ensure that
> they communicate the users intentions rather than details which are wholly
> specific to one client rendering or another. OT also deals with interleaving
> events without applying a global sequential ordering.
>
> I thinks Elms update-model-view structure would be very convenient for OT.
> It still might be fun to try out a straightforward event replay across
> clients with 30 lines of code though.
>
> --
> 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] Simple way to screen-share an application written in Elm?

[Noah Hall]

Like oh-so-many things, I implemented this about 1.5 years ago now. I even
gave 2 talks on it. With Elm 0.17, you can implement it in under 30 lines
of code, using firebase as a host. Sadly, the recordings of both the talks
I gave on it are lost. But you can read it here ->
https://github.com/eeue56/talks/tree/master/experiments_in_elm#the-future-of-debugging-with-elm

On Fri, Mar 3, 2017 at 7:15 AM, Zachary Kessin  wrote:

> No but that would be a really cool idea, I can think of several places
> that this could be useful, for example checking that things work the same
> on all browsers. Or being able to generate a sequence of events from a
> quickcheck type thing and play them in a browser.
>
> Zach
> ᐧ
>
> On Thu, Mar 2, 2017 at 5:57 PM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com> wrote:
>
>> Anyone tried something along these lines:
>>
>> The state of an application in Elm can be re-built by starting from its
>> 'init' state, then replaying all messages to a given state. This is called
>> event sourcing.
>>
>> If I am using some application written in Elm, and I want to share what I
>> am doing with someone else, all I need is for them to start up the same
>> application, the replay my event stream over it. Something like AMQP over
>> Web Sockets could provide the transport layer.
>>
>> There might need to be a way on the slave application to ignore all of
>> the local users events, and only update the model from the event source
>> from the master. That should be fairly easy to achieve by wrapping the
>> Program with one that does this.
>>
>> For a multi-user application, a simple but perhaps too inefficient way of
>> keeping things in sync would be for all user events to be round-tripped
>> through a message queue in order to put them in a sequential order that is
>> the same for all participants. So local input events would not go straight
>> to the update function, but be round tripped over the network. Would
>> probably work well enough for a small number of users on the LAN.
>>
>> Just curious to know if anyone has ever experimented with Elm along these
>> lines.
>>
>> --
>> 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.
>>
>
>
>
> --
> Zach Kessin
> Skype: zachkessin
>
> --
> 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] Using Elm on the server (full stack Elm webapps )

[Noah Hall]

I've already done this. Full stack elm is not a feasable option right now.
You can use elm to drive your logic if you want but the amount of
boilerplate and overhead from the runtime make it inefficent for a server.
For full stack elm, with the server code in elm, youll find yoyrself
fighting nodemore than anything else. See the readme of
https://github.com/noredink/take-home

On Thursday, January 26, 2017, Peter Damoc  wrote:

>
>
> On Thu, Jan 26, 2017 at 6:40 PM, 'Rupert Smith' via Elm Discuss <
> elm-discuss@googlegroups.com
> > wrote:
>
>> Still, its a long way from there to a full stack...
>>
>> Every journey has to start somewhere. Can you share a set of requirements
> for a full-stack? Like, how would a checklist for your must have and nice
> to have features would be?
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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] Maintainers wanted

[Noah Hall]

Please move these to elm-community. I can help move them over. Reach
on slack on #elm-community

On Fri, Jan 20, 2017 at 7:38 PM, Joey Eremondi  wrote:
> Might these be candidates for migrating to elm-community?
>
> On Fri, Jan 20, 2017 at 2:29 AM, Bogdan Popa  wrote:
>>
>> Hi folks,
>>
>> Due to various reasons, I will no longer be focusing my attention on Elm
>> for the foreseeable future. Unfortunately, this means that the libraries
>> that I have created/have been maintaining so far will no longer be
>> maintained by me. AFAICT, the following libraries are seeing a decent amount
>> of use:
>>
>> * elm-combine
>> * elm-datepicker
>> * elm-route
>> * elm-time
>>
>> It would be sad to see them die off and I would feel bad letting down any
>> of their current users by not providing a path forward. If you depend on any
>> of these and would like to step up and start maintaining one or more of
>> them, please e-mail me directly.
>>
>> I had also been maintaining the Elm mode for Emacs for the past couple of
>> years. I cannot give others commit access to that repository, but I'm sure
>> @jcollard would happily do it if anyone wants to step up and maintain the
>> project.
>>
>> Thanks!
>> Bogdan
>>
>> --
>> 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.

-- 
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: [early prototype] Elm-Data: a server loading code generator

[Noah Hall]

> 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?).

I've left NRI, not vanished and therefore deleted every thing of note
I've ever done and banned everyone from using my things. Please use
it. It's not just in Python, there is a Elm version (with native) and
a node version (just js).

On Thu, Jan 19, 2017 at 5:18 AM, Max Goldstein <maxgoldste...@gmail.com> wrote:
> 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.

-- 
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] Isomorphic web apps with Elm?

[Noah Hall]

It's easier to say:

code shared between client and the server

than

isomorphic

and have everyone understand you. Isomorphic means a lot of different
things to different people. Say what you mean, and more people will be
able to take part and understand :)

On Mon, Jan 9, 2017 at 3:24 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> On Monday, January 9, 2017 at 1:55:08 PM UTC, Joel McCracken wrote:
>>>
>>> It was very, very nice. It allows for seemless APIs that simplified
>>> the code sharing a whole bunch.
>>
>>
>> Oh? My impression was that you thought this wasn't worth it, based upon
>> comments here
>> https://github.com/noredink/take-home#should-i-use-this-in-production and
>> IIRC what I've read elsewhere.
>>
>> Incidentally, I also hate the term isomorphic for shared client-server
>> code.
>
>
> From the wikipedia page for isomorphism:
>
> "The interest of isomorphisms lies in the fact that two isomorphic objects
> cannot be distinguished by using only the properties used to define
> morphisms; thus isomorphic objects may be considered the same as long as one
> considers only these properties and their consequences."
>
> Which sounds like a reasonable way to describe when the rendered page is
> exactly the same, whether it is rendered client side or server side. As I
> understand it though, it often means that some elements of the server side
> rendering may be ommitted or only mocked up. Particularly interactive
> elements that just won't work with a full server round trip, but will work
> asm interactice UI components on the client side.
>
> Also, I think describing what I am trying to do with my editing mode as
> 'progressive enhancement' isn't quite right either. I think the concept
> behind progressive enhancement is that you start with you baseline client;
> perhpas you even have to support some old version of IE, or users who will
> not have javascript enabled in their browser. You code for that in the main,
> but add capabilities that better browsers/environments can take advantage
> of, if they are available.
>
> Not sure why you don't like isomorphism, has the word been poisened by too
> may javascript libraries?
>
> --
> 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] Isomorphic web apps with Elm?

[Noah Hall]

Let's not use Javascript names for things here here: you mean shared
code between client and the server.

Like everything else in the area, I have already done this in the
take-home: https://github.com/noredink/take-home#support-summary

It was very, very nice. It allows for seemless APIs that simplified
the code sharing a whole bunch.

On Mon, Jan 9, 2017 at 12:24 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> Just wondering if there is anyone out there interested in isomorphic
> applications with Elm? or has tried experimenting with isomorphic Elm?
>
> Now that I have the same view code running on server and client side, it
> occurs to me that I am potentially getting into isomorphic web development.
> If I understand it right, and isomorphic app is one which is written in
> javascript in order to run the same code client or server side. Some or all
> of the page rendering is done server side, then whatever has been rendered
> plus the application state is handed over to the client, and the client
> displays it or completes or enhances the rendering. The idea is to be able
> to get the best of both worlds without having to write the code twice; once
> in javascript for the client and once in some other language for the server.
>
> In my case, I am using server side rendering just for (relatively) static
> content, so there is practically no application state. I am pretty much
> there with this simple application model as far as being isomorphic goes.
>
> I believe there is something called the 'isomorphic hand-off' which refers
> to the transfer of state from server to client, once the server rendering
> has completed. I think this needs to go something like this:
>
> Run Elm on Server to produce HTML + a little bit of javascript to request
> everything needed to complete on the client.
> Show HTML on the client as quickly as possible (that is, don't download the
> Elm code just yet).
> Trigger the loading of the javascript needed to complete the client side
> rendering (the same Elm program as was run on the server).
> Start up the Elm program and request the state from the server.
> Continue rendering from where the server side left off.
>
> I'm really not sure what exactly the difference is between isomorphic and
> progressive enhancement. What I am actually trying to do is to add an
> editing mode on the client side - so client and server side renderings will
> be very different and more capabilities will be available in client editing
> mode. For this reason, I don't think isomorphic is really what I am after,
> but I can't help wondering if Elm provides a very neat starting point for
> doing it.
>
> I think Elm might be very well suited to isomorphic, so long as you keep the
> model clean and don't put any functions in it. If it is easy to
> encode/decode the model, then it becomes almost trivial to write the
> isomorphic hand-off?
>
> --
> 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] Is it possible to programmatically start an Elm program via Native?

[Noah Hall]

It's not 100% clear to me what you want to do, but if you ping me on
#elm-dev on slack then I can probably help. Better to discuss it there

On Sat, Jan 7, 2017 at 12:18 PM, Peter Damoc  wrote:
> I'm trying to explore how one could implement web-components in Elm natively
> using a minimal amount of Native code.
>
> The approach I tried is to use some code from
> https://github.com/WebReflection/dom-class
> https://www.webreflection.co.uk/blog/2015/09/17/simplified-web-components-via-dom-class
> and adapt it to Elm
>
> I managed to register the component and have it mount the needed CSS
> https://github.com/pdamoc/elm-box
>
> If you want to try it:
> - clone the repository
> - use elm-github-install in the examples folder
> - elm-make FirstMain.elm --output=elm.js
> - open First.html
>
> Now, is it possible to start a potential Elm program and embed it in the
> constructor or in the onAttached handler?
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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] How does evancz.Markdown work?

[Noah Hall]

It does support custom and supports markdown as a special case -
https://github.com/eeue56/elm-server-side-renderer/blob/master/src/ServerSide/Markdown.elm

However, it doesn't convert it to html on the server side. That should be
trivial to add - just a called to marked, but I haven't needed it yet


On Thursday, January 5, 2017, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> On Wednesday, January 4, 2017 at 11:01:44 PM UTC, Rupert Smith wrote:
>>
>> When server side rendering Html I am trying to figure out why markdown
>> processing is not working right.
>>
>
> I just get the unprocessed markdown appearing in the page. Perhaps:
>
> https://github.com/eeue56/elm-server-side-renderer
>
> does not support the "custom" Html model. I'll take a look and see if it
> can be made to work...
>
> --
> 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...

[Noah Hall]

Tight calculation loops and performance matters a lot in some cases
such as complex form validation. I've spoken with at least one company
suffering these bottlenecks with Elm, but it was resolvable by just
changing how the data is modelled.

For performance in production, if you're not running a game, then the
longest computational time is likely from multiple re-renders. Which
is thankfully not an issue. TBH, we do not care in production if Elm
is the "fastest". We care if it is "fast enough", which it is.

On Tue, Dec 27, 2016 at 2:01 PM, Robin Heggelund Hansen
 wrote:
> I was the one who raised the original issue. The reason there is only a 20%
> performance in the given example is because the comparison operator isn't
> the bottleneck of the code, which tests retrieving an object from an
> immutable array with 10.000 elements. What you are testing is essentially
> only measuring the overhead of a comparison operation. Still, my benchmark
> is able to run at 7,5 million ops per second, running on a macbook air from
> 2013. This is fast enough for most web apps, and this brings me to my next
> point.
>
> Elm is, at least currently, a language to make web applications. How often
> are you going to run calculations in tight loops where the performance
> impact of comparison or equality operators gives a noticeable performance
> impact for the end user in a web browser?
>
> I'm not saying that the proposed optimisation isn't worthwhile, it is. But
> Elm, being a 0.x language still, has a lot more important things to improve
> on before it turns its attention back to performance, which is already very
> good. Things like hot-code reloading, improved package manager and bug
> fixes.
>
>
> tirsdag 27. desember 2016 03.41.29 UTC+1 skrev GordonBGood følgende:
>>
>>
>>
>> On Tuesday, 27 December 2016 05:37:43 UTC+7, Robin Heggelund Hansen wrote:
>>>
>>> Part I: Evan is already aware of this issue, you can see the full
>>> discussion in this github issue:
>>> https://github.com/elm-lang/elm-compiler/issues/1528
>>> The short of it is that the code generator part of the compiler is not
>>> aware of type information, and adding this would be a serious undertaking.
>>> It will probably come at some point, as there are interesting optimizations
>>> that can be made, like the one mentioned
>>
>>
>> Although it is good to see that Even is aware of the issue, it is
>> discouraging to learn that the type information is not retained by the code
>> generator and therefore this improvement is part of a "huge project"; thus
>> the linked issue has been closed.  The person who raised the original issue
>> developed some timing results that showed only about a 20% speed improvement
>> for the particular code use.  However, when I compare the above tight loop
>> written directly in JavaScript, the difference here is about 700%!  Of
>> course, real use cases won't be quite this large, but I could see a fairly
>> tight loop being 300% (+/- 100%) faster.
>>
>>>
>>>
>>> Part II: Bitwise operators are inlined in 0.18, which gave a noticable
>>> performance boost in libraries like Skinney/elm-array-exploration and
>>> mgold/random-pcg. Having it available as a function (just like +, -, * etc.)
>>> allows more flexibility like currying.
>>
>>
>>  I checked and you are right that these functions are now inlined.
>>
>> The only other thing they should also have is infix for those with two
>> operands for better (conventional) clarity of code, but this is no biggy.
>>
>> It turns out that the huge slowdown as compared to equivalent JavaScript
>> code is another instance of the Part I problem as it is caused by a call to
>> `Native_Utils.eq` which is even less efficient than `Native_Utils.cmp`
>> resulting in about a 1500% slowdown compared to JavaScript for the following
>> code:
>>
>> import Bitwise as Bw
>>
>> testProg : Int -> Int
>> testProg n = -- do some work
>>   let loop i =
>> if Bw.and i 0x3FFF == 0x3FFF then i else
>> loop (i + 1) in loop n
>>
>> which compiles to:
>>
>> var _user$project$Temp1482804013226255$testProg = function (n) {
>> var loop = function (i) {
>> loop:
>> while (true) {
>> if (_elm_lang$core$Native_Utils.eq(i & 1073741823, 1073741823)) {
>> return i;
>> } else {
>> var _v0 = i + 1;
>> i = _v0;
>> continue loop;
>> }
>> }
>> };
>> return loop(n);
>> };
>>
>> with  `Native_Utils.eq` defined as:
>>
>> function eq(x, y)
>> {
>> var stack = [];
>> var isEqual = eqHelp(x, y, 0, stack);
>> var pair;
>> while (isEqual && (pair = stack.pop()))
>> {
>> isEqual = eqHelp(pair.x, pair.y, 0, stack);
>> }
>> return isEqual;
>> }
>>
>>
>> function eqHelp(x, y, depth, stack)
>> {
>> if (depth > 100)
>> {
>> stack.push({ x: x, y: y });
>> return true;
>> }
>>
>> if (x === y)
>> {
>> return true;
>> }
>> ...
>>
>> For this use case, there are a succession of conditions which won't cost
>> that much as explained in the opening post, but it is twice as slow as the
>> example in Part I 

Re: [elm-discuss] Re: Upgrading to 0.18 and elm-webpack-starter

[Noah Hall]

FWIW there's a patch I've been working on to make change detection
more consistent. I'll release it as 4.1.2 soon

On Fri, Dec 23, 2016 at 6:34 AM, Nathan Eldridge  wrote:
> I'm not certain of your configuration, but in our current project we pretty
> much use the standard:
>
> // This loader can be in commonConfig or the production/development section
> seperately.
>
> module: {
>  loaders: [
> {
> test: /\.elm$/,
> exclude: [/elm-stuff/, /node_modules/],
> loader: 'elm-hot!elm-webpack'
>
> }
> // our other loaders here
> ]};
>
>
> I assume that's your loader. In your package.json, you should have something
> like
>
> "devDependencies":{
> "elm": "^0.18.0",
> "elm-hot-loader": "^0.5.4",
> "elm-webpack-loader": "^4.1.1",
> "webpack": "^1.14.0",
> "webpack-dev-server": "^1.16.2",
> "webpack-merge": "^2.0.0"
> //just an example of the basic required packages
> }
>
> The above is what I can look at on a personal project where I have upgraded
> those modules manually without issue. The rest of the packages are the same
> as the starter with the exception of a few tweaks to change from bootstrap
> to semantic-ui, and I guess less-loader.
>
> If you're just using the standard elm-webpack-starter, then you should only
> need to set it as a query on the loader. I personally just installed the
> 0.18 package globally from the executable from elm-lang.org. If you don't
> want to do that, then just edit your loader so that it looks like this:
>
> //for development build
>
> {
> test: /\.elm$/,
> exclude: [/elm-stuff/, /node_modules/],
> loader: 'elm-hot!elm-webpack?pathToMake=node_modules/.bin/elm-make'
>
> }
>
> //for production build
>
> {
> test: /\.elm$/,
> exclude: [/elm-stuff/, /node_modules/],
> loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make'
>
> }
>
> Just double check and see that your packages were installed/upgraded through
> npm. I can't tell you how often I frustrate myself when I decide to upgrade
> a package for a new feature/bug fix and I continue to expect it to work
> without having actually done anything besides save the package change in
> package.json.
>
> The only other thing that I can think of that could be an issue is if you
> have globally installed 0.17 and that package is not upgraded to 0.18.
>
> Because I don't remember npm commands, the quick reference would just be
>
> npm upgrade -g elm
>
> That assumes you are using npm 3+ rather than installing the executable from
> the elm-lang website.
>
>
> As for what Martin and Simon have said, I've noticed that elm-hot-loader
> only seems to catch your top level changes. Basically, it requires that your
> file structure be flat to pick up changes consistently. Was that your
> experience? I would love for elm-hot-loader to catch a few nested folders we
> have, but playing around with the configuration didn't seem to help.
>
>
>
> On Thursday, December 22, 2016 at 12:41:44 PM UTC-6, Rex van der Spuy wrote:
>>
>>
>>>  It's possible that your elm-webpack-loader is pointing to the wrong
>>> executable.
>>
>>
>> Thanks Nathan! Everything else seem fine so it seems that this is likely
>> the problem.
>> Do you know where this needs to be set?
>> I noticed this from the README in elm-webpack-loader but I wasn't sure
>> where or how it should be set (in webpack.config.js?)
>>
>> ```
>> All options are sent down as an `options` object to node-elm-compiler. For
>> example, you can explicitly pick the local `elm-make` binary by setting the
>> option `pathToMake`:
>>
>> ```js
>>   ...
>>   loader: 'elm-webpack?pathToMake=node_modules/.bin/elm-make',
>>   ...
>> ```
>>
>
> --
> 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] Elm static source analysis

[Noah Hall]

I'm working on a linter, but right now, elm-format is your best bet
for maintaining code format. We use this with the `--validate` flag to
ensure that all checked in code matches elm-format.

On Fri, Dec 16, 2016 at 5:58 PM, Gian Giacomo Ermacora
 wrote:
> Hello everybody,
>
> my team and I are working on a complex project using Elm (today it was
> upgraded to version 0.18).
> Usually we run static source analysis using SonarQube and I am wondering if
> there is some way or an existing plugin for that tool to support the Elm
> source code
>
> Any suggestions? I can also accept to use another tool for the static
> analysis, it is not a problem, the required scenario is that Jenkins must be
> able to call this external tool that must do every night its task
>
> Thank you everybody in advance for suggestions and for this space.
>
> My best regards,
>
> Gian.
>
> --
> 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: Should and so on be part of Html?

[Noah Hall]

Yes, you can use `Html.node` for those. You might be better to
wrapping it with that stuff yourself outside of Elm though.

On Wed, Dec 14, 2016 at 5:18 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> On Wednesday, December 14, 2016 at 3:50:29 PM UTC, Rupert Smith wrote:
>>
>> The html elements  do not have
>> counterparts in the Html module, but they are part of Html. It does not
>> usually make sense to need them in Elm, since you tend to run Elm within the
>> Html  as fullscreeen or attach it to a DOM node deeper within the
>> body.
>>
>> For complete server side rendering, it does make sense to have build these
>> Html elements within Elm.
>>
>> Should they be added to the Html module?
>>
>> Or should I just write my own set of functions, I think using Html.node it
>> will be possible to make this work?
>
>
> Html.node "meta"
> [ attribute "charset" "utf-8" ]
> []
>
> Outputs  with no attributes. Could be a bug in the
> elm-server-side-renderer code though.
>
> --
> 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: Instaslling Elm 0.17 and Elm 0.18 at the same time.

[Noah Hall]

To expand on what simon said:
If you're using multiple Elm versions in production, use the version
installed via a local npm and make all your tooling refer to
node_modules/.bin/elm-make and friends. That way you can have a global
install of elm at a version, but still use 0.16 for a particular
project

On Wed, Nov 30, 2016 at 8:56 PM, Mickey Vashchinsky
 wrote:
> Maybe this would be helpfull:
>
> https://www.npmjs.com/package/elm-version-manager
>
>
> On Tuesday, November 29, 2016 at 3:54:06 PM UTC+2, Rupert Smith wrote:
>>
>> I've been trying to follow these instructions:
>>
>> http://www.lambdacat.com/how-to-setup-local-development-for-elm/
>>
>> but getting some errors when trying to build from source.
>>
>> Is there an easier way? I don't want to blat my exising 0.17 with 0.18
>> right away, would rather keep it around until I have finished upgrading.
>>
>> Perhaps just create a vm or docker container and install elm 0.18 inside
>> that?
>
> --
> 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] What Elm needs to move forward

[Noah Hall]

I had submitted a couple of talks on advance Elm usage for elm-conf,
but sadly that never happened. I have however talked about this kinda
thing in local meetups and in the remote meetup. Sadly the most
interesting and relevant one (on how to not get blocked with Elm in
production) failed to record correctly. These are the kind of talks
that I've been heavily recommending elm-conf should focus on. There
are so many intro to elm talks.

Maybe elm-conf EU will have more focus on that.



On Thu, Nov 24, 2016 at 7:58 AM, Zachary Kessin  wrote:
> I think we are only differing on the details. We could use talks / blogposts
> on all of those things. If you want to write a guest blogpost on any of the
> above I would be happy to put it on my blog.
>
>
> Zach
>
> On Thu, Nov 24, 2016 at 9:31 AM, Peter Damoc  wrote:
>>
>> I beg to differ.
>> There are a lot of intro talks to Elm syntax and some of them touch a
>> little bit on some libraries but we are doing very poorly in addressing
>> important concerns like styling, persistence or deployment.
>> Of course, one might argue that this falls outside of Elm concerns but
>> should it be outside of Elm's concerns?
>> Are we trying to build reliable webapps or are we trying to reliably
>> generate html?
>>
>> The domain covered by CSS is virtually unexplored in Elm. It is taken as a
>> given that people will solve this on their own using previous knowledge or
>> by learning CSS somewhere else.
>> There are a few libraries that attempt to address this but most of them
>> are bindings to CSS with a little bit of type safety thrown in and do a very
>> poor job at documenting use-cases.
>>
>> The topic of reusable components is still in limbo.
>> If someone asks me how would they do a dropdown in Elm I still don't know
>> what to say (other than implement it from scratch).
>> Have the sortable-table solution and the auto-complete examples been
>> imitated? Do we have a large pool of reusable UI elements?
>>
>> The topic of build tools and end-to-end development, again... it rests on
>> people reusing outside knowledge.
>> There is very little documentation on producing a deliverable.
>>
>> Were do we want to be in 3 years time?
>> How would we want Elm to have changed the webapp domain?
>> What would be the less than desirable future that we might risk ending up
>> in?
>>
>>
>>
>> On Thu, Nov 24, 2016 at 8:30 AM, Zachary Kessin  wrote:
>>>
>>> Glad you liked the blog post.
>>>
>>> I thinkw e are doing well on the intro talks and case studies part of the
>>> Elm story. But there are other stories to tell around elm that might appeal
>>> to the developer who has been doing elm already for 6 months.
>>>
>>>
>>> Zach
>>>
>>> On Thu, Nov 24, 2016 at 8:04 AM, Peter Damoc  wrote:

 I've seen a short blogpost by Zach
 http://get-finch.com/2016/11/23/what_elm_needs_to_to_move_forward.html
 and it got me curious.

 What do the rest of you think Elm needs to move forward faster?
 (it is already moving forward and will continue to do so but... maybe
 some things can accelerate the process.)

 I've seen also this comment:

 https://www.reddit.com/r/elm/comments/5dox3b/reddit_uses_elm_for_internal_apps/da6cyu9/?st=ivvxoob1=4476d8ec
 and I think the point made there is relevant.

 I think Elm needs a common story around some kind of web-framework.

 With one framework that multiple entities use and improve it is easier
 to build shared ground and shared knowledge and this gives the impression 
 of
 stability and predictability. In theory, it would be easier to find 
 multiple
 developers with the same subset of know-how.

 Attempting to implement such a framework would also make salient the
 issues that still remain (CSS) and will stress the tools (elm-format,
 elm-test) enough to push them forward faster.

 Constrains liberate.

 What do you think?


 --
 There is NO FATE, we are the creators.
 blog: http://damoc.ro/

 --
 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.
>>>
>>>
>>>
>>>
>>> --
>>> Zach Kessin
>>> SquareTarget
>>> Twitter: @zkessin
>>> Skype: zachkessin
>>>
>>> --
>>> 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.
>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>> --
>> You received this message because you are 

Re: [elm-discuss] Re: Structure for multiple small "apps" when using Elm with webpack (elm-webpack-loader)

[Noah Hall]

At NoRedInk, we use a single elm code base with multiple entry points
for each different page with a unique elm app. This is ideal in terms
of build time and reliabitly, as everything can be built and once and
share a single lot of packages.

We also use the webpack loader for this style of app (though to be
fair, we made it).

On Thu, Nov 24, 2016 at 3:07 AM, Robin Heggelund Hansen
 wrote:
> I would just keep everything in one Elm app, then use a router to display
> the correct page.
>
> When it comes to google closure, Elm only works with SimpleOptimizations.
> There are two-three lines in the runtime which causes problems with
> AdvancedOptimizations.
> In any case, the difference between Google Closure and Uglify is very small
> when it comes to Elm. In my app, Uglify brings size down to ~80Kb, while
> Closure with AdvancedOpts brings it down to ~74Kb. When gzipped, the
> differences are barely noticeable.
>
>
> onsdag 23. november 2016 19.49.19 UTC+1 skrev Rafał Cieślak følgende:
>>
>> For the posterity, I implemented said "architecture" in one of my side
>> projects. https://github.com/ravicious/rails-elm-forms/commit/b5ac6964f
>>
>> The only difference from what I said above is that the Elm apps don't have
>> their own entry points in the webpack config. Instead, the entry points are
>> the JS file which require the Elm file and then embed the app.
>>
>> I wish I could use Closure Compiler, but I couldn't get the trio (Closure
>> Compiler + webpack + Elm) to work together, for some reason the two webpack
>> Closure Compiler plugins I tried to use mess up the Elm code.
>>
>> On Saturday, November 19, 2016 at 9:58:27 PM UTC+1, Rafał Cieślak wrote:
>>>
>>> The project I'm working on is not a SPA, it's a rather big Rails app that
>>> sometimes needs JS to make some part of the page dynamic – usually it's
>>> about dynamic forms.
>>>
>>> When I was thinking about ways in which I can integrate Elm into the
>>> project, I thought about having a separate Elm project for each feature: so
>>> there would be an order_form folder with its own elm-package.json, its own
>>> versions of dependencies and Elm. Beside it there would be another folder,
>>> let's say product_form, also with its own elm-package.json and so on.
>>>
>>> I quickly realized it could be a nightmare from the maintainability point
>>> of view, since each folder would require its own version of Elm, thus each
>>> folder would need to have a separate package.json which would install Elm
>>> from npm.
>>>
>>> I looked at elm-webpack-loader and found out that it requires me to have
>>> a single elm-package.json for the whole project. Separate forms would have
>>> an access to the same dependencies and the same version of Elm. At first I
>>> was put off by this solution, as it was completely the opposite of what I
>>> had in mind (separate elm-package.json for each form). Finally, I had a
>>> sudden moment of clarity and I realized that what elm-webpack-loader does is
>>> exactly what we already do with our smaller React apps: each lives in its
>>> own directory, each has a separate entry point in webpack config, but all
>>> share the same package.json and all have access to the same deps.
>>>
>>> Do I get it right? If so, how should I structure the apps on the Elm
>>> side?
>>>
>>> I was thinking about creating a directory app/assets/javascripts/elm.
>>> Each Elm "app" would have its main module under
>>> app/assets/javascripts/elm/src. Each Elm "app" would also have its own entry
>>> point in webpack. app/assets/javascripts/elm/src would be added as a source
>>> directory in source-directories in elm-package.json. Then I could
>>> "namespace" each "app", so that there's OrderForm (the main module) and
>>> everything that is specific to it is nested under OrderForm (OrderForm.Foo,
>>> OrderForm.Bar).
>>>
>>> This way webpack could easily handle building all the Elm apps along with
>>> React apps.
>>>
>>> Are there any pitfalls in my thinking? Do you see ways in which this
>>> approach could fail? If you use elm-webpack-loader and had a similar
>>> problem, I'd love to hear how you handled 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.

Re: [elm-discuss] What ways are there of running Elm server side?

[Noah Hall]

The canoncial server-side Elm example is the take-home,
https://github.com/noredink/take-home, written by me. AFAIK it is
still the only full stack-Elm application. It also lists good reasons
as to not take that approach and why it should be avoided at all
costs.

If you want to render code on the server side, you can use
https://github.com/eeue56/elm-server-side-renderer/ which is also
written by me. While it's labelled a work in progress, we use it for
our production tests at NoRedInk and have been doing so for a while
now.

You'll need to set up a port to pull the generated string out, but
it's trivial bit of work to do with the elm-server-side-renderer
project. Just take a look at how something like elm-test pulls values
out through a port.

On Wed, Nov 23, 2016 at 9:29 PM, 'Rupert Smith' via Elm Discuss
 wrote:
> https://github.com/ElmCast/elm-node
>
> Any others?
>
> Also, are they very tied to nodejs? I'm wondering if the javascript
> interpreter that comes with Java could run it?
>
> I'm looking for ways I could render Html views using Elm, but in such a way
> that some of the view code can be shared between browser and server side.
> Generally content to render views from will be in Java, so it would make
> things easier if I could run Elm in a JVM. Hope this is not too crazy.
>
> --
> 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] Unpublishing a package

[Noah Hall]

The elm-community has been depreciating things every time a new Elm
release comes along, by simply just not publishing for that version.

On Tue, Nov 22, 2016 at 12:33 AM, Richard Feldman
 wrote:
> There is no unpublish feature, and it's important that there never be one.
> :)
>
> If you want to deprecate a package, I recommend publishing a new major
> release that removes everything and replaces the README with an explanation
> of how the package is gone now (and perhaps what to use instead).
>
> --
> 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] Rename Just to Something, as the counterpart to Nothing?

[Noah Hall]

Has anyone actually encountered anyone being confused by the names? I
haven't. I think this a solution to a problem that doesn't exist.

On Mon, Nov 21, 2016 at 6:15 PM, Will White  wrote:
> I think that’s because you already know what Just means. I don’t think it’s
> arbitrary though from an accessibility point of view. Some or None is easier
> for newcomers to understand than Just or Nothing, especially as Some isn’t
> misleading the way Just is, as Andrew described well.
>
> On 21 Nov 2016, at 17:05, Joey Eremondi  wrote:
>
> Honestly, these choices seem pretty arbitrary. Everyone has a preference. ML
> uses Some/None, Haskell uses Just/Nothing. Some people find Something
> intuitive, some don't.
>
> Given that the choices is (mostly) arbitrary, it seems best to stick with
> the status quo.
>
> On Mon, Nov 21, 2016 at 7:47 AM, 'Andrew Radford' via Elm Discuss
>  wrote:
>>
>> Probably inherited from Haskell, like a lot of other stuff. Doubt if there
>> was any other thought put into it if I'm honest.
>>
>> On Monday, 21 November 2016 14:46:40 UTC, Will White wrote:
>>>
>>> Sorry, meant to say “I guess he’s already considered and rejected them”.
>>>
>>> On 21 Nov 2016, at 14:21, Will White  wrote:
>>>
>>> I prefer Some or None, for understanding. Though, unless Evan didn’t know
>>> about them, I guess we’d already have them.
>>>
>>> On 20 Nov 2016, at 23:41, Robin Heggelund Hansen 
>>> wrote:
>>>
>>> How about 'Some' and 'None'?
>>> Those are not longer to type than what we have today, and they should
>>> solve your initial confusion.
>>>
>>> søndag 20. november 2016 18.16.26 UTC+1 skrev Will White følgende:

 I'm talking about Maybe.Just, of course. Just has always seemed strange
 to me, as if it's hinting that it's something other than just the
 counterpart to Nothing. I don't know the reasons behind its naming, but I
 think I would prefer Something, as in "something or nothing". What do you
 think?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Elm Discuss" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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.
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/EHnuE_gGFuo/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

-- 
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] How are you handling images references in Elm with Webpack?

[Noah Hall]

We solved this recently! You can checkout the loader here ->
https://github.com/NoRedInk/elm-assets-loader

The code lives in index.js. It's currently not fully released yet, but
some docs live here ->
https://github.com/NoRedInk/elm-assets-loader/blob/master/index.js#L3

On Mon, Nov 14, 2016 at 2:23 AM, Birowsky  wrote:
> I'm trying to make Elm work with images through Webpack.
>
> Here's my first struggle: http://stackoverflow.com/q/40580968/592641
>
> How do you configure Webpack to rename the images references in the compiled
> elm js with the appropriate hashes?
>
> Just.. how do you work with images and webpack? :}
>
> --
> 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] Help with beginner program

[Noah Hall]

In order to install elm at version 0.16, just do:

npm install -g elm@0.16

In order to re-install elm at version 0.17, just do:

npm install -g elm@0.17.1

On Wed, Nov 2, 2016 at 8:06 PM, Federico Venturini
 wrote:
> Hi everyone!
> I'm writing a brief report on Elm and FRP (functional reactive programming)
> for one of my classes. Since elm 0.16 and 0.17 are completely different, I'm
> basing my report on the comparison between the two and how this affects the
> approach to FRP.
> I've got a good hold of the theoretical part, but I've been asked to write
> an small example of elm in action. I was wanting to do a really simple
> example in both of the version and compare the different approaches.
> First of all, how can I test and compile my code for elm 0.16? Do I need to
> uninstall elm 0.17, download the older version, compile it and test it? Or
> is there a more straight forward way?
> Second, I'm planning on doing a program that basically let you see a funny
> pic of Donald Trump if your mouse is in the right part of the screen and a
> funny pic of Hillary if your mouse is in the left part of the screen. As
> stated, I want to do this for both the versions. Can someone help me out? I
> don't need the full blown solution, just some hints and maybe someone to ask
> questions to. There aren't many tutorials left on the web for the older
> version of Elm..
>
> Thanks in advance,
> Federico
>
> --
> 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] This week, we hit 5000+ users on Slack

[Noah Hall]

>From our Slack weekly update:

> In total there are 5190 people on your team (up 210 from last week) 
(that's not including 11 disabled accounts).

I think that's pretty cool. Lots of people to help and be helped! 

Here's a link for anyone unfamiliar -> http://elmlang.herokuapp.com/

-- 
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 mortem for my first attempt at using Elm in a real app.

[Noah Hall]

On Mon, Sep 19, 2016 at 3:08 PM, Peter Damoc  wrote:

> Middle Phase
>
> Once the build environment was set up, things started to move a little
> faster. I then ended up needing CSS and after playing a little bit with
> elm-css and hitting several missing properties I decided to implement my own
> library, taking inspiration from all 3 libraries that were dealing with
> style (rtfeldman/elm-css, elm-style and massung/elm-css). In hindsight this
> might have been a rather bad idea for productivity reasons but I have
> learned a lot.

elm-css is a complicated project. It's mostly complicated because of
_how big css is_. Reimplementing your own is not a reasonable idea for
getting things done :) A much better idea would've been to do one of:
1) fork, add the missing keywords, commit upstream
2) fork and add the missing keywords to your local copy
3) just use 
http://package.elm-lang.org/packages/rtfeldman/elm-css/5.0.0/Css#property
to achieve this without wasting any time messing around.

> Conclusions
>
> - Elm is an amazing language. I've had countless moments of sheer pleasure
> programing in Elm for this app.
> - Elm lacks the full story. My main hope was that I could implement the app
> even if I had very little CSS or JS knowledge. I could not do this. Elm does
> not have yet something that would allow someone to stop touching CSS.

Elm hasn't considered this a goal since elm-html has existed. The
graphics library allowed you to forego CSS. Nobody uses the graphics
library in production (though many in academia (did)do, that's what I
did)

> - I would not recommend webdev beginners to take the approach I took. It is
> better for now to stay the tried and proven path and just use Elm to
> implement smaller components in another web framework.

There isn't any reasoning here other than you tried to re-invent the
wheel a few too many times. I would also recommend to those trying to
solve a production problem to do the same ;). I would agree though,
that if you are intended to rely on the existing JS/CSS libraries out
there, you are probably better off investing time in making Elm part
of your site, not making Elm your whole site. You will spend too much
time like this otherwise

> - The tooling around producing a deliverable elm webapp are simply not ready
> yet.

You haven't provided an example of any tooling that "isn't ready yet".
You said you used gulp and there were no issues there. What were these
problems?

-- 
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] Proposal for a 1st-class, officially-supported CSS package

[Noah Hall]

elm-css doesn't need extra first class Elm support. It has first class
Elm support - everything is a function. As Nick said, focus on how you
_use_ elm-css. It's plenty first-class enough wihtout burdening the
compiler with excessive language features.

On Tue, Sep 13, 2016 at 7:17 PM, Nick H  wrote:
> Hi Kevin,
>
> As far as I can tell, the type alias you are quoting (Value, All,
> NumberedWeight) are not part of the elm-css API. I can't find them in the
> package documentation. Are you suggesting a change to the implementation of
> elm-css, or a change to the interface?
>
> Sorry if I'm missing the point. I don't have a lot of experience with Elm
> CSS.
>
>
> On Tue, Sep 13, 2016 at 8:23 AM, suttlecommakevin
>  wrote:
>>
>> Preface
>>
>> Saying Elm is a language for front-end apps, but leaving out 1/3 of the
>> stack isn't confidence-inspiring.
>> Between our collective experience, I think we can make something awesome
>> and fun to use, while leveraging
>> the features that make Elm a great language.
>>
>>
>> Problem to be solved
>>
>> One thing that React got right was that the UI is always a reflection of
>> state. The UI is defined by HTML/JS, but appearance is defined by CSS.
>>
>> I had proposed that the style attribute of the Virtual DOM package match
>> the same signature of the classList function, by adding a boolean as a
>> param,
>> but that wasn't accepted. To be fair, I didn't provide background or
>> explanation. I should have taken more time to explain. That's on me.
>>
>> What this was meant to do was described just below the style attribute
>> listing in the Elm docs, inside the classList example.
>> As a component author, by applying styles via logic ahead of time, you
>> save component consumers the task of having to know every possible class
>> name.
>>
>> A common trick for this in React is to use ES2015 template strings to
>> interpolate other enumerated properties, thus limiting the scope of what UI
>> component consumers have to know, and what the compiler has to validate
>> against.
>>
>> 
>>
>>
>> where design was enumerated in a PropType list like so:
>>
>> 
>>
>>
>> Prior Art
>>
>> Richard Feldman's work in this area is the most promising I've seen in CSS
>> since Sass. I mean that.
>>
>> One thing I'm curious about though, is in his Elm-CSS library, the APIs
>> don't seem to be taking advantage of Elm's native primitive types.
>> I'm almost a complete n00b, so please take that into context before I give
>> the following example.
>>
>> type alias Value compatible =
>>
>> { compatible | value : String }
>>
>> type alias All compatible =
>>
>> { compatible | value : String, all : Compatible }
>>
>> Like React, it appears that every property and value ends up being a
>> String, even when the possible CSS values are enumerated.
>>
>> Example:
>>
>> type alias NumberedWeight =
>> { value : String, fontWeight : Compatible }
>>
>> Shouldn't this be an Union -> Int  with the possible values of 100 | 200 |
>> 300 | 400 | 500 | 600 | 700 | 800 | 900 ?
>> Am I missing something here (wholly possible and very likely), or is there
>> a reason to not do this with the rest of the package?
>> In this case, it's true that font-weight can take other enumerated strings
>> as values, but I'm wondering why not leverage the native primitive types?
>>
>>
>> I have a slew of other ideas, but let's start here.
>> Thanks!
>>
>> --
>> 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.

-- 
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] Elm Jobs Board

[Noah Hall]

#jobs on the slack channel. http://elmlang.herokuapp.com/

On Mon, Aug 1, 2016 at 1:17 AM, Joey Eremondi  wrote:
> Advertising jobs, this is probably the best place, though you'll probably
> get good feedback on reddit.com/r/elm as well.
>
> You can look for jobs here, but Elm is *very* new. I'm sure there are a few
> people hiring Elm developers, but I doubt there are many specifically
> looking for Elm people.
>
> On Sun, Jul 31, 2016 at 4:34 AM, Andre Bolle  wrote:
>>
>> Is there a place where people can advertise and look for Elm jobs?
>>
>> Andre
>>
>> --
>> 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.

-- 
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] Is there a way to investigate a Html tree?

[Noah Hall]

It turns the internal representation to a string representation. It doesn't
actually render it at that point. It's just the internal representation.

On Thursday, July 28, 2016, Peter Damoc <pda...@gmail.com> wrote:

> I took quick look and I got here:
>
> https://github.com/eeue56/elm-server-side-renderer/blob/master/src/Helpers.elm#L31
>
> query leads to nodeTypeFromHtml which is actually living in a module named
> HtmlToString :)
>
> Looks like you are still turning it into a string.
> I'm imagining that with the help of that native, the string representation
> is smarter (ready for Json decoding)
>
> Am I missing something or misreading the code?
>
>
>
>
> On Thu, Jul 28, 2016 at 1:46 PM, Noah Hall <enali...@gmail.com
> <javascript:_e(%7B%7D,'cvml','enali...@gmail.com');>> wrote:
>
>> My implementation of server-side rendering allows you to do exactly
>> that, without turning it to a string.
>>
>> Checkout how this is implemented ->
>>
>> https://github.com/eeue56/elm-server-side-renderer/blob/master/src/Query.elm#L51
>>
>> On Thu, Jul 28, 2016 at 11:21 AM, Peter Damoc <pda...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','pda...@gmail.com');>> wrote:
>> > I need to gather all the class names used in a Html tree generated by
>> the
>> > app.
>> >
>> > Is there a way to do this short of converting the html to a string and
>> > manually parsing it?
>> >
>> >
>> >
>> >
>> >
>> > --
>> > There is NO FATE, we are the creators.
>> > blog: http://damoc.ro/
>> >
>> > --
>> > 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
>> <javascript:_e(%7B%7D,'cvml','elm-discuss%2bunsubscr...@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
>> <javascript:_e(%7B%7D,'cvml','elm-discuss%2bunsubscr...@googlegroups.com');>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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
> <javascript:_e(%7B%7D,'cvml','elm-discuss%2bunsubscr...@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] Is there a way to investigate a Html tree?

[Noah Hall]

My implementation of server-side rendering allows you to do exactly
that, without turning it to a string.

Checkout how this is implemented ->
https://github.com/eeue56/elm-server-side-renderer/blob/master/src/Query.elm#L51

On Thu, Jul 28, 2016 at 11:21 AM, Peter Damoc  wrote:
> I need to gather all the class names used in a Html tree generated by the
> app.
>
> Is there a way to do this short of converting the html to a string and
> manually parsing it?
>
>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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] How to do Context in 0.17 (passing in multiple Addesses to a view)

[Noah Hall]

This is what our accordion looks like in 0.17:

https://gist.github.com/eeue56/d0a2f901dc2fe36ab4562940b7fd28e4

it was a +7 -11 diff :)


Otherwise, you want `Html.App.map`. Make a component that has it's own
"update" function, with it's own messages. Map them and pass the
messages down from the top level in a wrapper to the `update` function
for that component. E.g


type MessageLevel = TopLevel Msg | SomeGenericViewLevel SomeGenericView.Msg


On Thu, Jul 28, 2016 at 12:38 AM, Sean Clark Hess  wrote:
> For the app I'm working on, I would like to create some views that have no
> update function or message. In 0.16, you could pass in extra addresses to a
> view. The example in the elm architecture lumped them together in a Context
> parameter.
>
> I found this useful in 0.16 when creating very general views that didn't
> manage their own state. This approach was analogous to when you pass in a
> callback as a prop in React, if that helps.
>
> How does one do this in 0.17?
>
> Specifically I'm thinking about the use case of a general view function that
> takes any HTML children, but has some events that need to fire (like an
> accordion container opening and closing).
>
> --
> 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] Writing tests on elm-lang/html data structures

[Noah Hall]

Yep, if you want to use karma

On Sun, Jul 17, 2016 at 6:40 PM, Conrad Dean <conrad.p.d...@gmail.com> wrote:
> By that do you mean write the test suite in JS and call elm with ports?
>
> On Sat, Jul 16, 2016 at 5:22 PM, Noah Hall <enali...@gmail.com> wrote:
>>
>> It has a native function to grab the internal node representation, so
>> you'll have to clone it and replace some of the refereneces to instead
>> talk about your package name.
>>
>> One caveat is that I don't remember if it works with Markdown right
>> now, since Markdown uses a custom renderer which has a different
>> internal representation.
>>
>> You might be better off writing tests using karma or something for
>> now, actually. Or just implement the representation of the call to the
>> markdown renderer.
>>
>> On Sat, Jul 16, 2016 at 11:04 PM, Conrad Dean <conrad.p.d...@gmail.com>
>> wrote:
>> > oh this looks great!  how do i install/vendor it?
>> >
>> > On Sat, Jul 16, 2016 at 4:49 PM, Noah Hall <enali...@gmail.com> wrote:
>> >>
>> >> We've been using this ->
>> >> https://github.com/eeue56/elm-server-side-renderer for testing that in
>> >> 0.17.
>> >>
>> >>
>> >> On Saturday, July 16, 2016, Conrad Dean <conrad.p.d...@gmail.com>
>> >> wrote:
>> >>>
>> >>> I want to write tests for https://github.com/evancz/elm-markdown , but
>> >>> I'm having problems comparing Html objects.
>> >>>
>> >>> There's something about the internals of a VirtualDom/Html object that
>> >>> are preventing me from testing if two html nodes are equal and I was
>> >>> wondering if someone could get me up to speed with how to strip that
>> >>> stuff
>> >>> out so that I'm just comparing either the raw HTML strings, or more
>> >>> basic
>> >>> Html type objects.
>> >>>
>> >>> Here's my test and error message from running my ElmTest suite:
>> >>>
>> >>> module MarkdownSpec exposing (all)
>> >>>
>> >>> import ElmTest exposing (..)
>> >>>
>> >>> import Html exposing (Html, Attribute)
>> >>> import Markdown exposing (toHtml)
>> >>>
>> >>> all : Test
>> >>> all =
>> >>> suite "MAKR DOEN"
>> >>> , test "simple html"
>> >>> <| assertHtmlEqual (Html.text "sup") (Html.text "sup")
>> >>> , test "basic MD"
>> >>> <| assertHtmlEqual (toHtml [] "sup") (Html.text "sup")
>> >>> ]
>> >>>
>> >>> assertHtmlEqual: Html msg -> Html msg -> Assertion
>> >>> assertHtmlEqual a b = assertEqual a b
>> >>>
>> >>>
>> >>> Error:
>> >>>
>> >>> $ elm make test/TestRunner.elm --output _build/test.js && node
>> >>> _build/test.js
>> >>> Success! Compiled 2 modules.
>> >>> Successfully generated _build/test.js
>> >>> /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567
>> >>> throw new Error(
>> >>> ^
>> >>>
>> >>> Error: Ran into a `Debug.crash` in module `ElmTest.Runner.Console`
>> >>>
>> >>> This was caused by the `case` expression between lines 28 and 33.
>> >>> One of the branches ended with a crash and the following value got
>> >>> through:
>> >>>
>> >>> False
>> >>>
>> >>> The message provided by the code author is:
>> >>>
>> >>>   3 suites run, containing 5 tests
>> >>>   1 suites and 4 tests passed
>> >>>   2 suites and 1 tests failed
>> >>>
>> >>> Test Suite: very tests: FAILED
>> >>>   Test Suite: A Test Suite: all tests passed
>> >>>   Test Suite: MAKR DOEN: FAILED
>> >>> Addition: passed.
>> >>> simple html: passed.
>> >>> basic MD: FAILED. Expected: { type = "custom", facts = {}, model =
>> >>> {
>> >>> options = { githubFlavored = Just { tables = False, breaks = False },
>> >>> defaultHighlighting = Nothing, sanitize = False, smartypants = F

Re: [elm-discuss] Writing tests on elm-lang/html data structures

[Noah Hall]

We've been using this -> https://github.com/eeue56/elm-server-side-renderer
for testing that in 0.17.

On Saturday, July 16, 2016, Conrad Dean  wrote:

> I want to write tests for https://github.com/evancz/elm-markdown , but
> I'm having problems comparing Html objects.
>
> There's something about the internals of a VirtualDom/Html object that are
> preventing me from testing if two html nodes are equal and I was wondering
> if someone could get me up to speed with how to strip that stuff out so
> that I'm just comparing either the raw HTML strings, or more basic Html
> type objects.
>
> *Here's my test and error message from running my ElmTest suite:*
>
> module MarkdownSpec exposing (all)
>
> import ElmTest exposing (..)
>
> import Html exposing (Html, Attribute)
> import Markdown exposing (toHtml)
>
> all : Test
> all =
> suite "MAKR DOEN"
> , test "simple html"
> <| assertHtmlEqual (Html.text "sup") (Html.text "sup")
> , test "basic MD"
> <| assertHtmlEqual (toHtml [] "sup") (Html.text "sup")
> ]
>
> assertHtmlEqual: Html msg -> Html msg -> Assertion
> assertHtmlEqual a b = assertEqual a b
>
>
> *Error:*
>
> $ elm make test/TestRunner.elm --output _build/test.js && node
> _build/test.js
> Success! Compiled 2 modules.
> Successfully generated _build/test.js
> /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567
> throw new Error(
> ^
>
> Error: Ran into a `Debug.crash` in module `ElmTest.Runner.Console`
>
> This was caused by the `case` expression between lines 28 and 33.
> One of the branches ended with a crash and the following value got through:
>
> False
>
> The message provided by the code author is:
>
>   3 suites run, containing 5 tests
>   1 suites and 4 tests passed
>   2 suites and 1 tests failed
>
> Test Suite: very tests: FAILED
>   Test Suite: A Test Suite: all tests passed
>   Test Suite: MAKR DOEN: FAILED
> Addition: passed.
> simple html: passed.
> basic MD: FAILED. Expected: { type = "custom", facts = {}, model = {
> options = { githubFlavored = Just { tables = False, breaks = False },
> defaultHighlighting = Nothing, sanitize = False, smartypants = False },
> markdown = "sup" }, impl = { render = , diff =
>  } }; got: { type = "text", text = "sup" }
> at /Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:567:9
> at _elm_community$elm_test$ElmTest_Runner_Console$runDisplay
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7778:9)
> at _elm_community$elm_test$ElmTest_Runner_Console$runSuite
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:7793:11)
> at Object.
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8061:8)
> at Object.
> (/Users/conrad/dev/foss/elm/elm-markdown/_build/test.js:8096:4)
> at Module._compile (module.js:435:26)
> at Object.Module._extensions..js (module.js:442:10)
> at Module.load (module.js:356:32)
> at Function.Module._load (module.js:311:12)
> at Function.Module.runMain (module.js:467:10)
>
>
> --
> 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] https://github.com/evancz down?

[Noah Hall]

Actually, the flakiness of github is one of our biggest problems of elm in
production. So we have internal caching mirrors

On Saturday, June 25, 2016, Tobias Hermann  wrote:

> No Problem. I think github usually can be considered very reliable though.
>
>
> On Saturday, June 25, 2016 at 8:41:23 PM UTC+2, Evan wrote:
>>
>> Seems to be back! Actually sitting on the plane now, so I'm glad I found
>> out before it took off.
>>
>> Sorry for the trouble. I have some plans for package.elm-lang.org
>> that'll make download mirrors possible, so we'll be less open to problems
>> like this.
>>
>> On Saturday, June 25, 2016, Tobias Hermann  wrote:
>>
>>> OK, thanks for the information. Have a nice flight. :)
>>>
>>>
>>> On Saturday, June 25, 2016 at 7:58:58 PM UTC+2, Evan wrote:

 It is a GitHub problem. I have opened a support ticket and reached out
 to them on Twitter
 .

 Hopefully it will be resolved soon. Though since it is Saturday, the
 support staff is probably not in the office... Not really sure what actions
 to take. I will be getting on a flight soon as well, so I can try more
 things once I land.

 On Sat, Jun 25, 2016 at 1:30 PM, Tobias Hermann 
 wrote:

> Just wanted to compile something using evancz/elm-markdown and the
> download failed . Is this a github
> problem or have things moved?
>
 --
> 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: Feature Request: Code Generation/ Macro System

[Noah Hall]

FWIW I've already turned json-to-elm into kind-of-macros for my own
personal usage along with a couple of other things.

I don't think that elmx is a compelling use case though. I think it's
best to leave that stuff to the react people. Things like decoders,
encoders, reducing boilerplate, generating ord and non-default
toString are good use cases of where Elm the language is missing
things _right now_, and therefore it makes sense to implement "macros"
or just editor plugins to generate that code for you. I don't think
they're compelling use cases for macros as part of Elm itself.



On Sun, Jun 12, 2016 at 5:44 PM, Isaac Shapira  wrote:
> Let me make the scenarios I mentioned more clear. I'm not advocating for a
> macro language, I'm advocating for a means of doing code generation that is
> consistent and maintainable. Producers could be solved with code generation,
> elmx could be replaced with code generation (I don't think it should be core
> language), boilerplate in update functions could be replaced with code
> generation (and I don't see another path here, since it involves pattern
> matching, see original example).
>
> On Sunday, June 12, 2016 at 10:16:59 AM UTC-6, Aaron VonderHaar wrote:
>>
>> If someone created a macro system, it would be interesting to see what
>> could be done with it.  But I think that would be extremely experimental.
>> I'm not convinced that having a macro system would lead to good solutions
>> for the things it could be used to solve.
>>
>> Specific to this conversation, there were three features mentioned in the
>> original github issue:
>>
>>  - make it easy to generate quickcheck producers
>>  - make `elmx` a core language feature
>>  - reduce boilerplate in `update` functions
>>  - other boilerplate scenearios
>>
>> I don't think a macro system is going to be a great solution for any of
>> those things.  (For quickcheck producers, I think having quickcheck
>> automatically do that via native code, or having a general API for data
>> structure reflection would probably be better.  For `elmx`, I personally
>> don't think it should be in the core language.  For `update` boilerplate, I
>> think a good solution will need to be part of the core framework and
>> shouldn't depend on macros even if they existed.  And for the supposedly
>> large number of other boilerplate scenarios, let's take a look at them and
>> see what they have in common that might be able to be solved more simply
>> than by having a macro language.)
>>
>> In general, if someone wants to build an experimental macros system just
>> to see what might come out of it, I think it would be great to see how that
>> goes.  But if we are talking about specific problems, we should focus on
>> trying to solve those problems rather than assuming that macros would solve
>> those problems.
>>
>> On Sun, Jun 12, 2016 at 3:58 AM, Maxime Dantec  wrote:
>>>
>>> I also think that it should not be in the core. And I'd argue, that this
>>> thread is about polling the community about the idea :)
>>>
>>> I have a tiny beginning of an Elm parser written using
>>> https://github.com/Bogdanp/elm-combine (awesome lib!!) that I could push
>>> once it compiles (^^).
>>>
>>> On Sunday, June 12, 2016 at 3:28:53 AM UTC+2, John Mayer wrote:

 Do you have a deadline? Ok. Then write a little external code generator,
 or fork the compiler and make your own technical decisions without any
 expectation that it will get merged into upstream.




 Now, are you simply trying to improve the language? You really want some
 kind of macro system merged into upstream? Great. Realistically, how this 
 is
 going to play out:

 Build out a taxonomy of macro systems in, like, 10 major languages,
 maintain some kind of matrix of pros and cons of different kinds of macro
 systems, maybe come up with some stuff that no language does. Do the
 research. Crucially, make sure that "no macro system" is also on that list;
 try to open-mindedly come up with reasons why not to have a macro system at
 all. Get people to help you with this research. Collect and organize
 everything into one place for consumption.

 Present that to the Elm maintainers (Evan, obviously) and share it on
 the mailing list.

 And then wait, because (based on his track record) Evan is going to mull
 it over for a while. IMO, he gets that privilege because he's our BDFL.
 Throughout this process Evan's going to come down with a set of principles
 that are consistent with the rest of the Greater Goals of Elm. The choice 
 of
 action will derive from those principles.




 Obviously people want this. People want lots of things. Making it easy
 for Evan maximizes the chances of something happening.

 On Sat, Jun 11, 2016 at 7:31 PM, Maxime Dantec  wrote:
>
>
>
> On 

Re: [elm-discuss] Re: Improving collaboration - part 2

[Noah Hall]

> I must say one of the main reasons I'm not using Elm today nor do I plan to 
> use it on the medium term is how slow paced, constraining and tightly 
> controlled it is.

I disagree that it's slow paced. I agree that it is constrained and
tightly controlled. Part of this is the focus on delivering Elm as an
entire, functional product that you can use and trust. There are some
negatives to this, like Evan doing all the work alone. I agree that
this is not ideal. But look at the end result we have - Elm is a
language that I can trust and work with day in, day out. With less
control over core, this wouldn't be possible to the same extent. That
isn't to say that it's not possible to still have a fully furnished
product without the control - but there is a process shift that needs
to happen in _the right way_ to make that happen.

> All this to say, Elm has been created 3 years ago, I sincerely hope it will 
> start to solve problems at a faster pace and be more open to the community.

I think the biggest problem is not about solving problems at a fast
pace. At NRI, we have solved all kinds of problems other people want,
and it wasn't a lot of work to implement them. Solving these problems
at a fast pace is almost my entire job.

But - developing things at a fast pace is not the way to create a
reliable or well designed language. We can trust our solutions
interally, since we know they work for _us_. That doesn't mean that
they will work for everyone, but as a result from our experiments, we
can give feedback upstream and help model the language by being part
of the community. Part of maintaining good language design is to not
just evaluate one use case and say "oh hey well it works for NRI, so
who cares about the rest". Most contributions have selfish reasons in
mind as to why they are contributed.

Being open with the community is a problem, and Evan has heard this
problem. As you can imagine, it sometimes come down to "write an email
in reply to A" or "write some code for this bug X that are blocking
people". It's frustrating for there to be no reply, I know. But there
is a good reason for it. This is a problem that's very dear to me, and
there is some stuff in the works to solve it, but it's not a simple
solution, and it needs a lot of thought on how to be proactive.

The biggest problem has been the changes in 0.17, for some people.
There were approaches possible in 0.16 that aren't as easy in 0.17.
0.17 is a better language, and html is a better framework. More
openness on this shift would've helped a bit here - a thread was made
on the changes to Html, but not so much as to what would happen to
signals. I believe I'm probably one of the people who has upgraded
most code from 0.16 to 0.17, and I know that it is possible to upgrade
everything. And almost everything I've upgraded has left me feeling
like "w this is much better!". So it's not a technical deficiency
here - the foundation is good. It's hard to communicate with everyone
about their particular use cases, though.


tl;dr - You aren't wrong to be frustrated, but there are good reasons
for the things that are frustrating you.

-- 
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] elm-stuff causing troubles after each updates

[Noah Hall]

Share your elm-package.json. we have had this problem at NRI, and the
tooling under https://github.com/NoRedInk/elm-ops-tooling#elm_deps_check
help to maintain consistency of the elm-stuff folder

-- 
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] Sublime Text 3 highlighting in 0.17

[Noah Hall]

The maintainer for the plugin is sadly unresponsive. There's been a
couple of offers to take it over, and it's been forked to
elm-community, but apparently the process to get it updated upstream
with sublime package control is complex. I'm not sure.

for now, you can add a `--where` as a comment after the `exposing`
bit, like this: `module Something exposing (..) -- where`. Hacky but
works until this is resolved

On Mon, May 23, 2016 at 7:23 PM, kgashok  wrote:
> Specifically after the changeover fro m
> module XXX where
> to
> module XXX exposing (..)
>
> the highlighting in Sublime Text 3 is all screwed up. How do I
> update/upgrade the Elm support settings in Sublime Text 3?
>
> --
> 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] Documentation for packages removed from Core is too hard to find

[Noah Hall]

https://github.com/elm-lang/elm-platform/blob/master/upgrade-docs/0.17.md#update-elm-packagejson

On Mon, May 23, 2016 at 7:06 PM, Alexander Biggs
 wrote:
> If I google "elm keyboard" today, here is the series of steps I follow
> before figuring out how to do keyboard input in my Elm game:
>
> 1. Click on first result, "Keyboard - core 2.1.0" packages page
> 2. Click on "go to latest version"
> 3. Get redirected to a 404 page
> 4. Scratch my head for a bit before realizing that the package was moved out
> of Core in Elm 4
> 5. Click on "elm-lang" at the top navigation to go to the frontpage for elm
> documentation
> 6. I lied, it actually brings me to the elm-lang github organization(?!?).
> Search for "keyboard" there
> 7. It brings me to a github repo for Keyboard, whose README has no info on
> how to install the package or what types are exposed, just a general
> overview of what the package is
> 8. Go back to the elm package website, click on the "Elm Packages" icon on
> the topleft to go to the documentation homepage
> 9. Search for "keyboard", click on first result.
>
> The page this shows me still has no documentation on how to install the
> package, for that I have to click back and go to "Using Packages" from the
> package homepage. However, finally I can find the documentation for what
> types are available in the Keyboard package by clicking on "Keyboard" on the
> right side of the page.
>
> This process can be improved a lot:
>
> 1. The "go to latest version" for packages removed from core should redirect
> to the new page for that package
> 2. Pages for packages that are not in Core should have a link to the
> installation instructions
> 3. The "elm-lang" link at the top of the packages navigation should go to
> the documentation frontpage, to avoid breaking the idea of a navigation
> tree.
>
> Any thoughts on other ways we can improve the process for getting started
> with elm packages?
>
> --
> 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.