Re: [elm-discuss] Re: Elm Textfield + a barcode scanner

[Rehno Lindeque]

In https://runelm.io/c/nx0 it looks like the trouble is that it is using 
value attribute no? Just to check, have you tried the defaultValue approach 
suggested? At least, in the example it doesn't look like value needs to be 
set at all.

My understanding is that two-way binding is problematic (there's some kind 
of race with the internal state of the control).

PS I think it would be interesting for someone to create a pure div control 
for text input some time (but that definitely way more challenging than it 
sounds).


-- 
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 Textfield + a barcode scanner

[Witold Szczerba]

You are so right. I have no idea how is this system supposed to work.

04.05.2017 07:09 "Matthias Winkelmann"  napisał(a):

> I have to say, the way issues are managed in the elm ecosystem has
> frequently left me stumped because i couldn’t find the relevant issue. This
> problem was reported at least twice, in https://github.com/elm-
> lang/elm-compiler/issues/727 and https://github.com/elm-
> lang/elm-compiler/issues/835. Those two threads were closed with a
> reference to https://github.com/elm-lang/core/issues/332, which is an
> aggregation of 20+ tickets. That, in turn, was closed without any further
> activity a year later–with yet another reference to
> https://github.com/evancz/elm-graphics/issues/4, at which point the
> ticket no longer has anything to do with the original issues.
>
> Most of these meta-tickets also discourage comments, asking people to open
> new issues for those. If people do so, chances are low they’ll manage to
> mention all the relevant tickets, so nobody would ever have a chance to
> find that information.
>
> Every other project simply has a ticket per problem. Duplicates get closed
> with a reference. Issues that can’t be reproduced get closed. Comments
> often contain useful workarounds, or partial fixes slowly building to a
> resolution.
>
> I can imagine that a three-digit number of open issues feels daunting, but
> I have never looked at a project on github with 1000+ open issues and
> thought worse of the maintainers. Almost universally, the number of issues
> is proportional to interest in the project (see tensorflow or Visual Studio
> Code).
>
>
> On 4 May 2017 at 01:04:40, Witold Szczerba (witoldsz@gmail.com) wrote:
>
> Here it is:
> https://github.com/witoldsz/elm-webdriver-problem
>
> And the Reddit topic:
> https://www.reddit.com/r/elm/comments/693v43/elmwebdriverproblem/
>
> I hope it will draw a little bit more attention to the issue.
>
> On Sun, Apr 30, 2017 at 2:36 AM, Witold Szczerba 
> wrote:
>
>> My issue was with regular input type=text fields.
>> I will try to find some time to create a project reproducing the issue.
>>
>> On Sun, Apr 30, 2017 at 12:57 AM, Noah Hall  wrote:
>>
>>> A known issue: https://github.com/elm-lang/html/issues/55
>>>
>>> The issue is elm-compiler was likely closed due to the fact that it is
>>> not a compiler problem, it is a web-browser problem.
>>>
>>> `defaultValue` is the recommended approach
>>>
>>> On Sun, Apr 30, 2017 at 12:52 AM, Francesco Orsenigo
>>>  wrote:
>>> > Witold, could you put together a minimal Elm app + Selenium script that
>>> > reproduces the problem?
>>> > This might be a significant issue, since it would impact the
>>> possibility to
>>> > end-to-end test Elm apps.
>>> >
>>> > On Sun, Apr 30, 2017 at 8:28 AM, Witold Szczerba <
>>> witoldsz@gmail.com>
>>> > wrote:
>>> >>
>>> >> This was my case with Selenium WebDriver and Chrome. The end-to-end
>>> tests
>>> >> of my Elm application are failing because of this.
>>> >> It was reported back in 2014:
>>> >> https://github.com/elm-lang/elm-compiler/issues/835
>>> >> The issue is closed, but the bug is still present.
>>> >>
>>> >> You want to know my workaround? It "just-works" on Firefox, so this
>>> is the
>>> >> browser I use for e2e tests…
>>> >>
>>> >> On Sat, Apr 29, 2017 at 11:57 PM, Francesco Orsenigo
>>> >>  wrote:
>>> >>>
>>> >>> This is an interesting problem and I wonder if it would happen also
>>> with
>>> >>> some other form of automated input (say, selenium).
>>> >>>
>>> >>> It might very well be a problem with Elm.
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken
>>> >>> wrote:
>>> 
>>>  I'm using a barcode scanner to enter data into an elm textfield.
>>> The
>>>  barcode scanner basically works like a keyboard with a user that
>>> makes very
>>>  rapid keystrokes.  This rapid entry causes random characters to be
>>> missing
>>>  in the textfield.  If the scan is supposed to enter "50494'', one
>>> or more of
>>>  these characters will often be missing.  Using the debugger I see
>>> that my
>>>  model has values for that field that change from "5" to "50" to
>>> "504" to
>>>  "509" to "5094", but it should be "5" to "50" to "504" to "5049" to
>>> "50494"
>>>  So it ends up replacing "504" with "509" instead of with "5049".  I
>>> believe
>>>  this is a threading issue where two events are firing in parallel
>>> instead of
>>>  in sequence, and both events are starting with the same model data
>>> ("50")
>>>  with the output of one event replacing the output of the other,
>>> when instead
>>>  the output model for one event should be the input for the next
>>> event.  Is
>>>  this a bug in Elm?  How do I fix this?
>>> 
>>>  Thanks,
>>>  Chris
>>> >>>
>>> >>> --
>>> >>> You received this message 

Re: [elm-discuss] Re: Elm Textfield + a barcode scanner

[Matthias Winkelmann]

I have to say, the way issues are managed in the elm ecosystem has frequently 
left me stumped because i couldn’t find the relevant issue. This problem was 
reported at least twice, in https://github.com/elm-lang/elm-compiler/issues/727 
and https://github.com/elm-lang/elm-compiler/issues/835. Those two threads were 
closed with a reference to https://github.com/elm-lang/core/issues/332, which 
is an aggregation of 20+ tickets. That, in turn, was closed without any further 
activity a year later–with yet another reference to 
https://github.com/evancz/elm-graphics/issues/4, at which point the ticket no 
longer has anything to do with the original issues.

Most of these meta-tickets also discourage comments, asking people to open new 
issues for those. If people do so, chances are low they’ll manage to mention 
all the relevant tickets, so nobody would ever have a chance to find that 
information. 

Every other project simply has a ticket per problem. Duplicates get closed with 
a reference. Issues that can’t be reproduced get closed. Comments often contain 
useful workarounds, or partial fixes slowly building to a resolution. 

I can imagine that a three-digit number of open issues feels daunting, but I 
have never looked at a project on github with 1000+ open issues and thought 
worse of the maintainers. Almost universally, the number of issues is 
proportional to interest in the project (see tensorflow or Visual Studio Code). 


On 4 May 2017 at 01:04:40, Witold Szczerba (witoldsz@gmail.com) wrote:

Here it is:
https://github.com/witoldsz/elm-webdriver-problem

And the Reddit topic:
https://www.reddit.com/r/elm/comments/693v43/elmwebdriverproblem/

I hope it will draw a little bit more attention to the issue.

On Sun, Apr 30, 2017 at 2:36 AM, Witold Szczerba  wrote:
My issue was with regular input type=text fields.
I will try to find some time to create a project reproducing the issue.

On Sun, Apr 30, 2017 at 12:57 AM, Noah Hall  wrote:
A known issue: https://github.com/elm-lang/html/issues/55

The issue is elm-compiler was likely closed due to the fact that it is
not a compiler problem, it is a web-browser problem.

`defaultValue` is the recommended approach

On Sun, Apr 30, 2017 at 12:52 AM, Francesco Orsenigo
 wrote:
> Witold, could you put together a minimal Elm app + Selenium script that
> reproduces the problem?
> This might be a significant issue, since it would impact the possibility to
> end-to-end test Elm apps.
>
> On Sun, Apr 30, 2017 at 8:28 AM, Witold Szczerba 
> wrote:
>>
>> This was my case with Selenium WebDriver and Chrome. The end-to-end tests
>> of my Elm application are failing because of this.
>> It was reported back in 2014:
>> https://github.com/elm-lang/elm-compiler/issues/835
>> The issue is closed, but the bug is still present.
>>
>> You want to know my workaround? It "just-works" on Firefox, so this is the
>> browser I use for e2e tests…
>>
>> On Sat, Apr 29, 2017 at 11:57 PM, Francesco Orsenigo
>>  wrote:
>>>
>>> This is an interesting problem and I wonder if it would happen also with
>>> some other form of automated input (say, selenium).
>>>
>>> It might very well be a problem with Elm.
>>>
>>>
>>>
>>> On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken
>>> wrote:

 I'm using a barcode scanner to enter data into an elm textfield.  The
 barcode scanner basically works like a keyboard with a user that makes very
 rapid keystrokes.  This rapid entry causes random characters to be missing
 in the textfield.  If the scan is supposed to enter "50494'', one or more 
 of
 these characters will often be missing.  Using the debugger I see that my
 model has values for that field that change from "5" to "50" to "504" to
 "509" to "5094", but it should be "5" to "50" to "504" to "5049" to "50494"
 So it ends up replacing "504" with "509" instead of with "5049".  I believe
 this is a threading issue where two events are firing in parallel instead 
 of
 in sequence, and both events are starting with the same model data ("50")
 with the output of one event replacing the output of the other, when 
 instead
 the output model for one event should be the input for the next event.  Is
 this a bug in Elm?  How do I fix this?

 Thanks,
 Chris
>>>
>>> --
>>> 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
>> 

Re: [elm-discuss] Re: Elm Textfield + a barcode scanner

[Witold Szczerba]

Here it is:
https://github.com/witoldsz/elm-webdriver-problem

And the Reddit topic:
https://www.reddit.com/r/elm/comments/693v43/elmwebdriverproblem/

I hope it will draw a little bit more attention to the issue.

On Sun, Apr 30, 2017 at 2:36 AM, Witold Szczerba 
wrote:

> My issue was with regular input type=text fields.
> I will try to find some time to create a project reproducing the issue.
>
> On Sun, Apr 30, 2017 at 12:57 AM, Noah Hall  wrote:
>
>> A known issue: https://github.com/elm-lang/html/issues/55
>>
>> The issue is elm-compiler was likely closed due to the fact that it is
>> not a compiler problem, it is a web-browser problem.
>>
>> `defaultValue` is the recommended approach
>>
>> On Sun, Apr 30, 2017 at 12:52 AM, Francesco Orsenigo
>>  wrote:
>> > Witold, could you put together a minimal Elm app + Selenium script that
>> > reproduces the problem?
>> > This might be a significant issue, since it would impact the
>> possibility to
>> > end-to-end test Elm apps.
>> >
>> > On Sun, Apr 30, 2017 at 8:28 AM, Witold Szczerba <
>> witoldsz@gmail.com>
>> > wrote:
>> >>
>> >> This was my case with Selenium WebDriver and Chrome. The end-to-end
>> tests
>> >> of my Elm application are failing because of this.
>> >> It was reported back in 2014:
>> >> https://github.com/elm-lang/elm-compiler/issues/835
>> >> The issue is closed, but the bug is still present.
>> >>
>> >> You want to know my workaround? It "just-works" on Firefox, so this is
>> the
>> >> browser I use for e2e tests…
>> >>
>> >> On Sat, Apr 29, 2017 at 11:57 PM, Francesco Orsenigo
>> >>  wrote:
>> >>>
>> >>> This is an interesting problem and I wonder if it would happen also
>> with
>> >>> some other form of automated input (say, selenium).
>> >>>
>> >>> It might very well be a problem with Elm.
>> >>>
>> >>>
>> >>>
>> >>> On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken
>> >>> wrote:
>> 
>>  I'm using a barcode scanner to enter data into an elm textfield.  The
>>  barcode scanner basically works like a keyboard with a user that
>> makes very
>>  rapid keystrokes.  This rapid entry causes random characters to be
>> missing
>>  in the textfield.  If the scan is supposed to enter "50494'', one or
>> more of
>>  these characters will often be missing.  Using the debugger I see
>> that my
>>  model has values for that field that change from "5" to "50" to
>> "504" to
>>  "509" to "5094", but it should be "5" to "50" to "504" to "5049" to
>> "50494"
>>  So it ends up replacing "504" with "509" instead of with "5049".  I
>> believe
>>  this is a threading issue where two events are firing in parallel
>> instead of
>>  in sequence, and both events are starting with the same model data
>> ("50")
>>  with the output of one event replacing the output of the other, when
>> instead
>>  the output model for one event should be the input for the next
>> event.  Is
>>  this a bug in Elm?  How do I fix this?
>> 
>>  Thanks,
>>  Chris
>> >>>
>> >>> --
>> >>> 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/Oy35n_BHUGM/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.
>>
>
>

-- 
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 Textfield + a barcode scanner

[Francesco Orsenigo]

Witold, could you put together a minimal Elm app + Selenium script that
reproduces the problem?
This might be a significant issue, since it would impact the possibility to
end-to-end test Elm apps.

On Sun, Apr 30, 2017 at 8:28 AM, Witold Szczerba 
wrote:

> This was my case with Selenium WebDriver and Chrome. The end-to-end tests
> of my Elm application are failing because of this.
> It was reported back in 2014: https://github.com/elm-
> lang/elm-compiler/issues/835
> The issue is closed, but the bug is still present.
>
> You want to know my workaround? It "just-works" on Firefox, so this is the
> browser I use for e2e tests…
>
> On Sat, Apr 29, 2017 at 11:57 PM, Francesco Orsenigo <
> francesco.orsen...@gmail.com> wrote:
>
>> This is an interesting problem and I wonder if it would happen also with
>> some other form of automated input (say, selenium).
>>
>> It might very well be a problem with Elm.
>>
>>
>>
>> On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken
>> wrote:
>>>
>>> I'm using a barcode scanner to enter data into an elm textfield.  The
>>> barcode scanner basically works like a keyboard with a user that makes very
>>> rapid keystrokes.  This rapid entry causes random characters to be missing
>>> in the textfield.  If the scan is supposed to enter "50494'', one or more
>>> of these characters will often be missing.  Using the debugger I see that
>>> my model has values for that field that change from "5" to "50" to "504" to
>>> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to
>>> "50494"  So it ends up replacing "504" with "509" instead of with "5049".
>>> I believe this is a threading issue where two events are firing in parallel
>>> instead of in sequence, and both events are starting with the same model
>>> data ("50") with the output of one event replacing the output of the other,
>>> when instead the output model for one event should be the input for the
>>> next event.  Is this a bug in Elm?  How do I fix this?
>>>
>>> Thanks,
>>> Chris
>>>
>> --
>> 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/Oy35n_BHUGM/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.

[elm-discuss] Re: Elm Textfield + a barcode scanner

[Francesco Orsenigo]

This is an interesting problem and I wonder if it would happen also with 
some other form of automated input (say, selenium).

It might very well be a problem with Elm.



On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken wrote:
>
> I'm using a barcode scanner to enter data into an elm textfield.  The 
> barcode scanner basically works like a keyboard with a user that makes very 
> rapid keystrokes.  This rapid entry causes random characters to be missing 
> in the textfield.  If the scan is supposed to enter "50494'', one or more 
> of these characters will often be missing.  Using the debugger I see that 
> my model has values for that field that change from "5" to "50" to "504" to 
> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to 
> "50494"  So it ends up replacing "504" with "509" instead of with "5049". 
>  I believe this is a threading issue where two events are firing in 
> parallel instead of in sequence, and both events are starting with the same 
> model data ("50") with the output of one event replacing the output of the 
> other, when instead the output model for one event should be the input for 
> the next event.  Is this a bug in Elm?  How do I fix this?
>
> Thanks,
> Chris
>

-- 
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 Textfield + a barcode scanner

[Bernardo]

You should definitely try with onchange. But without using oninput because 
otherwise the field is updated from the model. If you update the model 
after the field changes there shouldn't be any difference from using a 
plain html input.

On Friday, 28 April 2017 13:47:35 UTC-3, Chris Van Vranken wrote:
>
> I'm using the oninput event, the onchange event occurs when the element 
> loses focus.  The contents of the textbox are wrong before the onchange 
> event even fires, so I don't believe the onchange event will be helpful for 
> solving this.  I think maybe I need to prevent elm from modifying the value 
> of the textbox and then read in the final value when the scanner sends the 
> enter key, which it does every time it finishes scanning the barcode.
>
> On Friday, April 28, 2017 at 11:06:03 AM UTC-4, Simon wrote:
>>
>> not sure whether this is relevant but can you take advantage of the 
>> difference between the `oninput` and `onchange` events in a text field?
>>
>>
>> On Friday, 28 April 2017 07:51:48 UTC-7, Chris Van Vranken wrote:
>>>
>>> I'm using a barcode scanner to enter data into an elm textfield.  The 
>>> barcode scanner basically works like a keyboard with a user that makes very 
>>> rapid keystrokes.  This rapid entry causes random characters to be missing 
>>> in the textfield.  If the scan is supposed to enter "50494'', one or more 
>>> of these characters will often be missing.  Using the debugger I see that 
>>> my model has values for that field that change from "5" to "50" to "504" to 
>>> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to 
>>> "50494"  So it ends up replacing "504" with "509" instead of with "5049". 
>>>  I believe this is a threading issue where two events are firing in 
>>> parallel instead of in sequence, and both events are starting with the same 
>>> model data ("50") with the output of one event replacing the output of the 
>>> other, when instead the output model for one event should be the input for 
>>> the next event.  Is this a bug in Elm?  How do I fix this?
>>>
>>> Thanks,
>>> Chris
>>>
>>

-- 
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 Textfield + a barcode scanner

[Chris Van Vranken]

I'm using the oninput event, the onchange event occurs when the element 
loses focus.  The contents of the textbox are wrong before the onchange 
event even fires, so I don't believe the onchange event will be helpful for 
solving this.  I think maybe I need to prevent elm from modifying the value 
of the textbox and then read in the final value when the scanner sends the 
enter key, which it does every time it finishes scanning the barcode.

On Friday, April 28, 2017 at 11:06:03 AM UTC-4, Simon wrote:
>
> not sure whether this is relevant but can you take advantage of the 
> difference between the `oninput` and `onchange` events in a text field?
>
>
> On Friday, 28 April 2017 07:51:48 UTC-7, Chris Van Vranken wrote:
>>
>> I'm using a barcode scanner to enter data into an elm textfield.  The 
>> barcode scanner basically works like a keyboard with a user that makes very 
>> rapid keystrokes.  This rapid entry causes random characters to be missing 
>> in the textfield.  If the scan is supposed to enter "50494'', one or more 
>> of these characters will often be missing.  Using the debugger I see that 
>> my model has values for that field that change from "5" to "50" to "504" to 
>> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to 
>> "50494"  So it ends up replacing "504" with "509" instead of with "5049". 
>>  I believe this is a threading issue where two events are firing in 
>> parallel instead of in sequence, and both events are starting with the same 
>> model data ("50") with the output of one event replacing the output of the 
>> other, when instead the output model for one event should be the input for 
>> the next event.  Is this a bug in Elm?  How do I fix this?
>>
>> Thanks,
>> Chris
>>
>

-- 
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 Textfield + a barcode scanner

[Simon]

not sure whether this is relevant but can you take advantage of the 
difference between the `oninput` and `onchange` events in a text field?


On Friday, 28 April 2017 07:51:48 UTC-7, Chris Van Vranken wrote:
>
> I'm using a barcode scanner to enter data into an elm textfield.  The 
> barcode scanner basically works like a keyboard with a user that makes very 
> rapid keystrokes.  This rapid entry causes random characters to be missing 
> in the textfield.  If the scan is supposed to enter "50494'', one or more 
> of these characters will often be missing.  Using the debugger I see that 
> my model has values for that field that change from "5" to "50" to "504" to 
> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to 
> "50494"  So it ends up replacing "504" with "509" instead of with "5049". 
>  I believe this is a threading issue where two events are firing in 
> parallel instead of in sequence, and both events are starting with the same 
> model data ("50") with the output of one event replacing the output of the 
> other, when instead the output model for one event should be the input for 
> the next event.  Is this a bug in Elm?  How do I fix this?
>
> Thanks,
> Chris
>

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