From zl9d97p02@REDACTED Tue Sep 3 19:20:56 2013 From: zl9d97p02@REDACTED (Simon Cornish) Date: Tue, 3 Sep 2013 10:20:56 -0700 Subject: [erlang-bugs] Fix inconsistency in free_memory value on Linux platforms Message-ID: <25714-1378228856-678444@sneakemail.com> Either free_memory should be the amount of memory available to user processes or otherwise it should be called something different. This patch takes the former approach with more detail in the commit message. /Simon git fetch git://github.com/dotsimon/otp.git os_mon_memsup_linux https://github.com/dotsimon/otp/compare/os_mon_memsup_linux https://github.com/dotsimon/otp/compare/os_mon_memsup_linux.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabbe.fogelholm@REDACTED Thu Sep 5 14:31:02 2013 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Thu, 5 Sep 2013 14:31:02 +0200 Subject: [erlang-bugs] Missing space in message from ct_run Message-ID: <52287986.7090901@ericsson.com> When using ct_run with the -no_auto_compile option, and when the expected .beam file is not found, there is a console message about this. The message goes Suite nosuch_SUITE not foundin directory /tmp/newDirectory but it ought to be Suite nosuch_SUITE not found in directory /tmp/newDirectory Here is a console dump that shows how to reproduce the problem: erarafo@REDACTED:~$ mkdir /tmp/newDirectory erarafo@REDACTED:~$ ct_run -dir /tmp/newDirectory -suite nosuch_SUITE -no_auto_compile Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Common Test v1.7.2 starting (cwd is /home/erarafo) Eshell V5.10.2 (abort with ^G) (ct@REDACTED)1> Suite nosuch_SUITE not foundin directory /tmp/newDirectory From rabbe.fogelholm@REDACTED Thu Sep 5 14:35:41 2013 From: rabbe.fogelholm@REDACTED (Rabbe Fogelholm) Date: Thu, 5 Sep 2013 14:35:41 +0200 Subject: [erlang-bugs] Documentation of beam_lib:version/1 is inaccurate? Message-ID: <52287A9D.9040904@ericsson.com> According to the OTP documentation I should be able to do e. g. beam_lib:version(lists). However, it seems that an atom representing a module is not accepted as argument. My workaround is BeamFile = code:which(lists), beam_lib:version(BeamFile). Console dump: $ erl Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.2 (abort with ^G) 1> beam_lib:version(lists). {error,beam_lib,{file_error,"lists.beam",enoent}} 2> BeamFile = code:which(lists), beam_lib:version(BeamFile). {ok,{lists,[329984570326751442388870353176450263952]}} ____________________________________ Rabbe Fogelholm, Ericsson, Stockholm From peppe@REDACTED Thu Sep 5 14:48:53 2013 From: peppe@REDACTED (Peter Andersson) Date: Thu, 5 Sep 2013 14:48:53 +0200 Subject: [erlang-bugs] Missing space in message from ct_run In-Reply-To: <52287986.7090901@ericsson.com> References: <52287986.7090901@ericsson.com> Message-ID: Thanks! We'll correct it immediately. Best regards, Peter Ericsson AB, Erlang/OTP On Thu, 5 Sep 2013, Rabbe Fogelholm wrote: > When using ct_run with the -no_auto_compile option, and when the expected > .beam > file is not found, there is a console message about this. The message goes > > Suite nosuch_SUITE not foundin directory /tmp/newDirectory > > but it ought to be > > Suite nosuch_SUITE not found in directory /tmp/newDirectory > > > > > Here is a console dump that shows how to reproduce the problem: > > erarafo@REDACTED:~$ mkdir /tmp/newDirectory > erarafo@REDACTED:~$ ct_run -dir /tmp/newDirectory -suite nosuch_SUITE > -no_auto_compile > Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:4:4] [async-threads:10] > [hipe] [kernel-poll:false] > > > > Common Test v1.7.2 starting (cwd is /home/erarafo) > > Eshell V5.10.2 (abort with ^G) > (ct@REDACTED)1> > Suite nosuch_SUITE not foundin directory /tmp/newDirectory > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From colanderman@REDACTED Thu Sep 5 04:11:50 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 04 Sep 2013 22:11:50 -0400 Subject: [erlang-bugs] httpc:request_cancel oddities In-Reply-To: References: Message-ID: Trying to send this again, seems to have been eaten by /dev/null last time. The implementation of httpc:request_cancel is... strange. In httpc.erl, we have: ok = httpc_manager:cancel_request(RequestId, profile_name(Profile)), receive %% If the request was already fulfilled throw away the %% answer as the request has been canceled. {http, {RequestId, _}} -> ok after 0 -> ok end. Which is already suspect because if the {stream, true} option is set, then there will be *many* such messages, and only the first one will be eaten. Let's look in httpc_manager.erl: %% The request has allready compleated make sure %% it is deliverd to the client process queue so %% it can be thrown away by httpc:cancel_request %% This delay is hopfully a temporary workaround. %% Note that it will not not delay the manager, %% only the client that called httpc:cancel_request timer:apply_after(?DELAY, gen_server, reply, [From, ok]), {noreply, State}; Ignoring the implied hope that this gets fixed real soon now, this code relies on an arbitrary delay that guarantees nothing. Hence, the behavior of cancel_request is currently to *maybe* block the first message after it is invoked, and to let through the rest. Even worse, *this code needlessly blocks the caller for a full HALF SECOND*. I spent days tracking down a bug only to find it's caused by this same hacky code which had bothered me months prior. Taking streams into account, I feel the best remedy here would be to simply allow messages from a completed request through, and require the client to drop them. This is backward-compatible as the above nondeterministic behavior requires the client to handle stray messages anyway. Further, this request should be made asynchronous; there is no reason for it to block the caller *at all*, let alone for half a second. i.e.: drop the "timer:apply_after" call; change cancel_request from a call to a cast; and drop the receive/after 0. From colanderman@REDACTED Thu Sep 5 04:39:42 2013 From: colanderman@REDACTED (Chris King) Date: Wed, 04 Sep 2013 22:39:42 -0400 Subject: [erlang-bugs] httpc:request_cancel oddities In-Reply-To: References: Message-ID: Furthermore, there's a race condition in the cancel_request handler here: case ets:lookup(HandlerDb, RequestId) of [...snip...] [{_, Pid, _}] -> httpc_handler:cancel(RequestId, Pid, From), {noreply, State#state{cancel = [{RequestId, Pid, From} | State#state.cancel]}} After the ets:lookup, thread death & reuse races with httpc_handler:cancel. The handler thread then dies when it receives a cancel message for an unknown request. Easiest (and probably most correct) solution is for the handler thread to ignore cancel messages for unknown requests, rather than dying with function_clause as it currently does. From tony@REDACTED Sat Sep 7 01:14:28 2013 From: tony@REDACTED (Tony Rogvall) Date: Sat, 7 Sep 2013 01:14:28 +0200 Subject: [erlang-bugs] erl_eval funs Message-ID: R16B01 The following code compile and works when in a module: -module(m). -export([f/0]). f() -> fun abs/1. > (m:f())(-3). 3 But > > (fun abs/1)(-3). ** exception error: undefined function erl_eval:abs/1 /Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Sat Sep 7 17:55:57 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 7 Sep 2013 11:55:57 -0400 Subject: [erlang-bugs] erl_eval funs In-Reply-To: References: Message-ID: <20130907155556.GA13437@ferdmbp.local> This is a 'problem' for all funs going in the shell and evaluator, and they also hit escripts without a module name. It's about a fun of that type being seen as a local one rather than an auto-imported one, and so they get attached to erl_eval like other evaluated funs. This works with any other auto-imported function in the shell (say process_info/1-2). I guess there needs to be an extension to the entire chain to fix this. Regards, Fred. On 09/07, Tony Rogvall wrote: > R16B01 > > The following code compile and works when in a module: > > -module(m). > -export([f/0]). > > f() -> > fun abs/1. > > > (m:f())(-3). > 3 > > But > > > (fun abs/1)(-3). > ** exception error: undefined function erl_eval:abs/1 > > > /Tony > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From norton@REDACTED Sun Sep 8 17:43:27 2013 From: norton@REDACTED (Joseph Wayne Norton) Date: Mon, 9 Sep 2013 00:43:27 +0900 Subject: [erlang-bugs] Erlang R16B01: fun syntax and exception error: no case clause matching {location, 1} in function erl_lint:loc/1 (erl_lint.erl, line 577) Message-ID: <57DC0061-7CB4-4E68-9C5E-3B2133BC4F6E@lovely.email.ne.jp> Hello. I accidentally stumbled upon the crash below with erl_lint:loc/1. I also noticed similar behavior with erlc when compiling a module with this same issue. I'm unsure of the expected behavior. Best regards, Joe N. $ erl Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.2 (abort with ^G) 1> [ fun x:A/0 || A <- [b] ]. [#Fun] 2> [ fun x:C/0 || A <- [b] ]. ** exception error: no case clause matching {location,1} in function erl_lint:loc/1 (erl_lint.erl, line 577) in call from erl_lint:add_error/3 (erl_lint.erl, line 567) in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) in call from lists:foldl/3 (lists.erl, line 1248) in call from erl_lint:expr/3 (erl_lint.erl, line 2031) in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) in call from erl_lint:expr/3 (erl_lint.erl, line 1957) 3> 3> [ fun x:A/0 || A <- [a] ]. [#Fun] 4> [ fun x:L/0 || A <- [a] ]. ** exception error: no case clause matching {location,1} in function erl_lint:loc/1 (erl_lint.erl, line 577) in call from erl_lint:add_error/3 (erl_lint.erl, line 567) in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) in call from lists:foldl/3 (lists.erl, line 1248) in call from erl_lint:expr/3 (erl_lint.erl, line 2031) in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) in call from erl_lint:expr/3 (erl_lint.erl, line 1957) From dmkolesnikov@REDACTED Sun Sep 8 21:06:26 2013 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Sun, 8 Sep 2013 22:06:26 +0300 Subject: [erlang-bugs] Erlang R16B01: fun syntax and exception error: no case clause matching {location, 1} in function erl_lint:loc/1 (erl_lint.erl, line 577) In-Reply-To: <57DC0061-7CB4-4E68-9C5E-3B2133BC4F6E@lovely.email.ne.jp> References: <57DC0061-7CB4-4E68-9C5E-3B2133BC4F6E@lovely.email.ne.jp> Message-ID: Hello, I am not gonna comment here about correctness of given exception but crash is valid. C and L are not defined variables at list comprehension. They have to be defined prior comprehension e.g. C = a. [ fun x:C/0 || A <- [b] ]. Best Regards, Dmitry On Sep 8, 2013, at 6:43 PM, Joseph Wayne Norton wrote: > > Hello. > > I accidentally stumbled upon the crash below with erl_lint:loc/1. I also noticed similar behavior with erlc when compiling a module with this same issue. > > I'm unsure of the expected behavior. > > Best regards, > > Joe N. > > > $ erl > Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.2 (abort with ^G) > 1> [ fun x:A/0 || A <- [b] ]. > [#Fun] > 2> [ fun x:C/0 || A <- [b] ]. > ** exception error: no case clause matching {location,1} > in function erl_lint:loc/1 (erl_lint.erl, line 577) > in call from erl_lint:add_error/3 (erl_lint.erl, line 567) > in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) > in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) > in call from lists:foldl/3 (lists.erl, line 1248) > in call from erl_lint:expr/3 (erl_lint.erl, line 2031) > in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) > in call from erl_lint:expr/3 (erl_lint.erl, line 1957) > 3> > > > 3> [ fun x:A/0 || A <- [a] ]. > [#Fun] > 4> [ fun x:L/0 || A <- [a] ]. > ** exception error: no case clause matching {location,1} > in function erl_lint:loc/1 (erl_lint.erl, line 577) > in call from erl_lint:add_error/3 (erl_lint.erl, line 567) > in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) > in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) > in call from lists:foldl/3 (lists.erl, line 1248) > in call from erl_lint:expr/3 (erl_lint.erl, line 2031) > in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) > in call from erl_lint:expr/3 (erl_lint.erl, line 1957) > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From tony@REDACTED Sun Sep 8 22:55:00 2013 From: tony@REDACTED (Tony Rogvall) Date: Sun, 8 Sep 2013 22:55:00 +0200 Subject: [erlang-bugs] inline & inline_effort Message-ID: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> Hi! I dont know who is working on the cerl_inline functionality but it is really intriguing ! I have found some problems doing experiments with (undocumented) compile attributes inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be tested and reworked a bit :-) I am working on a module inline parse transform that I need for speed things up a bit, specially on modules that I think will not change so much over time (think lists module) Also, hipe compile on top of this tends to do marvelous things with performance :-) Any way here is a module that when compiled, first of all warns about some strange things and then generates some "interesting" code. I guess the ones working on this will see what is the problem. And please do NOT remove functionality just because I found it, improve it. I need it :-) Thanks /Tony -module(example3i). -export([run/1]). -compile(inline). -compile({inline_size, 500}). %% default=24 -compile({inline_effort, 500}). %% default=150 %% -compile({inline_unroll, 1}). %% default=1 -compile({verbose,true}). run(V) when is_float(V) -> B = vec3f_new(4,5,6), C = vec3f_new(7,8,9), vec3f_multiply(V,vec3f_add(B,C)). -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> {float(X),float(Y),float(Z)}. vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> {A1+B1,A2+B2,A3+B3}. vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> {A1*B1,A2*B2,A3*B3}; vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> {A*B1,A*B2,A*B3}; vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> {A1*B,A2*B,A3*B}. From norton@REDACTED Mon Sep 9 05:30:10 2013 From: norton@REDACTED (Joseph Wayne Norton) Date: Mon, 9 Sep 2013 12:30:10 +0900 Subject: [erlang-bugs] Erlang R16B01: fun syntax and exception error: no case clause matching {location, 1} in function erl_lint:loc/1 (erl_lint.erl, line 577) In-Reply-To: References: <57DC0061-7CB4-4E68-9C5E-3B2133BC4F6E@lovely.email.ne.jp> Message-ID: <6674BAEC-1925-4ECE-A2E4-B4E056E468D1@lovely.email.ne.jp> Yes, understood - thanks. I am simply expecting a crash report similar to this one: $ erl Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] Eshell V5.10.2 (abort with ^G) 1> [ C || A <- [b]]. * 1: variable 'C' is unbound Best regards, Joe N. On 2013/09/09, at 4:06, Dmitry Kolesnikov wrote: > Hello, > > I am not gonna comment here about correctness of given exception but crash is valid. > C and L are not defined variables at list comprehension. They have to be defined prior comprehension e.g. > > C = a. > [ fun x:C/0 || A <- [b] ]. > > > Best Regards, > Dmitry > > On Sep 8, 2013, at 6:43 PM, Joseph Wayne Norton wrote: > >> >> Hello. >> >> I accidentally stumbled upon the crash below with erl_lint:loc/1. I also noticed similar behavior with erlc when compiling a module with this same issue. >> >> I'm unsure of the expected behavior. >> >> Best regards, >> >> Joe N. >> >> >> $ erl >> Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] >> >> Eshell V5.10.2 (abort with ^G) >> 1> [ fun x:A/0 || A <- [b] ]. >> [#Fun] >> 2> [ fun x:C/0 || A <- [b] ]. >> ** exception error: no case clause matching {location,1} >> in function erl_lint:loc/1 (erl_lint.erl, line 577) >> in call from erl_lint:add_error/3 (erl_lint.erl, line 567) >> in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) >> in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) >> in call from lists:foldl/3 (lists.erl, line 1248) >> in call from erl_lint:expr/3 (erl_lint.erl, line 2031) >> in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) >> in call from erl_lint:expr/3 (erl_lint.erl, line 1957) >> 3> >> >> >> 3> [ fun x:A/0 || A <- [a] ]. >> [#Fun] >> 4> [ fun x:L/0 || A <- [a] ]. >> ** exception error: no case clause matching {location,1} >> in function erl_lint:loc/1 (erl_lint.erl, line 577) >> in call from erl_lint:add_error/3 (erl_lint.erl, line 567) >> in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) >> in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) >> in call from lists:foldl/3 (lists.erl, line 1248) >> in call from erl_lint:expr/3 (erl_lint.erl, line 2031) >> in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) >> in call from erl_lint:expr/3 (erl_lint.erl, line 1957) >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From n.oxyde@REDACTED Mon Sep 9 08:56:33 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 9 Sep 2013 08:56:33 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> Message-ID: <52F3E884-992C-4976-92CE-2D545FB40CEE@gmail.com> Hi Tony, Btw for low-level transformations, you should rather make a Core Erlang transform, it is way easier to reason about. Regards, Le 8 sept. 2013 ? 22:55, Tony Rogvall a ?crit : > Hi! > > I dont know who is working on the cerl_inline functionality but it is really intriguing ! > I have found some problems doing experiments with (undocumented) compile attributes > inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be > tested and reworked a bit :-) > > I am working on a module inline parse transform that I need for speed things up a bit, > specially on modules that I think will not change so much over time (think lists module) > Also, hipe compile on top of this tends to do marvelous things with performance :-) > > Any way here is a module that when compiled, first of all warns about some strange things > and then generates some "interesting" code. > > I guess the ones working on this will see what is the problem. And please do NOT remove > functionality just because I found it, improve it. I need it :-) > > Thanks > > > /Tony > > > > -module(example3i). > > -export([run/1]). > > -compile(inline). > -compile({inline_size, 500}). %% default=24 > -compile({inline_effort, 500}). %% default=150 > %% -compile({inline_unroll, 1}). %% default=1 > -compile({verbose,true}). > > run(V) when is_float(V) -> > B = vec3f_new(4,5,6), > C = vec3f_new(7,8,9), > vec3f_multiply(V,vec3f_add(B,C)). > > -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). > -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). > > vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> > {float(X),float(Y),float(Z)}. > > vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> > {A1+B1,A2+B2,A3+B3}. > > vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> > {A1*B1,A2*B2,A3*B3}; > vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> > {A*B1,A*B2,A*B3}; > vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> > {A1*B,A2*B,A3*B}. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From colanderman@REDACTED Mon Sep 9 00:44:03 2013 From: colanderman@REDACTED (Chris King) Date: Sun, 08 Sep 2013 18:44:03 -0400 Subject: [erlang-bugs] httpc:request_cancel oddities In-Reply-To: References: Message-ID: One more issue: The design of httpc_manager/_handler, wherein sessions are (a) committed to the DB asynchronously, and (b) not committed until a request is complete, results in max_sessions being grossly violated when many requests are made in rapid succession. This makes max_sessions, and pipelining in general, nearly worthless -- rapid requests are exactly the situation you want pipelining for! On Wed, 04 Sep 2013 22:39:42 -0400, Chris King wrote: > Furthermore, there's a race condition in the cancel_request handler here: > > case ets:lookup(HandlerDb, RequestId) of > [...snip...] > [{_, Pid, _}] -> > httpc_handler:cancel(RequestId, Pid, From), > {noreply, > State#state{cancel = > [{RequestId, Pid, From} | State#state.cancel]}} > > After the ets:lookup, thread death & reuse races with > httpc_handler:cancel. The handler thread then dies when it receives a > cancel message for an unknown request. Easiest (and probably most > correct) solution is for the handler thread to ignore cancel messages > for unknown requests, rather than dying with function_clause as it > currently does. From egil@REDACTED Mon Sep 9 10:42:05 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 9 Sep 2013 10:42:05 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <52F3E884-992C-4976-92CE-2D545FB40CEE@gmail.com> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> <52F3E884-992C-4976-92CE-2D545FB40CEE@gmail.com> Message-ID: <522D89DD.3080205@erlang.org> On 2013-09-09 08:56, Anthony Ramine wrote: > Hi Tony, > > Btw for low-level transformations, you should rather make a Core Erlang transform, it is way easier to reason about. +1, do it in core erlang or wait that's a novel idea, perhaps we should remove it .. =) // Bj?rn-Egil > > Regards, > > Le 8 sept. 2013 ? 22:55, Tony Rogvall a ?crit : > >> Hi! >> >> I dont know who is working on the cerl_inline functionality but it is really intriguing ! >> I have found some problems doing experiments with (undocumented) compile attributes >> inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be >> tested and reworked a bit :-) >> >> I am working on a module inline parse transform that I need for speed things up a bit, >> specially on modules that I think will not change so much over time (think lists module) >> Also, hipe compile on top of this tends to do marvelous things with performance :-) >> >> Any way here is a module that when compiled, first of all warns about some strange things >> and then generates some "interesting" code. >> >> I guess the ones working on this will see what is the problem. And please do NOT remove >> functionality just because I found it, improve it. I need it :-) >> >> Thanks >> >> >> /Tony >> >> >> >> -module(example3i). >> >> -export([run/1]). >> >> -compile(inline). >> -compile({inline_size, 500}). %% default=24 >> -compile({inline_effort, 500}). %% default=150 >> %% -compile({inline_unroll, 1}). %% default=1 >> -compile({verbose,true}). >> >> run(V) when is_float(V) -> >> B = vec3f_new(4,5,6), >> C = vec3f_new(7,8,9), >> vec3f_multiply(V,vec3f_add(B,C)). >> >> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). >> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). >> >> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> >> {float(X),float(Y),float(Z)}. >> >> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >> {A1+B1,A2+B2,A3+B3}. >> >> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >> {A1*B1,A2*B2,A3*B3}; >> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> >> {A*B1,A*B2,A*B3}; >> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> >> {A1*B,A2*B,A3*B}. >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From n.oxyde@REDACTED Mon Sep 9 10:54:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 9 Sep 2013 10:54:51 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <522D89DD.3080205@erlang.org> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> <52F3E884-992C-4976-92CE-2D545FB40CEE@gmail.com> <522D89DD.3080205@erlang.org> Message-ID: <62A9D8A1-ABB5-4276-920E-8008A8354DAD@gmail.com> Hey don't remove Core transforms, I use them :p https://github.com/nox/shippai -- Anthony Ramine Le 9 sept. 2013 ? 10:42, Bj?rn-Egil Dahlberg a ?crit : > On 2013-09-09 08:56, Anthony Ramine wrote: >> Hi Tony, >> >> Btw for low-level transformations, you should rather make a Core Erlang transform, it is way easier to reason about. > +1, do it in core erlang > > or wait that's a novel idea, perhaps we should remove it .. =) > > // Bj?rn-Egil > > >> >> Regards, >> >> Le 8 sept. 2013 ? 22:55, Tony Rogvall a ?crit : >> >>> Hi! >>> >>> I dont know who is working on the cerl_inline functionality but it is really intriguing ! >>> I have found some problems doing experiments with (undocumented) compile attributes >>> inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be >>> tested and reworked a bit :-) >>> >>> I am working on a module inline parse transform that I need for speed things up a bit, >>> specially on modules that I think will not change so much over time (think lists module) >>> Also, hipe compile on top of this tends to do marvelous things with performance :-) >>> >>> Any way here is a module that when compiled, first of all warns about some strange things >>> and then generates some "interesting" code. >>> >>> I guess the ones working on this will see what is the problem. And please do NOT remove >>> functionality just because I found it, improve it. I need it :-) >>> >>> Thanks >>> >>> >>> /Tony >>> >>> >>> >>> -module(example3i). >>> >>> -export([run/1]). >>> >>> -compile(inline). >>> -compile({inline_size, 500}). %% default=24 >>> -compile({inline_effort, 500}). %% default=150 >>> %% -compile({inline_unroll, 1}). %% default=1 >>> -compile({verbose,true}). >>> >>> run(V) when is_float(V) -> >>> B = vec3f_new(4,5,6), >>> C = vec3f_new(7,8,9), >>> vec3f_multiply(V,vec3f_add(B,C)). >>> >>> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). >>> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). >>> >>> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> >>> {float(X),float(Y),float(Z)}. >>> >>> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >>> {A1+B1,A2+B2,A3+B3}. >>> >>> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >>> {A1*B1,A2*B2,A3*B3}; >>> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> >>> {A*B1,A*B2,A*B3}; >>> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> >>> {A1*B,A2*B,A3*B}. >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From tony@REDACTED Mon Sep 9 12:58:06 2013 From: tony@REDACTED (Tony Rogvall) Date: Mon, 9 Sep 2013 12:58:06 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <62A9D8A1-ABB5-4276-920E-8008A8354DAD@gmail.com> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> <52F3E884-992C-4976-92CE-2D545FB40CEE@gmail.com> <522D89DD.3080205@erlang.org> <62A9D8A1-ABB5-4276-920E-8008A8354DAD@gmail.com> Message-ID: THAT WAS NOT FUNNY :-) I do not see what low level transformation has to do with anything in the example I sent. It is just a plain module that illustrate some problem with an undocumented feature that I found looking through the code. (Upping the default inline_effort from 24 to say 100 might have exposed it anyway) In the inline transform that I am writing I read forms from the beam files compiled with debug_info and then toss them into the module, cleaning and massaging a bit. It is not on core Erlang level at all. And does not have to be. The rest is passed on to the regular compiler to work on. Regards /Tony On 9 sep 2013, at 10:54, Anthony Ramine wrote: > Hey don't remove Core transforms, I use them :p > > https://github.com/nox/shippai > > -- > Anthony Ramine > > Le 9 sept. 2013 ? 10:42, Bj?rn-Egil Dahlberg a ?crit : > >> On 2013-09-09 08:56, Anthony Ramine wrote: >>> Hi Tony, >>> >>> Btw for low-level transformations, you should rather make a Core Erlang transform, it is way easier to reason about. >> +1, do it in core erlang >> >> or wait that's a novel idea, perhaps we should remove it .. =) >> >> // Bj?rn-Egil >> >> >>> >>> Regards, >>> >>> Le 8 sept. 2013 ? 22:55, Tony Rogvall a ?crit : >>> >>>> Hi! >>>> >>>> I dont know who is working on the cerl_inline functionality but it is really intriguing ! >>>> I have found some problems doing experiments with (undocumented) compile attributes >>>> inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be >>>> tested and reworked a bit :-) >>>> >>>> I am working on a module inline parse transform that I need for speed things up a bit, >>>> specially on modules that I think will not change so much over time (think lists module) >>>> Also, hipe compile on top of this tends to do marvelous things with performance :-) >>>> >>>> Any way here is a module that when compiled, first of all warns about some strange things >>>> and then generates some "interesting" code. >>>> >>>> I guess the ones working on this will see what is the problem. And please do NOT remove >>>> functionality just because I found it, improve it. I need it :-) >>>> >>>> Thanks >>>> >>>> >>>> /Tony >>>> >>>> >>>> >>>> -module(example3i). >>>> >>>> -export([run/1]). >>>> >>>> -compile(inline). >>>> -compile({inline_size, 500}). %% default=24 >>>> -compile({inline_effort, 500}). %% default=150 >>>> %% -compile({inline_unroll, 1}). %% default=1 >>>> -compile({verbose,true}). >>>> >>>> run(V) when is_float(V) -> >>>> B = vec3f_new(4,5,6), >>>> C = vec3f_new(7,8,9), >>>> vec3f_multiply(V,vec3f_add(B,C)). >>>> >>>> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). >>>> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). >>>> >>>> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> >>>> {float(X),float(Y),float(Z)}. >>>> >>>> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >>>> {A1+B1,A2+B2,A3+B3}. >>>> >>>> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >>>> {A1*B1,A2*B2,A3*B3}; >>>> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> >>>> {A*B1,A*B2,A*B3}; >>>> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> >>>> {A1*B,A2*B,A3*B}. >>>> >>>> >>>> _______________________________________________ >>>> erlang-bugs mailing list >>>> erlang-bugs@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-bugs >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Sep 9 13:17:45 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 9 Sep 2013 13:17:45 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> <52F3E884-992C-4976-92CE-2D545FB40CEE@gmail.com> <522D89DD.3080205@erlang.org> <62A9D8A1-ABB5-4276-920E-8008A8354DAD@gmail.com> Message-ID: Replied inline. Sorry for the dupe mail Tony, forgot to reply to all. Le 9 sept. 2013 ? 12:58, Tony Rogvall a ?crit : > THAT WAS NOT FUNNY :-) > > I do not see what low level transformation has to do with anything in > the example I sent. It is just a plain module that illustrate some problem > with an undocumented feature that I found looking through the code. > (Upping the default inline_effort from 24 to say 100 might have exposed it anyway) First I did say "btw" when mentioning the Core transforms, I was not trying to understand the bug itself. The warnings are emitted because the inline code isn't marked as compiler generated and the third clause of the last function is not used in the inlining. As you say, the bug has nothing to do with the undocumented options. > In the inline transform that I am writing I read forms from the beam files compiled with debug_info > and then toss them into the module, cleaning and massaging a bit. It is not on core Erlang level at all. > And does not have to be. The rest is passed on to the regular compiler to work on. The scoping rules and structure of Core Erlang are easier to reason about when transforming code than the ones from Erlang. Even if you get the forms from debug_info nothing forbids you to compile them with {core_transform,SomeCoreTransform}. That's why Erlang's own inliner is a Core pass, not an Erlang one. From n.oxyde@REDACTED Mon Sep 9 14:41:11 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 9 Sep 2013 14:41:11 +0200 Subject: [erlang-bugs] Erlang R16B01: fun syntax and exception error: no case clause matching {location, 1} in function erl_lint:loc/1 (erl_lint.erl, line 577) In-Reply-To: <57DC0061-7CB4-4E68-9C5E-3B2133BC4F6E@lovely.email.ne.jp> References: <57DC0061-7CB4-4E68-9C5E-3B2133BC4F6E@lovely.email.ne.jp> Message-ID: Hello Joseph, This is already fixed in upstream/maint: 2> [ fun x:C/0 || A <- [b] ]. * 1: variable 'C' is unbound Regards, Le 8 sept. 2013 ? 17:43, Joseph Wayne Norton a ?crit : > > Hello. > > I accidentally stumbled upon the crash below with erl_lint:loc/1. I also noticed similar behavior with erlc when compiling a module with this same issue. > > I'm unsure of the expected behavior. > > Best regards, > > Joe N. > > > $ erl > Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] > > Eshell V5.10.2 (abort with ^G) > 1> [ fun x:A/0 || A <- [b] ]. > [#Fun] > 2> [ fun x:C/0 || A <- [b] ]. > ** exception error: no case clause matching {location,1} > in function erl_lint:loc/1 (erl_lint.erl, line 577) > in call from erl_lint:add_error/3 (erl_lint.erl, line 567) > in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) > in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) > in call from lists:foldl/3 (lists.erl, line 1248) > in call from erl_lint:expr/3 (erl_lint.erl, line 2031) > in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) > in call from erl_lint:expr/3 (erl_lint.erl, line 1957) > 3> > > > 3> [ fun x:A/0 || A <- [a] ]. > [#Fun] > 4> [ fun x:L/0 || A <- [a] ]. > ** exception error: no case clause matching {location,1} > in function erl_lint:loc/1 (erl_lint.erl, line 577) > in call from erl_lint:add_error/3 (erl_lint.erl, line 567) > in call from erl_lint:expr_var/4 (erl_lint.erl, line 3049) > in call from erl_lint:'-expr_list/3-fun-0-'/3 (erl_lint.erl, line 2154) > in call from lists:foldl/3 (lists.erl, line 1248) > in call from erl_lint:expr/3 (erl_lint.erl, line 2031) > in call from erl_lint:handle_comprehension/4 (erl_lint.erl, line 2850) > in call from erl_lint:expr/3 (erl_lint.erl, line 1957) > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From sebastian.egner@REDACTED Mon Sep 9 16:20:38 2013 From: sebastian.egner@REDACTED (Sebastian Egner) Date: Mon, 9 Sep 2013 14:20:38 +0000 Subject: [erlang-bugs] bug in HiPE for <<_/utf8,...>> Message-ID: <7A9C4EA7-5ECC-4BB3-B9CC-B605409D96F8@entelios.com> Hi, There seems to be a Heisenbug in HiPE related to matching <<_/utf8,...>>. After a long and bloody fight, we have been able to isolate the problem to the degree that it is sufficiently reproducible. See details below. We strongly suspect that the problem is a genuine bug related to the binary matching and the garbage collector. Whether the bug is hit depends on the memory contents of previously allocated heap-allocated binaries. Best regards, Johannes Weissl and Sebastian Egner. -- Details: - The program 'crash.erl' loads a JSON sample file. Then it parses the file again and again, and after a wildly varying number of iterations (100-100000) the parser fails. - To run the program, execute "crash_it" in a directory containing "crash.erl" and "data.jsn". When the bug is hit, the program stops. This takes several seconds to minutes. - The problem manifests itself when <<"0123...">> does not match <<_/utf8,_/binary>> in the function crash:check_utf8_binary/1. (The program aborts with an exception exit.) - Surprisingly, we have not been able to reduce the program even more. In particular, when randomize_memory/0 is not called, the problem is much less frequent. - The bug is present in R13B02, R14B04, R16B01, "maint" (2f28245) and master (45eaf81). - The bug is present under MacOSX (10.8.4), Debian GNU/Linux and a Linux in an ARM emulator. This indicates that the bug is not related to the operating system platform. - We have run the program in Valgrind and found conditionals that depend on uninitialised values. Refer to "valgrind.out" for details. Attachments: MD5 (crash.erl) = 1f1507c8238e2136d9163314bcac0045 MD5 (crash_it) = 4061276b89dfc822cbfc22002f202358 MD5 (data.jsn) = c5b503cc61d76adc7dcb60832a123b99 MD5 (valgrind.out) = 2e6f67bf06b3df66c6daf728444b9b66 -------------- next part -------------- A non-text attachment was scrubbed... Name: crash_it Type: application/octet-stream Size: 107 bytes Desc: crash_it URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.erl Type: application/octet-stream Size: 4296 bytes Desc: crash.erl URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: data.jsn Type: application/octet-stream Size: 13826 bytes Desc: data.jsn URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: valgrind.out Type: application/octet-stream Size: 1308 bytes Desc: valgrind.out URL: From carlsson.richard@REDACTED Tue Sep 10 13:32:24 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 10 Sep 2013 13:32:24 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> Message-ID: <522F0348.2040109@gmail.com> Ah, memories! It was a long time since I implemented that stuff, and I never got the unrolling to work quite as I expected it to. I think the paper that the algorithm comes from just talked breifly about allowing unrolling, and I saw it as a feature that would be nice if it worked but not critical, and I didn't have time to fiddle too much with it. If someone wants to do some more work on that stuff, you're very welcome. (Manual unrolling experiments to the depth of 5-10 used to show a significant speedup in tight loops, even without native compilation, mainly because you avoid reducing and testing the reduction counter for each step. Combine that with the inline_list_funcs compiler flags and you should get pretty nice code.) /Richard On 2013-09-08 22:55 , Tony Rogvall wrote: > Hi! > > I dont know who is working on the cerl_inline functionality but it is really intriguing ! > I have found some problems doing experiments with (undocumented) compile attributes > inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be > tested and reworked a bit :-) > > I am working on a module inline parse transform that I need for speed things up a bit, > specially on modules that I think will not change so much over time (think lists module) > Also, hipe compile on top of this tends to do marvelous things with performance :-) > > Any way here is a module that when compiled, first of all warns about some strange things > and then generates some "interesting" code. > > I guess the ones working on this will see what is the problem. And please do NOT remove > functionality just because I found it, improve it. I need it :-) > > Thanks > > > /Tony > > > > -module(example3i). > > -export([run/1]). > > -compile(inline). > -compile({inline_size, 500}). %% default=24 > -compile({inline_effort, 500}). %% default=150 > %% -compile({inline_unroll, 1}). %% default=1 > -compile({verbose,true}). > > run(V) when is_float(V) -> > B = vec3f_new(4,5,6), > C = vec3f_new(7,8,9), > vec3f_multiply(V,vec3f_add(B,C)). > > -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). > -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). > > vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> > {float(X),float(Y),float(Z)}. > > vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> > {A1+B1,A2+B2,A3+B3}. > > vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> > {A1*B1,A2*B2,A3*B3}; > vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> > {A*B1,A*B2,A*B3}; > vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> > {A1*B,A2*B,A3*B}. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From tony@REDACTED Tue Sep 10 13:42:54 2013 From: tony@REDACTED (Tony Rogvall) Date: Tue, 10 Sep 2013 13:42:54 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <522F0348.2040109@gmail.com> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> <522F0348.2040109@gmail.com> Message-ID: <3CC4CDFC-2B7E-4AED-8BB5-E61AD573F873@rogvall.se> Ah! Its you again! :-) I have problems with the value inline_effort, it looks like the inliner (or later pass) leave unoptimised code after running an otherwise successful inlining. The unrolling is a really cool thing, but a bit hard to control (for me) I have successfully unrolled a number of examples and I think it has a great potential in things like code generation and module specialization etc. Some of my examples lead to (nearly) infinite speedup, the result is a precomputed module constant :-) Who in the OTP team is handling this kind of fun stuff now-a-days ? Tanks /Tony On 10 sep 2013, at 13:32, Richard Carlsson wrote: > Ah, memories! It was a long time since I implemented that stuff, and I never got the unrolling to work quite as I expected it to. I think the paper that the algorithm comes from just talked breifly about allowing unrolling, and I saw it as a feature that would be nice if it worked but not critical, and I didn't have time to fiddle too much with it. If someone wants to do some more work on that stuff, you're very welcome. (Manual unrolling experiments to the depth of 5-10 used to show a significant speedup in tight loops, even without native compilation, mainly because you avoid reducing and testing the reduction counter for each step. Combine that with the inline_list_funcs compiler flags and you should get pretty nice code.) > > /Richard > > On 2013-09-08 22:55 , Tony Rogvall wrote: >> Hi! >> >> I dont know who is working on the cerl_inline functionality but it is really intriguing ! >> I have found some problems doing experiments with (undocumented) compile attributes >> inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be >> tested and reworked a bit :-) >> >> I am working on a module inline parse transform that I need for speed things up a bit, >> specially on modules that I think will not change so much over time (think lists module) >> Also, hipe compile on top of this tends to do marvelous things with performance :-) >> >> Any way here is a module that when compiled, first of all warns about some strange things >> and then generates some "interesting" code. >> >> I guess the ones working on this will see what is the problem. And please do NOT remove >> functionality just because I found it, improve it. I need it :-) >> >> Thanks >> >> >> /Tony >> >> >> >> -module(example3i). >> >> -export([run/1]). >> >> -compile(inline). >> -compile({inline_size, 500}). %% default=24 >> -compile({inline_effort, 500}). %% default=150 >> %% -compile({inline_unroll, 1}). %% default=1 >> -compile({verbose,true}). >> >> run(V) when is_float(V) -> >> B = vec3f_new(4,5,6), >> C = vec3f_new(7,8,9), >> vec3f_multiply(V,vec3f_add(B,C)). >> >> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). >> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). >> >> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> >> {float(X),float(Y),float(Z)}. >> >> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >> {A1+B1,A2+B2,A3+B3}. >> >> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >> {A1*B1,A2*B2,A3*B3}; >> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> >> {A*B1,A*B2,A*B3}; >> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> >> {A1*B,A2*B,A3*B}. >> >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Sep 10 13:47:53 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 10 Sep 2013 13:47:53 +0200 Subject: [erlang-bugs] inline & inline_effort In-Reply-To: <3CC4CDFC-2B7E-4AED-8BB5-E61AD573F873@rogvall.se> References: <2A020870-B2D1-4530-8148-540BFCF96824@rogvall.se> <522F0348.2040109@gmail.com> <3CC4CDFC-2B7E-4AED-8BB5-E61AD573F873@rogvall.se> Message-ID: <522F06E9.7040902@erlang.org> On 2013-09-10 13:42, Tony Rogvall wrote: > Ah! Its you again! :-) > > I have problems with the value inline_effort, it looks like the > inliner (or later pass) leave unoptimised code > after running an otherwise successful inlining. > > The unrolling is a really cool thing, but a bit hard to control (for me) > I have successfully unrolled a number of examples and I think it has a > great > potential in things like code generation and module specialization etc. > > Some of my examples lead to (nearly) infinite speedup, the result is a > precomputed > module constant :-) > > Who in the OTP team is handling this kind of fun stuff now-a-days ? The compiler is nearly exclusively Bj?rns area, although there are a few padawans around also =) If a concise requirement is done, we can estimate and prioritize it. But if you really want it in it is probably best to send a patch for it. Bj?rn is a bit picky though so you better come prepared =D // Bj?rn-Egil > > Tanks > > /Tony > > On 10 sep 2013, at 13:32, Richard Carlsson > wrote: > >> Ah, memories! It was a long time since I implemented that stuff, and >> I never got the unrolling to work quite as I expected it to. I think >> the paper that the algorithm comes from just talked breifly about >> allowing unrolling, and I saw it as a feature that would be nice if >> it worked but not critical, and I didn't have time to fiddle too much >> with it. If someone wants to do some more work on that stuff, you're >> very welcome. (Manual unrolling experiments to the depth of 5-10 used >> to show a significant speedup in tight loops, even without native >> compilation, mainly because you avoid reducing and testing the >> reduction counter for each step. Combine that with the >> inline_list_funcs compiler flags and you should get pretty nice code.) >> >> /Richard >> >> On 2013-09-08 22:55 , Tony Rogvall wrote: >>> Hi! >>> >>> I dont know who is working on the cerl_inline functionality but it >>> is really intriguing ! >>> I have found some problems doing experiments with (undocumented) >>> compile attributes >>> inline_effort and inline_unroll. No No No do not remove them!!!! >>> They just needs to be >>> tested and reworked a bit :-) >>> >>> I am working on a module inline parse transform that I need for >>> speed things up a bit, >>> specially on modules that I think will not change so much over time >>> (think lists module) >>> Also, hipe compile on top of this tends to do marvelous things with >>> performance :-) >>> >>> Any way here is a module that when compiled, first of all warns >>> about some strange things >>> and then generates some "interesting" code. >>> >>> I guess the ones working on this will see what is the problem. And >>> please do NOT remove >>> functionality just because I found it, improve it. I need it :-) >>> >>> Thanks >>> >>> >>> /Tony >>> >>> >>> >>> -module(example3i). >>> >>> -export([run/1]). >>> >>> -compile(inline). >>> -compile({inline_size, 500}). %% default=24 >>> -compile({inline_effort, 500}). %% default=150 >>> %% -compile({inline_unroll, 1}). %% default=1 >>> -compile({verbose,true}). >>> >>> run(V) when is_float(V) -> >>> B = vec3f_new(4,5,6), >>> C = vec3f_new(7,8,9), >>> vec3f_multiply(V,vec3f_add(B,C)). >>> >>> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)). >>> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)). >>> >>> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) -> >>> {float(X),float(Y),float(Z)}. >>> >>> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >>> {A1+B1,A2+B2,A3+B3}. >>> >>> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB -> >>> {A1*B1,A2*B2,A3*B3}; >>> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB -> >>> {A*B1,A*B2,A*B3}; >>> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA -> >>> {A1*B,A2*B,A3*B}. >>> >>> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> > > "Installing applications can lead to corruption over time. > Applications gradually write over each other's libraries, partial > upgrades occur, user and system errors happen, and minute changes may > be unnoticeable and difficult to fix" > > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Schlager@REDACTED Wed Sep 11 09:21:16 2013 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Wed, 11 Sep 2013 07:21:16 +0000 Subject: [erlang-bugs] gen_server:multi_call/4 and Java nodes Message-ID: <12F2115FD1CCEE4294943B2608A18FA3AEAF9EB4@MAIL01.win.lbaum.eu> Hi, I ran into a problem with rpc:multicall/5 on hidden nodes yesterday. Despite specifying a timeout value the call hangs infinitly. Most certainly, I managed to locate the problem in gen_server:multi_call/4. I made an RPC with Nodes = [node() | nodes(connected)] (including hidden nodes). This (accidentially) also took some hidden Java nodes into account. Looking at the code in gen_server:start_monitor/2, the Java node does fall in the same category of nodes than a node running R6. However, when the timer expires in the R6 clause of gen_server:rec_nodes/7, the code issues an RPC with timeout infinity to find out whether the rex server is alive on the remote node. This RPC call blocks forever when it is applied to a Java node (this most probably also applies to C nodes). In my opinion, a hanging RPC call for whatever reason is always acceptable, when the user does not provide a timeout value. However, I would strongly expect an RPC to fail, when it can't succeed within a given timeout regardless what node it was applied to. This is why I decided to post this to the bug list. Regards Tobias From andrew@REDACTED Fri Sep 13 08:23:53 2013 From: andrew@REDACTED (Andrew Thompson) Date: Fri, 13 Sep 2013 02:23:53 -0400 Subject: [erlang-bugs] R16B01's monitor delivery is broken? In-Reply-To: <78E4CAE9-38E9-4050-97BF-395A63BD7406@gmail.com> References: <15464.1374612273@snookles.snookles.com> <51FAA1F7.8000704@erlang.org> <51FAA754.6090600@erlang.org> <78E4CAE9-38E9-4050-97BF-395A63BD7406@gmail.com> Message-ID: <20130913062353.GG10745@hijacked.us> Did a patch for this ever land on Github for R16B02? Andrew From wallentin.dahlberg@REDACTED Fri Sep 13 08:33:10 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Fri, 13 Sep 2013 08:33:10 +0200 Subject: [erlang-bugs] R16B01's monitor delivery is broken? In-Reply-To: <20130913062353.GG10745@hijacked.us> References: <15464.1374612273@snookles.snookles.com> <51FAA1F7.8000704@erlang.org> <51FAA754.6090600@erlang.org> <78E4CAE9-38E9-4050-97BF-395A63BD7406@gmail.com> <20130913062353.GG10745@hijacked.us> Message-ID: Yes! See https://github.com/erlang/otp/commit/f499b39ddc5025074c5d22f272f1dd55df79f009 Has ticket OTP-11225 in R16B02. // Bj?rn-Egil 2013/9/13 Andrew Thompson > Did a patch for this ever land on Github for R16B02? > > Andrew > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Sep 13 11:55:30 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Sep 2013 11:55:30 +0200 Subject: [erlang-bugs] R16B01's monitor delivery is broken? In-Reply-To: References: <15464.1374612273@snookles.snookles.com> <51FAA1F7.8000704@erlang.org> <51FAA754.6090600@erlang.org> <78E4CAE9-38E9-4050-97BF-395A63BD7406@gmail.com> <20130913062353.GG10745@hijacked.us> Message-ID: <4957735E-0210-4F28-A93A-70C5A8BD947D@gmail.com> Thanks for the explanation in the commit message, that's really appreciated :) Le 13 sept. 2013 ? 08:33, Bj?rn-Egil Dahlberg a ?crit : > Yes! > > See https://github.com/erlang/otp/commit/f499b39ddc5025074c5d22f272f1dd55df79f009 > > Has ticket OTP-11225 in R16B02. > > // Bj?rn-Egil > > > 2013/9/13 Andrew Thompson > Did a patch for this ever land on Github for R16B02? > > Andrew > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From Ingela.Anderton.Andin@REDACTED Fri Sep 13 15:57:01 2013 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Fri, 13 Sep 2013 15:57:01 +0200 Subject: [erlang-bugs] httpc:request_cancel oddities In-Reply-To: <522EE3CD.2020707@ericsson.com> References: <522EE3CD.2020707@ericsson.com> Message-ID: <523319AD.5090807@ericsson.com> Hi! On the branch http-client-cancel-request in my git repository I have addressed the issues you reported on request cancellation and pipelining. Alas it was not in time for R16B02 but will probably be merged to the maint branch soon after ... https://github.com/IngelaAndin/otp/compare/ia;inets;http-client-cancel-request Of course it passes our tests but all extra testing of this is welcome. Regards Ingela Erlang/OTP team - Ericsson AB From robert.virding@REDACTED Tue Sep 17 16:11:03 2013 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 17 Sep 2013 16:11:03 +0200 (CEST) Subject: [erlang-bugs] erl_eval funs In-Reply-To: <20130907155556.GA13437@ferdmbp.local> References: <20130907155556.GA13437@ferdmbp.local> Message-ID: <1585290734.179412.1379427063058.JavaMail.zimbra@erlang-solutions.com> I just saw this. How could shell ever realise that you are referring to an internal function inside an unspecified module? The fun returned by m:f() contains this information. Robert ----- Original Message ----- > From: "Fred Hebert" > To: "Tony Rogvall" > Cc: "erlang-bugs Bugs" > Sent: Saturday, 7 September, 2013 5:55:57 PM > Subject: Re: [erlang-bugs] erl_eval funs > > This is a 'problem' for all funs going in the shell and evaluator, and > they also hit escripts without a module name. > > It's about a fun of that type being seen as a local one rather than an > auto-imported one, and so they get attached to erl_eval like other > evaluated funs. This works with any other auto-imported function in the > shell (say process_info/1-2). > > I guess there needs to be an extension to the entire chain to fix this. > > Regards, > Fred. > > On 09/07, Tony Rogvall wrote: > > R16B01 > > > > The following code compile and works when in a module: > > > > -module(m). > > -export([f/0]). > > > > f() -> > > fun abs/1. > > > > > (m:f())(-3). > > 3 > > > > But > > > > (fun abs/1)(-3). > > ** exception error: undefined function erl_eval:abs/1 > > > > > > /Tony > > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://erlang.org/mailman/listinfo/erlang-bugs > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From tuncer.ayaz@REDACTED Wed Sep 18 21:10:25 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 18 Sep 2013 21:10:25 +0200 Subject: [erlang-bugs] diameter_sctp:connect_option/0 references unknown type Message-ID: The type definition of diameter_sctp:connect_option/0 in OTP_R16B02 references the unknown type gen_sctp:open_option/0. I didn't provide a patch because I'm uncertain about the right fix. From anders.otp@REDACTED Thu Sep 19 09:12:43 2013 From: anders.otp@REDACTED (Anders Svensson) Date: Thu, 19 Sep 2013 09:12:43 +0200 Subject: [erlang-bugs] diameter_sctp:connect_option/0 references unknown type In-Reply-To: References: Message-ID: This is the same problem you noticed with R16B01 back in June I'm afraid. There is a ticket on adding type gen_sctp:open_option/0 but it's simply fallen between the cracks. (Aka, I wrote the ticket when it wasn't obvious to me how to update the doc and then promptly forgot about it.) Anders, Erlang/OTP On Wed, Sep 18, 2013 at 9:10 PM, Tuncer Ayaz wrote: > The type definition of diameter_sctp:connect_option/0 in > OTP_R16B02 references the unknown type gen_sctp:open_option/0. I > didn't provide a patch because I'm uncertain about the right fix. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From flw@REDACTED Tue Sep 24 18:43:36 2013 From: flw@REDACTED (Florian Waas) Date: Tue, 24 Sep 2013 09:43:36 -0700 Subject: [erlang-bugs] ELDAP: peer verification fails due to mangled SSL options Message-ID: Moving this over to the bugs mailing list. The fix is to remove the {verify, 0} prefix as mentioned below. Regards, -fl. ---- Currently, eldap does not support peer verification (equivalent to ldap.conf's TLS_REQCERT). Turns out eldap:do_connect/3 always prefixes the caller's ssl options with {verify, 0} under the covers which renders a {verify, verify_peer} from the caller ineffective: https://github.com/erlang/otp/blob/maint/lib/eldap/src/eldap.erl#L392 As far as I can tell, there's no good/obvious reason for this -- and after removing this automatic prefix, it works as one would expect. Just a bug or anybody know of some rationale why verification is prevented this way? -fl. -------------- next part -------------- An HTML attachment was scrubbed... URL: From while1eq1.lists@REDACTED Thu Sep 26 07:36:39 2013 From: while1eq1.lists@REDACTED (while1eq1) Date: Thu, 26 Sep 2013 01:36:39 -0400 Subject: [erlang-bugs] Error when building erlang on opensolaris Message-ID: When I go to build the latest version of erlang on opensolaris I encounter the following error: drivers/common/inet_drv.c:5316: error: structure has no member named `sa_family' drivers/common/inet_drv.c:5318: error: structure has no member named `sa_family' drivers/common/inet_drv.c:5321: warning: passing arg 1 of `sockaddr_to_buf' from incompatible pointer type drivers/common/inet_drv.c:5324: warning: passing arg 1 of `sockaddr_to_buf' from incompatible pointer type drivers/common/inet_drv.c:5329: warning: passing arg 1 of `sockaddr_to_buf' from incompatible pointer type drivers/common/inet_drv.c:5333: warning: passing arg 1 of `sockaddr_to_buf' from incompatible pointer type drivers/common/inet_drv.c:5339: error: structure has no member named `sa_family' drivers/common/inet_drv.c:5344: error: structure has no member named `sa_family' drivers/common/inet_drv.c:5349: warning: passing arg 1 of `sockaddr_to_buf' from incompatible pointer type Ive spent several hours thus far trying to solve this and was unsuccessful thus far. Any help would be greatly appreciated. Thanks From Ingela.Anderton.Andin@REDACTED Thu Sep 26 15:13:48 2013 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Thu, 26 Sep 2013 15:13:48 +0200 Subject: [erlang-bugs] ELDAP: peer verification fails due to mangled SSL options In-Reply-To: References: Message-ID: <5244330C.1040306@ericsson.com> Hi! I think it should be considered a bug, and removed as you suggested. Regards Ingela Erlang/OTP team - Ericsson AB On 09/24/2013 06:43 PM, Florian Waas wrote: > Moving this over to the bugs mailing list. The fix is to remove the > {verify, 0} prefix as mentioned below. > > Regards, > -fl. > > ---- > > Currently, eldap does not support peer verification (equivalent > to ldap.conf's TLS_REQCERT). > > Turns out eldap:do_connect/3 always prefixes the caller's ssl options > with {verify, 0} under the covers which renders a {verify, verify_peer} > from the caller ineffective: > > https://github.com/erlang/otp/blob/maint/lib/eldap/src/eldap.erl#L392 > > As far as I can tell, there's no good/obvious reason for this -- and > after removing this automatic prefix, it works as one would expect. > > > Just a bug or anybody know of some rationale why verification is > prevented this way? > > > -fl. > > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs >