[elixir-core:9493] Elixir 1.10-dev: adding transitive deps to mix.exs now a requirement?

[Kip]

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 from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/3096188b-42de-414f-9cfd-3660e4964477%40googlegroups.com.

[elixir-core:9492] [Proposal] Support transforming lists to type specs

[Kip]

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,
:currency_short
  ]

  @currency_symbol [
:standard,
:iso
  ]

  @type standard_formats :: :standard | :currency | :accounting | :short | 
:long
  @type currency_formats ::  :currency_short | :currency_long | 
:decimal_short | :decimal_long
  @type currency_symbol :: :standard | :iso

It would go good to remove one source of error by being able to allow 
compile time use of a list as the subject of  @typespec. For example:

@type currency_symbol :: @currency_symbol # Any compile-time resolvable list

Of course a macro can be introduced to do this but its quite difficult to 
achieve since it requires manual manipulation of AST.

Proposal worth considering? Or consign to the history of my 
less-than-helpful ideas :-)


-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/36f821aa-d718-48aa-a9e8-2f6d5e440632%40googlegroups.com.

Re: [elixir-core:9490] Re: Proposal: IO.error/2

[José Valim]

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
> exceptions raised in macros. I submitted a PR here:
> https://github.com/elixir-lang/elixir/pull/10040
>
>
> On Friday, May 15, 2020 at 2:29:48 PM UTC-6, José Valim wrote:
>>
>> 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 with file:line.
>>
>> On Fri, May 15, 2020 at 9:30 PM cward  wrote:
>>
>>> 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 reading this thread, I now realize that this is actually somewhat
>>> common. I don't have a use case off the top of my head, but it's often that
>>> the `position` key is lost when an error comes from a macro.
>>>
>>> In the case of elixir_ls (vscode language server), the position is
>>> expected, and the fallback is to highlight the whole file:
>>> https://github.com/elixir-lsp/elixir-ls/blob/master/apps/language_server/lib/language_server/build.ex#L63
>>>
>>> On Friday, May 15, 2020 at 12:30:52 PM UTC-6, José Valim wrote:

 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 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
> attributes. Kernel.reraise takes in a stacktrace but when I use that I 
> only
> see changes in the compiler diagnostic's message; not in it's file nor
> position.
>
>
> On Friday, May 15, 2020 at 11:45:10 AM UTC-6, José Valim wrote:
>>
>> 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 15, 2020 at 6:22 PM Dallin Osmun 
>> wrote:
>>
>>> 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 report back on how it
>>> went. Using IO.warn to report problems worked well. However, two issues
>>> arose when I added this line to the end of the macro:
>>>
>>> raise "There are errors in your query"
>>>
>>>
>>> Here is the code in question:
>>>
>>>
>>> defmodule Queries do
>>>   use MyGoblet
>>>
>>>   query "First" do
>>> error1
>>> error2
>>>   end
>>>
>>>   query "Second" do
>>> error3
>>> error4
>>>   end
>>> end
>>>
>>>
>>> 1. The first call to the macro ran, reported warnings, and then
>>> raised, halting compilation. error3 and error4 were then never reported.
>>> This can be resolved by calling raise in an @after_compile hook but I 
>>> fear
>>> doing so may suffer from the same issues you described above. Unless you
>>> have any other suggestions I think that this issue, while not ideal, is
>>> still acceptable.
>>>
>>> 2. Calling raise inside the macro caused the entire file in my
>>> editor to turn red which made it next-to-impossible to see the original
>>> warnings (see the attached screenshot). This was the diagnostic that was
>>> reported from elixir:
>>>
>>>
>>> %Mix.Task.Compiler.Diagnostic{
>>>   compiler_name: "Elixir",
>>>   details: nil,
>>>   file: "/Users/dallin/code/goblet/lib/testing.ex",
>>>   message: "** (RuntimeError) There are errors in your query\n
>>> (goblet 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro:
>>> MyGoblet.query/2\nlib/testing.ex:8: Queries 

Re: [elixir-core:9490] Re: Proposal: IO.error/2

[Dallin Osmun]

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: 
https://github.com/elixir-lang/elixir/pull/10040


On Friday, May 15, 2020 at 2:29:48 PM UTC-6, José Valim wrote:
>
> 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 with file:line.
>
> On Fri, May 15, 2020 at 9:30 PM cward > 
> wrote:
>
>> 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 reading this thread, I now realize that this is actually somewhat 
>> common. I don't have a use case off the top of my head, but it's often that 
>> the `position` key is lost when an error comes from a macro.
>>
>> In the case of elixir_ls (vscode language server), the position is 
>> expected, and the fallback is to highlight the whole file: 
>> https://github.com/elixir-lsp/elixir-ls/blob/master/apps/language_server/lib/language_server/build.ex#L63
>>
>> On Friday, May 15, 2020 at 12:30:52 PM UTC-6, José Valim wrote:
>>>
>>> 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 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 
 attributes. Kernel.reraise takes in a stacktrace but when I use that I 
 only 
 see changes in the compiler diagnostic's message; not in it's file nor 
 position.


 On Friday, May 15, 2020 at 11:45:10 AM UTC-6, José Valim wrote:
>
> 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 15, 2020 at 6:22 PM Dallin Osmun  wrote:
>
>> 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 report back on how it went. 
>> Using IO.warn to report problems worked well. However, two issues arose 
>> when I added this line to the end of the macro:
>>
>> raise "There are errors in your query"
>>
>>
>> Here is the code in question:
>>
>>
>> defmodule Queries do
>>   use MyGoblet
>>
>>   query "First" do
>> error1
>> error2
>>   end
>>
>>   query "Second" do
>> error3
>> error4
>>   end
>> end
>>
>>
>> 1. The first call to the macro ran, reported warnings, and then 
>> raised, halting compilation. error3 and error4 were then never reported. 
>> This can be resolved by calling raise in an @after_compile hook but I 
>> fear 
>> doing so may suffer from the same issues you described above. Unless you 
>> have any other suggestions I think that this issue, while not ideal, is 
>> still acceptable.
>>
>> 2. Calling raise inside the macro caused the entire file in my editor 
>> to turn red which made it next-to-impossible to see the original 
>> warnings 
>> (see the attached screenshot). This was the diagnostic that was reported 
>> from elixir:
>>
>>
>> %Mix.Task.Compiler.Diagnostic{
>>   compiler_name: "Elixir",
>>   details: nil,
>>   file: "/Users/dallin/code/goblet/lib/testing.ex",
>>   message: "** (RuntimeError) There are errors in your query\n
>> (goblet 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro: 
>> MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
>>   position: nil,
>>   severity: :error
>> }
>>
>>
>> Even though the stack trace has a line number in it, that position is 
>> 

Re: [elixir-core:9488] Proposal: Task.Supervisor.async_stream_nolink to monitor created tasks same as Task.Supervisor.async_nolink

[José Valim]

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 Dyachenko 
wrote:

> 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 say it works same as async_nolink.
> And I think it would be better to repeat that behaviour at
> async_stream_nolink, cause it is barely possible to monitor these tasks
> manually. At least it would be great to add info in docs that there are no
> monitoring and example how to add monitoring manually. Thanks!
>
> How it works in async_nolink
> https://hexdocs.pm/elixir/Task.Supervisor.html#async_nolink/3
> Docs for async_stream_nolink
> https://hexdocs.pm/elixir/Task.Supervisor.html#async_stream_nolink/4
>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/f41d0091-23c8-4af1-9bb6-67c8f22f54f1%40googlegroups.com
> 
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JHNg%2BDT_CvDqb99V7OYivjdFboaX-dF8CTq5EfM%3DHwGg%40mail.gmail.com.

Re: [elixir-core:9487] Re: Proposal: IO.error/2

[José Valim]

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 with file:line.

On Fri, May 15, 2020 at 9:30 PM cward  wrote:

> 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 reading this thread, I now realize that this is actually somewhat
> common. I don't have a use case off the top of my head, but it's often that
> the `position` key is lost when an error comes from a macro.
>
> In the case of elixir_ls (vscode language server), the position is
> expected, and the fallback is to highlight the whole file:
> https://github.com/elixir-lsp/elixir-ls/blob/master/apps/language_server/lib/language_server/build.ex#L63
>
> On Friday, May 15, 2020 at 12:30:52 PM UTC-6, José Valim wrote:
>>
>> 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 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
>>> attributes. Kernel.reraise takes in a stacktrace but when I use that I only
>>> see changes in the compiler diagnostic's message; not in it's file nor
>>> position.
>>>
>>>
>>> On Friday, May 15, 2020 at 11:45:10 AM UTC-6, José Valim wrote:

 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 15, 2020 at 6:22 PM Dallin Osmun  wrote:

> 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 report back on how it went.
> Using IO.warn to report problems worked well. However, two issues arose
> when I added this line to the end of the macro:
>
> raise "There are errors in your query"
>
>
> Here is the code in question:
>
>
> defmodule Queries do
>   use MyGoblet
>
>   query "First" do
> error1
> error2
>   end
>
>   query "Second" do
> error3
> error4
>   end
> end
>
>
> 1. The first call to the macro ran, reported warnings, and then
> raised, halting compilation. error3 and error4 were then never reported.
> This can be resolved by calling raise in an @after_compile hook but I fear
> doing so may suffer from the same issues you described above. Unless you
> have any other suggestions I think that this issue, while not ideal, is
> still acceptable.
>
> 2. Calling raise inside the macro caused the entire file in my editor
> to turn red which made it next-to-impossible to see the original warnings
> (see the attached screenshot). This was the diagnostic that was reported
> from elixir:
>
>
> %Mix.Task.Compiler.Diagnostic{
>   compiler_name: "Elixir",
>   details: nil,
>   file: "/Users/dallin/code/goblet/lib/testing.ex",
>   message: "** (RuntimeError) There are errors in your query\n
> (goblet 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro:
> MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
>   position: nil,
>   severity: :error
> }
>
>
> Even though the stack trace has a line number in it, that position is
> missing at the root of the diagnostic. This is what ultimately causes the
> issue. Would you like me to file this as a bug in the elixir issue 
> tracker?
> Or should I instead work with the authors of the editor plugin to handle
> position-less Diagnostics differently?
>
> [image: screenshot.png]
>
>
>
> On Wednesday, May 13, 2020 at 12:20:29 PM UTC-6, José Valim wrote:
>>
>> Hi Dallin,
>>
>> Thank you for the detailed proposal.
>>
>> It is important to remember that in Elixir compilation and 

[elixir-core:9487] Proposal: Task.Supervisor.async_stream_nolink to monitor created tasks same as Task.Supervisor.async_nolink

[Anastasiya Dyachenko]

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 say it works same as async_nolink. 
And I think it would be better to repeat that behaviour at 
async_stream_nolink, cause it is barely possible to monitor these tasks 
manually. At least it would be great to add info in docs that there are no 
monitoring and example how to add monitoring manually. Thanks!

How it works in async_nolink 
https://hexdocs.pm/elixir/Task.Supervisor.html#async_nolink/3
Docs for 
async_stream_nolink 
https://hexdocs.pm/elixir/Task.Supervisor.html#async_stream_nolink/4

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/f41d0091-23c8-4af1-9bb6-67c8f22f54f1%40googlegroups.com.

Re: [elixir-core:9486] Re: Proposal: IO.error/2

[cward]

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 reading this thread, I now realize that this is actually somewhat 
common. I don't have a use case off the top of my head, but it's often that 
the `position` key is lost when an error comes from a macro.

In the case of elixir_ls (vscode language server), the position is 
expected, and the fallback is to highlight the whole file: 
https://github.com/elixir-lsp/elixir-ls/blob/master/apps/language_server/lib/language_server/build.ex#L63

On Friday, May 15, 2020 at 12:30:52 PM UTC-6, José Valim wrote:
>
> 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 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 
>> attributes. Kernel.reraise takes in a stacktrace but when I use that I only 
>> see changes in the compiler diagnostic's message; not in it's file nor 
>> position.
>>
>>
>> On Friday, May 15, 2020 at 11:45:10 AM UTC-6, José Valim wrote:
>>>
>>> 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 15, 2020 at 6:22 PM Dallin Osmun  wrote:
>>>
 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 report back on how it went. 
 Using IO.warn to report problems worked well. However, two issues arose 
 when I added this line to the end of the macro:

 raise "There are errors in your query"


 Here is the code in question:


 defmodule Queries do
   use MyGoblet

   query "First" do
 error1
 error2
   end

   query "Second" do
 error3
 error4
   end
 end


 1. The first call to the macro ran, reported warnings, and then raised, 
 halting compilation. error3 and error4 were then never reported. This can 
 be resolved by calling raise in an @after_compile hook but I fear doing so 
 may suffer from the same issues you described above. Unless you have any 
 other suggestions I think that this issue, while not ideal, is still 
 acceptable.

 2. Calling raise inside the macro caused the entire file in my editor 
 to turn red which made it next-to-impossible to see the original warnings 
 (see the attached screenshot). This was the diagnostic that was reported 
 from elixir:


 %Mix.Task.Compiler.Diagnostic{
   compiler_name: "Elixir",
   details: nil,
   file: "/Users/dallin/code/goblet/lib/testing.ex",
   message: "** (RuntimeError) There are errors in your query\n
 (goblet 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro: 
 MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
   position: nil,
   severity: :error
 }


 Even though the stack trace has a line number in it, that position is 
 missing at the root of the diagnostic. This is what ultimately causes the 
 issue. Would you like me to file this as a bug in the elixir issue 
 tracker? 
 Or should I instead work with the authors of the editor plugin to handle 
 position-less Diagnostics differently?

 [image: screenshot.png]



 On Wednesday, May 13, 2020 at 12:20:29 PM UTC-6, José Valim wrote:
>
> Hi Dallin,
>
> Thank you for the detailed proposal.
>
> It is important to remember that in Elixir compilation and execution 
> steps are not necessarily distinct. For example, someone could have this 
> project:
>
> # lib/a.ex
> defmodule A do
>   use UsesYourMacro
>   query do
> ...
>   end
> end
>
> # lib/b.ex
> defmodule B do
>   A.query
> end
>
> In other words, B can already try to execute the code from A before 
> compilation finishes. Therefore, "error" can be misleading because 

Re: [elixir-core:9484] Re: Proposal: IO.error/2

[José Valim]

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 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
> attributes. Kernel.reraise takes in a stacktrace but when I use that I only
> see changes in the compiler diagnostic's message; not in it's file nor
> position.
>
>
> On Friday, May 15, 2020 at 11:45:10 AM UTC-6, José Valim wrote:
>>
>> 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 15, 2020 at 6:22 PM Dallin Osmun  wrote:
>>
>>> 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 report back on how it went.
>>> Using IO.warn to report problems worked well. However, two issues arose
>>> when I added this line to the end of the macro:
>>>
>>> raise "There are errors in your query"
>>>
>>>
>>> Here is the code in question:
>>>
>>>
>>> defmodule Queries do
>>>   use MyGoblet
>>>
>>>   query "First" do
>>> error1
>>> error2
>>>   end
>>>
>>>   query "Second" do
>>> error3
>>> error4
>>>   end
>>> end
>>>
>>>
>>> 1. The first call to the macro ran, reported warnings, and then raised,
>>> halting compilation. error3 and error4 were then never reported. This can
>>> be resolved by calling raise in an @after_compile hook but I fear doing so
>>> may suffer from the same issues you described above. Unless you have any
>>> other suggestions I think that this issue, while not ideal, is still
>>> acceptable.
>>>
>>> 2. Calling raise inside the macro caused the entire file in my editor to
>>> turn red which made it next-to-impossible to see the original warnings (see
>>> the attached screenshot). This was the diagnostic that was reported from
>>> elixir:
>>>
>>>
>>> %Mix.Task.Compiler.Diagnostic{
>>>   compiler_name: "Elixir",
>>>   details: nil,
>>>   file: "/Users/dallin/code/goblet/lib/testing.ex",
>>>   message: "** (RuntimeError) There are errors in your query\n
>>> (goblet 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro:
>>> MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
>>>   position: nil,
>>>   severity: :error
>>> }
>>>
>>>
>>> Even though the stack trace has a line number in it, that position is
>>> missing at the root of the diagnostic. This is what ultimately causes the
>>> issue. Would you like me to file this as a bug in the elixir issue tracker?
>>> Or should I instead work with the authors of the editor plugin to handle
>>> position-less Diagnostics differently?
>>>
>>> [image: screenshot.png]
>>>
>>>
>>>
>>> On Wednesday, May 13, 2020 at 12:20:29 PM UTC-6, José Valim wrote:

 Hi Dallin,

 Thank you for the detailed proposal.

 It is important to remember that in Elixir compilation and execution
 steps are not necessarily distinct. For example, someone could have this
 project:

 # lib/a.ex
 defmodule A do
   use UsesYourMacro
   query do
 ...
   end
 end

 # lib/b.ex
 defmodule B do
   A.query
 end

 In other words, B can already try to execute the code from A before
 compilation finishes. Therefore, "error" can be misleading because
 continuing compilation with an error can lead to cascading failures, and
 causing the user to chase a bug that's not the original one.

 At best, you would need to consider mixing "IO.error" and "raise". My
 suggestion in your case is to emit warnings for all errors in a particular
 query definition, allowing the user to get multiple reports, and then raise
 at the end of that query definition if any warning was emitted.

 This doesn't provide warnings across all files but it can be a good
 starting point, especially because we indeed cannot continue beyond that
 file for the reasons I mentioned above.


>>> --
>>> 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-l...@googlegroups.com.
>>> To view this discussion on the web visit
>>> 

Re: [elixir-core:9484] Re: Proposal: IO.error/2

[Dallin Osmun]

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 
attributes. Kernel.reraise takes in a stacktrace but when I use that I only 
see changes in the compiler diagnostic's message; not in it's file nor 
position.


On Friday, May 15, 2020 at 11:45:10 AM UTC-6, José Valim wrote:
>
> 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 15, 2020 at 6:22 PM Dallin Osmun  > wrote:
>
>> 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 report back on how it went. 
>> Using IO.warn to report problems worked well. However, two issues arose 
>> when I added this line to the end of the macro:
>>
>> raise "There are errors in your query"
>>
>>
>> Here is the code in question:
>>
>>
>> defmodule Queries do
>>   use MyGoblet
>>
>>   query "First" do
>> error1
>> error2
>>   end
>>
>>   query "Second" do
>> error3
>> error4
>>   end
>> end
>>
>>
>> 1. The first call to the macro ran, reported warnings, and then raised, 
>> halting compilation. error3 and error4 were then never reported. This can 
>> be resolved by calling raise in an @after_compile hook but I fear doing so 
>> may suffer from the same issues you described above. Unless you have any 
>> other suggestions I think that this issue, while not ideal, is still 
>> acceptable.
>>
>> 2. Calling raise inside the macro caused the entire file in my editor to 
>> turn red which made it next-to-impossible to see the original warnings (see 
>> the attached screenshot). This was the diagnostic that was reported from 
>> elixir:
>>
>>
>> %Mix.Task.Compiler.Diagnostic{
>>   compiler_name: "Elixir",
>>   details: nil,
>>   file: "/Users/dallin/code/goblet/lib/testing.ex",
>>   message: "** (RuntimeError) There are errors in your query\n(goblet 
>> 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro: 
>> MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
>>   position: nil,
>>   severity: :error
>> }
>>
>>
>> Even though the stack trace has a line number in it, that position is 
>> missing at the root of the diagnostic. This is what ultimately causes the 
>> issue. Would you like me to file this as a bug in the elixir issue tracker? 
>> Or should I instead work with the authors of the editor plugin to handle 
>> position-less Diagnostics differently?
>>
>> [image: screenshot.png]
>>
>>
>>
>> On Wednesday, May 13, 2020 at 12:20:29 PM UTC-6, José Valim wrote:
>>>
>>> Hi Dallin,
>>>
>>> Thank you for the detailed proposal.
>>>
>>> It is important to remember that in Elixir compilation and execution 
>>> steps are not necessarily distinct. For example, someone could have this 
>>> project:
>>>
>>> # lib/a.ex
>>> defmodule A do
>>>   use UsesYourMacro
>>>   query do
>>> ...
>>>   end
>>> end
>>>
>>> # lib/b.ex
>>> defmodule B do
>>>   A.query
>>> end
>>>
>>> In other words, B can already try to execute the code from A before 
>>> compilation finishes. Therefore, "error" can be misleading because 
>>> continuing compilation with an error can lead to cascading failures, and 
>>> causing the user to chase a bug that's not the original one.
>>>
>>> At best, you would need to consider mixing "IO.error" and "raise". My 
>>> suggestion in your case is to emit warnings for all errors in a particular 
>>> query definition, allowing the user to get multiple reports, and then raise 
>>> at the end of that query definition if any warning was emitted.
>>>
>>> This doesn't provide warnings across all files but it can be a good 
>>> starting point, especially because we indeed cannot continue beyond that 
>>> file for the reasons I mentioned above.
>>>  
>>>
>> -- 
>> 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-l...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/ad4e81d8-6495-4511-ad7b-f6064dd1a95c%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.

Re: [elixir-core:9482] Re: Proposal: IO.error/2

[José Valim]

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 15, 2020 at 6:22 PM Dallin Osmun  wrote:

> 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 report back on how it went.
> Using IO.warn to report problems worked well. However, two issues arose
> when I added this line to the end of the macro:
>
> raise "There are errors in your query"
>
>
> Here is the code in question:
>
>
> defmodule Queries do
>   use MyGoblet
>
>   query "First" do
> error1
> error2
>   end
>
>   query "Second" do
> error3
> error4
>   end
> end
>
>
> 1. The first call to the macro ran, reported warnings, and then raised,
> halting compilation. error3 and error4 were then never reported. This can
> be resolved by calling raise in an @after_compile hook but I fear doing so
> may suffer from the same issues you described above. Unless you have any
> other suggestions I think that this issue, while not ideal, is still
> acceptable.
>
> 2. Calling raise inside the macro caused the entire file in my editor to
> turn red which made it next-to-impossible to see the original warnings (see
> the attached screenshot). This was the diagnostic that was reported from
> elixir:
>
>
> %Mix.Task.Compiler.Diagnostic{
>   compiler_name: "Elixir",
>   details: nil,
>   file: "/Users/dallin/code/goblet/lib/testing.ex",
>   message: "** (RuntimeError) There are errors in your query\n(goblet
> 0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro:
> MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
>   position: nil,
>   severity: :error
> }
>
>
> Even though the stack trace has a line number in it, that position is
> missing at the root of the diagnostic. This is what ultimately causes the
> issue. Would you like me to file this as a bug in the elixir issue tracker?
> Or should I instead work with the authors of the editor plugin to handle
> position-less Diagnostics differently?
>
> [image: screenshot.png]
>
>
>
> On Wednesday, May 13, 2020 at 12:20:29 PM UTC-6, José Valim wrote:
>>
>> Hi Dallin,
>>
>> Thank you for the detailed proposal.
>>
>> It is important to remember that in Elixir compilation and execution
>> steps are not necessarily distinct. For example, someone could have this
>> project:
>>
>> # lib/a.ex
>> defmodule A do
>>   use UsesYourMacro
>>   query do
>> ...
>>   end
>> end
>>
>> # lib/b.ex
>> defmodule B do
>>   A.query
>> end
>>
>> In other words, B can already try to execute the code from A before
>> compilation finishes. Therefore, "error" can be misleading because
>> continuing compilation with an error can lead to cascading failures, and
>> causing the user to chase a bug that's not the original one.
>>
>> At best, you would need to consider mixing "IO.error" and "raise". My
>> suggestion in your case is to emit warnings for all errors in a particular
>> query definition, allowing the user to get multiple reports, and then raise
>> at the end of that query definition if any warning was emitted.
>>
>> This doesn't provide warnings across all files but it can be a good
>> starting point, especially because we indeed cannot continue beyond that
>> file for the reasons I mentioned above.
>>
>>
> --
> 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 discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/ad4e81d8-6495-4511-ad7b-f6064dd1a95c%40googlegroups.com
> 
> .
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BV6DppveoWxwdU1fOFuvOaTFSfptE5mtABrC562naqyg%40mail.gmail.com.

Re: [elixir-core:9482] Re: Proposal: IO.error/2

[Dallin Osmun]

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 report back on how it went. Using 
IO.warn to report problems worked well. However, two issues arose when I 
added this line to the end of the macro:

raise "There are errors in your query"


Here is the code in question:


defmodule Queries do
  use MyGoblet

  query "First" do
error1
error2
  end

  query "Second" do
error3
error4
  end
end


1. The first call to the macro ran, reported warnings, and then raised, 
halting compilation. error3 and error4 were then never reported. This can 
be resolved by calling raise in an @after_compile hook but I fear doing so 
may suffer from the same issues you described above. Unless you have any 
other suggestions I think that this issue, while not ideal, is still 
acceptable.

2. Calling raise inside the macro caused the entire file in my editor to 
turn red which made it next-to-impossible to see the original warnings (see 
the attached screenshot). This was the diagnostic that was reported from 
elixir:


%Mix.Task.Compiler.Diagnostic{
  compiler_name: "Elixir",
  details: nil,
  file: "/Users/dallin/code/goblet/lib/testing.ex",
  message: "** (RuntimeError) There are errors in your query\n(goblet 
0.1.0) lib/goblet.ex:74: Goblet.build/6\nexpanding macro: 
MyGoblet.query/2\nlib/testing.ex:8: Queries (module)\n",
  position: nil,
  severity: :error
}


Even though the stack trace has a line number in it, that position is 
missing at the root of the diagnostic. This is what ultimately causes the 
issue. Would you like me to file this as a bug in the elixir issue tracker? 
Or should I instead work with the authors of the editor plugin to handle 
position-less Diagnostics differently?

[image: screenshot.png]



On Wednesday, May 13, 2020 at 12:20:29 PM UTC-6, José Valim wrote:
>
> Hi Dallin,
>
> Thank you for the detailed proposal.
>
> It is important to remember that in Elixir compilation and execution steps 
> are not necessarily distinct. For example, someone could have this project:
>
> # lib/a.ex
> defmodule A do
>   use UsesYourMacro
>   query do
> ...
>   end
> end
>
> # lib/b.ex
> defmodule B do
>   A.query
> end
>
> In other words, B can already try to execute the code from A before 
> compilation finishes. Therefore, "error" can be misleading because 
> continuing compilation with an error can lead to cascading failures, and 
> causing the user to chase a bug that's not the original one.
>
> At best, you would need to consider mixing "IO.error" and "raise". My 
> suggestion in your case is to emit warnings for all errors in a particular 
> query definition, allowing the user to get multiple reports, and then raise 
> at the end of that query definition if any warning was emitted.
>
> This doesn't provide warnings across all files but it can be a good 
> starting point, especially because we indeed cannot continue beyond that 
> file for the reasons I mentioned above.
>  
>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/ad4e81d8-6495-4511-ad7b-f6064dd1a95c%40googlegroups.com.