The second part is: https://github.com/elixir-lang/elixir/pull/9427
The PRs together should make it possible everything proposed in this
thread, but in a generic way so it also works with Decimal and other
comparison algorithms.
--
You received this message because you are subscribed to the
I’m +1 too. And I can’t think of a better name, since there is already a
`Enum.reverse` and a `Enum.sort`, that would be a pretty clear name IMO.
Best,
Kelvin Stinghen
kelvin.sting...@me.com
> On Oct 17, 2019, at 19:44, OvermindDL1 wrote:
>
> I've wanted such a function a few times because
Hello
for me, the current sort function seems very clear: in the resulting
enumeration, the predicate will be true for any two adjacent elements.
iex(14)> 1..10 |> Enum.to_list
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
iex(15)> Enum.sort(1..10, &>=/2)
[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
iex(16)> 10..1 |>
Hello
for me, the current sort function seems very clear: in the resulting
enumeration, the predicate will be true for any two adjacent elements.
iex(14)> 1..10 |> Enum.to_list
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
iex(15)> Enum.sort(1..10, &>=/2)
[10, 9, 8, 7, 6, 5, 4, 3, 2, 1]
iex(16)> 10..1 |>
+1 from me for `IEx.Helpers.time`. It doesn't solve the „oh I wish I timed this
command” problem, but I think its useful on its own, and personally I'd much
rather have just this.
I suggested something somewhat similiar with additional timing information in a
`Kernel.dbg` macro proposal. One
Let's go easy. :) Showing the timer as it does adds a bunch of complexity.
Showing it on the right also means we need to integrate with the inspect
algorithm to make sure they do not overlap. All of those are added
complexity. For now, we will only show a message at the end when above a
threshold
I think displaying the running time to the right of the result would be
ideal.
The user will not think it is program output, since it is to the right and
on the same line as the result.
iex(14)> :timer.sleep(4000)
:ok 4.000s
Here is a proposal I am satisfied with:
https://github.com/elixir-lang/elixir/pull/9426
It solves sorting but it doesn't solve getting the earliest/latest. There
will be another PR to address those. The idea is to provide a general
framework to address these limitations, as it will also be useful
+1 on this nice proposal.
terça-feira, 6 de Agosto de 2019 às 23:51:17 UTC+1, Exempll escreveu:
>
>
> This would be a neat detail. It is easy to forget to time a long-running
> function, and sometimes, when you are surprised by the running time, you
> want to know how long it ran for in
> But even that can have other consequences. For example, what is the
> precedence for <-? Does it work nicely with “and” and “or” and other logical
> operators?
>
> So there is a lot of complexity involved! I was not trying to be harsh. :D
> Almost anything you may want to do may impact others
Frequencies is a good name too. :D
Best,
Kelvin Stinghen
kelvin.sting...@me.com
Sent from my iPhone
> On 17 Oct 2019, at 21:30, Osawa QWYNG wrote:
>
> OK, I see.
> I'll create PR frequencies/1 and frequencies_by/2
>
> 2019年10月18日(金) 9:18 José Valim :
>>
>> I am not a big fan of
Is it necessary to have this information on the left? This way both the
result from your code and some iex internals will print there, which some
people said could be confusing. What if it's on the right?
Also instead of showing the time it took to run, could iex allow some
customization and
Other alternative is to have a `time` macro that would be similar to the
Unix `time` command. `time/0` would show the execution time of the last
command, and `time expr` would show the execution time of the given
expression.
We would loose discoverability, that's true, but we could list
I suppose it's reasonable to have a defined ordering within a particular class
e.g. number class includes integers and floats, and have some (possibly
undefined) ordering between classes. This basically is the same as Erlang term
order, but for every struct we could define its own class or in
Long-running commands could print some traces during execution and return a
big list of results. If this message is printed in-between, I think it will
be harder to spot.
On Friday, October 18, 2019 at 9:00:12 AM UTC+2, José Valim wrote:
>
> My suggestion is to show it *before* we show the
My suggestion is to show it *before* we show the result, this way I don't
think we need to include the prompt. +1 no some sort of IEx prefix:
iex> long_operation()
[iex] command took 12.1s
%Some.Struct{...]
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director
>
> One thing I really like about the automatic message is that it is
> discoverable. The feature is just there. And we have prior art.
Agreed.
And also agree with Ben Wilson on using the `iex` prefix, but I would
include the number of the prompt. Here is a mockup:
[image: Screen Shot
> There's also `Kernel.match?/2`, which is awkward to use [...]
It's neither more complex to write nor understand than `if_match`.
I would argue it just seems awkward because you haven't used it a lot? --
At least it felt awkward to me the first few times I used it.
Assuming we ruled out
18 matches
Mail list logo
