Re: [elixir-core:8777] Bisect tests question

Exactly. The normal workflow for using --bisect in RSpec is: - Your test suite is setup to run in random order, and prints out a seed on each run - If a test fails due to an ordering dependency for a particular ordering, you can reproduce it with `rspec --seed `. - However, this

Re: [elixir-core:8774] Bisect tests question

I authored the `--bisect` feature in RSpec. It's a useful and well-loved feature, but I don't think it is nearly as useful in Elixir. One of the big problems is ExUnit's async tests: bisection works well when your tests run sequentially, but as soon as you have any concurrency you've thrown

[elixir-core:7691] Re: [Proposal] Protected/Private modules

I'm in favor of this proposal. In fact, I proposed something similar awhile back: https://groups.google.com/d/msg/elixir-lang-core/X18SZnSDW7U/LZm8_8PYBQAJ On Tuesday, December 12, 2017 at 4:12:11 AM UTC-8, Wojtek Mach wrote: > > (I tried sending below message to the list but is still doesn't

Re: [elixir-core:7649] [Proposal] Make IEx autocomplete context-aware

Awesome :). On Mon, Dec 4, 2017 at 11:08 PM, José Valim wrote: > This is already in master! :) > -- > > > *José Valimwww.plataformatec.com.br > Founder and Director of R* > > -- > You received this message because you are subscribed to a

[elixir-core:7648] [Proposal] Make IEx autocomplete context-aware

IEx autocompletion is super useful, but it’s a bit unfortunate that when autocompleting something off of MyModule. it always autocompletes exported functions. Ideally, it would be aware of the IEx b and t helpers, so that if you typed t GenServer.ser it would autocomplete the GenServer.server

Re: [elixir-core:7630] Option to re-run only tests that failed last time?

unday, November 26, 2017 at 4:59:04 PM UTC-5, José Valim wrote: >> >>> Beautiful. >>> >>> Nathan, can you please open up an issue about supporting >>> --only-failures? Also, we would love if you could file a report with a >>> mechanism to reproduce

Re: [elixir-core:7625] Option to re-run only tests that failed last time?

does the job of identifying tests uniquely. > > > > *José Valimwww.plataformatec.com.br > <http://www.plataformatec.com.br/>Founder and Director of R* > > On Thu, Nov 23, 2017 at 7:14 PM, Myron Marston <myron.mars...@gmail.com> > wrote: > >> I think the firs

Re: [elixir-core:7622] Option to re-run only tests that failed last time?

t; > wrote: > >> +1 for --next-failure functionality. My current approach with ExUnit is >> basically a manual version of that. >> >> Allen Madsen >> http://www.allenmadsen.com >> >> On Thu, Nov 23, 2017 at 12:28 PM, Myron Marston <myron.mars...@gmail.com> >

Re: [elixir-core:7619] Option to re-run only tests that failed last time?

"--only failed" or "--only failures"? > > > > > *José Valimwww.plataformatec.com.br > <http://www.plataformatec.com.br/>Founder and Director of R* > > On Thu, Nov 23, 2017 at 6:03 AM, Myron Marston <myron.mars...@gmail.com> > wrote: >

Re: [elixir-core:7617] Option to re-run only tests that failed last time?

I too would love to see ExUnit support an `--only-failures` flag. It's one of my favorite features of RSpec and I wish every test framework had it. I find that it makes a huge difference to my workflow to be able to quickly and easily filter to the tests that failed the last time they ran.

Re: [elixir-core:7528] [Proposal] `IO.inspect_vars/1`

nder and Director of R* > > On Sat, Oct 14, 2017 at 5:44 AM, Myron Marston <myron.mars...@gmail.com> > wrote: > >> IO.inspect has long been my go-to technique for troubleshooting code >> that isn’t quite working how I would expect. Since the :label option was >&g

[elixir-core:7527] [Proposal] `IO.inspect_vars/1`

IO.inspect has long been my go-to technique for troubleshooting code that isn’t quite working how I would expect. Since the :label option was added in 1.4, I use that all the time, too. The majority of the time, I use it to inspect one or more variables like so: IO.inspect(foo, label:

Re: [elixir-core:7495] [Proposal] Strict form of `Map.new/2`

The input size is an enumerable and it is not guaranteed we can retrieve its size in constant time. The most common input is a list and it would require at least traversing the list one more time. Right, for Map.new/1, you’d have to traverse it one more time. But for Map.new/2, isn’t the

Re: [elixir-core:7492] [Proposal] Strict form of `Map.new/2`

It works that way on Erlang maps:from_list and also >> with for >> >> for n <- input, into: %{}, do: {n.name, n.age} >> >> >> 2017-10-03 23:23 GMT-04:00 Myron Marston <myron@gmail.com>: >> >>> Map.new/2 is quite useful and I

[elixir-core:7478] [Proposal] Strict form of `Map.new/2`

Map.new/2 is quite useful and I use it frequently. Whenever I use it, I expect that my transform function returns unique keys, so that Enum.count(input) == map_size(output) holds true. Unfortunately, this hasn’t always held true for the data I’m working with, and it results in an output map

Re: [elixir-core:7239] [Proposal] MapSet.intersection/1 (and perhaps MapSet.union/1)

t; I understand the convenience of a `MapSet.intersection/1` but there is > also `Enum.reduce/2`, which is very suitable for this use case - when the > accumulator is the same type as the elements of the enumerable and the > first element would become the accumulator. > > James > > On

[elixir-core:7238] [Proposal] MapSet.intersection/1 (and perhaps MapSet.union/1)

I have a list of MapSets, and I want to find the intersection of all of them. When I’ve wanted to find the union of a list of MapSets, it’s felt natural to use Enum.reduce: Enum.reduce(list_of_sets, MapSet.new, /2) To find the intersection of a list of MapSets, I wanted to use the same

Re: [elixir-core:7076] Re: Proposal: Enum.take/1

I don't think this would improve Elixir. Elixir favors explicitness over implicitness and fewer keystrokes and the only argument for this seems to be convenience. More worrying, `Enum.take/2` returns a list of items. If there was an `Enum.take/1`, I'd expect it to simply default the number

[elixir-core:6936] Re: Proposal

This is something I've asked for in the past[1] (albeit for different reason at the time). While not directly, supported, there's a fairly simple way to add a `mix test_all` task that does what you want. [2] José said he might be more open to it being built-in in the future, so it's nice to

[elixir-core:6935] Re: Proposal: Streamlining child specs

I definitely like this proposal overall. There are some nuances I don't understand yet, but it sounds like y'all are asking the right questions. In our code base we've already been defined a function like `child_spec` a few times for this exact purpose, so it neatly aligns with how I'd like to

Re: [elixir-core:6735] Do Elixir typespecs allow multiple clauses like Erlang's do?

:56:17 +0100 > Michał Muskała <mic...@muskala.eu > wrote: > > > As far as I know it should "just work™". > > > > Michał. > > > > > On 11 Dec 2016, at 21:11, Myron Marston <myron@gmail.com > > wrote: > > > > > > T

[elixir-core:6732] Do Elixir typespecs allow multiple clauses like Erlang's do?

Today I was reading through http://learnyousomeerlang.com/dialyzer and stumbled across this: -spec convert(tuple()) -> list(); (list()) -> tuple().convert(Tup) when is_tuple(Tup) -> tuple_to_list(Tup);convert(L = [_|_]) -> list_to_tuple(L). Rather than putting tuple() and list() types

Re: [elixir-core:6705] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

Personally, I've been gravitating toward the explicitness of `fun_call()` over `fun_call`, but have been on the fence about the warning. Something occurred to me while reading this conversation, though: I think this change means that *any* attempted shadowing in Elixir will yield a warning or

[elixir-core:6616] [Proposal] Improve IEx autocompletion to support atom map keys

IEx autocompletion is really nice, but I think there are some features missing to really make it shine. In particular, I wish it supported autocompletion of struct fields (or really, atom keys in any map). For example, in a case like: ``` iex> map = %{foo: 23, bar: 14} iex> map.f ``` ...I'd

[elixir-core:6449] Proposal: make module of Logger callsite available in Logger metadata

On the main Elixir project I work on, I’ve found that the log messages we naturally write tend to lack sufficient context to identify where in the application the message comes from. For example: Logger.warn("Extra metadata lines found while only expecting one: #{inspect rest}") In the

Re: [elixir-core:6119] Proposal: `delete_at/2` and `delete_at/1`

Thanks. I still kinda wish there was `delete_at/2` but I completely understand your reasoning. On Fri, Jul 15, 2016 at 2:34 PM, José Valim wrote: > You can get the second element of the tuple: > > %{users: [%{name: "John", age: 27}, %{name: "Betty", age: 40}]}

Re: [elixir-core:6117] Proposal: `delete_at/2` and `delete_at/1`

gt; > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R > > On Fri, Jul 15, 2016 at 10:16 PM, Myron Marston <myron.mars...@gmail.com> > wrote: > >> Currently, Elixir provides a number of functions that make working

Re: [elixir-core:5897] Elixir v1.3.0-rc.0 released

n able to figure out what the flag is. Anyone have a suggestion? Thanks, Myron On Thu, Jun 2, 2016 at 8:30 AM, Eric Meadows-Jönsson < eric.meadows.jons...@gmail.com> wrote: > It should be available now. > > On Wednesday, 1 June 2016, Myron Marston <myron.mars...@gmail.com>

[elixir-core:5892] Re: Elixir v1.3.0-rc.0 released

The new 1.3 features look really great! Any idea when 1.3.0-rc.0 will be available on hex so it can be used on travis? On Monday, May 30, 2016 at 6:41:32 AM UTC-7, José Valim wrote: > > Hello everyone, > > We are glad to announce our first release candidate for Elixir v1.3.0. > This release

Re: [elixir-core:5699] `try/after` does not provide the guarantees it is documented as providing

ter ExUnit.Callbacks.on_exit(ref, fn -> :ok end) unquote(cleanup_logic) end endend Myron ​ On Mon, May 9, 2016 at 9:32 PM, Myron Marston <myron.mars...@gmail.com> wrote: > Thanks for answering my questions! > > I'll open up a PR to improve the docs. > >

Re: [elixir-core:5699] `try/after` does not provide the guarantees it is documented as providing

separate > process that monitors and executes the clean up. Plug.Upload is such an > example. For tests, there is the on_exit callback (and that's also why we > don't have tear down). > > On Monday, May 9, 2016, Myron Marston <myron@gmail.com > > wrote: > >> T

Re: [elixir-core:5683] Re: Proposal: always expose ExUnit.configuration[:seed]

The point I need it is in a certain test, long after the suite has started. The work around I talked about in `test_helper.exs` was just a way to ensure it was set. Also, is there a reason `seed` couldn't be generated and assigned after processing CLI args (at which point ExUnit should be able