Note that this feature depends on the foundation of #319 anyway, because we need to track which inputs need to be reevalauted.

I think we can support enter none the less for single line inputs and perhaps Cmd+Enter for text areas. That's common to most forms.

Ah, I think we should pass the evaluation_time_ms as the third argument, rather than the whole @cell_view, so that LV doesn't need to re-render this part when an irrelevant part of @cell_view changes.

I think "as we type" inputs would itself address this, as the user won't need any additional action. As for Enter, it's specific to single line inputs, and could be confusing once we add textarea, but that's something we can consider yeah. As for blur, the more I think about blur the less intuitive this feels and we may as well press reevaluate, because we already have to click somewhere outside the input

I actually like this a lot. @jonatanklosko maybe this can be a good alternative to "as we type" reactive inputs... if we have this, it may be fine to have reactive inputs only on blur?

Environment

• Elixir & Erlang/OTP versions (elixir --version): Elixir 1.12 on Erlang 24.0.2
• Operating system: macOS
• How have you started Livebook (mix phx.server, livebook CLI, Docker, etc): livebook server
• Livebook version (use git show if running with mix): 0.1.2
• Browsers that reproduce this bug (the more the merrier): Chrome

Current behavior

(not a bug but potential UX improvement) When I press ENTER on an input field nothing happens.

Expected behavior

When I press ENTER on an input field, the associated + Elixir bit would re-evaluate. (think of a person so lazy, they try to use the mouse/trackpad/whateverpad as little as possible).

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

Precisely, thanks @thiamsantos and @JEG2!

I think it is the same error reported at https://github.com/elixir-lang/elixir/issues/11014. It seems to be already fixed in OTP https://github.com/erlang/otp/commit/c1942e39d44d50bb4bdf8e22456f31ee23931fdb.

Environment

• Elixir & Erlang/OTP versions (elixir --version):

Erlang/OTP 24 [erts-12.0.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit]

Elixir 1.12.1 (compiled with Erlang/OTP 22)

• Operating system: macOS Big Sur 11.2.3

Current behavior

iex(1)> String.to_existing_atom("valid_utf8")
** (ArgumentError) errors were found at the given arguments:

  * 1st argument: invalid UTF8 encoding

    :erlang.binary_to_existing_atom("valid_utf8", :utf8)

The error is a lie. It's valid UTF-8, it just doesn't exist as an atom.

Expected behavior

It would be great if it could tell us the atom doesn't exist. If that's not possible though, we should at least stop giving an incorrect reason.

Call mix release.init and configure the vm.args file.

Closes #368.

In the container:

/data # cat /app/releases/0.2.0/vm.args 
# Disable busy waiting, so that we don't waste
# resources when running in the cloud
+sbwt none +sbwtdcpu none +sbwtdio none

Hi André. Thanks for sharing this wonderful example.

I wanted to ask your opinion on one thing.

https://github.com/andreschaffer/event-sourcing-cqrs-examples/blob/1b47ccb25791213ba0a4195d7443f59b663bd0e8/src/main/java/bankservice/service/account/AccountService.java#L70-L73

This stores the event first in the event store (which I assume is the single source of truth), and publish the event through the event bus. But if you try to scale and there are multiple instances of the application (assume now we have an external event store and and external event bus, say mongodb and kafka perhaps) each trying to store and then publish events, would that not mess up the ordering of the events?

For example say there is a race between AccountDepositedEvent D and AccountWithdrawnEvent W. What could happen is that in the event store you have D stored before W, but have D published after W through the event bus. Then application states restored through replaying event processing would not be the same as the original.

What would be your approach to solve this problem?

Closes #368.

In the container:

/data # cat /app/releases/0.2.0/vm.args 
# Disable busy waiting, so that we don't waste
# resources when running in the cloud
+sbwt none +sbwtdcpu none +sbwtdio none

I believe a number of test would fail after changing the response format, looking for{:evaluation_response should be enough to find all the relevant places :)

        "#{seconds}s"

I'd set the time in finish_cell_evaluation, as that's the directly related action operation :)

That's not how the JS event works, unless we want to implement our own double click.

that’s enough to abort mission for me :)

Environment

• How have you started Livebook (mix phx.server, livebook CLI, Docker, etc): mix phx.server
• Livebook version (use git show if running with mix): master

Current behavior

Currently it requires two clicks: first on the filename itself, and second on "Open":

The benefit of the current design is we have ability to "Fork" the notebook here, but given we have such capability from the notebook itself too:

I'd consider removing the intermediate step from the file browser.

The filesystem browser shows files that cannot be opened in a "greyed" out format, that makes it clear they can't be clicked/selected. Could that help?

The point is that they can be clicked to select the file and we shouldn't discourage this with a disabled-like color.

And if we double-click something, the regular click should not activate, yet.

That's not how the JS event works, unless we want to implement our own double click.

dblclick fires after two click events (and by extension, after two pairs of mousedown and mouseup events).

Yeah, that's a good point. The filesystem browser shows files that cannot be opened in a "greyed" out format, that makes it clear they can't be clicked/selected. Could that help?

And if we double-click something, the regular click should not activate, yet.

Hmm, actually in our case we would need to only make the matching files double clickable, which doesn't feel consistent, at may actually give user the impression that they can double click anything:

https://user-images.githubusercontent.com/17034772/122575639-3ed4e480-d051-11eb-9ebb-131a2baa2a9e.mp4