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

crack at implementing it. >> >> -- >> Tyler Young >> >> >> On Sat, Sep 4, 2021 at 6:22 PM Zach Daniel wrote: >> >>> >>> Fwiw, “slide” sounds like a much more intuitive name than rotate, to me. >>> Rotate sounds like a 2d matrix

Fwd: [elixir-core:10482] Function / Macro Arguments in Compiler Tracers

owever, should > not be an issue. > > For example, I think a static analyzer could greatly profit from > evaluating arguments to a function. (one example could be sobelow checking > what headers were passed to the "put_secure_headers" plug) > > If you think this is a good id

Re: [elixir-core:10479] Function / Macro Arguments in Compiler Tracers

Hi Jonatan, Yes, the tracer does not receive the macro arguments, but we did not have a use case for such either. The biggest concern is that we could allow tracers to evaluate and execute arguments and that’s a very risky line to cross. Maybe this is the use case we were waiting for but then we

Re: [elixir-core:10476] Proposal: Kernel.then/3

I don't believe we should necessarily be leading people to encode more logic into pipelines. For example, sometimes the value that is in the conditional comes from the pipeline, other times it is simpler to pattern match with "case" or "with", etc. Or just a plain old conditional. It should also

Re: [elixir-core:10471] Proposal: Path.match?/3

This would be a welcome addition. However, notice that our wildcard implementation simply relies on Erlang's filelib:wildcard/2. So the first path would be to add filelib:match/2 to Erlang. Feel free to ping me on IRC if you need help or guidance to get this started on the Erlang side. On Sun,

Re: [elixir-core:10465] [Proposal] Add `:generated` field to `Macro.Env`

> As you can see, there is no way to detect that `Logger.__should_log__/2` and `Logger.__do_log__/4` are called from generated context, and these functions are quite private. Those macros do not add generated: true to their quoted expression. However, based on your examples, it seems you don't

Re: [elixir-core:10462] [Proposal] Add `:generated` field to `Macro.Env`

> This is come up from my discussion with Jason Alexon on Slack when he was trying to implement https://github.com/axelson/priv_check which checks for function calls to the private (aka marked as `@doc false`) functions. My understanding is that you want to not warn on calls to private functions,

Re: [elixir-core:10459] Proposal: programmatic access to the exact Mix.install/2 installation folder

My biggest concern about exposing those is that Mix.install/2's are cached and, if we expose the directory, people can write to it and then we will end-up with state in those. On the positive side, all of the files you referenced so far seem to be in priv, which means you can do

Re: [elixir-core:10457] Proposal: Remote dynamic configurable elixir application

ber 24, 2021 at 1:37:11 PM UTC+3 José Valim wrote: > >> In addition to what Jon wrote, it is worth keeping in mind that >> config/runtime.exs is mostly a wrapper around Application.put_env/4 with >> option persistent: true, as you well noted, so you can implement the >> funct

Re: [elixir-core:10455] Proposal: Remote dynamic configurable elixir application

In addition to what Jon wrote, it is worth keeping in mind that config/runtime.exs is mostly a wrapper around Application.put_env/4 with option persistent: true, as you well noted, so you can implement the functionality you need using those functions if necessary. On Fri, Sep 24, 2021 at 12:17 PM

Re: [elixir-core:10451] Update info for Erlang `crypto` module in Getting Started guide?

t_ adding > the module to `:extra_applications` because I'm running it on my 'dev' > computer? In the test project I used, there are NO (explicit) Mix deps, so > I don't _think_ `crypto` could be being pulled in via some other dependency. > > On Tuesday, September 21, 2021 at 11:39:25 A

Re: [elixir-core:10449] Update info for Erlang `crypto` module in Getting Started guide?

The wording here is definitely confusing. Erlang is a collection of applications and crypto is one of them. You need to include all of Erlang applications, outside of "kernel" and "stdlib" apps, in extra_applications. I will clarify the guides. Thanks! On Tue, Sep 21, 2021 at 5:33 PM Kenny Evitt

Re: [elixir-core:10446] [Proposal] Map.filter/2 based on :maps.filter

lightly faster than >> the non-inlined version. >> This difference is small, but significant (i.e. reproducible across >> benchmark re-runs). >> >> Repo with implementation + benchmarking details >> <https://github.com/Qqwy/elixir-profiling-maps_filter> >> >>

Re: [elixir-core:10443] [Proposal] Map.filter/2 based on :maps.filter

ns, which is something that might >> be worth checking. >> >> On September 9, 2021 12:31:54 PM UTC, "José Valim" >> wrote: >>> >>> Last time we had this discussion, the main concern was that :maps.filter >>> emits key, value as arguments

Re: [elixir-core:10440] [Proposal] Map.filter/2 based on :maps.filter

Last time we had this discussion, the main concern was that :maps.filter emits key, value as arguments instead of being in a tuple, and that was incongruent to the rest of Elixir’s API. We could wrap it in a tuple, but that added some considerable overhead. So we need to make a choice. On Thu,

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

position. On Sat, Sep 4, 2021 at 7:34 PM w...@resilia.nl wrote: > > > On Saturday, September 4, 2021 at 7:21:45 PM UTC+2 José Valim wrote: > >> It could definitely be implemented as a Enum or a Stream function, but >> the level of complexity is definitely much higher

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

reaching for this when the alternative is to >> do the split-and-recombine by hand. At least with a standard library >> implementation, we could provide the safest, cleanest implementation >> possible. >> >> >> On Thursday, September 2, 2021 at 9:57:06 AM UTC-5 J

Re: [elixir-core:10431] Provide an example for Enumerable suspension?

Zip uses suspension, so zipping it with any other enumerable will help test those scenarios. Use Stream.zip + Enum.take to test the combination of both suspension + halt. Improvements to the enumerable docs are welcome. :) On Sat, Sep 4, 2021 at 6:47 PM w...@resilia.nl wrote: > > Hi all! > > I

Re: [elixir-core:10429] Proposal: GenServer.reply_after

withdraw my proposal, and I'll > summarize the discussion in the near future. > On Thursday, September 2, 2021 at 2:30:09 PM UTC-7 José Valim wrote: > >> In this case, then I think I would have the GenServer return immediately >> and say: you can call the service at time X. The clie

Re: [elixir-core:10427] Proposal: GenServer.reply_after

ss, allowing it to move on to the next > request. > > On Thursday, September 2, 2021 at 12:28:31 PM UTC-7 José Valim wrote: > >> Hi Khionu, can you please explain a bit more about the design? Why does >> it need to delay the response in such a way? Is it coming from the rate >

Re: [elixir-core:10424] Proposal: GenServer.reply_after

Hi Khionu, can you please explain a bit more about the design? Why does it need to delay the response in such a way? Is it coming from the rate limiter process itself? On Thu, Sep 2, 2021 at 21:02 Khionu Sybiern wrote: > I have a case where I use a GenServer to block other operations from >

Re: [elixir-core:10421] Re: Proposal: built-in DynamicSupervisor partitioning

of DynamicSupervisor that flat_maps that over the > child supervisors? > > Overall though, +1 from me. > > On Thursday, September 2, 2021 at 11:28:19 AM UTC-4 José Valim wrote: > >> Given supervisors are also processes, they may also become bottlenecks. >> Whil

[elixir-core:10419] Proposal: built-in DynamicSupervisor partitioning

Given supervisors are also processes, they may also become bottlenecks. While this is unlikely to happen to a Supervisor, since it is mostly static, it can happen to a DynamicSupervisor. We can address this by partitioning the dynamic supervisor. Imagine the following dynamic supervisor:

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

;= end, and any violation of that gives you back > the original list. (I thiink that's consistent with the existing design > of List—e.g., List.pop_at/3 returns the original list if you give it an > index that's off the end, rather than raising an error or something. > 4. Oooh, I like

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

Hi Tyler! I think starting with a basic List.rotate is very welcome. My questions are: 1. Which of those indexes can be negative? 2. What happens if the middle index is less than or equal to the start index? 3. What happens if the last index is within start and middle? 4. Could List.rotate(list,

Re: [elixir-core:10411] Proposal: Have :array get its own protocol implementation

We supported tuples before but it led to a bunch of false positives on records looking like tuples. I think even the the is_array check does not guarantee it is actually an array. It is only a shallow check. On Wed, Sep 1, 2021 at 19:55 ad...@a-corp.co.uk wrote: > Hello, > > Not sure what the

Re: [elixir-core:10404] Proposal: "Dependency Groups" or "one of these dependencies is required, w/ a default"

>From an initial glance, I don't think this needs to be pushed to the tooling. I would create an application that sits in the middle and works as an adapter that knows how to interface with both libraries, and the user can configure which one they choose. Both libraries are optional dependencies

Re: [elixir-core:10395] [Question] mix behavior change in 1.12.2

If you have them listed as a dependency, then Mix has to control them. One option is to list them as path dependencies and point to them inside ERL_LIBS. However, if they are in ERL_LIBS, you should not need to list them as dependencies at all, instead, you can simply include them in

Re: [elixir-core:10392] [Proposal] Extend the mix formatter to work with eex files.

To make sure we are all on the same page, supporting EEx in mix format has two parts: 1. Having a formatter that works on EEx files 2. Adding hooks to "mix format" that allows custom formatting. In particular, we need to hook into certain extensions and into sigils Step 1 is a huge amount of

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

In this case, I would call Keyword.validate! And then call Map.new. I don’t see a benefit in the generic API as it won’t be faster and not necessarily clearer either. So I would stick with my last proposal. :) On Mon, Jul 26, 2021 at 20:01 Paulo Valente wrote: > I was considering making it only

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

I debated this with the Elixir team and we agreed on the following API: Keyword.validate! :: keyword | no_return Keyword.validate :: {:ok, keyword} | {:error, unknown_keys, missing_keys} The same functionality would have to be defined for Map. The API for Keyword.validate! and

Re: [elixir-core:10384] [Proposal] Enum.sum/2

I have thought about this a couple of times but another discussion we keep having is to make Enum.sum/1 part of a protocol for performance and then we wouldn't be able to optimize it in the Enum.sum/2 variant. I wonder if that can be confusing. So for now, I would go the reduce route if you are

Re: [elixir-core:10382] [Proposal] Option to generate stream from `for`

"into: Stream" plays well with the current semantics where "into: ..." changes the return value however, because emitting a stream would require "for" to emit a completely different code than today, "into: Stream" would only work if the Stream module is given at compilation time. In a nutshell,

Re: [elixir-core:10380] Re: [Proposal] Use different exit codes for compilation errors versus test failures

Sounds good to me. PR is welcome! On Thu, Jul 15, 2021 at 8:50 AM Christopher Keele wrote: > This is a compelling notion to me. > > I'd prefer an implementation where the default was generic and the > use-case was specific; ie have the complier return 1's for compilation > errors/other, and

Re: [elixir-core:10376] [Proposal] --return-errors should be propagated to Mix.Tasks.Deps.Compile

th dependency-only feature. > Although, I do think that *--return-errors *should never exit, but > instead return a list of errors, as the documentation suggests. > > What do you think? > > On Monday, July 12, 2021 at 1:34:49 PM UTC+1 José Valim wrote: > >> Gabriel,

Re: [elixir-core:10374] [Proposal] --return-errors should be propagated to Mix.Tasks.Deps.Compile

be handled by either > *elixir-ls* or the editor. > > The fact that the task current eagerly exits is what makes removes all > flexibility from being able to decide what to do with the errors at a later > stage. > > On Monday, July 12, 2021 at 9:18:20 AM UTC+1 José Valim wrote: > &

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

> Should the bang version really raise for redundant options?. If foo(opts) > wraps bar(opts) with extra options, foo() needs to clean up the opts before > passing them down [...] Maybe a non-bang version is the solution here. > Correct. But I'd say that's what I would want from a bang function.

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

I would propose to add this to the Kernel module, to mirror the struct! helper. But adding to Keyword also works. Thoughts? On Mon, Jul 12, 2021 at 8:38 AM Paulo Valente wrote: > One common problem we face when dealing with keyword list opts is > validating options passed and setting default

Re: [elixir-core:10368] [Proposal] --return-errors should be propagated to Mix.Tasks.Deps.Compile

Quick question: how would the errors in mix deps.compile be used in the editor? How could that be useful? Also note that we won't be able to do this for all dependencies... so for dependencies the best choice may be to capture stderr. On Sat, Jul 10, 2021 at 3:16 PM Guilherme Duarte wrote: >

Re: [elixir-core:10364] Proposal: Add List.keyfetch!/2

I think having a function in the shape of List.key* but one that assumes a certain shape (i.e. a two-element tuple) is counter-intuitive. We could have List.keyfind!(...) but it should still return a tuple in case of success. :) On Tue, Jul 6, 2021 at 1:38 PM Wojtek Mach wrote: > When working

Re: [elixir-core:10361] Re: [Proposal] add Task.completed

l/1 > > I'd love to hear any feedback on the approach and implementation before > submitting to the official repo. > > Thanks in advance! > > On Thursday, July 1, 2021 at 12:33:57 AM UTC-7 José Valim wrote: > >> It sounds good to me. A small but likely welcome c

Re: [elixir-core:10359] Re: [Proposal] add Task.completed

It sounds good to me. A small but likely welcome change. A PR to further explore this is welcome! On Thu, Jul 1, 2021 at 12:26 AM Aaron Ross wrote: > +1 > > I've encountered this in a similar context - I have one overall task that > will spawn some number of data fetching tasks, but in some

Re: [elixir-core:10352] [Question] Why does elixir not check source content to detect modifications?

t 1:29 PM José Valim wrote: > > Oh, just now I understand your previous point: we could simply order the > files by their last modified time. > The most recently modified is likely > the one we should try first anyway. This seems like a very trivial change > to make, I am on

Re: [elixir-core:10349] [Question] Why does elixir not check source content to detect modifications?

https://github.com/elixir-lang/elixir/commit/d9028a8d0405d19076418376ab50bdc83ff72974 On Tue, Jun 22, 2021 at 7:28 PM José Valim wrote: > Oh, just now I understand your previous point: we could simply order the > files by their last modified time. The most recently modified is likely the

Re: [elixir-core:10348] [Question] Why does elixir not check source content to detect modifications?

Oh, just now I understand your previous point: we could simply order the files by their last modified time. The most recently modified is likely the one we should try first anyway. This seems like a very trivial change to make, I am on it. On Tue, Jun 22, 2021 at 7:26 PM José Valim wrote

Re: [elixir-core:10347] [Question] Why does elixir not check source content to detect modifications?

dification date), no? > > On Tuesday, 22 June 2021 at 12:31:30 UTC-4 José Valim wrote: > >> I mean, even the impression of ordering is wrong. The compiler is running >> in parallel, so it may be that all of them are being compiled at the same >> time and none of them actually

Re: [elixir-core:10344] [Question] Why does elixir not check source content to detect modifications?

r in > Z. > 3) Fix Z > 4) `mix compile` => recompiles A, B, C, ...Y and finally Z. If there is > still an error, goto 3. A-Y should already be compiled. I haven't doubled > checked, but it is my impression that the compiler doesn't prioritize > latest modified file either? >

Re: [elixir-core:10342] [Question] Why does elixir not check source content to detect modifications?

checkpoints. On Mon, Jun 21, 2021 at 5:06 PM José Valim wrote: > I can't reproduce it. I introduced a syntax error: > > ~/ML/livebook[jv-eval-compile]$ mix test > Compiling 1 file (.ex) > > == Compilation error in file lib/livebook_cli.ex == > ** (ArithmeticError) bad a

Re: [elixir-core:10341] [Question] Why does elixir not check source content to detect modifications?

led again even though there's no other >> change to the files. >> >> Allen Madsen >> http://www.allenmadsen.com >> >> >> On Mon, Jun 21, 2021 at 3:29 AM Marc-André Lafortune < >> marc-...@marc-andre.ca> wrote: >> >>> >&

Re: [elixir-core:10337] [Question] Why does elixir not check source content to detect modifications?

Hi Marc-André! There is no particular reason, this is a functionality that could be added. In particular we can continue checking the mtime and file size but compare the contents if the mtime changed but the file size is the same. I also think we should update the mtime anyway, even if the hash

Re: [elixir-core:10332] Allow access to compiler_options while compiling EEx

Makes total sense. A PR for "parser_options" is welcome! On Sat, Jun 19, 2021 at 7:42 PM Wannes Gennar wrote: > > Currently the only way to modify the options passed into EEx's > Code.string_to_quoted!/2 call is by calling Code.put_compiler_option/2 for > :parser_options. > > Specifically I'd

Re: [elixir-core:10322] [Proposal] Strict matching comprehensions

wer is, but this feels to me like rushing >> to solve a specific problem without spending enough time considering how it >> meshes with the rest of the language in terms of cognitive complexity, >> particularly for those new to the language. >> >> Anyway, that’s m

Re: [elixir-core:10315] Preserve metadata for qualified identifiers and alias segments

ther >>> >>> El sábado, 5 de junio de 2021 a las 21:45:09 UTC-3, steve...@gmail.com >>> escribió: >>> >>>> Will that meta data extend to comments? >>>> >>>> On Fri, Jun 4, 2021 at 5:32 PM i Dorgan wrote: >>>

Re: [elixir-core:10306] [Proposal] Strict matching comprehensions

quot;* > > Does "quite later" here refer to code distance (the MatchError's > stacktrace would point away from/bury the for location)? Or temporal > distance? > > On Thursday, June 10, 2021 at 2:58:03 PM UTC-7 José Valim wrote: > >> My concern with :strict is th

Re: [elixir-core:10304] [Proposal] Strict matching comprehensions

My concern with :strict is that it changes the behavior considerably of the generators but it may show up only quite later on, far from them, especially if you have multiple filters. On Thu, Jun 10, 2021 at 23:56 Christopher Keele wrote: > > for {:ok, num} <- list, strict: true, do: num > >

Re: [elixir-core:10295] Preserve metadata for qualified identifiers and alias segments

of_expression would >>> be fine for both? It is described as "denotes when the end of expression >>> effectively happens", which is what we would be adding here. Moreover, they >>> would be the same positions that are already added in such field if the >&g

Re: [elixir-core:10293] Preserve metadata for qualified identifiers and alias segments

end_of_expression would > be fine for both? It is described as "denotes when the end of expression > effectively happens", which is what we would be adding here. Moreover, they > would be the same positions that are already added in such field if the > expression is part of a block. &

Re: [elixir-core:10291] Preserve metadata for qualified identifiers and alias segments

The dot one is easy, I think we can have the outer meta be the meta of the call identifier. A PR is welcome. For aliases, it is trickier, as you said. One alternative is to have something similar to [end: ...] that we have for constructs like do-blocks, so we can at least say where the whole

Re: [elixir-core:10284] [Proposal] `mix xref` improvements to detect problematic dependencies

> > Would `--label transient-compile` filter out all dependencies that are > either not compile time, or those that are compile-time but towards a sink > with no dependency? > E.g.: A => B (runtime) => C (compile) => D (anything): clearly `B => C` > needs to be selected, but would `A => B` also

Re: [elixir-core:10282] [Proposal] `mix xref` improvements to detect problematic dependencies

Those all look great! 1. Correct! We have recently changed --label compile so it considers transient dependencies, before it would only consider direct ones. I can think of two options here. One potential option here is to introduce a new label, called "--label transient-compile". Would that be

Re: [elixir-core:10276] [Proposal] ex_unit --warnings-as-errors option should not prevent tests from running

A PR that moves the warning to after tests run will surely be 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:10264] [Proposal] Add a Float.nearly_equal? function.

Thanks Eamonn for sharing! The article and its references led to very interesting reading. In principle I don't see an issue with adding such a function, but I believe we need to survey other languages and see what they are calling it and which edge cases they consider too. Using the code above

Re: [elixir-core:10261] [Proposal] Expose functions from `Code.Formatter` via the `Code` module

, but >> at the very least it the formatter should not break. >> >> If this works then I think I'd be in a good position to submit a PR, once >> a PR to expose the comments maps is submitted. >> El sábado, 8 de mayo de 2021 a las 2:54:13 UTC-3, José Valim escrib

Re: [elixir-core:10245] [Proposal] Expose functions from `Code.Formatter` via the `Code` module

parent node(so I can > fill line numbers, or metadata like format: :keyword to keyword lists). > > El viernes, 7 de mayo de 2021 a las 11:07:31 UTC-3, José Valim escribió: > >> I think there are two fronts: >> >> 1. Today, all of the API the formatter uses, ex

Re: [elixir-core:10242] [Proposal] Expose functions from `Code.Formatter` via the `Code` module

t, > Tonći > > On Friday, May 7, 2021 at 6:15:48 AM UTC+2 José Valim wrote: > >> Correct. Those are the trade-offs. We could for example have >> Code.string_to_quoted_formatter_options which returns the formatter options >> used for parsing the AST but then use

Re: [elixir-core:10240] [Proposal] Expose functions from `Code.Formatter` via the `Code` module

ward to any progress on this front. >> >> If anyone is interested, I was playing with these ideas and you can see >> some example use cases here: >> https://github.com/wojtekmach/fix/blob/master/test/fix_test.exs. But >> exactly because Code.Formatter is private, I had

Re: [elixir-core:10237] [Proposal] Expose functions from `Code.Formatter` via the `Code` module

I believe those ideas are promising. There is one issue about quoted_to_algebra though: the AST that the formatter works with is a special one, where the literals are wrapped in blocks so we can store their metadata. This means that, in order to have quotes_to_algebra, we would need to change the

Re: [elixir-core:10235] [Proposal] Rename :undefined in a child list when using a DynamicSupervisor

We are following Erlang convention here, and it is unlikely they will change it there, which means it is unlikely it will change in Elixir. Sorry. On Wed, Apr 28, 2021 at 17:05 Allie Sargente wrote: > > Hello, Very simple suggestion which I think would make the use case a bit > clearer. >

Re: [elixir-core:10216] [Proposal] Support steps in typespecs

ixir/compare/master...v0idpwn:patch-1>? > > Em terça-feira, 13 de abril de 2021 às 18:17:35 UTC+3, José Valim escreveu: > >> Given Dialyzer does not natively support stepped ranges, I don't think we >> should emulate them and have 1..10//1 and 1..10//2 to two very distinct >

Re: [elixir-core:10214] [Proposal] Support steps in typespecs

Given Dialyzer does not natively support stepped ranges, I don't think we should emulate them and have 1..10//1 and 1..10//2 to two very distinct things. :( On Tue, Apr 13, 2021 at 5:03 PM jonar...@gmail.com wrote: > While working with the v1.12.0 rc0 release, I wrote the following typespec: >

Re: [elixir-core:10210] [Proposal] Add explicit confirmation option to `Mix.Shell.IO.yes?`

We could support default: :yes | :no. A PR is welcome! On Sat, Apr 10, 2021 at 14:23 Darragh Enright wrote: > Hi there! > > I am currently writing some interactive mix tasks in a project I am > writing and I noticed that *Mix.Shell.IO.yes?* accepts any trimmed input > that matches the following

Re: [elixir-core:10208] [Proposal] Add Access.pop/3

Actually, please don't go ahead. Since Access.pop/2 calls module.pop/2, adding a default would change the callbacks and, therefore, the current API. I would probably wait until there is a strong need for such feature. On Wed, Apr 7, 2021 at 10:02 AM José Valim wrote: > Yes, please go ah

Re: [elixir-core:10207] [Proposal] Add Access.pop/3

Yes, please go ahead. On Wed, Apr 7, 2021 at 7:41 AM Felipe Stival wrote: > We have Map.pop/2,3, Keyword.pop/2,3, so I think that, for coherency, we > should also have default return support on Access.pop. > > This would require no additional callbacks, just a minor addition in the > Access.pop

Re: [elixir-core:10195] Proposal: Warn on duplicated specs

This is most likely the job of Dialyzer and tools working on typespecs to do. As they can do a better job at that. On Mon, Apr 5, 2021 at 2:13 AM eksperimental wrote: > Hi, > I would like to propose that the compiler emits a warning when specs > are duplicated. > > defmodule DuplicatedSpecs do

Re: [elixir-core:10193] Proposal: Add function to return the first async task to complete

esult. >> >> I'm starting in Elixir and in love, and I made my first package with >> exactly this need: >> https://github.com/ciareis/cep-promise-elixir/blob/master/lib/cep_promise.ex#L52 >> >> I could probably write everything in a better way, but I still get there.

Re: [elixir-core:10190] PROPOSAL: Nil-safe Access.at/1

Update: we also have precedents on this behaviour: pop_in also aborts as soon as it sees a nil. *José Valimhttps://dashbit.co/ <https://dashbit.co/>* On Fri, Apr 2, 2021 at 6:41 PM José Valim wrote: > After coming to this issue a couple times, I believe we should accept this &

Re: [elixir-core:10190] PROPOSAL: Nil-safe Access.at/1

mental model the > core team has for `get_in`. I ended up creating a small library to meet my > needs (https://hex.pm/packages/path_express). > > -Greg > > > On Jul 6, 2020, at 5:54 AM, José Valim wrote: > > > > Resurrecting this old-thread. Greg, what if we had a

Re: [elixir-core:10187] Proposal: Add function to return the first async task to complete

(?({:ok, _})) |> Enum.at(0) And this made me wonder: is there any reason why you can't use Task.async_stream? On Thu, Apr 1, 2021 at 3:59 PM José Valim wrote: > I don't see a reason why we wouldn't return the same order. You can easily > get the ones you want by `for {task, {:ok,

Re: [elixir-core:10186] Proposal: Add function to return the first async task to complete

ta-feira, 31 de março de 2021 às 19:35:47 UTC-3, > thia.md...@gmail.com escreveu: > >> +1 for yield_first(tasks, n, timeout) >> >> It seems to better convey the meaning "yield the first n tasks". >> >> Em qua., 31 de mar. de 2021 às 19:26, Felipe Stival >> e

Re: [elixir-core:10182] Proposal: Add function to return the first async task to complete

It was not possible to implement yield_first in Elixir but now that we have map_get in guards, we can easily do so by putting all refs in a map and only getting messages from the inbox where the ref is in the map. The number of tasks to wait and the maximum timeout should be configurable too. For

Re: [elixir-core:10171] Application.compile_all_env ?

The goal of compile_env is to track exactly which key is used. Something like compile_all_env would mark all configuration keys as compile-time, which you should most likely avoid. On Thu, Mar 25, 2021 at 5:25 PM Mihai Târnovan wrote: > I think it would be useful to have it. Are there any

Re: [elixir-core:10168] Ranges with steps

AM José Valim wrote: > > The path to supporting it in range *literals* with special rules for > guard, match, and normal contexts seems a little rough, but I can't think > of a better way than what's been proposed so far. > > To be clear, that's already how it works today. We

Re: [elixir-core:10167] Ranges with steps

pattern-matching, and guard-expressivity that ranges have today. > > 0,.0 -> [] > 0,.1 -> [1] > 2.,4 -> [2, 3] > 2,,4 -> [3] > > Not to derail the step discussion—but it does seem like on-topic insofar > as the motivations of the step feature is concerned? > On Monda

Re: [elixir-core:10165] Ranges with steps

The proposal has been updated in the gist for: x..y//z. > Since we're bike shedding on the syntax, I would throw my hat into the > ring for > 1..10:2 > It was commented before but the syntax above is ambiguous due to the use

Re: [elixir-core:10164] Proposal: Add return value to skip update in Access.get_and_update/3 callback

Thanks for the benchmarks. It turns out that for large maps we are always doing the update, I will try to send a PR upstream. On Mon, Mar 22, 2021 at 4:21 PM eksperimental wrote: > > Benchmark results. > > - map: > > https://gist.github.com/eksperimental/77d5c67427fed0a8a9e7eee21219febb > > -

Re: [elixir-core:10161] Ranges with steps

om/BinaryNoggin/> >> <https://www.instagram.com/binarynoggin/> >> <https://www.linkedin.com/company/binary-noggin> >> >> 573-263-2278 <(573)%20263-2278> am...@binarynoggin.com >> >> >> On Mon, Mar 22, 2021 at 9:05 AM José Valim w

Re: [elixir-core:10157] Ranges with steps

> I still find the syntax to be confusing with the step as the last element. > I really wish that we could do something like `a..b by: 3` but that comes > with other implementation issues. I like the proposals using a different > operator for the step. `a..b\\c`? > Unfortunately a..b\\c is

Re: [elixir-core:10152] Ranges with steps

> Isn't the issue of empty ranges really an issue of the range being right-closed without a way to say it should be right-open? So x..y.. could mean from x to y, excluding y. You could frame the issue as open/closed ranges but, given our ranges are exclusive to integers, the general consensus is

Re: [elixir-core:10149] Ranges with steps

I'm wondering if a "step" in a range should be a function instead? A function cannot be invoked in guards. So that rules it out. It has to be an integer. On Mon, Mar 22, 2021 at 1:38 PM José Valim wrote: > Hi Amos, I considered the Haskell approach, but the issue is really &g

Re: [elixir-core:10148] Ranges with steps

friendlier syntax that doesn’t have to be > explained in as much detail. 1..n makes sense when I look at it. 1..-1 also > makes sense at a glance. 1..2..10 makes sense IMO. 1..10..2 looks > surprising and confusing to me. > > Amos > > On Mar 22, 2021, at 06:32, José Valim wrot

Re: [elixir-core:10143] Ranges with steps

ssuming x, y, z to be > literals) expand to? > Maybe `when is_integer(foo) and foo >= 42 and foo <= 69 and rem(foo - > 42), 3)`? > Or is there a better alternative? > > > ~Marten / Qqwy > On 22-03-2021 11:06, José Valim wrote: > > Note: You can also read this propo

[elixir-core:10141] Ranges with steps

Note: You can also read this proposal in a gist . This is a proposal to address some of the limitations we have in Elixir ranges today. They are: * It is not possible to have ranges with custom steps * It is not possible to

Re: [elixir-core:10139] Add Watch Mode to mix test commnad

Yup, I have already changed it in master. :) -- 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 this

Re: [elixir-core:10137] Add Watch Mode to mix test commnad

wrote: > > I mean define "already exists" since as you said, I need another tool to > watch the files (which I have been doing that) > > The point is that you don't have to pipe things or use packages in order > to get the full experience. > > > On Sat, Mar 20,

Re: [elixir-core:10134] Add Watch Mode to mix test commnad

This feature already exists as —listen-to-stdin. You just need a tool, like fsevents, to watch the file: fsevents . | mix test —stale —listen-to-stdin The above will only run the files that changes (or the tests that depend on the files that have changed). On Sat, Mar 20, 2021 at 23:56

Re: [elixir-core:10131] Re: Should zip / zip_while have a reducer?

Yes, please give it a try! On Sat, Mar 20, 2021 at 4:18 PM Adam Lancaster wrote: > Awesome, yea exactly. > > Ah, i wondered if you would come up with a use case in Nx. > > I’d love to give this a stab if that’s okay so I’ll get a pr together. > > Adz > > On Sat, 20 Ma

Re: [elixir-core:10129] Re: Should zip / zip_while have a reducer?

ot;], Stream.repeatedly(fn -> 10 end), %{}, > fn k, v, acc -> > Map.merge(acc, {k, v}) > end) > > # => %{"a" => 10, "key" => 10, "list" => 10} > ``` > > Though I think if we are really going for it if you had a Zippable > proto

Re: [elixir-core:10127] Enum.uniq_by/3 with 3rd arg - a function that decides which value to keep

Hi Anastasiya, I like the proposal. A PR will be appreciated, thank you! On Fri, Mar 19, 2021 at 8:29 PM Anastasiya Dyachenko wrote: > Hi! I'd like to propose adding a 3rd optional argument to Enum.uniq_by > function, which will decide which one of the duplicated values should be > kept. This

Re: [elixir-core:10124] Proposal: Add return value to skip update in Access.get_and_update/3 callback

Hi Eksperimental, Thanks for the proposal! Can you please provide an example of where you think this would be optimized? I am certain for keyword it won't make a large difference because the cost is in traversing the keyword. And for maps, usually there is no update if you are trying to put the

Re: [elixir-core:10117] [Proposal] range pattern matching in case without when

Thanks for the proposal, However, ?a..?z in a pattern should match on a range from ?a..?z. Similarly, x..y can be used to match on any range and extract its values. Those are all valid and correct today, and introducing this proposal would break said semantics. On Sat, Mar 13, 2021 at 13:44

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