date:20191127

Re: [elixir-core:9288] Normalize compile errors and warnings

2019-11-27 Thread Mijail Rondon

Oh, I get it, thanks for the replies and explanation.

Thinking about it, you are right, because is not a machine making the code,
it is a human. So the machine should be able to parse that, it's not hard.

I make a change in the PR of GitHub Actions to parse warnings too.
https://github.com/actions/setup-elixir/pull/11/files#diff-c7e14e438b8ad4681d53486826a1b81b

-- 
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/CAJ_DNyUaT75kRyvoj01eoTXqnXru__s9EwOasPgny5qNRhG3zw%40mail.gmail.com.

Re: [elixir-core:9287] Normalize compile errors and warnings

2019-11-27 Thread José Valim

Correct. We had this discussion before and we reached some important
conclusions:

* warnings and errors should be visually distinct

* output should favor human readability rather than being parseable by
machines

* because compiling Elixir code is the same as running Elixir code,
compilation can fail due to runtime errors, and those will always have a
full stacktrace. This is a contrast to syntax errors, which always point to
the source location

Given these reasons, we introduced a diagnostics API in Mix that returns
structured data so it can be output in any format of choice. Perhaps it is
worth giving it a try.
-- 


*José Valim*
www.plataformatec.com.br
Founder and Director of R

-- 
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%2BXah_U8utecub0yS_pTShJdj3%2BXT8UiaZPbMdYa3AQ_A%40mail.gmail.com.

Re: [elixir-core:9286] Normalize compile errors and warnings

2019-11-27 Thread eksperimental

> Currently we have different ways to display errors or warnings during 
> compile time, we should normalize the output.
I would say currently there is one way to displays errors and one way to 
display warnings.

I think it is important to keep different formats to visually differentiate 
them with ease.


On Tue, 26 Nov 2019 21:57:00 -0800 (PST)
Mijail Rondon  wrote:

> Hello Elixir Core,
> 
> Currently we have different ways to display errors or warnings during 
> compile time, we should normalize the output.
> 
> For example, warnings are displayed as:
> 
> warning: unused alias Stream
>   lib/actions_sample.ex:2
> 
> and compile errors as:
> 
> ** (SyntaxError) lib/actions_sample.ex:15: unexpectedly reached end of 
> line. ...
> 
> So, no problem with compile errors but warnings should have the same format 
> as:
> 
> ** (Warning) lib/actions_sample.ex:2: unused alias Stream
> 
> The main reason to make this change is because in CI we have the ability of 
> catch those warnings or errors 
> and add annotations on specific lines of the corresponding files. 
> 
> If we normalize the warnings this will be possible to add annotations of 
> warnings to.
> 

-- 
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/20191127195511.16c3cd8f%40localhostx.

Re: [elixir-core:9285] Re: Normalize compile errors and warnings

2019-11-27 Thread Louis Pilfold

I agree there may not be any reason to introduce more formats, but Elixir
is now stable so we may want to think twice before we change any existing
output formats.

I quite like the idea of having a flag that can be given to cause all
output to be emitted in a structured format (such as JSON or the textual
Erlang term format) so it can be easily read by tooling and possibly
contain extra information that would be distracting for normal human
viewers.

Cheers,
Louis

On Wed, 27 Nov 2019 at 08:10, Mijail Rondon  wrote:

> There is not a prevention to parse both formats but also there is not a
> reason to have 2 formats.
>
> Currently to handle the warnings and errors anyone who want to do that
> have to create 2 regex to handle each one, with one format you only need
> one.
>
> I think there is not a problem if we normalize that.I'm facing that
> problem in Github Actions in this pull request:
> https://github.com/actions/setup-elixir/pull/11
> And i will be glad to make a collaboration in the core of elixir if you
> all allow me to do so.
>
> El mié., 27 de nov. de 2019 a la(s) 02:59, Louis Pilfold (lo...@lpil.uk)
> escribió:
>
>> Hello!
>>
>> What prevents the tool from attempting to parse both formats and using
>> whichever succeeds? That way this feature can exist without any changes to
>> the compiler.
>>
>> Cheers,
>> Louis
>>
>> On Wed, 27 Nov 2019, 06:11 Mijail Rondon, 
>> wrote:
>>
>>> I think i can make the change for that.
>>>
>>> Is on lib/elixir/src/elixir_errors.erl
>>>
>>> El miércoles, 27 de noviembre de 2019, 0:57:00 (UTC-5), Mijail Rondon
>>> escribió:

 Hello Elixir Core,

 Currently we have different ways to display errors or warnings during
 compile time, we should normalize the output.

 For example, warnings are displayed as:

 warning: unused alias Stream
   lib/actions_sample.ex:2

 and compile errors as:

 ** (SyntaxError) lib/actions_sample.ex:15: unexpectedly reached end of
 line. ...

 So, no problem with compile errors but warnings should have the same
 format as:

 ** (Warning) lib/actions_sample.ex:2: unused alias Stream

 The main reason to make this change is because in CI we have the
 ability of catch those warnings or errors
 and add annotations on specific lines of the corresponding files.

 If we normalize the warnings this will be possible to add annotations
 of warnings to.

>>> --
>>> 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/491c2a71-560e-4df3-9547-98696502aaf8%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/CABu8xFDk7_z2WoqBCMAOFjNpe3kCFoQC0M0%2BkV%2BwrA4sGtttPg%40mail.gmail.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/CAJ_DNyX3yPy043RsBbBKx9j-_m8B4OaofovN4dMY23gKEYj2QQ%40mail.gmail.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/CABu8xFBY1BMp2VV3seSy0PfD0rucBWDOG-y%3DTXoqzVkdu4HHGA%40mail.gmail.com.

Re: [elixir-core:9284] PROPOSAL: Improvements to doctests with pattern matching

2019-11-27 Thread José Valim

Good call!

What if we simply convert any line where = is the root expression and the
left-side is not a variable to an assertion?

The rationale is that this is an ok doctest:

iex> {:error, _} = do_something(var, 0)
iex> :ok = do_something(var, 1)

And we would most likely want to raise on these cases too.

So we can just convert everything automatically whenever we can.

*José Valim*
www.plataformatec.com.br
Founder and Director of R


On Wed, Nov 27, 2019 at 11:22 AM Devon Estes 
wrote:

> I think doctests are extremely helpful and powerful since they encourage
> developers to write testable, accurate documentation for their code. But
> the lack of some of the niceties that exist in ExUnit might make it less
> likely for developers to choose doctests instead of ExUnit tests, so I've
> been thinking of ways to narrow this gap.
>
> Currently if we are writing doctests and want to assert that the output of
> the function we're testing matches a pattern instead of testing the output
> for strict equality, we need to do one of the following two things:
>
> ```
> iex> match?(%{c: _}, Map.put(%{a: :b}, :c, :d))
> true
>
> iex> %{c: _} = Map.put(%{a: :b}, :c, :d)
> %{a: :b, c: :d}
> ```
>
> There are a few problems I see with this at the moment. First is the
> failure messages - they're not nearly as good as the failure messages in
> ExUnit at the moment for pattern matching.
>
> ```
> iex> %{f: _} = Map.put(%{a: :b}, :c, :d)
> %{a: :b, c: :d}
> ```
>
>   1) doctest Benchee.Configuration.init/1 (1) (Benchee.ConfigurationTest)
>  test/benchee/configuration_test.exs:3
>  ** (MatchError) no match of right hand side value: %{a: :b, c: :d}
>  stacktrace:
>(for doctest at) lib/benchee/configuration.ex:167: (test)
>
>
> And then for the other one we get an even less helpful error message:
>
> ```
> iex> match?(%{f: _}, Map.put(%{a: :b}, :c, :d))
> true
> ```
>
>   1) doctest Benchee.Configuration.init/1 (1) (Benchee.ConfigurationTest)
>  test/benchee/configuration_test.exs:3
>  Doctest failed
>  doctest:
>iex> match?(%{f: _}, Map.put(%{a: :b}, :c, :d))
>true
>  code:  match?(%{f: _}, Map.put(%{a: :b}, :c, :d)) === true
>  left:  false
>  right: true
>  stacktrace:
>lib/benchee/configuration.ex:167: Benchee.Configuration (module)
>
> To get the very nice new colored diff for matches available in 1.10 in our
> failure message we can do the following:
>
> ```
> iex> assert %{f: _} = Map.put(%{a: :b}, :c, :d)
> %{a: :b, c: :d}
> ```
>
>   1) doctest Benchee.Configuration.init/1 (1) (Benchee.ConfigurationTest)
>  test/benchee/configuration_test.exs:3
>  match (=) failed
>  code:  assert %{f: _} = Map.put(%{a: :b}, :c, :d)
>  left:  %{f: _}
>  right: %{a: :b, c: :d}
>  stacktrace:
>(for doctest at) lib/benchee/configuration.ex:167: (test)
>
> But putting this assertion in a doctest takes away from value of the
> example as documentation since the example is no longer really able to be
> cut and pasted - it's now more test than documentation and doesn't really
> belong here.
>
> Also, If you want to pattern match in the final line of a doctest, you
> still need to put the return value of the match (which is always the value
> being matched against) at the end of the test or else it's not parsed as a
> valid test, which makes the pattern match useless since you're already
> making the more strict comparison with `===`. Basically, we can't do this
> today:
>
> ```
> iex> %{f: _} = Map.put(%{a: :b}, :c, :d)
>
> iex> %{e: _} = Map.put(%{a: :b}, :e, :f)
>
> iex> %{f: _} = Map.put(%{a: :b}, :f, :e)
> ```
>
> My proposal is that we allow this to be a valid doctest, and that we use
> it to give really good failure messages. Anytime the last line of a doctest
> is a pattern match, we convert that into `assert pattern = expr` when
> parsing and running the test.
>
> The other thing I came up with (that I don't particularly like but figured
> I'd put it out there just in case someone builds something good off of it)
> is to use the anonymous function shorthand syntax to represent the output
> of the previous line and do something like this:
>
> ```
> iex> Map.put(%{a: :b}, :c, :d)
> %{f: _} = &1
>
> iex> Map.put(%{a: :b}, :e, :f)
> %{e: _} = &1
> ```
>
> This gets a little further away from the intended purpose of documentation
> and towards more of a test, but it would still give a better failure
> message for developers and keeps the requirement that the last line of a
> doctest includes something to test against.
>
> If folks have any better ideas for this I'd love to hear them!
>
> --
> 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
>

[elixir-core:9284] PROPOSAL: Improvements to doctests with pattern matching

2019-11-27 Thread Devon Estes

I think doctests are extremely helpful and powerful since they encourage 
developers to write testable, accurate documentation for their code. But 
the lack of some of the niceties that exist in ExUnit might make it less 
likely for developers to choose doctests instead of ExUnit tests, so I've 
been thinking of ways to narrow this gap.

Currently if we are writing doctests and want to assert that the output of 
the function we're testing matches a pattern instead of testing the output 
for strict equality, we need to do one of the following two things:

```
iex> match?(%{c: _}, Map.put(%{a: :b}, :c, :d))
true

iex> %{c: _} = Map.put(%{a: :b}, :c, :d)
%{a: :b, c: :d}
```

There are a few problems I see with this at the moment. First is the 
failure messages - they're not nearly as good as the failure messages in 
ExUnit at the moment for pattern matching.

```
iex> %{f: _} = Map.put(%{a: :b}, :c, :d)
%{a: :b, c: :d}
```

  1) doctest Benchee.Configuration.init/1 (1) (Benchee.ConfigurationTest)
 test/benchee/configuration_test.exs:3
 ** (MatchError) no match of right hand side value: %{a: :b, c: :d}
 stacktrace:
   (for doctest at) lib/benchee/configuration.ex:167: (test)


And then for the other one we get an even less helpful error message:

```
iex> match?(%{f: _}, Map.put(%{a: :b}, :c, :d))
true
```

  1) doctest Benchee.Configuration.init/1 (1) (Benchee.ConfigurationTest)
 test/benchee/configuration_test.exs:3
 Doctest failed
 doctest:
   iex> match?(%{f: _}, Map.put(%{a: :b}, :c, :d))
   true
 code:  match?(%{f: _}, Map.put(%{a: :b}, :c, :d)) === true
 left:  false
 right: true
 stacktrace:
   lib/benchee/configuration.ex:167: Benchee.Configuration (module)

To get the very nice new colored diff for matches available in 1.10 in our 
failure message we can do the following:

```
iex> assert %{f: _} = Map.put(%{a: :b}, :c, :d)
%{a: :b, c: :d}
```

  1) doctest Benchee.Configuration.init/1 (1) (Benchee.ConfigurationTest)
 test/benchee/configuration_test.exs:3
 match (=) failed
 code:  assert %{f: _} = Map.put(%{a: :b}, :c, :d)
 left:  %{f: _}
 right: %{a: :b, c: :d}
 stacktrace:
   (for doctest at) lib/benchee/configuration.ex:167: (test)

But putting this assertion in a doctest takes away from value of the 
example as documentation since the example is no longer really able to be 
cut and pasted - it's now more test than documentation and doesn't really 
belong here.

Also, If you want to pattern match in the final line of a doctest, you 
still need to put the return value of the match (which is always the value 
being matched against) at the end of the test or else it's not parsed as a 
valid test, which makes the pattern match useless since you're already 
making the more strict comparison with `===`. Basically, we can't do this 
today:

```
iex> %{f: _} = Map.put(%{a: :b}, :c, :d)

iex> %{e: _} = Map.put(%{a: :b}, :e, :f)

iex> %{f: _} = Map.put(%{a: :b}, :f, :e)
```

My proposal is that we allow this to be a valid doctest, and that we use it 
to give really good failure messages. Anytime the last line of a doctest is 
a pattern match, we convert that into `assert pattern = expr` when parsing 
and running the test.

The other thing I came up with (that I don't particularly like but figured 
I'd put it out there just in case someone builds something good off of it) 
is to use the anonymous function shorthand syntax to represent the output 
of the previous line and do something like this:

```
iex> Map.put(%{a: :b}, :c, :d)
%{f: _} = &1

iex> Map.put(%{a: :b}, :e, :f)
%{e: _} = &1
```

This gets a little further away from the intended purpose of documentation 
and towards more of a test, but it would still give a better failure 
message for developers and keeps the requirement that the last line of a 
doctest includes something to test against.

If folks have any better ideas for this I'd love to hear them!

-- 
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/b93ea3e4-9ebe-4090-b14c-bae138c60f4f%40googlegroups.com.

Re: [elixir-core:9282] Re: Normalize compile errors and warnings

2019-11-27 Thread Mijail Rondon

There is not a prevention to parse both formats but also there is not a
reason to have 2 formats.

Currently to handle the warnings and errors anyone who want to do that have
to create 2 regex to handle each one, with one format you only need one.

I think there is not a problem if we normalize that.I'm facing that problem
in Github Actions in this pull request:
https://github.com/actions/setup-elixir/pull/11
And i will be glad to make a collaboration in the core of elixir if you all
allow me to do so.

El mié., 27 de nov. de 2019 a la(s) 02:59, Louis Pilfold (lo...@lpil.uk)
escribió:

> Hello!
>
> What prevents the tool from attempting to parse both formats and using
> whichever succeeds? That way this feature can exist without any changes to
> the compiler.
>
> Cheers,
> Louis
>
> On Wed, 27 Nov 2019, 06:11 Mijail Rondon,  wrote:
>
>> I think i can make the change for that.
>>
>> Is on lib/elixir/src/elixir_errors.erl
>>
>> El miércoles, 27 de noviembre de 2019, 0:57:00 (UTC-5), Mijail Rondon
>> escribió:
>>>
>>> Hello Elixir Core,
>>>
>>> Currently we have different ways to display errors or warnings during
>>> compile time, we should normalize the output.
>>>
>>> For example, warnings are displayed as:
>>>
>>> warning: unused alias Stream
>>>   lib/actions_sample.ex:2
>>>
>>> and compile errors as:
>>>
>>> ** (SyntaxError) lib/actions_sample.ex:15: unexpectedly reached end of
>>> line. ...
>>>
>>> So, no problem with compile errors but warnings should have the same
>>> format as:
>>>
>>> ** (Warning) lib/actions_sample.ex:2: unused alias Stream
>>>
>>> The main reason to make this change is because in CI we have the ability
>>> of catch those warnings or errors
>>> and add annotations on specific lines of the corresponding files.
>>>
>>> If we normalize the warnings this will be possible to add annotations of
>>> warnings to.
>>>
>> --
>> 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/491c2a71-560e-4df3-9547-98696502aaf8%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/CABu8xFDk7_z2WoqBCMAOFjNpe3kCFoQC0M0%2BkV%2BwrA4sGtttPg%40mail.gmail.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/CAJ_DNyX3yPy043RsBbBKx9j-_m8B4OaofovN4dMY23gKEYj2QQ%40mail.gmail.com.

Re: [elixir-core:9288] Normalize compile errors and warnings

Re: [elixir-core:9287] Normalize compile errors and warnings

Re: [elixir-core:9286] Normalize compile errors and warnings

Re: [elixir-core:9285] Re: Normalize compile errors and warnings

Re: [elixir-core:9284] PROPOSAL: Improvements to doctests with pattern matching

[elixir-core:9284] PROPOSAL: Improvements to doctests with pattern matching

Re: [elixir-core:9282] Re: Normalize compile errors and warnings

7 matches

Site Navigation

Mail list logo

Footer information