Re: [elixir-core:10818] Proposal: Add support for list of strings in String.{trim, trim_leading, trim_trailing}

Thanks for the proposal. I believe we don't support all patterns because it will be inefficient, especially the suffix/trailing functions. It is not necessarily trivial to implement it for regexes either (and regexes have their own mechanism to represent prefixes/suffixes). The reason we don't

Re: [elixir-core:10815] [Proposal] Logger.put_process_level/2

Sounds good to me, a PR is welcome! We should actually change Logger.enable to use the new Logger.put_process_level, especially because we have two meta-levels called :none and :all. On Tue, Mar 1, 2022 at 1:11 PM Stefan Chrobot wrote: > Hi, I'd like to propose an addition of

Re: [elixir-core:10809] [Proposal] add an option to disable underscore_ints on formatter

Why would you want to disable it? Can you please expand on the _needs_ for the feature? Thank you. On Tue, Feb 22, 2022 at 9:31 AM Federico Bianchi wrote: > currently we are using this patch: > > defp state(comments, opts) do > underscore_ints = Keyword.get(opts, :underscore_ints, true) >

Re: [elixir-core:10808] [Proposal] exit_task in Task.async_stream to expose the element it timed out on

ne with me :) > > Thank you for the discussion! > > On Monday, 21 February 2022 at 10:32:23 UTC+1 José Valim wrote: > >> Yes, it would be {:exit, {input, :timeout}}. >> >> Generally speaking, options should not drastically change the output type >> of a fun

Re: [elixir-core:10805] [Proposal] Add methods to URI to aid in manual building & validating URIs

re & refined the various use cases. > > I’ll cut a PR against elixir-lang/elixir to update URI's documentation as > you suggest. > > Thanks again! > > m. > > > On Feb 21, 2022, at 3:54 PM, José Valim wrote: > > I see, in your case then it sounds like you running

Re: [elixir-core:10803] [Proposal] Add methods to URI to aid in manual building & validating URIs

h-normalization-and-cache-poisoning-to-steal-rocket-league-accounts/ > [2] > https://i.blackhat.com/USA-19/Thursday/us-19-Birch-HostSplit-Exploitable-Antipatterns-In-Unicode-Normalization.pdf > [3] https://community.cloudflare.com/t/faq-url-normalization/259183 > [4] https://datatracker.ietf.org/doc/html/

Re: [elixir-core:10801] [Proposal] exit_task in Task.async_stream to expose the element it timed out on

___* > *Juan* - > *No todo el oro reluce.Ni todo errante anda perdido* > *¯¯¯¯**¯**¯*** > > > On Mon, 21 Feb 2022 at 08:54, José Valim wrote: > >> {:ok, {input, output}} and so on. A PR is welcome! >> >> On Mon, Feb 21, 2022 at 08:40 vtm wrote: >

Re: [elixir-core:10799] [Proposal] exit_task in Task.async_stream to expose the element it timed out on

_input_, :timeout}] > or something along the lines of > [{_input_, {:ok, output}] > [{_input_, {:error, :timeout}] > > пт, 18 февр. 2022 г. в 13:08, José Valim : > >> Maybe we should have a zip_inputs: true or similar flag and we attach the >> input to all "ok" and

Re: [elixir-core:10795] [Proposal] Make function return values accessible in Mix.Tasks.Profile.#{Profiler}.profile

Good call, I think it should return the result directly. A PR is welcome! -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elixir-core:10793] [Proposal] Add methods to URI to aid in manual building & validating URIs

Hi Mat, thanks for starting this discussion! Quick question: don't you want to normalize the URI? I assume they already have to follow a strict format in the HTTP case that is ready to use as is. So doing any sort of normalization would be additional work. We could perform some minimal validation

Re: [elixir-core:10789] [Proposal] exit_task in Task.async_stream to expose the element it timed out on

in Enum.zip > Also you might wanna have a big list and just use `big_list |> > Task.async_stream(params) |> Stream.filter(stream, _error/1) |> > Stream.map(_error/1) |> Stream.run` > just to capture error with values and do some work > > > пт, 18 февр. 2022 г. в 12

Re: [elixir-core:10787] [Proposal] exit_task in Task.async_stream to expose the element it timed out on

Hi Juan, In your example a simple Enum.zip would suffice: list = [1, 2, 3, 4] list |> Task.async_stream( fn entry -> if entry == 3, do: :timer.sleep(2000) entry * entry end, timeout: 1000, on_timeout: :exit_task ) |> Enum.zip(list) Can you provide an example where zipping would

Re: [elixir-core:10785] Concurrrent Release Builds/Compile File Lock

ebruary 2022 at 16:42:09 UTC+2 José Valim wrote: > >> That's perfect. I believe the first step is to get those operations into >> Erlang/OTP, likely under the file module. Would you like to send a PR for >> that? I can probably provide some guidance around it. :) >> >

Re: [elixir-core:10782] Concurrrent Release Builds/Compile File Lock

t; On Wednesday, 16 February 2022 at 12:09:07 UTC+2 José Valim wrote: > >> My biggest concern with a file lock is: what happens if the other process >> terminates unexpectedly and does not remove the file lock? How can we >> ensure this won't happen? >> >> On Thu, J

Re: [elixir-core:10779] Concurrrent Release Builds/Compile File Lock

My biggest concern with a file lock is: what happens if the other process terminates unexpectedly and does not remove the file lock? How can we ensure this won't happen? On Thu, Jan 27, 2022 at 9:47 AM Brendan Ball wrote: > Hi > > We've been getting weird errors when building releases: > ``` >

Re: [elixir-core:10777] [Proposal] Allow String Literal in the TypeSpec

Type specs are restricted to what Erlang allows. So unless this is added to Erlang, which I hardly see happening, it can’t be added to Elixir. It also feel like atoms could be a better fit here. Convert the strings to atoms at the edge of the system. On Sun, Feb 13, 2022 at 23:55 Yordis Prieto

Re: [elixir-core:10773] [Proposal] Update MapSets with pattern matching, assignments, update shorthand, etc.

I believe that printing expressions is what python usually does in their >>> inspect implementation. It does help a lot with copy & paste when working >>> with the shell. >>> >>> >>> >>> *From: *elixir-lang-core@googlegroups.com < &

Re: [elixir-core:10771] [Proposal] Update MapSets with pattern matching, assignments, update shorthand, etc.

ing > with the shell. > > > > *From: *elixir-lang-core@googlegroups.com < > elixir-lang-core@googlegroups.com> on behalf of José Valim < > jose.va...@dashbit.co> > *Date: *Monday, 7 February 2022 at 13:57 > *To: *elixir-lang-core > *Subject: *Re: [elixir-core:10767]

Re: [elixir-core:10767] [Proposal] Update MapSets with pattern matching, assignments, update shorthand, etc.

And for all of those cases, if we the concern is inspections, there is always the option of printing an expression, such as: MapSet.new([1, 2, 3]) URI.parse("https://foo/bar;) Version.parse!("1.0.0") It doesn't address the concerns about pattern matching though. On Mon, Feb 7, 2022 at 2:31 PM

Re: [elixir-core:10765] [Proposal] Update MapSets with pattern matching, assignments, update shorthand, etc.

t; multi character sigils. > > Best > > Adam > > On 7 Feb 2022, at 13:10, José Valim wrote: > > Hi SV, thank you for the proposal. > > I think a more suitable solution to Elixir would be to not introduce a new > syntax to mapsets but, instead, find a mechanism to

Re: [elixir-core:10763] [Proposal] Update MapSets with pattern matching, assignments, update shorthand, etc.

Hi SV, thank you for the proposal. I think a more suitable solution to Elixir would be to not introduce a new syntax to mapsets but, instead, find a mechanism to make the constructions above possible. For example, you mentioned ranges, but they are implemented using macros and a regular operator.

Re: [elixir-core:10760] [Proposal] dual alias of the same module should result in a warning

twice in the same file without hassling those who just like to be explicit >> in files. >> >> Just my 2¢ >> >> Cheers >> Jon >> >> On Thu, 3 Feb 2022, at 10:57 PM, ku...@goyman.com wrote: >> >> Yeah I agree that import is more tricky. But fo

Re: [elixir-core:10757] Should this result in a warning?

As a general principle the formatter does not change the AST and changing the contents of a string would definitely change the AST. :) On Fri, Feb 4, 2022 at 9:10 AM Adam Lancaster wrote: > Is it something the formatter could handle at all? Perhaps with a best > effort if it ever sees `iex >`

Re: [elixir-core:10752] [Proposal] dual alias of the same module should result in a warning

We can warn it for aliases no problems and a PR would be welcome. However, for imports it is a bit more complicated because you can import something multiple times with different parts. Furthermore, maybe a library Bar is doing "import Foo" and you want to repeat "import Foo" for clarity. I think

Re: [elixir-core:10751] Should this result in a warning?

Hi Thibaut, There are two questions I asked myself: 1. What are the broadcast cases we can warn on to help people running into situations like these? 2. Can we emit false positives? One thing to keep in mind is that looking for "iex>" is already a bit lax today as it doesn't consider

Re: [elixir-core:10744] [Proposal] A 'concise' flag for 'mix test'

love to be able to run 'mix test --concise' so I can change > the formatter on the fly. > On Thursday, February 3, 2022 at 8:59:18 AM UTC-5 José Valim wrote: > >> Hi! >> >> ExUnit supports custom formatters, so my suggestion is to implement your >> own formatter and

Re: [elixir-core:10742] [Proposal] A 'concise' flag for 'mix test'

Hi! ExUnit supports custom formatters, so my suggestion is to implement your own formatter and plug it in, without a need to change Elixir. :) On Thu, Feb 3, 2022 at 1:47 PM sp wrote: > Hello! > > While working through a project I found that I just wanted a print out of > tests that failed and

Re: [elixir-core:10739] [Proposal] Formatter plugin to pre-format (or re-format) elixir files

We have added support for overwriting the formatter for .ex and .exs in the v1.13 branch. It may have been released on v1.13.2 already. On Wed, Feb 2, 2022 at 4:40 PM Zach Daniel wrote: > I've tried setting the extensions list to `[".ex", ".exs"]`, but it looks > like it isn't possible to write

Re: [elixir-core:10728] Proposal: Add support for list of strings in String.{trim, trim_leading, trim_trailing}

Yes, I think those would be consistent additions! -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view

Re: [elixir-core:10725] Re: Wrapper for receive block.

ement >> properly AFAIK :P >> >> Regards, >> Mateusz >> >> poniedziałek, 24 stycznia 2022 o 14:56:55 UTC+1 José Valim napisał(a): >> >>> Honestly, I am not sure if it is worth encapsulating the event as you >>> propose compared to a recei

Re: [elixir-core:10722] Re: Wrapper for receive block.

Honestly, I am not sure if it is worth encapsulating the event as you propose compared to a receive. For example, what happens if you want to receive at least one message from two distinct pipelines? What happens if you are inside a GenServer, where any receive pattern can be harmful and

Re: [elixir-core:10717] [Proposal] Embedded Elixir Expressions in Formatter Plugins

One option is to process the sigils formatter option early, so we pass this option to the Surface formatter (which can then pass it to format_to_string). In a nutshell, move this code

Re: [elixir-core:10711] [Proposal] add colored output to 'did you mean' suggestions

I would love to see how a prototype of this would work. One difficulty to keep in mind is that, for a diff to work, you need to show both options side by side. And I am not sure if repeating what you typed wrong will be helpful. But someone has to play with those ideas before we are sure. :) On

Re: [elixir-core:10701] Allow String.to_integer/1 to return integer when passed integer argument

Hi Curtis, All functions in String accept a string only as first argument, so I would be wary of making an exception. We could perhaps allow it in Integer.parse/2 but I am not sure if we should make an exception there either, especially when we consider there are other arguments such as base and

Re: [elixir-core:10693] ExUnit: async exclusion groups instead of async off

To be clear, I think my initial suggestions are bad too. Especially async_outside. :) On Wed, Jan 5, 2022 at 2:38 PM José Valim wrote: > I considered those options but I don't think they are intention revealing > enough. I feel like I would have to always consult the docs to be sure >

Re: [elixir-core:10692] ExUnit: async exclusion groups instead of async off

How about `async: [with: :group]` as "run asynchronously with other tests > with this group name" and `async: [except: :group]` as "run synchronously > with this group" > > On Wed, 5 Jan 2022, at 10:11 AM, José Valim wrote: > > I believe the constraints have n

Re: [elixir-core:10690] ExUnit: async exclusion groups instead of async off

at 10:36 AM Paul Dann wrote: > On Tue, 30 Nov 2021 at 12:27, Paul Dann wrote: > >> On Fri, 26 Nov 2021 at 20:22, José Valim wrote: >> >>> >>> To be clear, I understand and agree with the problem, but I don't agree >>> with the solution because it is

Re: [elixir-core:10688] Can we optimize immediately-called anonymous functions such as the ones used with then/2?

examples to > double-check whether the benchmark's results apply only on quick snippets > or across the board. > > Do you happen to know if there is any way to inspect the result of the > JIT-pass? > On 03-01-2022 20:47, José Valim wrote: > > Sorry, for the short replies,

Re: [elixir-core:10686] Can we optimize immediately-called anonymous functions such as the ones used with then/2?

oss benchmark runs the memory measurements are the same. > On 03-01-2022 20:17, José Valim wrote: > > Ah, df has no effect on a JIT system, I forgot about that. Is the memory > measurements guaranteed to have consistent effect of the GC across > benchmarks? > > On Mon, Jan 3, 2022 at 2

Re: [elixir-core:10684] Can we optimize immediately-called anonymous functions such as the ones used with then/2?

gt; > It seems that also during loading, no optimization of immediately-called > anonymous functions is taking place. > Above benchmarks seem to support this fact, although the results w.r.t. > memory usage and the difference in slowdown vs OTP23/24 seems very odd to > me. > >

Re: [elixir-core:10682] Can we optimize immediately-called anonymous functions such as the ones used with then/2?

anonymous functions are > still visible. > > I will do some benchmarks to see how the resulting performance is. Maybe > the JIT will do something which is not visible in the BEAM bytecode. > On 03-01-2022 16:57, José Valim wrote: > > then/2 is a macro and the emitted code shoul

Re: [elixir-core:10677] Add support for simultaneously updating multiple key-value pairs in maps and keyword lists

> few simple benchmarks below for the Map functions where the results are >>>>> from averaging 10k iterations. As you can see the performance improvement >>>>> is quite drastic, with both *_many functions being 130%+ . >>>>> >>>>> iex>

Re: [elixir-core:10672] Add support for simultaneously updating multiple key-value pairs in maps and keyword lists

) end) > > reduce + update! avg: 48.284 > > iex(35)> Benchmark.measure(10_000, "update_many", fn -> > Map.update_many(map, keys, &(&1*2)) end) > > update_many avg: 9.8719 > On Thursday, December 30, 2021 at 5:13:10 PM UTC-5 José Valim wrote: > >> Hi Paul

Re: [elixir-core:10670] Add support for simultaneously updating multiple key-value pairs in maps and keyword lists

Hi Paul, Thanks for the proposal. My personal take is that a Enum.reduce/3 + the relevant Map operation should be the way to go, because this can easily lead to a combination of replace_many, update_many, put_new_many, etc. Especially because the many operations likely wouldn't be any more

Re: [elixir-core:10667] Introduce let and reduce qualifiers to for

Thanks everybody for the feedback. Replies below! > I will say, I'm still not a fan of using new qualifiers. I'm not sure why we need to introduce a new special form for this, > since we can do whatever we need to in the macro? What's wrong with: for count = 0, count < 5, x <- element do {x,

Re: [elixir-core:10659] Introduce let and reduce qualifiers to for

> Does this break that? Would this (contrived) example be valid?: > > for reduce {%{start: count}, sum} = {%{start: 0}, 0}, count < 100, i <- > [1, 2, 3] do > {count + 1, i + sum} > end > It depends. It is still a pattern match but an initial version would allow only a subset of patterns. We

Re: [elixir-core:10657] Introduce let and reduce qualifiers to for

> In the examples given I can't see how they are different from using reduce > with a tuple as an accumulator, eg: > > ``` > for i <- [1, 2, 3], reduce: {0, 0} do > {doubled, sum} -> {i * 2, i + sum} > end > ``` > There is some confusion here. "reduce" cannot return the modified list, so the

Re: [elixir-core:10653] [Proposal] Block Comment Syntax for Eex/Heex Templates

This is now in the main branch. On Sunday, December 19, 2021 at 4:48:09 PM UTC+1 José Valim wrote: > Hi Simon, I will give a try implementing this during streaming today. > > On Mon, Dec 6, 2021 at 6:32 PM José Valim wrote: > >> I like the idea of supporting <%!--

Re: [elixir-core:10651] Introduce let and reduce qualifiers to for

r, lesson <- > > > > section["lessons"] do > > > > {Map.put(lesson, "position", lesson_counter), lesson_counter + 1} > > > > end > > > > section = > > > > section > > > > |> Map.put("lessons",

Re: [elixir-core:10646] Introduce let and reduce qualifiers to for

trikes the perfect balance >> between terseness and explicitness that I've come to enjoy in Elixir. >> >> My votes: >> - Naming: let over given; just because it's shorter, >> - Do use parents: let "feels" similar to var!. >> >> Best, >>

Re: [elixir-core:10642] Introduce let and reduce qualifiers to for

; count = count + 1 > {sum, count} > end > > It would lead to misunderstanding as it may not be clear which one we > are talking about when we say "use for reduce" > > > On Mon, 20 Dec 2021 19:11:54 +0100 > José Valim wrote: > > > Hi every

[elixir-core:10638] Introduce let and reduce qualifiers to for

Hi everyone, This is the second proposal for-let. You can find it in a gist: https://gist.github.com/josevalim/fe6b0bcc728539a5adf9b2821bd4a0f5 Please use the mailing list for comments and further discussion. Thanks for all the feedback so far! -- You received this message because you are

Re: [elixir-core:10636] Proposal: Emit warning on public functions without a proper function signature

some warnings to > > (somehow) when a your code is compiling vs the imported code? First > > because of what José describes here, and second it also means my > > students won't get so sidetracked when they see a ton of warnings > > from their libraries. > > > > On S

Re: [elixir-core:10633] [Proposal] Block Comment Syntax for Eex/Heex Templates

Hi Simon, I will give a try implementing this during streaming today. On Mon, Dec 6, 2021 at 6:32 PM José Valim wrote: > I like the idea of supporting <%!-- --%>, that seems like a natural > extension to me. :+1: > > Please open up an issue. And if you desire, send a PR too!

Re: [elixir-core:10632] Proposal: Emit warning on public functions without a proper function signature

While I can see this being useful for libraries, I think it is a very strong imposition for applications and I don’t think it should be the job of the compiler to enforce it. So my suggestion is to implement this as linter/credo check. On Sun, Dec 19, 2021 at 13:36 'eksperimental' via

Re: [elixir-core:10629] Introduce :let in for-comprehensions

Apologies, I re-read my first reply to you and it was definitely not clear I was taking about both approaches. On Fri, Dec 17, 2021 at 19:45 José Valim wrote: > That’s what I meant. The reduce solution requires the reverse. The state > proposal is very close to the Enum.map_reduce/3 so

Re: [elixir-core:10628] Introduce :let in for-comprehensions

{section, %{section_counter: section_counter + 1, lesson_counter: > lesson_counter}} > end > ``` > Although I did originally forget to include the fact that if `state` is > specified then not only do you match on it and return a tuple, but that the > comprehension would return a tu

Re: [elixir-core:10626] Introduce :let in for-comprehensions

ut this might limit the power of the feature. >>>> >>>> Or maybe just having the compiler raising an error if trying to >>>> re-assign within a nested block, with a helpful beginner-friendly message, >>>> could be enough to clear this confusion? >&

Re: [elixir-core:10618] Introduce :let in for-comprehensions

*Re: for section <- sections, $section_counter = 1, $lesson_counter = 1 do* I did consider introducing (precisely) $ for variables but my concern is that, by introducing special syntax, I believe most would expect it to be fully mutable, so you can modify it from any scope. That's why I decided

Re: [elixir-core:10612] Introduce :let in for-comprehensions

Thanks everyone, I am discarding the proposal for now and I will resubmit a new one next week. At this point, it is clear the "imperative assignment" is a big departure and any new proposal must not include that. Just one last point. Let's change the Pythagorean Triplets example to store values

Re: [elixir-core:10609] Re: Introduce :let in for-comprehensions

new task if it can replace several of the > others. This concept can only be applied within `for`, and then only in a > very restricted fashion, so I don't think it would enable new Elixir > developers to skip over learning Elixir as it is today. Because of this I > believe it's

Re: [elixir-core:10606] Re: Introduce :let in for-comprehensions

ew Elixir > developers to skip over learning Elixir as it is today. Because of this I > believe it's now N+1 concepts to learn. > > Cheers, > Louis > > On Thu, 16 Dec 2021 at 18:10, José Valim wrote: > >> Hi everyone, >> >> Thanks for the input so f

Re: [elixir-core:10603] Feature request: Working directory independent way to get formatter configuration for a file

Oh, the file_server is locally registered and not per process, I don't think we change this. :( On Thu, Dec 16, 2021 at 7:20 PM José Valim wrote: > > So I would like to request that there be a function to get the formatter > options (and as-of Elixir 1.13 formatter as well) relative to

Re: [elixir-core:10603] Feature request: Working directory independent way to get formatter configuration for a file

> So I would like to request that there be a function to get the formatter options (and as-of Elixir 1.13 formatter as well) relative to a passed in directory. If we can settle on an approach I'd be willing to create a PR for this. Maybe I am oversimplifying this but can we: 1. Accept cwd as an

Re: [elixir-core:10602] Re: Introduce :let in for-comprehensions

esson and counter > end > ``` > > And everything just works, as is normal in Elixir code. The proposed > changes would (as far as I can see) break this and that feels very > unexpected and foreign. > > I sympathize with the problem space, but so far it's a -1 for me on t

[elixir-core:10596] Introduce :let in for-comprehensions

Note: This proposal contains images and rich text that may not display correctly in your email. If so, you can read this proposal in a gist . There is prior art in languages like Common Lisp, Haskell, and even in C# with LINQ on

Re: [elixir-core:10595] Add Enum.split_evenly/1

ion. > четверг, 16 декабря 2021 г. в 01:45:52 UTC+3, José Valim: > >> Hi Masynchin, >> >> Thank you for the PR! >> >> I think this case can be conveniently done with two traversals, using >> take_every/drop_every, as you showed, so that's what I propose

Re: [elixir-core:10593] Add Enum.split_evenly/1

Hi Masynchin, Thank you for the PR! I think this case can be conveniently done with two traversals, using take_every/drop_every, as you showed, so that's what I propose people do. If the code is very performance oriented, then custom recursion or a reduce loop with two lists as accumulators is

Re: [elixir-core:10591] [Proposal] Include Keyword default argument validation

t just call Keyword.validate (unless I'm >> missing something). In our case we're running on Elixir 1.10, but we >> backport small bits because of their usefulness (so for example we have >> Future.Keyword.validate and Future.tap). Is something like that a viable >> way

Re: [elixir-core:10586] Proposal: Map.split_with/2

gt; 313 μs > > Comparison: > split_with 5.73 K > enum_split_with 5.06 K - 1.13x slower +23.06 μs > enum_reduce 4.52 K - 1.27x slower +46.69 μs > map_filter_reject4.52 K - 1.27x slower +46.73 μs > ``` > > So we do get some modest

Re: [elixir-core:10584] Proposal: Map.split_with/2

Hi Chris, Thanks for the proposal. I would like to first see benchmarks that show a Map implementation can be considerably more efficient. Otherwise, if it is about saving a couple Map.new calls, then I would rather not add it, as it will move to copying many more functions from Enum to Map. On

Re: [elixir-core:10582] Proposal: Map.replace/3 with a (map, key, fun) option

A PR that adds replace_lazy to Keyword and Map is welcome! On Sun, Dec 12, 2021 at 13:48 Andrea Leopardi wrote: > I love lazy_ too. We use _with for Enum functions such as split_with, but > in Map I prefer lazy_ too now that you brought it up! > > On 12 Dec 2021, at 09:44, José

[elixir-core:10572] Add PartitionSupervisor

Processes like Task.Supervisor and DynamicSupervisor can become bottlenecks on large systems and at the moment there is no dead-simple way to parallelize those. A minimal solution takes about 30-50 LOC and I believe it is important for the language to have an out-of-the-box solution to tackle

Re: [elixir-core:10570] [Proposal] Explicit indication of the execution mode in %Macro.Env{}

Oh, doh! It is there in your comments. :) Who reads code comments anyway? :D You want Code.can_await_module_compilation?, available since v1.11. mix test, livebook, iex, are all the same (and all return false). On Thu, Dec 9, 2021 at 8:39 PM José Valim wrote: > Can you please explain why

Re: [elixir-core:10569] [Proposal] Explicit indication of the execution mode in %Macro.Env{}

Can you please explain why you need to know the execution mode. The fact a library can compile different code depending if it is compile, test, or something else is not something we should encourage. On Thu, Dec 9, 2021 at 8:37 PM Ivan Rublev wrote: > Hi folks, > After delivering the library

Re: [elixir-core:10564] [Proposal] Config.config variant that does *not* deep-merge keyword lists

This is tricky because at what level do you stop deep merging? What if you had other queues? Do you want to delete them? What if you stored it at: config :core, queues: [my_queue: [global_limit: 1, local_limit: 1]] Maybe the best would be "delete_config", so you explicitly delete up to a certain

Re: [elixir-core:10559] Coverage failure should be more explicit

I like the additional input on why it failed, a PR is definitely welcome. On Tue, Dec 7, 2021 at 5:03 PM Aaron Gunderson wrote: > We are running elixir:latest in CI and hit this ambiguous problem with the > new change to coverage thresholds reporting an error: > > Changelog notes: > [mix test]

Re: [elixir-core:10557] [Proposal] Block Comment Syntax for Eex/Heex Templates

I guess because it is. > <.#> ? <%!-- ... --%>? Is it even possible to wrap other eex tags > inside, like <%!-- <% for x <- y do %> ... <% end %> ... --%>? > > We have {!-- ... --} in Surface which I use all the time. > > On Friday, 19 November 2021 at 7:29:05 pm UTC+8 José

Re: [elixir-core:10556] Enum.transpose/1 or List.transpose/1

Hi Oskar, I think the best option in this case is to move it to a private function called transpose and then call Enum.zip_with/2. This makes the intent clear without adding to the API, especially because the term transpose it self can be overloaded. On Fri, Dec 3, 2021 at 1:56 PM Oskar wrote:

Re: [elixir-core:10549] ExUnit: async exclusion groups instead of async off

o their own module so the absolute minimum number of tests are > running async which seems to be what you are after? Also that module can be > in the same test file as a test module with async tests inside them. > > Best > > Adam > > On 26 Nov 2021, at 16:42, Paul Dann wrote: >

Re: [elixir-core:10546] ExUnit: async exclusion groups instead of async off

to annotate their new test case to exclude a completely unrelated file, that may have been written 1 week, 1 month, or 1 year ago. On Fri, Nov 26, 2021 at 3:17 PM Paul Dann wrote: > On Fri, 26 Nov 2021 at 13:12, José Valim wrote: > >> Why are tests that fake a global gen se

Re: [elixir-core:10544] ExUnit: async exclusion groups instead of async off

Why are tests that fake a global gen server running asynchronously? :) If they change global state, how can you make sure in the long term, they are not going to affect any other test in the system? On Fri, Nov 26, 2021 at 2:04 PM Paul Dann wrote: > I always find it a real shame when I have to

Re: [elixir-core:10541] IEx and pipes ergonomics (with Ecto)

di 24 novembre 2021 à 18:37:22 UTC+1, thibaut...@gmail.com a > écrit : > >> Hi, >> >> > There is nothing we can do unfortunately, without perhaps changing >> upstream (i.e. how the Erlang shell system works) >> >> I understand ; thanks for the explanation ! We

Re: [elixir-core:10538] IEx and pipes ergonomics (with Ecto)

> Best > > Adam > > On 24 Nov 2021, at 16:37, José Valim wrote: > > Even then, it is debatable if we should do this change. One benefit of how > things work today is that you can see intermediate results, and I can see > people not happy if this behaviour is removed. :) > >

Re: [elixir-core:10535] IEx and pipes ergonomics (with Ecto)

Even then, it is debatable if we should do this change. One benefit of how things work today is that you can see intermediate results, and I can see people not happy if this behaviour is removed. :) -- You received this message because you are subscribed to the Google Groups "elixir-lang-core"

Re: [elixir-core:10535] IEx and pipes ergonomics (with Ecto)

There is nothing we can do unfortunately, without perhaps changing upstream (i.e. how the Erlang shell system works). The shell reads line by line, and therefore "a = DB.Resource" is a complete line on its own, which will therefore evaluate successfully. On Wed, Nov 24, 2021 at 5:34 PM

Re: [elixir-core:10531] Is `@__struct__` an implementation detail or a public API?

There is Macro.struct!(module, env), which will expand the struct for a given module accordingly and most likely what you would want to use. On Fri, Nov 19, 2021 at 11:10 PM 'eksperimental' via elixir-lang-core < elixir-lang-core@googlegroups.com> wrote: > Hi Marten, > You will find this PR

Re: [elixir-core:10526] [Proposal] Block Comment Syntax for Eex/Heex Templates

Something like <.ignore>.. would not be specific to the language (EEx knows nothing about HTML) but HTML specific. Something like ERb's would be EEx specific, so we would need to decide which solution we want. If our preference is on tags, then this should go back to LiveView. :D On Wed, Nov 17,

Re: [elixir-core:10525] Re: [Proposal] Add function `Mix.Shell.IO.password/1`

Unfortunately :io.get_password works only in limited scenarios, so I don't think we should provide first class conveniences around it until this limitation is addressed in Erlang/OTP: $ elixir -e "IO.inspect :io.get_password" {:error, {:request, {:get_password, :unicode}}} On Mon, Nov 8, 2021 at

Re: [elixir-core:10524] [Proposal]: Registry.select_count/2

Please do send a PR. Although we should probably call it count_select? Also note that instead of Enum.flat_map you want to use Enum.sum. Make sure to test that scenario too. :) On Thu, Nov 18, 2021 at 9:44 AM Rudolf Manusadzhian wrote: > Registry provides Registry.select/2 >

Re: [elixir-core:10517] Proposal: automatically highlight diff in ex_unit when match operator is used

I would prefer to not change the semantics of the code, because it can lead to subtle behavior: for example, what if the match is inside one of the monad libraries that already override what = means? You can say we could detect those cases, but it is not trivial to differentiate from a macro that

Re: [elixir-core:10513] [Proposal] no warning for external dependencies defined at root in umbrella apps

Hi Ken, this behaviour is by design. The apps inside the umbrella are still meant to run and work individually, so for example, you can run tests directly inside one of them. For sharing code between mix.exs, you can however have a separate file, called shared.exs at the root of the umbrella, or

Re: [elixir-core:10511] Proposal: Add Map.take!/2

ote: > https://github.com/whatyouhide/short_maps > > I think we can get some inspiration from this. > > Em seg., 25 de out. de 2021 09:58, José Valim > escreveu: > >> It doesn't quite apply to `Map.take/2` because the field may not be there >> anyway, so you can't e

Re: [elixir-core:10508] Proposal: Add Map.take!/2

It doesn't quite apply to `Map.take/2` because the field may not be there anyway, so you can't easily pattern match, you always need a case. I also see why we would add "delete!" but at the same time, "delete!" does not have much purpose. The result won't have said field anyway. Now I am

Re: [elixir-core:10506] Proposal: Add Map.take!/2

One thing to note though is that pattern matching is going to be the most efficient in most cases, if you want the actual values. So the docs need to be clearer that this is to return a new map with said keys. On Mon, Oct 25, 2021 at 3:11 PM José Valim wrote: > Sounds good to me, but

Re: [elixir-core:10504] Proposal: Add Map.take!/2

Sounds good to me, but we will also need Map.drop! for consistency? -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elixir-core:10501] [Proposal] List.rotate/4

elixir-lang/elixir? > > On Sunday, October 24, 2021 at 2:06:45 PM UTC-5 José Valim wrote: > >> Beautiful! >> >> On Sun, Oct 24, 2021 at 8:59 PM Tyler Young wrote: >> >>> >>> Oh, okay, works for me!  >>> >>> I'll put together an i

Re: [elixir-core:10498] [Proposal] List.rotate/4

Beautiful! On Sun, Oct 24, 2021 at 8:59 PM Tyler Young wrote: > > Oh, okay, works for me!  > > I'll put together an implementation. > > On Sunday, October 24, 2021 at 1:59:00 PM UTC-5 José Valim wrote: > >> > Re: an Enum version, I'm of the opinion this isn'

Re: [elixir-core:10496] [Proposal] List.rotate/4

the Enum module. > > -- > Tyler Young > > On Wednesday, October 20, 2021 at 10:37:31 AM UTC-5 José Valim wrote: > >> Great job! >> >> I think you can simplify this to require ranges to always have a step of >> 1. So decreasing ranges will need an explicit //1.

Re: [elixir-core:10494] Proposal: Permit specifying version requirement when declaring Mix dependencies via Git.

Hi Frerich Raabe, Thank you for the detailed proposal. Unfortunately, the issue with ~> 0.1 is that people may expect us to perform proper dependency resolution. The dependency resolution does not consider only how to download the package "foo" but rather the package "foo" and all of its

<    1   2   3   4   5   6   7   8   9   10   >