From fredrik@REDACTED Mon Jul 1 11:23:45 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 1 Jul 2013 11:23:45 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> Message-ID: <51D14AA1.2000508@erlang.org> On 06/06/2013 01:47 AM, Anthony Ramine wrote: > Hello, > > When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old > unused variables are not recorded as such: > > t(X, Y) -> > #r{a=[ K || K<- Y ],b=[ K || K<- Y ]. > > As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. > > The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: > > t(X, Y) -> > #r{a=A=X,b=A=Y}. > > Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. > > This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. > > git fetch https://github.com/nox/otp.git fix-erl_lint-variable-usage > > https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage > https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch > > Regards, > Hi Anthony, Your patch has been reviewed and the feedback was: " Hi, The first example of the commit messages lacks a '}' before the dot. I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? Best regards, " -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.aloi@REDACTED Mon Jul 1 10:17:08 2013 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Mon, 1 Jul 2013 09:17:08 +0100 (BST) Subject: [erlang-patches] Remove trailing spaces in Emacs skeletons In-Reply-To: <651084424.18696892.1372665164882.JavaMail.root@erlang-solutions.com> Message-ID: <603451168.18713928.1372666628423.JavaMail.root@erlang-solutions.com> Hi all, Remove trailing spaces in Emacs skeletons for gen_server and gen_event: git fetch git://github.com/robertoaloi/otp.git trailing-spaces-emacs-skels https://github.com/robertoaloi/otp/compare/erlang:maint...trailing-spaces-emacs-skels https://github.com/robertoaloi/otp/compare/erlang:maint...trailing-spaces-emacs-skels.patch Kind regards, Roberto Aloi --- Erlang Solutions Ltd. www.erlang-solutions.com From fredrik@REDACTED Mon Jul 1 15:27:43 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 1 Jul 2013 15:27:43 +0200 Subject: [erlang-patches] Remove trailing spaces in Emacs skeletons In-Reply-To: <603451168.18713928.1372666628423.JavaMail.root@erlang-solutions.com> References: <603451168.18713928.1372666628423.JavaMail.root@erlang-solutions.com> Message-ID: <51D183CF.5030604@erlang.org> On 07/01/2013 10:17 AM, Roberto Aloi wrote: > Hi all, > > Remove trailing spaces in Emacs skeletons for gen_server and gen_event: > > git fetch git://github.com/robertoaloi/otp.git trailing-spaces-emacs-skels > > https://github.com/robertoaloi/otp/compare/erlang:maint...trailing-spaces-emacs-skels > https://github.com/robertoaloi/otp/compare/erlang:maint...trailing-spaces-emacs-skels.patch > > Kind regards, > > Roberto Aloi > --- > Erlang Solutions Ltd. > www.erlang-solutions.com > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Roberto, I've fetched your patch and it should soon be visible in the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Mon Jul 1 19:08:04 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 1 Jul 2013 19:08:04 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler crash with 'inline_list_funcs' and "fun Fun/Arity" notation In-Reply-To: <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> References: <5195F094.2010003@ymir.co.jp> <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> Message-ID: Hello Bj?rn, I've amended my commit, please refetch. Regards, -- Anthony Ramine Le 26 juin 2013 ? 14:52, Anthony Ramine a ?crit : > Will amend. > > -- > Anthony Ramine > > Le 26 juin 2013 ? 14:43, Bj?rn Gustavsson a ?crit : > >> Thanks! Looks good. I have only two slight comments: >> >> If find the first sentence in the commit message confusing: >> >> "Local fun references look like plain old variables in the Core Erlang >> AST and should not be treated as such." >> >> I would suggest "but" instead of "and": >> >> "Local fun references look like plain old variables in the Core Erlang >> AST, but should not be treated as such." >> >> The test cases tests that the compiler does not crash and that >> the code can be loaded, but it does not test that the code actually >> works. I suggest that you rewrite it to something like this: >> >> ?MODULE() -> >> F = fun bar/1, >> G = lists:last([(fun (X) when F =:= X -> X end)]), >> F = G(F), >> ok. >> >> bar(X) -> >> X. >> >> /Bjorn >> >> >> >> On Sat, May 18, 2013 at 6:22 PM, Anthony Ramine wrote: >> Hello, >> >> This patch fixes the bug by forbidding inlining of variables which values are local fun references outside of application contexts. >> >> git fetch https://github.com/nox/otp.git fix-fname-inlining >> >> https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining >> https://github.com/nox/otp/compare/erlang:maint...fix-fname-inlining.patch >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 17 mai 2013 ? 20:06, Anthony Ramine a ?crit : >> >>> Hello, >>> >>> Shorter test case, showing the problem comes from the inline itself and not inline_list_funcs: >>> >>> -module(test). >>> -compile(inline). >>> -export([foo/0]). >>> >>> foo() -> >>> F = fun bar/1, >>> fun (X) when X =:= F -> X end. >>> >>> bar(X) -> X. >>> >>> If you run the core_lint pass, you can see where the problem comes from: >>> >>> $ erlc +clint test.erl >>> test: illegal guard expression in foo/0 >>> >>> The inliner inlines `when 'erlang':'=:='(X, F)` to `'erlang':'=:='(X, 'bar'/1)` but local fun references can't appear in guards. >>> >>> I'll try to make a patch. >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >>> Le 17 mai 2013 ? 10:55, Masatake Daimon a ?crit : >>> >>>> Hello, >>>> >>>> Compiling the following module makes the compiler crash. I'm using >>>> R16B. >>>> >>>> ===== test.erl ===== >>>> -module(test). >>>> -compile(inline). >>>> -compile(inline_list_funcs). >>>> -export([foo/0]). >>>> >>>> foo() -> >>>> lists:map(fun bar/1, [1]). >>>> >>>> bar(X) -> X. >>>> >>>> ===== the crash ==== >>>> % erlc test.erl >>>> test: function '-foo/0-lists^map/1-0-'/1+15: >>>> Internal consistency check failed - please report this bug. >>>> Instruction: {move,{x,0},{yy,0}} >>>> Error: {invalid_store,{yy,0},term}: >>>> >>>> >>>> Note that the problem disappears with any of these changes: >>>> >>>> * Commenting out "-compile(inline)." >>>> * Commenting out "-compile(inline_list_funcs)." >>>> * Changing the definition of foo/0 to: >>>> foo() -> >>>> lists:map(fun bar/1, []). % [] instead of [1] >>>> * Changing the definition of foo/0 to: >>>> foo() -> >>>> lists:map(fun (A) -> bar(A) end, [1]). >>>> >>>> Regards, >>>> -- >>>> ?? ?? >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > From n.oxyde@REDACTED Mon Jul 1 19:30:07 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 1 Jul 2013 19:30:07 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler/linter bug breaking unused variable warnings In-Reply-To: <51D14AA1.2000508@erlang.org> References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> Message-ID: Hi Fredrik, I've amended the commit message and gave an example of a simpler expression triggering the bug, e.g.: t(X, Y) -> {A=X,A=Y}. As for the vt_no_unused/1 call in expr_list/1, it is a mistake as Vt1 comes from the variable tables returned by expr/3 in the lists:foldl/3 call, which means it can't contain any old variable which was unused anyway. Regards, -- Anthony Ramine Le 1 juil. 2013 ? 11:23, Fredrik a ?crit : > On 06/06/2013 01:47 AM, Anthony Ramine wrote: >> Hello, >> >> When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old >> unused variables are not recorded as such: >> >> t(X, Y) -> >> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. >> >> As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. >> >> The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: >> >> t(X, Y) -> >> #r{a=A=X,b=A=Y}. >> >> Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. >> >> This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. >> >> git fetch >> https://github.com/nox/otp.git >> fix-erl_lint-variable-usage >> >> >> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage >> >> >> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch >> >> >> Regards, >> >> > Hi Anthony, > Your patch has been reviewed and the feedback was: > > " > Hi, > > The first example of the commit messages lacks a '}' before the dot. > > I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) > > I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? > > Best regards, > > " > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From fredrik@REDACTED Tue Jul 2 09:19:12 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Jul 2013 09:19:12 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler crash with 'inline_list_funcs' and "fun Fun/Arity" notation In-Reply-To: References: <5195F094.2010003@ymir.co.jp> <21AE91E1-9EF1-41B8-913E-AC0C959AC3F7@gmail.com> <599774A3-5492-4D15-9EC3-860BE4A9D484@gmail.com> Message-ID: <51D27EF0.6040805@erlang.org> On 07/01/2013 07:08 PM, Anthony Ramine wrote: > Hello Bj?rn, > > I've amended my commit, please refetch. > > Regards, > Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Tue Jul 2 10:12:29 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 2 Jul 2013 10:12:29 +0200 Subject: [erlang-patches] [eeps] EEP37: Funs with names In-Reply-To: References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> <514981E0.9030209@erlang.org> <806DFCE7-CC09-46F9-8B71-F97CE9E04A39@gmail.com> <5149C8AE.8030509@erlang.org> Message-ID: Did you discuss it yet? :) -- Anthony Ramine Le 19 juin 2013 ? 15:16, Bj?rn Gustavsson a ?crit : > The OTP Technical Board will discuss EEP37 > at its next meeting. > > > On Fri, Jun 7, 2013 at 6:24 PM, Anthony Ramine wrote: > Ping? > > -- > Anthony Ramine > > Le 21 avr. 2013 ? 22:17, Anthony Ramine a ?crit : > > > Hello, > > > > Any ETA for a review? > > > > Regards, > > > > On Wed, Mar 20, 2013 at 3:33 PM, Fredrik wrote: > >> On 03/20/2013 03:30 PM, Anthony Ramine wrote: > >>> > >>> Rebased! :) > >>> > >>> Does it mean it may be included before R17? Branch maint is for minor > >>> releases, right? > >>> > >> Right now im collecting all the patches active at the moment in pu. That > >> does not mean it will be included in a minor release. :) > >> > >> -- > >> > >> BR Fredrik Gustafsson > >> Erlang OTP Team > >> > > _______________________________________________ > eeps mailing list > eeps@REDACTED > http://erlang.org/mailman/listinfo/eeps > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Tobias.Schlager@REDACTED Thu Jul 4 16:44:12 2013 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Thu, 4 Jul 2013 14:44:12 +0000 Subject: [erlang-patches] Supervisor shutdown reason when reaching max restarts Message-ID: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu> Hi, this patch changes the behaviour of supervisors to exit with a more specific reason when exiting due to a maximum restart limit hit. This is especially useful (or even necessary) to distinguish between normal and erroneous process terminations when monitoring a supervisor from another process. In the above case a supervisor would now exit with {shutdown, {reached_max_restart_intensity, Child}} where Child is whatever is available to describe the child, either a child id or in case of a simple_one_for_one supervisor the offending child's process id. The patch should not affect the OTP restart behaviour (also for cascaded supervisors) since a subclass of 'normal' exit reasons is used. I'm aware that there is some potential backward incompatibility for people that do not expect {shutdown, Reason} when monitoring a supervisor. However, the feature of exiting normally with {shutdown, Reason} has been around for quite a while now and I think this could be a sensible place to use it. Let me know what you think. The patch does include tests and updated documentation. git fetch https://github.com/schlagert/otp.git supervisor_shutdown_reason https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason.patch Regards Tobias From fredrik@REDACTED Thu Jul 4 17:33:57 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 4 Jul 2013 17:33:57 +0200 Subject: [erlang-patches] Supervisor shutdown reason when reaching max restarts In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu> Message-ID: <51D595E5.70507@erlang.org> On 07/04/2013 04:44 PM, Tobias Schlager wrote: > Hi, > > this patch changes the behaviour of supervisors to exit with a more specific reason when exiting due to a maximum restart limit hit. This is especially useful (or even necessary) to distinguish between normal and erroneous process terminations when monitoring a supervisor from another process. > > In the above case a supervisor would now exit with {shutdown, {reached_max_restart_intensity, Child}} where Child is whatever is available to describe the child, either a child id or in case of a simple_one_for_one supervisor the offending child's process id. The patch should not affect the OTP restart behaviour (also for cascaded supervisors) since a subclass of 'normal' exit reasons is used. > > I'm aware that there is some potential backward incompatibility for people that do not expect {shutdown, Reason} when monitoring a supervisor. However, the feature of exiting normally with {shutdown, Reason} has been around for quite a while now and I think this could be a sensible place to use it. Let me know what you think. > > The patch does include tests and updated documentation. > > git fetch https://github.com/schlagert/otp.git supervisor_shutdown_reason > > https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason > https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason.patch > > Regards > Tobias > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Tobias, I've fetched your patch and assigned it to be reviewed by responsible team. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From jargon@REDACTED Fri Jul 5 16:47:35 2013 From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=) Date: Fri, 5 Jul 2013 16:47:35 +0200 Subject: [erlang-patches] Fix run_erl daemonizing on some platforms Message-ID: <20130705144735.GA30318@molb.org> Hello, On our embedded system "run_erl" does not work when used with the "-daemon" option (the logs show "Cannot dup"). I noticed that unlike erlexec and epmd, run_erl does not redirect the standard streams to /dev/null after closing them. This patch adds the redirection to /dev/null, which fixes the problem. git fetch git://github.com/weisslj/otp.git run-erl-redirect-dev-null https://github.com/weisslj/otp/compare/erlang:maint...run-erl-redirect-dev-null https://github.com/weisslj/otp/compare/erlang:maint...run-erl-redirect-dev-null.patch Greetings, Johannes Wei?l From fredrik@REDACTED Fri Jul 5 16:54:57 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 5 Jul 2013 16:54:57 +0200 Subject: [erlang-patches] Fix run_erl daemonizing on some platforms In-Reply-To: <20130705144735.GA30318@molb.org> References: <20130705144735.GA30318@molb.org> Message-ID: <51D6DE41.6020008@erlang.org> On 07/05/2013 04:47 PM, Johannes Wei?l wrote: > Hello, > > On our embedded system "run_erl" does not work when used with the > "-daemon" option (the logs show "Cannot dup"). I noticed that unlike > erlexec and epmd, run_erl does not redirect the standard streams to > /dev/null after closing them. > > This patch adds the redirection to /dev/null, which fixes the problem. > > git fetch git://github.com/weisslj/otp.git run-erl-redirect-dev-null > > https://github.com/weisslj/otp/compare/erlang:maint...run-erl-redirect-dev-null > https://github.com/weisslj/otp/compare/erlang:maint...run-erl-redirect-dev-null.patch > > Greetings, > > Johannes Wei?l > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Johannes, I've created a pull request on github and some initial tests will be done on the patch before the responsible team will look at it. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From jargon@REDACTED Sat Jul 6 13:42:42 2013 From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=) Date: Sat, 6 Jul 2013 13:42:42 +0200 Subject: [erlang-patches] Fix run_erl daemonizing on some platforms In-Reply-To: <51D6DE41.6020008@erlang.org> References: <20130705144735.GA30318@molb.org> <51D6DE41.6020008@erlang.org> Message-ID: <20130706114242.GA16453@molb.org> Hello Fredrik, On Fri, Jul 05, 2013 at 04:54:57PM +0200, Fredrik wrote: > I've created a pull request on github and some initial tests will be > done on the patch before the responsible team will look at it. Thanks! I noticed the README / Wiki has been changed regarding pull requests. Should I open a pull request by myself in the future after sending patches to the mailing list? Or is it better for small fixes like this to just send a pull request? Regards, Johannes From fredrik@REDACTED Mon Jul 8 09:20:01 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 8 Jul 2013 09:20:01 +0200 Subject: [erlang-patches] Fix run_erl daemonizing on some platforms In-Reply-To: <20130706114242.GA16453@molb.org> References: <20130705144735.GA30318@molb.org> <51D6DE41.6020008@erlang.org> <20130706114242.GA16453@molb.org> Message-ID: <51DA6821.5050806@erlang.org> On 07/06/2013 01:42 PM, Johannes Wei?l wrote: > Hello Fredrik, > > On Fri, Jul 05, 2013 at 04:54:57PM +0200, Fredrik wrote: >> I've created a pull request on github and some initial tests will be >> done on the patch before the responsible team will look at it. > Thanks! I noticed the README / Wiki has been changed regarding pull > requests. Should I open a pull request by myself in the future after > sending patches to the mailing list? Or is it better for small fixes > like this to just send a pull request? > > Regards, > Johannes > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches For smaller fixes it is better if you create a pull request. For a bigger change or a new feature, it is better if you send a mail that you usually send, and we'll take a decision from there. -- BR Fredrik Gustafsson Erlang OTP Team From bgustavsson@REDACTED Mon Jul 8 12:02:12 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 8 Jul 2013 12:02:12 +0200 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: References: Message-ID: On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine wrote: > > To choose a format, Rosetta Code was my main source of inspiration [1]. > > We think that it would be better if the stack traces would have the same format as in the shell. /Bj?rn -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Jul 8 12:11:00 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 8 Jul 2013 12:11:00 +0200 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: References: Message-ID: Ok. What about the eunit stacktraces? -- Anthony Ramine Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit : > On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine wrote: > > To choose a format, Rosetta Code was my main source of inspiration [1]. > > > We think that it would be better if the stack traces would have the > same format as in the shell. > > /Bj?rn > From bgustavsson@REDACTED Mon Jul 8 12:25:24 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 8 Jul 2013 12:25:24 +0200 Subject: [erlang-patches] Silence a misleading warning with some comprehensions In-Reply-To: References: Message-ID: Looks good. On Thu, Jun 6, 2013 at 10:55 PM, Anthony Ramine wrote: > Hello, > > When compiling comprehensions with generators which are foldable to > 'true', a misleading warning is emitted by sys_core_fold because a clause > resulting from the compilation of the comprehension to Core Erlang is not > marked as generated by the compiler. > > An example of such a comprehension is [ true || true ]. > > git fetch https://github.com/nox/otp.git fix-comp-warnings > > > https://github.com/nox/otp/compare/erlang:maint...fix-comp-warnings > > https://github.com/nox/otp/compare/erlang:maint...fix-comp-warnings.patch > > Regards, > > -- > Anthony Ramine > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Schlager@REDACTED Mon Jul 8 16:49:18 2013 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Mon, 8 Jul 2013 14:49:18 +0000 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow Message-ID: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> Hi, this patch fixes the problem I posted to the erlang-bugs mailing list earlier today. In short, this fix simply converts the type of erlNodeReductions from Counter32 to Counter64 in the OTP-MIB.mib file. This patch also removes some warnings discovered by smilint (regarding timestamp formats) and it introduces a new test suite for the otp_mibs application (quite similar to the os_mon_mib suite). git fetch https://github.com/schlagert/otp.git snmp_fix_node_reduction_type https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type.patch Regards Tobias From fredrik@REDACTED Tue Jul 9 08:59:38 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 9 Jul 2013 08:59:38 +0200 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> Message-ID: <51DBB4DA.1070101@erlang.org> On 07/08/2013 04:49 PM, Tobias Schlager wrote: > Hi, > > this patch fixes the problem I posted to the erlang-bugs mailing list earlier today. In short, this fix simply converts the type of erlNodeReductions from Counter32 to Counter64 in the OTP-MIB.mib file. This patch also removes some warnings discovered by smilint (regarding timestamp formats) and it introduces a new test suite for the otp_mibs application (quite similar to the os_mon_mib suite). > > git fetch https://github.com/schlagert/otp.git snmp_fix_node_reduction_type > > https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type > https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type.patch > > Regards > Tobias > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Tobias, I've fetched your patch and it should be visible in the 'pu' branch right now. I also assigned it to be reviewed by responsible team. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From erlangsiri@REDACTED Tue Jul 9 09:21:11 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 9 Jul 2013 09:21:11 +0200 Subject: [erlang-patches] Allow rb to use any io_device/registered name instead of only filename path In-Reply-To: <51C2B4B2.6010204@erlang.org> References: <51AB1928.3080503@wanadoo.fr> <51AD939B.80006@erlang.org> <51AE634D.7020608@wanadoo.fr> <51C0705C.9080301@erlang.org> <51C0984E.5090607@wanadoo.fr> <51C2215F.3010009@wanadoo.fr> <51C2B4B2.6010204@erlang.org> Message-ID: Eric, I'm sorry for the delay! I've looked at your patch again, and I think it looks good now. I would like you to amend your commits into one single commit since keeping them separate does not add any value imo. Also, you need to add tests for all changed code. There is an rb_SUITE in sasl/test which can be extended. Regards /siri 2013/6/20 Fredrik > On 06/19/2013 11:23 PM, PAILLEAU Eric wrote: > >> Le 19/06/2013 10:19, Siri Hansen a ?crit : >> >>> Hi Eric - I am looking at this patch, and I find the diff a bit strange. >>> I see in the first commit that you updated the documentation (rb.xml) >>> for e.g. rb:start: >>> >>> e.g. >>> -FileName = string() | standard_io >>> +FileName = string() | atom() | pid() >>> >>> but this is backed out again in your second commit, although is seems >>> the code is still there (and, as far as I can understand, this >>> functionality is also the main point of the patch). Could you please >>> have a look at it? Did something go wrong in a merge or rebase? >>> >>> Regards >>> >> Hello Siri, >> yes you are true. >> I fixed this. >> Fredik can refetch. >> Regards >> > Re-fetched. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue Jul 9 11:41:39 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 9 Jul 2013 11:41:39 +0200 Subject: [erlang-patches] Release the reltool script In-Reply-To: <51CAF705.2040900@erlang.org> References: <51CAF705.2040900@erlang.org> Message-ID: Hi H?kan! I have looked at your patch and it looks good :) Only some minors: * You have copied a lot of code from reltool_server_SUITE into reltool_escript_SUITE. Could you please move these functions into e.g. reltool_test_lib.erl instead? * In the start_gui/1 test you have commented out the actual start of the gui - is this intentional, and if so why? * Could you please undo the change of vsn.mk? This file will be updated at next release. * And finally, when you renamed the escript it looks like you created a new file and removed the old instead of doing 'git mv'? Is this correct? If so, could you please fix this so the full history of the file is still available? Thanks for you contribution! Regards /siri 2013/6/26 Fredrik > On 06/26/2013 04:04 PM, H?kan Mattsson wrote: > >> With this patch the reltool script is released among the the other top >> level executables, such as dialyzer, ct_run etc. >> I did also take the liberty of enhancing the script and renaming it >> script to "reltool". >> >> A new test suite and a new man(1) page is included. >> >> git fetch git://github.com/hawk/otp.git hawk/reltool_script >> >> or viewed here >> >> https://github.com/hawk/otp/**compare/hawk/reltool_script >> https://github.com/hawk/otp/**compare/hawk/reltool_script.**patch >> >> /H?kan >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > Hello H?kan, > I've fetched your patch and it should soon be visible in the 'pu' branch > on github. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gomoripeti@REDACTED Wed Jul 10 03:19:16 2013 From: gomoripeti@REDACTED (=?ISO-8859-1?Q?Peti_G=F6m=F6ri?=) Date: Wed, 10 Jul 2013 02:19:16 +0100 Subject: [erlang-patches] [erlang-questions] cover & export_all In-Reply-To: References: Message-ID: Hi OTP team, here is a patch that addresses the problem Yuri described. (I haven't added any tests or docs though) is it true that now you also accept pull requests? git fetch git://github.com/gomoripeti/otp.git pg?-cover-export-all https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all.patch br Peter On Wed, Jul 10, 2013 at 12:34 AM, Peti G?m?ri wrote: > Hi Yuri, > > You are right, while cover compiling from source works (you can use this > as a workaround): > > cover:compile(cover_test, UserOptions = [export_all, debug_info]). > {ok,cover_test} > > cover_test:test(). > ok > > (because UserOptions from the arguments is taken when cover recompiles the > instrumented forms) > when cover compiling from beam UserOptions = [] is taken. > This could be fixed in cover by taking the compile options from the beam > file as you assumed how it works. > > Actually the documentation still says that "Only options defining include > file directories and macros are passed to compile:file/2, everything else > is ignored." apparently a patch from Tobias Schlager added export_all to > the allowed options of cover:compile for the exact same use case as you > had. But this is missing from cover:compile_beam. > > May be I try to come up with a patch > > br > Peter > > > > On Tue, Jul 9, 2013 at 11:56 AM, Yuri Lukyanov wrote: > >> It seems that there is no way to cover-compile modules with export_all. >> Here is a simple example: >> >> cover_test.erl: >> >> -module(cover_test). >> test() -> ok. >> >> >> $ erl >> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:4:4] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> Eshell V5.9.1 (abort with ^G) >> 1> c(cover_test, [debug_info,export_all]). >> {ok,cover_test} >> 2> cover_test:test(). >> ok >> 3> cover:compile_beam(cover_test). >> {ok,cover_test} >> 4> cover_test:test(). >> ** exception error: undefined function cover_test:test/0 >> 5> >> >> >> Could someone explain why it is like this? Is it done on purpose? >> Maybe it's a bug? >> The reason I want modules to be cover-compiled with +export_all is >> that it is sometimes convinient to have unit tests outside of a >> module. Before unit tests are run the modules get compiled with >> +export_all for tests to be able to access private functions. But the >> situation is that it is not possibe in this case to enable coverage >> analysys. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Wed Jul 10 10:11:09 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 10 Jul 2013 10:11:09 +0200 Subject: [erlang-patches] [erlang-questions] cover & export_all In-Reply-To: References: Message-ID: <51DD171D.2090802@erlang.org> On 07/10/2013 03:19 AM, Peti G?m?ri wrote: > Hi OTP team, > > here is a patch that addresses the problem Yuri described. > (I haven't added any tests or docs though) > > is it true that now you also accept pull requests? > > > > git fetch git://github.com/gomoripeti/otp.git > pg?-cover-export-all > > https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all > > https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all.patch > > > > br > Peter > > On Wed, Jul 10, 2013 at 12:34 AM, Peti G?m?ri > wrote: > > Hi Yuri, > > You are right, while cover compiling from source works (you can > use this as a workaround): > > cover:compile(cover_test, UserOptions = [export_all, debug_info]). > {ok,cover_test} > > cover_test:test(). > ok > > (because UserOptions from the arguments is taken when cover > recompiles the instrumented forms) > when cover compiling from beam UserOptions = [] is taken. > This could be fixed in cover by taking the compile options from > the beam file as you assumed how it works. > > Actually the documentation still says that "Only options defining > include file directories and macros are passed to compile:file/2, > everything else is ignored." apparently a patch from Tobias > Schlager added export_all to the allowed options of cover:compile > for the exact same use case as you had. But this is missing from > cover:compile_beam. > > May be I try to come up with a patch > > br > Peter > > > > On Tue, Jul 9, 2013 at 11:56 AM, Yuri Lukyanov > wrote: > > It seems that there is no way to cover-compile modules with > export_all. > Here is a simple example: > > cover_test.erl: > > -module(cover_test). > test() -> ok. > > > $ erl > Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:4:4] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.9.1 (abort with ^G) > 1> c(cover_test, [debug_info,export_all]). > {ok,cover_test} > 2> cover_test:test(). > ok > 3> cover:compile_beam(cover_test). > {ok,cover_test} > 4> cover_test:test(). > ** exception error: undefined function cover_test:test/0 > 5> > > > Could someone explain why it is like this? Is it done on purpose? > Maybe it's a bug? > The reason I want modules to be cover-compiled with +export_all is > that it is sometimes convinient to have unit tests outside of a > module. Before unit tests are run the modules get compiled with > +export_all for tests to be able to access private functions. > But the > situation is that it is not possibe in this case to enable > coverage > analysys. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Peti, I am getting, fatal: Couldn't find remote ref pg?-cover-export-all when I am trying to fetch. Yes pull requests are accepted. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From gomoripeti@REDACTED Wed Jul 10 10:34:38 2013 From: gomoripeti@REDACTED (=?ISO-8859-1?Q?Peti_G=F6m=F6ri?=) Date: Wed, 10 Jul 2013 09:34:38 +0100 Subject: [erlang-patches] [erlang-questions] cover & export_all In-Reply-To: <51DD171D.2090802@erlang.org> References: <51DD171D.2090802@erlang.org> Message-ID: Hi Fredrik, sorry, what about this one (maybe it was a wrong ?) git fetch git://github.com/gomoripeti/otp.git pg?-cover-export-all On Wed, Jul 10, 2013 at 9:11 AM, Fredrik wrote: > On 07/10/2013 03:19 AM, Peti G?m?ri wrote: > > Hi OTP team, > > here is a patch that addresses the problem Yuri described. > (I haven't added any tests or docs though) > > is it true that now you also accept pull requests? > > > > git fetch git://github.com/gomoripeti/otp.git pg?-cover-export-all > > > https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all > > https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all.patch > > > br > Peter > > On Wed, Jul 10, 2013 at 12:34 AM, Peti G?m?ri wrote: > >> Hi Yuri, >> >> You are right, while cover compiling from source works (you can use >> this as a workaround): >> > cover:compile(cover_test, UserOptions = [export_all, debug_info]). >> {ok,cover_test} >> > cover_test:test(). >> ok >> >> (because UserOptions from the arguments is taken when cover recompiles >> the instrumented forms) >> when cover compiling from beam UserOptions = [] is taken. >> This could be fixed in cover by taking the compile options from the beam >> file as you assumed how it works. >> >> Actually the documentation still says that "Only options defining >> include file directories and macros are passed to compile:file/2, >> everything else is ignored." apparently a patch from Tobias Schlager added >> export_all to the allowed options of cover:compile for the exact same use >> case as you had. But this is missing from cover:compile_beam. >> >> May be I try to come up with a patch >> >> br >> Peter >> >> >> >> On Tue, Jul 9, 2013 at 11:56 AM, Yuri Lukyanov wrote: >> >>> It seems that there is no way to cover-compile modules with export_all. >>> Here is a simple example: >>> >>> cover_test.erl: >>> >>> -module(cover_test). >>> test() -> ok. >>> >>> >>> $ erl >>> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:4:4] >>> [async-threads:0] [hipe] [kernel-poll:false] >>> >>> Eshell V5.9.1 (abort with ^G) >>> 1> c(cover_test, [debug_info,export_all]). >>> {ok,cover_test} >>> 2> cover_test:test(). >>> ok >>> 3> cover:compile_beam(cover_test). >>> {ok,cover_test} >>> 4> cover_test:test(). >>> ** exception error: undefined function cover_test:test/0 >>> 5> >>> >>> >>> Could someone explain why it is like this? Is it done on purpose? >>> Maybe it's a bug? >>> The reason I want modules to be cover-compiled with +export_all is >>> that it is sometimes convinient to have unit tests outside of a >>> module. Before unit tests are run the modules get compiled with >>> +export_all for tests to be able to access private functions. But the >>> situation is that it is not possibe in this case to enable coverage >>> analysys. >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> > > > _______________________________________________ > erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches > > Hello Peti, > I am getting, > fatal: > Couldn't find remote ref pg?-cover-export-all when I am trying to fetch. > Yes pull requests are accepted. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Thu Jul 11 09:22:28 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 11 Jul 2013 09:22:28 +0200 Subject: [erlang-patches] add application:start_all/1-2 (recursive OTP app starting) In-Reply-To: <51C7EE73.9080606@erlang.org> References: <20130620181610.GB93763@ferdair.local> <51C7EE73.9080606@erlang.org> Message-ID: Hi Fred! OTP technical board has discussed your patch and we find the functionality useful. We would, however, like to see some adjustments: 1. Since the function behaves more like application:ensure_started/1,2 than application:start/1,2 we would like the new name to be ensure_all_started/1,2. 2. On failure, the current implementation potentially leaves one or more applications started. We would like it to clean up after itself in this situation. 3. On success, we would like the function to return {ok,StartedApps}, where StartedApps is the list of applications (names) that were actually started. Would it be possible for you to update the patch accordingly? Thanks for your contribution! Regards /siri 2013/6/24 Fredrik > On 06/20/2013 08:16 PM, Fred Hebert wrote: > >> This adds two new functions to the application module that will >> recursively look for missing dependencies to start the entire dependency >> chain of a given application, and then the application itself, if >> possible. >> >> Its entire behavior is based on the currently existing 'start/1-2' >> functions, which will report dependencies that have not yet been started >> and other problems encountered. 'start_all/1-2' will use this >> information the way any programmer would manually do it to automate the >> process. >> >> This kind of functionality, while not OTP-ish (releases do this start >> sequence for the user), is still useful for testing purposes, quick >> demonstrations, and programmers who do not wish or know how to use OTP >> releases. >> >> The function returns 'ok' for all started or already started >> applications, and will return '{error, {AppName, Reason}}' on a failure >> to allow users to rapidly know why the function failed. >> >> I decided to call it start_all even though its semantics are somewhat >> similar to ensure_start in how it ignores already_started applications, >> but am open to changing the name if the OTP team prefers >> 'ensure_all/1-2' as functions for this module. >> >> Documentation has been added, and so were tests, looking for a few >> simple case: simple app, app with a dependency, and apps with a >> 3rd-level dependency not booting, all locally. >> >> Note that no specific check is made for direct or indirect circular >> dependencies between applications, and these will make the function go >> in an infinite loop. >> >> git fetch git://github.com/ferd/otp.git start-all >> >> https://github.com/ferd/otp/**compare/erlang:maint...start-**all >> https://github.com/ferd/otp/**compare/erlang:maint...start-**all.patch >> >> Regards, >> Fred Hebert. >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > Hello Fred, > I've fetched your patch and assigned it to be reviewed. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc@REDACTED Thu Jul 11 10:23:02 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Thu, 11 Jul 2013 04:23:02 -0400 Subject: [erlang-patches] add application:start_all/1-2 (recursive OTP app starting) In-Reply-To: References: <20130620181610.GB93763@ferdair.local> <51C7EE73.9080606@erlang.org> Message-ID: +1 On Thu, Jul 11, 2013 at 3:22 AM, Siri Hansen wrote: > Hi Fred! > > OTP technical board has discussed your patch and we find the functionality > useful. We would, however, like to see some adjustments: > > 1. Since the function behaves more like application:ensure_started/1,2 > than application:start/1,2 we would like the new name to be > ensure_all_started/1,2. > > 2. On failure, the current implementation potentially leaves one or more > applications started. We would like it to clean up after itself in this > situation. > > 3. On success, we would like the function to return {ok,StartedApps}, > where StartedApps is the list of applications (names) that were actually > started. > > Would it be possible for you to update the patch accordingly? > > Thanks for your contribution! > Regards > /siri > > > > 2013/6/24 Fredrik > >> On 06/20/2013 08:16 PM, Fred Hebert wrote: >> >>> This adds two new functions to the application module that will >>> recursively look for missing dependencies to start the entire dependency >>> chain of a given application, and then the application itself, if >>> possible. >>> >>> Its entire behavior is based on the currently existing 'start/1-2' >>> functions, which will report dependencies that have not yet been started >>> and other problems encountered. 'start_all/1-2' will use this >>> information the way any programmer would manually do it to automate the >>> process. >>> >>> This kind of functionality, while not OTP-ish (releases do this start >>> sequence for the user), is still useful for testing purposes, quick >>> demonstrations, and programmers who do not wish or know how to use OTP >>> releases. >>> >>> The function returns 'ok' for all started or already started >>> applications, and will return '{error, {AppName, Reason}}' on a failure >>> to allow users to rapidly know why the function failed. >>> >>> I decided to call it start_all even though its semantics are somewhat >>> similar to ensure_start in how it ignores already_started applications, >>> but am open to changing the name if the OTP team prefers >>> 'ensure_all/1-2' as functions for this module. >>> >>> Documentation has been added, and so were tests, looking for a few >>> simple case: simple app, app with a dependency, and apps with a >>> 3rd-level dependency not booting, all locally. >>> >>> Note that no specific check is made for direct or indirect circular >>> dependencies between applications, and these will make the function go >>> in an infinite loop. >>> >>> git fetch git://github.com/ferd/otp.git start-all >>> >>> https://github.com/ferd/otp/**compare/erlang:maint...start-**all >>> https://github.com/ferd/otp/**compare/erlang:maint...start-**all.patch >>> >>> Regards, >>> Fred Hebert. >>> ______________________________**_________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/**listinfo/erlang-patches >>> >> Hello Fred, >> I've fetched your patch and assigned it to be reviewed. >> Thanks, >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Thu Jul 11 14:26:40 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 11 Jul 2013 14:26:40 +0200 Subject: [erlang-patches] erl_tidy option to print to stdout In-Reply-To: References: Message-ID: <51DEA480.6080107@erlang.org> On 06/02/2013 09:52 PM, Aaron France wrote: > Hi all, > > I've read the contribution rules and received some cursory guidance > from nox in IRC so I hope I don't awaken any wrath from the format. > > I've added an option to erl_tidy to simply print to stdout. These may > seem a trivial thing to want to have in but my use-case is wanting to > build intermediary steps around erl_tidy and not simply replace the > underlying file. > > Personally, I want to have this (and I am working on it now that I > have patched it in) available to erlang-mode in emacs. So that I can > have a save hook for formatting the code properly. Dealing with files > is less than stellar but dealing with the unixy stdin/out method is > far nicer. > > I have this set up on: > https://github.com/AeroNotix/otp/tree/feat/erl_tidy_print_to_stdout > > I added the requisite source and added the docs for it in the right areas. > > Regards, > Aaron > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Aaron, We are interested in this patch but before we can merge it we need tests and further documentation. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From awilniewczyc@REDACTED Thu Jul 11 13:23:36 2013 From: awilniewczyc@REDACTED (Artur Wilniewczyc) Date: Thu, 11 Jul 2013 13:23:36 +0200 Subject: [erlang-patches] Missing brackets in report formatting on ftp_progress process exit Message-ID: <51DE95B8.3060109@power.com.pl> Hello, git fetch git://github.com/powermedia/otp.git fix-ftp-report-formatting Added missing brackets to report formatting on ftp_progress process exit. When they are missing and progress reporting process exits, ftp client crashes because of badarg in io_lib:format argument. -- Regards, Artur Wilniewczyc From carlsson.richard@REDACTED Thu Jul 11 16:11:26 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 11 Jul 2013 16:11:26 +0200 Subject: [erlang-patches] erl_tidy option to print to stdout In-Reply-To: <51DEA480.6080107@erlang.org> References: <51DEA480.6080107@erlang.org> Message-ID: <51DEBD0E.6020702@gmail.com> On 2013-07-11 14:26 , Fredrik wrote: > On 06/02/2013 09:52 PM, Aaron France wrote: >> Hi all, >> >> I've read the contribution rules and received some cursory guidance >> from nox in IRC so I hope I don't awaken any wrath from the format. >> >> I've added an option to erl_tidy to simply print to stdout. These may >> seem a trivial thing to want to have in but my use-case is wanting to >> build intermediary steps around erl_tidy and not simply replace the >> underlying file. >> >> Personally, I want to have this (and I am working on it now that I >> have patched it in) available to erlang-mode in emacs. So that I can >> have a save hook for formatting the code properly. Dealing with files >> is less than stellar but dealing with the unixy stdin/out method is >> far nicer. >> >> I have this set up on: >> https://github.com/AeroNotix/otp/tree/feat/erl_tidy_print_to_stdout >> >> I added the requisite source and added the docs for it in the right areas. >> >> Regards, >> Aaron >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello Aaron, > We are interested in this patch but before we can merge it we need tests > and further documentation. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team Considering that he did document the new option, and that erl_tidy (and the whole of syntax_tools) currently has almost no tests, I think this patch should be accepted as it is. /Richard From fredrik@REDACTED Thu Jul 11 16:19:08 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 11 Jul 2013 16:19:08 +0200 Subject: [erlang-patches] Missing brackets in report formatting on ftp_progress process exit In-Reply-To: <51DE95B8.3060109@power.com.pl> References: <51DE95B8.3060109@power.com.pl> Message-ID: <51DEBEDC.1000903@erlang.org> On 07/11/2013 01:23 PM, Artur Wilniewczyc wrote: > Hello, > > git fetch git://github.com/powermedia/otp.git fix-ftp-report-formatting > > Added missing brackets to report formatting on ftp_progress process exit. > > When they are missing and progress reporting process exits, ftp client > crashes because of badarg in io_lib:format argument. > Hello Artur, I've fetched your patch and it will soon be merged to maint branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From mononcqc@REDACTED Thu Jul 11 16:19:31 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 11 Jul 2013 10:19:31 -0400 Subject: [erlang-patches] add application:start_all/1-2 (recursive OTP app starting) In-Reply-To: References: <20130620181610.GB93763@ferdair.local> <51C7EE73.9080606@erlang.org> Message-ID: <20130711141930.GA3229@ferdair.local> Hi Siri, I've amended the commit and rebased over maint to implement the recommendations you had. I extended the tests and the docs, but I didn't rename the branch, though. git fetch git://github.com/ferd/otp.git start-all https://github.com/ferd/otp/compare/erlang:maint...start-all https://github.com/ferd/otp/compare/erlang:maint...start-all.patch Regards, Fred. On 07/11, Siri Hansen wrote: > Hi Fred! > > OTP technical board has discussed your patch and we find the functionality > useful. We would, however, like to see some adjustments: > > 1. Since the function behaves more like application:ensure_started/1,2 than > application:start/1,2 we would like the new name to be > ensure_all_started/1,2. > > 2. On failure, the current implementation potentially leaves one or more > applications started. We would like it to clean up after itself in this > situation. > > 3. On success, we would like the function to return {ok,StartedApps}, where > StartedApps is the list of applications (names) that were actually started. > > Would it be possible for you to update the patch accordingly? > > Thanks for your contribution! > Regards > /siri > > > > 2013/6/24 Fredrik > > > On 06/20/2013 08:16 PM, Fred Hebert wrote: > > > >> This adds two new functions to the application module that will > >> recursively look for missing dependencies to start the entire dependency > >> chain of a given application, and then the application itself, if > >> possible. > >> > >> Its entire behavior is based on the currently existing 'start/1-2' > >> functions, which will report dependencies that have not yet been started > >> and other problems encountered. 'start_all/1-2' will use this > >> information the way any programmer would manually do it to automate the > >> process. > >> > >> This kind of functionality, while not OTP-ish (releases do this start > >> sequence for the user), is still useful for testing purposes, quick > >> demonstrations, and programmers who do not wish or know how to use OTP > >> releases. > >> > >> The function returns 'ok' for all started or already started > >> applications, and will return '{error, {AppName, Reason}}' on a failure > >> to allow users to rapidly know why the function failed. > >> > >> I decided to call it start_all even though its semantics are somewhat > >> similar to ensure_start in how it ignores already_started applications, > >> but am open to changing the name if the OTP team prefers > >> 'ensure_all/1-2' as functions for this module. > >> > >> Documentation has been added, and so were tests, looking for a few > >> simple case: simple app, app with a dependency, and apps with a > >> 3rd-level dependency not booting, all locally. > >> > >> Note that no specific check is made for direct or indirect circular > >> dependencies between applications, and these will make the function go > >> in an infinite loop. > >> > >> git fetch git://github.com/ferd/otp.git start-all > >> > >> https://github.com/ferd/otp/**compare/erlang:maint...start-**all > >> https://github.com/ferd/otp/**compare/erlang:maint...start-**all.patch > >> > >> Regards, > >> Fred Hebert. > >> ______________________________**_________________ > >> erlang-patches mailing list > >> erlang-patches@REDACTED > >> http://erlang.org/mailman/**listinfo/erlang-patches > >> > > Hello Fred, > > I've fetched your patch and assigned it to be reviewed. > > Thanks, > > > > -- > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > > > > > ______________________________**_________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/**listinfo/erlang-patches > > From fredrik@REDACTED Thu Jul 11 16:22:34 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 11 Jul 2013 16:22:34 +0200 Subject: [erlang-patches] add application:start_all/1-2 (recursive OTP app starting) In-Reply-To: <20130711141930.GA3229@ferdair.local> References: <20130620181610.GB93763@ferdair.local> <51C7EE73.9080606@erlang.org> <20130711141930.GA3229@ferdair.local> Message-ID: <51DEBFAA.9080800@erlang.org> On 07/11/2013 04:19 PM, Fred Hebert wrote: > Hi Siri, > > I've amended the commit and rebased over maint to implement the > recommendations you had. I extended the tests and the docs, but > I didn't rename the branch, though. > > git fetch git://github.com/ferd/otp.git start-all > > https://github.com/ferd/otp/compare/erlang:maint...start-all > https://github.com/ferd/otp/compare/erlang:maint...start-all.patch > > Regards, > Fred. > > On 07/11, Siri Hansen wrote: >> Hi Fred! >> >> OTP technical board has discussed your patch and we find the functionality >> useful. We would, however, like to see some adjustments: >> >> 1. Since the function behaves more like application:ensure_started/1,2 than >> application:start/1,2 we would like the new name to be >> ensure_all_started/1,2. >> >> 2. On failure, the current implementation potentially leaves one or more >> applications started. We would like it to clean up after itself in this >> situation. >> >> 3. On success, we would like the function to return {ok,StartedApps}, where >> StartedApps is the list of applications (names) that were actually started. >> >> Would it be possible for you to update the patch accordingly? >> >> Thanks for your contribution! >> Regards >> /siri >> >> >> >> 2013/6/24 Fredrik >> >>> On 06/20/2013 08:16 PM, Fred Hebert wrote: >>> >>>> This adds two new functions to the application module that will >>>> recursively look for missing dependencies to start the entire dependency >>>> chain of a given application, and then the application itself, if >>>> possible. >>>> >>>> Its entire behavior is based on the currently existing 'start/1-2' >>>> functions, which will report dependencies that have not yet been started >>>> and other problems encountered. 'start_all/1-2' will use this >>>> information the way any programmer would manually do it to automate the >>>> process. >>>> >>>> This kind of functionality, while not OTP-ish (releases do this start >>>> sequence for the user), is still useful for testing purposes, quick >>>> demonstrations, and programmers who do not wish or know how to use OTP >>>> releases. >>>> >>>> The function returns 'ok' for all started or already started >>>> applications, and will return '{error, {AppName, Reason}}' on a failure >>>> to allow users to rapidly know why the function failed. >>>> >>>> I decided to call it start_all even though its semantics are somewhat >>>> similar to ensure_start in how it ignores already_started applications, >>>> but am open to changing the name if the OTP team prefers >>>> 'ensure_all/1-2' as functions for this module. >>>> >>>> Documentation has been added, and so were tests, looking for a few >>>> simple case: simple app, app with a dependency, and apps with a >>>> 3rd-level dependency not booting, all locally. >>>> >>>> Note that no specific check is made for direct or indirect circular >>>> dependencies between applications, and these will make the function go >>>> in an infinite loop. >>>> >>>> git fetch git://github.com/ferd/otp.git start-all >>>> >>>> https://github.com/ferd/otp/**compare/erlang:maint...start-**all >>>> https://github.com/ferd/otp/**compare/erlang:maint...start-**all.patch >>>> >>>> Regards, >>>> Fred Hebert. >>>> ______________________________**_________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/**listinfo/erlang-patches >>>> >>> Hello Fred, >>> I've fetched your patch and assigned it to be reviewed. >>> Thanks, >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >>> >>> ______________________________**_________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/**listinfo/erlang-patches >>> > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From egil@REDACTED Thu Jul 11 16:48:12 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 11 Jul 2013 16:48:12 +0200 Subject: [erlang-patches] erl_tidy option to print to stdout In-Reply-To: <51DEBD0E.6020702@gmail.com> References: <51DEA480.6080107@erlang.org> <51DEBD0E.6020702@gmail.com> Message-ID: <51DEC5AC.90907@erlang.org> On 2013-07-11 16:11, Richard Carlsson wrote: > On 2013-07-11 14:26 , Fredrik wrote: >> On 06/02/2013 09:52 PM, Aaron France wrote: >>> Hi all, >>> >>> I've read the contribution rules and received some cursory guidance >>> from nox in IRC so I hope I don't awaken any wrath from the format. >>> >>> I've added an option to erl_tidy to simply print to stdout. These may >>> seem a trivial thing to want to have in but my use-case is wanting to >>> build intermediary steps around erl_tidy and not simply replace the >>> underlying file. >>> >>> Personally, I want to have this (and I am working on it now that I >>> have patched it in) available to erlang-mode in emacs. So that I can >>> have a save hook for formatting the code properly. Dealing with files >>> is less than stellar but dealing with the unixy stdin/out method is >>> far nicer. >>> >>> I have this set up on: >>> https://github.com/AeroNotix/otp/tree/feat/erl_tidy_print_to_stdout >>> >>> I added the requisite source and added the docs for it in the right >>> areas. >>> >>> Regards, >>> Aaron >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello Aaron, >> We are interested in this patch but before we can merge it we need tests >> and further documentation. >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team > > Considering that he did document the new option, and that erl_tidy > (and the whole of syntax_tools) currently has almost no tests, I think > this patch should be accepted as it is. It is great that the new option is documented! Especially since syntax_tools is lacking tests, I think it's crucial that tests are added. It is our policy to require tests for all new features unless the feature is already covered under some other test. // Bj?rn-Egil Erlang/OTP > > /Richard > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From andrew@REDACTED Thu Jul 11 18:54:29 2013 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 11 Jul 2013 12:54:29 -0400 Subject: [erlang-patches] erl_tidy option to print to stdout In-Reply-To: <51DEC5AC.90907@erlang.org> References: <51DEA480.6080107@erlang.org> <51DEBD0E.6020702@gmail.com> <51DEC5AC.90907@erlang.org> Message-ID: <20130711165429.GB6560@hijacked.us> On Thu, Jul 11, 2013 at 04:48:12PM +0200, Bj?rn-Egil Dahlberg wrote: > It is great that the new option is documented! > > Especially since syntax_tools is lacking tests, I think it's crucial > that tests are added. > > It is our policy to require tests for all new features unless the > feature is already covered under some other test. Not that I don't applaud this policy, but it can be *extremely* difficult to add new tests to a untested/minimally tested codebase. I know when I've made contributions in the past I've tried to update the test suites where applicable, but when there's no tests I've sort of thrown up my hands and just submitted the patch. I don't know the best solution to this, but pushing all the work on the contributor seems a little unfair. Maybe the OTP team can help out with testing in such cases. Andrew From eric.pailleau@REDACTED Sat Jul 13 21:54:52 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sat, 13 Jul 2013 21:54:52 +0200 Subject: [erlang-patches] Allow rb to use any io_device/registered name instead of only filename path In-Reply-To: References: <51AB1928.3080503@wanadoo.fr> <51AD939B.80006@erlang.org> <51AE634D.7020608@wanadoo.fr> <51C0705C.9080301@erlang.org> <51C0984E.5090607@wanadoo.fr> <51C2215F.3010009@wanadoo.fr> <51C2B4B2.6010204@erlang.org> Message-ID: <51E1B08C.3000803@wanadoo.fr> Le 09/07/2013 09:21, Siri Hansen a ?crit : > Eric, I'm sorry for the delay! I've looked at your patch again, and I > think it looks good now. I would like you to amend your commits into one > single commit since keeping them separate does not add any value imo. Hello Siri, no problem for the delay, I was busy too. I squashed the last commits into the first. I will try to add tests in the rb_SUITE, and then come back to you. Regards From eric.pailleau@REDACTED Sun Jul 14 00:04:39 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 14 Jul 2013 00:04:39 +0200 Subject: [erlang-patches] Allow rb to use any io_device/registered name instead of only filename path In-Reply-To: <51E1B08C.3000803@wanadoo.fr> References: <51AB1928.3080503@wanadoo.fr> <51AD939B.80006@erlang.org> <51AE634D.7020608@wanadoo.fr> <51C0705C.9080301@erlang.org> <51C0984E.5090607@wanadoo.fr> <51C2215F.3010009@wanadoo.fr> <51C2B4B2.6010204@erlang.org> <51E1B08C.3000803@wanadoo.fr> Message-ID: <51E1CEF7.8010808@wanadoo.fr> Le 13/07/2013 21:54, PAILLEAU Eric a ?crit : > Le 09/07/2013 09:21, Siri Hansen a ?crit : >> Eric, I'm sorry for the delay! I've looked at your patch again, and I >> think it looks good now. I would like you to amend your commits into one >> single commit since keeping them separate does not add any value imo. > > Hello Siri, > no problem for the delay, I was busy too. > I squashed the last commits into the first. > I will try to add tests in the rb_SUITE, and then come back to you. > Regards Hello Siri, Adding tests in rb_SUITE was easier than I thought . ct_run is ok and everything merged into a single commit. Please refetch . Best regards From stefan.zegenhagen@REDACTED Mon Jul 15 13:19:43 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 15 Jul 2013 13:19:43 +0200 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> Message-ID: <1373887183.3597.15.camel@ax-sze> Dear Tobias, > this patch fixes the problem I posted to the erlang-bugs mailing list earlier today. In short, this fix simply converts the type of erlNodeReductions from Counter32 to Counter64 in the OTP-MIB.mib file. This patch also removes some warnings discovered by smilint (regarding timestamp formats) and it introduces a new test suite for the otp_mibs application (quite similar to the os_mon_mib suite). > > git fetch https://github.com/schlagert/otp.git snmp_fix_node_reduction_type > > https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type > https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type.patch Unfortunately, (integer) numbers in Erlang never wrap. So even the Counter64 type will overflow at some point (I've tested that with other counters in SNMP). It seems to be required to change the instrumentation function to manually truncate numbers, or change the erlang SNMP stack to implicitely truncate long integers. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From aaron.l.france@REDACTED Mon Jul 15 13:41:09 2013 From: aaron.l.france@REDACTED (Aaron France) Date: Mon, 15 Jul 2013 13:41:09 +0200 Subject: [erlang-patches] erl_tidy option to print to stdout In-Reply-To: <20130711165429.GB6560@hijacked.us> References: <51DEA480.6080107@erlang.org> <51DEBD0E.6020702@gmail.com> <51DEC5AC.90907@erlang.org> <20130711165429.GB6560@hijacked.us> Message-ID: Hi, Besides from cultivating an entire test suite for the erl_tidy module, which is outside of the scope for the patch, if I were to provide a test for the addition, I would essentially be testing a simple print function. Would I not? Some pointers on what to test would be a great help, otherwise I'm a bit a loss as to what to test. Regards, Aaron On Thu, Jul 11, 2013 at 6:54 PM, Andrew Thompson wrote: > On Thu, Jul 11, 2013 at 04:48:12PM +0200, Bj?rn-Egil Dahlberg wrote: > > It is great that the new option is documented! > > > > Especially since syntax_tools is lacking tests, I think it's crucial > > that tests are added. > > > > It is our policy to require tests for all new features unless the > > feature is already covered under some other test. > > Not that I don't applaud this policy, but it can be *extremely* > difficult to add new tests to a untested/minimally tested codebase. > > I know when I've made contributions in the past I've tried to update the > test suites where applicable, but when there's no tests I've sort of > thrown up my hands and just submitted the patch. > > I don't know the best solution to this, but pushing all the work on the > contributor seems a little unfair. Maybe the OTP team can help out with > testing in such cases. > > Andrew > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Jul 15 14:34:47 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 15 Jul 2013 08:34:47 -0400 Subject: [erlang-patches] erl_tidy option to print to stdout In-Reply-To: References: <51DEA480.6080107@erlang.org> <51DEBD0E.6020702@gmail.com> <51DEC5AC.90907@erlang.org> <20130711165429.GB6560@hijacked.us> Message-ID: <20130715123446.GB3229@ferdair.local> Given you're printing with io:format/1, the output will go to the caller process' group leader (http://www.erlang.org/doc/man/erlang.html#group_leader-0). My recommendation would then be to have your test work using the IO protocol (http://erlang.org/doc/apps/stdlib/io_protocol.html) a bit as follows: my_test(_Config) -> Parent = self(), spawn_link(fun() -> erlang:group_leader(self(), Parent), call_to_pretty_print() end) receive {io_request, From, ReplyAs, {put_chars, _Encoding, Characters}} -> From ! {io_reply, ReplyAs, ok}. % validate reception check_for_content(Characters) after 1000 -> erlang:error(too_slow) end. Make sure to differentiate requests going to you because they're printingwhat you want, and not because of any other call that is not related. Regards, Fred. On 07/15, Aaron France wrote: > Hi, > > Besides from cultivating an entire test suite for the erl_tidy module, > which is outside of the scope for the patch, if I were to provide a test > for the addition, I would essentially be testing a simple print function. > Would I not? > > Some pointers on what to test would be a great help, otherwise I'm a bit a > loss as to what to test. > > Regards, > Aaron > > > On Thu, Jul 11, 2013 at 6:54 PM, Andrew Thompson wrote: > > > On Thu, Jul 11, 2013 at 04:48:12PM +0200, Bj?rn-Egil Dahlberg wrote: > > > It is great that the new option is documented! > > > > > > Especially since syntax_tools is lacking tests, I think it's crucial > > > that tests are added. > > > > > > It is our policy to require tests for all new features unless the > > > feature is already covered under some other test. > > > > Not that I don't applaud this policy, but it can be *extremely* > > difficult to add new tests to a untested/minimally tested codebase. > > > > I know when I've made contributions in the past I've tried to update the > > test suites where applicable, but when there's no tests I've sort of > > thrown up my hands and just submitted the patch. > > > > I don't know the best solution to this, but pushing all the work on the > > contributor seems a little unfair. Maybe the OTP team can help out with > > testing in such cases. > > > > Andrew > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From egil@REDACTED Mon Jul 15 15:26:39 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 15 Jul 2013 15:26:39 +0200 Subject: [erlang-patches] Allow rb to use any io_device/registered name instead of only filename path In-Reply-To: <51E1CEF7.8010808@wanadoo.fr> References: <51AB1928.3080503@wanadoo.fr> <51AD939B.80006@erlang.org> <51AE634D.7020608@wanadoo.fr> <51C0705C.9080301@erlang.org> <51C0984E.5090607@wanadoo.fr> <51C2215F.3010009@wanadoo.fr> <51C2B4B2.6010204@erlang.org> <51E1B08C.3000803@wanadoo.fr> <51E1CEF7.8010808@wanadoo.fr> Message-ID: <51E3F88F.4060506@erlang.org> On 2013-07-14 00:04, PAILLEAU Eric wrote: > Le 13/07/2013 21:54, PAILLEAU Eric a ?crit : >> Le 09/07/2013 09:21, Siri Hansen a ?crit : >>> Eric, I'm sorry for the delay! I've looked at your patch again, and I >>> think it looks good now. I would like you to amend your commits into one >>> single commit since keeping them separate does not add any value imo. >> Hello Siri, >> no problem for the delay, I was busy too. >> I squashed the last commits into the first. >> I will try to add tests in the rb_SUITE, and then come back to you. >> Regards > Hello Siri, > Adding tests in rb_SUITE was easier than I thought . > ct_run is ok and everything merged into a single commit. > Please refetch . > Best regards Refetched. Siri is on vacation (most of otp is on vacation). Reviewing will be resumed once they are back. // Bj?rn-Egil > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From Tobias.Schlager@REDACTED Mon Jul 15 16:30:09 2013 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Mon, 15 Jul 2013 14:30:09 +0000 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <1373887183.3597.15.camel@ax-sze> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu>, <1373887183.3597.15.camel@ax-sze> Message-ID: <12F2115FD1CCEE4294943B2608A18FA361B091AF@MAIL01.win.lbaum.eu> Hi Stefan, I was aware of the fact that this would not finally fix the overflow when I created the patch. I should've made clear in the mail that this does only address, not fix the issue. You're absolutely right, I do also think that the SNMP instrumentation should handle this kind of overflow. Unfortunately, I didn't come up with that idea myself when I wrote the patch. However, I think extending this and probably some other values to a wider type is actually a good thing because providing a value that typically overflows within a few hours is quite meaningless. I would like to make another patch that actually fixes the problem but I'm not sure what the desired behaviour would be for a counter. Should it always reflect the highest valid value when overflowing or should it start over? Thank you for the input. Regards Tobias ________________________________________ Von: Stefan Zegenhagen [stefan.zegenhagen@REDACTED] Gesendet: Montag, 15. Juli 2013 13:19 An: Tobias Schlager Cc: erlang-patches@REDACTED Betreff: Re: [erlang-patches] SNMP erlNodeReductions defined too narrow Dear Tobias, > this patch fixes the problem I posted to the erlang-bugs mailing list earlier today. In short, this fix simply converts the type of erlNodeReductions from Counter32 to Counter64 in the OTP-MIB.mib file. This patch also removes some warnings discovered by smilint (regarding timestamp formats) and it introduces a new test suite for the otp_mibs application (quite similar to the os_mon_mib suite). > > git fetch https://github.com/schlagert/otp.git snmp_fix_node_reduction_type > > https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type > https://github.com/schlagert/otp/compare/erlang:maint...snmp_fix_node_reduction_type.patch Unfortunately, (integer) numbers in Erlang never wrap. So even the Counter64 type will overflow at some point (I've tested that with other counters in SNMP). It seems to be required to change the instrumentation function to manually truncate numbers, or change the erlang SNMP stack to implicitely truncate long integers. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From egil@REDACTED Mon Jul 15 16:34:40 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 15 Jul 2013 16:34:40 +0200 Subject: [erlang-patches] Allow rb to use any io_device/registered name instead of only filename path In-Reply-To: <51E3F88F.4060506@erlang.org> References: <51AB1928.3080503@wanadoo.fr> <51AD939B.80006@erlang.org> <51AE634D.7020608@wanadoo.fr> <51C0705C.9080301@erlang.org> <51C0984E.5090607@wanadoo.fr> <51C2215F.3010009@wanadoo.fr> <51C2B4B2.6010204@erlang.org> <51E1B08C.3000803@wanadoo.fr> <51E1CEF7.8010808@wanadoo.fr> <51E3F88F.4060506@erlang.org> Message-ID: <51E40880.3020505@erlang.org> On 2013-07-15 15:26, Bj?rn-Egil Dahlberg wrote: > On 2013-07-14 00:04, PAILLEAU Eric wrote: >> Le 13/07/2013 21:54, PAILLEAU Eric a ?crit : >>> Le 09/07/2013 09:21, Siri Hansen a ?crit : >>>> Eric, I'm sorry for the delay! I've looked at your patch again, and I >>>> think it looks good now. I would like you to amend your commits >>>> into one >>>> single commit since keeping them separate does not add any value imo. >>> Hello Siri, >>> no problem for the delay, I was busy too. >>> I squashed the last commits into the first. >>> I will try to add tests in the rb_SUITE, and then come back to you. >>> Regards >> Hello Siri, >> Adding tests in rb_SUITE was easier than I thought . >> ct_run is ok and everything merged into a single commit. >> Please refetch . >> Best regards > Refetched. Your branch failed to build the documentation. I added this to your branch: epa/add_fd_usage_in_rb egil@REDACTED /ldisk/egil/community-patches/otp-patches $ git diff diff --git a/lib/sasl/doc/src/rb.xml b/lib/sasl/doc/src/rb.xml index bfde58e..b94914d 100644 --- a/lib/sasl/doc/src/rb.xml +++ b/lib/sasl/doc/src/rb.xml @@ -138,7 +138,6 @@ - log_list() log_list(Type) Log reports list > > Siri is on vacation (most of otp is on vacation). Reviewing will be > resumed once they are back. > > // Bj?rn-Egil > >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From stefan.zegenhagen@REDACTED Mon Jul 15 16:47:49 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 15 Jul 2013 16:47:49 +0200 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B091AF@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> ,<1373887183.3597.15.camel@ax-sze> <12F2115FD1CCEE4294943B2608A18FA361B091AF@MAIL01.win.lbaum.eu> Message-ID: <1373899669.3597.22.camel@ax-sze> Hi Tobias, > However, I think extending this and probably some other values to a > wider type is actually a good thing because providing a value that > typically overflows within a few hours is quite meaningless. I would > like to make another patch that actually fixes the problem but I'm not > sure what the desired behaviour would be for a counter. Should it > always reflect the highest valid value when overflowing or should it > start over? I only know this for network counters. Here the desired behaviour is that the counter starts again from zero. If someone wants to get accurate numbers from the device, he has to poll those counters in regular intervals to detect overflows. The minimum time (in which the counter can overflow) can easily be calculated from the link speed (10/100/1000 MBit) here. This behaviour sounds reasonable for other counters as well, especially when there's no counter-reset MIB object. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From stefan.zegenhagen@REDACTED Mon Jul 15 17:03:07 2013 From: stefan.zegenhagen@REDACTED (Stefan Zegenhagen) Date: Mon, 15 Jul 2013 17:03:07 +0200 Subject: [erlang-patches] make edlin understand a few important control keys In-Reply-To: <51C1B85A.3050109@erlang.org> References: <1367844839.31752.73.camel@ax-sze> <51C1B85A.3050109@erlang.org> Message-ID: <1373900587.3597.26.camel@ax-sze> Hi Fredrik, > I've gotten some feedback from your review, > You need to add documentation under Erts-> "User's Guide" -> "tty - A > command line interface" > > You need to add testcase in interactive_shell_SUITE a simplified > example of how this testcase could look like; > ctrl_w_and_ctrl_u(_Conf) -> > rtnode([{putline,""}, {putline, "2."}, {getline, "2"}, > {putline,"xxx yy"++[$\^w]++"."}, {getline,"xxx"}, {putline,"xxx > yy"++[$\^u]++"z."}, {getline,"z"}],[]). Please find an updated version of the patch attached to this e-mail. I hope that you still accept it via e-mail because the former patch was sent the same way ;-). I have extended the documentation to list the new key combinations and added tests to make sure they work. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. -------------- next part -------------- A non-text attachment was scrubbed... Name: edlin.patch Type: text/x-patch Size: 9600 bytes Desc: not available URL: From egil@REDACTED Mon Jul 15 17:53:06 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 15 Jul 2013 17:53:06 +0200 Subject: [erlang-patches] make edlin understand a few important control keys In-Reply-To: <1373900587.3597.26.camel@ax-sze> References: <1367844839.31752.73.camel@ax-sze> <51C1B85A.3050109@erlang.org> <1373900587.3597.26.camel@ax-sze> Message-ID: <51E41AE2.9040405@erlang.org> On 2013-07-15 17:03, Stefan Zegenhagen wrote: > Hi Fredrik, > >> I've gotten some feedback from your review, >> You need to add documentation under Erts-> "User's Guide" -> "tty - A >> command line interface" >> >> You need to add testcase in interactive_shell_SUITE a simplified >> example of how this testcase could look like; >> ctrl_w_and_ctrl_u(_Conf) -> >> rtnode([{putline,""}, {putline, "2."}, {getline, "2"}, >> {putline,"xxx yy"++[$\^w]++"."}, {getline,"xxx"}, {putline,"xxx >> yy"++[$\^u]++"z."}, {getline,"z"}],[]). > > Please find an updated version of the patch attached to this e-mail. I > hope that you still accept it via e-mail because the former patch was > sent the same way ;-). > > I have extended the documentation to list the new key combinations and > added tests to make sure they work. Refetched! It is vacation time for most people in otp so people re-reviewing will be slow(er) to answer. // Bj?rn-Egil > > > Kind regards, > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Schlager@REDACTED Tue Jul 16 12:23:02 2013 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Tue, 16 Jul 2013 10:23:02 +0000 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <1373899669.3597.22.camel@ax-sze> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> ,<1373887183.3597.15.camel@ax-sze> <12F2115FD1CCEE4294943B2608A18FA361B091AF@MAIL01.win.lbaum.eu>, <1373899669.3597.22.camel@ax-sze> Message-ID: <12F2115FD1CCEE4294943B2608A18FA361B09253@MAIL01.win.lbaum.eu> Hi, I've created a new patch. Since I wanted to give the branch a more describtive name, the previous branch 'snmp_fix_node_reduction_type' can be dropped. After looking into the snmp and os_mon application it seems to me that the otp_mibs application is the only application facing this kind of overflow problems. The os_mon application does already handle large values nicely, e.g. by masking memory-related values to the desired 32bit type ranges. This patch updates all applicable MIB objects of the OTP-MIB to 64bit based types. This affects the objects erlNodeReductions, erlNodeInBytes, erlNodeOutBytes as well as the MilliSeconds based objects erlNodeRunTime and erlNodeWallClock. Additionally, the patch checks and trims the values before inserting them into the node's shadow table. I've chosen to 'reset' (modulo operation) counter based values and simply limit other integer based values. The patch does also remove trailing whitespace from the edited files and fixes some date-related warnings in the MIB files (returned by 'smilint'). git fetch https://github.com/schlagert/otp.git otp_mibs_fix_type_overflows https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows.patch Regards Tobias ________________________________________ Von: Stefan Zegenhagen [stefan.zegenhagen@REDACTED] Gesendet: Montag, 15. Juli 2013 16:47 An: Tobias Schlager Cc: erlang-patches@REDACTED Betreff: Re: AW: [erlang-patches] SNMP erlNodeReductions defined too narrow Hi Tobias, > However, I think extending this and probably some other values to a > wider type is actually a good thing because providing a value that > typically overflows within a few hours is quite meaningless. I would > like to make another patch that actually fixes the problem but I'm not > sure what the desired behaviour would be for a counter. Should it > always reflect the highest valid value when overflowing or should it > start over? I only know this for network counters. Here the desired behaviour is that the counter starts again from zero. If someone wants to get accurate numbers from the device, he has to poll those counters in regular intervals to detect overflows. The minimum time (in which the counter can overflow) can easily be calculated from the link speed (10/100/1000 MBit) here. This behaviour sounds reasonable for other counters as well, especially when there's no counter-reset MIB object. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. From egil@REDACTED Tue Jul 16 15:19:57 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 16 Jul 2013 15:19:57 +0200 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B09253@MAIL01.win.lbaum.eu> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> , <1373887183.3597.15.camel@ax-sze> <12F2115FD1CCEE4294943B2608A18FA361B091AF@MAIL01.win.lbaum.eu>, <1373899669.3597.22.camel@ax-sze> <12F2115FD1CCEE4294943B2608A18FA361B09253@MAIL01.win.lbaum.eu> Message-ID: <51E5487D.7020305@erlang.org> On 2013-07-16 12:23, Tobias Schlager wrote: > Hi, > > I've created a new patch. Since I wanted to give the branch a more describtive name, the previous branch 'snmp_fix_node_reduction_type' can be dropped. After looking into the snmp and os_mon application it seems to me that the otp_mibs application is the only application facing this kind of overflow problems. The os_mon application does already handle large values nicely, e.g. by masking memory-related values to the desired 32bit type ranges. > > This patch updates all applicable MIB objects of the OTP-MIB to 64bit based types. This affects the objects erlNodeReductions, erlNodeInBytes, erlNodeOutBytes as well as the MilliSeconds based objects erlNodeRunTime and erlNodeWallClock. Additionally, the patch checks and trims the values before inserting them into the node's shadow table. I've chosen to 'reset' (modulo operation) counter based values and simply limit other integer based values. The patch does also remove trailing whitespace from the edited files and fixes some date-related warnings in the MIB files (returned by 'smilint'). > > git fetch https://github.com/schlagert/otp.git otp_mibs_fix_type_overflows > > https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows > https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows.patch Thank you. I've fetched this branch and replaced the previous one in pu. It is cooking. I've also reassigned it to the protocol team for review. This might take some time since most otp people are on vacation. Thank you! Regards, Bj?rn-Egil > > Regards > Tobias > > ________________________________________ > Von: Stefan Zegenhagen [stefan.zegenhagen@REDACTED] > Gesendet: Montag, 15. Juli 2013 16:47 > An: Tobias Schlager > Cc: erlang-patches@REDACTED > Betreff: Re: AW: [erlang-patches] SNMP erlNodeReductions defined too narrow > > Hi Tobias, > >> However, I think extending this and probably some other values to a >> wider type is actually a good thing because providing a value that >> typically overflows within a few hours is quite meaningless. I would >> like to make another patch that actually fixes the problem but I'm not >> sure what the desired behaviour would be for a counter. Should it >> always reflect the highest valid value when overflowing or should it >> start over? > I only know this for network counters. Here the desired behaviour is > that the counter starts again from zero. If someone wants to get > accurate numbers from the device, he has to poll those counters in > regular intervals to detect overflows. The minimum time (in which the > counter can overflow) can easily be calculated from the link speed > (10/100/1000 MBit) here. > > This behaviour sounds reasonable for other counters as well, especially > when there's no counter-reset MIB object. > > Kind regards, > > -- > Dr. Stefan Zegenhagen > > arcutronix GmbH > Garbsener Landstr. 10 > 30419 Hannover > Germany > > Tel: +49 511 277-2734 > Fax: +49 511 277-2709 > Email: stefan.zegenhagen@REDACTED > Web: www.arcutronix.com > > *Synchronize the Ethernet* > > General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - > Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht > Hannover; Ust-Id: DE257551767. > > Please consider the environment before printing this message. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From egil@REDACTED Tue Jul 16 15:51:45 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 16 Jul 2013 15:51:45 +0200 Subject: [erlang-patches] SNMP erlNodeReductions defined too narrow In-Reply-To: <51E5487D.7020305@erlang.org> References: <12F2115FD1CCEE4294943B2608A18FA361B08C4D@MAIL01.win.lbaum.eu> , <1373887183.3597.15.camel@ax-sze> <12F2115FD1CCEE4294943B2608A18FA361B091AF@MAIL01.win.lbaum.eu>, <1373899669.3597.22.camel@ax-sze> <12F2115FD1CCEE4294943B2608A18FA361B09253@MAIL01.win.lbaum.eu> <51E5487D.7020305@erlang.org> Message-ID: <51E54FF1.2060003@erlang.org> First off, big thanks for the test suite! =) I'm far from a snmp and mib expert but i guess it could be an issue with type changes in the mib? The patch has been reviewed and approved but I'm putting this on the R17 track, the next major release, because of potential incompatibilities. I'm letting it cook in r17-branch, unless tests start failing it will be merged. // Bj?rn-Egil On 2013-07-16 15:19, Bj?rn-Egil Dahlberg wrote: > On 2013-07-16 12:23, Tobias Schlager wrote: >> Hi, >> >> I've created a new patch. Since I wanted to give the branch a more >> describtive name, the previous branch 'snmp_fix_node_reduction_type' >> can be dropped. After looking into the snmp and os_mon application it >> seems to me that the otp_mibs application is the only application >> facing this kind of overflow problems. The os_mon application does >> already handle large values nicely, e.g. by masking memory-related >> values to the desired 32bit type ranges. >> >> This patch updates all applicable MIB objects of the OTP-MIB to 64bit >> based types. This affects the objects erlNodeReductions, >> erlNodeInBytes, erlNodeOutBytes as well as the MilliSeconds based >> objects erlNodeRunTime and erlNodeWallClock. Additionally, the patch >> checks and trims the values before inserting them into the node's >> shadow table. I've chosen to 'reset' (modulo operation) counter based >> values and simply limit other integer based values. The patch does >> also remove trailing whitespace from the edited files and fixes some >> date-related warnings in the MIB files (returned by 'smilint'). >> >> git fetch https://github.com/schlagert/otp.git >> otp_mibs_fix_type_overflows >> >> https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows >> >> https://github.com/schlagert/otp/compare/erlang:maint...otp_mibs_fix_type_overflows.patch >> > Thank you. I've fetched this branch and replaced the previous one in > pu. It is cooking. > > I've also reassigned it to the protocol team for review. This might > take some time since most otp people are on vacation. > > Thank you! Regards, > Bj?rn-Egil > >> >> Regards >> Tobias >> >> ________________________________________ >> Von: Stefan Zegenhagen [stefan.zegenhagen@REDACTED] >> Gesendet: Montag, 15. Juli 2013 16:47 >> An: Tobias Schlager >> Cc: erlang-patches@REDACTED >> Betreff: Re: AW: [erlang-patches] SNMP erlNodeReductions defined too >> narrow >> >> Hi Tobias, >> >>> However, I think extending this and probably some other values to a >>> wider type is actually a good thing because providing a value that >>> typically overflows within a few hours is quite meaningless. I would >>> like to make another patch that actually fixes the problem but I'm not >>> sure what the desired behaviour would be for a counter. Should it >>> always reflect the highest valid value when overflowing or should it >>> start over? >> I only know this for network counters. Here the desired behaviour is >> that the counter starts again from zero. If someone wants to get >> accurate numbers from the device, he has to poll those counters in >> regular intervals to detect overflows. The minimum time (in which the >> counter can overflow) can easily be calculated from the link speed >> (10/100/1000 MBit) here. >> >> This behaviour sounds reasonable for other counters as well, especially >> when there's no counter-reset MIB object. >> >> Kind regards, >> >> -- >> Dr. Stefan Zegenhagen >> >> arcutronix GmbH >> Garbsener Landstr. 10 >> 30419 Hannover >> Germany >> >> Tel: +49 511 277-2734 >> Fax: +49 511 277-2709 >> Email: stefan.zegenhagen@REDACTED >> Web: www.arcutronix.com >> >> *Synchronize the Ethernet* >> >> General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - >> Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht >> Hannover; Ust-Id: DE257551767. >> >> Please consider the environment before printing this message. >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From n.oxyde@REDACTED Tue Jul 23 09:27:57 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 23 Jul 2013 09:27:57 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> Message-ID: <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> Hello, I've added a commit to the branch that fix the bug discovered with Paul Davis where used variables in try expressions aren't properly marked as unsafe. Please refetch. -- Anthony Ramine Le 1 juil. 2013 ? 19:30, Anthony Ramine a ?crit : > Hi Fredrik, > > I've amended the commit message and gave an example of a simpler expression triggering the bug, e.g.: > > t(X, Y) -> > {A=X,A=Y}. > > As for the vt_no_unused/1 call in expr_list/1, it is a mistake as Vt1 comes from the variable tables returned by expr/3 in the lists:foldl/3 call, which means it can't contain any old variable which was unused anyway. > > Regards, > > -- > Anthony Ramine > > Le 1 juil. 2013 ? 11:23, Fredrik a ?crit : > >> On 06/06/2013 01:47 AM, Anthony Ramine wrote: >>> Hello, >>> >>> When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old >>> unused variables are not recorded as such: >>> >>> t(X, Y) -> >>> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. >>> >>> As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. >>> >>> The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: >>> >>> t(X, Y) -> >>> #r{a=A=X,b=A=Y}. >>> >>> Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. >>> >>> This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. >>> >>> git fetch >>> https://github.com/nox/otp.git >>> fix-erl_lint-variable-usage >>> >>> >>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage >>> >>> >>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch >>> >>> >>> Regards, >>> >>> >> Hi Anthony, >> Your patch has been reviewed and the feedback was: >> >> " >> Hi, >> >> The first example of the commit messages lacks a '}' before the dot. >> >> I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) >> >> I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? >> >> Best regards, >> >> " >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> > From n.oxyde@REDACTED Mon Jul 29 08:37:14 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Jul 2013 08:37:14 +0200 Subject: [erlang-patches] Lift 'after' blocks to zeroary functions Message-ID: Hello, If 'after' blocks are not lifted, the ids of functions in their bodies must be killed and it can make stacktraces more confusing than they should. We lift them to zeroary functions to avoid unnecessary killings and duplication of code. git fetch https://github.com/nox/otp.git lift-after https://github.com/nox/otp/compare/erlang:master...lift-after https://github.com/nox/otp/compare/erlang:master...lift-after.patch Regards, -- Anthony Ramine From fredrik@REDACTED Mon Jul 29 09:46:01 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Jul 2013 09:46:01 +0200 Subject: [erlang-patches] Lift 'after' blocks to zeroary functions In-Reply-To: References: Message-ID: <51F61DB9.7020005@erlang.org> On 07/29/2013 08:37 AM, Anthony Ramine wrote: > Hello, > > If 'after' blocks are not lifted, the ids of functions in their bodies must be killed and it can make stacktraces more confusing than they should. We lift them to zeroary functions to avoid unnecessary killings and duplication of code. > > git fetch https://github.com/nox/otp.git lift-after > > https://github.com/nox/otp/compare/erlang:master...lift-after > https://github.com/nox/otp/compare/erlang:master...lift-after.patch > > Regards, > Hello Anthony, I've fetched your patch and it has been assigned to be reviewed by responsible team. When this is done you will get more information. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Wed Jul 31 10:37:54 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 31 Jul 2013 10:37:54 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler/linter bug breaking unused variable warnings In-Reply-To: <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> Message-ID: Hello, I've added a commit that fixes variable usage tracking when reporting the redefinition of a record field, e.g. X is not reported as unused in: t() -> X = 1, #r{a=foo,a=bar}. Please refetch. Regards, -- Anthony Ramine Le 23 juil. 2013 ? 09:27, Anthony Ramine a ?crit : > Hello, > > I've added a commit to the branch that fix the bug discovered with Paul Davis where used variables in try expressions aren't properly marked as unsafe. > > Please refetch. > > -- > Anthony Ramine > > Le 1 juil. 2013 ? 19:30, Anthony Ramine a ?crit : > >> Hi Fredrik, >> >> I've amended the commit message and gave an example of a simpler expression triggering the bug, e.g.: >> >> t(X, Y) -> >> {A=X,A=Y}. >> >> As for the vt_no_unused/1 call in expr_list/1, it is a mistake as Vt1 comes from the variable tables returned by expr/3 in the lists:foldl/3 call, which means it can't contain any old variable which was unused anyway. >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 1 juil. 2013 ? 11:23, Fredrik a ?crit : >> >>> On 06/06/2013 01:47 AM, Anthony Ramine wrote: >>>> Hello, >>>> >>>> When analyzing complex expressions (i.e. comprehensions, cases, tries, ifs and receives), erl_lint does not forget about old unused variables when returning the updated variable table. This causes a bug where old >>>> unused variables are not recorded as such: >>>> >>>> t(X, Y) -> >>>> #r{a=[ K || K <- Y ],b=[ K || K <- Y ]. >>>> >>>> As erl_lint uses vtmerge_pat/2 to merge the results of the analysis of the two list comprehensions, X is marked as used and the warning is not emitted. >>>> >>>> The function vtmerge_pat/2 is used instead of the similar vtmerge/2 which does not mark multiple occurrences of a variable as usage to handle cases like the following one: >>>> >>>> t(X, Y) -> >>>> #r{a=A=X,b=A=Y}. >>>> >>>> Other simpler expressions like conses, tuples and external fun references does not correctly follow this behaviour. >>>> >>>> This patch fixes both issues and makes erl_lint not return old unused variables in updated tables and makes all compound expressions use vtmerge_pat/2. >>>> >>>> git fetch >>>> https://github.com/nox/otp.git >>>> fix-erl_lint-variable-usage >>>> >>>> >>>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage >>>> >>>> >>>> https://github.com/nox/otp/compare/erlang:maint...fix-erl_lint-variable-usage.patch >>>> >>>> >>>> Regards, >>>> >>>> >>> Hi Anthony, >>> Your patch has been reviewed and the feedback was: >>> >>> " >>> Hi, >>> >>> The first example of the commit messages lacks a '}' before the dot. >>> >>> I'm not sure I understand exactly what the paragraph starting with "Other simpler expressions..." means. Could you clarify, please? (And substitute "do" for "does"...) >>> >>> I noticed that if the call to vt_no_unused() in the last line of expr_list/3 is removed the test suite still passes; there is no case where the call actually removes anything. Would it be possible to include a test that covers this particular call? >>> >>> Best regards, >>> >>> " >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >> > From fredrik@REDACTED Wed Jul 31 11:19:52 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 31 Jul 2013 11:19:52 +0200 Subject: [erlang-patches] [erlang-bugs] Compiler/linter bug breaking unused variable warnings In-Reply-To: References: <82DC27D088947C4D943175FDA0DA60F411526021@EXMB13TSTRZ2.tcad.telia.se> <5312CBA2-4C31-46FF-9E8A-74589DB5349D@gmail.com> <51D14AA1.2000508@erlang.org> <88786564-AE73-4005-AC73-0A23689DD35D@gmail.com> Message-ID: <51F8D6B8.1070208@erlang.org> On 07/31/2013 10:37 AM, Anthony Ramine wrote: > Hello, > > I've added a commit that fixes variable usage tracking when reporting the redefinition of a record field, e.g. X is not reported as unused in: > > t() -> X = 1, #r{a=foo,a=bar}. > > Please refetch. > > Regards, > Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team