From mikpelinux@REDACTED Wed Feb 4 21:08:04 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Wed, 4 Feb 2015 21:08:04 +0100 Subject: [erlang-patches] don't create oversize bignums in binary matching Message-ID: <21714.31780.65297.891775@gargle.gargle.HOWL> Bignums are artifically restricted in size. Arithmetic and logical operations check the sizes of resulting bignums, and turn oversize results into system_limit exceptions. However, this check is not performed when bignums are constructed by binary matching. The consequence is that such matchings can construct oversize bignums that satisfy is_integer/1 yet don't work. Performing arithmetic such as Term - 0 fails with a system_limit exception. Worse, performing a logical operation such as Term band Term results in []. The latter occurs because the size checking (e.g. in erts_band()) is a simple ASSERT(is_not_nil(...)) on the result of the bignum operation, which internally is [] (NIL) in the case of oversize results. However, ASSERT is a no-op in release builds, so the error goes unnoticed and [] is returned as the result of the band/2. This patch addresses this by preventing oversize bignums from entering the VM via binary matching: - the internal bytes_to_big() procedure is augmented to return NIL for oversize results, just like big_norm() - callers of bytes_to_big() are augmented to check for NIL returns and signal errors in those cases - erts_bs_get_integer_2() can only fail with badmatch, so that is the Erlang-level result of oversize bignums from binary matches - big_SUITE.erl is extended with a test case that fails without this fix (no error signalled) and passes with it (badmatch occurs) Credit goes to Nico Kruber for the initial bug report. Signed-off-by: Mikael Pettersson Links: git fetch git://github.com/mikpe/otp.git avoid-oversize-bignums https://github.com/mikpe/otp/compare/erlang:maint...avoid-oversize-bignums https://github.com/mikpe/otp/compare/erlang:maint...avoid-oversize-bignums.patch https://github.com/erlang/otp/pull/603 From mikpelinux@REDACTED Sun Feb 8 21:42:40 2015 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 8 Feb 2015 21:42:40 +0100 Subject: [erlang-patches] remove perfctr support Message-ID: <21719.51776.31016.421514@gargle.gargle.HOWL> Perfctr is a Linux kernel extension that allows programmatic access to the performance monitoring counters found in most current CPUs. However, development of perfctr ceased after 2010, and it cannot be used with Linux kernels newer than 2.6.32. Therefore the perfctr support code in the Erlang VM is effectively dead code, so this patch removes it. Signed-off-by: Mikael Pettersson Links: git fetch git://github.com/mikpe/otp.git remove-perfctr-support https://github.com/mikpe/otp/compare/erlang:maint...remove-perfctr-support https://github.com/mikpe/otp/compare/erlang:maint...remove-perfctr-support.patch https://github.com/erlang/otp/pull/610 From henrik@REDACTED Wed Feb 11 11:10:19 2015 From: henrik@REDACTED (Henrik Nord) Date: Wed, 11 Feb 2015 11:10:19 +0100 Subject: [erlang-patches] Non-overlapping Application Distribution Node Sets In-Reply-To: <20140218083918.GJ96250@wavenets-mbp.motivity.ca> References: <51837891.9020207@erlang.org> <20130503134345.GB21384@aluminium> <5188BDFB.8090703@erlang.org> <20130508133013.GR31110@aluminium.local> <518A5581.2080401@erlang.org> <20130613091638.GE32127@aluminium.local> <20130614033619.GF32127@aluminium.local> <5301CF96.5070507@erlang.org> <20140218083918.GJ96250@wavenets-mbp.motivity.ca> Message-ID: <54DB2A8B.6050802@erlang.org> Hi again! I might have missed some kind of update to this? Or are we in really long weeks mode =) I would suggest you open a Pull Request on github for this patch when(if) you decide to work on it again. Thank you On 2014-02-18 09:39, Vance Shipley wrote: > Henrik, > > Yes, I haven't forgotten about this. It will get the required attention > in the next few weeks. > -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Feb 12 10:20:10 2015 From: henrik@REDACTED (Henrik Nord) Date: Thu, 12 Feb 2015 10:20:10 +0100 Subject: [erlang-patches] [PATCH] - Add NIF function enif_phash2 In-Reply-To: References: Message-ID: <54DC704A.9040607@erlang.org> Hello! This patch has now seen 2 years of inactivity. If you are willing to, please re-base upon current master and open a Pull request towards Erlang/otp on github. Thank you On 2013-02-08 00:58, Paul Davis wrote: > git fetch git://github.com/davisp/otp.git enif_phash2 > > https://github.com/davisp/otp/compare/maint...enif_phash2 > https://github.com/davisp/otp/compare/maint...enif_phash2.patch > > This patch exposes the phash2 function to NIFs. It is exactly equivalent to: > > erlang:phash2(Term, 16#100000000) > > Thanks, > Paul Davis > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /Henrik Nord Erlang/OTP From henrik@REDACTED Thu Feb 12 10:27:55 2015 From: henrik@REDACTED (Henrik Nord) Date: Thu, 12 Feb 2015 10:27:55 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <50EEE304.3030309@erlang.org> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <50EEE304.3030309@erlang.org> Message-ID: <54DC721B.2000902@erlang.org> Hello Anthony! Whats the status of this patch? nox/rm-reverse-eta-conversion https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion Open a PR if it is still relevant, Im closing this specific patch thread. -- /Henrik Nord Erlang/OTP From n.oxyde@REDACTED Thu Feb 12 11:35:30 2015 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 12 Feb 2015 11:35:30 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <54DC721B.2000902@erlang.org> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <50EEE304.3030309@erlang.org> <54DC721B.2000902@erlang.org> Message-ID: <9F901833-D3DD-4BC0-BD54-3E44C09813E4@gmail.com> Hello Henrik, Kostis was supposed to come back to me to talk about this patch but I'm still waiting, you can close that thread. Le 12 f?vr. 2015 ? 10:27, Henrik Nord a ?crit : > Hello Anthony! > > Whats the status of this patch? > nox/rm-reverse-eta-conversion > https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion > > Open a PR if it is still relevant, Im closing this specific patch thread. > > -- > /Henrik Nord Erlang/OTP > From bgustavsson@REDACTED Wed Feb 25 11:37:03 2015 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 25 Feb 2015 11:37:03 +0100 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: References: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> <8B4CFDC7-B801-419A-B865-BA4A6279AAFE@gmail.com> Message-ID: On Mon, Dec 16, 2013 at 12:59 PM, Bj?rn Gustavsson wrote: > 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. > If you want to do further work on this topic, create a pull request. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From egil@REDACTED Wed Feb 25 11:58:59 2015 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Wed, 25 Feb 2015 11:58:59 +0100 Subject: [erlang-patches] Attempt at making stacktraces more readable In-Reply-To: References: <4550E589-CD0A-4660-8B7E-9CF053B6F262@gmail.com> <8B4CFDC7-B801-419A-B865-BA4A6279AAFE@gmail.com> Message-ID: <54EDAAF3.9070107@erlang.org> On 2015-02-25 11:37, Bj?rn Gustavsson wrote: > On Mon, Dec 16, 2013 at 12:59 PM, Bj?rn Gustavsson > wrote: >> 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. >> > If you want to do further work on this topic, > create a pull request. > Anthony, beware .. as you probably already know this in the same area as https://github.com/erlang/otp/pull/359 If we can mitigate the memory issue, I think sending a term and then formatting it in Erlang would be better. Less code in beam is always better in my view. I haven't looked at the whole error-handling stack recently though, I could be missing something. // Bj?rn-Egil