From n.oxyde@REDACTED Tue Oct 1 13:27:17 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Oct 2013 13:27:17 +0200 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <5199DAEF.2080603@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> Message-ID: Hello, I see on the development page that an action is required from me for this patch [1]. And what exactly is required from me..? Regards, [1] http://www.erlang.org/development/ Le 20 mai 2013 ? 10:12, Fredrik a ?crit : > On 05/19/2013 12:33 PM, Anthony Ramine wrote: >> Hello Michael, >> >> This patch fixes support of implicit funs with variables in igor. >> >> git fetch https://github.com/nox/otp.git igor-funs >> >> https://github.com/nox/otp/compare/erlang:maint...igor-funs >> https://github.com/nox/otp/compare/erlang:maint...igor-funs.patch >> >> Regards, >> > Hello Anthony, > I've fetched your patch and it should be visible in the 'pu' branch shortly. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > -- Anthony Ramine From henrik@REDACTED Tue Oct 1 13:58:00 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 1 Oct 2013 13:58:00 +0200 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> Message-ID: <524AB8C8.1020008@erlang.org> Hi I was awaiting an answer to this: @richcarl Should I amend this commit? And the possible amend to the commit. If that is not going to happen I can put it through the test-merge precedure /Henrik On 2013-10-01 13:27, Anthony Ramine wrote: > Hello, > > I see on the development page that an action is required from me for this patch [1]. > > And what exactly is required from me..? > > Regards, > > [1] http://www.erlang.org/development/ > > Le 20 mai 2013 ? 10:12, Fredrik a ?crit : > >> On 05/19/2013 12:33 PM, Anthony Ramine wrote: >>> Hello Michael, >>> >>> This patch fixes support of implicit funs with variables in igor. >>> >>> git fetch https://github.com/nox/otp.git igor-funs >>> >>> https://github.com/nox/otp/compare/erlang:maint...igor-funs >>> https://github.com/nox/otp/compare/erlang:maint...igor-funs.patch >>> >>> Regards, >>> >> Hello Anthony, >> I've fetched your patch and it should be visible in the 'pu' branch shortly. >> Thanks, >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Tue Oct 1 14:25:38 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Tue, 01 Oct 2013 14:25:38 +0200 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <524AB8C8.1020008@erlang.org> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> Message-ID: <524ABF42.2030904@gmail.com> Sorry, drowning in stuff as usual. Anthony, I trust that your analysis of why that clause could be deleted, so that should be ok. But I thought there was something weird about the format changes, and now I think I see what it is: calls like arity_qualifier_body(Name) should never return a naked atom or integer - always a syntax tree. So the fix for the revert "fun F/A" case should be done in implicit_fun_name/1 instead, just as it's handled for "fun M:F/A". And in the reverting of "fun M:F/A", you shouldn't have to change anything at all, since it's already handled. /Richard On 2013-10-01 13:58 , Henrik Nord wrote: > Hi > I was awaiting an answer to this: > @richcarl Should I amend this commit? > And the possible amend to the commit. > > If that is not going to happen I can put it through the test-merge precedure > > /Henrik > > On 2013-10-01 13:27, Anthony Ramine wrote: >> Hello, >> >> I see on the development page that an action is required from me for this patch [1]. >> >> And what exactly is required from me..? >> >> Regards, >> >> [1]http://www.erlang.org/development/ >> >> Le 20 mai 2013 ? 10:12, Fredrik a ?crit : >> >>> On 05/19/2013 12:33 PM, Anthony Ramine wrote: >>>> Hello Michael, >>>> >>>> This patch fixes support of implicit funs with variables in igor. >>>> >>>> git fetchhttps://github.com/nox/otp.git igor-funs >>>> >>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs >>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs.patch >>>> >>>> Regards, >>>> >>> Hello Anthony, >>> I've fetched your patch and it should be visible in the 'pu' branch shortly. >>> Thanks, >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> > > -- > /Henrik Nord Erlang/OTP > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From n.oxyde@REDACTED Tue Oct 1 14:30:07 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 1 Oct 2013 14:30:07 +0200 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <524ABF42.2030904@gmail.com> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> Message-ID: Thanks for the reply, will amend this tonight. Le 1 oct. 2013 ? 14:25, Richard Carlsson a ?crit : > Sorry, drowning in stuff as usual. Anthony, I trust that your analysis of why that clause could be deleted, so that should be ok. But I thought there was something weird about the format changes, and now I think I see what it is: calls like arity_qualifier_body(Name) should never return a naked atom or integer - always a syntax tree. So the fix for the revert "fun F/A" case should be done in implicit_fun_name/1 instead, just as it's handled for "fun M:F/A". And in the reverting of "fun M:F/A", you shouldn't have to change anything at all, since it's already handled. > > /Richard > > On 2013-10-01 13:58 , Henrik Nord wrote: >> Hi >> I was awaiting an answer to this: >> @richcarl Should I amend this commit? >> And the possible amend to the commit. >> >> If that is not going to happen I can put it through the test-merge precedure >> >> /Henrik >> >> On 2013-10-01 13:27, Anthony Ramine wrote: >>> Hello, >>> >>> I see on the development page that an action is required from me for this patch [1]. >>> >>> And what exactly is required from me..? >>> >>> Regards, >>> >>> [1]http://www.erlang.org/development/ >>> >>> Le 20 mai 2013 ? 10:12, Fredrik a ?crit : >>> >>>> On 05/19/2013 12:33 PM, Anthony Ramine wrote: >>>>> Hello Michael, >>>>> >>>>> This patch fixes support of implicit funs with variables in igor. >>>>> >>>>> git fetchhttps://github.com/nox/otp.git igor-funs >>>>> >>>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs >>>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs.patch >>>>> >>>>> Regards, >>>>> >>>> Hello Anthony, >>>> I've fetched your patch and it should be visible in the 'pu' branch shortly. >>>> Thanks, >>>> >>>> -- >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> >> >> -- >> /Henrik Nord Erlang/OTP >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > -- Anthony Ramine From vinoski@REDACTED Wed Oct 2 09:02:35 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 2 Oct 2013 03:02:35 -0400 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: I've added a new commit to this branch that addresses the concerns Anthony raised. Please refetch. --steve On Mon, Sep 30, 2013 at 5:32 AM, Steve Vinoski wrote: > Great feedback, Anthony -- thanks very much. Clearly there are more > backward compatibility issues I need to address. > > --steve > > > On Mon, Sep 30, 2013 at 4:00 AM, Anthony Ramine wrote: > >> Hello Steve, >> >> Great patch, I added a few comments about some edge cases. >> >> Regards, >> >> Le 30 sept. 2013 ? 09:38, Steve Vinoski a ?crit : >> >> > This patch improves the performance of some orddict functions by >> reimplementing them using the lists module: >> > >> > https://github.com/erlang/otp/pull/91 >> > >> > The commit message at the link above is very detailed and includes >> performance measurements, so please read it to know more about the changes. >> > >> > --steve >> > _______________________________________________ >> > erlang-patches mailing list >> > erlang-patches@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-patches >> >> -- >> Anthony Ramine >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc@REDACTED Wed Oct 2 09:14:25 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Wed, 2 Oct 2013 03:14:25 -0400 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: This looks great, major improvement for larger orddicts, +1 On Wed, Oct 2, 2013 at 3:02 AM, Steve Vinoski wrote: > I've added a new commit to this branch that addresses the concerns Anthony > raised. Please refetch. > > --steve > > > On Mon, Sep 30, 2013 at 5:32 AM, Steve Vinoski wrote: > >> Great feedback, Anthony -- thanks very much. Clearly there are more >> backward compatibility issues I need to address. >> >> --steve >> >> >> On Mon, Sep 30, 2013 at 4:00 AM, Anthony Ramine wrote: >> >>> Hello Steve, >>> >>> Great patch, I added a few comments about some edge cases. >>> >>> Regards, >>> >>> Le 30 sept. 2013 ? 09:38, Steve Vinoski a ?crit : >>> >>> > This patch improves the performance of some orddict functions by >>> reimplementing them using the lists module: >>> > >>> > https://github.com/erlang/otp/pull/91 >>> > >>> > The commit message at the link above is very detailed and includes >>> performance measurements, so please read it to know more about the changes. >>> > >>> > --steve >>> > _______________________________________________ >>> > erlang-patches mailing list >>> > erlang-patches@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-patches >>> >>> -- >>> Anthony Ramine >>> >>> >> > > _______________________________________________ > 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 n.oxyde@REDACTED Wed Oct 2 10:55:26 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 2 Oct 2013 10:55:26 +0200 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <524B44F6.2090000@gmail.com> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> Message-ID: <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> I guess we can merge it now then. Le 1 oct. 2013 ? 23:56, Richard Carlsson a ?crit : > Maybe I got confused - was the format change in the other direction, i.e., used to be atoms but is now trees? In that case, I guess you're right. Just make sure that the code does the right thing in all combinations of cases, and you're done. :-) > > /Richard > > On 2013-10-01 23:41, Anthony Ramine wrote: >> In fact I really don't see what you mean. The problem is revert_implicit_fun/1 calling concrete/1 on the individual parts when it shouldn't. >> >> I don't see how changing another function would fix anything. >> >> Le 1 oct. 2013 ? 14:30, Anthony Ramine a ?crit : >> >>> Thanks for the reply, will amend this tonight. >>> >>> Le 1 oct. 2013 ? 14:25, Richard Carlsson a ?crit : >>> >>>> Sorry, drowning in stuff as usual. Anthony, I trust that your analysis of why that clause could be deleted, so that should be ok. But I thought there was something weird about the format changes, and now I think I see what it is: calls like arity_qualifier_body(Name) should never return a naked atom or integer - always a syntax tree. So the fix for the revert "fun F/A" case should be done in implicit_fun_name/1 instead, just as it's handled for "fun M:F/A". And in the reverting of "fun M:F/A", you shouldn't have to change anything at all, since it's already handled. >>>> >>>> /Richard >>>> >>>> On 2013-10-01 13:58 , Henrik Nord wrote: >>>>> Hi >>>>> I was awaiting an answer to this: >>>>> @richcarl Should I amend this commit? >>>>> And the possible amend to the commit. >>>>> >>>>> If that is not going to happen I can put it through the test-merge precedure >>>>> >>>>> /Henrik >>>>> >>>>> On 2013-10-01 13:27, Anthony Ramine wrote: >>>>>> Hello, >>>>>> >>>>>> I see on the development page that an action is required from me for this patch [1]. >>>>>> >>>>>> And what exactly is required from me..? >>>>>> >>>>>> Regards, >>>>>> >>>>>> [1]http://www.erlang.org/development/ >>>>>> >>>>>> Le 20 mai 2013 ? 10:12, Fredrik a ?crit : >>>>>> >>>>>>> On 05/19/2013 12:33 PM, Anthony Ramine wrote: >>>>>>>> Hello Michael, >>>>>>>> >>>>>>>> This patch fixes support of implicit funs with variables in igor. >>>>>>>> >>>>>>>> git fetchhttps://github.com/nox/otp.git igor-funs >>>>>>>> >>>>>>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs >>>>>>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs.patch >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>> Hello Anthony, >>>>>>> I've fetched your patch and it should be visible in the 'pu' branch shortly. >>>>>>> Thanks, >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> BR Fredrik Gustafsson >>>>>>> Erlang OTP Team >>>>>>> >>>>> >>>>> -- >>>>> /Henrik Nord Erlang/OTP >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>> >>>> >>> >>> -- >>> Anthony Ramine >>> >> > -- Anthony Ramine From vinoski@REDACTED Wed Oct 2 23:36:39 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 2 Oct 2013 17:36:39 -0400 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: I've added a third commit to this branch to address new concerns and suggestions from Anthony Ramine and Richard Carlsson. I appreciate your help, guys. Please refetch. --steve On Wed, Oct 2, 2013 at 3:02 AM, Steve Vinoski wrote: > I've added a new commit to this branch that addresses the concerns Anthony > raised. Please refetch. > > --steve > > > On Mon, Sep 30, 2013 at 5:32 AM, Steve Vinoski wrote: > >> Great feedback, Anthony -- thanks very much. Clearly there are more >> backward compatibility issues I need to address. >> >> --steve >> >> >> On Mon, Sep 30, 2013 at 4:00 AM, Anthony Ramine wrote: >> >>> Hello Steve, >>> >>> Great patch, I added a few comments about some edge cases. >>> >>> Regards, >>> >>> Le 30 sept. 2013 ? 09:38, Steve Vinoski a ?crit : >>> >>> > This patch improves the performance of some orddict functions by >>> reimplementing them using the lists module: >>> > >>> > https://github.com/erlang/otp/pull/91 >>> > >>> > The commit message at the link above is very detailed and includes >>> performance measurements, so please read it to know more about the changes. >>> > >>> > --steve >>> > _______________________________________________ >>> > erlang-patches mailing list >>> > erlang-patches@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-patches >>> >>> -- >>> Anthony Ramine >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Thu Oct 3 14:30:35 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 3 Oct 2013 14:30:35 +0200 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> References: <5195C82C.104@gmail.com> <5199DAEF.2080603@erlang.org> <524AB8C8.1020008@erlang.org> <524ABF42.2030904@gmail.com> <7A4238B1-3F41-4BD0-8F4F-639F95CB8919@gmail.com> <524B44F6.2090000@gmail.com> <35098A6E-014B-4BB2-8672-E6B17EB99350@gmail.com> Message-ID: <524D636B.4080508@erlang.org> I will move it into the que Thank you for your contribution! On 2013-10-02 10:55, Anthony Ramine wrote: > I guess we can merge it now then. > > Le 1 oct. 2013 ? 23:56, Richard Carlsson a ?crit : > >> Maybe I got confused - was the format change in the other direction, i.e., used to be atoms but is now trees? In that case, I guess you're right. Just make sure that the code does the right thing in all combinations of cases, and you're done. :-) >> >> /Richard >> >> On 2013-10-01 23:41, Anthony Ramine wrote: >>> In fact I really don't see what you mean. The problem is revert_implicit_fun/1 calling concrete/1 on the individual parts when it shouldn't. >>> >>> I don't see how changing another function would fix anything. >>> >>> Le 1 oct. 2013 ? 14:30, Anthony Ramine a ?crit : >>> >>>> Thanks for the reply, will amend this tonight. >>>> >>>> Le 1 oct. 2013 ? 14:25, Richard Carlsson a ?crit : >>>> >>>>> Sorry, drowning in stuff as usual. Anthony, I trust that your analysis of why that clause could be deleted, so that should be ok. But I thought there was something weird about the format changes, and now I think I see what it is: calls like arity_qualifier_body(Name) should never return a naked atom or integer - always a syntax tree. So the fix for the revert "fun F/A" case should be done in implicit_fun_name/1 instead, just as it's handled for "fun M:F/A". And in the reverting of "fun M:F/A", you shouldn't have to change anything at all, since it's already handled. >>>>> >>>>> /Richard >>>>> >>>>> On 2013-10-01 13:58 , Henrik Nord wrote: >>>>>> Hi >>>>>> I was awaiting an answer to this: >>>>>> @richcarl Should I amend this commit? >>>>>> And the possible amend to the commit. >>>>>> >>>>>> If that is not going to happen I can put it through the test-merge precedure >>>>>> >>>>>> /Henrik >>>>>> >>>>>> On 2013-10-01 13:27, Anthony Ramine wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I see on the development page that an action is required from me for this patch [1]. >>>>>>> >>>>>>> And what exactly is required from me..? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> [1]http://www.erlang.org/development/ >>>>>>> >>>>>>> Le 20 mai 2013 ? 10:12, Fredrik a ?crit : >>>>>>> >>>>>>>> On 05/19/2013 12:33 PM, Anthony Ramine wrote: >>>>>>>>> Hello Michael, >>>>>>>>> >>>>>>>>> This patch fixes support of implicit funs with variables in igor. >>>>>>>>> >>>>>>>>> git fetchhttps://github.com/nox/otp.git igor-funs >>>>>>>>> >>>>>>>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs >>>>>>>>> https://github.com/nox/otp/compare/erlang:maint...igor-funs.patch >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>> Hello Anthony, >>>>>>>> I've fetched your patch and it should be visible in the 'pu' branch shortly. >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> BR Fredrik Gustafsson >>>>>>>> Erlang OTP Team >>>>>>>> >>>>>> -- >>>>>> /Henrik Nord Erlang/OTP >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> erlang-patches mailing list >>>>>> erlang-patches@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>>> >>>> -- >>>> Anthony Ramine >>>> -- /Henrik Nord Erlang/OTP From vinoski@REDACTED Fri Oct 4 02:58:52 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 3 Oct 2013 20:58:52 -0400 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: OK, Anthony brought up yet another issue with my previous modified orddict, which is that if someone passes an improper list instead of an orddict, the new version acts differently than the old. Since the goal is backwards compatibility with improved performance, I've added a fourth commit that deals with these issues. Notably, the original orddict, if passed an improper list or a list with elements that are not 2-tuples, will still work properly if the key being dealt with occurs before the problematic part of the list. For example, this works with the R16B02 orddict: {ok,2} = orddict:find(1,[{1,2},{2,3,4}]). I believe the latest commit addresses this and the previous comments, while still providing an orddict with improved performance: https://github.com/vinoski/otp/commit/a261aae36f617e39c5e53dc8a16fa186e4c5830c Thanks again to Anthony and Richard for their excellent feedback. --steve On Wed, Oct 2, 2013 at 5:36 PM, Steve Vinoski wrote: > I've added a third commit to this branch to address new concerns and > suggestions from Anthony Ramine and Richard Carlsson. I appreciate your > help, guys. > > Please refetch. > > --steve > > > On Wed, Oct 2, 2013 at 3:02 AM, Steve Vinoski wrote: > >> I've added a new commit to this branch that addresses the concerns >> Anthony raised. Please refetch. >> >> --steve >> >> >> On Mon, Sep 30, 2013 at 5:32 AM, Steve Vinoski wrote: >> >>> Great feedback, Anthony -- thanks very much. Clearly there are more >>> backward compatibility issues I need to address. >>> >>> --steve >>> >>> >>> On Mon, Sep 30, 2013 at 4:00 AM, Anthony Ramine wrote: >>> >>>> Hello Steve, >>>> >>>> Great patch, I added a few comments about some edge cases. >>>> >>>> Regards, >>>> >>>> Le 30 sept. 2013 ? 09:38, Steve Vinoski a ?crit : >>>> >>>> > This patch improves the performance of some orddict functions by >>>> reimplementing them using the lists module: >>>> > >>>> > https://github.com/erlang/otp/pull/91 >>>> > >>>> > The commit message at the link above is very detailed and includes >>>> performance measurements, so please read it to know more about the changes. >>>> > >>>> > --steve >>>> > _______________________________________________ >>>> > erlang-patches mailing list >>>> > erlang-patches@REDACTED >>>> > http://erlang.org/mailman/listinfo/erlang-patches >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rich.neswold@REDACTED Fri Oct 4 05:27:42 2013 From: rich.neswold@REDACTED (Rich Neswold) Date: Thu, 3 Oct 2013 22:27:42 -0500 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: On Thu, Oct 3, 2013 at 7:58 PM, Steve Vinoski wrote: > OK, Anthony brought up yet another issue with my previous modified > orddict, which is that if someone passes an improper list instead of an > orddict, the new version acts differently than the old. Since the goal is > backwards compatibility with improved performance, I've added a fourth > commit that deals with these issues. > I'm not sure whether this is the backwards compatibility one wants to preserve. Usually you want to preserve an API, but in this case you're preserving code that manipulates the internal representation of an orddict. Any code that uses the orddict API should not end up with an improper list. Any code that passes an improper list to orddict should break. -- Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.chochol@REDACTED Fri Oct 4 08:52:19 2013 From: jan.chochol@REDACTED (Jan Chochol) Date: Fri, 4 Oct 2013 08:52:19 +0200 Subject: [erlang-patches] Race condition in mnesia_locker after nodedown for sticky_locks Message-ID: Hi OTP team, We found found bug (race condition) in mnesia code regarding disconnecting nodes owning sticky lock. Our (simplified) setup consists of two nodes, when first node acts as active one and second acts as standby. It means that all requests are normally going through first node and second node is only used after fail of the first. Mnesia in our scenario is used as HA data store. For this setup it seems that sticky locks are ideal solution - all operations are performed only on one node. Everything worked well, until we found that some times transactions started just after disconnecting first node hangs indefinitely. This bogus behaviour was very rare, so it seemed that there is some race condition how sticky locks are handled after disconnection of node. We found that there is problem in synchronization of transaction process (process initializing transaction) and mnesia_locker process. It can happen that mnesia_locker process respond to lock request with {switch, N, Req} message, but node N is already disconnected. Part of message trace to show the problem: List of interesting PIDs: mnesia_controller="<0.93.0>" mnesia_tm="<0.89.0>" mnesia_monitor="<0.85.0>" mnesia_locker="<0.87.0>" mnesia_recover="<0.88.0>" transaction process="<0.206.0>" Message trace: % mnesia_monitor lost track of mnesia_monitor at node 1 (<0.85.0>) << {'EXIT',<5184.92.0>,noconnection} % mnesia_monitor receives nodedown - this message is ignored (<0.85.0>) << {nodedown,'gcfc-triple1_519129@REDACTED'} % mnesia_monitor call mnesia_recover:mnesia_down() (<0.85.0>) <0.88.0> ! {'$gen_cast', {mnesia_down,'gcfc-triple1_519129@REDACTED'}} % mnesia_recover receives mnesia_down, nothing to do there (<0.88.0>) << {'$gen_cast',{mnesia_down,'gcfc-triple1_519129@REDACTED'}} % mnesia_monitor call mnesia_controller:mnesia_down (<0.85.0>) <0.93.0> ! {'$gen_cast', {mnesia_down,'gcfc-triple1_519129@REDACTED'}} % mnesia_controller receives mnesia_down (<0.93.0>) << {'$gen_cast',{mnesia_down,'gcfc-triple1_519129@REDACTED'}} % mnesia_controller calls mnesia_recover:log_mnesia_down() (<0.93.0>) <0.88.0> ! {'$gen_call', {<0.93.0>,#Ref<0.0.0.1860>}, {log_mnesia_down,'gcfc-triple1_519129@REDACTED'}} % mnesia_recover receives log_mnesia_down, store it in decision table and reply (<0.88.0>) << {'$gen_call',{<0.93.0>,#Ref<0.0.0.1860>}, {log_mnesia_down,'gcfc-triple1_519129@REDACTED'}} (<0.88.0>) <0.93.0> ! {#Ref<0.0.0.1860>,ok} % mnesia_controller receives response from mnesia_recover:log_mnesia_down() (<0.93.0>) << {#Ref<0.0.0.1860>,ok} % mnesia_controller calls mnesia_monitor:mnesia_down(mnesia_controller, Node) (<0.93.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_controller, 'gcfc-triple1_519129@REDACTED'}} % mnesia_controller receives mnesia_down, mnesia_controller (<0.85.0>) << {'$gen_cast', {mnesia_down,mnesia_controller, 'gcfc-triple1_519129@REDACTED'}} % mnesia_controller forwards mnesia_down to mnesia_tm (<0.85.0>) <0.89.0> ! {mnesia_down,'gcfc-triple1_519129@REDACTED'} % mnesia_tm receives mnesia_down (<0.89.0>) << {mnesia_down,'gcfc-triple1_519129@REDACTED'} % mnesia_tm calls mnesia_monitor:mnesia_down(mnesia_tm, {Node, ParticipantsTids}), (<0.89.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_tm, {'gcfc-triple1_519129@REDACTED',[]}}} % mnesia_monitor receives mnesia_down, mnesia_tm % now it is going to call mnesia_locker:mnesia_down, which will send release_remote_non_pending (<0.85.0>) << {'$gen_cast', {mnesia_down, mnesia_tm, {'gcfc-triple1_519129@REDACTED',[]}}} % Our processes receives information about node down and try to recover from mnesiai (<0.206.0>) << {activate,true} % Starts outer transaction (<0.206.0>) <0.89.0> ! {{<0.206.0>,#Ref<0.0.0.1875>},start_outer} (<0.89.0>) << {{<0.206.0>,#Ref<0.0.0.1875>},start_outer} % Reply for start_outer (<0.89.0>) <0.206.0> ! {mnesia_tm,#Ref<0.0.0.1875>, {new_tid,{tid,176,<0.206.0>},245835}} (<0.206.0>) << {mnesia_tm,#Ref<0.0.0.1875>, {new_tid,{tid,176,<0.206.0>},245835}} % Try to obtain lock for mnesia:select (just failed node holded sticky lock for that table) (<0.206.0>) {mnesia_locker,'gcfc-triple2_519129@REDACTED'} ! {<0.206.0>, {read, {tid,176, <0.206.0>}, {'tasks_tt_gcfc-triple1_519129@REDACTED', '______WHOLETABLE_____'}}} (<0.87.0>) << {<0.206.0>, {read, {tid,176,<0.206.0>}, {'tasks_tt_gcfc-triple1_519129@REDACTED', '______WHOLETABLE_____'}}} % mnesia_locker informs out process that it needs switch sticky lock (<0.87.0>) <0.206.0> ! {mnesia_locker,'gcfc-triple2_519129@REDACTED', {switch,'gcfc-triple1_519129@REDACTED', {<0.206.0>, {read, {tid,176,<0.206.0>}, {'tasks_tt_gcfc-triple1_519129@REDACTED', '______WHOLETABLE_____'}}}}} (<0.206.0>) << {mnesia_locker,'gcfc-triple2_519129@REDACTED', {switch,'gcfc-triple1_519129@REDACTED', {<0.206.0>, {read, {tid,176,<0.206.0>}, {'tasks_tt_gcfc-triple1_519129@REDACTED', '______WHOLETABLE_____'}}}}} % Our proces just want to send {<0.206.0>, {read, {tid,176,<0.206.0>}, {'tasks_tt_gcfc-triple1_519129@REDACTED', '______WHOLETABLE_____'}}} to other node % Other node is not connected, so Erlang tryies to connect to it (<0.21.0> is net_kernel process) (<0.206.0>) <0.21.0> ! {'$gen_call', {<0.206.0>,#Ref<0.0.0.1884>}, {connect,normal,'gcfc-triple1_519129@REDACTED'}} % Connection to remote node was unsucsefull, and our process is hanged in this function: % % l_req_rec(Node, Store) -> % ?ets_insert(Store, {nodes, Node}), % receive % {?MODULE, Node, Reply} -> % Reply; % {mnesia_down, Node} -> % {not_granted, {node_not_running, Node}} % end. % % It will never get out, as sent message is lost (<0.206.0>) << {#Ref<0.0.0.1884>,false} % mnesia_monitor call mnesia_locker:mnesia_down, which is sending release_remote_non_pending (<0.85.0>) <0.87.0> ! {release_remote_non_pending, 'gcfc-triple1_519129@REDACTED',[]} % mnesia_locker receives release_remote_non_pending % it removes sticky locks of failed nodes and releases all transactions % but it is too late - process <0.206.0> is already stucked for waiting for response from not connected node (<0.87.0>) << {release_remote_non_pending,'gcfc-triple1_519129@REDACTED',[]} % mnesia_locker call mnesia_monitor:mnesia_down(mnesia_locker, Node) (<0.87.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_locker, 'gcfc-triple1_519129@REDACTED'}} % mnesia_monitor receives mnesia_down, mnesia_locker (<0.85.0>) << {'$gen_cast', {mnesia_down,mnesia_locker,'gcfc-triple1_519129@REDACTED'}} % mnesia_monitor calls mnesia_lib:report_system_event, which will send notify to mnesia_event (<0.85.0>) <0.83.0> ! {notify, {mnesia_system_event, {mnesia_down,'gcfc-triple1_519129@REDACTED'}}} So problem is that transaction process sends messages to not-connected node and awaits response which will never come. One of the easiest solution is to monitor remote process, which prevent this from happening. Suggested patch is available at: git fetch git://github.com/janchochol/otp.git sticky_lock_race https://github.com/janchochol/otp/compare/erlang:maint...sticky_lock_race https://github.com/janchochol/otp/compare/erlang:maint...sticky_lock_race.patch You can try to reproduce the problem with following module: --- BEGIN OF slock.erl --- %% stick_lock problem reproducer %% %% To reproduce problem execute these commands in parallel: %% %% erl -sname n2@REDACTED -cookie slock -s slock n2 %% erl -sname n1@REDACTED -cookie slock -s slock n1 %% %% Problem is timing related, so it has relatively low probability of reproducing. %% To increase probability use this patch: %% %% --- a/lib/mnesia/src/mnesia_locker.erl %% +++ b/lib/mnesia/src/mnesia_locker.erl %% @@ -663,6 +663,7 @@ mnesia_down(N, Pending) -> %% %% race with mnesia_tm's coordinator processes %% %% that may restart and acquire new locks. %% %% mnesia_monitor ensures the sync. %% + timer:sleep(1000), %% Pid ! {release_remote_non_pending, N, Pending} %% end. %% %% %% When problem appears n1 node will hang indefinitely. %% When problem is not present n1 will finish shortly after n2. -module(slock). -export([n1/0, n2/0]). wait_for_n2() -> case rpc:call(n2@REDACTED, erlang, whereis, [n2]) of Pid when is_pid(Pid) -> Pid; _ -> timer:sleep(100), wait_for_n2() end. wait_fun(Fun, PollIntervalMs) -> case Fun() of false -> timer:sleep(PollIntervalMs), wait_fun(Fun, PollIntervalMs); true -> ok end. n1() -> register(n1, self()), io:format("n1: statred~n", []), io:format("n1: waiting for n2~n", []), N2 = wait_for_n2(), io:format("n1: n2 found~n", []), io:format("n1: init mnesia start~n", []), ok = application:start(mnesia, permanent), ok = rpc:call(n2@REDACTED, application, start, [mnesia, permanent]), {ok, [_ | _]} = mnesia:change_config(extra_db_nodes, [n2@REDACTED]), {atomic, ok} = mnesia:create_table(t1, [{ram_copies, [n1@REDACTED, n2@REDACTED]}]), ok = rpc:call(n2@REDACTED, mnesia, wait_for_tables, [[t1], infinity]), io:format("n1: init mnesia end~n", []), N2 ! {ping, self()}, receive step -> ok end, wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang end, 100), io:format("n1: select start~n", []), Ret = mnesia:transaction(fun() -> wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang end, 10), mnesia:select(t1, [{{t1, '_', '_'}, [], ['$_']}]) end), io:format("n1: select end: ~p~n", [Ret]), init:stop(). n2() -> register(n2, self()), io:format("n2: statred~n", []), io:format("n2: waiting for n1 ping~n", []), N2 = receive {ping, IN2} -> IN2 end, io:format("n2: n1 pinged~n", []), io:format("n2: write start~n", []), mnesia:transaction(fun() -> mnesia:write(t1, {t1, a, b}, sticky_write) end), io:format("n2: write end~n", []), N2 ! step, io:format("n2: finish~n", []), erlang:halt(). --- END OF slock.erl --- I do not see any other easy solution for this problem. Best Regards, Jan Chochol From mc@REDACTED Fri Oct 4 09:34:18 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Fri, 4 Oct 2013 03:34:18 -0400 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: That's actually a pretty good point, Backwards compatibility in Erlang is usually a slow gradual 3 version process.. But it might be prudent to throw a warning when a non orddict is introduced. On Thu, Oct 3, 2013 at 11:27 PM, Rich Neswold wrote: > On Thu, Oct 3, 2013 at 7:58 PM, Steve Vinoski wrote: > >> OK, Anthony brought up yet another issue with my previous modified >> orddict, which is that if someone passes an improper list instead of an >> orddict, the new version acts differently than the old. Since the goal is >> backwards compatibility with improved performance, I've added a fourth >> commit that deals with these issues. >> > > I'm not sure whether this is the backwards compatibility one wants to > preserve. Usually you want to preserve an API, but in this case you're > preserving code that manipulates the internal representation of an orddict. > Any code that uses the orddict API should not end up with an improper list. > Any code that passes an improper list to orddict should break. > > -- > Rich > > _______________________________________________ > 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 raimo+erlang-patches@REDACTED Fri Oct 4 12:19:08 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Fri, 4 Oct 2013 12:19:08 +0200 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: <20131004101906.GB25851@erix.ericsson.se> On Thu, Oct 03, 2013 at 10:27:42PM -0500, Rich Neswold wrote: > On Thu, Oct 3, 2013 at 7:58 PM, Steve Vinoski wrote: > > > OK, Anthony brought up yet another issue with my previous modified > > orddict, which is that if someone passes an improper list instead of an > > orddict, the new version acts differently than the old. Since the goal is > > backwards compatibility with improved performance, I've added a fourth > > commit that deals with these issues. > > > > I'm not sure whether this is the backwards compatibility one wants to > preserve. Usually you want to preserve an API, but in this case you're > preserving code that manipulates the internal representation of an orddict. > Any code that uses the orddict API should not end up with an improper list. > Any code that passes an improper list to orddict should break. But in the case of orddict, it is actually documented to have a data representation being an ordered list of key-value tuples. Therefore there is a possibility that someone has misused that knowledge and uses an improper ordered list of key-value tuples, which may not be violating the documentation... > > -- > Rich > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Fri Oct 4 12:23:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 4 Oct 2013 12:23:41 +0200 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> Message-ID: <627499B9-5833-4309-911A-7954A374924E@gmail.com> Hello Steve, Btw did you measure a call to is_key/2 with a very large orddict not containing the given key? Wouldn't the short-circuiting due to ordering allow for better performances than using keyfind/3? Also please note there is nearly no way to totally address backwards-compatibility with lists functions, due to the short-circuiting: orddict:is_key(b, [{a,1},{c,3},not_a_pair]). Le 4 oct. 2013 ? 02:58, Steve Vinoski a ?crit : > OK, Anthony brought up yet another issue with my previous modified orddict, which is that if someone passes an improper list instead of an orddict, the new version acts differently than the old. Since the goal is backwards compatibility with improved performance, I've added a fourth commit that deals with these issues. > > Notably, the original orddict, if passed an improper list or a list with elements that are not 2-tuples, will still work properly if the key being dealt with occurs before the problematic part of the list. For example, this works with the R16B02 orddict: > > {ok,2} = orddict:find(1,[{1,2},{2,3,4}]). > > I believe the latest commit addresses this and the previous comments, while still providing an orddict with improved performance: > > https://github.com/vinoski/otp/commit/a261aae36f617e39c5e53dc8a16fa186e4c5830c > > Thanks again to Anthony and Richard for their excellent feedback. > > --steve > > > > On Wed, Oct 2, 2013 at 5:36 PM, Steve Vinoski wrote: > I've added a third commit to this branch to address new concerns and suggestions from Anthony Ramine and Richard Carlsson. I appreciate your help, guys. > > Please refetch. > > --steve > > > On Wed, Oct 2, 2013 at 3:02 AM, Steve Vinoski wrote: > I've added a new commit to this branch that addresses the concerns Anthony raised. Please refetch. > > --steve > > > On Mon, Sep 30, 2013 at 5:32 AM, Steve Vinoski wrote: > Great feedback, Anthony -- thanks very much. Clearly there are more backward compatibility issues I need to address. > > --steve > > > On Mon, Sep 30, 2013 at 4:00 AM, Anthony Ramine wrote: > Hello Steve, > > Great patch, I added a few comments about some edge cases. > > Regards, > > Le 30 sept. 2013 ? 09:38, Steve Vinoski a ?crit : > > > This patch improves the performance of some orddict functions by reimplementing them using the lists module: > > > > https://github.com/erlang/otp/pull/91 > > > > The commit message at the link above is very detailed and includes performance measurements, so please read it to know more about the changes. > > > > --steve > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > -- > Anthony Ramine > > > > > -- Anthony Ramine From rich.neswold@REDACTED Fri Oct 4 13:26:02 2013 From: rich.neswold@REDACTED (Rich Neswold) Date: Fri, 4 Oct 2013 06:26:02 -0500 Subject: [erlang-patches] improved orddict performance In-Reply-To: <20131004101906.GB25851@erix.ericsson.se> References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> <20131004101906.GB25851@erix.ericsson.se> Message-ID: On Fri, Oct 4, 2013 at 5:19 AM, Raimo Niskanen < raimo+erlang-patches@REDACTED> wrote: > On Thu, Oct 03, 2013 at 10:27:42PM -0500, Rich Neswold wrote: > > Any code that uses the orddict API should not end up with an improper > list. > > Any code that passes an improper list to orddict should break. > > But in the case of orddict, it is actually documented to have a > data representation being an ordered list of key-value tuples. > > Therefore there is a possibility that someone has misused that knowledge > and uses an improper ordered list of key-value tuples, which may not be > violating the documentation... > If the documentation exposes the implementation (which is not a good idea, either) as an ordered list of key-value tuples, then users shouldn't complain when it doesn't handle improper lists. -- Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Fri Oct 4 14:59:06 2013 From: henrik@REDACTED (Henrik Nord) Date: Fri, 4 Oct 2013 14:59:06 +0200 Subject: [erlang-patches] Race condition in mnesia_locker after nodedown for sticky_locks In-Reply-To: References: Message-ID: <524EBB9A.4030402@erlang.org> Hi Thank you for your contribution! I have created a pull request from this, (This is becoming the prefered way of submitting patches to Erlang/otp) and the team will take a look at your patch. /Henrik On 2013-10-04 08:52, Jan Chochol wrote: > Hi OTP team, > > We found found bug (race condition) in mnesia code regarding > disconnecting nodes owning sticky lock. > Our (simplified) setup consists of two nodes, when first node acts as > active one and second acts as standby. > It means that all requests are normally going through first node and > second node is only used after fail of the first. Mnesia in our > scenario is used as HA data store. > For this setup it seems that sticky locks are ideal solution - all > operations are performed only on one node. > Everything worked well, until we found that some times transactions > started just after disconnecting first node hangs indefinitely. > This bogus behaviour was very rare, so it seemed that there is some > race condition how sticky locks are handled after disconnection of > node. > > We found that there is problem in synchronization of transaction > process (process initializing transaction) and mnesia_locker process. > It can happen that mnesia_locker process respond to lock request with > {switch, N, Req} message, but node N is already disconnected. > > Part of message trace to show the problem: > > List of interesting PIDs: > > mnesia_controller="<0.93.0>" > mnesia_tm="<0.89.0>" > mnesia_monitor="<0.85.0>" > mnesia_locker="<0.87.0>" > mnesia_recover="<0.88.0>" > transaction process="<0.206.0>" > > Message trace: > > % mnesia_monitor lost track of mnesia_monitor at node 1 > (<0.85.0>) << {'EXIT',<5184.92.0>,noconnection} > > % mnesia_monitor receives nodedown - this message is ignored > (<0.85.0>) << {nodedown,'gcfc-triple1_519129@REDACTED'} > > % mnesia_monitor call mnesia_recover:mnesia_down() > (<0.85.0>) <0.88.0> ! {'$gen_cast', > {mnesia_down,'gcfc-triple1_519129@REDACTED'}} > > % mnesia_recover receives mnesia_down, nothing to do there > (<0.88.0>) << {'$gen_cast',{mnesia_down,'gcfc-triple1_519129@REDACTED'}} > > % mnesia_monitor call mnesia_controller:mnesia_down > (<0.85.0>) <0.93.0> ! {'$gen_cast', > {mnesia_down,'gcfc-triple1_519129@REDACTED'}} > > % mnesia_controller receives mnesia_down > (<0.93.0>) << {'$gen_cast',{mnesia_down,'gcfc-triple1_519129@REDACTED'}} > > % mnesia_controller calls mnesia_recover:log_mnesia_down() > (<0.93.0>) <0.88.0> ! {'$gen_call', {<0.93.0>,#Ref<0.0.0.1860>}, > {log_mnesia_down,'gcfc-triple1_519129@REDACTED'}} > > % mnesia_recover receives log_mnesia_down, store it in decision table and reply > (<0.88.0>) << {'$gen_call',{<0.93.0>,#Ref<0.0.0.1860>}, > {log_mnesia_down,'gcfc-triple1_519129@REDACTED'}} > (<0.88.0>) <0.93.0> ! {#Ref<0.0.0.1860>,ok} > > % mnesia_controller receives response from mnesia_recover:log_mnesia_down() > (<0.93.0>) << {#Ref<0.0.0.1860>,ok} > > % mnesia_controller calls mnesia_monitor:mnesia_down(mnesia_controller, Node) > (<0.93.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_controller, > 'gcfc-triple1_519129@REDACTED'}} > > % mnesia_controller receives mnesia_down, mnesia_controller > (<0.85.0>) << {'$gen_cast', {mnesia_down,mnesia_controller, > 'gcfc-triple1_519129@REDACTED'}} > > % mnesia_controller forwards mnesia_down to mnesia_tm > (<0.85.0>) <0.89.0> ! {mnesia_down,'gcfc-triple1_519129@REDACTED'} > > % mnesia_tm receives mnesia_down > (<0.89.0>) << {mnesia_down,'gcfc-triple1_519129@REDACTED'} > > % mnesia_tm calls mnesia_monitor:mnesia_down(mnesia_tm, {Node, > ParticipantsTids}), > (<0.89.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_tm, > {'gcfc-triple1_519129@REDACTED',[]}}} > > % mnesia_monitor receives mnesia_down, mnesia_tm > % now it is going to call mnesia_locker:mnesia_down, which will send > release_remote_non_pending > (<0.85.0>) << {'$gen_cast', {mnesia_down, mnesia_tm, > {'gcfc-triple1_519129@REDACTED',[]}}} > > % Our processes receives information about node down and try to > recover from mnesiai > (<0.206.0>) << {activate,true} > > % Starts outer transaction > (<0.206.0>) <0.89.0> ! {{<0.206.0>,#Ref<0.0.0.1875>},start_outer} > (<0.89.0>) << {{<0.206.0>,#Ref<0.0.0.1875>},start_outer} > > % Reply for start_outer > (<0.89.0>) <0.206.0> ! {mnesia_tm,#Ref<0.0.0.1875>, > {new_tid,{tid,176,<0.206.0>},245835}} > (<0.206.0>) << {mnesia_tm,#Ref<0.0.0.1875>, > {new_tid,{tid,176,<0.206.0>},245835}} > > % Try to obtain lock for mnesia:select (just failed node holded sticky > lock for that table) > (<0.206.0>) {mnesia_locker,'gcfc-triple2_519129@REDACTED'} ! > {<0.206.0>, {read, {tid,176, <0.206.0>}, > {'tasks_tt_gcfc-triple1_519129@REDACTED', > '______WHOLETABLE_____'}}} > (<0.87.0>) << {<0.206.0>, {read, {tid,176,<0.206.0>}, > {'tasks_tt_gcfc-triple1_519129@REDACTED', > '______WHOLETABLE_____'}}} > > % mnesia_locker informs out process that it needs switch sticky lock > (<0.87.0>) <0.206.0> ! {mnesia_locker,'gcfc-triple2_519129@REDACTED', > {switch,'gcfc-triple1_519129@REDACTED', {<0.206.0>, {read, > {tid,176,<0.206.0>}, > {'tasks_tt_gcfc-triple1_519129@REDACTED', > '______WHOLETABLE_____'}}}}} > (<0.206.0>) << {mnesia_locker,'gcfc-triple2_519129@REDACTED', > {switch,'gcfc-triple1_519129@REDACTED', {<0.206.0>, {read, > {tid,176,<0.206.0>}, > {'tasks_tt_gcfc-triple1_519129@REDACTED', > '______WHOLETABLE_____'}}}}} > > % Our proces just want to send {<0.206.0>, {read, {tid,176,<0.206.0>}, > {'tasks_tt_gcfc-triple1_519129@REDACTED', > '______WHOLETABLE_____'}}} to other node > % Other node is not connected, so Erlang tryies to connect to it > (<0.21.0> is net_kernel process) > (<0.206.0>) <0.21.0> ! {'$gen_call', {<0.206.0>,#Ref<0.0.0.1884>}, > {connect,normal,'gcfc-triple1_519129@REDACTED'}} > > % Connection to remote node was unsucsefull, and our process is hanged > in this function: > % > % l_req_rec(Node, Store) -> > % ?ets_insert(Store, {nodes, Node}), > % receive > % {?MODULE, Node, Reply} -> > % Reply; > % {mnesia_down, Node} -> > % {not_granted, {node_not_running, Node}} > % end. > % > % It will never get out, as sent message is lost > (<0.206.0>) << {#Ref<0.0.0.1884>,false} > > % mnesia_monitor call mnesia_locker:mnesia_down, which is sending > release_remote_non_pending > (<0.85.0>) <0.87.0> ! {release_remote_non_pending, > 'gcfc-triple1_519129@REDACTED',[]} > > % mnesia_locker receives release_remote_non_pending > % it removes sticky locks of failed nodes and releases all transactions > % but it is too late - process <0.206.0> is already stucked for > waiting for response from not connected node > (<0.87.0>) << {release_remote_non_pending,'gcfc-triple1_519129@REDACTED',[]} > > % mnesia_locker call mnesia_monitor:mnesia_down(mnesia_locker, Node) > (<0.87.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_locker, > 'gcfc-triple1_519129@REDACTED'}} > > % mnesia_monitor receives mnesia_down, mnesia_locker > (<0.85.0>) << {'$gen_cast', > {mnesia_down,mnesia_locker,'gcfc-triple1_519129@REDACTED'}} > > % mnesia_monitor calls mnesia_lib:report_system_event, which will send > notify to mnesia_event > (<0.85.0>) <0.83.0> ! {notify, {mnesia_system_event, > {mnesia_down,'gcfc-triple1_519129@REDACTED'}}} > > > So problem is that transaction process sends messages to not-connected > node and awaits response which will never come. > One of the easiest solution is to monitor remote process, which > prevent this from happening. > > Suggested patch is available at: > > git fetch git://github.com/janchochol/otp.git sticky_lock_race > > https://github.com/janchochol/otp/compare/erlang:maint...sticky_lock_race > https://github.com/janchochol/otp/compare/erlang:maint...sticky_lock_race.patch > > > You can try to reproduce the problem with following module: > > --- BEGIN OF slock.erl --- > %% stick_lock problem reproducer > %% > %% To reproduce problem execute these commands in parallel: > %% > %% erl -sname n2@REDACTED -cookie slock -s slock n2 > %% erl -sname n1@REDACTED -cookie slock -s slock n1 > %% > %% Problem is timing related, so it has relatively low probability of > reproducing. > %% To increase probability use this patch: > %% > %% --- a/lib/mnesia/src/mnesia_locker.erl > %% +++ b/lib/mnesia/src/mnesia_locker.erl > %% @@ -663,6 +663,7 @@ mnesia_down(N, Pending) -> > %% %% race with mnesia_tm's coordinator processes > %% %% that may restart and acquire new locks. > %% %% mnesia_monitor ensures the sync. > %% + timer:sleep(1000), > %% Pid ! {release_remote_non_pending, N, Pending} > %% end. > %% > %% > %% When problem appears n1 node will hang indefinitely. > %% When problem is not present n1 will finish shortly after n2. > > > -module(slock). > > -export([n1/0, n2/0]). > > wait_for_n2() -> > case rpc:call(n2@REDACTED, erlang, whereis, [n2]) of > Pid when is_pid(Pid) -> > Pid; > _ -> > timer:sleep(100), > wait_for_n2() > end. > > wait_fun(Fun, PollIntervalMs) -> > case Fun() of > false -> > timer:sleep(PollIntervalMs), > wait_fun(Fun, PollIntervalMs); > true -> > ok > end. > > > n1() -> > register(n1, self()), > io:format("n1: statred~n", []), > io:format("n1: waiting for n2~n", []), > N2 = wait_for_n2(), > io:format("n1: n2 found~n", []), > io:format("n1: init mnesia start~n", []), > ok = application:start(mnesia, permanent), > ok = rpc:call(n2@REDACTED, application, start, [mnesia, permanent]), > {ok, [_ | _]} = mnesia:change_config(extra_db_nodes, [n2@REDACTED]), > {atomic, ok} = mnesia:create_table(t1, [{ram_copies, > [n1@REDACTED, n2@REDACTED]}]), > ok = rpc:call(n2@REDACTED, mnesia, wait_for_tables, [[t1], infinity]), > io:format("n1: init mnesia end~n", []), > N2 ! {ping, self()}, > receive step -> ok end, > wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang end, 100), > io:format("n1: select start~n", []), > Ret = mnesia:transaction(fun() -> > wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang end, 10), > mnesia:select(t1, [{{t1, '_', '_'}, [], ['$_']}]) > end), > io:format("n1: select end: ~p~n", [Ret]), > init:stop(). > > n2() -> > register(n2, self()), > io:format("n2: statred~n", []), > io:format("n2: waiting for n1 ping~n", []), > N2 = receive > {ping, IN2} -> > IN2 > end, > io:format("n2: n1 pinged~n", []), > io:format("n2: write start~n", []), > mnesia:transaction(fun() -> mnesia:write(t1, {t1, a, b}, sticky_write) end), > io:format("n2: write end~n", []), > N2 ! step, > io:format("n2: finish~n", []), > erlang:halt(). > --- END OF slock.erl --- > > I do not see any other easy solution for this problem. > > Best Regards, > Jan Chochol > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From aschultz@REDACTED Fri Oct 4 16:57:22 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 4 Oct 2013 16:57:22 +0200 (CEST) Subject: [erlang-patches] ssl: don't sent client certificate with anon ciphers In-Reply-To: <11749491.226.1380454388609.JavaMail.zimbra@tpip.net> Message-ID: <797860080.114553.1380898642198.JavaMail.zimbra@tpip.net> Hi, ssl: don't sent client certificate with anon ciphers whatever the SSL options say, when we negotiated a anonymous, PSK or SRP cipher suites, client certificates and certificate requests are not permitted. git fetch git://github.com/RoadRunnr/otp.git ssl_anon_certs https://github.com/RoadRunnr/otp/compare/master...ssl_anon_certs https://github.com/RoadRunnr/otp/compare/master...ssl_anon_certs.patch Change is against master, but should apply to maint as well. Andreas From aschultz@REDACTED Fri Oct 4 18:57:00 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 4 Oct 2013 18:57:00 +0200 (CEST) Subject: [erlang-patches] ssl: don't sent client certificate with anon ciphers In-Reply-To: <797860080.114553.1380898642198.JavaMail.zimbra@tpip.net> References: <797860080.114553.1380898642198.JavaMail.zimbra@tpip.net> Message-ID: <317052909.119443.1380905820877.JavaMail.zimbra@tpip.net> Hi, I have pushed a second changeset to that branch since it depends on the first. However, both could also be takes separately. The new one is: ssl: add ECDHE_PSK and PSK_NULL cipher suites As the commit messages already says, it adds support for some additional PSK ciphers. Review URL's are still the same. singled out: ssl: don't sent client certificate with anon ciphers: https://github.com/RoadRunnr/otp/commit/79ddf94dd2a393b55dceaf4bccafac5fb3d898b0 ssl: add ECDHE_PSK and PSK_NULL cipher suites: https://github.com/RoadRunnr/otp/commit/37069f9bff48df88900da73b43b170a84f991b19 Andreas ----- Original Message ----- > Hi, > > ssl: don't sent client certificate with anon ciphers > > whatever the SSL options say, when we negotiated a anonymous, > PSK or SRP cipher suites, client certificates and certificate > requests are not permitted. > > git fetch git://github.com/RoadRunnr/otp.git ssl_anon_certs > > https://github.com/RoadRunnr/otp/compare/master...ssl_anon_certs > https://github.com/RoadRunnr/otp/compare/master...ssl_anon_certs.patch > > > Change is against master, but should apply to maint as well. > > Andreas > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From vinoski@REDACTED Fri Oct 4 19:15:19 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 4 Oct 2013 13:15:19 -0400 Subject: [erlang-patches] improved orddict performance In-Reply-To: <627499B9-5833-4309-911A-7954A374924E@gmail.com> References: <472B4FA4-81D6-4123-917B-28009B7BD1BC@gmail.com> <627499B9-5833-4309-911A-7954A374924E@gmail.com> Message-ID: On Fri, Oct 4, 2013 at 6:23 AM, Anthony Ramine wrote: > Hello Steve, > > Btw did you measure a call to is_key/2 with a very large orddict not > containing the given key? Wouldn't the short-circuiting due to ordering > allow for better performances than using keyfind/3? > Yes, this is definitely a scenario for which the R16B02 orddict can be much faster. Where the difference point lies depends on the terms involved. My posted tests don't include this scenario but instead measure the time it takes to find a key halfway through the list. Perhaps instead of trying to reuse the lists module as it does now, which has obviously proven to be tricky and can't take advantage of list order, this patch should instead introduce either an ordered list find function into the lists module as a BIF, or go all the way and introduce a BIF ordered lists module and reimplement orddict on top of that. I'd be willing to give either of the latter a try if the OTP team feels they would be better approaches. > Also please note there is nearly no way to totally address > backwards-compatibility with lists functions, due to the short-circuiting: > > orddict:is_key(b, [{a,1},{c,3},not_a_pair]). > To handle this my latest (amended) commit does a check for pairs only up until it sees a key equal or greater than the key being requested. --steve > Le 4 oct. 2013 ? 02:58, Steve Vinoski a ?crit : > > > OK, Anthony brought up yet another issue with my previous modified > orddict, which is that if someone passes an improper list instead of an > orddict, the new version acts differently than the old. Since the goal is > backwards compatibility with improved performance, I've added a fourth > commit that deals with these issues. > > > > Notably, the original orddict, if passed an improper list or a list with > elements that are not 2-tuples, will still work properly if the key being > dealt with occurs before the problematic part of the list. For example, > this works with the R16B02 orddict: > > > > {ok,2} = orddict:find(1,[{1,2},{2,3,4}]). > > > > I believe the latest commit addresses this and the previous comments, > while still providing an orddict with improved performance: > > > > > https://github.com/vinoski/otp/commit/a261aae36f617e39c5e53dc8a16fa186e4c5830c > > > > Thanks again to Anthony and Richard for their excellent feedback. > > > > --steve > > > > > > > > On Wed, Oct 2, 2013 at 5:36 PM, Steve Vinoski wrote: > > I've added a third commit to this branch to address new concerns and > suggestions from Anthony Ramine and Richard Carlsson. I appreciate your > help, guys. > > > > Please refetch. > > > > --steve > > > > > > On Wed, Oct 2, 2013 at 3:02 AM, Steve Vinoski wrote: > > I've added a new commit to this branch that addresses the concerns > Anthony raised. Please refetch. > > > > --steve > > > > > > On Mon, Sep 30, 2013 at 5:32 AM, Steve Vinoski wrote: > > Great feedback, Anthony -- thanks very much. Clearly there are more > backward compatibility issues I need to address. > > > > --steve > > > > > > On Mon, Sep 30, 2013 at 4:00 AM, Anthony Ramine > wrote: > > Hello Steve, > > > > Great patch, I added a few comments about some edge cases. > > > > Regards, > > > > Le 30 sept. 2013 ? 09:38, Steve Vinoski a ?crit : > > > > > This patch improves the performance of some orddict functions by > reimplementing them using the lists module: > > > > > > https://github.com/erlang/otp/pull/91 > > > > > > The commit message at the link above is very detailed and includes > performance measurements, so please read it to know more about the changes. > > > > > > --steve > > > _______________________________________________ > > > erlang-patches mailing list > > > erlang-patches@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > > Anthony Ramine > > > > > > > > > > > > -- > Anthony Ramine > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 8 11:24:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 8 Oct 2013 11:24:51 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130610145051.GA9514@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> <410DB75B-3587-41C0-89C4-E5B49E9C5F59@gmail.com> <20130429133226.GA14490@erix.ericsson.se> <6F811862-36D9-4E61-BEB0-C33AD9B01CFA@gmail.com> <20130610145051.GA9514@erix.ericsson.se> Message-ID: <1AF66D8E-BA95-43D0-9F2C-21346402D3EE@gmail.com> Hello Raimo, Unicode source code will require infinite look ahead during normalization, still against this patch? Regards, Le 10 juin 2013 ? 16:50, Raimo Niskanen a ?crit : > But I still think that forever forcing Erlang to need an infinite look > ahead custom syntax aware scanner still is a strong argument against the > suggested improvement. -- Anthony Ramine From mc@REDACTED Tue Oct 8 11:38:30 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Tue, 8 Oct 2013 05:38:30 -0400 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <1AF66D8E-BA95-43D0-9F2C-21346402D3EE@gmail.com> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> <410DB75B-3587-41C0-89C4-E5B49E9C5F59@gmail.com> <20130429133226.GA14490@erix.ericsson.se> <6F811862-36D9-4E61-BEB0-C33AD9B01CFA@gmail.com> <20130610145051.GA9514@erix.ericsson.se> <1AF66D8E-BA95-43D0-9F2C-21346402D3EE@gmail.com> Message-ID: This patch absolutely needs to go in, it fixes a problem and will ultimately be necessary for Unicode. +1 I'd hate to see this silly issue subsist past r16b03 On Tue, Oct 8, 2013 at 5:24 AM, Anthony Ramine wrote: > Hello Raimo, > > Unicode source code will require infinite look ahead during normalization, > still against this patch? > > Regards, > > Le 10 juin 2013 ? 16:50, Raimo Niskanen a ?crit : > > > But I still think that forever forcing Erlang to need an infinite look > > ahead custom syntax aware scanner still is a strong argument against the > > suggested improvement. > > -- > Anthony Ramine > > _______________________________________________ > 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 rich.neswold@REDACTED Tue Oct 8 14:24:20 2013 From: rich.neswold@REDACTED (Rich Neswold) Date: Tue, 8 Oct 2013 07:24:20 -0500 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130610145051.GA9514@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> <410DB75B-3587-41C0-89C4-E5B49E9C5F59@gmail.com> <20130429133226.GA14490@erix.ericsson.se> <6F811862-36D9-4E61-BEB0-C33AD9B01CFA@gmail.com> <20130610145051.GA9514@erix.ericsson.se> Message-ID: On Mon, Jun 10, 2013 at 9:50 AM, Raimo Niskanen < raimo+erlang-patches@REDACTED> wrote: > But I still think that forever forcing Erlang to need an infinite look ahead > custom syntax aware scanner still is a strong argument against the suggested > improvement. > The language designers used certain symbols multiple times in the grammar which could create ambiguous scanning results. The compiler needs to properly handle them, even if it means sacrificing the scanner's simplicity. The C++ camp recently fixed a similar wart with nested templates. You used to place a whitespace between the closing '>'s so the compiler didn't confuse the closing of both template specifications with a shift operator (>>). It now Does The Right Thing even though it was a special case. -- Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Tue Oct 8 18:24:06 2013 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 8 Oct 2013 18:24:06 +0200 (CEST) Subject: [erlang-patches] improved orddict performance In-Reply-To: References: <20131004101906.GB25851@erix.ericsson.se> Message-ID: <2046491272.581885.1381249446881.JavaMail.zimbra@erlang-solutions.com> Normally I agree with you but in this case we decided that we should have an orddict which completely specified the internal representation. The whole point of orddict is that the internal structure is documented and can be relied on. So you *can* use it as a proplist if you want, or as a list of key-value options to a function. Re proplists I feel that the orddict API is cleaner. I personally wouldn't worry about compatibility if someone calls these functions with an improper list. But then again I have rarely worried about backwards compatibility. :-) Robert ----- Original Message ----- > From: "Rich Neswold" > To: "erlang patches" > Sent: Friday, 4 October, 2013 1:26:02 PM > Subject: Re: [erlang-patches] improved orddict performance > On Fri, Oct 4, 2013 at 5:19 AM, Raimo Niskanen < > raimo+erlang-patches@REDACTED > wrote: > > On Thu, Oct 03, 2013 at 10:27:42PM -0500, Rich Neswold wrote: > > > > Any code that uses the orddict API should not end up with an improper > > > list. > > > > Any code that passes an improper list to orddict should break. > > > But in the case of orddict, it is actually documented to have a data > > representation being an ordered list of key-value tuples. > > > Therefore there is a possibility that someone has misused that knowledge > > and > > uses an improper ordered list of key-value tuples, which may not be > > violating the documentation... > > If the documentation exposes the implementation (which is not a good idea, > either) as an ordered list of key-value tuples, then users shouldn't > complain when it doesn't handle improper lists. > -- > Rich > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 8 18:57:19 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 8 Oct 2013 18:57:19 +0200 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <9587CB66-B48E-42EC-AEB2-7EA8B383714D@gmail.com> References: <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> <185EEAD8-2C06-4BCB-8863-B6F8CC79460D@gmail.com> <5195E2BE.4060104@erlang.org> <406DB238-CBC1-4CCD-9AFF-1AC9DBFDA62B@gmail.com> <637F7FCA-3360-4F81-AFB1-C3D41A6E4139@gmail.com> <5199D1BA.6010206@erlang.org> <5B7E1490-0301-4BF7-B6E4-FBD792B3ECD1@gmail.com> <8BBBCFB9-8917-456D-B21B-558C163D09C8@gmail.com> <5236CAA6.7050609@erlang.org> <7ED437FD-45EA-4079-A381-AFC9F566F89E@gmail.com> <9587CB66-B48E-42EC-AEB2-7EA8B383714D@gmail.com> Message-ID: <5783C96C-164E-470D-AD84-45EDF2DC5B4E@gmail.com> Hello Kostis, Any idea why this still segfaults if HiPE is enabled? Regards, Le 19 sept. 2013 ? 15:18, Anthony Ramine a ?crit : > Received the core dump. > > In this GDB session (https://gist.github.com/nox/6623009) you can notice at the end that HiPE tries to patch a LOT of fun entries for the same erl_prettypr:lay/2 function. This is because I forgot to strip the eta-abstracted id annotations when compiling local fun references to Core Erlang in v3_core. I amended the first commit of that branch to fix that. > > Please refetch. > > Regards, > > Le 16 sept. 2013 ? 11:37, Anthony Ramine a ?crit : > >> I can't reproduce the issue, you were supposed to give me a core dump or something by "tomorrow", that was May 27th :) >> >> Le 16 sept. 2013 ? 11:08, Fredrik a ?crit : >> >>> Hello Anthony, >>> Afaik the same issue is remaining as we discussed in private conversation i.e >>> with these flags the build aborts: >>> CONFIG_FLAGS = --enable-hipe --enable-smp-support --enable-native-libs >> > -- Anthony Ramine From lukas@REDACTED Wed Oct 9 17:09:52 2013 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 9 Oct 2013 17:09:52 +0200 Subject: [erlang-patches] add {active,N} support for sockets In-Reply-To: <5227488B.8050004@erlang.org> References: <5227488B.8050004@erlang.org> Message-ID: <525571C0.1020402@erlang.org> Hello, This has now been merged upsteam to be released in the next major release. Lukas On 04/09/13 16:49, Fredrik wrote: > On 09/04/2013 04:48 PM, Steve Vinoski wrote: >> This pull request adds support for an {active,N} option for TCP, UDP, >> and SCTP sockets. It's similar to {active,true} except the socket >> enters passive mode once N messages have been sent to the controlling >> process, similar to what the {active,once} mode does after 1 message. >> The commit message contains more details: >> >> https://github.com/vinoski/otp/commit/abd3703840ff9395b40e38aa7c7648171a9adc82 >> >> The pull request is here: >> >> https://github.com/erlang/otp/pull/66 >> >> --steve >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello Steve, > The pull-request machinery will pick this patch up tonight and run > some initial testing on it, if that goes well I'll assign it to the > responsible team tomorrow. > 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 lukas@REDACTED Wed Oct 9 17:10:28 2013 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 9 Oct 2013 17:10:28 +0200 Subject: [erlang-patches] add system_info(ets_limit) In-Reply-To: References: Message-ID: <525571E4.20509@erlang.org> Hello, This has now been merged to be included in the next service release. Lukas On 04/09/13 21:20, Steve Vinoski wrote: > Add system_info(ets_limit) to provide a way to get the system's > maximum number of ETS tables. > > https://github.com/erlang/otp/pull/67 > > --steve > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Thu Oct 10 08:37:54 2013 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 10 Oct 2013 02:37:54 -0400 Subject: [erlang-patches] Various improvements to CRL handling Message-ID: <20131010063754.GW9818@hijacked.us> https://github.com/erlang/otp/pull/97 Andrew From dangud@REDACTED Thu Oct 10 11:17:07 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Thu, 10 Oct 2013 11:17:07 +0200 Subject: [erlang-patches] Race condition in mnesia_locker after nodedown for sticky_locks In-Reply-To: <524EBB9A.4030402@erlang.org> References: <524EBB9A.4030402@erlang.org> Message-ID: I changed the fix to synchronize the lock clearing from mnesia_tm. See https://github.com/dgud/otp/compare/dgud;mnesia;sticky-race;OTP-11375 Does that work for you? On Fri, Oct 4, 2013 at 2:59 PM, Henrik Nord wrote: > Hi > > Thank you for your contribution! > I have created a pull request from this, (This is becoming the prefered > way of submitting patches to Erlang/otp) and the team will take a look at > your patch. > > /Henrik > > > On 2013-10-04 08:52, Jan Chochol wrote: > >> Hi OTP team, >> >> We found found bug (race condition) in mnesia code regarding >> disconnecting nodes owning sticky lock. >> Our (simplified) setup consists of two nodes, when first node acts as >> active one and second acts as standby. >> It means that all requests are normally going through first node and >> second node is only used after fail of the first. Mnesia in our >> scenario is used as HA data store. >> For this setup it seems that sticky locks are ideal solution - all >> operations are performed only on one node. >> Everything worked well, until we found that some times transactions >> started just after disconnecting first node hangs indefinitely. >> This bogus behaviour was very rare, so it seemed that there is some >> race condition how sticky locks are handled after disconnection of >> node. >> >> We found that there is problem in synchronization of transaction >> process (process initializing transaction) and mnesia_locker process. >> It can happen that mnesia_locker process respond to lock request with >> {switch, N, Req} message, but node N is already disconnected. >> >> Part of message trace to show the problem: >> >> List of interesting PIDs: >> >> mnesia_controller="<0.93.0>" >> mnesia_tm="<0.89.0>" >> mnesia_monitor="<0.85.0>" >> mnesia_locker="<0.87.0>" >> mnesia_recover="<0.88.0>" >> transaction process="<0.206.0>" >> >> Message trace: >> >> % mnesia_monitor lost track of mnesia_monitor at node 1 >> (<0.85.0>) << {'EXIT',<5184.92.0>,**noconnection} >> >> % mnesia_monitor receives nodedown - this message is ignored >> (<0.85.0>) << {nodedown,'gcfc-triple1_**519129@REDACTED'} >> >> % mnesia_monitor call mnesia_recover:mnesia_down() >> (<0.85.0>) <0.88.0> ! {'$gen_cast', >> {mnesia_down,'gcfc-triple1_**519129@REDACTED'}} >> >> % mnesia_recover receives mnesia_down, nothing to do there >> (<0.88.0>) << {'$gen_cast',{mnesia_down,'**gcfc-triple1_519129@REDACTED' >> **}} >> >> % mnesia_monitor call mnesia_controller:mnesia_down >> (<0.85.0>) <0.93.0> ! {'$gen_cast', >> {mnesia_down,'gcfc-triple1_**519129@REDACTED'}} >> >> % mnesia_controller receives mnesia_down >> (<0.93.0>) << {'$gen_cast',{mnesia_down,'**gcfc-triple1_519129@REDACTED' >> **}} >> >> % mnesia_controller calls mnesia_recover:log_mnesia_**down() >> (<0.93.0>) <0.88.0> ! {'$gen_call', {<0.93.0>,#Ref<0.0.0.1860>}, >> {log_mnesia_down,'gcfc-**triple1_519129@REDACTED'}} >> >> % mnesia_recover receives log_mnesia_down, store it in decision table and >> reply >> (<0.88.0>) << {'$gen_call',{<0.93.0>,#Ref<0.**0.0.1860>}, >> {log_mnesia_down,'gcfc-**triple1_519129@REDACTED'}} >> (<0.88.0>) <0.93.0> ! {#Ref<0.0.0.1860>,ok} >> >> % mnesia_controller receives response from mnesia_recover:log_mnesia_** >> down() >> (<0.93.0>) << {#Ref<0.0.0.1860>,ok} >> >> % mnesia_controller calls mnesia_monitor:mnesia_down(**mnesia_controller, >> Node) >> (<0.93.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_**controller, >> 'gcfc-triple1_519129@REDACTED**'}} >> >> % mnesia_controller receives mnesia_down, mnesia_controller >> (<0.85.0>) << {'$gen_cast', {mnesia_down,mnesia_**controller, >> 'gcfc-triple1_519129@REDACTED**'}} >> >> % mnesia_controller forwards mnesia_down to mnesia_tm >> (<0.85.0>) <0.89.0> ! {mnesia_down,'gcfc-triple1_**519129@REDACTED'} >> >> % mnesia_tm receives mnesia_down >> (<0.89.0>) << {mnesia_down,'gcfc-triple1_**519129@REDACTED'} >> >> % mnesia_tm calls mnesia_monitor:mnesia_down(**mnesia_tm, {Node, >> ParticipantsTids}), >> (<0.89.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_tm, >> {'gcfc-triple1_519129@**localhost',[]}}} >> >> % mnesia_monitor receives mnesia_down, mnesia_tm >> % now it is going to call mnesia_locker:mnesia_down, which will send >> release_remote_non_pending >> (<0.85.0>) << {'$gen_cast', {mnesia_down, mnesia_tm, >> {'gcfc-triple1_519129@**localhost',[]}}} >> >> % Our processes receives information about node down and try to >> recover from mnesiai >> (<0.206.0>) << {activate,true} >> >> % Starts outer transaction >> (<0.206.0>) <0.89.0> ! {{<0.206.0>,#Ref<0.0.0.1875>},**start_outer} >> (<0.89.0>) << {{<0.206.0>,#Ref<0.0.0.1875>},**start_outer} >> >> % Reply for start_outer >> (<0.89.0>) <0.206.0> ! {mnesia_tm,#Ref<0.0.0.1875>, >> {new_tid,{tid,176,<0.206.0>},**245835}} >> (<0.206.0>) << {mnesia_tm,#Ref<0.0.0.1875>, >> {new_tid,{tid,176,<0.206.0>},**245835}} >> >> % Try to obtain lock for mnesia:select (just failed node holded sticky >> lock for that table) >> (<0.206.0>) {mnesia_locker,'gcfc-triple2_**519129@REDACTED'} ! >> {<0.206.0>, {read, {tid,176, <0.206.0>}, >> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >> '______WHOLETABLE_____'}}} >> (<0.87.0>) << {<0.206.0>, {read, {tid,176,<0.206.0>}, >> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >> '______WHOLETABLE_____'}}} >> >> % mnesia_locker informs out process that it needs switch sticky lock >> (<0.87.0>) <0.206.0> ! {mnesia_locker,'gcfc-triple2_**519129@REDACTED', >> {switch,'gcfc-triple1_519129@**localhost', {<0.206.0>, {read, >> {tid,176,<0.206.0>}, >> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >> '______WHOLETABLE_____'}}}}} >> (<0.206.0>) << {mnesia_locker,'gcfc-triple2_**519129@REDACTED', >> {switch,'gcfc-triple1_519129@**localhost', {<0.206.0>, {read, >> {tid,176,<0.206.0>}, >> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >> '______WHOLETABLE_____'}}}}} >> >> % Our proces just want to send {<0.206.0>, {read, {tid,176,<0.206.0>}, >> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >> '______WHOLETABLE_____'}}} to other node >> % Other node is not connected, so Erlang tryies to connect to it >> (<0.21.0> is net_kernel process) >> (<0.206.0>) <0.21.0> ! {'$gen_call', {<0.206.0>,#Ref<0.0.0.1884>}, >> {connect,normal,'gcfc-triple1_**519129@REDACTED'}} >> >> % Connection to remote node was unsucsefull, and our process is hanged >> in this function: >> % >> % l_req_rec(Node, Store) -> >> % ?ets_insert(Store, {nodes, Node}), >> % receive >> % {?MODULE, Node, Reply} -> >> % Reply; >> % {mnesia_down, Node} -> >> % {not_granted, {node_not_running, Node}} >> % end. >> % >> % It will never get out, as sent message is lost >> (<0.206.0>) << {#Ref<0.0.0.1884>,false} >> >> % mnesia_monitor call mnesia_locker:mnesia_down, which is sending >> release_remote_non_pending >> (<0.85.0>) <0.87.0> ! {release_remote_non_pending, >> 'gcfc-triple1_519129@REDACTED**',[]} >> >> % mnesia_locker receives release_remote_non_pending >> % it removes sticky locks of failed nodes and releases all transactions >> % but it is too late - process <0.206.0> is already stucked for >> waiting for response from not connected node >> (<0.87.0>) << {release_remote_non_pending,'** >> gcfc-triple1_519129@REDACTED'**,[]} >> >> % mnesia_locker call mnesia_monitor:mnesia_down(**mnesia_locker, Node) >> (<0.87.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_locker, >> 'gcfc-triple1_519129@REDACTED**'}} >> >> % mnesia_monitor receives mnesia_down, mnesia_locker >> (<0.85.0>) << {'$gen_cast', >> {mnesia_down,mnesia_locker,'**gcfc-triple1_519129@REDACTED'**}} >> >> % mnesia_monitor calls mnesia_lib:report_system_**event, which will send >> notify to mnesia_event >> (<0.85.0>) <0.83.0> ! {notify, {mnesia_system_event, >> {mnesia_down,'gcfc-triple1_**519129@REDACTED'}}} >> >> >> So problem is that transaction process sends messages to not-connected >> node and awaits response which will never come. >> One of the easiest solution is to monitor remote process, which >> prevent this from happening. >> >> Suggested patch is available at: >> >> git fetch git://github.com/janchochol/**otp.gitsticky_lock_race >> >> https://github.com/janchochol/**otp/compare/erlang:maint...** >> sticky_lock_race >> https://github.com/janchochol/**otp/compare/erlang:maint...** >> sticky_lock_race.patch >> >> >> You can try to reproduce the problem with following module: >> >> --- BEGIN OF slock.erl --- >> %% stick_lock problem reproducer >> %% >> %% To reproduce problem execute these commands in parallel: >> %% >> %% erl -sname n2@REDACTED -cookie slock -s slock n2 >> %% erl -sname n1@REDACTED -cookie slock -s slock n1 >> %% >> %% Problem is timing related, so it has relatively low probability of >> reproducing. >> %% To increase probability use this patch: >> %% >> %% --- a/lib/mnesia/src/mnesia_**locker.erl >> %% +++ b/lib/mnesia/src/mnesia_**locker.erl >> %% @@ -663,6 +663,7 @@ mnesia_down(N, Pending) -> >> %% %% race with mnesia_tm's coordinator processes >> %% %% that may restart and acquire new locks. >> %% %% mnesia_monitor ensures the sync. >> %% + timer:sleep(1000), >> %% Pid ! {release_remote_non_pending, N, Pending} >> %% end. >> %% >> %% >> %% When problem appears n1 node will hang indefinitely. >> %% When problem is not present n1 will finish shortly after n2. >> >> >> -module(slock). >> >> -export([n1/0, n2/0]). >> >> wait_for_n2() -> >> case rpc:call(n2@REDACTED, erlang, whereis, [n2]) of >> Pid when is_pid(Pid) -> >> Pid; >> _ -> >> timer:sleep(100), >> wait_for_n2() >> end. >> >> wait_fun(Fun, PollIntervalMs) -> >> case Fun() of >> false -> >> timer:sleep(PollIntervalMs), >> wait_fun(Fun, PollIntervalMs); >> true -> >> ok >> end. >> >> >> n1() -> >> register(n1, self()), >> io:format("n1: statred~n", []), >> io:format("n1: waiting for n2~n", []), >> N2 = wait_for_n2(), >> io:format("n1: n2 found~n", []), >> io:format("n1: init mnesia start~n", []), >> ok = application:start(mnesia, permanent), >> ok = rpc:call(n2@REDACTED, application, start, [mnesia, >> permanent]), >> {ok, [_ | _]} = mnesia:change_config(extra_db_**nodes, [n2@REDACTED >> ]), >> {atomic, ok} = mnesia:create_table(t1, [{ram_copies, >> [n1@REDACTED, n2@REDACTED]}]), >> ok = rpc:call(n2@REDACTED, mnesia, wait_for_tables, [[t1], >> infinity]), >> io:format("n1: init mnesia end~n", []), >> N2 ! {ping, self()}, >> receive step -> ok end, >> wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang end, 100), >> io:format("n1: select start~n", []), >> Ret = mnesia:transaction(fun() -> >> wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang >> end, 10), >> mnesia:select(t1, [{{t1, '_', '_'}, [], ['$_']}]) >> end), >> io:format("n1: select end: ~p~n", [Ret]), >> init:stop(). >> >> n2() -> >> register(n2, self()), >> io:format("n2: statred~n", []), >> io:format("n2: waiting for n1 ping~n", []), >> N2 = receive >> {ping, IN2} -> >> IN2 >> end, >> io:format("n2: n1 pinged~n", []), >> io:format("n2: write start~n", []), >> mnesia:transaction(fun() -> mnesia:write(t1, {t1, a, b}, >> sticky_write) end), >> io:format("n2: write end~n", []), >> N2 ! step, >> io:format("n2: finish~n", []), >> erlang:halt(). >> --- END OF slock.erl --- >> >> I do not see any other easy solution for this problem. >> >> Best Regards, >> Jan Chochol >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > > -- > /Henrik Nord Erlang/OTP > > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.chochol@REDACTED Thu Oct 10 13:10:38 2013 From: jan.chochol@REDACTED (Jan Chochol) Date: Thu, 10 Oct 2013 13:10:38 +0200 Subject: [erlang-patches] Race condition in mnesia_locker after nodedown for sticky_locks In-Reply-To: References: <524EBB9A.4030402@erlang.org> Message-ID: Hi Dan, I tested your patch, and it seems working. Thanks, Jan On Thu, Oct 10, 2013 at 11:17 AM, Dan Gudmundsson wrote: > I changed the fix to synchronize the lock clearing from mnesia_tm. > > See https://github.com/dgud/otp/compare/dgud;mnesia;sticky-race;OTP-11375 > > Does that work for you? > > > On Fri, Oct 4, 2013 at 2:59 PM, Henrik Nord wrote: > >> Hi >> >> Thank you for your contribution! >> I have created a pull request from this, (This is becoming the prefered >> way of submitting patches to Erlang/otp) and the team will take a look at >> your patch. >> >> /Henrik >> >> >> On 2013-10-04 08:52, Jan Chochol wrote: >> >>> Hi OTP team, >>> >>> We found found bug (race condition) in mnesia code regarding >>> disconnecting nodes owning sticky lock. >>> Our (simplified) setup consists of two nodes, when first node acts as >>> active one and second acts as standby. >>> It means that all requests are normally going through first node and >>> second node is only used after fail of the first. Mnesia in our >>> scenario is used as HA data store. >>> For this setup it seems that sticky locks are ideal solution - all >>> operations are performed only on one node. >>> Everything worked well, until we found that some times transactions >>> started just after disconnecting first node hangs indefinitely. >>> This bogus behaviour was very rare, so it seemed that there is some >>> race condition how sticky locks are handled after disconnection of >>> node. >>> >>> We found that there is problem in synchronization of transaction >>> process (process initializing transaction) and mnesia_locker process. >>> It can happen that mnesia_locker process respond to lock request with >>> {switch, N, Req} message, but node N is already disconnected. >>> >>> Part of message trace to show the problem: >>> >>> List of interesting PIDs: >>> >>> mnesia_controller="<0.93.0>" >>> mnesia_tm="<0.89.0>" >>> mnesia_monitor="<0.85.0>" >>> mnesia_locker="<0.87.0>" >>> mnesia_recover="<0.88.0>" >>> transaction process="<0.206.0>" >>> >>> Message trace: >>> >>> % mnesia_monitor lost track of mnesia_monitor at node 1 >>> (<0.85.0>) << {'EXIT',<5184.92.0>,**noconnection} >>> >>> % mnesia_monitor receives nodedown - this message is ignored >>> (<0.85.0>) << {nodedown,'gcfc-triple1_**519129@REDACTED'} >>> >>> % mnesia_monitor call mnesia_recover:mnesia_down() >>> (<0.85.0>) <0.88.0> ! {'$gen_cast', >>> {mnesia_down,'gcfc-triple1_**519129@REDACTED'}} >>> >>> % mnesia_recover receives mnesia_down, nothing to do there >>> (<0.88.0>) << {'$gen_cast',{mnesia_down,'**gcfc-triple1_519129@REDACTED >>> '**}} >>> >>> % mnesia_monitor call mnesia_controller:mnesia_down >>> (<0.85.0>) <0.93.0> ! {'$gen_cast', >>> {mnesia_down,'gcfc-triple1_**519129@REDACTED'}} >>> >>> % mnesia_controller receives mnesia_down >>> (<0.93.0>) << {'$gen_cast',{mnesia_down,'**gcfc-triple1_519129@REDACTED >>> '**}} >>> >>> % mnesia_controller calls mnesia_recover:log_mnesia_**down() >>> (<0.93.0>) <0.88.0> ! {'$gen_call', {<0.93.0>,#Ref<0.0.0.1860>}, >>> {log_mnesia_down,'gcfc-**triple1_519129@REDACTED'}} >>> >>> % mnesia_recover receives log_mnesia_down, store it in decision table >>> and reply >>> (<0.88.0>) << {'$gen_call',{<0.93.0>,#Ref<0.**0.0.1860>}, >>> {log_mnesia_down,'gcfc-**triple1_519129@REDACTED'}} >>> (<0.88.0>) <0.93.0> ! {#Ref<0.0.0.1860>,ok} >>> >>> % mnesia_controller receives response from mnesia_recover:log_mnesia_** >>> down() >>> (<0.93.0>) << {#Ref<0.0.0.1860>,ok} >>> >>> % mnesia_controller calls mnesia_monitor:mnesia_down(**mnesia_controller, >>> Node) >>> (<0.93.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_**controller, >>> 'gcfc-triple1_519129@REDACTED**'}} >>> >>> % mnesia_controller receives mnesia_down, mnesia_controller >>> (<0.85.0>) << {'$gen_cast', {mnesia_down,mnesia_**controller, >>> 'gcfc-triple1_519129@REDACTED**'}} >>> >>> % mnesia_controller forwards mnesia_down to mnesia_tm >>> (<0.85.0>) <0.89.0> ! {mnesia_down,'gcfc-triple1_**519129@REDACTED'} >>> >>> % mnesia_tm receives mnesia_down >>> (<0.89.0>) << {mnesia_down,'gcfc-triple1_**519129@REDACTED'} >>> >>> % mnesia_tm calls mnesia_monitor:mnesia_down(**mnesia_tm, {Node, >>> ParticipantsTids}), >>> (<0.89.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_tm, >>> {'gcfc-triple1_519129@**localhost',[]}}} >>> >>> % mnesia_monitor receives mnesia_down, mnesia_tm >>> % now it is going to call mnesia_locker:mnesia_down, which will send >>> release_remote_non_pending >>> (<0.85.0>) << {'$gen_cast', {mnesia_down, mnesia_tm, >>> {'gcfc-triple1_519129@**localhost',[]}}} >>> >>> % Our processes receives information about node down and try to >>> recover from mnesiai >>> (<0.206.0>) << {activate,true} >>> >>> % Starts outer transaction >>> (<0.206.0>) <0.89.0> ! {{<0.206.0>,#Ref<0.0.0.1875>},**start_outer} >>> (<0.89.0>) << {{<0.206.0>,#Ref<0.0.0.1875>},**start_outer} >>> >>> % Reply for start_outer >>> (<0.89.0>) <0.206.0> ! {mnesia_tm,#Ref<0.0.0.1875>, >>> {new_tid,{tid,176,<0.206.0>},**245835}} >>> (<0.206.0>) << {mnesia_tm,#Ref<0.0.0.1875>, >>> {new_tid,{tid,176,<0.206.0>},**245835}} >>> >>> % Try to obtain lock for mnesia:select (just failed node holded sticky >>> lock for that table) >>> (<0.206.0>) {mnesia_locker,'gcfc-triple2_**519129@REDACTED'} ! >>> {<0.206.0>, {read, {tid,176, <0.206.0>}, >>> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >>> '______WHOLETABLE_____'}}} >>> (<0.87.0>) << {<0.206.0>, {read, {tid,176,<0.206.0>}, >>> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >>> '______WHOLETABLE_____'}}} >>> >>> % mnesia_locker informs out process that it needs switch sticky lock >>> (<0.87.0>) <0.206.0> ! {mnesia_locker,'gcfc-triple2_**519129@REDACTED', >>> {switch,'gcfc-triple1_519129@**localhost', {<0.206.0>, {read, >>> {tid,176,<0.206.0>}, >>> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >>> '______WHOLETABLE_____'}}}}} >>> (<0.206.0>) << {mnesia_locker,'gcfc-triple2_**519129@REDACTED', >>> {switch,'gcfc-triple1_519129@**localhost', {<0.206.0>, {read, >>> {tid,176,<0.206.0>}, >>> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >>> '______WHOLETABLE_____'}}}}} >>> >>> % Our proces just want to send {<0.206.0>, {read, {tid,176,<0.206.0>}, >>> {'tasks_tt_gcfc-triple1_**519129@REDACTED', >>> '______WHOLETABLE_____'}}} to other node >>> % Other node is not connected, so Erlang tryies to connect to it >>> (<0.21.0> is net_kernel process) >>> (<0.206.0>) <0.21.0> ! {'$gen_call', {<0.206.0>,#Ref<0.0.0.1884>}, >>> {connect,normal,'gcfc-triple1_**519129@REDACTED'}} >>> >>> % Connection to remote node was unsucsefull, and our process is hanged >>> in this function: >>> % >>> % l_req_rec(Node, Store) -> >>> % ?ets_insert(Store, {nodes, Node}), >>> % receive >>> % {?MODULE, Node, Reply} -> >>> % Reply; >>> % {mnesia_down, Node} -> >>> % {not_granted, {node_not_running, Node}} >>> % end. >>> % >>> % It will never get out, as sent message is lost >>> (<0.206.0>) << {#Ref<0.0.0.1884>,false} >>> >>> % mnesia_monitor call mnesia_locker:mnesia_down, which is sending >>> release_remote_non_pending >>> (<0.85.0>) <0.87.0> ! {release_remote_non_pending, >>> 'gcfc-triple1_519129@REDACTED**',[]} >>> >>> % mnesia_locker receives release_remote_non_pending >>> % it removes sticky locks of failed nodes and releases all transactions >>> % but it is too late - process <0.206.0> is already stucked for >>> waiting for response from not connected node >>> (<0.87.0>) << {release_remote_non_pending,'** >>> gcfc-triple1_519129@REDACTED'**,[]} >>> >>> % mnesia_locker call mnesia_monitor:mnesia_down(**mnesia_locker, Node) >>> (<0.87.0>) <0.85.0> ! {'$gen_cast', {mnesia_down,mnesia_locker, >>> 'gcfc-triple1_519129@REDACTED**'}} >>> >>> % mnesia_monitor receives mnesia_down, mnesia_locker >>> (<0.85.0>) << {'$gen_cast', >>> {mnesia_down,mnesia_locker,'**gcfc-triple1_519129@REDACTED'**}} >>> >>> % mnesia_monitor calls mnesia_lib:report_system_**event, which will send >>> notify to mnesia_event >>> (<0.85.0>) <0.83.0> ! {notify, {mnesia_system_event, >>> {mnesia_down,'gcfc-triple1_**519129@REDACTED'}}} >>> >>> >>> So problem is that transaction process sends messages to not-connected >>> node and awaits response which will never come. >>> One of the easiest solution is to monitor remote process, which >>> prevent this from happening. >>> >>> Suggested patch is available at: >>> >>> git fetch git://github.com/janchochol/**otp.gitsticky_lock_race >>> >>> https://github.com/janchochol/**otp/compare/erlang:maint...** >>> sticky_lock_race >>> https://github.com/janchochol/**otp/compare/erlang:maint...** >>> sticky_lock_race.patch >>> >>> >>> You can try to reproduce the problem with following module: >>> >>> --- BEGIN OF slock.erl --- >>> %% stick_lock problem reproducer >>> %% >>> %% To reproduce problem execute these commands in parallel: >>> %% >>> %% erl -sname n2@REDACTED -cookie slock -s slock n2 >>> %% erl -sname n1@REDACTED -cookie slock -s slock n1 >>> %% >>> %% Problem is timing related, so it has relatively low probability of >>> reproducing. >>> %% To increase probability use this patch: >>> %% >>> %% --- a/lib/mnesia/src/mnesia_**locker.erl >>> %% +++ b/lib/mnesia/src/mnesia_**locker.erl >>> %% @@ -663,6 +663,7 @@ mnesia_down(N, Pending) -> >>> %% %% race with mnesia_tm's coordinator processes >>> %% %% that may restart and acquire new locks. >>> %% %% mnesia_monitor ensures the sync. >>> %% + timer:sleep(1000), >>> %% Pid ! {release_remote_non_pending, N, Pending} >>> %% end. >>> %% >>> %% >>> %% When problem appears n1 node will hang indefinitely. >>> %% When problem is not present n1 will finish shortly after n2. >>> >>> >>> -module(slock). >>> >>> -export([n1/0, n2/0]). >>> >>> wait_for_n2() -> >>> case rpc:call(n2@REDACTED, erlang, whereis, [n2]) of >>> Pid when is_pid(Pid) -> >>> Pid; >>> _ -> >>> timer:sleep(100), >>> wait_for_n2() >>> end. >>> >>> wait_fun(Fun, PollIntervalMs) -> >>> case Fun() of >>> false -> >>> timer:sleep(PollIntervalMs), >>> wait_fun(Fun, PollIntervalMs); >>> true -> >>> ok >>> end. >>> >>> >>> n1() -> >>> register(n1, self()), >>> io:format("n1: statred~n", []), >>> io:format("n1: waiting for n2~n", []), >>> N2 = wait_for_n2(), >>> io:format("n1: n2 found~n", []), >>> io:format("n1: init mnesia start~n", []), >>> ok = application:start(mnesia, permanent), >>> ok = rpc:call(n2@REDACTED, application, start, [mnesia, >>> permanent]), >>> {ok, [_ | _]} = mnesia:change_config(extra_db_**nodes, >>> [n2@REDACTED]), >>> {atomic, ok} = mnesia:create_table(t1, [{ram_copies, >>> [n1@REDACTED, n2@REDACTED]}]), >>> ok = rpc:call(n2@REDACTED, mnesia, wait_for_tables, [[t1], >>> infinity]), >>> io:format("n1: init mnesia end~n", []), >>> N2 ! {ping, self()}, >>> receive step -> ok end, >>> wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang end, 100), >>> io:format("n1: select start~n", []), >>> Ret = mnesia:transaction(fun() -> >>> wait_fun(fun() -> net_adm:ping(n2@REDACTED) =:= pang >>> end, 10), >>> mnesia:select(t1, [{{t1, '_', '_'}, [], ['$_']}]) >>> end), >>> io:format("n1: select end: ~p~n", [Ret]), >>> init:stop(). >>> >>> n2() -> >>> register(n2, self()), >>> io:format("n2: statred~n", []), >>> io:format("n2: waiting for n1 ping~n", []), >>> N2 = receive >>> {ping, IN2} -> >>> IN2 >>> end, >>> io:format("n2: n1 pinged~n", []), >>> io:format("n2: write start~n", []), >>> mnesia:transaction(fun() -> mnesia:write(t1, {t1, a, b}, >>> sticky_write) end), >>> io:format("n2: write end~n", []), >>> N2 ! step, >>> io:format("n2: finish~n", []), >>> erlang:halt(). >>> --- END OF slock.erl --- >>> >>> I do not see any other easy solution for this problem. >>> >>> Best Regards, >>> Jan Chochol >>> ______________________________**_________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/**listinfo/erlang-patches >>> >> >> -- >> /Henrik Nord Erlang/OTP >> >> >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From puzza007@REDACTED Thu Oct 10 20:03:58 2013 From: puzza007@REDACTED (Paul Oliver) Date: Thu, 10 Oct 2013 20:03:58 +0200 Subject: [erlang-patches] Add iodata, nonempty_string to built-in type highlighting for emacs Message-ID: https://github.com/erlang/otp/pull/99 Cheers, Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From puzza007@REDACTED Thu Oct 10 20:27:37 2013 From: puzza007@REDACTED (Paul Oliver) Date: Thu, 10 Oct 2013 20:27:37 +0200 Subject: [erlang-patches] Add iodata, nonempty_string to built-in type highlighting for emacs In-Reply-To: References: Message-ID: Use this instead - based on the maint branch https://github.com/erlang/otp/pull/100 On Thu, Oct 10, 2013 at 8:03 PM, Paul Oliver wrote: > https://github.com/erlang/otp/pull/99 > > Cheers, > Paul. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Oct 12 14:10:38 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 12 Oct 2013 14:10:38 +0200 Subject: [erlang-patches] Properly handle export_all when looking for undefined callbacks Message-ID: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> Hello, When compiling a behaviour with export_all, every callback is marked as missing by erl_lint. This patch fixes this. Thanks to Michele Miron (Cc'd) for reporting this bug. git fetch https://github.com/nox/otp.git export_all-behaviour https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour.patch Regards, -- Anthony Ramine From sean@REDACTED Mon Oct 14 02:44:26 2013 From: sean@REDACTED (Sean Cribbs) Date: Sun, 13 Oct 2013 19:44:26 -0500 Subject: [erlang-patches] Add lists:find/2,3 Message-ID: `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned. ## Why this new feature? A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value. ## Risks / uncertain artifacts It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last. ## How did you solve it? Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not. https://github.com/erlang/otp/pull/102 -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc@REDACTED Mon Oct 14 02:49:25 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Sun, 13 Oct 2013 20:49:25 -0400 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: Message-ID: +1 On Oct 13, 2013 8:44 PM, "Sean Cribbs" wrote: > `lists:find/2,3` returns the first element of the passed list for which > the predicate fun returns `true`. If no elements result in the predicate > being true, `undefined` (/2) or the given default value (/3) is returned. > > ## Why this new feature? > > A common task is to select the first element from a list that matches a > condition, but there is no existing lists function or language feature that > avoids traversing the entire list, while still returning a "safe" value. > `lists:find/2,3` codifies the pattern of a tail-recursive search for the > matching item without resorting to exceptions (used to abort `foreach/2` or > `foldl/3`) and always returns either the first matching item, or an > otherwise safe value. > > ## Risks / uncertain artifacts > > It is unclear the desired order of arguments for the 3-arity version. I > have made the default value the final argument which is consistent with > `application:get_env/3` and `proplists:get_value/3`, but most functions in > lists place the `List` argument last. > > ## How did you solve it? > > Following the patterns of other functions in the lists module, > `lists:find/3` tests the predicate function against the head of the list, > returning the head if the predicate passes, or recursing over the tail if > it does not. > > https://github.com/erlang/otp/pull/102 > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Mon Oct 14 09:54:44 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Oct 2013 09:54:44 +0200 Subject: [erlang-patches] Properly handle export_all when looking for undefined callbacks In-Reply-To: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> Message-ID: <525BA344.9020907@erlang.org> On 10/12/2013 02:10 PM, Anthony Ramine wrote: > Hello, > > When compiling a behaviour with export_all, every callback is marked as missing by erl_lint. This patch fixes this. > > Thanks to Michele Miron (Cc'd) for reporting this bug. > > git fetch https://github.com/nox/otp.git export_all-behaviour > > https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour > https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour.patch > > Regards, > Hello Anthony, I've fetched your patch, applied the correct bootstrap file and assigned it to be reviewed by responsible developers. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Mon Oct 14 12:28:33 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 14 Oct 2013 12:28:33 +0200 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: References: Message-ID: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> Hello Sean, I don't like this patch. 1/ You can't know whether an element was found or not if the list elements are arbitrary terms. 2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2. A naive implementation of find/2 using dropwhile/2: find(F, L) -> case dropwhile(fun (E) -> not F(E) end, L) of [] -> undefined; [E|_] -> E end. Regards, -- Anthony Ramine Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : > `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned. > > ## Why this new feature? > > A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value. > > ## Risks / uncertain artifacts > > It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last. > > ## How did you solve it? > > Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not. > > https://github.com/erlang/otp/pull/102 > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From masklinn@REDACTED Mon Oct 14 12:38:55 2013 From: masklinn@REDACTED (Masklinn) Date: Mon, 14 Oct 2013 12:38:55 +0200 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> Message-ID: <6FCEA575-1016-4695-8A7B-EFDC130700A8@masklinn.net> On 2013-10-14, at 12:28 , Anthony Ramine wrote: > Hello Sean, > > I don't like this patch. > > 1/ You can't know whether an element was found or not if the list elements are arbitrary terms. You also can't assert that an element was found in the usual manner (namely {ok, Result} = fun:call()) > 2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2. > > A naive implementation of find/2 using dropwhile/2: > > find(F, L) -> > case dropwhile(fun (E) -> not F(E) end, L) of > [] -> undefined; > [E|_] -> E > end. > > Regards, > > -- > Anthony Ramine From n.oxyde@REDACTED Mon Oct 14 12:45:38 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 14 Oct 2013 12:45:38 +0200 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <52544B0D.50501@cs.ntua.gr> References: <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> <185EEAD8-2C06-4BCB-8863-B6F8CC79460D@gmail.com> <5195E2BE.4060104@erlang.org> <406DB238-CBC1-4CCD-9AFF-1AC9DBFDA62B@gmail.com> <637F7FCA-3360-4F81-AFB1-C3D41A6E4139@gmail.com> <5199D1BA.6010206@erlang.org> <5B7E1490-0301-4BF7-B6E4-FBD792B3ECD1@gmail.com> <8BBBCFB9-8917-456D-B21B-558C163D09C8@gmail.com> <5! 236CAA6.7050609@erlang.org> <7ED437FD-45EA-4079-A381-AFC9F566F89E@gmail.com> <9587CB66-B48E-42EC-AEB2-7EA8B383714D@gmail.com> <5783C96C-164E-470D-AD84-45EDF2DC5B4E@gmail.com> <52544B0D.50501@cs.ntua.gr> Message-ID: <4C753C85-31F5-46E3-B91A-73356C815A7D@gmail.com> Hello Kostis, To reproduce the crash, compile the following module with +native with my rm-reverse-eta-conversion branch: -module(t). -export([t1/0,t2/0]). t1() -> fun identity/1. t2() -> fun identity/2. identity(X) -> X. Loading this module compiled with HiPE on my branch will make HiPE crash in patch_funentries. Commenting the t2/0 function out makes the crash disappear. That shows that the cause of the crash is multiple references to the same local function. Regards, -- Anthony Ramine Le 8 oct. 2013 ? 20:12, Kostis Sagonas a ?crit : > Anyway, I am not sure how to contribute here and it will take me quite some time to investigate this from scratch, time which sadly I do not have these days. I can spend some time on this if I feel like hacking again one of the nights to come, but only if you minimize this and send me a self-contained module that shows the problem when you generate BEAM code with the changed compiler, but not with the vanilla. From n.oxyde@REDACTED Mon Oct 14 13:07:26 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 14 Oct 2013 13:07:26 +0200 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <4C753C85-31F5-46E3-B91A-73356C815A7D@gmail.com> References: <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> <185EEAD8-2C06-4BCB-8863-B6F8CC79460D@gmail.com> <5195E2BE.4060104@erlang.org> <406DB238-CBC1-4CCD-9AFF-1AC9DBFDA62B@gmail.com> <637F7FCA-3360-4F81-AFB1-C3D41A6E4139@gmail.com> <5199D1BA.6010206@erlang.org> <5B7E1490-0301-4BF7-B6E4-FBD792B3ECD1@gmail.com> <8BBBCFB9-8917-456D-B21B-558C163D09C8@gmail.com> <5! 236CAA6.7050609@erlang.org> <7ED437FD-45EA-4079-A381-AFC9F566F89E@gmail.com> <9587CB66-B48E-42EC-AEB2-7EA8B383714D@gmail.com> <5783C96C-164E-470D-AD84-45EDF2DC5B4E@gmail.com> <52544B0D.50501@cs.ntua.gr> <4C753C85-31F5-46E3-B91A-73356C815A7D@gmail.com> Message-ID: Err, t2() -> fun identity/1. -- Anthony Ramine > Le 14 oct. 2013 ? 12:45, Anthony Ramine a ?crit : > > Hello Kostis, > > To reproduce the crash, compile the following module with +native with my rm-reverse-eta-conversion branch: > > -module(t). > -export([t1/0,t2/0]). > > t1() -> fun identity/1. > t2() -> fun identity/2. > > identity(X) -> X. > > Loading this module compiled with HiPE on my branch will make HiPE crash in patch_funentries. Commenting the t2/0 function out makes the crash disappear. That shows that the cause of the crash is multiple references to the same local function. > > Regards, > > -- > Anthony Ramine > >> Le 8 oct. 2013 ? 20:12, Kostis Sagonas a ?crit : >> >> Anyway, I am not sure how to contribute here and it will take me quite some time to investigate this from scratch, time which sadly I do not have these days. I can spend some time on this if I feel like hacking again one of the nights to come, but only if you minimize this and send me a self-contained module that shows the problem when you generate BEAM code with the changed compiler, but not with the vanilla. > From n.oxyde@REDACTED Tue Oct 15 13:09:11 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Oct 2013 13:09:11 +0200 Subject: [erlang-patches] Fix some warnings when compiling with Clang Message-ID: <065F93FE-9039-46F6-B6DC-658472EA2028@gmail.com> Hello, This branch fixes some warnings, a badly-written assertion when in debug mode and some silent rules. git fetch https://github.com/nox/otp.git fix-clang-warnings https://github.com/nox/otp/compare/erlang:maint...fix-clang-warnings https://github.com/nox/otp/compare/erlang:maint...fix-clang-warnings.patch Regards, -- Anthony Ramine From henrik@REDACTED Tue Oct 15 15:05:50 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 15 Oct 2013 15:05:50 +0200 Subject: [erlang-patches] Fix some warnings when compiling with Clang In-Reply-To: <065F93FE-9039-46F6-B6DC-658472EA2028@gmail.com> References: <065F93FE-9039-46F6-B6DC-658472EA2028@gmail.com> Message-ID: <525D3DAE.1040700@erlang.org> Hi I created a pull request from this so that it will go into the system via the script. Thank you for your contribution! On 2013-10-15 13:09, Anthony Ramine wrote: > Hello, > > This branch fixes some warnings, a badly-written assertion when in debug mode and some silent rules. > > git fetch https://github.com/nox/otp.git fix-clang-warnings > > https://github.com/nox/otp/compare/erlang:maint...fix-clang-warnings > https://github.com/nox/otp/compare/erlang:maint...fix-clang-warnings.patch > > Regards, > -- /Henrik Nord Erlang/OTP From bengt.kleberg@REDACTED Wed Oct 16 14:13:15 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 16 Oct 2013 14:13:15 +0200 Subject: [erlang-patches] Add name_in_archive option to erl_tar:add/3 Message-ID: <1381925595.4823.37.camel@sekic1152.release> git fetch git://github.com/ebengt/otp.git erl_tar_add3_name_option https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option.patch From fredrik@REDACTED Wed Oct 16 15:26:00 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Oct 2013 15:26:00 +0200 Subject: [erlang-patches] Add name_in_archive option to erl_tar:add/3 In-Reply-To: <1381925595.4823.37.camel@sekic1152.release> References: <1381925595.4823.37.camel@sekic1152.release> Message-ID: <525E93E8.8050203@erlang.org> On 10/16/2013 02:13 PM, Bengt Kleberg wrote: > git fetch git://github.com/ebengt/otp.git erl_tar_add3_name_option > > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option.patch > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Bengt, I've created a pull request which is becoming the appropriate way of submitting patches. It is being built and assigned to responsible developers within a couple of days for review. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Fri Oct 18 21:20:05 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 18 Oct 2013 21:20:05 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> References: <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> <504DF309.2040900@erlang.org> <415229C2-452E-45FF-A207-69BD2212E2F5@gmail.com> <50519F42.7000109@erlang.org> <50598C38.8060506@erlang.org> <77306113-0789-4B6F-A45D-8304FFED5C39@gmail.com> <513DE767.90700@erlang.org> <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> Message-ID: Pang? -- Anthony Ramine Le 11 sept. 2013 ? 11:33, Anthony Ramine a ?crit : > Ping? > > -- > Anthony Ramine > > Le 22 avr. 2013 ? 13:38, Anthony Ramine a ?crit : > >> Ping? >> >> -- >> Anthony Ramine >> >> Le 18 mars 2013 ? 14:07, Anthony Ramine a ?crit : >> >>> Hi, >>> >>> Just rebased against latest maint. >>> >>> Please refetch. >>> >>> -- >>> Anthony Ramine >>> >>> Le 11 mars 2013 ? 15:17, Fredrik a ?crit : >>> >>>> On 12/02/2012 11:07 AM, Anthony Ramine wrote: >>>>> Hi, >>>>> >>>>> I've made column numbers a non-optional thing in compile but still an >>>>> option in epp; so that tools like edoc which don't need the full >>>>> locations can get only the line numbers. >>>>> >>>>> Please refetch. >>>>> >>>>> -- >>>>> Anthony Ramine >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> Hello, >>>> Could you please rebase this patch upon the current 'maint' branch? >>>> Thanks. >>>> >>>> -- >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >> From andrew@REDACTED Tue Oct 22 05:32:17 2013 From: andrew@REDACTED (Andrew Thompson) Date: Mon, 21 Oct 2013 23:32:17 -0400 Subject: [erlang-patches] Implement 'honor_cipher_order' SSL server-side option Message-ID: <20131022033217.GH9818@hijacked.us> https://github.com/erlang/otp/pull/111 Andrew From hm@REDACTED Tue Oct 22 10:15:00 2013 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 22 Oct 2013 10:15:00 +0200 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> Message-ID: Further, the function find/2 is inconsistent with the style in the lists module. Other functions in the lists module returns 'false' instead of 'undefined' when an item not is found. See lists:keyfind/3 for example. /H?kan On Mon, Oct 14, 2013 at 12:28 PM, Anthony Ramine wrote: > Hello Sean, > > I don't like this patch. > > 1/ You can't know whether an element was found or not if the list elements > are arbitrary terms. > 2/ I don't see why you would say people hack either foreach/2 or foldl/3 > to do that when they should just use dropwhile/2. > > A naive implementation of find/2 using dropwhile/2: > > find(F, L) -> > case dropwhile(fun (E) -> not F(E) end, L) of > [] -> undefined; > [E|_] -> E > end. > > Regards, > > -- > Anthony Ramine > > Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : > > > `lists:find/2,3` returns the first element of the passed list for which > the predicate fun returns `true`. If no elements result in the predicate > being true, `undefined` (/2) or the given default value (/3) is returned. > > > > ## Why this new feature? > > > > A common task is to select the first element from a list that matches a > condition, but there is no existing lists function or language feature that > avoids traversing the entire list, while still returning a "safe" value. > `lists:find/2,3` codifies the pattern of a tail-recursive search for the > matching item without resorting to exceptions (used to abort `foreach/2` or > `foldl/3`) and always returns either the first matching item, or an > otherwise safe value. > > > > ## Risks / uncertain artifacts > > > > It is unclear the desired order of arguments for the 3-arity version. I > have made the default value the final argument which is consistent with > `application:get_env/3` and `proplists:get_value/3`, but most functions in > lists place the `List` argument last. > > > > ## How did you solve it? > > > > Following the patterns of other functions in the lists module, > `lists:find/3` tests the predicate function against the head of the list, > returning the head if the predicate passes, or recursing over the tail if > it does not. > > > > https://github.com/erlang/otp/pull/102 > > > > -- > > Sean Cribbs > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Oct 22 12:04:43 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 22 Oct 2013 12:04:43 +0200 Subject: [erlang-patches] Add lists:find/2,3 In-Reply-To: <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> References: <7B18B788-0CB8-45E4-8F0D-E1B4B92D77A6@gmail.com> <56EEBA04-D9B4-4A05-BEC7-3C56E3621368@gmail.com> Message-ID: <1B1A83F9-D9D5-4A04-8E45-3A530FBC35F8@gmail.com> Forwarding to list. -- Anthony Ramine Le 22 oct. 2013 ? 11:56, Anthony Ramine a ?crit : > Maybe we could just have dropuntil(F, L) -> dropwhile(fun (X) -> not F(X) end, L). > > Of course, the function would be written less naively to avoid constructing a new fun. > > -- > Anthony Ramine > > Le 14 oct. 2013 ? 15:52, Sean Cribbs a ?crit : > >> #1: Would tagging the return value address like Masklinn mentions address your concern? {ok, Term} | error (instead of a default value)? >> >> #2: Also, I considered dropwhile but it involves introducing another fun, whereas the version I wrote is direct. >> >> >> On Mon, Oct 14, 2013 at 5:28 AM, Anthony Ramine wrote: >> Hello Sean, >> >> I don't like this patch. >> >> 1/ You can't know whether an element was found or not if the list elements are arbitrary terms. >> 2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2. >> >> A naive implementation of find/2 using dropwhile/2: >> >> find(F, L) -> >> case dropwhile(fun (E) -> not F(E) end, L) of >> [] -> undefined; >> [E|_] -> E >> end. >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 14 oct. 2013 ? 02:44, Sean Cribbs a ?crit : >> >>> `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned. >>> >>> ## Why this new feature? >>> >>> A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value. >>> >>> ## Risks / uncertain artifacts >>> >>> It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last. >>> >>> ## How did you solve it? >>> >>> Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not. >>> >>> https://github.com/erlang/otp/pull/102 >>> >>> -- >>> Sean Cribbs >>> Software Engineer >>> Basho Technologies, Inc. >>> http://basho.com/ >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> >> >> >> -- >> Sean Cribbs >> Software Engineer >> Basho Technologies, Inc. >> http://basho.com/ > From daniel@REDACTED Tue Oct 22 23:46:21 2013 From: daniel@REDACTED (Daniel White) Date: Wed, 23 Oct 2013 08:46:21 +1100 Subject: [erlang-patches] [PATCH] Teach xmerl_xpath to resolve context namespaces in more cases In-Reply-To: <364F4E6E-1C16-4413-9B90-A342F400945F@gmail.com> References: <7A894AF5-CA8B-46F5-AD1F-756CC0025B1D@gmail.com> <364F4E6E-1C16-4413-9B90-A342F400945F@gmail.com> Message-ID: Anthony, I thought I might have a chance to look at items mentioned above, but there are many other issues competing for my attention, and this doesn't scratch any of my itches. Will keep it in mind if I'm passing this way again, however. Fredrik, Has the applicable team been able to look at this? We're hoping it is minimal enough to see it in an R16 release. As it stands, we need to have unnecessarily complicated hacks in our codebase in order to work around this problem. Cheers, On Fri, Sep 13, 2013 at 8:49 PM, Anthony Ramine wrote: > Btw 3 years ago when I implemented the namespace axis in xmerl_xpath I had to fix a few things beforehand, but I left a todo in that commit: > > https://github.com/nox/otp/commit/770d6d9aaf4ebad18b1247911c5c3c23d688364a > > You may be interested in actually completing it. > > Regards, > > Le 13 sept. 2013 ? 12:47, Anthony Ramine a ?crit : > >> Well, good news, that's one less bug to fix :) >> >> Le 13 sept. 2013 ? 12:45, Daniel White a ?crit : >> >>> D'oh, that was a mistake when transcribing it from my console. The >>> example above should have read: >>> >>> >>> >>> >>> >>> On Fri, Sep 13, 2013 at 7:57 PM, Anthony Ramine wrote: >>>> Isn't that case wrong too? >>>> >>>> The element isn't in the http://www.example.com/ns namespace, right? >>>> >>>> Le 12 sept. 2013 ? 18:52, Daniel White a ?crit : >>>> >>>>>> [#xmlElement{}] = xmerl_xpath:string("/root/t:child", Doc, [{namespace, [{"t", "http://www.example.com/ns"}]}]). >> > -- Daniel White From n.oxyde@REDACTED Wed Oct 23 12:02:45 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 23 Oct 2013 12:02:45 +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> <14F3108F-0268-4597-83CE-A2D610C2A5A6@gmail.com> <48B3401B-EAD7-442B-BA36-395E9B510B06@gmail.com> Message-ID: IntelliJ-Erlang now supports named funs. https://github.com/ignatov/intellij-erlang/issues/325#issuecomment-26837215 -- Anthony Ramine Le 10 sept. 2013 ? 14:41, Kenneth Lundin a ?crit : > Sorry for the delay. > > Anyway , we decided that the Fun with names implementation can be included in the R17 release which is > scheduled for Q1 2014. > > We have to look into the impact on tools. The additional syntax might confuse some of the tools working on source code. > > /Kenneth, Erlang/OTP, Ericsson > > > On Tue, Sep 10, 2013 at 10:52 AM, Tony Rogvall wrote: > Give the dog his bone ;-) > > /Tony > > On 10 sep 2013, at 10:28, Anthony Ramine wrote: > >> And of which today this tomorrow is supposed to be? :p >> >> Le 5 sept. 2013 ? 16:50, Kenneth Lundin a ?crit : >> >>> Hi, >>> >>> Yes, we have dicussed this on our technical board, I don't have the exact outcome >>> at hand but can give more info tomorrow. As far as I remember it was a positive verdict. >>> >>> /Kenneth, Erlang/OTP Ericsson >>> >>> Den 5 sep 2013 11:56 skrev "Anthony Ramine" : >>> Ping? >>> >>> -- >>> Anthony Ramine >>> >>> Le 2 juil. 2013 ? 10:12, Anthony Ramine a ?crit : >>> >>>> 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 >>>> >>> >>> _______________________________________________ >>> eeps mailing list >>> eeps@REDACTED >>> http://erlang.org/mailman/listinfo/eeps >> >> _______________________________________________ >> eeps mailing list >> eeps@REDACTED >> http://erlang.org/mailman/listinfo/eeps > > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" > > > > From bgustavsson@REDACTED Wed Oct 23 15:04:16 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 23 Oct 2013 15:04:16 +0200 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine wrote: > This patch implements EEP37: Funs with names [...] > I have now reviewed your implementation and have the following comments: As far as I understand, you have done updates in all places that should be changed. Excellent! The new test cases are insufficient for an extension of the language. Each application that have updates should have test cases to ensure that new or updated code is covered. The following applications should have test cases for named funs: compiler, tools (xref and cover), stdlib (qlc, erl_eval, ms_transform), dialyzer, debugger, and syntax_tools. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Wed Oct 23 15:38:31 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 23 Oct 2013 15:38:31 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> <504DF309.2040900@erlang.org> <415229C2-452E-45FF-A207-69BD2212E2F5@gmail.com> <50519F42.7000109@erlang.org> <50598C38.8060506@erlang.org> <77306113-0789-4B6F-A45D-8304FFED5C39@gmail.com> <5 13DE767.90700@erlang.org> <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> Message-ID: <5267D157.7020305@erlang.org> On 10/18/2013 09:20 PM, Anthony Ramine wrote: > Pang? > Hello Anthony, There has been a decision made that we are going to start investigating this issue in the coming weeks and you will get further information in a couple of weeks regarding the outcome of this. Thanks for your patience. -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Wed Oct 23 15:42:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 23 Oct 2013 15:42:41 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: <5267D157.7020305@erlang.org> References: <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> <504DF309.2040900@erlang.org> <415229C2-452E-45FF-A207-69BD2212E2F5@gmail.com> <50519F42.7000109@erlang.org> <50598C38.8060506@erlang.org> <77306113-0789-4B6F-A45D-8304FFED5C39@gmail.com> <5 13DE767.90700@erlang.org> <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> <6FFF00A1-0745-4B22-9A94-4A9C154B6BC6@gmail.com> <5267D157.7020305@erlang.org> Message-ID: You?re welcome. I know you have a lot to do! -- Anthony Ramine Le 23 oct. 2013 ? 15:38, Fredrik a ?crit : > On 10/18/2013 09:20 PM, Anthony Ramine wrote: >> Pang? >> > Hello Anthony, > There has been a decision made that we are going to start investigating this issue in the coming weeks and you will get further information in a couple of weeks regarding the outcome of this. > Thanks for your patience. > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From n.oxyde@REDACTED Wed Oct 23 15:46:32 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 23 Oct 2013 15:46:32 +0200 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: Will add tests for everything you said. Could you just tell me which compiler suites I should update? -- Anthony Ramine Le 23 oct. 2013 ? 15:04, Bj?rn Gustavsson a ?crit : > > On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine wrote: > This patch implements EEP37: Funs with names [...] > > I have now reviewed your implementation and have the following comments: > > As far as I understand, you have done updates in all places that should be changed. > Excellent! > > The new test cases are insufficient for an extension of the language. Each > application that have updates should have test cases to ensure that new or > updated code is covered. The following applications should have test cases > for named funs: compiler, tools (xref and cover), stdlib (qlc, erl_eval, ms_transform), > dialyzer, debugger, and syntax_tools. > > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From fredrik@REDACTED Thu Oct 24 09:06:18 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 24 Oct 2013 09:06:18 +0200 Subject: [erlang-patches] [PATCH] Teach xmerl_xpath to resolve context namespaces in more cases In-Reply-To: References: <7A894AF5-CA8B-46F5-AD1F-756CC0025B1D@gmail.com> <364F4E6E-1C16-4413-9B90-A342F400945F@gmail.com> Message-ID: <5268C6EA.4060705@erlang.org> On 10/22/2013 11:46 PM, Daniel White wrote: > Anthony, > > I thought I might have a chance to look at items mentioned above, but > there are many other issues competing for my attention, and this > doesn't scratch any of my itches. Will keep it in mind if I'm passing > this way again, however. > > > Fredrik, > > Has the applicable team been able to look at this? We're hoping it is > minimal enough to see it in an R16 release. As it stands, we need to > have unnecessarily complicated hacks in our codebase in order to work > around this problem. > > > Cheers, > > > On Fri, Sep 13, 2013 at 8:49 PM, Anthony Ramine wrote: >> Btw 3 years ago when I implemented the namespace axis in xmerl_xpath I had to fix a few things beforehand, but I left a todo in that commit: >> >> https://github.com/nox/otp/commit/770d6d9aaf4ebad18b1247911c5c3c23d688364a >> >> You may be interested in actually completing it. >> >> Regards, >> >> Le 13 sept. 2013 ? 12:47, Anthony Ramine a ?crit : >> >>> Well, good news, that's one less bug to fix :) >>> >>> Le 13 sept. 2013 ? 12:45, Daniel White a ?crit : >>> >>>> D'oh, that was a mistake when transcribing it from my console. The >>>> example above should have read: >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Sep 13, 2013 at 7:57 PM, Anthony Ramine wrote: >>>>> Isn't that case wrong too? >>>>> >>>>> The element isn't in the http://www.example.com/ns namespace, right? >>>>> >>>>> Le 12 sept. 2013 ? 18:52, Daniel White a ?crit : >>>>> >>>>>>> [#xmlElement{}] = xmerl_xpath:string("/root/t:child", Doc, [{namespace, [{"t", "http://www.example.com/ns"}]}]). > > Hello Daniel, Your patch has been reviewed and will be included in the nightly builds and testing for R16B03 if there's no problems, it will be included in R16B03. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From bgustavsson@REDACTED Fri Oct 25 11:48:44 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 25 Oct 2013 11:48:44 +0200 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: On Wed, Oct 23, 2013 at 3:46 PM, Anthony Ramine wrote: > Will add tests for everything you said. > > Could you just tell me which compiler suites I should update? > > fun_SUITE seems to be a good place for test of named funs. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Oct 25 13:12:26 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 25 Oct 2013 13:12:26 +0200 Subject: [erlang-patches] Add name_in_archive option to erl_tar:add/3 In-Reply-To: <1381925595.4823.37.camel@sekic1152.release> References: <1381925595.4823.37.camel@sekic1152.release> Message-ID: I have reviewed the branch and added two comments to the pull request: https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option On Wed, Oct 16, 2013 at 2:13 PM, Bengt Kleberg wrote: > git fetch git://github.com/ebengt/otp.git erl_tar_add3_name_option > > > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option > > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option.patch > > > _______________________________________________ > 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 bgustavsson@REDACTED Fri Oct 25 13:13:18 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 25 Oct 2013 13:13:18 +0200 Subject: [erlang-patches] Add name_in_archive option to erl_tar:add/3 In-Reply-To: References: <1381925595.4823.37.camel@sekic1152.release> Message-ID: Oops... here is the link to the pull request: https://github.com/erlang/otp/pull/105 On Fri, Oct 25, 2013 at 1:12 PM, Bj?rn Gustavsson wrote: > I have reviewed the branch and added two comments to the pull request: > > > https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option > > > On Wed, Oct 16, 2013 at 2:13 PM, Bengt Kleberg > wrote: > >> git fetch git://github.com/ebengt/otp.git erl_tar_add3_name_option >> >> >> https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option >> >> https://github.com/ebengt/otp/compare/erlang:maint...erl_tar_add3_name_option.patch >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Oct 26 15:09:20 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 26 Oct 2013 15:09:20 +0200 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: <1A11105D-B94D-498D-B5C7-4473D55E8E77@gmail.com> Why do we have two erl_eval suites? I can?t spot any major difference between the two of them. $ git ls-files \*/erl_eval_SUITE.erl lib/debugger/test/erl_eval_SUITE.erl lib/stdlib/test/erl_eval_SUITE.erl -- Anthony Ramine Le 25 oct. 2013 ? 11:48, Bj?rn Gustavsson a ?crit : > On Wed, Oct 23, 2013 at 3:46 PM, Anthony Ramine wrote: > Will add tests for everything you said. > > Could you just tell me which compiler suites I should update? > > > fun_SUITE seems to be a good place for test of named funs. > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Sat Oct 26 15:43:20 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 26 Oct 2013 15:43:20 +0200 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: <4361102C-1368-4490-8D68-69567FAD0F39@gmail.com> There is nothing really tested in syntax_tools already apart from a smoke test over the OTP sources. As there is a named fun in erl_eval already, I don?t see why I should add a patch there. -- Anthony Ramine Le 23 oct. 2013 ? 15:04, Bj?rn Gustavsson a ?crit : > syntax_tools From mhssler@REDACTED Sat Oct 26 21:30:26 2013 From: mhssler@REDACTED (=?ISO-8859-1?Q?Martin_H=E4ssler?=) Date: Sat, 26 Oct 2013 21:30:26 +0200 Subject: [erlang-patches] Add os:unsetenv/1 Message-ID: This patch adds os:unsetenv/1 which deletes an environment variable. ### Why this new feature? With os:unsetenv/1, it is possible to delete environment variables. This makes it easier to test code which uses os:getenv/1 to check if an environment variable exists or not. The new function differs from os:putenv(Value, "") as the former deletes the variable while the latter keeps the variable with an empty value. Example: 1> os:putenv("foo", ""). true 2> os:getenv("foo"). [] 3> os:unsetenv("foo"). true 4> os:getenv("foo"). false ### Risks / uncertain artifacts None. New function without any changes in old functionality. ### How did you solve it? New BIF which calls the libc function unsetenv(3) on UNIX and SetEnvironmentVariableW(key, NULL) on Windows. The unicode support is the same as for os:getenv and os:putenv. https://github.com/erlang/otp/pull/114 -- Best Regards, /Martin From eric.pailleau@REDACTED Sun Oct 27 03:12:28 2013 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 27 Oct 2013 03:12:28 +0100 Subject: [erlang-patches] Add SASL log quick search for pid in observer Message-ID: <526C768C.2060506@wanadoo.fr> Hello, Please see pull request #116 . Regards From n.oxyde@REDACTED Sun Oct 27 21:29:12 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 27 Oct 2013 21:29:12 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: <66EC6D06-4291-4544-921A-325EBD8BBF5F@gmail.com> I?ve added tests for named funs in every place you asked for except syntax_tools. The Dialyzer test doesn?t pass and I haven?t found a fix for it yet, Cc?ing Kostis. If I give "fact() -> fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end" to typer, the following spec is computed: -spec fact() -> fun((0) -> none()). Please refetch. -- Anthony Ramine Le 23 oct. 2013 ? 15:04, Bj?rn Gustavsson a ?crit : > The new test cases are insufficient for an extension of the language. Each > application that have updates should have test cases to ensure that new or > updated code is covered. The following applications should have test cases > for named funs: compiler, tools (xref and cover), stdlib (qlc, erl_eval, ms_transform), > dialyzer, debugger, and syntax_tools. > From n.oxyde@REDACTED Mon Oct 28 00:26:54 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 28 Oct 2013 00:26:54 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <66EC6D06-4291-4544-921A-325EBD8BBF5F@gmail.com> References: <66EC6D06-4291-4544-921A-325EBD8BBF5F@gmail.com> Message-ID: <473CD07F-27D0-4933-AECF-D369BDD26992@gmail.com> With DEBUG and DEBUG_PP defined in dialyzer_dataflow: $ bin/dialyzer --plt .dialyzer_plt lib/dialyzer/test/small_SUITE_data/src/eep37.erl Checking whether the PLT .dialyzer_plt is up-to-date... yes Proceeding with analysis? module 'eep37' ['fact'/0, 'module_info'/0, 'module_info'/1, 'self'/0] attributes ['spec' = [{{'self', 0}, [{'type', 5, 'fun', [{'type', 5, 'product', []}, {'type', 5, 'fun', [{'type', 5, 'product', []}, {'type', 5, 'fun', []}]}]}]}]] ('self'/0 -| [{'label', 0}]) = (fun () -> case <> of <> when 'true' -> letrec ('Self'/0 -| [{'label', 5}]) = (fun () -> let (Self -| [{'label', 6}]) = ('Self'/0 -| [{'label', 5}]) in case <> of <> when 'true' -> (Self -| [{'label', 6}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 13}]) in ('Self'/0 -| [{'label', 5}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 19}]) ('fact'/0 -| [{'label', 1}]) = (fun () -> case <> of <> when 'true' -> letrec ('Fact'/1 -| [{'label', 21}]) = (fun ((_cor2 -| [{'label', 22}])) -> let (Fact -| [{'label', 23}]) = ('Fact'/1 -| [{'label', 21}]) in case (_cor2 -| [{'label', 22}]) of (N -| [{'label', 24}]) when call 'erlang':'>'((N -| [{'label', 24}]), 0) -> let (_cor0 -| [{'label', 27}]) = call 'erlang':'-'((N -| [{'label', 24}]), 1) in let (_cor1 -| [{'label', 29}]) = apply (Fact -| [{'label', 23}])((_cor0 -| [{'label', 27}])) in call 'erlang':'*'((N -| [{'label', 24}]), (_cor1 -| [{'label', 29}])) 0 when 'true' -> 1 (_cor3 -| [{'label', 35}]) when 'true' -> primop 'match_fail'({'function_clause', (_cor3 -| [{'label', 35}])}) end -| [{'label', 41}]) in ('Fact'/1 -| [{'label', 21}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 47}]) ('module_info'/0 -| [{'label', 2}]) = (fun () -> case <> of <> when 'true' -> call 'erlang':'get_module_info'('eep37') <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 54}]) ('module_info'/1 -| [{'label', 3}]) = (fun ((_cor0 -| [{'label', 55}])) -> case (_cor0 -| [{'label', 55}]) of (X -| [{'label', 56}]) when 'true' -> call 'erlang':'get_module_info'('eep37', (X -| [{'label', 56}])) (_cor1 -| [{'label', 59}]) when 'true' -> primop 'match_fail'({'function_clause', (_cor1 -| [{'label', 59}])}) end -| [{'label', 64}]) end DICT:[{64,{[any],unit}}, {top,{[],none}}, {19,{[],unit}}, {54,{[],unit}}, {41,{[any],unit}}, {47,{[],unit}}, {13,{[],unit}}] FunType 64:{ok,{[any],unit}} Handling fun {eep37,module_info,1}: fun((_) -> no_return()) Entering 55 :: any() Handling 'case' Handling var Looking up unknown variable: {c_var, [{label,55}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], cor0} Entering 56 :: any() Subst: storing 55 = 56 Binding pat: var to any() Entering 56 :: any() Binding pat: var to any() Binding 55 to 56 Entering 56 :: any() Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal Handling var Looking up unknown variable: {c_var, [{label,56}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], 'X'} -------------------------------------------------------- Fun: {erlang,get_module_info,2} Args: <'eep37',_> NewArgsSig: <'eep37',_> NewArgsContract: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> NewArgsBif: <'eep37',_> NewArgTypes: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> RetWithoutContr: any() RetWithoutLocal: atom() | [{atom(),_} | {atom(),byte(),integer()}] BifRet: any() ContrRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] SigRet: any() NewAccRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] Entering 56 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Map: 55 :: any() Done analyzing: {eep37,module_info,1}:fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) New Entry for {eep37,module_info,1}: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) done adding stuff for {eep37,module_info,1} FunType 19:{ok,{[],unit}} Handling fun {eep37,self,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],unit}} Entering 5 :: fun(() -> no_return()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> no_return())) New Entry for {eep37,self,0}: fun(() -> fun(() -> no_return())) {eep37,self,0}: Will try to add:[13] done adding stuff for {eep37,self,0} FunType 54:{ok,{[],unit}} Handling fun {eep37,module_info,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal -------------------------------------------------------- Fun: {erlang,get_module_info,1} Args: 'eep37' NewArgsSig: 'eep37' NewArgsContract: 'eep37' NewArgsBif: 'eep37' NewArgTypes: 'eep37' RetWithoutContr: any() RetWithoutLocal: [{atom(),[{atom(),_}]}] BifRet: any() ContrRet: [{atom(),[{atom(),_}]}] SigRet: any() NewAccRet: [{atom(),[{atom(),_}]}] Map: Done analyzing: {eep37,module_info,0}:fun(() -> [{atom(),[{atom(),_}]}]) New Entry for {eep37,module_info,0}: fun(() -> [{atom(),[any()]}]) done adding stuff for {eep37,module_info,0} FunType 41:{ok,{[any],unit}} Handling fun 41: fun((_) -> no_return()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) New Entry for 41: fun((_) -> none()) 41: Will try to add:[41,{eep37,fact,0}] done adding stuff for 41 FunType 47:{ok,{[],unit}} Handling fun {eep37,fact,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 41:{ok,{[any],none}} Entering 21 :: fun((_) -> none()) Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Map: Done analyzing: {eep37,fact,0}:fun(() -> fun((_) -> none())) New Entry for {eep37,fact,0}: fun(() -> fun((non_neg_integer()) -> none())) {eep37,fact,0}: Will try to add:[41] done adding stuff for {eep37,fact,0} FunType 13:{ok,{[],unit}} Handling fun 13: fun(() -> no_return()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) New Entry for 13: fun(() -> none()) 13: Will try to add:[{eep37,self,0},13] done adding stuff for 13 FunType 41:{ok,{[any],none}} Handling fun 41: fun((_) -> none()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) Fixpoint for 41: fun((_) -> none()) done adding stuff for 41 FunType 19:{ok,{[],{c,function,[{c,product,[],unknown},unit],unknown}}} Handling fun {eep37,self,0}: fun(() -> fun(() -> no_return())) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],none}} Entering 5 :: fun(() -> none()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> none())) New Entry for {eep37,self,0}: fun(() -> fun(() -> none())) {eep37,self,0}: Will try to add:[13] done adding stuff for {eep37,self,0} FunType 13:{ok,{[],none}} Handling fun 13: fun(() -> none()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) Fixpoint for 13: fun(() -> none()) done adding stuff for 13 module 'eep37' ['fact'/0, 'module_info'/0, 'module_info'/1, 'self'/0] attributes ['spec' = [{{'self', 0}, [{'type', 5, 'fun', [{'type', 5, 'product', []}, {'type', 5, 'fun', [{'type', 5, 'product', []}, {'type', 5, 'fun', []}]}]}]}]] ('self'/0 -| [{'label', 0}]) = (fun () -> case <> of <> when 'true' -> letrec ('Self'/0 -| [{'label', 5}]) = (fun () -> let (Self -| [{'label', 6}]) = ('Self'/0 -| [{'label', 5}]) in case <> of <> when 'true' -> (Self -| [{'label', 6}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 13}]) in ('Self'/0 -| [{'label', 5}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 19}]) ('fact'/0 -| [{'label', 1}]) = (fun () -> case <> of <> when 'true' -> letrec ('Fact'/1 -| [{'label', 21}]) = (fun ((_cor2 -| [{'label', 22}])) -> let (Fact -| [{'label', 23}]) = ('Fact'/1 -| [{'label', 21}]) in case (_cor2 -| [{'label', 22}]) of (N -| [{'label', 24}]) when call 'erlang':'>'((N -| [{'label', 24}]), 0) -> let (_cor0 -| [{'label', 27}]) = call 'erlang':'-'((N -| [{'label', 24}]), 1) in let (_cor1 -| [{'label', 29}]) = apply (Fact -| [{'label', 23}])((_cor0 -| [{'label', 27}])) in call 'erlang':'*'((N -| [{'label', 24}]), (_cor1 -| [{'label', 29}])) 0 when 'true' -> 1 (_cor3 -| [{'label', 35}]) when 'true' -> primop 'match_fail'({'function_clause', (_cor3 -| [{'label', 35}])}) end -| [{'label', 41}]) in ('Fact'/1 -| [{'label', 21}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 47}]) ('module_info'/0 -| [{'label', 2}]) = (fun () -> case <> of <> when 'true' -> call 'erlang':'get_module_info'('eep37') <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 54}]) ('module_info'/1 -| [{'label', 3}]) = (fun ((_cor0 -| [{'label', 55}])) -> case (_cor0 -| [{'label', 55}]) of (X -| [{'label', 56}]) when 'true' -> call 'erlang':'get_module_info'('eep37', (X -| [{'label', 56}])) (_cor1 -| [{'label', 59}]) when 'true' -> primop 'match_fail'({'function_clause', (_cor1 -| [{'label', 59}])}) end -| [{'label', 64}]) end DICT:[{64,{[any],unit}}, {top,{[],none}}, {19,{[],unit}}, {54,{[],unit}}, {41,{[any],unit}}, {47,{[],unit}}, {13,{[],unit}}] FunType 64:{ok,{[any],unit}} Handling fun {eep37,module_info,1}: fun((_) -> no_return()) Entering 55 :: any() Handling 'case' Handling var Looking up unknown variable: {c_var, [{label,55}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], cor0} Entering 56 :: any() Subst: storing 55 = 56 Binding pat: var to any() Entering 56 :: any() Binding pat: var to any() Binding 55 to 56 Entering 56 :: any() Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal Handling var Looking up unknown variable: {c_var, [{label,56}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], 'X'} -------------------------------------------------------- Fun: {erlang,get_module_info,2} Args: <'eep37',_> NewArgsSig: <'eep37',_> NewArgsContract: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> NewArgsBif: <'eep37',_> NewArgTypes: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> RetWithoutContr: any() RetWithoutLocal: atom() | [{atom(),_} | {atom(),byte(),integer()}] BifRet: any() ContrRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] SigRet: any() NewAccRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] Entering 56 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Map: 55 :: any() Done analyzing: {eep37,module_info,1}:fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) New Entry for {eep37,module_info,1}: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) done adding stuff for {eep37,module_info,1} FunType 19:{ok,{[],unit}} Handling fun {eep37,self,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],unit}} Entering 5 :: fun(() -> no_return()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> no_return())) New Entry for {eep37,self,0}: fun(() -> fun(() -> none())) {eep37,self,0}: Will try to add:[13] done adding stuff for {eep37,self,0} FunType 54:{ok,{[],unit}} Handling fun {eep37,module_info,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal -------------------------------------------------------- Fun: {erlang,get_module_info,1} Args: 'eep37' NewArgsSig: 'eep37' NewArgsContract: 'eep37' NewArgsBif: 'eep37' NewArgTypes: 'eep37' RetWithoutContr: any() RetWithoutLocal: [{atom(),[{atom(),_}]}] BifRet: any() ContrRet: [{atom(),[{atom(),_}]}] SigRet: any() NewAccRet: [{atom(),[{atom(),_}]}] Map: Done analyzing: {eep37,module_info,0}:fun(() -> [{atom(),[{atom(),_}]}]) New Entry for {eep37,module_info,0}: fun(() -> [{atom(),[any()]}]) done adding stuff for {eep37,module_info,0} FunType 41:{ok,{[any],unit}} Handling fun 41: fun((_) -> no_return()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) New Entry for 41: fun((_) -> none()) 41: Will try to add:[41,{eep37,fact,0}] done adding stuff for 41 FunType 47:{ok,{[],unit}} Handling fun {eep37,fact,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 41:{ok,{[any],none}} Entering 21 :: fun((_) -> none()) Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Map: Done analyzing: {eep37,fact,0}:fun(() -> fun((_) -> none())) New Entry for {eep37,fact,0}: fun(() -> fun((0) -> none())) {eep37,fact,0}: Will try to add:[41] done adding stuff for {eep37,fact,0} FunType 13:{ok,{[],unit}} Handling fun 13: fun(() -> no_return()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) New Entry for 13: fun(() -> none()) 13: Will try to add:[{eep37,self,0},13] done adding stuff for 13 FunType 41:{ok,{[any],none}} Handling fun 41: fun((_) -> none()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) Fixpoint for 41: fun((_) -> none()) done adding stuff for 41 FunType 19:{ok,{[],{c,function,[{c,product,[],unknown},none],unknown}}} Handling fun {eep37,self,0}: fun(() -> fun(() -> none())) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],none}} Entering 5 :: fun(() -> none()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> none())) Fixpoint for {eep37,self,0}: fun(() -> fun(() -> none())) done adding stuff for {eep37,self,0} FunType 13:{ok,{[],none}} Handling fun 13: fun(() -> none()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) Fixpoint for 13: fun(() -> none()) done adding stuff for 13 module 'eep37' ['fact'/0, 'module_info'/0, 'module_info'/1, 'self'/0] attributes ['spec' = [{{'self', 0}, [{'type', 5, 'fun', [{'type', 5, 'product', []}, {'type', 5, 'fun', [{'type', 5, 'product', []}, {'type', 5, 'fun', []}]}]}]}]] ('self'/0 -| [{'label', 0}]) = (fun () -> case <> of <> when 'true' -> letrec ('Self'/0 -| [{'label', 5}]) = (fun () -> let (Self -| [{'label', 6}]) = ('Self'/0 -| [{'label', 5}]) in case <> of <> when 'true' -> (Self -| [{'label', 6}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 13}]) in ('Self'/0 -| [{'label', 5}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 19}]) ('fact'/0 -| [{'label', 1}]) = (fun () -> case <> of <> when 'true' -> letrec ('Fact'/1 -| [{'label', 21}]) = (fun ((_cor2 -| [{'label', 22}])) -> let (Fact -| [{'label', 23}]) = ('Fact'/1 -| [{'label', 21}]) in case (_cor2 -| [{'label', 22}]) of (N -| [{'label', 24}]) when call 'erlang':'>'((N -| [{'label', 24}]), 0) -> let (_cor0 -| [{'label', 27}]) = call 'erlang':'-'((N -| [{'label', 24}]), 1) in let (_cor1 -| [{'label', 29}]) = apply (Fact -| [{'label', 23}])((_cor0 -| [{'label', 27}])) in call 'erlang':'*'((N -| [{'label', 24}]), (_cor1 -| [{'label', 29}])) 0 when 'true' -> 1 (_cor3 -| [{'label', 35}]) when 'true' -> primop 'match_fail'({'function_clause', (_cor3 -| [{'label', 35}])}) end -| [{'label', 41}]) in ('Fact'/1 -| [{'label', 21}]) <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 47}]) ('module_info'/0 -| [{'label', 2}]) = (fun () -> case <> of <> when 'true' -> call 'erlang':'get_module_info'('eep37') <> when 'true' -> primop 'match_fail'({'function_clause'}) end -| [{'label', 54}]) ('module_info'/1 -| [{'label', 3}]) = (fun ((_cor0 -| [{'label', 55}])) -> case (_cor0 -| [{'label', 55}]) of (X -| [{'label', 56}]) when 'true' -> call 'erlang':'get_module_info'('eep37', (X -| [{'label', 56}])) (_cor1 -| [{'label', 59}]) when 'true' -> primop 'match_fail'({'function_clause', (_cor1 -| [{'label', 59}])}) end -| [{'label', 64}]) end DICT:[{64,{[any],unit}}, {top,{[],none}}, {19,{[],unit}}, {54,{[],unit}}, {41,{[any],unit}}, {47,{[],unit}}, {13,{[],unit}}] FunType 64:{ok,{[any],unit}} Handling fun {eep37,module_info,1}: fun((_) -> no_return()) Entering 55 :: any() Handling 'case' Handling var Looking up unknown variable: {c_var, [{label,55}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], cor0} Entering 56 :: any() Subst: storing 55 = 56 Binding pat: var to any() Entering 56 :: any() Binding pat: var to any() Binding 55 to 56 Entering 56 :: any() Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal Handling var Looking up unknown variable: {c_var, [{label,56}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], 'X'} -------------------------------------------------------- Fun: {erlang,get_module_info,2} Args: <'eep37',_> NewArgsSig: <'eep37',_> NewArgsContract: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> NewArgsBif: <'eep37',_> NewArgTypes: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> RetWithoutContr: any() RetWithoutLocal: atom() | [{atom(),_} | {atom(),byte(),integer()}] BifRet: any() ContrRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] SigRet: any() NewAccRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] Entering 56 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Map: 55 :: any() Done analyzing: {eep37,module_info,1}:fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) New Entry for {eep37,module_info,1}: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) done adding stuff for {eep37,module_info,1} FunType 19:{ok,{[],unit}} Handling fun {eep37,self,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],unit}} Entering 5 :: fun(() -> no_return()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> no_return())) New Entry for {eep37,self,0}: fun(() -> fun(() -> none())) {eep37,self,0}: Will try to add:[13] done adding stuff for {eep37,self,0} FunType 54:{ok,{[],unit}} Handling fun {eep37,module_info,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal -------------------------------------------------------- Fun: {erlang,get_module_info,1} Args: 'eep37' NewArgsSig: 'eep37' NewArgsContract: 'eep37' NewArgsBif: 'eep37' NewArgTypes: 'eep37' RetWithoutContr: any() RetWithoutLocal: [{atom(),[{atom(),_}]}] BifRet: any() ContrRet: [{atom(),[{atom(),_}]}] SigRet: any() NewAccRet: [{atom(),[{atom(),_}]}] Map: Done analyzing: {eep37,module_info,0}:fun(() -> [{atom(),[{atom(),_}]}]) New Entry for {eep37,module_info,0}: fun(() -> [{atom(),[any()]}]) done adding stuff for {eep37,module_info,0} FunType 41:{ok,{[any],unit}} Handling fun 41: fun((_) -> no_return()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) New Entry for 41: fun((_) -> none()) 41: Will try to add:[41,{eep37,fact,0}] done adding stuff for 41 FunType 47:{ok,{[],unit}} Handling fun {eep37,fact,0}: fun(() -> no_return()) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 41:{ok,{[any],none}} Entering 21 :: fun((_) -> none()) Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Map: Done analyzing: {eep37,fact,0}:fun(() -> fun((_) -> none())) New Entry for {eep37,fact,0}: fun(() -> fun((0) -> none())) {eep37,fact,0}: Will try to add:[41] done adding stuff for {eep37,fact,0} FunType 13:{ok,{[],unit}} Handling fun 13: fun(() -> no_return()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) New Entry for 13: fun(() -> none()) 13: Will try to add:[{eep37,self,0},13] done adding stuff for 13 FunType 41:{ok,{[any],none}} Handling fun 41: fun((_) -> none()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) Fixpoint for 41: fun((_) -> none()) done adding stuff for 41 FunType 19:{ok,{[],{c,function,[{c,product,[],unknown},none],unknown}}} Handling fun {eep37,self,0}: fun(() -> fun(() -> none())) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],none}} Entering 5 :: fun(() -> none()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> none())) Fixpoint for {eep37,self,0}: fun(() -> fun(() -> none())) done adding stuff for {eep37,self,0} FunType 13:{ok,{[],none}} Handling fun 13: fun(() -> none()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) Fixpoint for 13: fun(() -> none()) done adding stuff for 13 ========== Starting warning pass ========== FunType top:{ok,{[],none}} Handling fun top: fun(() -> none()) Handling module Handling letrec Handling 'fun' FunType 19:{ok,{[],{c,function,[{c,product,[],unknown},none],unknown}}} Entering 0 :: fun(() -> fun(() -> none())) Handling 'fun' FunType 47:{ok,{[], {c,function, [{c,product,[{c,number,{int_set,[0]},integer}],unknown}, none], unknown}}} Entering 1 :: fun(() -> fun((0) -> none())) Handling 'fun' FunType 54:{ok,{[], {c,list, [{c,tuple, [{c,atom,any,unknown}, {c,list,[any,{c,nil,[],unknown}],unknown}], {2,any}}, {c,nil,[],unknown}], unknown}}} Entering 2 :: fun(() -> [{atom(),[any()]}]) Handling 'fun' FunType 64:{ok,{[any], {c,union, [{c,atom,any,unknown}, none,none,none, {c,list, [{c,tuple_set, [{2,[{c,tuple,[{c,atom,any,unknown},any],{2,any}}]}, {3, [{c,tuple, [{c,atom,any,unknown}, {c,number,{int_rng,0,255},integer}, {c,number,any,integer}], {3,any}}]}], unknown}, {c,nil,[],unknown}], unknown}, none,none,none,none,none], unknown}}} Entering 3 :: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) Handling literal FunType 19:{ok,{[],{c,function,[{c,product,[],unknown},none],unknown}}} FunType 47:{ok,{[], {c,function, [{c,product,[{c,number,{int_set,[0]},integer}],unknown}, none], unknown}}} FunType 54:{ok,{[], {c,list, [{c,tuple, [{c,atom,any,unknown}, {c,list,[any,{c,nil,[],unknown}],unknown}], {2,any}}, {c,nil,[],unknown}], unknown}}} FunType 64:{ok,{[any], {c,union, [{c,atom,any,unknown}, none,none,none, {c,list, [{c,tuple_set, [{2,[{c,tuple,[{c,atom,any,unknown},any],{2,any}}]}, {3, [{c,tuple, [{c,atom,any,unknown}, {c,number,{int_rng,0,255},integer}, {c,number,any,integer}], {3,any}}]}], unknown}, {c,nil,[],unknown}], unknown}, none,none,none,none,none], unknown}}} Entering 0 :: fun(() -> fun(() -> none())) Entering 1 :: fun(() -> fun((0) -> none())) Entering 2 :: fun(() -> [{atom(),[any()]}]) Entering 3 :: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) Done analyzing: top:fun(() -> any()) New Entry for top: fun(() -> any()) done adding stuff for top FunType 64:{ok,{[any], {c,union, [{c,atom,any,unknown}, none,none,none, {c,list, [{c,tuple_set, [{2,[{c,tuple,[{c,atom,any,unknown},any],{2,any}}]}, {3, [{c,tuple, [{c,atom,any,unknown}, {c,number,{int_rng,0,255},integer}, {c,number,any,integer}], {3,any}}]}], unknown}, {c,nil,[],unknown}], unknown}, none,none,none,none,none], unknown}}} Handling fun {eep37,module_info,1}: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) Entering 55 :: any() Handling 'case' Handling var Looking up unknown variable: {c_var, [{label,55}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], cor0} Entering 56 :: any() Subst: storing 55 = 56 Binding pat: var to any() Entering 56 :: any() Binding pat: var to any() Binding 55 to 56 Entering 56 :: any() Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal Handling var Looking up unknown variable: {c_var, [{label,56}, 0, {file, "/Users/nox/src/otp/lib/dialyzer/test/small_SUITE_data/src/eep37.erl"}], 'X'} -------------------------------------------------------- Fun: {erlang,get_module_info,2} Args: <'eep37',_> NewArgsSig: <'eep37',_> NewArgsContract: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> NewArgsBif: <'eep37',_> NewArgTypes: <'eep37','attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses'> RetWithoutContr: any() RetWithoutLocal: atom() | [{atom(),_} | {atom(),byte(),integer()}] BifRet: any() ContrRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] SigRet: any() NewAccRet: atom() | [{atom(),_} | {atom(),byte(),integer()}] Entering 56 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Entering 55 :: 'attributes' | 'compile' | 'exports' | 'functions' | 'imports' | 'module' | 'native_addresses' Map: 55 :: any() Done analyzing: {eep37,module_info,1}:fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) Fixpoint for {eep37,module_info,1}: fun((_) -> atom() | [{atom(),_} | {atom(),byte(),integer()}]) done adding stuff for {eep37,module_info,1} FunType 19:{ok,{[],{c,function,[{c,product,[],unknown},none],unknown}}} Handling fun {eep37,self,0}: fun(() -> fun(() -> none())) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 13:{ok,{[],none}} Entering 5 :: fun(() -> none()) Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Map: Done analyzing: {eep37,self,0}:fun(() -> fun(() -> none())) Fixpoint for {eep37,self,0}: fun(() -> fun(() -> none())) done adding stuff for {eep37,self,0} FunType 54:{ok,{[], {c,list, [{c,tuple, [{c,atom,any,unknown}, {c,list,[any,{c,nil,[],unknown}],unknown}], {2,any}}, {c,nil,[],unknown}], unknown}}} Handling fun {eep37,module_info,0}: fun(() -> [{atom(),[any()]}]) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling call Handling literal Handling literal Handling literal -------------------------------------------------------- Fun: {erlang,get_module_info,1} Args: 'eep37' NewArgsSig: 'eep37' NewArgsContract: 'eep37' NewArgsBif: 'eep37' NewArgTypes: 'eep37' RetWithoutContr: any() RetWithoutLocal: [{atom(),[{atom(),_}]}] BifRet: any() ContrRet: [{atom(),[{atom(),_}]}] SigRet: any() NewAccRet: [{atom(),[{atom(),_}]}] Map: Done analyzing: {eep37,module_info,0}:fun(() -> [{atom(),[{atom(),_}]}]) Fixpoint for {eep37,module_info,0}: fun(() -> [{atom(),[any()]}]) done adding stuff for {eep37,module_info,0} FunType 41:{ok,{[any],none}} Handling fun 41: fun((_) -> none()) Entering 22 :: any() Handling 'let' Subst: storing 23 = 21 Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Done analyzing: 41:fun((_) -> none()) Fixpoint for 41: fun((_) -> none()) done adding stuff for 41 FunType 47:{ok,{[], {c,function, [{c,product,[{c,number,{int_set,[0]},integer}],unknown}, none], unknown}}} Handling fun {eep37,fact,0}: fun(() -> fun((0) -> none())) Handling 'case' Handling values Binding pat: values to <> Handling pos guard: 'true' Handling letrec Handling 'fun' FunType 41:{ok,{[any],none}} Entering 21 :: fun((_) -> none()) Handling var Looking up unknown variable: {c_var,[{label,21}],{'Fact',1}} Map: Done analyzing: {eep37,fact,0}:fun(() -> fun((_) -> none())) Fixpoint for {eep37,fact,0}: fun(() -> fun((0) -> none())) done adding stuff for {eep37,fact,0} FunType 13:{ok,{[],none}} Handling fun 13: fun(() -> none()) Handling 'let' Subst: storing 6 = 5 Handling var Looking up unknown variable: {c_var,[{label,5}],{'Self',0}} Done analyzing: 13:fun(() -> none()) Fixpoint for 13: fun(() -> none()) done adding stuff for 13 eep37.erl:7: The created fun has no local return eep37.erl:11: The created fun has no local return done in 0m0.46s done (warnings were emitted) Regards, -- Anthony Ramine Le 27 oct. 2013 ? 21:29, Anthony Ramine a ?crit : > I?ve added tests for named funs in every place you asked for except syntax_tools. > > The Dialyzer test doesn?t pass and I haven?t found a fix for it yet, Cc?ing Kostis. > > If I give "fact() -> fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end" to typer, the following spec is computed: > > -spec fact() -> fun((0) -> none()). > > Please refetch. > > -- > Anthony Ramine > > Le 23 oct. 2013 ? 15:04, Bj?rn Gustavsson a ?crit : > >> The new test cases are insufficient for an extension of the language. Each >> application that have updates should have test cases to ensure that new or >> updated code is covered. The following applications should have test cases >> for named funs: compiler, tools (xref and cover), stdlib (qlc, erl_eval, ms_transform), >> dialyzer, debugger, and syntax_tools. >> > From robert.virding@REDACTED Tue Oct 29 16:07:17 2013 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 29 Oct 2013 16:07:17 +0100 (CET) Subject: [erlang-patches] [erlang-bugs] Properly handle export_all when looking for undefined callbacks In-Reply-To: <525BA344.9020907@erlang.org> References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> <525BA344.9020907@erlang.org> Message-ID: <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> Sorry I missed this one earlier. Do you mean EVERY callback or just those which haven't been explicitly exported and have been left to the export_all? If it is the latter case then I wouldn't consider this an error. Functions which are meant to be seen on the outside of a module should be explicitly exported, export_all is more a development/debugging hack. IMAO anyway. If it the first case where having an export_all means that no callback is seen then it is a bug. Robert ----- Original Message ----- > From: "Fredrik" > > On 10/12/2013 02:10 PM, Anthony Ramine wrote: > > Hello, > > > > When compiling a behaviour with export_all, every callback is marked as > > missing by erl_lint. This patch fixes this. > > > > Thanks to Michele Miron (Cc'd) for reporting this bug. > > > > git fetch https://github.com/nox/otp.git export_all-behaviour > > > > https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour > > https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour.patch > > > > Regards, > > > Hello Anthony, > I've fetched your patch, applied the correct bootstrap file and assigned > it to be reviewed by responsible developers. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From n.oxyde@REDACTED Tue Oct 29 16:50:20 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Oct 2013 16:50:20 +0100 Subject: [erlang-patches] [erlang-bugs] Properly handle export_all when looking for undefined callbacks In-Reply-To: <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> <525BA344.9020907@erlang.org> <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> Message-ID: <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> export_all means that everything is exported, so seeing a warning about an undefined behaviour callback is quite weird and surprising and confusing. At the very least, the message should be changed when export_all is used, maybe something like "warning: callback is not explicitly exported". I still think this is a bug, you use export_all during development to avoid exporting warnings and/or errors. -- Anthony Ramine Le 29 oct. 2013 ? 16:07, Robert Virding a ?crit : > Sorry I missed this one earlier. Do you mean EVERY callback or just those which haven't been explicitly exported and have been left to the export_all? If it is the latter case then I wouldn't consider this an error. Functions which are meant to be seen on the outside of a module should be explicitly exported, export_all is more a development/debugging hack. IMAO anyway. If it the first case where having an export_all means that no callback is seen then it is a bug. > > Robert > > ----- Original Message ----- >> From: "Fredrik" >> >> On 10/12/2013 02:10 PM, Anthony Ramine wrote: >>> Hello, >>> >>> When compiling a behaviour with export_all, every callback is marked as >>> missing by erl_lint. This patch fixes this. >>> >>> Thanks to Michele Miron (Cc'd) for reporting this bug. >>> >>> git fetch https://github.com/nox/otp.git export_all-behaviour >>> >>> https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour >>> https://github.com/nox/otp/compare/erlang:maint...export_all-behaviour.patch >>> >>> Regards, >>> >> Hello Anthony, >> I've fetched your patch, applied the correct bootstrap file and assigned >> it to be reviewed by responsible developers. >> Thanks, >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> From carlsson.richard@REDACTED Wed Oct 30 13:35:47 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 30 Oct 2013 13:35:47 +0100 Subject: [erlang-patches] Fix serialization problem in xmerl export In-Reply-To: <52457AD3.80405@erlang.org> References: <524570D0.9040605@gmail.com> <52457AD3.80405@erlang.org> Message-ID: <5270FD23.1050402@gmail.com> Ping? /Richard On 2013-09-27 14:32, Fredrik wrote: > On 09/27/2013 01:49 PM, Richard Carlsson wrote: >> The inheritance mechanism in xmerl uses 'catch apply(M,F,Args)' >> to try different modules M until one was found that had a function >> F/A. However, when M:F/A does not exist, apply/3 will trap to >> error_handler:undefined_function/3, which will call >> code:ensure_loaded(M), making a synchronous request to the code >> server process. If many processes tried to use xmerl:export() >> concurrently, they would get serialized waiting for the code server >> process. >> >> This patch uses erlang:function_exported/3 instead to check if M:F/A >> exists. If M exists, it should already have been loaded at that point >> due to the inheritance checking in the xmerl:callbacks/1 function. >> >> git fetch git@REDACTED:richcarl/otp.git >> xmerl-avoid-code-server-serialization >> >> https://github.com/richcarl/otp/tree/xmerl-avoid-code-server-serialization >> >> >> >> /Richard >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello Richard, > I've created a pullrequest for your patch, which you can follow here: > https://github.com/erlang/otp/pull/87 > The patch will be run through initial tests and then be assigned to be > reviewed by responsible developers. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From n.oxyde@REDACTED Thu Oct 31 11:42:32 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 31 Oct 2013 11:42:32 +0100 Subject: [erlang-patches] [erlang-bugs] bug_xmerl_invalid_attribute In-Reply-To: References: Message-ID: <270FE946-A813-426E-ADB1-EB0F4E0BD1BE@gmail.com> I don't understand. What is the bug? That xmerl crashes on malformed input sounds like a feature to me, not a bug. -- Anthony Ramine > Le 31 oct. 2013 ? 05:01, Constantin Malikov a ?crit : > > Hello , friends. I want to tell you about a bug in Erlang: > > I have a trouble with validating xml document by xsd schema in case of > one of the attribute have incorrect record in the xml document. I attached simple sample, where you can see this problem. To run it, compile xml_attribute_test.erl and invoke ?invalid_xml_test? method. > You can see the error message: > _________________________________________________________________ > ** exception error: no function clause matching > xmerl_scan:scan_att_value("a>\n \n \n \n \n \n \n\n", > {xmerl_scanner,undefined,no,prolog,[],undefined,internal, > true,false,false,49173,false,false, > "/home/konstantin/erlang/tasks/diffR15B02/xml_invalid_attribute_test", > undefined,[],file_name_unknown,off,[],preserve, > #Fun,#Fun, > #Fun,#Fun, > #Fun,#Fun, > #Fun,...}, > 'CDATA') (xmerl_scan.erl, line 2343) > in function xmerl_scan:scan_element/12 (xmerl_scan.erl, line 2147) > in call from xmerl_scan:scan_document/2 (xmerl_scan.erl, line 571) > in call from xmerl_scan:string/2 (xmerl_scan.erl, line 287) > in call from xml_attribute_test:read_xml/1 (xml_attribute_test.erl, line 13) > in call from xml_attribute_test:invalid_xml_test/0 (xml_attribute_test.erl, line 17) > ________________________________________________________________ > > How can i see, in the xmerl_scan.erl module, scan_att_value metod. No function for processing incorrect attribute record. > > Tested by Erlang 16B02, xmerl 1.3.4 and R15B02, xmerl 1.3.2. > > _______________________ctx_megaco.xml____________________________ > > > > > > > > > > ________________________________________________________________ > > _________________________ecss_routing.xsd__________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________________________________ > > _______________________xml_attribute_test.erl__________________________ > > -module (xml_attribute_test). > > -export ([ > invalid_xml_test / 0 > ]). > > read_xml (FileName) -> > {ok, Schema} = xmerl_xsd: process_schema ("ecss_routing.xsd"), > {ok, BXml} = file: read_file (FileName), > Xml = erlang: binary_to_list (BXml), > {XmerXml, _} = xmerl_scan: string (Xml), > xmerl_xsd: validate (XmerXml, Schema). > > invalid_xml_test () -> > Result = read_xml ("ctx_megaco.xml"), > io: format ("~ p ~ n", [Result]). > ________________________________________________________________ > > I can offer the option of a patch that fixes this problem. The person who is responsible for supporting ssh has the discretion to take it as it is, or can make own fix. > ________________________________________________________________ > --- xmerl-1.3.2/src/xmerl_scan.erl 2013-10-26 14:25:25.000000000 > +++ xmerl-1.3.2.1/src/xmerl_scan.erl 2013-10-26 13:03:42.000000000 > @@ -2373,13 +2373,16 @@ > scan_att_value([H|T], S0,'CDATA'=AT) when H == $"; H == $' -> > ?bump_col(1), > scan_att_chars(T, S, H, [],[], AT,false); > scan_att_value([H|T], S0,AttType) when H == $"; H == $' -> > ?bump_col(1), > {T1,S1,IsNorm} = normalize(T,S,false), > - scan_att_chars(T1, S1, H, [],[], AttType,IsNorm). > + scan_att_chars(T1, S1, H, [],[], AttType,IsNorm); > +%% EltexPatch: prevent function_clause exception > +scan_att_value([H|_], S0, _AttType) -> > + ?fatal({unexpected_char, H}, S0). > scan_att_chars([],S=#xmerl_scanner{continuation_fun=F},H,Acc,TmpAcc,AT,IsNorm)-> > ?dbg("cont()...~n", []), > F(fun(MoreBytes, S1) -> > scan_att_chars(MoreBytes, S1, H, Acc,TmpAcc,AT,IsNorm) > end, > ________________________________________________________________ > > With best regards, > Malikov Constantin, software developer, Eltex. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From klyr@REDACTED Thu Oct 31 15:00:25 2013 From: klyr@REDACTED (Julien Barbot) Date: Thu, 31 Oct 2013 15:00:25 +0100 Subject: [erlang-patches] SSL Server Name Indication (SNI) client support In-Reply-To: References: Message-ID: Hi, Here is a new attempt to implement SNI (RFC 6066, section 3). This is *only* the client side implementation. The server implementation will come later. There is no API modification, SNI is used if the connection endpoint is a hostname. Comments are welcome. git fetch git://github.com/klyr/otp.git r17_ssl_sni_client https://github.com/klyr/otp/compare/master...r17_ssl_sni_client https://github.com/klyr/otp/compare/master...r17_ssl_sni_client.patch Pending questions are: - how to do an ssl upgrade with sni ? - is an aditional option to ssl:connect needed to explicitly choose an ssl virtual host (like {virtual_host, string()}) ? - is an aditional option to ssl:connect needed to explicitly disable sni ? Regards, -- Julien Barbot From fredrik@REDACTED Thu Oct 31 15:12:07 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 31 Oct 2013 15:12:07 +0100 Subject: [erlang-patches] SSL Server Name Indication (SNI) client support In-Reply-To: References: Message-ID: <52726537.80002@erlang.org> On 10/31/2013 03:00 PM, Julien Barbot wrote: > Hi, > > Here is a new attempt to implement SNI (RFC 6066, section 3). This is > *only* the client side implementation. > > The server implementation will come later. > > There is no API modification, SNI is used if the connection endpoint > is a hostname. > > Comments are welcome. > > git fetch git://github.com/klyr/otp.git r17_ssl_sni_client > > https://github.com/klyr/otp/compare/master...r17_ssl_sni_client > https://github.com/klyr/otp/compare/master...r17_ssl_sni_client.patch > > Pending questions are: > - how to do an ssl upgrade with sni ? > - is an aditional option to ssl:connect needed to explicitly choose an > ssl virtual host (like {virtual_host, string()}) ? > - is an aditional option to ssl:connect needed to explicitly disable sni ? > > Regards, > Hey Julien, I've fetched your patch and assigned it to be reviewed by responsible developers. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From klyr@REDACTED Thu Oct 31 17:47:45 2013 From: klyr@REDACTED (Julien Barbot) Date: Thu, 31 Oct 2013 17:47:45 +0100 Subject: [erlang-patches] SSL, client_preferred_next_protocol option documentation fix Message-ID: Hi, Here is a simple documentation fix for the client_preferred_next_protocol option. git fetch git://github.com/klyr/otp.git fix-ssl-npn-doc-2 https://github.com/klyr/otp/compare/erlang:maint...fix-ssl-npn-doc-2 https://github.com/klyr/otp/compare/erlang:maint...fix-ssl-npn-doc-2.patch Regards, -- Julien Barbot