gmane.comp.lang.erlang.bugs

Re: Spec or Dialyzer regression

Tuncer Ayaz — 2012-05-16T14:54:55


Checked, maint results are the same as R15B01.


Done, found no erroneous commit in rebar.
_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Re: Spec or Dialyzer regression

Tuncer Ayaz — 2012-05-15T23:24:21

Forgot to test with maint, but will do. That's why it's not mentioned.


Upon review of the rebar code which provokes the warnings, the
substantial changes to erl_bif_types seem like a good candidate for
further analysis (commits bd941f50 03715097 9d870a01). Maybe the
changes are not finished yet.


That's a good idea. I will git bisect rebar.
_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Re: Spec or Dialyzer regression

Kostis Sagonas — 2012-05-15T20:24:34

Since Tuncer did not submit all the info he has, let me add that the 
behavior reported in his mail exists in the *master* branch of OTP and 
*not* in the maint branch which works correctly in rebar's code base.

It's unlikely that this is a dialyzer issue, as AFAIK dialyzer's code is 
the same in these two branches, but it's most likely either due to some 
erroneous spec that was introduced/changed in the master branch or a 
problem in rebar's code base.

IMO, Tuncer should have checked the latter before filling the report. It 
would be nice if he did that.

Kostis
_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Spec or Dialyzer regression

Tuncer Ayaz — 2012-05-15T19:50:30

Tthere seems to be a spec or Dialyzer regression in otp master
revealed when dialyzing rebar.

Steps to reproduce:
$ git clone git://github.com/basho/rebar.git && cd rebar
# assuming ~/.dialzer_plt is for otp master
$ make check
# otherwise, use custom PLT
$ make debug && dialyzer --plt otp_master_plt ebin

You can ignore the extra warnings enabled via 'make check'. They make
no difference.

R15B01:
rebar_utils.erl:154: Call to missing or unexported function escript:foldl/3

R16 (OTP_R15B01-386-g77c47cd):

rebar_core.erl:440: The call rebar_core:apply_hook({_,{_,_}}) will
never return since it differs in the 1st argument from the success
typing arguments: ({_,{binary() | maybe_improper_list(binary() |
maybe_improper_list(any(),binary() | []) | non_neg_integer(),binary()
| []) | {'re_pattern',_,_,_},_,_}})
rebar_ct.erl:64: Function run_test/3 has no local return
rebar_ct.erl:91: Function check_log/1 will never be called
rebar_ct.erl:113: Function show_log/1 will never be called
rebar_deps.erl:287: Function re

Re: rpc:call hide throw

Eric Merritt — 2012-05-14T15:39:11

I am not saying its a good idea mind you, but could you not catch the
exception where its propagated and reraise it in the client with
erlang:raise/3. Again, let me reiterate that I am *not* proposing this
as a solution, I would really need to think out the repercussions
before doing that.


I think we are agreeing here.


I thought that catch was actually deprecated. After going and looking
I realize that it is not. Not only that, but the docs don't seem to
mention that its a bad idea.


This also sounds like a problem that needs to be fixed, perhaps actual
deprecation and removal of catch?


That sounds reasonable to me.

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Re: rpc:call hide throw

Samuel — 2012-05-14T15:23:45

The problem with that is that once you propagate the exception to the
caller you loose the stack trace. Also throwing outside a catching
construct is an error in the called side, that should't propagate as
valid return to the calling side.

I've come across many instances of these problem trying to use throws
as exceptions. We (me and Richard Carlsson reported a possible bug to
the list as OTP behaviour callbacks do the same thing, and recently we
saw the same problem in dynamic pages in yaws (though that has already
been fixed by Steve Vinoski).

The underlying issue is that catch and try-catch have really different
behaviour concerning throws. I'd like to think that catch is legacy
and shouldn't be used, as that enables developers to use throw as it
is defined in http://www.erlang.se/workshop/2004/exception.pdf. That
is, an uncaught exception behaves as a no_catch error, with a proper
stack trace. This way, throws can be used both as non-local returns
and as exceptions. However, there seem to be lots of c

Re: rpc:call hide throw

Eric Merritt — 2012-05-14T14:31:47

Just to throw my 2c and agree with the original poster. Regardless of
whether exceptions are encouraged or not, the fact is that thrown
exceptions are a documented part of the language, and for rpc:call not
to return some indicator of the excepted state is broken.

I would equate this to the use of 'catch'. The argument against that
use that you can't tell valid return values from thrown return values.
The solution is "don't use catch, use one of the try forms".  That
same argument would seem to apply here. However, In this case there is
no form that propagates the exception in any way. Perhaps some
additional rpc:call_<x> or rpc:<x>_call needs to be added that either
propagates the exception as an exception (problematic I know) or wraps
all values in a tuple in the normal erlang way. `{ok, <valid-result>}`
or `{exit | throw | error, <thrown-value>}`.

On Mon, May 14, 2012 at 9:17 AM, Vyacheslav Vorobyov <vjache< at >gmail.com> wrote:
_______________________________________________
erlang-bugs mailing list
erlang

Re: rpc:call hide throw

Vyacheslav Vorobyov — 2012-05-14T14:17:42

Let me disagree with "erlang:throw/1 does not generate an exception".

Am I wrong addressing you to
http://www.erlang.org/doc/reference_manual/errors.html#id81437. I
think it does generate exception of class 'throw' ;-)

About "We don't throw errors in erlang.", probably yes, but we also
don't want to loose (hide) information when using rpc:call.
Information about HOW value returned. Currently rpc:call provides us
with doubtful "service" it decides for us that normally returned value
and thrown one are "equally good".

2012/5/14 Robert Virding <robert.virding< at >erlang-solutions.com>:

Re: rpc:call hide throw

Richard Carlsson — 2012-05-14T09:12:13

Well, a "nonlocal return" is also an exception. It's just a different 
class of exception than exits and errors. The question here is whether 
the rpc really ought to catch the trow and convert it to a regular 
return value, as done currently, or if it should let the caller know for 
sure that the code terminated with a throw.

The documentation for rpc:call() just says that you should get {badrpc, 
Reason} "if the call fails". And exactly what Reason is in this case is 
not specified further. Turns out, it's whatever you got from "catch 
apply(M,F,As)" if that yields {'EXIT',...}, so if the rpc failed with an 
error, you get a stack trace, but if it failed with an exit, you don't 
get a stack trace. This is all rather messy.

    /Richard

On 2012-05-14 08:33, Robert Virding wrote:

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Re: rpc:call hide throw

Robert Virding — 2012-05-14T06:33:24

erlang:throw/1 does not generate an exception or error, it does a non-local return from a function up to a surrounding catch or try. In this sense this is not an unreasonable return value, it behaves as if there is an implicit catch. If it were to generate an error it would be a 'nocatch' error. See

http://www.erlang.org/doc/man/erlang.html#throw-1

We don't throw errors in erlang. :-)

Robert

----- Original Message -----
_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

rpc:call hide throw

Vyacheslav Vorobyov — 2012-05-12T20:53:43

---------- Forwarded message ----------
From: Vyacheslav Vorobyov <vjache< at >gmail.com>
Date: 2012/5/11
Subject: rpc:call hide throw
To: erlang-bugs< at >erlang.org


Hello,

% 1. Good behavior
{badrpc,{'EXIT', some_reson }} = rpc:call(node(),erlang,exit,[some_reson]).

% 2. Bad behavior
some_reson = rpc:call(node(),erlang,throw,[some_reson]).

The second case describes an issue. It makes indistinguishable normal
result from exception.


--
Best Regargs,
     Vyacheslav

Re: lists:suffix/2 (R15B01 x64)

Beads Land-Trujillo — 2012-05-12T00:40:02

Doh!

 

- Beads

 

http://tanglelabs.com/

 

 

From: Nicolas Charpentier [mailto:nc< at >charpi.net] 
Sent: Friday, May 11, 2012 6:49 PM
To: Beads Land-Trujillo
Cc: erlang-bugs< at >erlang.org
Subject: Re: [erlang-bugs] lists:suffix/2 (R15B01 x64)

 

http://www.erlang.org/doc/man/lists.html#suffix-2

 

suffix(List1, List2) -> boolean()

 

Returns true if List1 is a suffix of List2, otherwise false

 

 

I think you wanted to call lists:suffix("a", "ala").

 

 

 

/Nicolas

 

 

 

On 11 May 2012, at 23:40, Beads Land-Trujillo wrote:





Not the behaviour I was expecting:

 

Running Erlang

Eshell V5.9.1  (abort with ^G)

1> lists:suffix("ala", "a")

false

 

Is this a release-wide issue?

 

- Beads

 

http://tanglelabs.com/

 

 

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

 

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinf

Re: lists:suffix/2 (R15B01 x64)

Nicolas Charpentier — 2012-05-11T22:48:59

http://www.erlang.org/doc/man/lists.html#suffix-2

suffix(List1, List2) -> boolean()

Returns true if List1 is a suffix of List2, otherwise false



I think you wanted to call lists:suffix("a", "ala").



/Nicolas



On 11 May 2012, at 23:40, Beads Land-Trujillo wrote:


_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

lists:suffix/2 (R15B01 x64)

Beads Land-Trujillo — 2012-05-11T22:40:44

Not the behaviour I was expecting:

 

Running Erlang

Eshell V5.9.1  (abort with ^G)

1> lists:suffix("ala", "a")

false

 

Is this a release-wide issue?

 

- Beads

 

http://tanglelabs.com/

 

 

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

rpc:call hide throw

Vyacheslav Vorobyov — 2012-05-11T14:43:23

Hello,

% 1. Good behavior
{badrpc,{'EXIT', some_reson }} = rpc:call(node(),erlang,exit,[some_reson]).

% 2. Bad behavior
some_reson = rpc:call(node(),erlang,throw,[some_reson]).

The second case describes an issue. It makes indistinguishable normal
result from exception.

List comprehension generate "function clause" exception instead of "bad generator"

Ivan Glushkov — 2012-05-11T13:59:12

Hi.

We have found recently an interesting behaviour:
- erlang console generate "bad generator" exception for the code:
1> [ {A,B} || {A,B} <- aaa ].
** exception error: bad generator aaa

- if compiled, the code throw "function clause" exception:

$ cat a.erl
-module(a).
-export([a/1]).
a(List) -> [ {A,B} || {A,B} <- List ].

$ erl
1> c(a).
{ok,a}
2> a:a(aaa).
** exception error: no function clause matching
                    a:'-a/1-lc$^0/1-0-'(aaa)


The reason is that new anonymous function is created to handle the
list comprehension, but it expects only lists. So incorrect generator
also would cause a "function clause" exception.

I suppose that the reason of such an exception here is for the
similarity with the lists:map, it also generates a "function clause"
for unsupported arguments:

2> lists:map(fun(A) -> A end, aaa).
** exception error: no function clause matching
                    lists:map(#Fun<erl_eval.6.80247286>,aaa)



To my mind this behavior is not correct as somebody might expect "bad

SystemTap kludge omitted from DTrace mega-patch forR15B01

Scott Lystig Fritchie — 2012-05-10T20:57:19

Hi, all.  I just noticed that there was one part of my DTrace mega-patch
for R1501 that was omitted ... and causes some icky problems for
SystemTap.

That change looked mostly like this:

    https://github.com/slfritchie/otp/commit/f4d2ff83f550244e5fa36472ad06231624b256cd

... and was included in the 5-part squished feature branch that was
submitted to the OTP team for the R15B01 release.  I assume that this
particular kludge wasn't used because it is ugly?

Well, granted, it's quite ugly.  But it makes stuff *work*.  From some
small testing efforts with SystemTap 1.6, a kludge-less build does not
work correctly.  Nor does Solaris 10, though the loss of function is
much smaller for Solaris 10 than for Linux's SystemTap.

What is the tolerance level for this kind of ugliness for R15B02?  I've
started putting Erlang-triggered probes into Riak, but if the entire
SystemTap-using community cannot get those probes to work, then the
value of adding the probes is significantly diminished.

-Scott
__________________

Re: Issues integrating Common Test into CI frameworks

Beads Land-Trujillo — 2012-05-10T16:15:05

Hi Peter, Eric,

A thought that probably occurred to you already, but perhaps what returns
non-zero might be controlled by flag options?

- Beads

http://twitter.com/beadsland

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Re: Issues integrating Common Test into CI frameworks

Peter Andersson — 2012-05-09T21:20:59

Hi Eric,

Thanks for the report. I can certainly see the usefulness, and I 
agree it should be implemented in ct_run preferrably. We need to 
look into a few things, such as what (besides failing test cases 
obviously), should result in non-zero exit. Auto skips? Failing end 
configuration functions? I'll create a ticket and give this some more 
thought. I'll get back to you.

Best regards,
Peter


On Wed, 9 May 2012, Eric Merritt wrote:

_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Issues integrating Common Test into CI frameworks

Eric Merritt — 2012-05-09T14:51:57

Guys,

ct_run does not return a non-zero exit status on failure. This is
needed to integrate well in any make based environment, which includes
many of the continuous integration systems out there. There are work
arounds for this, but I think this is something that should probably
at the source.

Eric
_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Re: Common Test 1.6.1 - Surefire

Jóvan Sean Dippenaar — 2012-05-08T12:37:20

Snippet of "skipped" test cases change for bamboo integration.


to_xml(#testcase{ group = Group, classname = CL, log = L, name = N, time = T, timestamp = TS, failure = F}) ->
    ["<testcase ",
     [["group=\"",Group,"\""]||Group /= ""]," "
     "name=\"",N,"\" "
     "time=\"",T,"\" "
     "timestamp=\"",TS,"\" "
     "log=\"",L,"\">",
     case F of
 passed ->
     [];
 {skipped,Reason} ->
     ["<failure type=\"skip\" message=\"Test ",N," in ",CL,
      " skipped!\">", sanitize(Reason),"</failure>"];
 {fail,Reason} ->
     ["<failure message=\"Test ",N," in ",CL," failed!\" type=\"crash\">",
      sanitize(Reason),"</failure>"]
     end,
     "</testcase>"];



/Jovan Sean Dippenaar - Aeonmind Enterprises



On 08 May 2012, at 10:49 AM, Jóvan Sean Dippenaar wrote:


_______________________________________________
erlang-bugs mailing list
erlang-bugs< at >erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs