1. Yes, the granularity you get is per macro.
2. When emitting the warning, do "Macro.Env.stacktrace(__CALLER__)" to get
the actual caller. You may also need to look at the AST to get the proper
line. Note you would need to do the same if we were to introduce some sort
of IO.error.
On Fri, May
Hi José,
Thanks for the helpful response!
What you are saying makes sense. I must admit I don't have a very advanced
knowledge of metaprogramming in elixir so I'll have to learn/practice a lot
more before I can come up with an informed response.
I tried out your suggestion and wanted to
I must be missing something. I am already using Macro.Env.stacktrace when
emitting my warnings and that's working great. The problem happens when
calling raise. Is there a way to pass a new stacktrace into raise? The docs
for Kernel.raise say it accepts either a message or an exception and
In async_stream there is a separate process that controls the stream, so
there isn't much the parent process can do, even in terms of monitors. If
you need monitors and control, then it is best to not use the stream. I
will update the docs, thanks!
On Fri, May 15, 2020 at 9:51 PM Anastasiya
It seems unreasonable for the editor to infer the line number from the
`message` key. Am I wrong in thinking that? It seems that `position` is
getting lost at some point in translation. Why would the `message` string
contain the full stacktrace with line number, but `position` is `nil`?
After
Hi José
Thank you so much for taking the time to respond to this thread. It has
been incredibly helpful and is very much appreciated!
I think I may have found an issue with how line numbers are determined for
exceptions raised in macros. I submitted a PR here:
Given Elixir compile time is really executing code, then I think it would
be a nice feature to attempt to extract it from exceptions, although I
understand it can be brittle.
If the error is really a compile-time reason (invalid syntax, invalid call,
etc), then Elixir does show a proper error
Awesome job on the PR!
On Fri, May 15, 2020 at 23:09 Dallin Osmun wrote:
> Hi José
>
> Thank you so much for taking the time to respond to this thread. It has
> been incredibly helpful and is very much appreciated!
>
> I think I may have found an issue with how line numbers are determined for
>
You can use reraise/3. It is a bit misnamed, but it is correct. But this
behaviour in particular sounds like a bug in the editor itself, given it
does have a line in the stacktrace specific to that file.
On Fri, May 15, 2020 at 8:04 PM Dallin Osmun wrote:
> I must be missing something. I am
Hi!
I propose to add monitoring of tasks, created in
Task.Supervisor.async_stream_nolink, so it would work the same as
Task.Supervisor.async_nolink for cases when it used in OTP behaviour.
For now, there is no info in docs that there are no monitoring and
handle_info would not call, cause docs
It's not uncommon to have domain overlap between lists of valid tokens
(used for validations) and type specs. For example:
@standard_formats [
:standard,
:accounting,
:currency,
:percent
]
@currency_formats [
:currency,
:accounting,
:currency_long,
I notice on elixir master than a warning is now issued if transitive
dependencies aren't directly configured in `mix.exs` and I'm curious as to
the motivation and purpose.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe
12 matches
Mail list logo
