From n.oxyde@REDACTED Sun Dec 1 13:21:05 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 13:21:05 +0100 Subject: [erlang-patches] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: A PR was created by Henrik, it may as well be announced here?: https://github.com/erlang/otp/pull/150 -- Anthony Ramine Le 16 nov. 2013 ? 13:58, Anthony Ramine a ?crit : > Finally I may have found one. > > Tell me where I should write tests for that and I will add them. > > git fetch https://github.com/nox/otp.git core-clause-subst > > https://github.com/nox/otp/compare/erlang:maint...core-clause-subst > https://github.com/nox/otp/compare/erlang:maint...core-clause-subst.patch > > Regards, > > -- > Anthony Ramine > > Le 16 nov. 2013 ? 13:27, Anthony Ramine a ?crit : > >> Hello, >> >> I have trying to fix a bug for a while without success so I post it here. >> >> t(Bin1) -> >> case Bin1 of >> <<>> -> ok; >> Bin2 -> >> case Bin1 of >> <<0>> -> ok; >> _ -> Bin2 >> end >> end. >> >> In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: >> >> t: function t/1+17: >> Internal consistency check failed - please report this bug. >> Instruction: return >> Error: {match_context,{x,0}}: >> >> Regards, >> >> -- >> Anthony Ramine >> > From n.oxyde@REDACTED Sun Dec 1 13:21:28 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 13:21:28 +0100 Subject: [erlang-patches] [erlang-bugs] Properly let floating-point instructions through in the BEAM compiler In-Reply-To: <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> References: <113A0B03-CADF-4F17-AC28-B51B80C37DFA@gmail.com> <77C0BAA2-632D-4C45-B79C-845109FE66C0@gmail.com> Message-ID: <9FA43EB6-559F-49B4-9971-07F70AC3E9DA@gmail.com> PR created by Henrik: https://github.com/erlang/otp/pull/152 -- Anthony Ramine Le 18 nov. 2013 ? 13:41, Anthony Ramine a ?crit : > I owe you a beer for that tip, I should have thought to grep for no_postopt in the code. > > I have just found another discrepancy with regard to allocate and init by recompiling sofs. > > -- > Anthony Ramine > > Le 18 nov. 2013 ? 12:58, Bj?rn Gustavsson a ?crit : > >> Suggestion: Include the following one-line change in your patch and >> fix the remaining problems: > From n.oxyde@REDACTED Sun Dec 1 13:46:08 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 13:46:08 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: Amended with your fixup and some covering code for functions named with "_" in xref_SUITE. Please refetch. -- Anthony Ramine Le 28 nov. 2013 ? 13:52, Anthony Ramine a ?crit : > Hello Bj?rn, > > Replied inline. > > -- > Anthony Ramine > > Le 28 nov. 2013 ? 13:44, Bj?rn Gustavsson a ?crit : > >> On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine wrote: >> This patch implements EEP37: Funs with names >> >> >> It is now much closer to being graduated. >> >> I have added the branch to our daily builds for the master branch. > > Cool. > >> I would like a comment from Kostis about the Dialyzer changes. > > Me too, he suggested to me that it might break HiPE too but I couldn?t make HiPE crash. > >> What also remains is coverage in test suites. I have fixed a few, >> but xref_SUITE remains to be fixed (a named fun with the '_' name >> should be tested). > > Will do. > >> Here are my fixes for the test suites (also included as an attachment >> to make it easier to apply): > > Will apply. > >> diff --git a/lib/compiler/test/fun_SUITE.erl b/lib/compiler/test/fun_SUITE.erl >> index 0ff846e..e35692e 100644 >> --- a/lib/compiler/test/fun_SUITE.erl >> +++ b/lib/compiler/test/fun_SUITE.erl >> @@ -197,10 +197,14 @@ external(Config) when is_list(Config) -> >> call_me(I) -> >> {ok,I}. >> >> -id(I) -> >> - I. >> - >> eep37(Config) when is_list(Config) -> >> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, >> + Add = fun _(N) -> N + 1 end, >> + UnusedName = fun BlackAdder(N) -> N + 42 end, >> 720 = F(6), >> + 10 = Add(9), >> + 50 = UnusedName(8), >> ok. >> + >> +id(I) -> >> + I. >> diff --git a/lib/debugger/test/fun_SUITE.erl b/lib/debugger/test/fun_SUITE.erl >> index 569af6c..75e3b55 100644 >> --- a/lib/debugger/test/fun_SUITE.erl >> +++ b/lib/debugger/test/fun_SUITE.erl >> @@ -288,10 +288,14 @@ external(Config) when is_list(Config) -> >> call_me(I) -> >> {ok,I}. >> >> -id(I) -> >> - I. >> - >> eep37(Config) when is_list(Config) -> >> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, >> + Add = fun _(N) -> N + 1 end, >> + UnusedName = fun BlackAdder(N) -> N + 42 end, >> 720 = F(6), >> + 10 = Add(9), >> + 50 = UnusedName(8), >> ok. >> + >> +id(I) -> >> + I. >> diff --git a/lib/stdlib/test/erl_lint_SUITE.erl b/lib/stdlib/test/erl_lint_SUITE.erl >> index ea90793..ad51bfa 100644 >> --- a/lib/stdlib/test/erl_lint_SUITE.erl >> +++ b/lib/stdlib/test/erl_lint_SUITE.erl >> @@ -644,7 +644,9 @@ unused_vars_warn_fun(Config) when is_list(Config) -> >> u() -> >> fun U(U) -> foo end; % U shadowed. U unused. >> u() -> >> - fun U(1) -> U; U(U) -> foo end. % U shadowed. U unused. >> + fun U(1) -> U; U(U) -> foo end; % U shadowed. U unused. >> + u() -> >> + fun _(N) -> N + 1 end. % Cover handling of '_' name. >> ">>, >> [warn_unused_vars], >> {error,[{3,erl_lint,{unbound_var,'U'}}], >> >> >> id/1 is a common help function, so I want it to remain at the end >> of the file. > > Thanks for nitpicking even more than myself :p > >> /Bjorn From n.oxyde@REDACTED Sun Dec 1 14:37:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 14:37:35 +0100 Subject: [erlang-patches] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: <64A693D8-EA9C-4E1E-9A1D-82ED07384434@gmail.com> Amended the commit to fix a bug when folding over receive clauses. Please refetch. -- Anthony Ramine Le 1 d?c. 2013 ? 13:21, Anthony Ramine a ?crit : > A PR was created by Henrik, it may as well be announced here?: > > https://github.com/erlang/otp/pull/150 > > -- > Anthony Ramine > > Le 16 nov. 2013 ? 13:58, Anthony Ramine a ?crit : > >> Finally I may have found one. >> >> Tell me where I should write tests for that and I will add them. >> >> git fetch https://github.com/nox/otp.git core-clause-subst >> >> https://github.com/nox/otp/compare/erlang:maint...core-clause-subst >> https://github.com/nox/otp/compare/erlang:maint...core-clause-subst.patch >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 16 nov. 2013 ? 13:27, Anthony Ramine a ?crit : >> >>> Hello, >>> >>> I have trying to fix a bug for a while without success so I post it here. >>> >>> t(Bin1) -> >>> case Bin1 of >>> <<>> -> ok; >>> Bin2 -> >>> case Bin1 of >>> <<0>> -> ok; >>> _ -> Bin2 >>> end >>> end. >>> >>> In the following function, sys_core_fold fails to see that Bin2 is an alias of Bin1 and does not emit a bs_context_to_binary, making beam_validator crash quite violently: >>> >>> t: function t/1+17: >>> Internal consistency check failed - please report this bug. >>> Instruction: return >>> Error: {match_context,{x,0}}: >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >> > From n.oxyde@REDACTED Sun Dec 1 14:48:42 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 1 Dec 2013 14:48:42 +0100 Subject: [erlang-patches] [erlang-bugs] Properly handle export_all when looking for undefined callbacks In-Reply-To: <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> <525BA344.9020907@erlang.org> <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> Message-ID: Ping? -- Anthony Ramine Le 29 oct. 2013 ? 16:50, Anthony Ramine a ?crit : > 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 henrik@REDACTED Mon Dec 2 08:53:43 2013 From: henrik@REDACTED (Henrik Nord) Date: Mon, 2 Dec 2013 08:53:43 +0100 Subject: [erlang-patches] [erlang-bugs] Properly handle export_all when looking for undefined callbacks In-Reply-To: References: <0610605E-ABED-4CA9-BA88-73A3014D131A@gmail.com> <525BA344.9020907@erlang.org> <1028606425.371940.1383059237855.JavaMail.zimbra@erlang-solutions.com> <551C7602-F33A-4149-A88E-9DAF17987262@gmail.com> Message-ID: <529C3C87.5080208@erlang.org> We are currently reviewing this patch, and it is under some discussion here. /Henrik On 2013-12-01 14:48, Anthony Ramine wrote: > Ping? > -- /Henrik Nord Erlang/OTP From francesco.lattanzio@REDACTED Mon Dec 2 09:01:25 2013 From: francesco.lattanzio@REDACTED (Francesco Lattanzio) Date: Mon, 2 Dec 2013 09:01:25 +0100 Subject: [erlang-patches] Improving ETS performances In-Reply-To: <5298B136.7040608@erix.ericsson.se> References: <20130910102235.GA4812@wagner.intra.a-tono.com> <5298B136.7040608@erix.ericsson.se> Message-ID: <20131202080125.GA647@wagner.intra.a-tono.com> Thank you for the reply and the tips. This was really a proof-of-concept patch, made just to hear from you if you were interested in it -- so optimising things was not a pressing issue. The code in the "erl_db_hash.[ch]" is getting too convoluted for me to tollerate and adding more checks to minimize memory consumption would make things worse. Thus I was thinking to split those files in two: one for the 'set' type and the other for the 'bag' and 'duplicate_bag' types. I suppose that increasing code size is not an issue as it is increasing memory consuption. At the moment I'm working on something else and don't know when I can start working on this patch again -- maybe a few weeks, maybe a couple of months. Regards. On Fri, Nov 29, 2013 at 04:22:30PM +0100, Sverker Eriksson wrote: > Hi > > This patch has now been discussed by OTP technical board. > > It's a desirable feature but the patch is not acceptable as-is, > mainly due to too large memory overhead per object. > > We would need > > * No extra overhead for table type 'set'. > * Minimized overhead per object for 'bag' and 'duplicate_bag', > especially when the nested hash feature is not used. > > Another weakness is the lack of yielding when long key chains are > traversed. BIFs should not execute too long but rather yield by > returning back to the emulator loop to be continued later by the > scheduler (as is done by the ets:select operations). > The patch removes this problem for unrelated keys but it still arise > at lookup/delete on a lot of objects with same key. > If an otherwise accepted patch is supplied we can undertake the job > to fix the yielding. It can be good to have in mind though while doing > the design. > > > > Some tips and tricks to minimize memory overhead: > (some of them are probably mutually exclusive) > > * Use lower bits in pointers as flags. > * Combine next and kprevious as only one of them is used. > * Move nkitems and lht into a separate root struct that is allocated > when the first duplicate key is inserted. > * Move knext and kprevious to NestedDbTerm to only allocate them when > needed. > * Use really dirty trick to allocate a mutilated struct with an unused > prologue. > > > typedef struct { > HashDbTerm* previous; /* NOT ACCESSABLE FOR SET */ > HashDbTerm* next; > HashValue hvalue; > DbTerm dbterm; > }HashDbTerm; > > /* For bags */ > ptr = malloc(sizeof(HashDbTerm)); > > /* For sets */ > ptr = malloc(sizeof(HashDbTerm) - offsetof(HashDbTerm,next)); > ptr = (char*)ptr - offsetof(HashDbTerm,next); > > ptr->next = ...; > ptr->hvalue = ...; > ptr->dbterm = ...; > > ptr->previous = NULL; /* MEMORY CORRUPTION!!! */ > > free((char*)ptr + offsetof(HashDbTerm,next)); > > > Maybe there are more sensible ways to accomplish the same thing. -- FRANCESCO LATTANZIO : SYSTEM & SOFTWARE A-TONO TECHNOLOGY : VIA DEL CHIESINO, 10 - 56025 PONTEDERA (PI) : T +39 02 32069100 : SKYPE franz.lattanzio a-tono.com : twitter.com/ATonoOfficial : facebook.com/ATonoOfficial Information in this email is confidential and may be privileged. It is intended for the addresses only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its content to anyone. Thank you for your co-operation. From henrik@REDACTED Mon Dec 2 09:11:00 2013 From: henrik@REDACTED (Henrik Nord) Date: Mon, 2 Dec 2013 09:11:00 +0100 Subject: [erlang-patches] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: <64A693D8-EA9C-4E1E-9A1D-82ED07384434@gmail.com> References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> <64A693D8-EA9C-4E1E-9A1D-82ED07384434@gmail.com> Message-ID: <529C4094.4070906@erlang.org> Thanks you for that, and for announcing on list. On 2013-12-01 14:37, Anthony Ramine wrote: > Amended the commit to fix a bug when folding over receive clauses. > > Please refetch. > -- /Henrik Nord Erlang/OTP From bgustavsson@REDACTED Mon Dec 2 12:53:25 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 2 Dec 2013 12:53:25 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: On Sun, Dec 1, 2013 at 1:46 PM, Anthony Ramine wrote: > Amended with your fixup and some covering code for functions named with > "_" in xref_SUITE. > > Please refetch. > > Thanks, refetched. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Dec 2 13:15:35 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 2 Dec 2013 16:15:35 +0400 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: Hi, Bj?rn. Are there any considerations against this feature? It is really very good feature that will help to reduce lot of code that deals with local recursion. On Mon, Dec 2, 2013 at 3:53 PM, Bj?rn Gustavsson wrote: > > On Sun, Dec 1, 2013 at 1:46 PM, Anthony Ramine wrote: > >> Amended with your fixup and some covering code for functions named with >> "_" in xref_SUITE. >> >> Please refetch. >> >> Thanks, refetched. > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _______________________________________________ > 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 Mon Dec 2 14:03:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 2 Dec 2013 14:03:03 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: <5CC762CA-ED8D-442D-9492-3706D7B6C26C@gmail.com> It is just a big feature that requires lot of reviewing. -- Anthony Ramine Le 2 d?c. 2013 ? 13:15, Max Lapshin a ?crit : > Hi, Bj?rn. > > Are there any considerations against this feature? It is really very good feature that will help to reduce lot of code that deals with local recursion. > > > > On Mon, Dec 2, 2013 at 3:53 PM, Bj?rn Gustavsson wrote: > > On Sun, Dec 1, 2013 at 1:46 PM, Anthony Ramine wrote: > Amended with your fixup and some covering code for functions named with "_" in xref_SUITE. > > Please refetch. > > Thanks, refetched. > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From bgustavsson@REDACTED Mon Dec 2 14:22:22 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 2 Dec 2013 14:22:22 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: On Mon, Dec 2, 2013 at 1:15 PM, Max Lapshin wrote: > Hi, Bj?rn. > > Are there any considerations against this feature? It is really very good > feature that will help to reduce lot of code that deals with local > recursion. > > > > Our intention is to include in R17. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Wed Dec 4 08:44:39 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 4 Dec 2013 08:44:39 +0100 Subject: [erlang-patches] compile: asm and core options Message-ID: Implement the suggestions I made in http://erlang.org/pipermail/erlang-questions/2013-August/075161.html: * compile(3): stop declaring 'asm' as "for internal debugging use" * compile:file/2: implement 'core' option * compile_SUITE: test 'asm' https://github.com/erlang/otp/pull/154 https://github.com/erlang/otp/pull/154.patch git fetch git://github.com/tuncer/otp.git asm-core From n.oxyde@REDACTED Wed Dec 4 10:09:09 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 4 Dec 2013 10:09:09 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: Message-ID: I would rather document 'from_asm' and 'from_core' than add ?core?, we already have ?to_asm? and ?to_core?. -- Anthony Ramine Le 4 d?c. 2013 ? 08:44, Tuncer Ayaz a ?crit : > Implement the suggestions I made in > http://erlang.org/pipermail/erlang-questions/2013-August/075161.html: > > * compile(3): stop declaring 'asm' as "for internal debugging use" > * compile:file/2: implement 'core' option > * compile_SUITE: test 'asm' > > https://github.com/erlang/otp/pull/154 > https://github.com/erlang/otp/pull/154.patch > git fetch git://github.com/tuncer/otp.git asm-core > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From tuncer.ayaz@REDACTED Wed Dec 4 11:09:53 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 4 Dec 2013 11:09:53 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: Message-ID: On Wed, Dec 4, 2013 at 10:09 AM, Anthony Ramine wrote: > I would rather document 'from_asm' and 'from_core' than add ?core?, > we already have ?to_asm? and ?to_core?. We already have 'asm' (mapping to 'from_asm') implemented and documented as an option for compile:file/2. Therefore, I added 'core'. I think this makes more sense given the existing docs and implementation. > Le 4 d?c. 2013 ? 08:44, Tuncer Ayaz a ?crit : > >> Implement the suggestions I made in >> http://erlang.org/pipermail/erlang-questions/2013-August/075161.html: >> >> * compile(3): stop declaring 'asm' as "for internal debugging use" >> * compile:file/2: implement 'core' option >> * compile_SUITE: test 'asm' >> >> https://github.com/erlang/otp/pull/154 >> https://github.com/erlang/otp/pull/154.patch >> git fetch git://github.com/tuncer/otp.git asm-core From Andrew.Caruth@REDACTED Wed Dec 4 15:38:13 2013 From: Andrew.Caruth@REDACTED (Andrew Caruth) Date: Wed, 4 Dec 2013 14:38:13 +0000 Subject: [erlang-patches] Fix spec for cpu_sup:util/1 Message-ID: <1fb41668f5e8478398b8e62f3adcfd21@DB3PR03MB315.eurprd03.prod.outlook.com> Hi OTP devs, I recently noticed dialyzer was flagging an issue in one of our own modules that was making a call to cpu_sup:util([detailed]). An 'is_list()' guard test was performed on the second element of the tuple returned which dialyzer was reporting as a test that could never succeed. Sample output from a call to cpu_sup:util([detailed]): {[0], [{soft_irq,0.0}, {hard_irq,0.0}, {kernel,0.41368935690109065}, {nice_user,0.0}, {user,0.9402030838661151}], [{steal,0.0},{idle,98.64610755923279},{wait,0.0}], []} The spec implied {'all' | integer | list, tuple | float, tuple | float, []}, which excludes the above output, so I've updated the spec to allow the second and third elements as lists. Also, the atoms 'soft_irq', 'hard_irq', and 'steal' were also not part of the spec, so I've also added those. git fetch git://github.com/acaruth/otp.git cpu_sup_spec_fix https://github.com/acaruth/otp/compare/erlang:maint...cpu_sup_spec_fix https://github.com/acaruth/otp/compare/erlang:maint...cpu_sup_spec_fix.patch Thanks, Andrew Caruth From kostis@REDACTED Wed Dec 4 15:57:00 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 04 Dec 2013 15:57:00 +0100 Subject: [erlang-patches] Fix spec for cpu_sup:util/1 In-Reply-To: <1fb41668f5e8478398b8e62f3adcfd21@DB3PR03MB315.eurprd03.prod.outlook.com> References: <1fb41668f5e8478398b8e62f3adcfd21@DB3PR03MB315.eurprd03.prod.outlook.com> Message-ID: <529F42BC.6040809@cs.ntua.gr> On 12/04/2013 03:38 PM, Andrew Caruth wrote: > Hi OTP devs, > > I recently noticed dialyzer was flagging an issue in one of our own modules that was making a call to cpu_sup:util([detailed]). An 'is_list()' guard test was performed on the second element of the tuple returned which dialyzer was reporting as a test that could never succeed. Sample output from a call to cpu_sup:util([detailed]): > > {[0], > [{soft_irq,0.0}, > {hard_irq,0.0}, > {kernel,0.41368935690109065}, > {nice_user,0.0}, > {user,0.9402030838661151}], > [{steal,0.0},{idle,98.64610755923279},{wait,0.0}], > []} > > The spec implied {'all' | integer | list, tuple | float, tuple | float, []}, which excludes the above output, so I've updated the spec to allow the second and third elements as lists. > > Also, the atoms 'soft_irq', 'hard_irq', and 'steal' were also not part of the spec, so I've also added those. I do not want to comment on the particular patch, but only to point out that this a more general problem. Often, there are good reasons for implementations of built-in of library functions to contain *more* functionality than what the fine manual describes (e.g. to have some experimental features or interfaces that are not cast in stone yet). I think it's a good idea that the specs and the manual always agree with each other. In fact, I think that the manual of library modules should ideally be produced by what's in their code. All the above imply that dialyzer, which is based on specs, may be less forgiving than the actual implementation, and there are very good reasons for it to behave so: It warns you that you are relying on some undocumented (and likely to disappear) feature of the current implementation. Kostis From Andrew.Caruth@REDACTED Wed Dec 4 17:23:24 2013 From: Andrew.Caruth@REDACTED (Andrew Caruth) Date: Wed, 4 Dec 2013 16:23:24 +0000 Subject: [erlang-patches] [erlang-questions] Fix spec for cpu_sup:util/1 In-Reply-To: <529F42BC.6040809@cs.ntua.gr> References: <1fb41668f5e8478398b8e62f3adcfd21@DB3PR03MB315.eurprd03.prod.outlook.com> <529F42BC.6040809@cs.ntua.gr> Message-ID: Hi Kostis, Thanks for taking a look at that! I definitely agree that the ideal is the documentation of library functions should ultimately come from the code. Otherwise either the spec/documentation is misleading, or the code is misleading. Also, as you point out, the fact that dialyzer flags an error is a potential warning sign that the module is either incomplete, undergoing some changes, is potentially no longer properly supported, or simply contains bugs. Though, upon the completion of a release of a particular version of a library, is that not the point at which the functionality is cast in stone as it were? In general the OTP specs and documentation are excellent. Thanks, Andrew -----Original Message----- From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Kostis Sagonas Sent: 04 December 2013 14:57 To: erlang-patches@REDACTED Cc: Erlang Subject: Re: [erlang-questions] [erlang-patches] Fix spec for cpu_sup:util/1 On 12/04/2013 03:38 PM, Andrew Caruth wrote: > Hi OTP devs, > > I recently noticed dialyzer was flagging an issue in one of our own modules that was making a call to cpu_sup:util([detailed]). An 'is_list()' guard test was performed on the second element of the tuple returned which dialyzer was reporting as a test that could never succeed. Sample output from a call to cpu_sup:util([detailed]): > > {[0], > [{soft_irq,0.0}, > {hard_irq,0.0}, > {kernel,0.41368935690109065}, > {nice_user,0.0}, > {user,0.9402030838661151}], > [{steal,0.0},{idle,98.64610755923279},{wait,0.0}], > []} > > The spec implied {'all' | integer | list, tuple | float, tuple | float, []}, which excludes the above output, so I've updated the spec to allow the second and third elements as lists. > > Also, the atoms 'soft_irq', 'hard_irq', and 'steal' were also not part of the spec, so I've also added those. I do not want to comment on the particular patch, but only to point out that this a more general problem. Often, there are good reasons for implementations of built-in of library functions to contain *more* functionality than what the fine manual describes (e.g. to have some experimental features or interfaces that are not cast in stone yet). I think it's a good idea that the specs and the manual always agree with each other. In fact, I think that the manual of library modules should ideally be produced by what's in their code. All the above imply that dialyzer, which is based on specs, may be less forgiving than the actual implementation, and there are very good reasons for it to behave so: It warns you that you are relying on some undocumented (and likely to disappear) feature of the current implementation. Kostis _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions From tuncer.ayaz@REDACTED Thu Dec 5 09:54:41 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 5 Dec 2013 09:54:41 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: Message-ID: On Wed, Dec 4, 2013 at 11:09 AM, Tuncer Ayaz wrote: > On Wed, Dec 4, 2013 at 10:09 AM, Anthony Ramine wrote: >> I would rather document 'from_asm' and 'from_core' than add ?core?, >> we already have ?to_asm? and ?to_core?. > > We already have 'asm' (mapping to 'from_asm') implemented and > documented as an option for compile:file/2. Therefore, I added 'core'. > I think this makes more sense given the existing docs and > implementation. Anthony, after some pondering, I agree that it's important to document 'from_asm' and 'from_core'. But, we need to do both - add 'core' and document 'from_asm' and 'from_core'. If this gets accepted, it will be safe to rely on the options. The branch has been updated accordingly. From bgustavsson@REDACTED Thu Dec 5 12:16:44 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 5 Dec 2013 12:16:44 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: Could you rebase the branch on master? On Sun, Dec 1, 2013 at 1:46 PM, Anthony Ramine wrote: > Amended with your fixup and some covering code for functions named with > "_" in xref_SUITE. > > Please refetch. > > -- > Anthony Ramine > > Le 28 nov. 2013 ? 13:52, Anthony Ramine a ?crit : > > > Hello Bj?rn, > > > > Replied inline. > > > > -- > > Anthony Ramine > > > > Le 28 nov. 2013 ? 13:44, Bj?rn Gustavsson a > ?crit : > > > >> On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine > wrote: > >> This patch implements EEP37: Funs with names > >> > >> > >> It is now much closer to being graduated. > >> > >> I have added the branch to our daily builds for the master branch. > > > > Cool. > > > >> I would like a comment from Kostis about the Dialyzer changes. > > > > Me too, he suggested to me that it might break HiPE too but I couldn?t > make HiPE crash. > > > >> What also remains is coverage in test suites. I have fixed a few, > >> but xref_SUITE remains to be fixed (a named fun with the '_' name > >> should be tested). > > > > Will do. > > > >> Here are my fixes for the test suites (also included as an attachment > >> to make it easier to apply): > > > > Will apply. > > > >> diff --git a/lib/compiler/test/fun_SUITE.erl > b/lib/compiler/test/fun_SUITE.erl > >> index 0ff846e..e35692e 100644 > >> --- a/lib/compiler/test/fun_SUITE.erl > >> +++ b/lib/compiler/test/fun_SUITE.erl > >> @@ -197,10 +197,14 @@ external(Config) when is_list(Config) -> > >> call_me(I) -> > >> {ok,I}. > >> > >> -id(I) -> > >> - I. > >> - > >> eep37(Config) when is_list(Config) -> > >> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, > >> + Add = fun _(N) -> N + 1 end, > >> + UnusedName = fun BlackAdder(N) -> N + 42 end, > >> 720 = F(6), > >> + 10 = Add(9), > >> + 50 = UnusedName(8), > >> ok. > >> + > >> +id(I) -> > >> + I. > >> diff --git a/lib/debugger/test/fun_SUITE.erl > b/lib/debugger/test/fun_SUITE.erl > >> index 569af6c..75e3b55 100644 > >> --- a/lib/debugger/test/fun_SUITE.erl > >> +++ b/lib/debugger/test/fun_SUITE.erl > >> @@ -288,10 +288,14 @@ external(Config) when is_list(Config) -> > >> call_me(I) -> > >> {ok,I}. > >> > >> -id(I) -> > >> - I. > >> - > >> eep37(Config) when is_list(Config) -> > >> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, > >> + Add = fun _(N) -> N + 1 end, > >> + UnusedName = fun BlackAdder(N) -> N + 42 end, > >> 720 = F(6), > >> + 10 = Add(9), > >> + 50 = UnusedName(8), > >> ok. > >> + > >> +id(I) -> > >> + I. > >> diff --git a/lib/stdlib/test/erl_lint_SUITE.erl > b/lib/stdlib/test/erl_lint_SUITE.erl > >> index ea90793..ad51bfa 100644 > >> --- a/lib/stdlib/test/erl_lint_SUITE.erl > >> +++ b/lib/stdlib/test/erl_lint_SUITE.erl > >> @@ -644,7 +644,9 @@ unused_vars_warn_fun(Config) when is_list(Config) -> > >> u() -> > >> fun U(U) -> foo end; % U shadowed. U unused. > >> u() -> > >> - fun U(1) -> U; U(U) -> foo end. % U shadowed. U > unused. > >> + fun U(1) -> U; U(U) -> foo end; % U shadowed. U > unused. > >> + u() -> > >> + fun _(N) -> N + 1 end. % Cover handling of '_' name. > >> ">>, > >> [warn_unused_vars], > >> {error,[{3,erl_lint,{unbound_var,'U'}}], > >> > >> > >> id/1 is a common help function, so I want it to remain at the end > >> of the file. > > > > Thanks for nitpicking even more than myself :p > > > >> /Bjorn > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Dec 5 13:16:18 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 5 Dec 2013 13:16:18 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: Done. Please don?t ask me this again, the two bootstrap commits in the middle of the branch are a pain to rebase :p Regards, -- Anthony Ramine Le 5 d?c. 2013 ? 12:16, Bj?rn Gustavsson a ?crit : > Could you rebase the branch on master? > > > > On Sun, Dec 1, 2013 at 1:46 PM, Anthony Ramine wrote: > Amended with your fixup and some covering code for functions named with "_" in xref_SUITE. > > Please refetch. > > -- > Anthony Ramine > > Le 28 nov. 2013 ? 13:52, Anthony Ramine a ?crit : > > > Hello Bj?rn, > > > > Replied inline. > > > > -- > > Anthony Ramine > > > > Le 28 nov. 2013 ? 13:44, Bj?rn Gustavsson a ?crit : > > > >> On Wed, Nov 14, 2012 at 5:42 PM, Anthony Ramine wrote: > >> This patch implements EEP37: Funs with names > >> > >> > >> It is now much closer to being graduated. > >> > >> I have added the branch to our daily builds for the master branch. > > > > Cool. > > > >> I would like a comment from Kostis about the Dialyzer changes. > > > > Me too, he suggested to me that it might break HiPE too but I couldn?t make HiPE crash. > > > >> What also remains is coverage in test suites. I have fixed a few, > >> but xref_SUITE remains to be fixed (a named fun with the '_' name > >> should be tested). > > > > Will do. > > > >> Here are my fixes for the test suites (also included as an attachment > >> to make it easier to apply): > > > > Will apply. > > > >> diff --git a/lib/compiler/test/fun_SUITE.erl b/lib/compiler/test/fun_SUITE.erl > >> index 0ff846e..e35692e 100644 > >> --- a/lib/compiler/test/fun_SUITE.erl > >> +++ b/lib/compiler/test/fun_SUITE.erl > >> @@ -197,10 +197,14 @@ external(Config) when is_list(Config) -> > >> call_me(I) -> > >> {ok,I}. > >> > >> -id(I) -> > >> - I. > >> - > >> eep37(Config) when is_list(Config) -> > >> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, > >> + Add = fun _(N) -> N + 1 end, > >> + UnusedName = fun BlackAdder(N) -> N + 42 end, > >> 720 = F(6), > >> + 10 = Add(9), > >> + 50 = UnusedName(8), > >> ok. > >> + > >> +id(I) -> > >> + I. > >> diff --git a/lib/debugger/test/fun_SUITE.erl b/lib/debugger/test/fun_SUITE.erl > >> index 569af6c..75e3b55 100644 > >> --- a/lib/debugger/test/fun_SUITE.erl > >> +++ b/lib/debugger/test/fun_SUITE.erl > >> @@ -288,10 +288,14 @@ external(Config) when is_list(Config) -> > >> call_me(I) -> > >> {ok,I}. > >> > >> -id(I) -> > >> - I. > >> - > >> eep37(Config) when is_list(Config) -> > >> F = fun Fact(N) when N > 0 -> N * Fact(N - 1); Fact(0) -> 1 end, > >> + Add = fun _(N) -> N + 1 end, > >> + UnusedName = fun BlackAdder(N) -> N + 42 end, > >> 720 = F(6), > >> + 10 = Add(9), > >> + 50 = UnusedName(8), > >> ok. > >> + > >> +id(I) -> > >> + I. > >> diff --git a/lib/stdlib/test/erl_lint_SUITE.erl b/lib/stdlib/test/erl_lint_SUITE.erl > >> index ea90793..ad51bfa 100644 > >> --- a/lib/stdlib/test/erl_lint_SUITE.erl > >> +++ b/lib/stdlib/test/erl_lint_SUITE.erl > >> @@ -644,7 +644,9 @@ unused_vars_warn_fun(Config) when is_list(Config) -> > >> u() -> > >> fun U(U) -> foo end; % U shadowed. U unused. > >> u() -> > >> - fun U(1) -> U; U(U) -> foo end. % U shadowed. U unused. > >> + fun U(1) -> U; U(U) -> foo end; % U shadowed. U unused. > >> + u() -> > >> + fun _(N) -> N + 1 end. % Cover handling of '_' name. > >> ">>, > >> [warn_unused_vars], > >> {error,[{3,erl_lint,{unbound_var,'U'}}], > >> > >> > >> id/1 is a common help function, so I want it to remain at the end > >> of the file. > > > > Thanks for nitpicking even more than myself :p > > > >> /Bjorn > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From yura.beznos@REDACTED Thu Dec 5 13:32:38 2013 From: yura.beznos@REDACTED (Yura Beznos) Date: Thu, 5 Dec 2013 16:32:38 +0400 Subject: [erlang-patches] crypto: Add IGE mode for AES In-Reply-To: References: <51FA1A44.4060401@erlang.org> <520A29FA.9080602@erix.ericsson.se> Message-ID: Hey, hello! I can see my patch (IGE mode for AES / aes_ige_crypt) as graduated on site http://www.erlang.org/development/ in "master" not in some release and I can't find my code in otp repository. Is it error or something? On Wed, Nov 13, 2013 at 6:01 PM, Yura Beznos wrote: > Hello! > > The patch isn't graduated ? (IGE mode for AES) > > > On Tue, Aug 13, 2013 at 11:31 PM, Yura Beznos wrote: > >> >> On Tue, Aug 13, 2013 at 4:43 PM, Sverker Eriksson < >> sverker.eriksson@REDACTED> wrote: >> >>> Fredrik wrote: >>> >>>> On 08/01/2013 07:40 AM, Yura Beznos wrote: >>>> >>>>> Hello, >>>>> >>>>> I'd like to submit this patch to add two new functions to the crypt >>>>> library. >>>>> >>>>> Repo branch: https://github.com/Zhiz0id/otp/tree/aes_ige_crypt >>>>> Compare: >>>>> https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt >>>>> >>>>> Why this new feature? >>>>> >>>>> It allows to use OpenSSL aes_ige_encrypt function. >>>>> >>>>> Risks / uncertain artifacts >>>>> >>>>> None. >>>>> >>>>> How did you solve it? >>>>> >>>>> Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt . >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> -- >>>>> Yura >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>> >>>> Hello Yura, >>>> I've assigned this patch to be reviewed by responsible, you will get >>>> feedback as soon as this is done. >>>> Thanks, >>>> >>> >>> Looks good, Yura. Two objections though: >>> >>> 1. Do not export the aes_ige_256_encrypt/decrypt functions. Users should >>> only use block_encrypt/4 and block_decrypt/4. >>> >>> 2. Documentation updates is missing (of block_encrypt/4 and >>> block_decrypt/4). >>> >>> >>> /Sverker, Erlang/OTP >>> >>> >> >> Compare url: >> https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Dec 5 14:13:41 2013 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 5 Dec 2013 14:13:41 +0100 Subject: [erlang-patches] crypto: Add IGE mode for AES In-Reply-To: References: <51FA1A44.4060401@erlang.org> <520A29FA.9080602@erix.ericsson.se> Message-ID: <52A07C05.2040008@erlang.org> An error was made when inputting the target version of the patch, I've updated it to say R17B, the change should show up wheneven the next sync happens. The patch has been merged on our internal master and will be pushed soon(tm) to the github one. Sorry for the confusion, Lukas On 05/12/13 13:32, Yura Beznos wrote: > Hey, hello! > > I can see my patch (IGE mode for AES / aes_ige_crypt) as graduated on > site http://www.erlang.org/development/ in "master" not in some > release and I can't find my code in otp repository. > Is it error or something? > > > > On Wed, Nov 13, 2013 at 6:01 PM, Yura Beznos > wrote: > > Hello! > > The patch isn't graduated ? (IGE mode for AES) > > > On Tue, Aug 13, 2013 at 11:31 PM, Yura Beznos > > wrote: > > > On Tue, Aug 13, 2013 at 4:43 PM, Sverker Eriksson > > wrote: > > Fredrik wrote: > > On 08/01/2013 07:40 AM, Yura Beznos wrote: > > Hello, > > I'd like to submit this patch to add two new > functions to the crypt > library. > > Repo branch: > https://github.com/Zhiz0id/otp/tree/aes_ige_crypt > Compare: > https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt > > Why this new feature? > > It allows to use OpenSSL aes_ige_encrypt function. > > Risks / uncertain artifacts > > None. > > How did you solve it? > > Added two functions: aes_ige_256_decrypt, > aes_ige_256_encrypt . > > > Thanks. > > > -- > Yura > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > Hello Yura, > I've assigned this patch to be reviewed by > responsible, you will get feedback as soon as this is > done. > Thanks, > > > Looks good, Yura. Two objections though: > > 1. Do not export the aes_ige_256_encrypt/decrypt > functions. Users should only use block_encrypt/4 and > block_decrypt/4. > > 2. Documentation updates is missing (of block_encrypt/4 > and block_decrypt/4). > > > /Sverker, Erlang/OTP > > > > Compare url: > https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt > > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Dec 6 10:56:32 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 6 Dec 2013 10:56:32 +0100 Subject: [erlang-patches] [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: On Sat, Nov 16, 2013 at 1:58 PM, Anthony Ramine wrote: > Finally I may have found one. > > Tell me where I should write tests for that and I will add them. > > bs_match_SUITE.erl -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Dec 6 11:07:21 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 6 Dec 2013 11:07:21 +0100 Subject: [erlang-patches] [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: That?s for the original bug, but the fix I did is way more pervasive, don?t you think? Any additional suites I should patch for that reason? -- Anthony Ramine Le 6 d?c. 2013 ? 10:56, Bj?rn Gustavsson a ?crit : > On Sat, Nov 16, 2013 at 1:58 PM, Anthony Ramine wrote: > Finally I may have found one. > > Tell me where I should write tests for that and I will add them. > > > bs_match_SUITE.erl > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From rzezeski@REDACTED Sat Dec 7 22:00:21 2013 From: rzezeski@REDACTED (Ryan Zezeski) Date: Sat, 7 Dec 2013 16:00:21 -0500 Subject: [erlang-patches] Fix DTrace build on Illumos Message-ID: https://github.com/erlang/otp/pull/156 This patch fixes the configure and Makefile scripts to work with newer DTrace. This applies to all Illumos derivatives including OpenIndiana, SmartOS and OmnioOS. I've copied the commit message here verbatim. --- SNIP --- Fix DTrace build on Illumos DTrace was recently patched in Illumos to fail to create an object file if no probes are found. * https://www.illumos.org/issues/4248 * https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59 This patch fixes two issues: * Modify the configure script to pass an object file to `dtrace -G` that actually invokes a probe. * Remove creation of `dtrace_user.o` from the dyntrace Makefile. In a previous commit [1] Scott Fritchie relocated all the user probes into the VM proper due to difficulties with DTrace probes in shared libraries. The `dtrace_user.d` file is now empty and generates a header file with nothing in it. There is no longer any reason to generate `dtrace_user.o` because all the probes are in the VM. Thus all the steps for building `dtrace_user.o` have been removed. [1]: https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99 --- END SNIP --- -Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Mon Dec 9 12:54:06 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 9 Dec 2013 12:54:06 +0100 Subject: [erlang-patches] [erlang-bugs] sys_core_fold forgets about aliases when marking bit string variables for context reusing In-Reply-To: References: <969218F9-BEE3-4122-815E-6A45135954D8@gmail.com> Message-ID: On Fri, Dec 6, 2013 at 11:07 AM, Anthony Ramine wrote: > That?s for the original bug, but the fix I did is way more pervasive, > don?t you think? > > Any additional suites I should patch for that reason? > > core_fold_SUITE.erl I have not looked closely at the patch yet, but I have a few questions: The variable GSub is named that way because it was only used for the guard. Shouldn't it be renamed now that it is used both for the guard and body? Shouldn't the comment be updated? -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Dec 10 01:05:03 2013 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Mon, 9 Dec 2013 18:05:03 -0600 Subject: [erlang-patches] erlang:system_monitor long_message_queue Message-ID: Hey All, https://github.com/erlang/otp/pull/161 This patch adds a new option to the erlang:system_monitor BIF, allowing to subscribe monitor process to the long_message_queue events. It should be really helpful when investigating architectural bottlenecks, as well as a part of regular logging procedures. Few comments about the implementation: - Monitor messages are generated once the message gets appended to the receiver's message queue. - For a certain process - monitor message can be generated only once after exceeding a pre-configured threshold. Erlang VM will resend the monitor message only once the process mailbox size gets below the limit and exceeds them again. - Info list of the monitor message currently contains only receiver's message queue length. If you have any ideas on what might be useful to put there in addition to the mailbox size - please let me know. Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From bduggan@REDACTED Tue Dec 10 05:44:47 2013 From: bduggan@REDACTED (Bernard Duggan) Date: Tue, 10 Dec 2013 15:44:47 +1100 Subject: [erlang-patches] Fix SSL ETS table element leak and error cleanup Message-ID: <52A69C3F.4020502@shoretel.com> Hi list, The SSL library maintains an internal table of CA certificates (ssl_otp_cacertificate_db). This is supposed to be cleaned up when the last connection using a certificate closes, however there's two problems in R16B02 (and in the current master branch on github): * When CA certificates are provided as binary blobs, rather than by filename (ie, #ssl_options.cacerts is set, but #ssl_options.cacertfile is not) the cleanup never occurs due to an incorrect pattern match in tls_connection:handle_trusted_certs_db/1. This causes the table to grow unchecked because each connection adds a new entry. * When the process exits abnormally, tls_connection:terminate/1 is never called because the trap_exit process flag is not set and so similarly the table (and everything else cleaned in terminate/1, for that matter) is not cleaned up. This doesn't affect "normal" termination caused by the connection closing because terminate/1 is called explicitly from handle_sync_event/4, rather that relying on gen_fsm's automatic calling. Fixes for both are here: git fetch git://github.com/bernardd/otp ssl_cert_cache_fix https://github.com/bernardd/otp/compare/erlang:master...ssl_cert_cache_fix Credit goes to my colleague Nick Marino for doing the initial legwork to track this down. Cheers, Bernard ________________________________ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From henrik@REDACTED Tue Dec 10 14:09:11 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 10 Dec 2013 14:09:11 +0100 Subject: [erlang-patches] Fix spec for cpu_sup:util/1 In-Reply-To: <1fb41668f5e8478398b8e62f3adcfd21@DB3PR03MB315.eurprd03.prod.outlook.com> References: <1fb41668f5e8478398b8e62f3adcfd21@DB3PR03MB315.eurprd03.prod.outlook.com> Message-ID: <52A71277.4080308@erlang.org> Thank you for you contribution! At first glance, feel free to include the WHY in the commit message. https://github.com/erlang/otp/wiki/Writing-good-commit-messages Tidy up the commit message and then create a pull request from the branch, We will keep this email thread too, for comments and reviews. On 2013-12-04 15:38, Andrew Caruth wrote: > Hi OTP devs, > > I recently noticed dialyzer was flagging an issue in one of our own modules that was making a call to cpu_sup:util([detailed]). An 'is_list()' guard test was performed on the second element of the tuple returned which dialyzer was reporting as a test that could never succeed. Sample output from a call to cpu_sup:util([detailed]): > > {[0], > [{soft_irq,0.0}, > {hard_irq,0.0}, > {kernel,0.41368935690109065}, > {nice_user,0.0}, > {user,0.9402030838661151}], > [{steal,0.0},{idle,98.64610755923279},{wait,0.0}], > []} > > The spec implied {'all' | integer | list, tuple | float, tuple | float, []}, which excludes the above output, so I've updated the spec to allow the second and third elements as lists. > > Also, the atoms 'soft_irq', 'hard_irq', and 'steal' were also not part of the spec, so I've also added those. > > git fetch git://github.com/acaruth/otp.git cpu_sup_spec_fix > https://github.com/acaruth/otp/compare/erlang:maint...cpu_sup_spec_fix > https://github.com/acaruth/otp/compare/erlang:maint...cpu_sup_spec_fix.patch > > Thanks, > Andrew Caruth > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Dec 10 14:19:30 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 10 Dec 2013 14:19:30 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: Message-ID: <52A714E2.8090005@erlang.org> Hi Sending this for review but: squash the commits or make 2, one for core and one for asm , and write a proper commit message. On 2013-12-04 08:44, Tuncer Ayaz wrote: > Implement the suggestions I made in > http://erlang.org/pipermail/erlang-questions/2013-August/075161.html: > > * compile(3): stop declaring 'asm' as "for internal debugging use" > * compile:file/2: implement 'core' option > * compile_SUITE: test 'asm' > > https://github.com/erlang/otp/pull/154 > https://github.com/erlang/otp/pull/154.patch > git fetch git://github.com/tuncer/otp.git asm-core > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Tue Dec 10 14:26:40 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 10 Dec 2013 14:26:40 +0100 Subject: [erlang-patches] Fix DTrace build on Illumos In-Reply-To: References: Message-ID: <52A71690.7000808@erlang.org> Thank you for your contribution ! patch has been assigned to be reviewed On 2013-12-07 22:00, Ryan Zezeski wrote: > https://github.com/erlang/otp/pull/156 > > This patch fixes the configure and Makefile scripts to work with newer > DTrace. This applies to all Illumos derivatives including OpenIndiana, > SmartOS and OmnioOS. I've copied the commit message here verbatim. > > --- SNIP --- > > Fix DTrace build on Illumos > > DTrace was recently patched in Illumos to fail to create an object > file if no probes are found. > > * https://www.illumos.org/issues/4248 > * > https://github.com/illumos/illumos-gate/commit/54a20ab41aadcb81c53e72fc65886e964e9add59 > > This patch fixes two issues: > > * Modify the configure script to pass an object file to `dtrace -G` > that actually invokes a probe. > > * Remove creation of `dtrace_user.o` from the dyntrace Makefile. In a > previous commit [1] Scott Fritchie relocated all the user probes > into the VM proper due to difficulties with DTrace probes in shared > libraries. The `dtrace_user.d` file is now empty and generates a > header file with nothing in it. There is no longer any reason to > generate `dtrace_user.o` because all the probes are in the VM. Thus > all the steps for building `dtrace_user.o` have been removed. > > [1]: > https://github.com/erlang/otp/commit/75552bd3bb4e7f3cf4dab81a5c81cf73b1d3fb99 > > --- END SNIP --- > > -Z > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Dec 10 14:32:07 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 10 Dec 2013 14:32:07 +0100 Subject: [erlang-patches] erlang:system_monitor long_message_queue In-Reply-To: References: Message-ID: <52A717D7.4080104@erlang.org> Hi Thank you for your contribution! As you can see Lukas is already waiting for answers on the pull request. On 2013-12-10 01:05, Micha? Ptaszek wrote: > Hey All, > > https://github.com/erlang/otp/pull/161 > > This patch adds a new option to the erlang:system_monitor BIF, > allowing to subscribe monitor process to the long_message_queue > events. It should be really helpful when investigating architectural > bottlenecks, as well as a part of regular logging procedures. > > Few comments about the implementation: > - Monitor messages are generated once the message gets appended to the > receiver's message queue. > - For a certain process - monitor message can be generated only once > after exceeding a pre-configured threshold. Erlang VM will resend the > monitor message only once the process mailbox size gets below the > limit and exceeds them again. > - Info list of the monitor message currently contains only receiver's > message queue length. If you have any ideas on what might be useful to > put there in addition to the mailbox size - please let me know. > _ > _ > Thanks, > Michal > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Tue Dec 10 14:43:34 2013 From: henrik@REDACTED (Henrik Nord) Date: Tue, 10 Dec 2013 14:43:34 +0100 Subject: [erlang-patches] Fix SSL ETS table element leak and error cleanup In-Reply-To: <52A69C3F.4020502@shoretel.com> References: <52A69C3F.4020502@shoretel.com> Message-ID: <52A71A86.20300@erlang.org> Thank you for your contribution! You could, in addition to the email and proper links, also create a pullrequest for the patch. That way it will be processed into our system. I will create a pullrequest for this. Thank you! On 2013-12-10 05:44, Bernard Duggan wrote: > Hi list, > The SSL library maintains an internal table of CA certificates > (ssl_otp_cacertificate_db). This is supposed to be cleaned up when the > last connection using a certificate closes, however there's two problems > in R16B02 (and in the current master branch on github): > > * When CA certificates are provided as binary blobs, rather than by > filename (ie, #ssl_options.cacerts is set, but #ssl_options.cacertfile > is not) the cleanup never occurs due to an incorrect pattern match in > tls_connection:handle_trusted_certs_db/1. This causes the table to grow > unchecked because each connection adds a new entry. > > * When the process exits abnormally, tls_connection:terminate/1 is never > called because the trap_exit process flag is not set and so similarly > the table (and everything else cleaned in terminate/1, for that matter) > is not cleaned up. This doesn't affect "normal" termination caused by > the connection closing because terminate/1 is called explicitly from > handle_sync_event/4, rather that relying on gen_fsm's automatic calling. > > Fixes for both are here: > > git fetch git://github.com/bernardd/otp ssl_cert_cache_fix > https://github.com/bernardd/otp/compare/erlang:master...ssl_cert_cache_fix > > > Credit goes to my colleague Nick Marino for doing the initial legwork to > track this down. > > Cheers, > > Bernard > > ________________________________ > > This e-mail and any attachments are confidential. If it is not > intended for you, please notify the sender, and please erase and > ignore the contents. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From tuncer.ayaz@REDACTED Wed Dec 11 12:17:31 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 11 Dec 2013 12:17:31 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: <52A714E2.8090005@erlang.org> References: <52A714E2.8090005@erlang.org> Message-ID: On 12/10/13, Henrik Nord wrote: > Hi > > Sending this for review but: > squash the commits or make 2, one for core and one for asm , and write a > proper commit message. Done, please re-fetch. > On 2013-12-04 08:44, Tuncer Ayaz wrote: >> Implement the suggestions I made in >> http://erlang.org/pipermail/erlang-questions/2013-August/075161.html: >> >> * compile(3): stop declaring 'asm' as "for internal debugging use" >> * compile:file/2: implement 'core' option >> * compile_SUITE: test 'asm' >> >> https://github.com/erlang/otp/pull/154 >> https://github.com/erlang/otp/pull/154.patch >> git fetch git://github.com/tuncer/otp.git asm-core From bgustavsson@REDACTED Wed Dec 11 16:02:28 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 11 Dec 2013 16:02:28 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 1:16 PM, Anthony Ramine wrote: > Done. > > Please don?t ask me this again, the two bootstrap commits in the middle of > the branch are a pain to rebase :p > > OK. Will try to avoid that. We also had some interesting merge conflicts trying to include this branch in our daily builds (conflicts with another language exentsion), so it has taken me longer than I hoped to see the test results. Anyway, it turns out that ordinary funs no longer work in the debugger. It is probably my fault. The evaluation code depends on order of the items in the fun environment, which is not guaranteed to stay unchanged. So I have rewritten the code in a safer way. It can be found here: git fetch git@REDACTED:bjorng/otp.git nox/eep37 Have a look at it and see if you agree with my solution. Then there is one more thing. The test case erl_lint_SUITE:unused_vars_warn_fun/1 fails. It think that is the last thing that will need to be fixed before merging the branch. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Dec 12 02:07:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Dec 2013 02:07:35 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: Message-ID: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Hello, Thanks for the review, will take care of it. Commented inline. -- Anthony Ramine Le 11 d?c. 2013 ? 16:02, Bj?rn Gustavsson a ?crit : > On Thu, Dec 5, 2013 at 1:16 PM, Anthony Ramine wrote: > Done. > > Please don?t ask me this again, the two bootstrap commits in the middle of the branch are a pain to rebase :p > > > OK. Will try to avoid that. > > We also had some interesting merge conflicts trying > to include this branch in our daily builds (conflicts with another > language exentsion), so it has taken me longer than I > hoped to see the test results. Was the extension maps? I imagine the mess merging all of that, heh. > Anyway, it turns out that ordinary funs no longer > work in the debugger. It is probably my fault. The > evaluation code depends on order of the items in the > fun environment, which is not guaranteed to stay > unchanged. So I have rewritten the code in a safer > way. It can be found here: > > git fetch git@REDACTED:bjorng/otp.git nox/eep37 > > Have a look at it and see if you agree with my > solution. Your solution is correct. But shouldn?t that be done in erl_eval too? > Then there is one more thing. The test case > erl_lint_SUITE:unused_vars_warn_fun/1 fails. > It think that is the last thing that will need to be > fixed before merging the branch. There is probably a bug in my erl_lint modifications, guess who won a rebase? > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Thu Dec 12 10:20:23 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 12 Dec 2013 10:20:23 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Message-ID: On Thu, Dec 12, 2013 at 2:07 AM, Anthony Ramine wrote: > > Was the extension maps? I imagine the mess merging all of that, heh. > > Yes. In the end, we decided to take out maps from our daily builds until your branch have been merged. > > Anyway, it turns out that ordinary funs no longer > > work in the debugger. It is probably my fault. The > > evaluation code depends on order of the items in the > > fun environment, which is not guaranteed to stay > > unchanged. So I have rewritten the code in a safer > > way. It can be found here: > > > > git fetch git@REDACTED:bjorng/otp.git nox/eep37 > > > > Have a look at it and see if you agree with my > > solution. > > Your solution is correct. But shouldn?t that be done in erl_eval too? > You are right. It happens to work now, but it could break at any time. Can you do that change? -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Dec 12 10:39:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Dec 2013 10:39:41 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Message-ID: Replied inline. -- Anthony Ramine Le 12 d?c. 2013 ? 10:20, Bj?rn Gustavsson a ?crit : > On Thu, Dec 12, 2013 at 2:07 AM, Anthony Ramine wrote: > > Yes. In the end, we decided to take out maps from > our daily builds until your branch have been merged. Postponing a feature of your own to merge one from the community? That?s very nice. > You are right. It happens to work now, but it could > break at any time. > > Can you do that change? Will do. From egil@REDACTED Thu Dec 12 11:27:07 2013 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 12 Dec 2013 11:27:07 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Message-ID: <52A98F7B.5070803@erlang.org> On 2013-12-12 10:39, Anthony Ramine wrote: >> On Thu, Dec 12, 2013 at 2:07 AM, Anthony Ramine wrote: >> > >> >Yes. In the end, we decided to take out maps from >> >our daily builds until your branch have been merged. > Postponing a feature of your own to merge one from the community? That?s very nice. > Other opinions exists =) // Bj?rn-Egil From andreas@REDACTED Thu Dec 12 12:18:52 2013 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 12 Dec 2013 12:18:52 +0100 Subject: [erlang-patches] Scan "=<<" as something useful Message-ID: <52A99B9C.4030809@erlang.org> Hi Anthony, Your patch nox/disambiguate-equal-binary has been rejected. After a long discussion, evaluating the arguments from the related mailing list discussions, the OTP Technical Board concluded to keep the current solution; and thus, to reject the patch, among others because the decision support has not changed since the (first) discussion on the erlang-questions list in May 2003. In other words, we would like to get rid of that issue as well, but we do not want to pay the prize. That is, we do not want to replace one inconsistency with another, thereby introducing a special case and syntax knowledge in the scanner. Kind regards, Andreas Schumacher Erlang/OTP, Ericsson AB From tuncer.ayaz@REDACTED Thu Dec 12 13:33:30 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 12 Dec 2013 13:33:30 +0100 Subject: [erlang-patches] R16B03 type fixes Message-ID: If you build a comprehensive PLT for R16B03, you'll get the following warnings: Unknown types: gen_sctp:open_option/0 inet:ipaddress/0 proplists:proplists/0 public_key:private_key/0 This branch fixes all but the gen_sctp:open_option/0 warning, because I wasn't sure about the right approach. I'll leave that as an exercise for Raimo and Anders :-). https://github.com/erlang/otp/pull/166 https://github.com/erlang/otp/pull/166.patch git fetch git://github.com/tuncer/otp.git 16b03-type-fixes From n.oxyde@REDACTED Thu Dec 12 13:53:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Dec 2013 13:53:16 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Message-ID: I?ve squashed your commits with mine and fixed erl_lint. Please refetch. -- Anthony Ramine Le 12 d?c. 2013 ? 10:39, Anthony Ramine a ?crit : > Replied inline. > > -- > Anthony Ramine > > Le 12 d?c. 2013 ? 10:20, Bj?rn Gustavsson a ?crit : > >> On Thu, Dec 12, 2013 at 2:07 AM, Anthony Ramine wrote: >> >> Yes. In the end, we decided to take out maps from >> our daily builds until your branch have been merged. > > Postponing a feature of your own to merge one from the community? That?s very nice. > >> You are right. It happens to work now, but it could >> break at any time. >> >> Can you do that change? > > Will do. > From n.oxyde@REDACTED Thu Dec 12 17:35:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Dec 2013 17:35:53 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <5280ECDD.3020001@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> Message-ID: This patch breaks reverting of local implicit funs in R16B03. We have two ways of fixing this: - Making erl_syntax reverts local implicit funs? parts as concrete values. - Change the AST format in a backwards-incompatible way and use abstract values for local implicit funs too. My vote is on fixing erl_syntax right now for R16, and change the AST in R17 as we will have maps and named funs anyway in there. Sorry for the inconvenience. Richard, maybe we should write tests for syntax_tools? -- Anthony Ramine Le 11 nov. 2013 ? 15:42, Henrik Nord a ?crit : > Its moving forward as we speak. > > Thank you for your contribution! > > On 2013-11-01 12:29, Anthony Ramine wrote: >> Ping? This is still ? Status: Author ? in the Development page. >> > > -- > /Henrik Nord Erlang/OTP > From n.oxyde@REDACTED Fri Dec 13 00:22:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 00:22:03 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> Message-ID: <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Hello again, I?ve pushed the fix. It is just a partial revert of the previous commit on erl_syntax. Such a thing would have been avoided by basic tests. Or just double checking the documentation about the AST, I?m to blame for that. Should the AST be made consistent between local and remote implicit funs in R17A? I can write a patch for that. With proper tests and documentation. git fetch https://github.com/nox/otp.git fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch Regards, -- Anthony Ramine Le 12 d?c. 2013 ? 17:35, Anthony Ramine a ?crit : > This patch breaks reverting of local implicit funs in R16B03. > > We have two ways of fixing this: > > - Making erl_syntax reverts local implicit funs? parts as concrete values. > - Change the AST format in a backwards-incompatible way and use abstract values for local implicit funs too. > > My vote is on fixing erl_syntax right now for R16, and change the AST in R17 as we will have maps and named funs anyway in there. > > Sorry for the inconvenience. > > Richard, maybe we should write tests for syntax_tools? > > -- > Anthony Ramine > > Le 11 nov. 2013 ? 15:42, Henrik Nord a ?crit : > >> Its moving forward as we speak. >> >> Thank you for your contribution! >> >> On 2013-11-01 12:29, Anthony Ramine wrote: >>> Ping? This is still ? Status: Author ? in the Development page. >>> >> >> -- >> /Henrik Nord Erlang/OTP >> > From henrik@REDACTED Fri Dec 13 09:52:26 2013 From: henrik@REDACTED (Henrik Nord) Date: Fri, 13 Dec 2013 09:52:26 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <51F1416E-F323-47A0-A17A-334E01310C8B@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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Message-ID: <52AACACA.7000005@erlang.org> The patch, igor funs, was merged into maint 2013-11-29 https://github.com/erlang/otp/commit/40d21f3f803a336b3d3edf338ec71a67ea1f09b1 Also, Would you mind pressing the "pull request" button on github for your patches? We are still working on how to solve this in a good way, until then patches, discussions and reviews in email, code on github? And making it a pull request from the getgo ensures that it will go into our patch monitoring system saves us some manual labor Thanks! /Henrik On 2013-12-13 00:22, Anthony Ramine wrote: > Hello again, > > I?ve pushed the fix. It is just a partial revert of the previous commit on erl_syntax. Such a thing would have been avoided by basic tests. Or just double checking the documentation about the AST, I?m to blame for that. > > Should the AST be made consistent between local and remote implicit funs in R17A? I can write a patch for that. With proper tests and documentation. > > git fetch https://github.com/nox/otp.git fix-OTP-11506 > > https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 > https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch > > Regards, > -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Fri Dec 13 10:05:48 2013 From: davidnwelton@REDACTED (David Welton) Date: Fri, 13 Dec 2013 10:05:48 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <51F1416E-F323-47A0-A17A-334E01310C8B@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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Message-ID: Hi guys, Since this code is out in the wild, and seems to cause some problems (I noticed the problem when trying to work with Chicago Boss with R16B03 and brought it to Anthony's attention), can you recommend a good way to work around it until B04 comes out? Thank you, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From henrik@REDACTED Fri Dec 13 10:16:55 2013 From: henrik@REDACTED (Henrik Nord) Date: Fri, 13 Dec 2013 10:16:55 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> Message-ID: <52AAD087.6010407@erlang.org> Next release is R17pre sometime in Jan So, If this fix that Anthony sent : git fetchhttps://github.com/nox/otp.git fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch Fixes the problem, you might have to apply that yourself until we merge it into master. On 2013-12-13 10:05, David Welton wrote: > Hi guys, > > Since this code is out in the wild, and seems to cause some problems > (I noticed the problem when trying to work with Chicago Boss with > R16B03 and brought it to Anthony's attention), can you recommend a > good way to work around it until B04 comes out? > > Thank you, -- /Henrik Nord Erlang/OTP From n.oxyde@REDACTED Fri Dec 13 11:08:51 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 11:08:51 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52AACACA.7000005@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AACACA.7000005@erlang.org> Message-ID: I can reluctantly make a PR, but don?t expect me to notice when comments are posted, or to comment myself there. I prefer my mailbox which I can actually archive. -- Anthony Ramine Le 13 d?c. 2013 ? 09:52, Henrik Nord a ?crit : > Also, Would you mind pressing the "pull request" button on github for your patches? From n.oxyde@REDACTED Fri Dec 13 11:09:25 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 11:09:25 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52AAD087.6010407@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: This means any project relying on erl_syntax won?t work with R16B03. In my opinion we need an R16B03-1. -- Anthony Ramine Le 13 d?c. 2013 ? 10:16, Henrik Nord a ?crit : > Fixes the problem, you might have to apply that yourself until we merge it into master. From bgustavsson@REDACTED Fri Dec 13 12:38:29 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 13 Dec 2013 12:38:29 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Message-ID: On Thu, Dec 12, 2013 at 1:53 PM, Anthony Ramine wrote: > I?ve squashed your commits with mine and fixed erl_lint. Please refetch. > > Thanks! I fetched, I tested, I merged. (Henrik will push master later today.) /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Dec 13 12:53:47 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 13 Dec 2013 12:53:47 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> Message-ID: <257D42CA-49C2-48A4-A787-E0E85B2F7B52@gmail.com> Honestly, in the end it happened faster than I would have thought :p Thank you! -- Anthony Ramine Le 13 d?c. 2013 ? 12:38, Bj?rn Gustavsson a ?crit : > I fetched, I tested, I merged. From henrik@REDACTED Fri Dec 13 12:58:06 2013 From: henrik@REDACTED (Henrik Nord) Date: Fri, 13 Dec 2013 12:58:06 +0100 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <257D42CA-49C2-48A4-A787-E0E85B2F7B52@gmail.com> References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> <257D42CA-49C2-48A4-A787-E0E85B2F7B52@gmail.com> Message-ID: <52AAF64E.8030502@erlang.org> To git@REDACTED:erlang/otp.git 458e302..7d4e5e2 master -> master Should be live On 2013-12-13 12:53, Anthony Ramine wrote: > Honestly, in the end it happened faster than I would have thought :p > > Thank you! > -- /Henrik Nord Erlang/OTP From essen@REDACTED Fri Dec 13 13:31:37 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 13 Dec 2013 13:31:37 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: <52AAFE29.4010808@ninenines.eu> This potentially breaks pretty much any project that manipulates AST, including many parse_transforms, other BEAM languages targetting the Erlang AST, tools that generate code, and of course everything that requires one of the above to work. This sounds serious enough to do a hotfix. Also sounds like test suites are really missing there, something should be done about it to make sure it doesn't happen again. On 12/13/2013 11:09 AM, Anthony Ramine wrote: > This means any project relying on erl_syntax won?t work with R16B03. In my opinion we need an R16B03-1. > -- Lo?c Hoguin http://ninenines.eu From bgustavsson@REDACTED Fri Dec 13 13:31:43 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 13 Dec 2013 13:31:43 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: <52A714E2.8090005@erlang.org> Message-ID: On Wed, Dec 11, 2013 at 12:17 PM, Tuncer Ayaz wrote: > On 12/10/13, Henrik Nord wrote: > > Hi > > > > Sending this for review but: > > squash the commits or make 2, one for core and one for asm , and write a > > proper commit message. > > Done, please re-fetch. > > I and Bj?rn-Egil discussed the options. We see no reason to have two names for the same option. So we suggest: Remove the documentation for 'asm' and 'core', but retain the implementation for 'asm' and 'core'. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuncer.ayaz@REDACTED Fri Dec 13 14:08:57 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 13 Dec 2013 14:08:57 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: <52A714E2.8090005@erlang.org> Message-ID: On 12/13/13, Bj?rn Gustavsson wrote: > On Wed, Dec 11, 2013 at 12:17 PM, Tuncer Ayaz wrote: > >> On 12/10/13, Henrik Nord wrote: >> > Hi >> > >> > Sending this for review but: squash the commits or make 2, one >> > for core and one for asm , and write a proper commit message. >> >> Done, please re-fetch. >> >> > I and Bj?rn-Egil discussed the options. We see no reason to have two > names for the same option. So we suggest: I agree. > Remove the documentation for 'asm' and 'core', but retain the > implementation for 'asm' and 'core'. So, you're suggesting to * _only_ document 'from_asm' and 'from_core' and un-document 'asm' * implement 'core' -> 'from_core' mapping Is that correct? Wouldn't it make more sense to _not_ implement 'core' and deprecate 'asm'? From bgustavsson@REDACTED Fri Dec 13 14:26:44 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 13 Dec 2013 14:26:44 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: <52A714E2.8090005@erlang.org> Message-ID: On Fri, Dec 13, 2013 at 2:08 PM, Tuncer Ayaz wrote: > > > I and Bj?rn-Egil discussed the options. We see no reason to have two > > names for the same option. So we suggest: > > I agree. > > > Remove the documentation for 'asm' and 'core', but retain the > > implementation for 'asm' and 'core'. > > So, you're suggesting to > * _only_ document 'from_asm' and 'from_core' and un-document 'asm' > * implement 'core' -> 'from_core' mapping > > Is that correct? > > Wouldn't it make more sense to _not_ implement 'core' and deprecate 'asm'? > Yes, it does. Make it so. :-) By deprecating, do you mean printing a message when the 'asm' option is used and internally translate it to 'to_asm'? I still think that 'asm' should be undocumented. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Fri Dec 13 14:41:46 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 13 Dec 2013 15:41:46 +0200 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: <52A714E2.8090005@erlang.org> Message-ID: <52AB0E9A.20002@cs.ntua.gr> On 12/13/13 15:26, Bj?rn Gustavsson wrote: > By deprecating, do you mean printing a message when the 'asm' option is used > and internally translate it to 'to_asm'? This probably does not belong to this thread, but since there is some discussion about compiler options and printing messages going on, can I please ask/propose that the BEAM compiler becomes a bit more verbose when unrecognized or unknown options are given to it? Currently, we have: Eshell V5.10.4 (abort with ^G) 1> c(foo, [gazonk]). {ok,foo} 2> compile:file(foo, [gazonk]). {ok,foo} (same with erlc, I believe). In contrast, the HiPE compiler issues a warning in such cases: 3> hipe:c(foo, [gazonk]). Warning: [hipe:1515]: Unknown options: [gazonk]. {ok,foo} which has saved me multiple times when mistyping options... Kostis From max.lapshin@REDACTED Fri Dec 13 15:19:43 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 13 Dec 2013 18:19:43 +0400 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <52AAF64E.8030502@erlang.org> References: <3160F6B6-27DF-44D3-B816-1BE50828ED64@gmail.com> <257D42CA-49C2-48A4-A787-E0E85B2F7B52@gmail.com> <52AAF64E.8030502@erlang.org> Message-ID: Hooray! On Fri, Dec 13, 2013 at 3:58 PM, Henrik Nord wrote: > To git@REDACTED:erlang/otp.git > 458e302..7d4e5e2 master -> master > > Should be live > > > On 2013-12-13 12:53, Anthony Ramine wrote: > >> Honestly, in the end it happened faster than I would have thought :p >> >> Thank you! >> >> > -- > /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 tuncer.ayaz@REDACTED Fri Dec 13 15:26:57 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 13 Dec 2013 15:26:57 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: <52A714E2.8090005@erlang.org> Message-ID: On 12/13/13, Bj?rn Gustavsson wrote: > On Fri, Dec 13, 2013 at 2:08 PM, Tuncer Ayaz wrote: > >> >> > I and Bj?rn-Egil discussed the options. We see no reason to have two >> > names for the same option. So we suggest: >> >> I agree. >> >> > Remove the documentation for 'asm' and 'core', but retain the >> > implementation for 'asm' and 'core'. >> >> So, you're suggesting to >> * _only_ document 'from_asm' and 'from_core' and un-document 'asm' >> * implement 'core' -> 'from_core' mapping >> >> Is that correct? >> >> Wouldn't it make more sense to _not_ implement 'core' and deprecate >> 'asm'? >> > > Yes, it does. Make it so. :-) Thanks, it's great you accept that change! The original patch didn't do that because I expected you to find it too invasive :). > By deprecating, do you mean printing a message when the 'asm' option > is used and internally translate it to 'to_asm'? I still think that > 'asm' should be undocumented. Yes, it should warn about a removal in R18. Also, of course 'asm' should be un-documented; I'm sorry if I wasn't clear in the previous email. Updated the branch accordingly, please re-fetch. From n.oxyde@REDACTED Sat Dec 14 12:46:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Dec 2013 12:46:41 +0100 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: References: Message-ID: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> Ping? I have trouble understanding what they should look like, as in a lot of situations the shell does not even print a stack trace. Also the eunit format seems to be more verbose. Regards, -- Anthony Ramine Le 8 juil. 2013 ? 12:11, Anthony Ramine a ?crit : > Ok. What about the eunit stacktraces? > > -- > Anthony Ramine > > Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit : > >> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine wrote: >> >> To choose a format, Rosetta Code was my main source of inspiration [1]. >> >> >> We think that it would be better if the stack traces would have the >> same format as in the shell. >> >> /Bj?rn >> > From n.oxyde@REDACTED Sat Dec 14 02:08:18 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 14 Dec 2013 02:08:18 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52AAFE29.4010808@ninenines.eu> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52AAFE29.4010808@ninenines.eu> Message-ID: <50A92E52-39CF-4199-BD43-5B6168745333@gmail.com> Hello, I?ve added a commit which smoke tests erl_syntax:revert/1. Henrik, please refetch. Regards, -- Anthony Ramine Le 13 d?c. 2013 ? 13:31, Lo?c Hoguin a ?crit : > This potentially breaks pretty much any project that manipulates AST, including many parse_transforms, other BEAM languages targetting the Erlang AST, tools that generate code, and of course everything that requires one of the above to work. This sounds serious enough to do a hotfix. > > Also sounds like test suites are really missing there, something should be done about it to make sure it doesn't happen again. > > On 12/13/2013 11:09 AM, Anthony Ramine wrote: >> This means any project relying on erl_syntax won?t work with R16B03. In my opinion we need an R16B03-1. >> > > -- > Lo?c Hoguin > http://ninenines.eu From bgustavsson@REDACTED Mon Dec 16 12:42:51 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 16 Dec 2013 12:42:51 +0100 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> References: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> Message-ID: I did not understand your eunit question. Did you ask whether you should update stacktraces in eunit too? I have not seen stacktrace in eunit, since I have used eunit very little. Here are some examples of stacktraces produced by the shell: 1> lists:map(fun(X) -> X + 1 end, [a]). ** exception error: an error occurred when evaluating an arithmetic expression in operator +/2 called as a + 1 in call from lists:map/2 (lists.erl, line 1224) 2> lists:map(fun(X) -> lists:sum(X) + 1 end, [a]). ** exception error: no function clause matching lists:sum(a,0) (lists.erl, line 276) in function erl_eval:do_apply/6 (erl_eval.erl, line 573) in call from erl_eval:expr/5 (erl_eval.erl, line 395) in call from lists:map/2 (lists.erl, line 1224) 3> The code that formats the stacktrace can be found in lib.erl (in stdlib). The point with my answer was that we didn't want significantly different stacktraces depending on their origin. If you want to rewrite how the shell formats stacktraces, that is also fine. In that case, make sure that you include examples of the stacktraces in the commit message so that we can see how the stacktrace will look without having to build the branch in order to see a stacktrace. On Sat, Dec 14, 2013 at 12:46 PM, Anthony Ramine wrote: > Ping? > > I have trouble understanding what they should look like, as in a lot of > situations the shell does not even print a stack trace. > > Also the eunit format seems to be more verbose. > > Regards, > > -- > Anthony Ramine > > Le 8 juil. 2013 ? 12:11, Anthony Ramine a ?crit : > > > Ok. What about the eunit stacktraces? > > > > -- > > Anthony Ramine > > > > Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit : > > > >> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine > wrote: > >> > >> To choose a format, Rosetta Code was my main source of inspiration [1]. > >> > >> > >> We think that it would be better if the stack traces would have the > >> same format as in the shell. > >> > >> /Bj?rn > >> > > > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Dec 16 12:46:26 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Dec 2013 12:46:26 +0100 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: References: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> Message-ID: <8B4CFDC7-B801-419A-B865-BA4A6279AAFE@gmail.com> Thanks for the example. Apart from the infix operators, I can print such stack traces easily. Would printing of operators as fully-qualified erlang function calls be a game breaker? -- Anthony Ramine Le 16 d?c. 2013 ? 12:42, Bj?rn Gustavsson a ?crit : > I did not understand your eunit question. Did you > ask whether you should update stacktraces > in eunit too? > > I have not seen stacktrace in eunit, since I have > used eunit very little. > > Here are some examples of stacktraces produced > by the shell: > > 1> lists:map(fun(X) -> X + 1 end, [a]). > ** exception error: an error occurred when evaluating an arithmetic expression > in operator +/2 > called as a + 1 > in call from lists:map/2 (lists.erl, line 1224) > 2> lists:map(fun(X) -> lists:sum(X) + 1 end, [a]). > ** exception error: no function clause matching lists:sum(a,0) (lists.erl, line 276) > in function erl_eval:do_apply/6 (erl_eval.erl, line 573) > in call from erl_eval:expr/5 (erl_eval.erl, line 395) > in call from lists:map/2 (lists.erl, line 1224) > 3> > > The code that formats the stacktrace can be found > in lib.erl (in stdlib). > > The point with my answer was that we didn't want significantly > different stacktraces depending on their origin. If you want > to rewrite how the shell formats stacktraces, that is also > fine. In that case, make sure that you include examples > of the stacktraces in the commit message so that we > can see how the stacktrace will look without having to > build the branch in order to see a stacktrace. > > > > > On Sat, Dec 14, 2013 at 12:46 PM, Anthony Ramine wrote: > Ping? > > I have trouble understanding what they should look like, as in a lot of situations the shell does not even print a stack trace. > > Also the eunit format seems to be more verbose. > > Regards, > > -- > Anthony Ramine > > Le 8 juil. 2013 ? 12:11, Anthony Ramine a ?crit : > > > Ok. What about the eunit stacktraces? > > > > -- > > Anthony Ramine > > > > Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit : > > > >> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine wrote: > >> > >> To choose a format, Rosetta Code was my main source of inspiration [1]. > >> > >> > >> We think that it would be better if the stack traces would have the > >> same format as in the shell. > >> > >> /Bj?rn > >> > > > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Mon Dec 16 12:50:15 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 16 Dec 2013 12:50:15 +0100 Subject: [erlang-patches] Fix evaluation of and also and orelse in the debugger Message-ID: <69CBECDF-CE28-4394-B0EF-D55641807695@gmail.com> Hello, While implementing cond, I stumbled onto that bug. git fetch https://github.com/nox/otp.git fix-dbg_ieval-exporting-rules https://github.com/erlang/otp/pull/171 https://github.com/nox/otp/compare/fix-dbg_ieval-exporting-rules https://github.com/nox/otp/compare/fix-dbg_ieval-exporting-rules.patch Regards, -- Anthony Ramine From bgustavsson@REDACTED Mon Dec 16 12:59:21 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 16 Dec 2013 12:59:21 +0100 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: <8B4CFDC7-B801-419A-B865-BA4A6279AAFE@gmail.com> References: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> <8B4CFDC7-B801-419A-B865-BA4A6279AAFE@gmail.com> Message-ID: On Mon, Dec 16, 2013 at 12:46 PM, Anthony Ramine wrote: > Thanks for the example. > > Apart from the infix operators, I can print such stack traces easily. > Would printing of operators as fully-qualified erlang function calls be a > game breaker? > > No, it wouldn't. Minor differences are OK if it simplifies the code in the run-time system. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From florz@REDACTED Mon Dec 16 13:19:05 2013 From: florz@REDACTED (Florian Zumbiehl) Date: Mon, 16 Dec 2013 13:19:05 +0100 Subject: [erlang-patches] [PATCH] crypto: fix a few memleaks/undefined pointer dereferences Message-ID: <20131216121905.GO5636@florz.florz.dyndns.org> --- Hi, now, those are the obviously broken cases - what I am wondering about is whether it is correct that almost none of the OpenSSL calls in crypto are being checked for memory allocation failures!? IIUC, OpenSSL is configured to use enif_alloc(), which according to this ... http://www.erlang.org/doc/man/erl_nif.html#enif_alloc ... will return NULL in case of an allocation failure. Now, is that there just to confuse people because the function doesn't actually ever return in case of an allocation failure, or is this really severely broken? Am I missing something? Regards, Florian diff --git a/lib/crypto/c_src/crypto.c b/lib/crypto/c_src/crypto.c index 42fb172..9e5c42a 100644 --- a/lib/crypto/c_src/crypto.c +++ b/lib/crypto/c_src/crypto.c @@ -1789,7 +1789,7 @@ static ERL_NIF_TERM rand_uniform_nif(ErlNifEnv* env, int argc, const ERL_NIF_TER static ERL_NIF_TERM mod_exp_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {/* (Base,Exponent,Modulo,bin_hdr) */ - BIGNUM *bn_base=NULL, *bn_exponent=NULL, *bn_modulo, *bn_result; + BIGNUM *bn_base=NULL, *bn_exponent=NULL, *bn_modulo=NULL, *bn_result; BN_CTX *bn_ctx; unsigned char* ptr; unsigned dlen; @@ -1804,6 +1804,7 @@ static ERL_NIF_TERM mod_exp_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM arg if (bn_base) BN_free(bn_base); if (bn_exponent) BN_free(bn_exponent); + if (bn_modulo) BN_free(bn_modulo); return enif_make_badarg(env); } bn_result = BN_new(); @@ -2600,7 +2601,7 @@ static ERL_NIF_TERM dh_compute_key_nif(ErlNifEnv* env, int argc, const ERL_NIF_T static ERL_NIF_TERM srp_value_B_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {/* (Multiplier, Verifier, Generator, Exponent, Prime) */ BIGNUM *bn_verifier = NULL; - BIGNUM *bn_exponent, *bn_generator, *bn_prime, *bn_multiplier, *bn_result; + BIGNUM *bn_exponent = NULL, *bn_generator = NULL, *bn_prime = NULL, *bn_multiplier = NULL, *bn_result; BN_CTX *bn_ctx; unsigned char* ptr; unsigned dlen; @@ -2613,9 +2614,9 @@ static ERL_NIF_TERM srp_value_B_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM || !get_bn_from_bin(env, argv[4], &bn_prime)) { if (bn_multiplier) BN_free(bn_multiplier); if (bn_verifier) BN_free(bn_verifier); - if (bn_verifier) BN_free(bn_generator); - if (bn_verifier) BN_free(bn_exponent); - if (bn_verifier) BN_free(bn_prime); + if (bn_generator) BN_free(bn_generator); + if (bn_exponent) BN_free(bn_exponent); + if (bn_prime) BN_free(bn_prime); return enif_make_badarg(env); } @@ -2739,7 +2740,7 @@ static ERL_NIF_TERM srp_host_secret_nif(ErlNifEnv* env, int argc, const ERL_NIF_ = (A * v^u) ^ b % N */ BIGNUM *bn_b = NULL, *bn_verifier = NULL; - BIGNUM *bn_prime, *bn_A, *bn_u, *bn_base, *bn_result; + BIGNUM *bn_prime = NULL, *bn_A = NULL, *bn_u = NULL, *bn_base, *bn_result; BN_CTX *bn_ctx; unsigned char* ptr; unsigned dlen; From sverker.eriksson@REDACTED Mon Dec 16 16:23:54 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 16 Dec 2013 16:23:54 +0100 Subject: [erlang-patches] [PATCH] crypto: fix a few memleaks/undefined pointer dereferences In-Reply-To: <20131216121905.GO5636@florz.florz.dyndns.org> References: <20131216121905.GO5636@florz.florz.dyndns.org> Message-ID: <52AF1B0A.3010704@erix.ericsson.se> On 12/16/2013 01:19 PM, Florian Zumbiehl wrote: > --- > Hi, > > now, those are the obviously broken cases - Thanks. I'll put the patch in the pipe for R17. > what I am wondering about is > whether it is correct that almost none of the OpenSSL calls in crypto are > being checked for memory allocation failures!? Not sure what you mean. Can you give an example. > IIUC, OpenSSL is configured > to use enif_alloc(), which according to this ... > > http://www.erlang.org/doc/man/erl_nif.html#enif_alloc > > ... will return NULL in case of an allocation failure. Now, is that there > just to confuse people because the function doesn't actually ever return in > case of an allocation failure, or is this really severely broken? Am I > missing something? enif_alloc calls erts_alloc_fnf where "fnf" stands for "Failure Not Fatal" which means that it will return NULL on failure. /Sverker From florz@REDACTED Mon Dec 16 17:24:23 2013 From: florz@REDACTED (Florian Zumbiehl) Date: Mon, 16 Dec 2013 17:24:23 +0100 Subject: [erlang-patches] [PATCH] crypto: fix a few memleaks/undefined pointer dereferences In-Reply-To: <52AF1B0A.3010704@erix.ericsson.se> References: <20131216121905.GO5636@florz.florz.dyndns.org> <52AF1B0A.3010704@erix.ericsson.se> Message-ID: <20131216162423.GX5636@florz.florz.dyndns.org> Hi, > >now, those are the obviously broken cases - > Thanks. I'll put the patch in the pipe for R17. Thanks! > >what I am wondering about is > >whether it is correct that almost none of the OpenSSL calls in crypto are > >being checked for memory allocation failures!? > Not sure what you mean. Can you give an example. For example, almost none of the bignum calls (BN_.*) are checked for error returns, the OpensSSL documentation explicitly states that you always have to check returns because it uses dynamic memory allocation and thus allocation failures might occur. Looking around in the code, I also found a call to HMAC_Init(), for example, which I'm pretty sure also uses dynamic allocation (and in any case, the OpenSSL documentation shows that is has an error return, even though the possible causes of failure are not listed), and then there are all those _Init calls and the like, of which I don't have a clue whether they do use dynamic allocation, but in any case, the OpenSSL documentation shows they also have error returns, and those generally don't seem to be checked either. > >IIUC, OpenSSL is configured > >to use enif_alloc(), which according to this ... > > > >http://www.erlang.org/doc/man/erl_nif.html#enif_alloc > > > >... will return NULL in case of an allocation failure. Now, is that there > >just to confuse people because the function doesn't actually ever return in > >case of an allocation failure, or is this really severely broken? Am I > >missing something? > enif_alloc calls erts_alloc_fnf where "fnf" stands for "Failure Not > Fatal" which means that it will return NULL on failure. IC - I didn't quite manage to penetrate all the allocator indirections, though I didn't try too hard ;-) Regards, Florian From davidnwelton@REDACTED Wed Dec 18 12:05:52 2013 From: davidnwelton@REDACTED (David Welton) Date: Wed, 18 Dec 2013 12:05:52 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52AAD087.6010407@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: Hi, > Next release is R17pre sometime in Jan > So, If this fix that Anthony sent : > > git fetchhttps://github.com/nox/otp.git fix-OTP-11506 > > > https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506 > > https://github.com/nox/otp/compare/erlang:maint...fix-OTP-11506.patch > > > Fixes the problem, you might have to apply that yourself until we merge it > into master. Applying a patch does not do much for code like Chicago Boss that people will download and try with "the latest Erlang". What is necessary is some code that will do case erlang:system_info(otp_release) of "R16B03" -> ... mangle the AST in such a way to not make the parse transform barf...; _ -> ok end. I've been looking at how to do this, but I'm afraid my knowledge of this part of Erlang is not quite up to the task so far. Thank you, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From essen@REDACTED Wed Dec 18 12:12:51 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 18 Dec 2013 12:12:51 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> Message-ID: <52B18333.8090807@ninenines.eu> On 12/18/2013 12:05 PM, David Welton wrote: > What is necessary is some code that will do > > case erlang:system_info(otp_release) of > "R16B03" -> > ... mangle the AST in such a way to not make the parse transform barf...; > _ -> ok > end. Don't do that, this doesn't mean that the syntax_tools application will actually be the one that shipped with R16B03. Check the application version instead: application:get_key(syntax_tools, vsn). (Note that this is only available after the application is loaded.) -- Lo?c Hoguin http://ninenines.eu From davidnwelton@REDACTED Wed Dec 18 12:28:20 2013 From: davidnwelton@REDACTED (David Welton) Date: Wed, 18 Dec 2013 12:28:20 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52B18333.8090807@ninenines.eu> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> Message-ID: > Don't do that, Looking at version numbers like this is not something I'm in the habit of doing often... > this doesn't mean that the syntax_tools application will > actually be the one that shipped with R16B03. Check the application version > instead: application:get_key(syntax_tools, vsn). (Note that this is only > available after the application is loaded.) I don't know how those numbers are managed, but the vsn.mk file in master still has SYNTAX_TOOLS_VSN = 1.6.12, which is the same as I get from my Erlang shell in R16B03; presumably, since the code in master has been patched, the version number should get bumped? -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From henrik@REDACTED Thu Dec 19 10:12:14 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 10:12:14 +0100 Subject: [erlang-patches] Fix evaluation of and also and orelse in the debugger In-Reply-To: <69CBECDF-CE28-4394-B0EF-D55641807695@gmail.com> References: <69CBECDF-CE28-4394-B0EF-D55641807695@gmail.com> Message-ID: <52B2B86E.9010409@erlang.org> Thanks! As always we will take a look, expect delays due to holidays On 2013-12-16 12:50, Anthony Ramine wrote: > Hello, > > While implementing cond, I stumbled onto that bug. > > git fetch https://github.com/nox/otp.git fix-dbg_ieval-exporting-rules > > https://github.com/erlang/otp/pull/171 > > https://github.com/nox/otp/compare/fix-dbg_ieval-exporting-rules > https://github.com/nox/otp/compare/fix-dbg_ieval-exporting-rules.patch > > Regards, > -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Dec 19 10:18:58 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 10:18:58 +0100 Subject: [erlang-patches] [erlang-bugs] ssh_cli error during start_shell In-Reply-To: References: Message-ID: <52B2BA02.7090804@erlang.org> Thank you! We will take a look at this, expect delay due to holidays. On 2013-12-17 04:33, Anton Ryabkov wrote: > Hello, > > on Erlang R16B03 I've found that ssh_cli crushed with function_clause, > when I trying connected by ssh to my ssh daemon. Error: > ... > ** {function_clause,[{proplists,get_value, > [user,{ok,[]},undefined], > [{file,"proplists.erl"},{line,225}]}, > {ssh_cli,start_shell,2,[{file,"ssh_cli.erl"},{line,457}]}, > {ssh_cli,handle_ssh_msg,2, > [{file,"ssh_cli.erl"},{line,107}]}, > {ssh_channel,handle_info,2, > [{file,"ssh_channel.erl"},{line,241}]}, > {gen_server,handle_msg,5, > [{file,"gen_server.erl"},{line,604}]}, > {proc_lib,init_p_do_apply,3, > [{file,"proc_lib.erl"},{line,239}]}]} > > Note: all error in the file error. > > Steps to reproduce: > 1. compile ssh_bug.erl > 2. ssh_bug:test(). > 3. connect by ssh: ssh localhost -p9876 > 4. look at erlang concole for error. > > The reason of the bug is getting ConnectionInfo in the ssh_cli. > Instead of use ssh_connection_handler:connection_info method to get > ConnectionInfo used ssh_connection_handler:info. > > Patch for current bug: > 452c452 > < ConnectionInfo = ssh_connection_handler:info(ConnectionHandler, > --- > > ConnectionInfo = > ssh_connection_handler:connection_info(ConnectionHandler, > 456c456 > < {ok, User} = > --- > > User = > 462c462 > < [{_, PeerAddr}] = > --- > > {_, PeerAddr} = > 480c480 > < ConnectionInfo = ssh_connection_handler:info(ConnectionHandler, > --- > > ConnectionInfo = > ssh_connection_handler:connection_info(ConnectionHandler, > 482c482 > < {ok, User} = > --- > > User = > 491c491 > < [{_, PeerAddr}] = > --- > > {_, PeerAddr} = > > > Sample, error and patch in the attach. > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- /Henrik Nord Erlang/OTP -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Thu Dec 19 10:22:04 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 10:22:04 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> Message-ID: <52B2BABC.4060701@erlang.org> On 2013-12-18 12:28, David Welton wrote: >> Don't do that, > Looking at version numbers like this is not something I'm in the habit > of doing often... > >> this doesn't mean that the syntax_tools application will >> actually be the one that shipped with R16B03. Check the application version >> instead: application:get_key(syntax_tools, vsn). (Note that this is only >> available after the application is loaded.) > I don't know how those numbers are managed, but the vsn.mk file in > master still has SYNTAX_TOOLS_VSN = 1.6.12, which is the same as I get > from my Erlang shell in R16B03; presumably, since the code in master > has been patched, the version number should get bumped? Problem is that we usually bump the version only when we do a release, (includes major, minor and patch releases) /Henrik Nord Erlang/OTP From bgustavsson@REDACTED Thu Dec 19 11:36:15 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 19 Dec 2013 11:36:15 +0100 Subject: [erlang-patches] compile: asm and core options In-Reply-To: References: <52A714E2.8090005@erlang.org> Message-ID: On Fri, Dec 13, 2013 at 3:26 PM, Tuncer Ayaz wrote: > > > Yes, it should warn about a removal in R18. Also, of course 'asm' should > be un-documented; I'm sorry if I wasn't clear in the previous email. > > Updated the branch accordingly, please re-fetch. > Tested and merged. I have also merged Anthony's branch that fix the optimization passes so that they can handle assembly code that has already been optimized. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Thu Dec 19 11:36:24 2013 From: henrik@REDACTED (Henrik Nord) Date: Thu, 19 Dec 2013 11:36:24 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52B18333.8090807@ninenines.eu> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> Message-ID: <52B2CC28.80801@erlang.org> Hi We will not merge this patch just before Christmas and release a R16B03-1. Our suggestion is that: 1. If you are affected by this bug, apply the patch yourself until it will be merged into Erlang/OTP. (probably 17rc1 late January) 2. If you are using chicagoboss, stay on R16B02 if possible. 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for download on chicagoboss.org for R16B03 users. 4. add the patch to the rebar deps of chicagoboss. We will try to make sure things like this do not sneak into releases in the future, and apologise for the inconvenience caused. -- /Henrik Nord Erlang/OTP From davidnwelton@REDACTED Thu Dec 19 11:43:52 2013 From: davidnwelton@REDACTED (David Welton) Date: Thu, 19 Dec 2013 11:43:52 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52B2BABC.4060701@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2BABC.4060701@erlang.org> Message-ID: Hi, >> I don't know how those numbers are managed, but the vsn.mk file in >> master still has SYNTAX_TOOLS_VSN = 1.6.12, which is the same as I get >> from my Erlang shell in R16B03; presumably, since the code in master >> has been patched, the version number should get bumped? > > > Problem is that we usually bump the version only when we do a release, > (includes major, minor and patch releases) The functionality changed, in a way that's not backwards compatible, so by my understanding of something like http://semver.org/ it'd be a good idea to change the major number of the syntax_tools application. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From n.oxyde@REDACTED Thu Dec 19 11:47:13 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 19 Dec 2013 11:47:13 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52B2CC28.80801@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2CC28.80801@erlang.org> Message-ID: <2DE1069F-55EA-45CA-89F1-75B390C837A8@gmail.com> Hello, With all due respect, that is completely irresponsible. Regards, -- Anthony Ramine Le 19 d?c. 2013 ? 11:36, Henrik Nord a ?crit : > Hi > > We will not merge this patch just before Christmas and release a R16B03-1. > > Our suggestion is that: > 1. If you are affected by this bug, apply the patch yourself until it will be merged into Erlang/OTP. (probably 17rc1 late January) > 2. If you are using chicagoboss, stay on R16B02 if possible. > 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for download on chicagoboss.org for R16B03 users. > 4. add the patch to the rebar deps of chicagoboss. > > We will try to make sure things like this do not sneak into releases in the future, and apologise for the inconvenience caused. > > > -- > /Henrik Nord Erlang/OTP > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From essen@REDACTED Thu Dec 19 11:55:46 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 19 Dec 2013 11:55:46 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2BABC.4060701@erlang.org> Message-ID: <52B2D0B2.9070600@ninenines.eu> On 12/19/2013 11:43 AM, David Welton wrote: > Hi, > >>> I don't know how those numbers are managed, but the vsn.mk file in >>> master still has SYNTAX_TOOLS_VSN = 1.6.12, which is the same as I get >>> from my Erlang shell in R16B03; presumably, since the code in master >>> has been patched, the version number should get bumped? >> >> >> Problem is that we usually bump the version only when we do a release, >> (includes major, minor and patch releases) > > The functionality changed, in a way that's not backwards compatible, > so by my understanding of something like http://semver.org/ it'd be a > good idea to change the major number of the syntax_tools application. That only applies to releases. If there's no release there's no need to bump anything. -- Lo?c Hoguin http://ninenines.eu From davidnwelton@REDACTED Thu Dec 19 11:56:52 2013 From: davidnwelton@REDACTED (David Welton) Date: Thu, 19 Dec 2013 11:56:52 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: <52B2CC28.80801@erlang.org> 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2CC28.80801@erlang.org> Message-ID: Hi, > We will not merge this patch just before Christmas and release a R16B03-1. Ok. > Our suggestion is that: > 1. If you are affected by this bug, apply the patch yourself until it will > be merged into Erlang/OTP. (probably 17rc1 late January) That's not really a workable solution for most people using CB. Zach can correct me if I'm wrong, but I think the idea is going to simply put a warning in CB so that people trying to use it with a R16B03 - pretty much anyone who gets the "latest and greatest" from, say, Erlang Solutions .deb repository - will get a user friendly message saying that that release of Erlang is incompatible with Chicago Boss, so please downgrade. > 2. If you are using chicagoboss, stay on R16B02 if possible. That probably works now that people have been warned. > 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for > download on chicagoboss.org for R16B03 users. I am not an Erlang power user like you guys, but is it possible to include that code in CB itself, and conditionally load it, overriding the system version of that file, in the case of R16B03? > 4. add the patch to the rebar deps of chicagoboss. I think something like this could work too, but i don't know the details of how it would work out. > We will try to make sure things like this do not sneak into releases in the > future, and apologise for the inconvenience caused. I'm just a Chicago Boss user trying to figure out a solution that improves things for everyone. I realize that parse_transforms are kind of a 'dark corner' of Erlang, so I appreciate the help. Thank you -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From bjorn@REDACTED Thu Dec 19 12:23:28 2013 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 19 Dec 2013 12:23:28 +0100 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: Message-ID: On Mon, Sep 30, 2013 at 9:38 AM, Steve Vinoski wrote: > 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. > > > We like optimizations and we like simple, elegant code, so this patch has been a tricky one to review. In the end, we reached the conclusion that we like the improvements of orddict:from_list/1. We reject the optimizations of the other functions (is_key/2, fetch/2, find/2) for the following reasons: The optimization depends on the lists:keyfind/3 function being implemented as a BIF. That sort of optimization is fine in a specific application if you have measured and found that it really makes a difference; I would avoid it in other circumstances. All the compatibility code further destroys the elegance. Because of the compatibility code find/2 and is_key/2 do not get faster if the key is missing in the dictionary; that is unfortunate since you use find/2 if you cannot be sure that the key is present and fetch/2 if you know that the key is present. Because the internal representation of orddict is intentionally documented, an application can use lists:keyfind/3 directly if needed and it does not have to worry about about compatibility. Regarding the from_list/1 function, I am not sure that it is necessary to force a function_clause error. The original code could either crash in store/3 or in lists:foldl/3 when given illegal input. Also, from_list/1 depends on lists:reverse/1 being implemented as a BIF; I think it would be more elegant to check and reverse at the same time: reverse_pairs([{_,_}=H|T], Acc) -> reverse_pairs(T, [H|Acc]); reverse_pairs([], Acc) -> Acc. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Thu Dec 19 13:56:15 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 19 Dec 2013 13:56:15 +0100 Subject: [erlang-patches] [erlang-bugs] syntax_tools anonymous function error In-Reply-To: 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> <524D636B.4080508@erlang.org> <3D1D6E35-2562-438E-8B6C-9BCE51B04457@gmail.com> <5280ECDD.3020001@erlang.org> <51F1416E-F323-47A0-A17A-334E01310C8B@gmail.com> <52AAD087.6010407@erlang.org> <52B18333.8090807@ninenines.eu> <52B2CC28.80801@erlang.org> Message-ID: I have pushed a workaround for parse_trans. https://github.com/uwiger/parse_trans/blob/master/doc/parse_trans.md#revert-1 parse_trans:revert/1 and parse_trans:revert_form/1 should be usable as drop-in replacements to erl_syntax:revert(). The workaround verifies that a transform is actually needed by generating a dummy module, reverting it and feeding it to the linter; if the linter crashes, the abstract code needs to be fixed. BR, Ulf W On 19 Dec 2013, at 11:56, David Welton wrote: > Hi, > >> We will not merge this patch just before Christmas and release a R16B03-1. > > Ok. > >> Our suggestion is that: >> 1. If you are affected by this bug, apply the patch yourself until it will >> be merged into Erlang/OTP. (probably 17rc1 late January) > > That's not really a workable solution for most people using CB. Zach > can correct me if I'm wrong, but I think the idea is going to simply > put a warning in CB so that people trying to use it with a R16B03 - > pretty much anyone who gets the "latest and greatest" from, say, > Erlang Solutions .deb repository - will get a user friendly message > saying that that release of Erlang is incompatible with Chicago Boss, > so please downgrade. > >> 2. If you are using chicagoboss, stay on R16B02 if possible. > > That probably works now that people have been warned. > >> 3. compile "lib/syntax_tools/src/erl_syntax.erl" and put the beam up for >> download on chicagoboss.org for R16B03 users. > > I am not an Erlang power user like you guys, but is it possible to > include that code in CB itself, and conditionally load it, overriding > the system version of that file, in the case of R16B03? > >> 4. add the patch to the rebar deps of chicagoboss. > > I think something like this could work too, but i don't know the > details of how it would work out. > >> We will try to make sure things like this do not sneak into releases in the >> future, and apologise for the inconvenience caused. > > I'm just a Chicago Boss user trying to figure out a solution that > improves things for everyone. I realize that parse_transforms are > kind of a 'dark corner' of Erlang, so I appreciate the help. > > Thank you > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From ulf@REDACTED Thu Dec 19 14:12:08 2013 From: ulf@REDACTED (Ulf Wiger) Date: Thu, 19 Dec 2013 14:12:08 +0100 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: Message-ID: <23E20F8A-B8FE-4FD2-BEDA-3FE2D9A859BA@feuerlabs.com> On 19 Dec 2013, at 12:23, Bj?rn Gustavsson wrote: > The optimization depends on the lists:keyfind/3 function > being implemented as a BIF. That sort of > optimization is fine in a specific application if you > have measured and found that it really makes a difference; > I would avoid it in other circumstances. I think that any future change that would make lists:keyfind/3 or lists:reverse/1 significantly *slower* than they are today, would struggle for acceptance by the community. ;-) In practice, I would say that a great deal of code out there depends on these functions being highly efficient - whether or not they are implemented as BIFs. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Thu Dec 19 15:41:54 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 19 Dec 2013 09:41:54 -0500 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: Message-ID: Hi Bj?rn, thanks for the explanation. Is there any more work I need to do for this patch? --steve On Thu, Dec 19, 2013 at 6:23 AM, Bj?rn Gustavsson wrote: > On Mon, Sep 30, 2013 at 9:38 AM, Steve Vinoski wrote: > >> 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. >> >> >> > We like optimizations and we like simple, elegant > code, so this patch has been a tricky one to review. > > In the end, we reached the conclusion that we like > the improvements of orddict:from_list/1. > > We reject the optimizations of the other functions > (is_key/2, fetch/2, find/2) for the following reasons: > > The optimization depends on the lists:keyfind/3 function > being implemented as a BIF. That sort of > optimization is fine in a specific application if you > have measured and found that it really makes a difference; > I would avoid it in other circumstances. > > All the compatibility code further destroys the > elegance. Because of the compatibility code find/2 and > is_key/2 do not get faster if the key is missing in > the dictionary; that is unfortunate since you use find/2 > if you cannot be sure that the key is present and fetch/2 > if you know that the key is present. > > Because the internal representation of orddict is > intentionally documented, an application can use > lists:keyfind/3 directly if needed and it does not have > to worry about about compatibility. > > Regarding the from_list/1 function, I am not sure that > it is necessary to force a function_clause error. > The original code could either crash in store/3 or in > lists:foldl/3 when given illegal input. Also, from_list/1 > depends on lists:reverse/1 being implemented as a BIF; I > think it would be more elegant to check and reverse at > the same time: > > reverse_pairs([{_,_}=H|T], Acc) -> > reverse_pairs(T, [H|Acc]); > reverse_pairs([], Acc) -> Acc. > > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Thu Dec 19 16:11:18 2013 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 19 Dec 2013 16:11:18 +0100 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: Message-ID: On Thu, Dec 19, 2013 at 3:41 PM, Steve Vinoski wrote: > Hi Bj?rn, thanks for the explanation. Is there any more work I need to do > for this patch? > > Yes, we are still in orddict:from_list/1, so it would be nice if you could produce a single commit with the update of from_list/1. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas@REDACTED Thu Dec 19 18:24:02 2013 From: thomas@REDACTED (Thomas Lange) Date: Thu, 19 Dec 2013 18:24:02 +0100 Subject: [erlang-patches] [PATCH] Add missing semicolon to example code Message-ID: <1387473842-14244-1-git-send-email-thomas@corelatus.se> Signed-off-by: Thomas Lange --- system/doc/reference_manual/expressions.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/system/doc/reference_manual/expressions.xml b/system/doc/reference_manual/expressions.xml index e9de3e0..16a4a81 100644 --- a/system/doc/reference_manual/expressions.xml +++ b/system/doc/reference_manual/expressions.xml @@ -1177,7 +1177,7 @@ termize_file(Name) -> try Expr catch throw:Term -> Term; - exit:Reason -> {'EXIT',Reason} + exit:Reason -> {'EXIT',Reason}; error:Reason -> {'EXIT',{Reason,erlang:get_stacktrace()}} end -- 1.7.10.4 From vinoski@REDACTED Fri Dec 20 02:05:28 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Thu, 19 Dec 2013 20:05:28 -0500 Subject: [erlang-patches] improved orddict performance In-Reply-To: References: Message-ID: I've modified the branch as requested. https://github.com/erlang/otp/pull/91 --steve On Thu, Dec 19, 2013 at 10:11 AM, Bj?rn Gustavsson wrote: > On Thu, Dec 19, 2013 at 3:41 PM, Steve Vinoski wrote: > >> Hi Bj?rn, thanks for the explanation. Is there any more work I need to do >> for this patch? >> >> > Yes, we are still in orddict:from_list/1, so it > would be nice if you could produce a single > commit with the update of from_list/1. > > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Fri Dec 20 16:13:42 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Fri, 20 Dec 2013 16:13:42 +0100 Subject: [erlang-patches] [PATCH] crypto: fix a few memleaks/undefined pointer dereferences In-Reply-To: <20131216162423.GX5636@florz.florz.dyndns.org> References: <20131216121905.GO5636@florz.florz.dyndns.org> <52AF1B0A.3010704@erix.ericsson.se> <20131216162423.GX5636@florz.florz.dyndns.org> Message-ID: <52B45EA6.6020703@ericsson.com> On 12/16/2013 05:24 PM, Florian Zumbiehl wrote: >>> what I am wondering about is >>> whether it is correct that almost none of the OpenSSL calls in crypto are >>> being checked for memory allocation failures!? >> Not sure what you mean. Can you give an example. > For example, almost none of the bignum calls (BN_.*) are checked for error > returns, the OpensSSL documentation explicitly states that you always have > to check returns because it uses dynamic memory allocation and thus > allocation failures might occur. Looking around in the code, I also found a > call to HMAC_Init(), for example, which I'm pretty sure also uses dynamic > allocation (and in any case, the OpenSSL documentation shows that is has an > error return, even though the possible causes of failure are not listed), > and then there are all those _Init calls and the like, of which > I don't have a clue whether they do use dynamic allocation, but in any > case, the OpenSSL documentation shows they also have error returns, and > those generally don't seem to be checked either. > A simple fix to this would be to let the crypto_alloc (in crypto_callback.c) to call abort() if the allocation failed as that is the strategy otherwise in out-of-memory scenarios. Thus a "nice crash" with an "Out of memory" message instead of a segmentation violation. /Sverker