As other input options will appear, you might want to change radio button by select if it is within the design proposal, it would look like this:

https://user-images.githubusercontent.com/30236552/122628286-a7d94e00-d08b-11eb-8b72-3636f4758ac7.mp4

I started to think of a way to add the textarea I managed to get a result but I don't know if it is the path they would like to follow.

When I add the textarea to get for line breaks I only stop at the last occurrence of \n but this breaks the input test.

Is allowing line breaks in an input really a problem? if yes, how can we get around ?

to IO.gets work with textarea I made the adjustment below in the file io_proxy.ex

  defp line_from_input(input) do
    case :binary.match(input, ["\r\n", "\n"]) do
      :nomatch ->
        {input, ""}

      {pos, len} ->
        size = byte_size(input)
        line = binary_part(input, 0, pos + len)
        rest = binary_part(input, pos + len, size - pos - len)

        {line_tail, rest_tail} = line_from_input(rest)
        {line <> line_tail, rest_tail}

    end
  end

My reason to chose a keyword list over a map is the fact that the user inputs a keyword list when creating a Ecto.Enum field, so it seemed consistent returning the exact same thing the user inputted. Yet, as you pointed out, this didn't reflect the exact mappings that are done on on_dump and on_load (these are maps, and the last one would take precedence). I opened another PR that prevents the user from inputting keyword lists with duplicate keys.

Duplicate values make so that only the last of the duplicates is taken into account, due to the fact that the keyword list is cast into a map for the on_load and on_dump values. With this commit we can avoid this scenario in compile time.

Pointed out by @wojtekmach on #3676

For those tracking this issue, #423 uses a new version of TensorFlow which should support Mac ARM. I believe you might need Bazel 4.1. If anybody would like to take a shot at building off of that branch, that would be really appreciated

The return value here is a 5 element tuple, rather than the 4 element tuple declared in the typespec:

https://github.com/elixir-ecto/db_connection/blob/master/lib/db_connection/holder.ex#L57

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

Hi all!

We are migrating our app to LiveView but the process is so slow we are embedding new features done in LiveView through cross-domain iframes.

Live reload uses an iframe too so I have an iframe inside an iframe inside a page. Both iframes share domain but the domain in the main window is different. Indeed, the iframe sends messages to the parent via postMessage.

When live reload tries to reload my iframe it uses window.top.location.reload which produces a security error because the browser doesn't allow that.

Shouldn't it try to reload via window.parent.location.reload? That should be always be allowed by the browser because there's no domain problem.

Thanks for your time.

Given that the pull request has been merged I think this can be closed… Thanks!

WIP

This is an attempt to resolve #174. I've implemented vmap in basically the same style as grad except it supports multiple vectorized arguments. We don't include out_axes like Jax, but that's easy to add either with an additional transpose or to propagate during the expression transformation.

There are still a lot of checks and validations that need to be done:

• Normalize in axes
• Do we support multiple in axes?
• What constraints should be placed on in axes?

I wanted to open this to collect feedback on the foundation before moving forward with implementing some additional batch rules. Based on this PR, we'd then have to revisit some Nx implementations to support batching. Off the top of my head I believe most of the LinAlg operators will need to support batched matrix operations.

I think we can also discuss the possibility of implementing automatic vectorization based on input names (e.g. :batch name is always treated as a batch dimension).

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

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.

This is a simple example showing how we can use Infeeds to stream data to a function at run time and how we can use Outfeeds receive data from a function at run time.

Next steps would be an Infeed Pool and an Outfeed Receiver from EXLA.

Updates EXLA Dockerfiles to use OTP24 with @wojtekmach beamup.

Also adds Livebook

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.

The issue is somewhere in pad. Two tests that fail (they raise, no result is returned):

test "window max f64" do
  t = Nx.iota({3, 3}, type: {:f, 64})
  assert Nx.window_max(t, {2, 1}) == Nx.tensor([[3, 4, 5], [6, 7, 8]], type: {:f, 64})
end

test "window min f64" do
  t = Nx.iota({3, 3}, type: {:f, 64})
  assert Nx.window_min(t, {2, 1}) == Nx.tensor([[0.0, 1.0, 2.0], [3.0, 4.0, 5.0]], type: {:f, 64})
end

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