About --debug

[Evan Czaplicki]

So far no one has said anything about using the debugger. Does that mean everything is great and works on all platforms?

Can you share some experiences trying it out? Anything it makes sense to discuss?

For example, I'd like to make the following two improvements:

• Somewhere show the index of the message.
• Have the expando model deal with "line is too long" data more intelligently.

[Richard Feldman]

So far no one has said anything about using the debugger. Does that mean everything is great and works on all platforms?

Can't speak for anyone else, but personally I can't try it on anything nontrivial until a bunch of libraries I depend on have published 0.18-compatible versions.

[Evan Czaplicki]

At this stage, I am hoping folks will use it however they can and give feedback based on that.

For example, you can use 0.18 version of elm-todomvc or on Pablo's progress example.

Richard, I assume you mean "I can't try it on work stuff until a bunch ..." because I know you have an example from the workshop you ran that works with the debugger. I think it's totally possible to get decent experiential data as things stand, so read this post as, "hey, can we try to get that data?"

On Mon, Oct 17, 2016 at 12:31 PM, Richard Feldman <richard....@gmail.com> wrote:

So far no one has said anything about using the debugger. Does that mean everything is great and works on all platforms?

Can't speak for anyone else, but personally I can't try it on anything nontrivial until a bunch of libraries I depend on have published 0.18-compatible versions.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/0c88dfc2-658b-4f73-9baf-15781c2dc4ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Feldman]

Richard, I assume you mean "I can't try it on work stuff until a bunch ..." because I know you have an example from the workshop you ran that works with the debugger. I think it's totally possible to get decent experiential data as things stand, so read this post as, "hey, can we try to get that data?"

Fair point! I got that working by manually updating elm-stuff, but I can do that again and see if everything still works.

[Mike Clark]

I'd love to give it a whirl. Are there notes somewhere that outline the basic usage? 

[Florian Zinggeler]

I tried it on a few of my projects, but couldn't try it on any of my current projects, as the dependencies weren't updated yet.

However, I found an old 0.16 project with very few dependencies and I managed to upgrade this to 0.18.

This is a little game, and it becomes immediately obvious that the debugger wasn't designed with games in mind.

Don't get me wrong, this is totally ok, as elms main target are web apps, not games.

The biggest issues with games and the debugger are:

  1. It doesn't pause the event stream when the debugger is open. It would be helpful to pause the game.

  2. No filtering or grouping of similar events:

        In a game setting I get a tick event every 16ms, this overloads the UI very quickly.

        One way to avoid that would be to enable msg filtering and/or debouncing/throttling

        Another way might be to group similar msgs.

Addressing these issues might also help app developers that make use of elm controlled animations.

I also tried the debugger with a more traditional but very simple web app and found no problems for that use case.

I absolutely love that you can save and load a history, very helpful!

I miss the timeline from the old debugger, but I also see that it was basically just a cool looking gimmick.

[Mike Clark]

Ah, it turns out to be as easy as I'd expect from Elm. :-) 

Not sure if this is the canonical usage, but I just compiled an educational 0.18 app using --debug, opened the index.html in Chrome, and clicked the "Explore History" pane in the lower-left. One oddity I noticed right away is there seems to be some encoding issues (see screenshot). Clicking "Export" in Chrome gave me a history-1.json file that I was able to import successfully. Really cool!

For what it's worth, Safari doesn't seem to know what to do with a .json file (it just shows the data in the browser).

[Peter Damoc]

On Mon, Oct 17, 2016 at 9:25 PM, Evan Czaplicki <eva...@gmail.com> wrote:

So far no one has said anything about using the debugger. Does that mean everything is great and works on all platforms?

Can you share some experiences trying it out? Anything it makes sense to discuss?

 

Based on a very summary look: 

1. Clicking on a message and then on resume resumes the app from the end of the messages rather then the selected message. This is both unexpected (for people who played with the old debugger) and potentially less useful (I might want to explore a different execution path) 

2. The messages sidebar is not resizable and with a long enough Message tag, I found myself wanting to drag to make it a little bigger. 
3. Having a Time.every based subscription in the app, make the interaction with the debugger troublesome. It would be awesome to have a play-pause-resume style of interacting with the app. 

--

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

[Evan Czaplicki]

Thanks for the feedback so far! I'll reply to folks individually to keep it more organized.

Also, I just added indexes to each message, so if you delete elm-stuff/ and rebuild you should see them!

On Mon, Oct 17, 2016 at 2:25 PM, Florian Zinggeler <florian....@gmail.com> wrote: 

  1. It doesn't pause the event stream when the debugger is open. It would be helpful to pause the game.

I think it is going to be tricky to balance the workflows for web apps and games given what we know now.

When I debug a web app, I usually open the debug pane first, so I can see the model changing. So I do not want it to pause, I want to see things change as I use the program.

My gut here is that it'll be clearer how to balance the needs of each workflow as we learn more about them. Maybe it's a pause button, maybe it is detecting fast events, maybe it is some settings. More data will make this more clear.

 

  2. No filtering or grouping of similar events:

        In a game setting I get a tick event every 16ms, this overloads the UI very quickly.

        One way to avoid that would be to enable msg filtering and/or debouncing/throttling

        Another way might be to group similar msgs.

Yeah, this is something I was planning to do in the next round because it depends on how people want to use things. In some ways, having a search box that filters messages is really nice. You can put in the type of message you care about and it'll filter everything else out. But maybe you want to always ignore certain events?

I think the hard part here is really UI. There are a bunch of viable ideas, but it's hard to know how to fit them into the UI in a nice way. I feel like the best way to make progress here is to create UI mocks for particular usage scenarios.

Addressing these issues might also help app developers that make use of elm controlled animations.

Definitely agree. 

Generally, I think both of these are important things to solve, but my feeling is that it will be hard to solve them in the first release. Once we get more data, we can make mocks and experiment with how to make this nice without making the UI way more complex.

[Evan Czaplicki]

Not sure if this is the canonical usage, but I just compiled an educational 0.18 app using --debug, opened the index.html in Chrome, and clicked the "Explore History" pane in the lower-left. One oddity I noticed right away is there seems to be some encoding issues (see screenshot). Clicking "Export" in Chrome gave me a history-1.json file that I was able to import successfully. Really cool!

What OS and browser are you seeing those encoding artifacts in? They should be little unicode triangles.

Can you report more info here? With a title like "[alpha] unicode triangles do not render properly on ..."

 

For what it's worth, Safari doesn't seem to know what to do with a .json file (it just shows the data in the browser).

Yeah, I noticed that as well. It appears that there is no way to force Safari to do a download right now. If anyone has forced Safari to do the right thing, I'm interested in how you did it!

[Evan Czaplicki]

1. Clicking on a message and then on resume resumes the app from the end of the messages rather then the selected message. This is both unexpected (for people who played with the old debugger) and potentially less useful (I might want to explore a different execution path)

There is no more exploring a different future. In fact, when you go back into the history, the program is still running. If an HTTP request resolves after you pause, that'll get fed into your model. The debugger is controlling the view, so you won't see that though. This means you cannot drop important messages while paused and get into an invalid state.

 

2. The messages sidebar is not resizable and with a long enough Message tag, I found myself wanting to drag to make it a little bigger.

I was thinking it may make sense to show the message for a given frame in full in the value explorer area on the right. Would that help?

 

3. Having a Time.every based subscription in the app, make the interaction with the debugger troublesome. It would be awesome to have a play-pause-resume style of interacting with the app. 

Not sure what this means, but it sounds similar to what Florian was saying about games. I think making this nice will be out of scope for the initial release. 

[Mike Clark]

Sure thing - I've reported the details in a new issue. Hope that helps!

[Fedor Nezhivoi]

Can't try it as well. I'd like to make installations of such things in a manageable way, but there is currently no npm package.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/72e27f21-96ae-42d9-8b22-899b79be1f4b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Fedor Nezhivoi

[Keith Lazuka]

Current versions of Safari do not support the 'download' attribute on the anchor element. But the beta version *does*, and I can confirm that the Elm debugger's export button works correctly in the beta:

https://developer.apple.com/safari/technology-preview/release-notes/

[Keith Lazuka]

One problem I've noticed with Elm TodoMVC and the --debug flag is that on Safari, the input field's placeholder text does not get replaced when you load from an exported Elm history file. It works fine in Chrome.

Notice above that the todo item, "bad", is drawn on top of the placeholder text, "what needs to be done".

Safari Version 10.0 (12602.1.50.0.8) on macOS Sierra

My Elm TodoMVC checkout is SHA 166e5f2

I have attached the history file.

[Yosuke Torii]

I tried the debugger on some of my projects.

The great points I found is there is no need to modify the code or add extra dependencies. Very clean! 

Also, it is always visible so we would never ship debugging version by mistake. 

However, I also found this debugger can become a lot greater.

1. Frequent messages like Time.every (which Florian and Peter mentioned) occurs not only in games but also in general web apps. Drag and drop example emits many "Mousemove" messages. So I want filtering or grouping feature too.

2. I think it needs more features that support users to dig deeper into the problem. Now we can see how model and messages is working. The next thing we'll probably want to know is, where in the model has changed, when it changed or why it has changed. (Maybe this is not the scope of first release though.)

I made my own debugger to explore around those things (some people gave me feedback, I appreciate it!), but I think official support would be way better (mine is doing some hacks!). I hope it helps for something, but don't want to be too opinionated on this.

2016-10-18 14:22 GMT+09:00 Fedor Nezhivoi <gyz...@gmail.com>:

Can't try it as well. I'd like to make installations of such things in a manageable way, but there is currently no npm package.

On Tue, Oct 18, 2016 at 2:30 AM Mike Clark <mi...@pragmaticstudio.com> wrote:

Sure thing - I've reported the details in a new issue. Hope that helps!

On Monday, October 17, 2016 at 4:26:54 PM UTC-6, Evan Czaplicki wrote:

Not sure if this is the canonical usage, but I just compiled an educational 0.18 app using --debug, opened the index.html in Chrome, and clicked the "Explore History" pane in the lower-left. One oddity I noticed right away is there seems to be some encoding issues (see screenshot). Clicking "Export" in Chrome gave me a history-1.json file that I was able to import successfully. Really cool!

What OS and browser are you seeing those encoding artifacts in? They should be little unicode triangles.

Can you report more info here? With a title like "[alpha] unicode triangles do not render properly on ..."

 

For what it's worth, Safari doesn't seem to know what to do with a .json file (it just shows the data in the browser).

Yeah, I noticed that as well. It appears that there is no way to force Safari to do a download right now. If anyone has forced Safari to do the right thing, I'm interested in how you did it!

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/72e27f21-96ae-42d9-8b22-899b79be1f4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Fedor Nezhivoi

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAL91TZhfiZX5cCRQgKJkYJ3uvuREJ%3DOLmqNZtecj83M0DFQfXQ%40mail.gmail.com.

[Florian Zinggeler]

> In some ways, having a search box that filters messages is really nice. You can put in the type of message you care about and it'll filter everything else out. But maybe you want to always ignore certain events?

Thinking a bit more about this, I think filtering isn't enough. What would work best in my example (and I think also for the drag and drop example) would be to group consecutive messages of the same type into one. Then when you click on such a grouped message, show a mini timeline in the panel on the right

> I was thinking it may make sense to show the message for a given frame in full in the value explorer area on the right. Would that help?

Yes, I think this is best. Show the message with the full message payload on the right, just above the model.

I generally think that the space on the right could be used better, maybe add a small toolbar at the bottom with a pause/resume button.

> There is no more exploring a different future. In fact, when you go back into the history, the program is still running. If an HTTP request resolves after you pause, that'll get fed into your model. The debugger is controlling the view, so you won't see that though. This means you cannot drop important messages while paused and get into an invalid state.

I think exploring a different future is very important for quickly testing all possible sequences of actions.

I don't think that the risk of getting into an invalid state is important enough for dropping such a useful feature. 

Here is a simple ascii mockup of how I imagine the grouping could look like:

# Timeline   |  # msg detail

...          | (1, 2, ..., 12)

57x Tick     |  Tick 16

KeyInput     |

|> 12x Tick  |  # model

KeyInput     | { game = { .. } }

...          |

             | resume | export | import

or the drag and drop example:

# Timeline   |  # msg detail

...          |  DragEnd
DragStart    |   { x = 492, y = 229 }

13x DragMove |

|> DragEnd   |  # model

             | { position = { x = 444, y = 192 }

             | , drag = Nothing }

             |

             | resume | export | import

[Evan Czaplicki]

Floraian, I don't think it makes sense for navigating messages to be split into two different places (makes navigation more confusing, means the two visually distinguished areas have overlapping functionality) so I made a mock that I think is starting towards something nicer on that:

There are still tons of hard questions after this. How to open and close the group? How to navigate with keyboard when the group is open and closed? How to decide when something is a group? 5 messages in a row with the same constructor? But what if someone is selecting a bunch of stuff and it's helpful to see more info? So is it a threshold of repetitions, or do you need to bring in timing as well. Only group if they are fast events? Or regular events?

Point is, this is hard, and I don't think it's productive to just talk about it more.

So here is how I want to proceed on this:

• If you think there's a program where the debugger pane can be better, turn that program into an http://sscce.org in a gist along with a history.json that shows what looks bad. Open an issue here with the gist and I will consolidate them into a meta issue. The more diverse the examples the better.
• Yosuke, your debugger is really nice! The idea of having "field search" on the model is great and seems really quick and practical. I think we should coordinate to see if we can combine our efforts. I'll contact you about this.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/b755063a-0c8f-4054-9200-51bae53f0879%40googlegroups.com.

[Florian Zinggeler]

Yes, you are right.

Your mock looks much clearer and more intuitive.

I do agree that this is a hard problem, and I don't think it should block the release of 0.18.

The debugger in it's current state is very nice already, making it nicer for certain situations would just be a nice bonus.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

[Simon Hampton]

I tried --debug with some code I had recently updated to 0.18-alpha. I realise this is not an SSCE but hope it is nonetheless useful.

I ran `elm-make --debug src/Main.elm --output=dist/Main.js`, and when I then tried to load the code I got an error at this part of the compiled code

```

function init(value) 

{ 

[...]

if (type === 'object' && 'ctor' in value)

{

var ctor = value.ctor;

```

value was `null`.

I did not get these errors when using `elm-make src/Main.elm --output=dist/Main.js`

I've uploaded the code (i commented out all the port code, thinking that might be cause, but it was not), including the js file compiled with --debug in /dist.

Simon

[Evan Czaplicki]

Simon, need an SSCCE and info about OS, browser, etc. Open an issue on virtual-dom like "[alpha] ..."

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/67c92c67-836c-4f9f-aad4-8b6b9525b800%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

[Simon Hampton]

https://github.com/elm-lang/elm-make/issues/122

It is being caused by having Json.Encode.null in init

[Gábor Varga]

I am very excited about this upcoming debugger! Just want to share a screenshot from a relatively more complex application since others have not done that so far.

The only really obvious (and for me blocking) issue is that it is impossible to read the messages (this was mentioned before).

Putting the full message text in a tooltip (using the standard title attribute) is minimal effort probably and would greatly improve usability even with this simple UI.

[Richard Feldman]

Thanks for reporting this! I made a quick PR.

[Gábor Varga]

Thanks Richard for this PR, I tried it out.

Actually it is really exciting to use the debugger and go through how the application state is changing. 

I mean it was really awesome, really very exciting experience for me -- even though I have good understanding of what is going on in my project -- to dig into and really interactively click back and forth, and see what is going on.

Another thing that came up: 

it would be nice if the expando model remembered (in-between steps) what was opened down. For a larger model like this, much of the exciting stuff is at deeper levels. And when I go back-and-forth between steps the stuff that I really want to see keeps disappearing.

[Murphy Randle]

Hi, Evan!

I just got the chance to try the debugger on my app for the first time. Thanks so much for doing all of this super cool work. It's very exciting!

I echo the feedback below about the importance of making the content of the app messages readable. Right now I've got to "inspect element" on the messages, and look at their HTML in order to see what values a message actually contains. And a resizable model view would be very nice as well.

Here's a hangup I had while getting going:

My project uses Webpack as a bundler, and I was calling `Elm.Main.embed(..)` to mount my application. It looks like `embed` has been entirely removed when --debug is enabled. I had to switch over to `Elm.Main.fullscreen` to make it work.

Is this because you don't want multiple instances of the debugger on the page if there are multiple Elm apps mounted? That might be a big bummer to those who are mounting Elm apps inside of their React components.

A feature idea:

I had to turn off elm-hot in order to get the debugger to work, as well. (Which makes sense, hot-swapping code could make the history inaccurate)

But it'd be incredibly neat to have some kind of webpack plugin that, when the Elm code is changed, automatically exports the history (to memory?), reloads the page, and imports the history again, so that I can keep working from the same point. Sometimes I'll be working on markup or styling somewhere deep in the app that's not content-addressable, and reloading to the same state would save a lot of time.

It's possible to do that manually right now by clicking export / import, but would be considerably more helpful during development if that could happen automatically.


Again, very cool! And thanks.

[Evan Czaplicki]

I just got the chance to try the debugger on my app for the first time. Thanks so much for doing all of this super cool work. It's very exciting!

Thanks for the feedback :)

I echo the feedback below about the importance of making the content of the app messages readable. Right now I've got to "inspect element" on the messages, and look at their HTML in order to see what values a message actually contains. And a resizable model view would be very nice as well.

I don't think this can be addressed before Monday. All debugger code lives in elm-lang/virtual-dom so it can be improved in a patch release of that package at any time.

Richard did a quick hack that kind of did something about this, but I think it's important to mock out an actual design and make sure it is nice. I do not want to do last minute UX changes without thinking it through carefully.

So I'd say, the way to make progress here is to think through the exact details of the design. Should it be about resizing the message sidebar? Or should it be about displaying messages on the right along with the model? Maybe the important information can be summarized more intelligently? Maybe all three! What are the benefits of each scenario? What would the UI look like in all these combinations?

I think the next step would be sharing screenshots of your exact experience. What's hard to see? What are you doing in general? From those basic facts, we can do a good design.

Here's a hangup I had while getting going:

My project uses Webpack as a bundler, and I was calling `Elm.Main.embed(..)` to mount my application. It looks like `embed` has been entirely removed when --debug is enabled. I had to switch over to `Elm.Main.fullscreen` to make it work.

Oh, I think that's just an oversight! I'll look today.

 

Is this because you don't want multiple instances of the debugger on the page if there are multiple Elm apps mounted? That might be a big bummer to those who are mounting Elm apps inside of their React components.

Nah, it's designed to work in a bunch of places.

 

A feature idea:

I had to turn off elm-hot in order to get the debugger to work, as well. (Which makes sense, hot-swapping code could make the history inaccurate)

But it'd be incredibly neat to have some kind of webpack plugin that, when the Elm code is changed, automatically exports the history (to memory?), reloads the page, and imports the history again, so that I can keep working from the same point. Sometimes I'll be working on markup or styling somewhere deep in the app that's not content-addressable, and reloading to the same state would save a lot of time.

It's possible to do that manually right now by clicking export / import, but would be considerably more helpful during development if that could happen automatically.

This is something I'd like to do through elm-reactor. It is possible to watch Elm and CSS files and load in the new code with the old history. I worked on getting it working, but it is quite tricky when you really get down to it. So I felt it was more important to get import/export out and unblock on a bunch of other stuff that is high priority for production folks. That would allow folks to try it out in practice and give a bunch of feedback that can all be incorporated in a holistic way.

Yosuke has a bunch of great ideas from elm-time-travel that I think it'd be amazing to bring into the official debugger (along with stuff like resizing and swapping) so I have reached out to him to coordinate on these kinds of things.

So I agree with all of this, but I also think it makes sense to bundle the work into patch releases.

 

Again, very cool! And thanks.

On Monday, October 17, 2016 at 12:26:12 PM UTC-6, Evan Czaplicki wrote:

So far no one has said anything about using the debugger. Does that mean everything is great and works on all platforms?

Can you share some experiences trying it out? Anything it makes sense to discuss?

For example, I'd like to make the following two improvements:

• Somewhere show the index of the message.
• Have the expando model deal with "line is too long" data more intelligently.

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/9109bb55-fee1-4aac-aa0c-e98b4c2457bd%40googlegroups.com.

[Evan Czaplicki]

Murphy, I just added the 'embed' option in --debug mode, so if you delete your elm-stuff/ and rebuild you should have it.

Can you confirm that it works alright?

[Murphy Randle]

Yes thanks, Evan. I’ll try it out right now!

And thanks for your well thought-out responses. I think your responses sound good, and I’m glad you’re concerned with getting the UX right before we get stuck with something undesirable.

You received this message because you are subscribed to a topic in the Google Groups "elm-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-dev/K1-P4I9TyBE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAF7GuPF_D5QYciRVq05FGe1W-7dC8NSO3DRwxqihS5Lxm%3DhNTw%40mail.gmail.com.

[Murphy Randle]

Yep! It’s working famously. Thanks for the quick response!

[Evan Czaplicki]

Great, thanks for trying it :)

And definitely share the message visibility issue in https://github.com/elm-lang/elm-reactor/issues I understand it, but I think it'll help to see it as well.

On Thu, Nov 10, 2016 at 3:23 PM, Murphy Randle <murphy...@gmail.com> wrote:

Yep! It’s working famously. Thanks for the quick response!

--

You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/582501384723670001553e96%40polymail.io.

[Murphy Randle]

Whoops! I made the issue on the virtual-dom package before coming back to this thread and seeing that you wanted it on elm-reactor, Evan.
Would you like me to move it?

https://github.com/elm-lang/virtual-dom/issues/49

On Thursday, November 10, 2016 at 5:13:37 PM UTC-7, Evan Czaplicki wrote:

Great, thanks for trying it :)

And definitely share the message visibility issue in https://github.com/elm-lang/elm-reactor/issues I understand it, but I think it'll help to see it as well.

On Thu, Nov 10, 2016 at 3:23 PM, Murphy Randle <murphy...@gmail.com> wrote:

Yep! It’s working famously. Thanks for the quick response!

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.

[Evan Czaplicki]

That's my mistake. Having it on virtual-dom is better!

To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/1b8f021f-704b-4783-b534-39342feefcf7%40googlegroups.com.