[elm-discuss] Re: The way forward for Elm Arrays

[Evan]

Oh, and a few more notes. I recently did two pull requests on a framework 
comparison benchmark to improve the Elm implementation:

   - Start using lazy 
   <https://github.com/krausest/js-framework-benchmark/pull/192> - This 
   made the Elm version significantly faster than before.
   - Get rid of List => Array => List conversion 
   <https://github.com/krausest/js-framework-benchmark/pull/194> - This 
   actually had *no significant impact* on the results. With random noise, 
   it actually got slower in the run they chose. Touching the DOM is so 
   expensive that it tends to overshadow any other concern, and I had the same 
   experience converting TodoMVC to use a Dict rather than List.

In looking for these, I also found this PR 
<https://github.com/krausest/js-framework-benchmark/pull/195> that does 
another optimization which should help a bit. The fact that you can now 
remove without changing event handlers in all subsequent entries should 
provide a decent speed boost, but we'll see when the results are out!

This is all to say: it is important to contextualize these ideas in the 
performance characteristics of real programs, and those characteristics can 
be quite surprising given how the DOM works.


On Monday, June 12, 2017 at 6:08:50 AM UTC+1, Evan wrote:
>
> Very interesting, thank you for sharing!
>
> I wanted to add a couple notes and ideas that I've had separately.
>
>
> Syntax
>
> I was formerly somewhat keen on having special syntax for other 
> collections. For example, OCaml allows you to say [| 1, 2, 3 |] to create 
> an array. Hassan made a really nice proposal 
> <https://github.com/elm-lang/elm-plans/issues/12> to have it be #[ 1, 2, 
> 3 ] back in 2015. Since then I realized you can do the following:
>
> a = Array.fromList
> s = Set.fromList
> d = Dict.fromList
>
> array =
>   (a[ 1, 2, 3 ])
>
> set =
>   (s[ 1, 2, 3 ])
>
> dict =
>   (d[ 1 => "Tom", 2 => "Sue", 3 => "Jane" ])
>
> (=>) = (,)
>
> This is 1 or 2 characters off all the proposals out there, and it is 
> visually much nicer in my opinion.
>
> With that knowledge, the case for special syntax seems significantly 
> weaker. I can also imagine detecting when a list is converted to something 
> else and doing something more clever in the compiler. That path seems 
> better overall to me.
>
>
> List performance of map, foldl, and foldr
>
> I shared this blog post 
> <https://blogs.janestreet.com/optimizing-list-map/> about optimizing 
> List.map in OCaml a while ago, and Fred did some excellent work on this 
> <https://github.com/elm-lang/core/pull/707>! I have not had a chance to 
> fully assess the impact on generated code size, so I have not merged it in 
> yet. That trick can likely be very helpful for foldl and foldr, but no one 
> has looked into it.
>
> I suspect there are many creative things we can do if some focused energy 
> was applied to lists. I have not taken a comprehensive look at this after 
> Elm got TCO, and I suspect we can do better!
>
>
> Alternate Implementations of List
>
> Another thing to consider before switching to some other data structure is 
> that we can change the performance profile of List using various techniques 
> behind the scenes. For example:
>
>- Skip Lists <https://en.wikipedia.org/wiki/Skip_list>
>- Finger Trees <https://en.wikipedia.org/wiki/Finger_tree> that maybe 
>do some sort of "compression" on older leaves
>- I believe there's one that immutable.js does for their lists? 
>Richard told me about something like this. Where "old" nodes grow 
>exponentially in size so the nodes are 1, 2, 4, 8, etc. so it is faster to 
>hop around and you get better locality. Do you recall what this was called 
>Richard?
>
> I also think that manually recursing through lists with a case is 
> relatively common, at least in my experience, so I think it'd be good to 
> explore concrete bottlenecks in Elm code and see if there are not creative 
> things we can do to improve the performance profile of List without 
> changing it completely.
>
>
> Anyway, exciting to see your work as always! And hopefully these ideas are 
> helpful!
> Evan
>
>
>
> On Monday, June 12, 2017 at 12:15:59 AM UTC+1, Robin Heggelund Hansen 
> wrote:
>>
>> I've been doing some thinking on how to improve Arrays in Elm. The result 
>> of that thinking have been written down in this document:
>>
>>
>> https://docs.google.com/document/d/1Z8IC5qk98ISQLP_xKXNOHScCfzkQ8jCVSiYd1SxObB4/edit?usp=sharing
>>
>> The document is quite large, but most of it are benchmark results 
>> comparing Arrays and Lists.
>>
>> There are some questions at the bottom of the document that I would love 
>> to get feedback on.
>>
>

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

[elm-discuss] Re: The way forward for Elm Arrays

[Evan]

Very interesting, thank you for sharing!

I wanted to add a couple notes and ideas that I've had separately.


Syntax

I was formerly somewhat keen on having special syntax for other 
collections. For example, OCaml allows you to say [| 1, 2, 3 |] to create 
an array. Hassan made a really nice proposal 
<https://github.com/elm-lang/elm-plans/issues/12> to have it be #[ 1, 2, 3 
] back in 2015. Since then I realized you can do the following:

a = Array.fromList
s = Set.fromList
d = Dict.fromList

array =
  (a[ 1, 2, 3 ])

set =
  (s[ 1, 2, 3 ])

dict =
  (d[ 1 => "Tom", 2 => "Sue", 3 => "Jane" ])

(=>) = (,)

This is 1 or 2 characters off all the proposals out there, and it is 
visually much nicer in my opinion.

With that knowledge, the case for special syntax seems significantly 
weaker. I can also imagine detecting when a list is converted to something 
else and doing something more clever in the compiler. That path seems 
better overall to me.


List performance of map, foldl, and foldr

I shared this blog post <https://blogs.janestreet.com/optimizing-list-map/> 
about 
optimizing List.map in OCaml a while ago, and Fred did some excellent work 
on this <https://github.com/elm-lang/core/pull/707>! I have not had a 
chance to fully assess the impact on generated code size, so I have not 
merged it in yet. That trick can likely be very helpful for foldl and 
foldr, but no one has looked into it.

I suspect there are many creative things we can do if some focused energy 
was applied to lists. I have not taken a comprehensive look at this after 
Elm got TCO, and I suspect we can do better!


Alternate Implementations of List

Another thing to consider before switching to some other data structure is 
that we can change the performance profile of List using various techniques 
behind the scenes. For example:

   - Skip Lists <https://en.wikipedia.org/wiki/Skip_list>
   - Finger Trees <https://en.wikipedia.org/wiki/Finger_tree> that maybe do 
   some sort of "compression" on older leaves
   - I believe there's one that immutable.js does for their lists? Richard 
   told me about something like this. Where "old" nodes grow exponentially in 
   size so the nodes are 1, 2, 4, 8, etc. so it is faster to hop around and 
   you get better locality. Do you recall what this was called Richard?

I also think that manually recursing through lists with a case is 
relatively common, at least in my experience, so I think it'd be good to 
explore concrete bottlenecks in Elm code and see if there are not creative 
things we can do to improve the performance profile of List without 
changing it completely.


Anyway, exciting to see your work as always! And hopefully these ideas are 
helpful!
Evan



On Monday, June 12, 2017 at 12:15:59 AM UTC+1, Robin Heggelund Hansen wrote:
>
> I've been doing some thinking on how to improve Arrays in Elm. The result 
> of that thinking have been written down in this document:
>
>
> https://docs.google.com/document/d/1Z8IC5qk98ISQLP_xKXNOHScCfzkQ8jCVSiYd1SxObB4/edit?usp=sharing
>
> The document is quite large, but most of it are benchmark results 
> comparing Arrays and Lists.
>
> There are some questions at the bottom of the document that I would love 
> to get feedback on.
>

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

[elm-discuss] Re: Elm on fully distributed back-end? Meet Elmchemy. Elm for Erlang VM

[Evan]

Between /r/elm and slack, we came to a nice conclusion on all this :)

Just wanted to let folks know here!


On Thursday, April 27, 2017 at 1:50:30 PM UTC-7, Evan wrote:
>
> I'm not sure I understand exactly what this has to do with Elm.
>
> Based on this example <https://wende.github.io/elmchemy/stable/> this 
> appears to be a transpiler that uses syntax *similar* to Elm.
>
> For example:
>
>1. In the pattern matches, you pattern match on tuples without the 
>open and close parens. So this is not valid Elm code. 
>2. It appears that the ffi function is allowing you to bring in impure 
>Elixir functions. So now effects are not captured in the types.
>
> The second one in particular is such a divergence from the core design of 
> Elm that I don't see how it makes sense to call it by the same name. So 
> again, this does not appear to be related to Elm except in that the syntax 
> is similar. Is that a correct assessment?
>
> On Thursday, April 27, 2017 at 1:42:38 PM UTC-7, Krzysztof Wende wrote:
>>
>> Hello there everyone
>>
>> I think my project is ready enough to share it with you all.
>>
>> I'm a diehard longtime Erlang / Elixir programmer, and I always searched 
>> for a way to write static typing for Erlang.
>> After 5th attempts to implement Hindley-Milner on Elixir's AST I decided 
>> that it's time to try something else.
>>
>> So here it is:
>>
>>
>> https://www.reddit.com/r/elm/comments/67v2so/elm_on_fully_distributed_backend_meet_elmchemy/
>>  
>> <https://www.google.com/url?q=https%3A%2F%2Fwww.reddit.com%2Fr%2Felm%2Fcomments%2F67v2so%2Felm_on_fully_distributed_backend_meet_elmchemy%2F=D=1=AFQjCNGPNzBt63GPnKOOKZW10Qfj90owgQ>
>>
>> Elm to Elixir compiler.
>> Please enjoy, and please contribute!
>>
>> Constructive critique welcome
>>
>> PS. Yes. I am aware of alpaca-lang and purerl. I'll gladly answer why I'm 
>> not satisfied enough with these to anyone wondering
>>
>

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

[elm-discuss] Re: Elm on fully distributed back-end? Meet Elmchemy. Elm for Erlang VM

[Evan]

I'm not sure I understand exactly what this has to do with Elm.

Based on this example  this 
appears to be a transpiler that uses syntax *similar* to Elm.

For example:

   1. In the pattern matches, you pattern match on tuples without the open 
   and close parens. So this is not valid Elm code. 
   2. It appears that the ffi function is allowing you to bring in impure 
   Elixir functions. So now effects are not captured in the types.

The second one in particular is such a divergence from the core design of 
Elm that I don't see how it makes sense to call it by the same name. So 
again, this does not appear to be related to Elm except in that the syntax 
is similar. Is that a correct assessment?

On Thursday, April 27, 2017 at 1:42:38 PM UTC-7, Krzysztof Wende wrote:
>
> Hello there everyone
>
> I think my project is ready enough to share it with you all.
>
> I'm a diehard longtime Erlang / Elixir programmer, and I always searched 
> for a way to write static typing for Erlang.
> After 5th attempts to implement Hindley-Milner on Elixir's AST I decided 
> that it's time to try something else.
>
> So here it is:
>
>
> https://www.reddit.com/r/elm/comments/67v2so/elm_on_fully_distributed_backend_meet_elmchemy/
>  
> 
>
> Elm to Elixir compiler.
> Please enjoy, and please contribute!
>
> Constructive critique welcome
>
> PS. Yes. I am aware of alpaca-lang and purerl. I'll gladly answer why I'm 
> not satisfied enough with these to anyone wondering
>

-- 
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] Emphasizing /r/elm more

[Evan Czaplicki]

I recently talked with folks who moderate the various Elm discussion forums
about the challenges that come up and how we can do better.

The short version is: *we should start migrating more discussion to /r/elm
.*

Now the long version!


How Things Are Now

Long-form discussion is split between elm-discuss and /r/elm
. There are a lot of regulars that spend
more time on elm-discuss, but I think it's fair to say that /r/elm is much
more easily accessible and "public facing" for newcomers. This creates some
problems.

Problems with elm-discuss:

   - Threads are linear, so it's hard for people to branch off into
   sub-discussions.
   - There's no voting mechanism in elm-discuss, so topics are sorted by
   "are people posting?" not by "do people care?"
   - Moderation to avoid spam is more difficult. All new users are
   moderated by default to avoid those awful spam robots that Google Groups
   does not catch.
   - It goes to people's already full inboxes. If you change this, you use
   the online interface, which is not amazing.

Problems from having two long-form forums:

   - Lots of valuable expertise *only* lives on elm-discuss. When new folks
   come to /r/elm, there are not as many folks with as much production
   experience.
   - Blog posts (frequently shared on /r/elm) miss out on a lot of valuable
   feedback.


How Things Could Be

Right now I'm just suggesting that folks who are regulars here get on
/r/elm and see if you like it. I'd like to start by shifting the center of
gravity for community discussion.

Longer term though, things could look more like how Rust does it. It seems
like /r/rust  is the center of gravity for
community discussion. See their sidebar! They moderate content well and have
some laughs
.
(I personally think it's very important for moderators to be active in
guiding people towards *friendly* discussion! That's super hard on
elm-discuss.)

They also have an interesting approach to answering beginner questions

that
I think it'd be good to try out!

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

[elm-discuss] Re: Suggested edit to Json.Decode docs

[Evan]

Those docs came from a draft API that didn't ultimately make it. I'll make 
an edit!

On Wednesday, November 16, 2016 at 5:59:52 AM UTC-8, Max Goldstein wrote:
>
> That's probably an oversight. Yes, docs for core should not reference a 
> third-party library. 

-- 
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] Performance in Elm - Comparing Elm, React, Angular, and Ember

[Evan]

Finally finished the blog post on performance 
!

With 0.17, I had to rewrite our virtual DOM implementation from scratch, 
and the new one is way faster. So if you are using 0.17, your code is 
already using the new implementation :D

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

[elm-discuss] Re: More thorough side-effect isolation

[Evan]

Warning, I have not read everything here. About ignoring commands though, 
think of the type of a Html.App.program

program : { init, update, view, subscriptions } -> Program Never

The essence of this is just a record. So you can wrap that record however 
you want. Say like this:

myProgram : ({ init, update, view, subscriptions } as details) =
  { details | update = \msg model -> (fst (update msg model), Cmd.none) }

Now you have programs that drop all commands.

I'm in the process of revining elm-reactor to track history for exactly the 
kinds of things you have in mind (testing, etc.) and I am using this basic 
technique. Anyone can do this. You can write time-travel in pure Elm this 
way. Make the update log all the messages it gets.

Again, I have no idea what's happening in this discussion though, so 
hopefully that's a helpful insight.


On Thursday, August 11, 2016 at 10:37:48 AM UTC-7, Kasey Speakman wrote:
>
> Hi all,
>
> I'm getting to know Elm. I recently read this article 
>  about 
> event sourcing in Elm. Essentially, the time-traveling debugger is event 
> sourcing. But it's a pattern that could be used in an app for other great 
> things. (Lots of literature on that in the internet. One particular 
> interest of mine is producing a complete failing use case from live running 
> app -- it's just all the events. Obviously wouldn't work for real-time 
> apps... too many events... but for most of mine it would.)
>
> However, one thing that is a hindrance (to the TTD as well) and that has 
> always bothered me about the Elm examples is this signature.
>
> update : Msg -> Model -> (Model, Cmd Msg)
>
>
> Because an update returns both a Model and Cmd, for instance, the 
> time-traveling debugger "...needs to tell the runtime not to perform any 
> side-effects during replay to avoid these issues"[1]. An event-sourcing 
> implementation would have to figure a way to do the same without runtime 
> hooks.
>
> This part of the architecture mixes concerns by returning a model and 
> effects. And usually (not always) you see each message returning one or the 
> other, not both. From the docs:
>
> update : Msg -> Model -> (Model, Cmd Msg)
> update msg model =
>   case msg of
> Roll ->
>   (model, Random.generate NewFace (Random.int 1 6))
>
> NewFace newFace ->
>   (Model newFace, Cmd.none)
>
>
> Here, Roll does an effect, but nothing with the model. NewFace returns a 
> new model but no effects. You do have cases where you want to update a UI 
> element when an outside effect happens, like activating a spinner when 
> sending off an HTTP request. Those could still be modeled as two "Cmd"s. 
> One that immediately returns a separate message affecting the model's 
> spinner. And another to do the HTTP request.
>
> So it seems to me that there are really two concepts at work here. There 
> are "events" which have happened and can be used completely 
> deterministically, and there are commands which interface with the outside 
> and may produce events.
>
> I think it's something worth pointing out and considering for the future. 
> What do y'all think?
>
> Kasey
>
> [1] source , section "How Elm makes this 
> possible", subsection "Purity", last paragraph
>

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

[elm-discuss] Re: How do I organize "inheritance" between my data types?

[Evan]

Both Max and Aaron PS suggested using extensible records for this scenario, 
but I don't think that is the right way to go. It is particularly tempting 
for folks who want Elm to just work like an OO language, but it isn't like 
that. I think Tessa put it very nicely in her post 
: 
extensible 
records are for making functions flexible, not for modeling your data. I 
highly recommend OP and the folks who suggested extensible records read 
that post!

I believe Tessa's 
 and 
Aaron Vonderhaar's advice will get you to better code that is easier to 
understand and refactor.

On Sunday, July 17, 2016 at 6:40:52 PM UTC-7, Max Goldstein wrote:
>
> Aaron's solution is a good one, but since customers and employees are both 
> people, you may want:
>
> type alias Person a =
> { a | name : String
> , address : String
> }
>
> type alias Employee =
> Person { department : String }
>
> type alias Customer =
> Person { itemsPurchased : Int }
>

-- 
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: Set.fromList crashing

[Evan]

Zach, try deleting elm-stuff/ and building the Set version again. Is there 
a problem then? If so, try deleting ~/.elm as well. Still a problem?

On Thursday, July 14, 2016 at 9:21:09 AM UTC-7, Zachary Kessin wrote:
>
> I reworked the code into a dict, not a great solution but it worked and 
> everyhting is now good
>
> Zach
> ᐧ
>
> On Thu, Jul 14, 2016 at 1:49 PM, William Bailey  
> wrote:
>
>> PS: I code in GO aka GOLANG a lot too and this has been an active area 
>>> for them for the last year.  They call it "vendoring".
>>
>>
>>  I suppose that ideally there would be a way to auto-update to the latest 
>> bug-fix releases but major release updates (eg the move to 0.17 from 0.16) 
>> would need to be done consciously by hand.  
>>
>> -- 
>> 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
> Your CRM Link 
> 
> 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.

Re: [elm-discuss] Abort tasks?

[Evan Czaplicki]

Process.spawn and Process.kill let you "kill tasks". Killing a process that
has an HTTP request pending will cancel the request as well.

Interprocess communication is not ready yet, but the current API can cover
some use cases.

On Tuesday, June 28, 2016, Mark Hamburg  wrote:

> I would absolutely tag the tasks. You can do this in the response action.
> I recommend keeping a counter in the model and advancing it whenever the
> basis for requests changes.
>
> Aborting would be ideal but it's harder or potentially impossible at
> present.
>
> Mark
>
> --
> 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.
>


-- 
Sent from Gmail Mobile

-- 
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] Has elm reactor 0.17 dropped support for HTML files?

[Evan Czaplicki]

Try the 0.17.1 beta

On Tuesday, June 28, 2016, Stuart Axon <stu.a...@gmail.com> wrote:

> Hi,
>I just started with elm and this is a bit confusing.   - I guess I need
> a separate http server for now to see the output ?
>
> So workflow - is:
>
> Compile, then refresh browser that is pointing at separate http server?
>
> S
>
>
>
> On Sunday, May 15, 2016 at 9:57:26 PM UTC+1, John Orford wrote:
>>
>> Yeh the manual compiles are irksome
>>
>> Paul D <paul...@gmail.com> schrieb am So., 15. Mai 2016 17:07:
>>
>>> It's not just serving the files, it's also debugging. It'd be pretty sad
>>> if embedding Elm meant that you couldn't use its main (sole?) development
>>> tool. I'm glad to hear that HTML support is coming back!
>>>
>>>
>>> On Sunday, May 15, 2016 at 3:16:07 AM UTC-6, John Watson wrote:
>>>>
>>>> Don't worry - I'm quite happy just serving it with Apache.
>>>>
>>>> On Sunday, 15 May 2016 01:29:06 UTC+1, Evan wrote:
>>>>>
>>>>> It's probably a mistake in how I added the "pretty" view. Like I've
>>>>> been saying to everyone about reactor, I needed to release without
>>>>> *everything* or I'd never get 0.17 out the door. Things will be fixed
>>>>> up later!
>>>>>
>>>>> On Sat, May 14, 2016 at 8:11 AM, John Watson <john@gmx.co.uk>
>>>>> wrote:
>>>>>
>>>>>> elm-reactor --version gives 0.17.0.  I'm running 64-bit Ubuntu.
>>>>>>
>>>>>> On Saturday, 14 May 2016 16:07:29 UTC+1, Joey Eremondi wrote:
>>>>>>>
>>>>>>> Can you verify what version of Elm reactor is being used?
>>>>>>> On May 14, 2016 2:43 AM, "John Watson" <john@gmx.co.uk> wrote:
>>>>>>>
>>>>>>>> I'm affected by this, too.  If I compile with --output Main.html
>>>>>>>> then an Html file is produced with the new syntax of 
>>>>>>>> Elm.Main.fullscreen();
>>>>>>>> however elm reactor no longer serves it.  I need this to test HTTP 
>>>>>>>> requests
>>>>>>>> which otherwise will give me CORS errors.  Am I missing something 
>>>>>>>> obvious?
>>>>>>>>
>>>>>>>> On Friday, 13 May 2016 09:51:39 UTC+1, Paul D wrote:
>>>>>>>>>
>>>>>>>>> I'm using the fullscreen function to embed an Elm app in an HTML
>>>>>>>>> file. With Elm 0.16, I could run elm-reactor and then go to
>>>>>>>>> http://localhost:8080/myfile.html to use the app. After upgrading
>>>>>>>>> to Elm 0.17, elm-reactor no longer serves the HTML. Instead it just
>>>>>>>>> displays the file contents, much like view source would. Is this a 
>>>>>>>>> bug or
>>>>>>>>> was that functionality deliberately removed?
>>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "Elm Discuss" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to elm-discuss...@googlegroups.com.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Elm Discuss" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to elm-discuss...@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...@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.
>


-- 
Sent from Gmail Mobile

-- 
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] Try out the 0.17.1 beta

[Evan Czaplicki]

The 0.17 release revealed a few rough spots. Particularly for new folks who
were trying to install evancz/elm-html instead of elm-lang/html. So I did a
bunch of bug fixes for stuff along these lines. The main changes are:

   - Default dependencies in elm-package.json are core *and* elm-lang/html.
   - Error messages for elm-package are improved (e.g. this
   
and this
   
   )
   - Packages download concurrently (a.k.a. faster)
   - Make elm-reactor serve assets better. Was messing up CSS and HTML.
   - Use ~/.elm/0.17.1/ so all globally cached things are isolated
   - Binaries are much smaller (~120MB to ~40MB on OSX)

I have some beta binaries ready. Please give them a try:

   - mac 
   - windows 

It is just a better version of 0.17, so you should be able to install and
just have things be nicer. If you try it and want to go back to 0.17, just
run the installers here . The most recent one
takes precedence.

I'm hoping to do a relatively quite announcement on twitter tomorrow, so
let me know if you run into any 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] https://github.com/evancz down?

[Evan Czaplicki]

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 <edit...@gmail.com> 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 <https://twitter.com/czaplic/status/746761566255779840>.
>>
>> 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 <edi...@gmail.com> wrote:
>>
>>> Just wanted to compile something using evancz/elm-markdown and the
>>> download failed <http://i.imgur.com/aIjs3Kv.png>. 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...@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.
>


-- 
Sent from Gmail Mobile

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

[Evan Czaplicki]

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.

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

[Evan James]

Whether or not there was a process for contributing to the compiler, only 
Evan could have made the proposal to replace Signals.  That's not because 
it takes a dictator to make bold decisions, or because Evan is so much 
smarter than everyone else, or anything like that.

It's because Signals were based on Evan's graduate research, and Elm grew 
out of that work.  It would be extraordinarily insulting for someone to 
propose deleting Evan's thesis from his own language.  That's why nobody 
could make the proposal unless Evan suggested it first.

On Sunday, June 5, 2016 at 12:40:50 PM UTC-4, Rex van der Spuy wrote:
>
> Hi Everyone!
>
> I'm not sure that open-source contributions are always a good idea.
> I want more simplicity, less syntax and fewer features  :)
> That's why I'm using Elm.
>
> Open-source projects invariably go the opposite way: contributors keep on 
> endlessly "adding more stuff".
> They tend to end up as a steaming witches brew of badly patched together 
> excellent ideas and a bloated mess of pain.
> That's why I'm not using React, Angular or JavaScript (and wish I didn't 
> have to use Node or Webpack).
>
> I'm pretty doubtful that if Elm were truly open source that such a 
> radical, well-considered, and superbly correct decision as getting rid of 
> signals would have ever happened.
>
> But, I'm just a dumb-user! 
> I'm only interested in using Elm for making cool stuff - I'm not 
> interested in or capable of contributing to its source code.
> However, to my great delight I found that 0.17 addressed the four big 
> headaches I had in 0.16:
> Signals (confusing!), Boilerplate (too much!) drag-and-drop (tricky!) and 
> random numbers (near impossible?)
>
> How did that happen?
> Because I and many others inundated Elm's discussion lists (here and at 
> Reddit) with endless questions on these subjects.
> And, someone was obviously listening closely, because all those issues 
> were magically addressed in 0.17 without my having to even having to glance 
> at Elm's source code.
> Thank you, Elm!
>
> I also noticed that there were many extremely well-considered, 
> convincingly argued and excellent suggestions from the community on how to 
> solve these problems.
> But, significantly, the way they were solved in 0.17 was better than all 
> of them.
>
> What would have happened if those excellent - but ultimately less perfect 
> - decisions made it into 0.17?
>  JavaScript?
>
> So if development on Elm needs to be slow and reject direct collaboration 
> in order for it to be good, then I truly hope that future development is as 
> slow and single-mined as as possible :)
>
> PS: 
>
> (And I just want to once again thank all of you who've helped me to lean 
> Elm with your brilliant answers to all my newbie questions over these past 
> 6 months - Peter! Daniel! Magnus! Max! and others! - you guys rock! I 
> deeply appreciate it.)
>
> On Thursday, June 2, 2016 at 3:04:53 AM UTC-4, Peter Damoc wrote:
>>
>> On Thu, Jun 2, 2016 at 2:34 AM, Evan <eva...@gmail.com> wrote:
>>
>>> Use ports!
>>>
>>> Support for "web platform" things will expand as quickly is as 
>>> manageable with all the other things that need to happen.
>>>
>>  
>> https://groups.google.com/d/msg/elm-discuss/oQz5_HvsdcQ/BFN_rLIDAgAJ
>>
>> Evan, 
>>
>> Here is what I see: 
>>
>> Fred attempted to expand the support for the "web platform". 
>> He did all the work and produced a package that follows, to the best of 
>> his abilities, the latest guidelines. 
>> He even went as far as to gift this package to elm-lang.org. 
>> He opened an issue and there are a number of people who saw that issue 
>> and expressed interest in having this solved (even if they did it only by 
>> giving the issue a thumbs-up) . 
>>
>> There was NO official feedback on that issue in the past 7 days since it 
>> was published. 
>> No comment, no label, no feedback either way. 
>> And now you say "Use ports!" like that doesn't even exist. 
>>
>> I realize that there are other important things that need to happen but 
>> maybe you should take some time and create some Community Guidelines that 
>> would include a detailed checklist for contributing. 
>>
>> Make it easier for people like Fred who are actively trying to help to 
>> actually help. 
>> Make it easier for people who see people like Fred to become like Fred 
>> (active contributors). 
>>
>> I realize that there are technical concerns and maybe legal concerns but 
>> all these can be solved by adopting a clear and solid contr

Re: [elm-discuss] Re: Web storage

[Evan]

Use ports!

Support for "web platform" things will expand as quickly is as manageable 
with all the other things that need to happen.

On Wednesday, June 1, 2016 at 3:45:48 PM UTC-7, Frederick Yankowski wrote:
>
> I have not seen any such documentation. One has to work from examples. And 
> the Elm leaders (broadly speaking) actively discourage us from writing 
> native code and effect managers.
>
> On Wednesday, June 1, 2016 at 5:14:30 PM UTC-5, Leonti Bielski wrote:
>>
>> Hi Frederick! This is awesome, thanks!
>> Is there any documentation on how to write native modules?
>>
>

-- 
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] Announcing elm-lang/navigation for "routing in single-page apps"

[Evan]

Simon, just like I said here 
<https://github.com/elm-lang/navigation/issues/3>, create 
an http://sscce.org/ and open a new issue. Provide a minimal Elm program 
that exhibits the error, compiles, etc.

Read http://sscce.org/, particularly the part about self-contained.

On Thursday, May 26, 2016 at 1:31:14 PM UTC-7, Simon wrote:
>
> My initial tests with the code shows that it crashes pretty heavily. I was 
> trying to use HTML5 urls rather than #/, so I made these changes in the 
> example code. I should have dropped 9, not 8, but the result was a complete 
> hang.
> ```
> toUrl : Int -> String
> toUrl count =
>   "/counter/" ++ toString count
>   -- "#/" ++ toString count
>
>
> fromUrl : String -> Result String Int
> fromUrl url =
>   String.toInt (String.dropLeft 8 url)
> ```
>
>
> On Thursday, 26 May 2016 20:28:54 UTC+2, Gage Peterson wrote:
>>
>> I was too, a bit confused to find out that it didn't show up in the 
>> subscriptions... and the fact that we're aren't using Html.App anymore. Not 
>> a huge deal but I think it would be nice to like only 3 or 2 ways to set a 
>> project to lower the cognitive load. Not a huge deal considering how 
>> closely related everything is in Elm. 
>>
>>  The "s" command failed to be looked up properly by elm-oracle (probably 
>> a bug either in the vim config or oracle), I think "strict" or perhaps 
>> "exactly" would be a better name. People can always alias it if it gets too 
>> long. I'm a big fan of aliasing in the local scope of function rather than 
>> at the Library level. 
>>
>> Very strong work however! It was very easy to understand overall. 100x 
>> better than what I've seen in JS in complexity and size. Bravo!
>>
>> On Thursday, May 26, 2016 at 4:09:35 AM UTC-6, Fedor Nezhivoi wrote:
>>>
>>> Shouldn't "s" function be named as "strict"?
>>>
>>> 2016-05-26 12:10 GMT+06:00 Bogdan Popa <popa.b...@gmail.com>:
>>>
>>>> I've updated elm-route's example app to use `elm-lang/navigation`[1].
>>>> The diff[2] looks pretty good if you ask me.  Thanks guys!
>>>>
>>>> 1: https://github.com/Bogdanp/elm-route/tree/master/examples/app
>>>> 2: 
>>>> https://github.com/Bogdanp/elm-route/commit/2b33522c09213b1197fe9512c9ac3fc745b1f16d
>>>>
>>>> Evan Czaplicki <eva...@gmail.com> writes:
>>>>
>>>> > On Friday, Noah and I worked on "updating elm-history" so that folks 
>>>> can do
>>>> > "routing" with Elm 0.17. The results are these libraries:
>>>> >
>>>> >- elm-lang/navigation
>>>> ><http://package.elm-lang.org/packages/elm-lang/navigation/latest/>
>>>> >- evancz/url-parser
>>>> ><http://package.elm-lang.org/packages/evancz/url-parser/latest/>
>>>> >
>>>> > I think they will cover the core functionality in a way that also 
>>>> promotes
>>>> > healthy architecture. If you disagree, I ask that you *use* these 
>>>> libraries
>>>> > before you share your opinion (or ideally the particular scenario you 
>>>> are
>>>> > having trouble with).
>>>> >
>>>> >
>>>> > Details
>>>> >
>>>> > The elm-lang/navigation library is the core thing. It lets you get 
>>>> notified
>>>> > about changes to the address bar. This may be the user typing in 
>>>> there or
>>>> > pressing the forward and back buttons on the browser. It also lets you
>>>> > "navigate to new URLs" so you can go to new URLs without reloading any
>>>> > assets.
>>>> >
>>>> > The elm-lang/navigation library is designed such that you can parse 
>>>> URLs
>>>> > however you want. You can see a basic example of that here
>>>> > <https://github.com/elm-lang/navigation/tree/master/examples>. The
>>>> > evancz/url-parser library is meant to handle more complex cases. You 
>>>> can
>>>> > see a bit of that in this example
>>>> > <https://github.com/evancz/url-parser/tree/master/examples>.
>>>> >
>>>> > My URL parser is intended to be a baseline for exploration. There are
>>>> > probably cases it does not cover well. My goal right now is to point 
>>>> us
>>>> > towards good API

[elm-discuss] Announcing elm-lang/navigation for "routing in single-page apps"

[Evan Czaplicki]

On Friday, Noah and I worked on "updating elm-history" so that folks can do
"routing" with Elm 0.17. The results are these libraries:

   - elm-lang/navigation
   
   - evancz/url-parser
   

I think they will cover the core functionality in a way that also promotes
healthy architecture. If you disagree, I ask that you *use* these libraries
before you share your opinion (or ideally the particular scenario you are
having trouble with).


Details

The elm-lang/navigation library is the core thing. It lets you get notified
about changes to the address bar. This may be the user typing in there or
pressing the forward and back buttons on the browser. It also lets you
"navigate to new URLs" so you can go to new URLs without reloading any
assets.

The elm-lang/navigation library is designed such that you can parse URLs
however you want. You can see a basic example of that here
. The
evancz/url-parser library is meant to handle more complex cases. You can
see a bit of that in this example
.

My URL parser is intended to be a baseline for exploration. There are
probably cases it does not cover well. My goal right now is to point us
towards good API design, not to be *the* URL parser.


Thanks

Big thanks to Noah for working through all this with me! And thank you to
Aaron who helped review and talk through the API we ended up with. These
were fun to work on :D

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