[elixir-core:6121] Re: List.swap

Thank you very much for your replies. I have mentioned this in another thread but the lack of discussion is a > feedback itself. It seems very few developers see themselves needing this > feature, which means it likely does not justify it being part of the > standard library. > This is true,

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:6118] Proposal: `delete_at/2` and `delete_at/1`

You can get the second element of the tuple: %{users: [%{name: "John", age: 27}, %{name: "Betty", age: 40}]} |> pop_in([:users, Access.all(), :age]) |> elem(1) |> update_in([:users, Access.all(), :name], /1) # => %{users: [%{name: "john"}, %{name: "betty"}]} Also, if the answer is “delete isn’t

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

pop_in works, but it’s not very friendly for pipelines. For example, let’s say I want to do this: %{users: [%{name: "John", age: 27}, %{name: "Betty", age: 40}]} |> delete_at([:users, Access.all(), :age]) |> update_in([:users, Access.all(), :name], /1)# => %{users: [%{name: "john"}, %{name:

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

It is intentional because pop_in does exactly what you want. It deletes and returns the value deleted, which should be straight-forward to discard. *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

Re: [elixir-core:6114] Application.process_tree

> On 15 Jul 2016, at 16:16 , José Valim wrote: > > Sounds reasonable to me, yes. > > For a while I got confused here. I though you were interested in getting the > tree of applications. The process tree for an application makes more sense. > :) Although now I

Re: [elixir-core:6113] Application.process_tree

Sounds reasonable to me, yes. For a while I got confused here. I though you were interested in getting the tree of applications. The process tree for an application makes more sense. :) Although now I am concerned with what will happen when you have a simple one for one supervisor with hundreds

Re: [elixir-core:6112] Application.process_tree

After thinking a bit more on it, I think there are two parts to these features: * Functional, low level programmatic access for tools in form of Process.registered() or Application.process_tree() that doesn’t print anything * Nice, pretty printed forms as IEx helpers Does that make sense?

Re: [elixir-core:6111] Application.process_tree

+1 for the process tree being available via command line. I also want to be able to visualize it on a server where :observer is not an option. Allen Madsen http://www.allenmadsen.com On Fri, Jul 15, 2016 at 9:51 AM, Adam Lindberg wrote: > Yeah, a family of such functions makes

Re: [elixir-core:6110] Application.process_tree

Yeah, a family of such functions makes sense. Not every deployment includes IEx necessarily (embedded systems, Erlang releases including Elixir dependencies, etc.). I personally prefer if those would be available in the Process and Application module, because then they are accessible on every

Re: [elixir-core:6109] Application.process_tree

Maybe a helper on IEx is enough? It feels like we should do such for printing both the number of apps and a list of registered processes (similar to Erlang regs()). *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R On Fri, Jul 15, 2016 at 3:27 PM, Adam Lindberg

[elixir-core:6108] Application.process_tree

Would there be any interest in a new function Application.process_tree/1? I’m envisioning something like the shell `tree` utility but for an application process tree for situations when :observer cannot be started (for example, on a remote session via SSH). Cheers, Adam -- You received this

Re: [elixir-core:6104] Tagging IO.inspect

Ok, I will work on it. > On 15 Jul 2016, at 12:07, José Valim wrote: > > Good points Andrea. Yes, let's ship this then. > > > > José Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R > > On Fri,

Re: [elixir-core:6103] Tagging IO.inspect

Good points Andrea. Yes, let's ship this then. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R On Fri, Jul 15, 2016 at 12:00 PM, Andrea Leopardi wrote: > I love this feature, but I am against wrapping in a tuple because then you > may

Re: [elixir-core:6101] Tagging IO.inspect

I like this suggestion. I am wondering though if the tagging should be done by wrapping the input in a tuple: IO.inspect([1, 2, 3], tag: “my list”) #=> {"my list", [1, 2, 3]} If not, we should probably just print: "my list: [1, 2, 3]". *José Valim* www.plataformatec.com.br Skype: jv.ptec

[elixir-core:6100] Tagging IO.inspect

Hello everybody. IO.inspect/2 is one of the most useful debugging tools, and I use it extremely often. The ability to stick `|> IO.inspect` in pretty much every part of the program is really powerful. Unfortunately when having multiple such calls it becomes hard to distinguish which output

Re: [elixir-core:6099] Parameterizing Mix Erlang Compiler to handle Core

I would like to see more use cases before adding a core compiler to the language. In particular, if you are writing your own language, it is most likely that sooner rather than later you will have your own compiler on top of core and then you won't use the core compiler at all. *José Valim*