From jimenezrick@REDACTED Thu Mar 1 14:16:06 2012 From: jimenezrick@REDACTED (Ricardo Catalinas =?iso-8859-1?Q?Jim=E9nez?=) Date: Thu, 1 Mar 2012 14:16:06 +0100 Subject: [erlang-patches] Fix global:{random_exit_name, random_notify_name}/3 spec Message-ID: <20120301131606.GE847@viper.local> Both functions return pid(), not 'none'. The one that always returns 'none' is notify_all_name/3. Please fetch: git fetch git://github.com/jimenezrick/otp.git fix-global-spec Review here: https://github.com/jimenezrick/otp/compare/erlang:maint...fix-global-spec https://github.com/jimenezrick/otp/compare/erlang:maint...fix-global-spec.patch Regards -- Ricardo (http://r.untroubled.be/) From aronisstav@REDACTED Thu Mar 1 14:24:54 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Thu, 1 Mar 2012 14:24:54 +0100 Subject: [erlang-patches] Dialyzer fixes In-Reply-To: References: Message-ID: The branch has been updated with two commits. Please re-fetch: git fetch git://github.com/aronisstav/otp.git dialyzer-fixes Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav@REDACTED Thu Mar 1 15:18:46 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Thu, 1 Mar 2012 15:18:46 +0100 Subject: [erlang-patches] Fix global:{random_exit_name, random_notify_name}/3 spec In-Reply-To: <20120301131606.GE847@viper.local> References: <20120301131606.GE847@viper.local> Message-ID: <4F4F8546.3000406@erlang.org> We have included this patch in our 'pu' branch. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-01 14:16, Ricardo Catalinas Jim?nez wrote: > Both functions return pid(), not 'none'. The one that always returns > 'none' is notify_all_name/3. > > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-global-spec > > Review here: > https://github.com/jimenezrick/otp/compare/erlang:maint...fix-global-spec > https://github.com/jimenezrick/otp/compare/erlang:maint...fix-global-spec.patch > > > Regards From gustav@REDACTED Thu Mar 1 15:19:59 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Thu, 1 Mar 2012 15:19:59 +0100 Subject: [erlang-patches] Dialyzer fixes In-Reply-To: References: Message-ID: <4F4F858F.9040905@erlang.org> We've refetched this patch and included the new version in the 'pu' branch. Thank you for the update! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-01 14:24, Stavros Aronis wrote: > The branch has been updated with two commits. Please re-fetch: > > git fetch git://github.com/aronisstav/otp.git > dialyzer-fixes > > Stavros > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhunleth@REDACTED Thu Mar 1 16:30:08 2012 From: fhunleth@REDACTED (Frank Hunleth) Date: Thu, 1 Mar 2012 10:30:08 -0500 Subject: [erlang-patches] Updates for cross-compiling HiPE Message-ID: Hi all, I've made a couple updates to support cross-compiling HiPE. I've split these into two patches. The first is a trivial update to configure.in which seems like it should be generally useful even for people not cross-compiling. The second is the addition of qemu-user to the build process so that cross-compiled binaries can be run as part of the build process. I needed this to be able to run hipe_mkliterals without major makefile surgery. In the future, the use of qemu-user seems like it may be useful for cross-compiling beams. I have not looked into that yet. The first patch is here: git fetch git://github.com/fhunleth/otp.git add_arch_and_opsys_to_configure https://github.com/fhunleth/otp/compare/add_arch_and_opsys_to_configure https://github.com/fhunleth/otp/compare/add_arch_and_opsys_to_configure.patch Hopefully the patch and commit comment make sense. The second patch to add qemu-user support is here: git fetch git://github.com/fhunleth/otp.git add_qemu_user_support_for_crosscompiling https://github.com/fhunleth/otp/compare/add_qemu_user_support_for_crosscompiling https://github.com/fhunleth/otp/compare/add_qemu_user_support_for_crosscompiling.patch I have attempted to test both of these patches (for an ARM target) and others have told me that the cross-compiled version of HiPE works for them. However, if there are any particular tests that I should run on the target, please let me know. Thanks, Frank From jimenezrick@REDACTED Thu Mar 1 20:16:29 2012 From: jimenezrick@REDACTED (=?UTF-8?Q?Ricardo_Catalinas_Jim=C3=A9nez?=) Date: Thu, 1 Mar 2012 20:16:29 +0100 Subject: [erlang-patches] Fix global:{random_exit_name, random_notify_name}/3 spec In-Reply-To: <4F4F8546.3000406@erlang.org> References: <20120301131606.GE847@viper.local> <4F4F8546.3000406@erlang.org> Message-ID: Please refetch, I added another commit: Improve global:re_register_name/2,3 spec Both functions always return `yes'. - I am not a dialyzer expert, so maybe this change is not correct. I mean, both functions, in the normal execution path, always return `yes', but the function call could fail if something goes wrong. I am not totally sure if the spec has to reflect that. - Any feedback on this other patch I sent?: Fix supervisor doc: Shutdown, MaxR and MaxT type specs http://erlang.org/pipermail/erlang-patches/2012-February/002682.html Best regards On Thu, Mar 1, 2012 at 3:18 PM, Gustav Simonsson wrote: > We have included this patch in our 'pu' branch. > Thank you for the contribution! > > Regards, > Gustav Simonsson > Erlang/OTP team > > > On 2012-03-01 14:16, Ricardo Catalinas Jim?nez wrote: >> >> Both functions return pid(), not 'none'. The one that always returns >> 'none' is notify_all_name/3. >> >> Please fetch: >> git fetch git://github.com/jimenezrick/otp.git fix-global-spec >> >> Review here: >> https://github.com/jimenezrick/otp/compare/erlang:maint...fix-global-spec >> >> https://github.com/jimenezrick/otp/compare/erlang:maint...fix-global-spec.patch >> >> >> Regards > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- Ricardo From gustav@REDACTED Fri Mar 2 16:40:56 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Fri, 2 Mar 2012 16:40:56 +0100 Subject: [erlang-patches] Fix supervisor doc: Shutdown, MaxR and MaxT type specs In-Reply-To: <20120224141004.GB821@viper.local> References: <20120224141004.GB821@viper.local> Message-ID: <4F50EA08.4070908@erlang.org> Hi Ricardo, This patch looks good, we'll include it (possibly with some edits) into the 'pu' branch. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-02-24 15:10, Ricardo Catalinas Jim?nez wrote: > The next code snippets from supervisor.erl show that Shutdown from a > child specification must be greater than zero and the same applies to > MaxT. > > --- supervisor.erl ---------------------------------------------------------- > validShutdown(Shutdown, _) > when is_integer(Shutdown), Shutdown> 0 -> true; > validShutdown(infinity, _) -> true; > validShutdown(brutal_kill, _) -> true; > validShutdown(Shutdown, _) -> throw({invalid_shutdown, Shutdown}). > > validIntensity(Max) when is_integer(Max), > Max>= 0 -> true; > validIntensity(What) -> throw({invalid_intensity, What}). > > validPeriod(Period) when is_integer(Period), > Period> 0 -> true; > validPeriod(What) -> throw({invalid_period, What}). > ----------------------------------------------------------------------------- > > I fixed the supervisor doc and made minor cosmetic changes. > > > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-supervisor-shutdown-doc > > Review here: > https://github.com/jimenezrick/otp/compare/erlang:maint...fix-supervisor-shutdown-doc > https://github.com/jimenezrick/otp/compare/erlang:maint...fix-supervisor-shutdown-doc.patch > > > Regards From vladdu55@REDACTED Mon Mar 5 10:28:57 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 5 Mar 2012 10:28:57 +0100 Subject: [erlang-patches] Fix some malformed macros in wx Message-ID: wx.hrl and glu.hrl were defining macros that expand to malformed terms. git fetch git://github.com/vladdu/otp.git wx_macro_fixes https://github.com/vladdu/otp/compare/wx_macro_fixes https://github.com/vladdu/otp/compare/wx_macro_fixes.patch best regards, Vlad From vladdu55@REDACTED Mon Mar 5 10:30:25 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 5 Mar 2012 10:30:25 +0100 Subject: [erlang-patches] syntax error in xmerl_xlink.hrl Message-ID: A comma was missing from the record definition. git fetch git://github.com/vladdu/otp.git xmerl_macro_fixes https://github.com/vladdu/otp/compare/xmerl_macro_fixes https://github.com/vladdu/otp/compare/xmerl_macro_fixes.patch best regards, Vlad From vladdu55@REDACTED Mon Mar 5 10:32:01 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 5 Mar 2012 10:32:01 +0100 Subject: [erlang-patches] Syntax error in orber/src/corba_request.erl Message-ID: Syntax error in orber/src/corba_request.erl. git fetch git://github.com/vladdu/otp.git orber_corba_fix https://github.com/vladdu/otp/compare/orber_corba_fix https://github.com/vladdu/otp/compare/orber_corba_fix.patch best regards, Vlad From vladdu55@REDACTED Mon Mar 5 10:34:05 2012 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 5 Mar 2012 10:34:05 +0100 Subject: [erlang-patches] Malformed macros in orber_iiop.hrl Message-ID: Malformed macros in orber_iiop.hrl, missing commas in value. git fetch git://github.com/vladdu/otp.git orber_macro_fixes https://github.com/vladdu/otp/compare/orber_macro_fixes https://github.com/vladdu/otp/compare/orber_macro_fixes.patch best regards, Vlad From kostis@REDACTED Mon Mar 5 10:50:37 2012 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 05 Mar 2012 10:50:37 +0100 Subject: [erlang-patches] syntax error in xmerl_xlink.hrl In-Reply-To: References: Message-ID: <4F548C6D.9050907@cs.ntua.gr> On 03/05/2012 10:30 AM, Vlad Dumitrescu wrote: > A comma was missing from the record definition. > > git fetch git://github.com/vladdu/otp.git xmerl_macro_fixes > > https://github.com/vladdu/otp/compare/xmerl_macro_fixes > https://github.com/vladdu/otp/compare/xmerl_macro_fixes.patch Just wondering: Instead of fixing this syntax error (and the other ones in the patches submitted today by Vlad) wouldn't a patch that removes these record definitions and macros that are actually unused be a better alternative? Kostis From jay@REDACTED Tue Mar 6 06:09:37 2012 From: jay@REDACTED (Jay Nelson) Date: Mon, 5 Mar 2012 21:09:37 -0800 Subject: [erlang-patches] [PATCH] Add inets_sup:start_link/0 Message-ID: <1796C2E3-013F-495E-97AE-AEA66E653FD2@duomark.com> inets_app calls supervisor:start_link/3 directly rather than calling the root supervisor function inets_sup:start_link/0. This precludes using included_applications to start inets without having a wrapper function. This patch makes inets_app follow the standard OTP application structure. git fetch git://github.com/jaynel/otp.git inets_sup_start_link https://github.com/jaynel/otp/compare/inets_sup_start_link https://github.com/jaynel/otp/compare/inets_sup_start_link.patch jay From jose.valim@REDACTED Wed Mar 7 09:38:59 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 7 Mar 2012 09:38:59 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: Hello everyone, any feedback on the proposal below? Thanks. On Mon, Feb 20, 2012 at 5:18 PM, Jos? Valim wrote: > So here is a patch that allows ** in filelib:wildcard() in order to > support recursion. > > git fetch git://github.com/josevalim/otp.git double_star > > https://github.com/josevalim/otp/compare/double_star > https://github.com/josevalim/otp/compare/double_star.patch > > ** now works similarly to bash, ruby, racf, etc. For example, running > filelib:wildcard("**/*.erl", Cwd) will find all files ending with .erl in > the Cwd recursively. > > PS: I had some minor bumps in the road but in general I've found the > process of submitting patches to Erlang very well documented. So thanks to > those responsible for making this easy. :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav@REDACTED Wed Mar 7 14:58:05 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Wed, 7 Mar 2012 14:58:05 +0100 Subject: [erlang-patches] Malformed macros in orber_iiop.hrl In-Reply-To: References: Message-ID: <4F57696D.9080007@erlang.org> Hi Vlad! The patches for xmerl and wx will be dropped, because the affected code will be removed in a future Erlang release. The orber patches may be included pending a few internal decisions about that code. Regards, Gustav Simonsson Erlang/OTP team On 2012-03-05 10:34, Vlad Dumitrescu wrote: > Malformed macros in orber_iiop.hrl, missing commas in value. > > git fetch git://github.com/vladdu/otp.git orber_macro_fixes > > https://github.com/vladdu/otp/compare/orber_macro_fixes > https://github.com/vladdu/otp/compare/orber_macro_fixes.patch > > best regards, > Vlad > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From serge@REDACTED Thu Mar 8 19:03:22 2012 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 08 Mar 2012 13:03:22 -0500 Subject: [erlang-patches] [erlang-questions] [patch] new float_to_list/2 In-Reply-To: <4D90ABBD.8050100@erix.ericsson.se> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> Message-ID: <4F58F46A.5050701@aleynikov.org> Dear Sverker, Sorry for a belated response. The following commit addresses three issues you indicated. Attached is also a small performance test program which illustrates that the new float_to_list/2 is about 6x faster than float_to_list/1: https://github.com/saleyn/otp/commit/d7a108f28fd8cd519852feb0233920af511b5eba git fetch git://github.com/saleyn/otp.git float_to_list_2 https://github.com/saleyn/otp/compare/float_to_list_2 https://github.com/saleyn/otp/compare/float_to_list_2.patch Executing the attachment test function: 1> test:test(1.0). float_to_list(1.000000, []) = {0.149531,"1.000000"} float_to_list(1.000000, [{decimals, 4}]) = {0.109001,"1.0000"} float_to_list(1.000000) = {0.629831,"1.00000000000000000000e+00"} ok Regards, Serge P.S. I don't have access to solaris and freebsd at the moment, but the code works on 32/64-bit linux, and is identical for those two platforms. On 3/28/2011 11:39 AM, Sverker Eriksson wrote: > Thanks for your patch. As you may have seen it did not make it into R14B02. > > Comments: > > 1. Test fail on some platforms (32-bit solaris, freebsd and 64-bit linux) > > float_to_list(1.0,[compact]) > > returns "1." instead of "1.0" > > > 2. Would like the interface to be extendable to support printf's %e and > %g formats in future. Maybe just rename 'precision' to 'decimals'. > > 3. Why is default 4 decimals when printf and io:format has 6 as default. > > > /Sverker, Erlang/OTP > > > > > Serge Aleynikov wrote: >> This implementation has been submitted as the pull request: >> >> https://github.com/erlang/otp/pull/9 >> >> This version is also optimized to run 5-10x faster than >> float_to_list/1 for floats under 2^52. >> >> Regards, >> >> Serge >> >> On 1/14/2011 10:33 AM, Gleb Peregud wrote: >>> Here's my patch: >>> >>> http://www.erlang.org/cgi-bin/ezmlm-cgi/4/43529 >>> >>> It uses double sprintf invocations. Your solution is clearly better (I >>> didn't knew it is possible to specify precision in args). >>> >>> Your benchmark shows that difference is negligible. Between integer as >>> a second parameter or a proplist (~0.4%). Though it might be a bit >>> more "stable" in terms of running time, but still probably not worth >>> considering it for performance reasons. It still may be useful in >>> terms of simpler API, but I have no strong opinion on it. >>> >>> So generally +1 on including Serge's patch into Erlang. Serge, can you >>> put it into GitHub pull request? As described here: >>> >>> https://github.com/erlang/otp/wiki/submitting-patches >>> >>> Best, >>> Gleb >>> >>> On Wed, Jan 12, 2011 at 18:13, Serge Aleynikov >>> wrote: >>>> I did a micro-benchmark on a slightly modified version of the BIF that >>>> accepts an integer as its options. The results shown below display a >>>> very >>>> insignificant difference between a call with no options and a call >>>> with an >>>> integer precision passed as the second argument: >>>> >>>> 1> test:test(). >>>> float_to_list(123.4, []) = {0.619512,"123.4000"} >>>> float_to_list(123.4, [{precision, 4}]) = {0.624895,"123.4000"} >>>> float_to_list(123.4, 4) = {0.622896,"123.4000"} >>>> >>>> The majority of time is actually spent in the printf(3) function, which >>>> takes longer to execute when given the "%.*f" argument compared to >>>> "%g" as >>>> in float_to_list/1 case. >>>> >>>> Did your patch rely on printf? >>>> >>>> >>>> On 1/12/2011 9:23 AM, Gleb Peregud wrote: >>>>> >>>>> Some time ago I've submitted similar but simpler patch. It was a >>>>> float_to_list/2 with a second parameter being an integer specifying >>>>> precision. For me it was important to generate A LOT of floats as >>>>> strings as fast as possible with specified precision. Serge's version >>>>> has an overhead of inspecting proplist of the second parameter. So I >>>>> was wondering about introducing two versions of this function: with a >>>>> proplist as a second parameter and with a number as a second >>>>> parameter. Alternatively proplist version can be factored out into >>>>> float_to_list_opts/2. >>>>> >>>>> Just my 0.2 cents >>>>> >>>>> On Wed, Jan 12, 2011 at 15:10, Serge Aleynikov >>>>> wrote: >>>>>> >>>>>> The reason I called it precision was to be consistent with the naming >>>>>> convention of the printf function. Below is the extract from "man 3 >>>>>> printf", which refers to the digits after the decimal point as >>>>>> "precision": >>>>>> >>>>>> f, F The double argument is rounded and converted to decimal >>>>>> notation in the style [-]ddd.ddd, where the number of >>>>>> digits after the decimal-point character is equal to the >>>>>> precision specification. If the precision is missing, >>>>>> it is taken as 6; if the precision is explicitly zero, >>>>>> no decimal-point character appears. If a decimal point >>>>>> appears, at least one digit appears before it. >>>>>> >>>>>> I don't have a very strong preference for calling it precision or >>>>>> scale, >>>>>> but >>>>>> I do have a strong preference for including this patch in the >>>>>> distribution, >>>>>> because the default behavior of float_to_list/1 hard-coded in C is >>>>>> deficient. >>>>>> >>>>>> >>>>>> On 1/12/2011 4:58 AM, nox wrote: >>>>>>> >>>>>>> Il should be called "scale", shouldn't it? >>>>>>> >>>>>>> Le 12 janv. 2011 ? 10:26, Pierpaolo Bernardi a >>>>>>> ?crit >>>>>>> : >>>>>>> >>>>>>>> On Wed, Jan 12, 2011 at 06:44, Serge Aleynikov >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Attached please find a patch that adds a new float_to_list/2 >>>>>>>>> BIF. The >>>>>>>>> patch >>>>>>>>> was created off of the master branch of >>>>>>>>> https://github.com/erlang/otp. >>>>>>>>> >>>>>>>>> This BIF solves a problem of float_to_list/1 that doesn't allow >>>>>>>>> specifying >>>>>>>>> the number of digits after the decimal point when formatting >>>>>>>>> floats. >>>>>>>>> >>>>>>>>> float_to_list(Float, Options) -> string() >>>>>>>>> >>>>>>>>> Float = float() >>>>>>>>> Options = [Option] >>>>>>>>> Option = {precision, Precision::integer()} | compact >>>>>>>>> >>>>>>>>> Text representation of a float formatted using given options >>>>>>>>> >>>>>>>>> Returns a string which corresponds to the text >>>>>>>>> representation of Float using fixed decimal point formatting. >>>>>>>>> When precision option is specified >>>>>>>>> the returned value will contain at most Precision number of >>>>>>>>> digits past the decimal point. When compact option is provided >>>>>>>>> the trailing zeros at the end of the list are truncated. >>>>>>>> >>>>>>>> I think the option is misnamed. >>>>>>>> >>>>>>>> In the usual terminology, 'precision' is the total number of >>>>>>>> significative digits, not only the ones past the decimal point. >>>>>>>> >>>>>>>> Cheers >>>>>>>> P. >>>>>>>> >>>>>>>> ________________________________________________________________ >>>>>>>> erlang-questions (at) erlang.org mailing list. >>>>>>>> See http://www.erlang.org/faq.html >>>>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>>>> >>>>>> >>>>>> ________________________________________________________________ >>>>>> erlang-questions (at) erlang.org mailing list. >>>>>> See http://www.erlang.org/faq.html >>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>> >>>>>> >>>> >> >> ________________________________________________________________ >> erlang-patches (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.erl URL: From benh@REDACTED Fri Mar 9 04:23:16 2012 From: benh@REDACTED (Benjamin Herrenschmidt) Date: Fri, 09 Mar 2012 14:23:16 +1100 Subject: [erlang-patches] [PATCH] Fix memory corruption when reading topology information Message-ID: <1331263396.3105.48.camel@pasglop> If the number of processors actually found while reading sysfs is lower than the configured value, we realloc() the cpuinfo array to the smaller size, but we then iterate it using the original configured size, thus corrupting memory beyond the allocated block. Signed-off-by: Benjamin Herrenschmidt --- diff -urN otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c otp_src_R15B/erts/lib_src/common/erl_misc_utils.c --- otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c 2011-12-14 21:22:11.000000000 +1100 +++ otp_src_R15B/erts/lib_src/common/erl_misc_utils.c 2012-03-08 14:40:18.111420986 +1100 @@ -939,7 +939,7 @@ if (res > 1) { prev = this++; - last = &cpuinfo->topology[cpuinfo->configured-1]; + last = &cpuinfo->topology[cpuinfo->topology_size-1]; while (1) { this->thread = ((this->node == prev->node From gustav@REDACTED Tue Mar 13 14:44:49 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Tue, 13 Mar 2012 14:44:49 +0100 Subject: [erlang-patches] [PATCH] Add inets_sup:start_link/0 In-Reply-To: <1796C2E3-013F-495E-97AE-AEA66E653FD2@duomark.com> References: <1796C2E3-013F-495E-97AE-AEA66E653FD2@duomark.com> Message-ID: <4F5F4F51.3050708@erlang.org> Hi Jay, We have included this patch in the 'pu' branch. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-06 06:09, Jay Nelson wrote: > inets_app calls supervisor:start_link/3 directly rather than calling the > root supervisor function inets_sup:start_link/0. This precludes using > included_applications to start inets without having a wrapper function. > This patch makes inets_app follow the standard OTP application structure. > > git fetch git://github.com/jaynel/otp.git inets_sup_start_link > > https://github.com/jaynel/otp/compare/inets_sup_start_link > https://github.com/jaynel/otp/compare/inets_sup_start_link.patch > > jay > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From gustav@REDACTED Tue Mar 13 14:47:44 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Tue, 13 Mar 2012 14:47:44 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: <4F5F5000.7030703@erlang.org> Hi Jos?, We have included this patch in the 'pu' branch. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-07 09:38, Jos? Valim wrote: > Hello everyone, any feedback on the proposal below? > > Thanks. > > > On Mon, Feb 20, 2012 at 5:18 PM, Jos? Valim > wrote: > > So here is a patch that allows ** in filelib:wildcard() in order > to support recursion. > > git fetch git://github.com/josevalim/otp.git > double_star > > https://github.com/josevalim/otp/compare/double_star > https://github.com/josevalim/otp/compare/double_star.patch > > ** now works similarly to bash, ruby, racf, etc. For example, > running filelib:wildcard("**/*.erl", Cwd) will find all files > ending with .erl in the Cwd recursively. > > PS: I had some minor bumps in the road but in general I've found > the process of submitting patches to Erlang very well documented. > So thanks to those responsible for making this easy. :) > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav@REDACTED Tue Mar 13 14:50:02 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Tue, 13 Mar 2012 14:50:02 +0100 Subject: [erlang-patches] [PATCH] Fix memory corruption when reading topology information In-Reply-To: <1331263396.3105.48.camel@pasglop> References: <1331263396.3105.48.camel@pasglop> Message-ID: <4F5F508A.1040304@erlang.org> Hi Benjamin, We discovered this error in a few other places, and will create a slightly larger internal patch for this issue. Thank you for finding this error and reporting it! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-09 04:23, Benjamin Herrenschmidt wrote: > If the number of processors actually found while reading sysfs > is lower than the configured value, we realloc() the cpuinfo array > to the smaller size, but we then iterate it using the original > configured size, thus corrupting memory beyond the allocated > block. > > Signed-off-by: Benjamin Herrenschmidt > --- > > diff -urN otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c otp_src_R15B/erts/lib_src/common/erl_misc_utils.c > --- otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c 2011-12-14 21:22:11.000000000 +1100 > +++ otp_src_R15B/erts/lib_src/common/erl_misc_utils.c 2012-03-08 14:40:18.111420986 +1100 > @@ -939,7 +939,7 @@ > > if (res> 1) { > prev = this++; > - last =&cpuinfo->topology[cpuinfo->configured-1]; > + last =&cpuinfo->topology[cpuinfo->topology_size-1]; > > while (1) { > this->thread = ((this->node == prev->node > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From gustav@REDACTED Tue Mar 13 15:00:30 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Tue, 13 Mar 2012 15:00:30 +0100 Subject: [erlang-patches] [erlang-questions] [patch] new float_to_list/2 In-Reply-To: <4F58F46A.5050701@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> Message-ID: <4F5F52FE.7060003@erlang.org> Hi Serge, We'll get back to you about this patch after the ERTS team have reviewed it. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-08 19:03, Serge Aleynikov wrote: > Dear Sverker, > > Sorry for a belated response. The following commit addresses three > issues you indicated. Attached is also a small performance test > program which illustrates that the new float_to_list/2 is about 6x > faster than float_to_list/1: > > https://github.com/saleyn/otp/commit/d7a108f28fd8cd519852feb0233920af511b5eba > > > git fetch git://github.com/saleyn/otp.git float_to_list_2 > > https://github.com/saleyn/otp/compare/float_to_list_2 > https://github.com/saleyn/otp/compare/float_to_list_2.patch > > > Executing the attachment test function: > 1> test:test(1.0). > float_to_list(1.000000, []) = {0.149531,"1.000000"} > float_to_list(1.000000, [{decimals, 4}]) = {0.109001,"1.0000"} > float_to_list(1.000000) = {0.629831,"1.00000000000000000000e+00"} > ok > > Regards, > > Serge > > P.S. I don't have access to solaris and freebsd at the moment, but the > code works on 32/64-bit linux, and is identical for those two platforms. > > On 3/28/2011 11:39 AM, Sverker Eriksson wrote: >> Thanks for your patch. As you may have seen it did not make it into >> R14B02. >> >> Comments: >> >> 1. Test fail on some platforms (32-bit solaris, freebsd and 64-bit >> linux) >> >> float_to_list(1.0,[compact]) >> >> returns "1." instead of "1.0" >> >> >> 2. Would like the interface to be extendable to support printf's %e and >> %g formats in future. Maybe just rename 'precision' to 'decimals'. >> >> 3. Why is default 4 decimals when printf and io:format has 6 as default. >> >> >> /Sverker, Erlang/OTP >> >> >> >> >> Serge Aleynikov wrote: >>> This implementation has been submitted as the pull request: >>> >>> https://github.com/erlang/otp/pull/9 >>> >>> This version is also optimized to run 5-10x faster than >>> float_to_list/1 for floats under 2^52. >>> >>> Regards, >>> >>> Serge >>> >>> On 1/14/2011 10:33 AM, Gleb Peregud wrote: >>>> Here's my patch: >>>> >>>> http://www.erlang.org/cgi-bin/ezmlm-cgi/4/43529 >>>> >>>> It uses double sprintf invocations. Your solution is clearly better (I >>>> didn't knew it is possible to specify precision in args). >>>> >>>> Your benchmark shows that difference is negligible. Between integer as >>>> a second parameter or a proplist (~0.4%). Though it might be a bit >>>> more "stable" in terms of running time, but still probably not worth >>>> considering it for performance reasons. It still may be useful in >>>> terms of simpler API, but I have no strong opinion on it. >>>> >>>> So generally +1 on including Serge's patch into Erlang. Serge, can you >>>> put it into GitHub pull request? As described here: >>>> >>>> https://github.com/erlang/otp/wiki/submitting-patches >>>> >>>> Best, >>>> Gleb >>>> >>>> On Wed, Jan 12, 2011 at 18:13, Serge Aleynikov >>>> wrote: >>>>> I did a micro-benchmark on a slightly modified version of the BIF >>>>> that >>>>> accepts an integer as its options. The results shown below display a >>>>> very >>>>> insignificant difference between a call with no options and a call >>>>> with an >>>>> integer precision passed as the second argument: >>>>> >>>>> 1> test:test(). >>>>> float_to_list(123.4, []) = {0.619512,"123.4000"} >>>>> float_to_list(123.4, [{precision, 4}]) = {0.624895,"123.4000"} >>>>> float_to_list(123.4, 4) = {0.622896,"123.4000"} >>>>> >>>>> The majority of time is actually spent in the printf(3) function, >>>>> which >>>>> takes longer to execute when given the "%.*f" argument compared to >>>>> "%g" as >>>>> in float_to_list/1 case. >>>>> >>>>> Did your patch rely on printf? >>>>> >>>>> >>>>> On 1/12/2011 9:23 AM, Gleb Peregud wrote: >>>>>> >>>>>> Some time ago I've submitted similar but simpler patch. It was a >>>>>> float_to_list/2 with a second parameter being an integer specifying >>>>>> precision. For me it was important to generate A LOT of floats as >>>>>> strings as fast as possible with specified precision. Serge's >>>>>> version >>>>>> has an overhead of inspecting proplist of the second parameter. So I >>>>>> was wondering about introducing two versions of this function: >>>>>> with a >>>>>> proplist as a second parameter and with a number as a second >>>>>> parameter. Alternatively proplist version can be factored out into >>>>>> float_to_list_opts/2. >>>>>> >>>>>> Just my 0.2 cents >>>>>> >>>>>> On Wed, Jan 12, 2011 at 15:10, Serge Aleynikov >>>>>> wrote: >>>>>>> >>>>>>> The reason I called it precision was to be consistent with the >>>>>>> naming >>>>>>> convention of the printf function. Below is the extract from "man 3 >>>>>>> printf", which refers to the digits after the decimal point as >>>>>>> "precision": >>>>>>> >>>>>>> f, F The double argument is rounded and converted to decimal >>>>>>> notation in the style [-]ddd.ddd, where the number of >>>>>>> digits after the decimal-point character is equal to the >>>>>>> precision specification. If the precision is missing, >>>>>>> it is taken as 6; if the precision is explicitly zero, >>>>>>> no decimal-point character appears. If a decimal point >>>>>>> appears, at least one digit appears before it. >>>>>>> >>>>>>> I don't have a very strong preference for calling it precision or >>>>>>> scale, >>>>>>> but >>>>>>> I do have a strong preference for including this patch in the >>>>>>> distribution, >>>>>>> because the default behavior of float_to_list/1 hard-coded in C is >>>>>>> deficient. >>>>>>> >>>>>>> >>>>>>> On 1/12/2011 4:58 AM, nox wrote: >>>>>>>> >>>>>>>> Il should be called "scale", shouldn't it? >>>>>>>> >>>>>>>> Le 12 janv. 2011 ? 10:26, Pierpaolo >>>>>>>> Bernardi a >>>>>>>> ?crit >>>>>>>> : >>>>>>>> >>>>>>>>> On Wed, Jan 12, 2011 at 06:44, Serge >>>>>>>>> Aleynikov >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Attached please find a patch that adds a new float_to_list/2 >>>>>>>>>> BIF. The >>>>>>>>>> patch >>>>>>>>>> was created off of the master branch of >>>>>>>>>> https://github.com/erlang/otp. >>>>>>>>>> >>>>>>>>>> This BIF solves a problem of float_to_list/1 that doesn't allow >>>>>>>>>> specifying >>>>>>>>>> the number of digits after the decimal point when formatting >>>>>>>>>> floats. >>>>>>>>>> >>>>>>>>>> float_to_list(Float, Options) -> string() >>>>>>>>>> >>>>>>>>>> Float = float() >>>>>>>>>> Options = [Option] >>>>>>>>>> Option = {precision, Precision::integer()} | compact >>>>>>>>>> >>>>>>>>>> Text representation of a float formatted using given options >>>>>>>>>> >>>>>>>>>> Returns a string which corresponds to the text >>>>>>>>>> representation of Float using fixed decimal point formatting. >>>>>>>>>> When precision option is specified >>>>>>>>>> the returned value will contain at most Precision number of >>>>>>>>>> digits past the decimal point. When compact option is provided >>>>>>>>>> the trailing zeros at the end of the list are truncated. >>>>>>>>> >>>>>>>>> I think the option is misnamed. >>>>>>>>> >>>>>>>>> In the usual terminology, 'precision' is the total number of >>>>>>>>> significative digits, not only the ones past the decimal point. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> P. >>>>>>>>> >>>>>>>>> ________________________________________________________________ >>>>>>>>> erlang-questions (at) erlang.org mailing list. >>>>>>>>> See http://www.erlang.org/faq.html >>>>>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>>>>> >>>>>>> >>>>>>> ________________________________________________________________ >>>>>>> erlang-questions (at) erlang.org mailing list. >>>>>>> See http://www.erlang.org/faq.html >>>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>>> >>>>>>> >>>>> >>> >>> ________________________________________________________________ >>> erlang-patches (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED >>> >> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Tue Mar 13 18:15:03 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Tue, 13 Mar 2012 18:15:03 +0100 Subject: [erlang-patches] [erlang-questions] [patch] new float_to_list/2 In-Reply-To: <4F5F52FE.7060003@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> Message-ID: <4F5F8097.5060003@erix.ericsson.se> #1. The patch does not compile on Windows: error LNK2019: unresolved external symbol _snprintf referenced in function _sys_double_to_chars_fast Use erts_snprintf instead. Same as snprintf with extra %T feature for printing Erlang terms. #2. We don't like identical source copies of sys_double_to_chars_fast(). There is a directory sys/common for shared code. /Sverker, Erlang/OTP Gustav Simonsson wrote: > Hi Serge, > > We'll get back to you about this patch after the ERTS team have > reviewed it. > Thank you for the contribution! > > Regards, > Gustav Simonsson > Erlang/OTP team > > On 2012-03-08 19:03, Serge Aleynikov wrote: >> Dear Sverker, >> >> Sorry for a belated response. The following commit addresses three >> issues you indicated. Attached is also a small performance test >> program which illustrates that the new float_to_list/2 is about 6x >> faster than float_to_list/1: >> >> https://github.com/saleyn/otp/commit/d7a108f28fd8cd519852feb0233920af511b5eba >> >> >> git fetch git://github.com/saleyn/otp.git float_to_list_2 >> >> https://github.com/saleyn/otp/compare/float_to_list_2 >> https://github.com/saleyn/otp/compare/float_to_list_2.patch >> >> >> Executing the attachment test function: >> 1> test:test(1.0). >> float_to_list(1.000000, []) = {0.149531,"1.000000"} >> float_to_list(1.000000, [{decimals, 4}]) = {0.109001,"1.0000"} >> float_to_list(1.000000) = {0.629831,"1.00000000000000000000e+00"} >> ok >> >> Regards, >> >> Serge >> >> P.S. I don't have access to solaris and freebsd at the moment, but >> the code works on 32/64-bit linux, and is identical for those two >> platforms. >> >> On 3/28/2011 11:39 AM, Sverker Eriksson wrote: >>> Thanks for your patch. As you may have seen it did not make it into >>> R14B02. >>> >>> Comments: >>> >>> 1. Test fail on some platforms (32-bit solaris, freebsd and 64-bit >>> linux) >>> >>> float_to_list(1.0,[compact]) >>> >>> returns "1." instead of "1.0" >>> >>> >>> 2. Would like the interface to be extendable to support printf's %e and >>> %g formats in future. Maybe just rename 'precision' to 'decimals'. >>> >>> 3. Why is default 4 decimals when printf and io:format has 6 as >>> default. >>> >>> >>> /Sverker, Erlang/OTP >>> >>> >>> >>> >>> Serge Aleynikov wrote: >>>> This implementation has been submitted as the pull request: >>>> >>>> https://github.com/erlang/otp/pull/9 >>>> >>>> This version is also optimized to run 5-10x faster than >>>> float_to_list/1 for floats under 2^52. >>>> >>>> Regards, >>>> >>>> Serge >>>> >>>> On 1/14/2011 10:33 AM, Gleb Peregud wrote: >>>>> Here's my patch: >>>>> >>>>> http://www.erlang.org/cgi-bin/ezmlm-cgi/4/43529 >>>>> >>>>> It uses double sprintf invocations. Your solution is clearly >>>>> better (I >>>>> didn't knew it is possible to specify precision in args). >>>>> >>>>> Your benchmark shows that difference is negligible. Between >>>>> integer as >>>>> a second parameter or a proplist (~0.4%). Though it might be a bit >>>>> more "stable" in terms of running time, but still probably not worth >>>>> considering it for performance reasons. It still may be useful in >>>>> terms of simpler API, but I have no strong opinion on it. >>>>> >>>>> So generally +1 on including Serge's patch into Erlang. Serge, can >>>>> you >>>>> put it into GitHub pull request? As described here: >>>>> >>>>> https://github.com/erlang/otp/wiki/submitting-patches >>>>> >>>>> Best, >>>>> Gleb >>>>> >>>>> On Wed, Jan 12, 2011 at 18:13, Serge Aleynikov >>>>> wrote: >>>>>> I did a micro-benchmark on a slightly modified version of the BIF >>>>>> that >>>>>> accepts an integer as its options. The results shown below display a >>>>>> very >>>>>> insignificant difference between a call with no options and a call >>>>>> with an >>>>>> integer precision passed as the second argument: >>>>>> >>>>>> 1> test:test(). >>>>>> float_to_list(123.4, []) = {0.619512,"123.4000"} >>>>>> float_to_list(123.4, [{precision, 4}]) = {0.624895,"123.4000"} >>>>>> float_to_list(123.4, 4) = {0.622896,"123.4000"} >>>>>> >>>>>> The majority of time is actually spent in the printf(3) function, >>>>>> which >>>>>> takes longer to execute when given the "%.*f" argument compared to >>>>>> "%g" as >>>>>> in float_to_list/1 case. >>>>>> >>>>>> Did your patch rely on printf? >>>>>> >>>>>> >>>>>> On 1/12/2011 9:23 AM, Gleb Peregud wrote: >>>>>>> >>>>>>> Some time ago I've submitted similar but simpler patch. It was a >>>>>>> float_to_list/2 with a second parameter being an integer specifying >>>>>>> precision. For me it was important to generate A LOT of floats as >>>>>>> strings as fast as possible with specified precision. Serge's >>>>>>> version >>>>>>> has an overhead of inspecting proplist of the second parameter. >>>>>>> So I >>>>>>> was wondering about introducing two versions of this function: >>>>>>> with a >>>>>>> proplist as a second parameter and with a number as a second >>>>>>> parameter. Alternatively proplist version can be factored out into >>>>>>> float_to_list_opts/2. >>>>>>> >>>>>>> Just my 0.2 cents >>>>>>> >>>>>>> On Wed, Jan 12, 2011 at 15:10, Serge Aleynikov >>>>>>> wrote: >>>>>>>> >>>>>>>> The reason I called it precision was to be consistent with the >>>>>>>> naming >>>>>>>> convention of the printf function. Below is the extract from >>>>>>>> "man 3 >>>>>>>> printf", which refers to the digits after the decimal point as >>>>>>>> "precision": >>>>>>>> >>>>>>>> f, F The double argument is rounded and converted to decimal >>>>>>>> notation in the style [-]ddd.ddd, where the number of >>>>>>>> digits after the decimal-point character is equal to the >>>>>>>> precision specification. If the precision is missing, >>>>>>>> it is taken as 6; if the precision is explicitly zero, >>>>>>>> no decimal-point character appears. If a decimal point >>>>>>>> appears, at least one digit appears before it. >>>>>>>> >>>>>>>> I don't have a very strong preference for calling it precision or >>>>>>>> scale, >>>>>>>> but >>>>>>>> I do have a strong preference for including this patch in the >>>>>>>> distribution, >>>>>>>> because the default behavior of float_to_list/1 hard-coded in C is >>>>>>>> deficient. >>>>>>>> >>>>>>>> >>>>>>>> On 1/12/2011 4:58 AM, nox wrote: >>>>>>>>> >>>>>>>>> Il should be called "scale", shouldn't it? >>>>>>>>> >>>>>>>>> Le 12 janv. 2011 ? 10:26, Pierpaolo >>>>>>>>> Bernardi a >>>>>>>>> ?crit >>>>>>>>> : >>>>>>>>> >>>>>>>>>> On Wed, Jan 12, 2011 at 06:44, Serge >>>>>>>>>> Aleynikov >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Attached please find a patch that adds a new float_to_list/2 >>>>>>>>>>> BIF. The >>>>>>>>>>> patch >>>>>>>>>>> was created off of the master branch of >>>>>>>>>>> https://github.com/erlang/otp. >>>>>>>>>>> >>>>>>>>>>> This BIF solves a problem of float_to_list/1 that doesn't allow >>>>>>>>>>> specifying >>>>>>>>>>> the number of digits after the decimal point when formatting >>>>>>>>>>> floats. >>>>>>>>>>> >>>>>>>>>>> float_to_list(Float, Options) -> string() >>>>>>>>>>> >>>>>>>>>>> Float = float() >>>>>>>>>>> Options = [Option] >>>>>>>>>>> Option = {precision, Precision::integer()} | compact >>>>>>>>>>> >>>>>>>>>>> Text representation of a float formatted using given options >>>>>>>>>>> >>>>>>>>>>> Returns a string which corresponds to the text >>>>>>>>>>> representation of Float using fixed decimal point formatting. >>>>>>>>>>> When precision option is specified >>>>>>>>>>> the returned value will contain at most Precision number of >>>>>>>>>>> digits past the decimal point. When compact option is provided >>>>>>>>>>> the trailing zeros at the end of the list are truncated. >>>>>>>>>> >>>>>>>>>> I think the option is misnamed. >>>>>>>>>> >>>>>>>>>> In the usual terminology, 'precision' is the total number of >>>>>>>>>> significative digits, not only the ones past the decimal point. >>>>>>>>>> >>>>>>>>>> Cheers >>>>>>>>>> P. >>>>>>>>>> >>>>>>>>>> ________________________________________________________________ >>>>>>>>>> erlang-questions (at) erlang.org mailing list. >>>>>>>>>> See http://www.erlang.org/faq.html >>>>>>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>>>>>> >>>>>>>> >>>>>>>> ________________________________________________________________ >>>>>>>> erlang-questions (at) erlang.org mailing list. >>>>>>>> See http://www.erlang.org/faq.html >>>>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> ________________________________________________________________ >>>> erlang-patches (at) erlang.org mailing list. >>>> See http://www.erlang.org/faq.html >>>> To unsubscribe; mailto:erlang-patches-unsubscribe@REDACTED >>>> >>> >>> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > From benh@REDACTED Tue Mar 13 21:14:26 2012 From: benh@REDACTED (Benjamin Herrenschmidt) Date: Wed, 14 Mar 2012 07:14:26 +1100 Subject: [erlang-patches] [PATCH] Fix memory corruption when reading topology information In-Reply-To: <4F5F508A.1040304@erlang.org> References: <1331263396.3105.48.camel@pasglop> <4F5F508A.1040304@erlang.org> Message-ID: <1331669666.3105.108.camel@pasglop> On Tue, 2012-03-13 at 14:50 +0100, Gustav Simonsson wrote: > Hi Benjamin, > > We discovered this error in a few other places, and will create a > slightly larger internal patch for this issue. > Thank you for finding this error and reporting it! Thanks. Any chance you can CC me on the patch ? I'd like to try to get it included/backported in some distro as it prevents anything using erlang from running on some setups. (Typically if you have unplugged CPU, which is common when running KVM on POWER7 machines where the host has to unplug the SMT threads). Cheers, Ben. > Regards, > Gustav Simonsson > Erlang/OTP team > > > On 2012-03-09 04:23, Benjamin Herrenschmidt wrote: > > If the number of processors actually found while reading sysfs > > is lower than the configured value, we realloc() the cpuinfo array > > to the smaller size, but we then iterate it using the original > > configured size, thus corrupting memory beyond the allocated > > block. > > > > Signed-off-by: Benjamin Herrenschmidt > > --- > > > > diff -urN otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c otp_src_R15B/erts/lib_src/common/erl_misc_utils.c > > --- otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c 2011-12-14 21:22:11.000000000 +1100 > > +++ otp_src_R15B/erts/lib_src/common/erl_misc_utils.c 2012-03-08 14:40:18.111420986 +1100 > > @@ -939,7 +939,7 @@ > > > > if (res> 1) { > > prev = this++; > > - last =&cpuinfo->topology[cpuinfo->configured-1]; > > + last =&cpuinfo->topology[cpuinfo->topology_size-1]; > > > > while (1) { > > this->thread = ((this->node == prev->node > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches From bgustavsson@REDACTED Wed Mar 14 07:23:52 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 14 Mar 2012 07:23:52 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: On Mon, Feb 20, 2012 at 5:18 PM, Jos? Valim wrote: > So here is a patch that allows ** in filelib:wildcard() in order to support > recursion. > Thanks for your contribution. I have reviewed it, and found some issues that will need to be fixed before we can consider including it in Erlang/OTP. Behavior: You say: "** now works similarly to bash, ruby, racf, etc". We'll need a better description of the behavior than that. It seems to me that bash 4 and ruby may implement '**' slightly differently, but I cannot be sure since ruby's documentation does not fully describe what '**' does. Bash 4's documentation of '**' is terse, but it does describe the behavior in detail. I suggest that you implement '**' the same way as in Bash 4. If you don't agree, you should justify your decision in the commit message. Hint: A single "**" pattern gives different result in Bash 4 and your implementation, and so does "**/lib/**/*.xsd" (run in the OTP source tree). Documentation: The behavior must be better described (perhaps similar to the description in the Bash 4 manual) so that a reader can actually understand what it does and doesn't do. One or more examples should also be added. Test suite: The test suite should be improved. There is no test for multiple '**' patterns (for example, "**/lib/**/*.xsd"), and the directory structure created for testing only has two levels; it seems that you are only testing that '**' can match zero or one levels (as opposed to zero or more). Implementation: It seems that it is possible do more work during compilation of the wildcard and less when evaluating it. I think that it would be easier if you represent '**' as {double_star,Pattern} always at the end of pattern list, and that you can just recursively match Pattern going down one level at the time until a recursive match does not find anything more. That should probably take care of multiple '**' patterns (which don't seem to work now). Code style: Looks good with a few exceptions. The indentation is off in one place in do_wildcard_3/4. Also, there are extra blank lines between clauses; they should not be there. Nit picking: The first line in the commit message should not end in a period. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From lukas@REDACTED Wed Mar 14 10:11:29 2012 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 14 Mar 2012 10:11:29 +0100 Subject: [erlang-patches] Fix port leaking after controlling_process(Port, self()) In-Reply-To: <20120204155510.GA1431@viper.local> References: <20120204155510.GA1431@viper.local> Message-ID: <4F6060C1.8010301@erlang.org> Hello! The fix looks fine. Could you also add a testcase to gen_tcp_misc_SUITE which verifies this? As soon as that is added we'll merge it upstream. Lukas On 04/02/12 16:55, Ricardo Catalinas Jim?nez wrote: > I spotted the same issue that Max Lapshin reported in: > > http://erlang.org/pipermail/erlang-questions/2011-April/057944.html > > > Add case to handle the situation when someone call > {gen_tcp,gen_udp}:controlling_process(Port, self()). Also improve spec > and doc from gen_udp and gen_sctp for controlling_process/2. > > To reproduce the issue, open an UDP port: > > 4> {ok,Port} = gen_udp:open(9000, [binary]). > {ok,#Port<0.587>} > 5> gen_udp:controlling_process(Port, self()). > ok > > Simulate error: > > 6> 1=2. > ** exception error: no match of right hand side value 2 > > Here is the leak: > > 7> inet:i(). > Port Module Recv Sent Owner Local Address Foreign Address State > Type > 581 inet_udp 0 0<0.31.0> *:cslistener *:* BOUND > DGRAM > ok > > > Please fetch: > git fetch git://github.com/jimenezrick/otp.git fix-gen_udp_tcp-leak > > Review here: > https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-gen_udp_tcp-leak > https://github.com/jimenezrick/otp/compare/erlang:maint...jimenezrick:fix-gen_udp_tcp-leak.patch > > > Regards From jose.valim@REDACTED Wed Mar 14 14:04:16 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 14 Mar 2012 14:04:16 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: Here is an updated patch for ** support in filelib:wildcard(). git fetch git://github.com/josevalim/otp.git fixed_double_star https://github.com/josevalim/otp/compare/fixed_double_star https://github.com/josevalim/otp/compare/fixed_double_star.patch Quoting from bash documentation: Two adjacent *'s used as a single pattern will match all files and zero or more directories and subdirectories. I have tested this against Bash 4.2 implementation (previously I was using Ruby's implementation as basis). Since I didn't know there was a difference between Ruby and Bash, I removed any reference to Ruby in the commit message. I have also kept the current filelib:wildcard() behavior of returning files that start with dot ".". Bash by default does not return files starting with "." in wildcards. I have also improved the test coverage, documentation and added some examples. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel@REDACTED Wed Mar 14 14:34:53 2012 From: daniel@REDACTED (Daniel Luna) Date: Wed, 14 Mar 2012 09:34:53 -0400 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: Just a comment, without reading the patch. I don't know how this is done in bash, but in zsh there is also *** expansion. While ** expands to any level of directories, *** will also include symbolic links in its expansion. This is of course "unsafe" in the sense that symlinked directories outside of the tree you are working on will be included if there are links to the outside. It can also quite easily expand to an infinite size if there are symlinks that point to any of their ancestors. Not yet a suggestion for adding this feature to the patch, but at this stage only a comment on the caveat of expanding symbolic links. /Daniel 2012/3/14 Jos? Valim : > Here is an updated patch for ** support in filelib:wildcard(). > > git fetch git://github.com/josevalim/otp.git?fixed_double_star > > https://github.com/josevalim/otp/compare/fixed_double_star > https://github.com/josevalim/otp/compare/fixed_double_star.patch > > Quoting from bash documentation: > > Two adjacent *'s used as a single pattern will?match all files and zero or > more directories and subdirectories. > > I have tested this against Bash 4.2 implementation (previously I was using > Ruby's implementation as basis). Since I didn't know there was a difference > between Ruby and Bash, I removed any reference to Ruby in the commit > message. > > I have also kept the current filelib:wildcard() behavior of returning files > that start with dot ".". Bash by default does not return files starting with > "." in wildcards. > > I have also improved the test coverage, documentation and added some > examples. > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From jose.valim@REDACTED Wed Mar 14 14:53:45 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 14 Mar 2012 14:53:45 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: Daniel, In Bash, ** follows symlinks and I have kept this behavior. FWIW, nested single * follows symlinks in both Bash and Erlang as well. * Jos? Valim www.plataformatec.com.br Founder and Lead Developer * 2012/3/14 Daniel Luna > Just a comment, without reading the patch. > > I don't know how this is done in bash, but in zsh there is also *** > expansion. While ** expands to any level of directories, *** will > also include symbolic links in its expansion. This is of course > "unsafe" in the sense that symlinked directories outside of the tree > you are working on will be included if there are links to the outside. > It can also quite easily expand to an infinite size if there are > symlinks that point to any of their ancestors. > > Not yet a suggestion for adding this feature to the patch, but at this > stage only a comment on the caveat of expanding symbolic links. > > /Daniel > > > 2012/3/14 Jos? Valim : > > Here is an updated patch for ** support in filelib:wildcard(). > > > > git fetch git://github.com/josevalim/otp.git fixed_double_star > > > > https://github.com/josevalim/otp/compare/fixed_double_star > > https://github.com/josevalim/otp/compare/fixed_double_star.patch > > > > Quoting from bash documentation: > > > > Two adjacent *'s used as a single pattern will match all files and zero > or > > more directories and subdirectories. > > > > I have tested this against Bash 4.2 implementation (previously I was > using > > Ruby's implementation as basis). Since I didn't know there was a > difference > > between Ruby and Bash, I removed any reference to Ruby in the commit > > message. > > > > I have also kept the current filelib:wildcard() behavior of returning > files > > that start with dot ".". Bash by default does not return files starting > with > > "." in wildcards. > > > > I have also improved the test coverage, documentation and added some > > examples. > > > > _______________________________________________ > > 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 Wed Mar 14 15:21:33 2012 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 14 Mar 2012 15:21:33 +0100 Subject: [erlang-patches] Support ** for recursion in filelib:wildcard In-Reply-To: References: Message-ID: On 3/14/12, Jos? Valim wrote: > Here is an updated patch for ** support in filelib:wildcard(). > > git fetch git://github.com/josevalim/otp.git fixed_double_star > Thanks! You have fixed everything I asked you to fix. I noticed one more thing that I missed the first time: There is no need to add ?line macros as exceptions in R15 have line numbers. I have amended your commit and done that change. Also, I have updated the commit message to mention that wildcards work like in Bash 4 (since that can be useful to know for someone who browses the commit history in the future): Allow ** in filelib:wildcard Two adjacent * used as a single pattern will match all files and zero or more directories and subdirectories, as in Bash 4. See: http://www.gnu.org/software/bash/manual/bashref.html Search for "globstar". I will ask Gustav to include the version of the branch with those changes, so there is no need for you to submit an updated branch. We will now let your branch run in our daily builds for a couple of days. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From spawn.think@REDACTED Wed Mar 14 17:35:44 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 14 Mar 2012 17:35:44 +0100 Subject: [erlang-patches] Fix some crashes within debugger handling breaks Message-ID: git fetch https://github.com/spawnthink/otp.git fix_debugger_breaks_crashes https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Wed Mar 14 17:39:40 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 14 Mar 2012 17:39:40 +0100 Subject: [erlang-patches] Fix some crashes within debugger handling breaks In-Reply-To: References: Message-ID: Please note it was also reported before by Ricardo Catalinas Jim?nez http://erlang.org/pipermail/erlang-bugs/2012-February/002760.html On Wed, Mar 14, 2012 at 5:35 PM, Ahmed Omar wrote: > git fetch https://github.com/spawnthink/otp.gitfix_debugger_breaks_crashes > > > https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes > > > https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes.patch > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker@REDACTED Wed Mar 14 17:52:11 2012 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 14 Mar 2012 17:52:11 +0100 Subject: [erlang-patches] [PATCH] Fix memory corruption when reading topology information In-Reply-To: <1331669666.3105.108.camel@pasglop> References: <1331263396.3105.48.camel@pasglop> <4F5F508A.1040304@erlang.org> <1331669666.3105.108.camel@pasglop> Message-ID: <4F60CCBB.4000507@erix.ericsson.se> I found two other places in erl_misc_utils.c where the same mistake seems to be done. Do you have some test to share that provokes this bug? diff --git a/erts/lib_src/common/erl_misc_utils.c b/erts/lib_src/common/erl_misc_utils.c index 4806311..162c908 100644 --- a/erts/lib_src/common/erl_misc_utils.c +++ b/erts/lib_src/common/erl_misc_utils.c @@ -727,7 +727,7 @@ adjust_processor_nodes(erts_cpu_info_t *cpuinfo, int no_nodes) prev = NULL; this = &cpuinfo->topology[0]; - last = &cpuinfo->topology[cpuinfo->configured-1]; + last = &cpuinfo->topology[cpuinfo->topology_size-1]; while (1) { if (processor == this->processor) { if (node != this->node) @@ -939,7 +939,7 @@ read_topology(erts_cpu_info_t *cpuinfo) if (res > 1) { prev = this++; - last = &cpuinfo->topology[cpuinfo->configured-1]; + last = &cpuinfo->topology[cpuinfo->topology_size-1]; while (1) { this->thread = ((this->node == prev->node @@ -1094,7 +1094,7 @@ read_topology(erts_cpu_info_t *cpuinfo) if (res > 1) { prev = this++; - last = &cpuinfo->topology[cpuinfo->configured-1]; + last = &cpuinfo->topology[cpuinfo->topology_size-1]; while (1) { this->thread = ((this->node == prev->node /Sverker, Erlang/OTP Ericsson Benjamin Herrenschmidt wrote: > On Tue, 2012-03-13 at 14:50 +0100, Gustav Simonsson wrote: > >> Hi Benjamin, >> >> We discovered this error in a few other places, and will create a >> slightly larger internal patch for this issue. >> Thank you for finding this error and reporting it! >> > > Thanks. Any chance you can CC me on the patch ? I'd like to try to get > it included/backported in some distro as it prevents anything using > erlang from running on some setups. (Typically if you have unplugged > CPU, which is common when running KVM on POWER7 machines where the host > has to unplug the SMT threads). > > Cheers, > Ben. > > >> Regards, >> Gustav Simonsson >> Erlang/OTP team >> >> >> On 2012-03-09 04:23, Benjamin Herrenschmidt wrote: >> >>> If the number of processors actually found while reading sysfs >>> is lower than the configured value, we realloc() the cpuinfo array >>> to the smaller size, but we then iterate it using the original >>> configured size, thus corrupting memory beyond the allocated >>> block. >>> >>> Signed-off-by: Benjamin Herrenschmidt >>> --- >>> >>> diff -urN otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c otp_src_R15B/erts/lib_src/common/erl_misc_utils.c >>> --- otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c 2011-12-14 21:22:11.000000000 +1100 >>> +++ otp_src_R15B/erts/lib_src/common/erl_misc_utils.c 2012-03-08 14:40:18.111420986 +1100 >>> @@ -939,7 +939,7 @@ >>> >>> if (res> 1) { >>> prev = this++; >>> - last =&cpuinfo->topology[cpuinfo->configured-1]; >>> + last =&cpuinfo->topology[cpuinfo->topology_size-1]; >>> >>> while (1) { >>> this->thread = ((this->node == prev->node >>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From dangud@REDACTED Wed Mar 14 20:04:08 2012 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 14 Mar 2012 20:04:08 +0100 Subject: [erlang-patches] Fix some crashes within debugger handling breaks In-Reply-To: References: Message-ID: Thanks for the patch. But I've already made the patch which is in testing in our internal nightly builds. Sorry about that extra work for you, it is my fault I have not taken the time to merge that into maint/master branch. My patch also includes a testcase which provokes the issue. Please in future provide tests for the bugs or features supplied. /Dan PS: It always better to use =:= instead of == when not comparing numbers. On Wed, Mar 14, 2012 at 5:39 PM, Ahmed Omar wrote: > Please note it ?was also reported before by?Ricardo Catalinas Jim?nez > http://erlang.org/pipermail/erlang-bugs/2012-February/002760.html > > > On Wed, Mar 14, 2012 at 5:35 PM, Ahmed Omar wrote: >> >> git fetch https://github.com/spawnthink/otp.git >> fix_debugger_breaks_crashes >> >> >> https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes >> >> >> https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes.patch >> >> > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From spawn.think@REDACTED Wed Mar 14 20:17:33 2012 From: spawn.think@REDACTED (Ahmed Omar) Date: Wed, 14 Mar 2012 20:17:33 +0100 Subject: [erlang-patches] Fix some crashes within debugger handling breaks In-Reply-To: References: Message-ID: No problem yes i already had it changed to =:=, and was about to ask for refetch :) Now i will delete my branch to avoid confusion Thanks On Wed, Mar 14, 2012 at 8:04 PM, Dan Gudmundsson wrote: > Thanks for the patch. > > But I've already made the patch which is in testing in our internal > nightly builds. > Sorry about that extra work for you, it is my fault I have not taken > the time to merge > that into maint/master branch. > > My patch also includes a testcase which provokes the issue. > Please in future provide tests for the bugs or features supplied. > > /Dan > PS: It always better to use =:= instead of == when not comparing numbers. > > On Wed, Mar 14, 2012 at 5:39 PM, Ahmed Omar wrote: > > Please note it was also reported before by Ricardo Catalinas Jim?nez > > http://erlang.org/pipermail/erlang-bugs/2012-February/002760.html > > > > > > On Wed, Mar 14, 2012 at 5:35 PM, Ahmed Omar > wrote: > >> > >> git fetch https://github.com/spawnthink/otp.git > >> fix_debugger_breaks_crashes > >> > >> > >> > https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes > >> > >> > >> > https://github.com/spawnthink/otp/compare/erlang:maint...spawnthink:fix_debugger_breaks_crashes.patch > >> > >> > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benh@REDACTED Wed Mar 14 21:00:10 2012 From: benh@REDACTED (Benjamin Herrenschmidt) Date: Thu, 15 Mar 2012 07:00:10 +1100 Subject: [erlang-patches] [PATCH] Fix memory corruption when reading topology information In-Reply-To: <4F60CCBB.4000507@erix.ericsson.se> References: <1331263396.3105.48.camel@pasglop> <4F5F508A.1040304@erlang.org> <1331669666.3105.108.camel@pasglop> <4F60CCBB.4000507@erix.ericsson.se> Message-ID: <1331755210.3105.125.camel@pasglop> On Wed, 2012-03-14 at 17:52 +0100, Sverker Eriksson wrote: > I found two other places in erl_misc_utils.c where the same mistake > seems to be done. > > Do you have some test to share that provokes this bug? On a reasonably large machine, offline some CPUs and run erlang, it will either segfault or abort with a glibc detected heap corruption. Our test setup is some POWER7 machines on which we disable SMT with the command: ppc64_cpu --smt=off That disables 3 out of 4 logical CPUs, so the machine goes from 64 to 16 which is plenty enough to trigger glibc heap corruption detection. Cheers, Ben. > diff --git a/erts/lib_src/common/erl_misc_utils.c > b/erts/lib_src/common/erl_misc_utils.c > index 4806311..162c908 100644 > --- a/erts/lib_src/common/erl_misc_utils.c > +++ b/erts/lib_src/common/erl_misc_utils.c > @@ -727,7 +727,7 @@ adjust_processor_nodes(erts_cpu_info_t *cpuinfo, int > no_nodes) > > prev = NULL; > this = &cpuinfo->topology[0]; > - last = &cpuinfo->topology[cpuinfo->configured-1]; > + last = &cpuinfo->topology[cpuinfo->topology_size-1]; > while (1) { > if (processor == this->processor) { > if (node != this->node) > @@ -939,7 +939,7 @@ read_topology(erts_cpu_info_t *cpuinfo) > > if (res > 1) { > prev = this++; > - last = &cpuinfo->topology[cpuinfo->configured-1]; > + last = &cpuinfo->topology[cpuinfo->topology_size-1]; > > while (1) { > this->thread = ((this->node == prev->node > @@ -1094,7 +1094,7 @@ read_topology(erts_cpu_info_t *cpuinfo) > > if (res > 1) { > prev = this++; > - last = &cpuinfo->topology[cpuinfo->configured-1]; > + last = &cpuinfo->topology[cpuinfo->topology_size-1]; > > while (1) { > this->thread = ((this->node == prev->node > > > /Sverker, Erlang/OTP Ericsson > > > Benjamin Herrenschmidt wrote: > > On Tue, 2012-03-13 at 14:50 +0100, Gustav Simonsson wrote: > > > >> Hi Benjamin, > >> > >> We discovered this error in a few other places, and will create a > >> slightly larger internal patch for this issue. > >> Thank you for finding this error and reporting it! > >> > > > > Thanks. Any chance you can CC me on the patch ? I'd like to try to get > > it included/backported in some distro as it prevents anything using > > erlang from running on some setups. (Typically if you have unplugged > > CPU, which is common when running KVM on POWER7 machines where the host > > has to unplug the SMT threads). > > > > Cheers, > > Ben. > > > > > >> Regards, > >> Gustav Simonsson > >> Erlang/OTP team > >> > >> > >> On 2012-03-09 04:23, Benjamin Herrenschmidt wrote: > >> > >>> If the number of processors actually found while reading sysfs > >>> is lower than the configured value, we realloc() the cpuinfo array > >>> to the smaller size, but we then iterate it using the original > >>> configured size, thus corrupting memory beyond the allocated > >>> block. > >>> > >>> Signed-off-by: Benjamin Herrenschmidt > >>> --- > >>> > >>> diff -urN otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c otp_src_R15B/erts/lib_src/common/erl_misc_utils.c > >>> --- otp_src_R15B.orig/erts/lib_src/common/erl_misc_utils.c 2011-12-14 21:22:11.000000000 +1100 > >>> +++ otp_src_R15B/erts/lib_src/common/erl_misc_utils.c 2012-03-08 14:40:18.111420986 +1100 > >>> @@ -939,7 +939,7 @@ > >>> > >>> if (res> 1) { > >>> prev = this++; > >>> - last =&cpuinfo->topology[cpuinfo->configured-1]; > >>> + last =&cpuinfo->topology[cpuinfo->topology_size-1]; > >>> > >>> while (1) { > >>> this->thread = ((this->node == prev->node > >>> > >>> > >>> > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > >>> > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > From erlangsiri@REDACTED Thu Mar 15 15:01:57 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 15 Mar 2012 15:01:57 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> <4F0431C5.9030300@gmail.com> <4F048C1D.9000905@gmail.com> <4F05F4A1.9080407@gmail.com> Message-ID: Hi Richard! Once again sorry for the long silence. We have now decided to allow this feature with the following adjustments: * the default behavior must be as it is today - i.e. the feature has to be explicitly activated per supervisor * parameters that don't have an obvious default value shall not have a default value I think this should be possible with your proplist-child-spec feature :) Also we do of course need tests and documentation. Thanks! /siri Den 10:24 12. januar 2012 skrev Siri Hansen f?lgende: > Hi Richard! > > Sorry for the long silence! We will discuss this on our next technical > board meeting and get back to you with our decision as soon as possible. > > Regards > /siri > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Thu Mar 15 15:28:06 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 15 Mar 2012 15:28:06 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> <4F0431C5.9030300@gmail.com> <4F048C1D.9000905@gmail.com> <4F05F4A1.9080407@gmail.com> Message-ID: <4F61FC76.4060506@gmail.com> On 03/15/2012 03:01 PM, Siri Hansen wrote: > Hi Richard! > > Once again sorry for the long silence. We have now decided to allow this > feature with the following adjustments: > > * the default behavior must be as it is today - i.e. the feature has to > be explicitly activated per supervisor > * parameters that don't have an obvious default value shall not have a > default value > > I think this should be possible with your proplist-child-spec feature :) > > Also we do of course need tests and documentation. That is good news, but I have very little time at the moment. If you would like this feature (and the proplist child specs) in the next few months, it has to be down to OTP to modify, test and document it. /Richard From erlangsiri@REDACTED Fri Mar 16 09:42:44 2012 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 16 Mar 2012 09:42:44 +0100 Subject: [erlang-patches] delayed child restart with incremental back-off In-Reply-To: <4F61FC76.4060506@gmail.com> References: <4F03875D.1020504@gmail.com> <4F03A4B5.2090404@gmail.com> <4F0431C5.9030300@gmail.com> <4F048C1D.9000905@gmail.com> <4F05F4A1.9080407@gmail.com> <4F61FC76.4060506@gmail.com> Message-ID: Den 15:28 15. mars 2012 skrev Richard Carlsson f?lgende: > On 03/15/2012 03:01 PM, Siri Hansen wrote: > >> Hi Richard! >> >> Once again sorry for the long silence. We have now decided to allow this >> feature with the following adjustments: >> >> * the default behavior must be as it is today - i.e. the feature has to >> be explicitly activated per supervisor >> * parameters that don't have an obvious default value shall not have a >> default value >> >> I think this should be possible with your proplist-child-spec feature :) >> >> Also we do of course need tests and documentation. >> > > That is good news, but I have very little time at the moment. If you would > like this feature (and the proplist child specs) in the next few months, it > has to be down to OTP to modify, test and document it. > > /Richard > I'm sorry to say that we don't have this time either right now, so we will let this feature rest for now and hope for better times... /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattevans123@REDACTED Sun Mar 18 13:54:55 2012 From: mattevans123@REDACTED (Matthew Evans) Date: Sun, 18 Mar 2012 08:54:55 -0400 Subject: [erlang-patches] [erlang-questions] Erlang shell - JCL Mode In-Reply-To: References: Message-ID: I managed to do it by changing user_drv.erl. You can connect the nodes to create a mesh (e.g. net_adm:ping/1) and then from JCL do: r all e.g. (manager@REDACTED)4> nodes().['bob@REDACTED','sue@REDACTED', 'matt@REDACTED','jane@REDACTED'](manager@REDACTED)5> User switch command --> r all --> j 1 {shell,start,[init]} 2 {'bob@REDACTED',shell,start,[]} 3 {'sue@REDACTED',shell,start,[]} 4 {'matt@REDACTED',shell,start,[]} 5* {'jane@REDACTED',shell,start,[]} --> Seems to work.... Attached is a patch file (Erlang R15B) for those that are interested... Matt From: mattevans123@REDACTED To: erlang-questions@REDACTED Date: Sat, 17 Mar 2012 19:27:35 -0400 Subject: [erlang-questions] Erlang shell - JCL Mode Hi I am working on a system where we could (hopefully) have deployments of many nodes (dimensioned to be in the 100's). It would be really nice if we could use JCL to switch between shells (using a central management shell) without having to enter JCL and doing r 'node@REDACTED' for each remote node in the system. Is there any magic that makes this possible? Thanks Matt _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: user_drv.erl.patch Type: application/octet-stream Size: 1069 bytes Desc: not available URL: From aronisstav@REDACTED Mon Mar 19 16:18:22 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Mon, 19 Mar 2012 16:18:22 +0100 Subject: [erlang-patches] Parallel Dialyzer Message-ID: Hi all, Dialyzer's inner machinery has been rewritten to run faster on multi-core machines. The relevant branch, based on current 'master', is available at: git fetch git://github.com/aronisstav/otp.git dialyzer-parallel Try it and send us any feedback you may have! Cheers, Stavros & Kostis -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav@REDACTED Mon Mar 19 16:51:57 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Mon, 19 Mar 2012 16:51:57 +0100 Subject: [erlang-patches] Parallel Dialyzer In-Reply-To: References: Message-ID: <4F67561D.9000603@erlang.org> This branch has been added to the 'master-opu' branch. We'll get back to you with feedback once it has been reviewed. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-19 16:18, Stavros Aronis wrote: > Hi all, > > Dialyzer's inner machinery has been rewritten to run faster on > multi-core machines. The relevant branch, based on current 'master', > is available at: > > git fetch git://github.com/aronisstav/otp.git > dialyzer-parallel > > Try it and send us any feedback you may have! > > Cheers, > > Stavros & Kostis > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From yrashk@REDACTED Tue Mar 20 04:25:42 2012 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Mon, 19 Mar 2012 20:25:42 -0700 Subject: [erlang-patches] inet_tcp_dist fix Message-ID: Hi, I am considering extracting a fix I made to inet_tcp_dist recently. The nature of the fix is as follows: Currently, while doing connection setup, inet_tcp_dist will only try resolving host name to one IP address. That means that if your hostname either has multiple A records or multiple records in the hosts file, it will always try one and only one IP. In certain cases, when some IPs are either out of reach, or those host are just being down, that means that the connection will never be established. The patch that I have retrieves all the IP addresses and tries them one by one until the connection is established (or not). Please let me know if the OTP team will consider such a change, and if yes, I will happily extract this patch and submit it to this list. Thanks, Yurii. From aronisstav@REDACTED Tue Mar 20 18:48:32 2012 From: aronisstav@REDACTED (Stavros Aronis) Date: Tue, 20 Mar 2012 18:48:32 +0100 Subject: [erlang-patches] Parallel Dialyzer In-Reply-To: <4F67561D.9000603@erlang.org> References: <4F67561D.9000603@erlang.org> Message-ID: Hi again, After taking some early reviews into consideration, I have updated the branch. It is now based on 'maint'. git fetch git://github.com/aronisstav/otp.git dialyzer-parallel One of the major concerns about the parallel version is memory consumption. There is now a fallback into the sequential mode that consumes a lot less memory and is enabled if the machine you are running Dialyzer on has only one logical processor or only one scheduler. Dialyzer supports the '+S ' as an option to specify the number of schedulers, so if you are on a multi-core you can activate the fallback by using "dialyzer +S 1 ...". Otherwise the number of schedulers is equal to the number of logical processors. Regards, Stavros On Mon, Mar 19, 2012 at 4:51 PM, Gustav Simonsson wrote: > ** > This branch has been added to the 'master-opu' branch. > We'll get back to you with feedback once it has been reviewed. > > Thank you for the contribution! > > Regards, > Gustav Simonsson > Erlang/OTP team > > > On 2012-03-19 16:18, Stavros Aronis wrote: > > Hi all, > > Dialyzer's inner machinery has been rewritten to run faster on > multi-core machines. The relevant branch, based on current 'master', is > available at: > > git fetch git://github.com/aronisstav/otp.git dialyzer-parallel > > Try it and send us any feedback you may have! > > Cheers, > > Stavros & Kostis > > > _______________________________________________ > erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav@REDACTED Wed Mar 21 09:57:01 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Wed, 21 Mar 2012 09:57:01 +0100 Subject: [erlang-patches] Parallel Dialyzer In-Reply-To: References: <4F67561D.9000603@erlang.org> Message-ID: <4F6997DD.8020006@erlang.org> Hi, We've refetched this branch and moved it from the 'master-opu' branch to the 'opu' branch. Regards, Gustav Simonsson Erlang/OTP team On 2012-03-20 18:48, Stavros Aronis wrote: > Hi again, > > After taking some early reviews into consideration, I have updated the > branch. It is now based on 'maint'. > > git fetch git://github.com/aronisstav/otp.git > dialyzer-parallel > > One of the major concerns about the parallel version is memory > consumption. There is now a fallback into the sequential mode that > consumes a lot less memory and is enabled if the machine you are > running Dialyzer on has only one logical processor or only one > scheduler. Dialyzer supports the '+S ' as an option to specify the > number of schedulers, so if you are on a multi-core you can activate > the fallback by using "dialyzer +S 1 ...". Otherwise the number of > schedulers is equal to the number of logical processors. > > Regards, > Stavros > > On Mon, Mar 19, 2012 at 4:51 PM, Gustav Simonsson > wrote: > > This branch has been added to the 'master-opu' branch. > We'll get back to you with feedback once it has been reviewed. > > Thank you for the contribution! > > Regards, > Gustav Simonsson > Erlang/OTP team > > > On 2012-03-19 16:18, Stavros Aronis wrote: >> Hi all, >> >> Dialyzer's inner machinery has been rewritten to run faster on >> multi-core machines. The relevant branch, based on current >> 'master', is available at: >> >> git fetch git://github.com/aronisstav/otp.git >> dialyzer-parallel >> >> Try it and send us any feedback you may have! >> >> Cheers, >> >> Stavros & Kostis >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sperber@REDACTED Fri Mar 23 09:20:27 2012 From: sperber@REDACTED (Michael Sperber) Date: Fri, 23 Mar 2012 09:20:27 +0100 Subject: [erlang-patches] Float endianness in 15B Message-ID: On certain ARM machines, there's a problem with float endianness, which has been reported many times before. Symptons: io_lib:write(1.0). "0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005299808824" The problem is *not* that the ARM is not using IEEE 754, as is inferred here: http://erlang.org/pipermail/erlang-questions/2008-October/039148.html The ARM uses IEEE 754, but the two 32-bit words in the FP representation are swapped wrt. Erlang's assumptions. The fix to the source code is very simple, but the associated autoconf hackery is a bit more extensive. Such a fix is here: git fetch git://github.com/bjorng/otp.git double_middle_endian https://github.com/mikesperber/otp/compare/double_middle_endian https://github.com/mikesperber/otp/compare/double_middle_endian.patch (This is the first time I'm submitting a fix to Erlang, and I needed our resident git ninja to help me set up, so I hope you'll forgive me if I did something wrong - let me know.) -- Regards, Mike From jose.valim@REDACTED Fri Mar 23 15:00:56 2012 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 23 Mar 2012 15:00:56 +0100 Subject: [erlang-patches] Allow the source to be set when compiling forms Message-ID: Here is a patch that allows compile:forms() to receive a source option that specifies the source value returned by module_info(compile). Currently, there is no way to set the source and Erlang ends up setting the source to the current directory. git fetch git://github.com/josevalim/otp.git forms-source https://github.com/josevalim/otp/compare/forms-source https://github.com/josevalim/otp/compare/forms-source.patch The patch includes code, tests and docs changes. For more information, the initial discussion in Erlang Questions mailing list: http://erlang.org/pipermail/erlang-questions/2012-March/065361.html Thanks! * Jos? Valim www.plataformatec.com.br Founder and Lead Developer * -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustav@REDACTED Fri Mar 30 14:29:31 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Fri, 30 Mar 2012 14:29:31 +0200 Subject: [erlang-patches] Fix some crashes within debugger handling breaks In-Reply-To: References: Message-ID: <4F75A72B.3030204@erlang.org> Hi Ahmed, We have included this patch into the 'pu' branch. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-14 17:39, Ahmed Omar wrote: > git fetch https://github.com/spawnthink/otp.git > fix_debugger_breaks_crashes From gustav@REDACTED Fri Mar 30 14:34:52 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Fri, 30 Mar 2012 14:34:52 +0200 Subject: [erlang-patches] Fix some crashes within debugger handling breaks In-Reply-To: <4F75A72B.3030204@erlang.org> References: <4F75A72B.3030204@erlang.org> Message-ID: <4F75A86C.7020500@erlang.org> I mixed up this patch with another one, as Dan wrote this fix is already in testing. Please ignore the previous mail. Regards, Gustav Simonsson Erlang/OTP team On 2012-03-30 14:29, Gustav Simonsson wrote: > Hi Ahmed, > > We have included this patch into the 'pu' branch. > Thank you for the contribution! > > Regards, > Gustav Simonsson > Erlang/OTP team > > On 2012-03-14 17:39, Ahmed Omar wrote: >> git fetch https://github.com/spawnthink/otp.git >> fix_debugger_breaks_crashes > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From gustav@REDACTED Fri Mar 30 15:08:16 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Fri, 30 Mar 2012 15:08:16 +0200 Subject: [erlang-patches] Float endianness in 15B In-Reply-To: References: Message-ID: <4F75B040.4010205@erlang.org> Hi Michael, Unfortunately we do not yet have an ARM machine in our daily builds & tests. For some time we have discussed adding ARM to our test cluster, until then we'll just add this one in our patch notes, preparing it for future testing. As for the commit itself there was some trailing whitespaces and a dot at the end of the commit message. A review of the actual code will be done when we get hold of an ARM machine for testing. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-23 09:20, Michael Sperber wrote: > On certain ARM machines, there's a problem with float endianness, which > has been reported many times before. Symptons: > > io_lib:write(1.0). > "0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005299808824" > > The problem is *not* that the ARM is not using IEEE 754, as is inferred > here: > > http://erlang.org/pipermail/erlang-questions/2008-October/039148.html > > The ARM uses IEEE 754, but the two 32-bit words in the FP > representation are swapped wrt. Erlang's assumptions. > > The fix to the source code is very simple, but the associated autoconf > hackery is a bit more extensive. > > Such a fix is here: > > git fetch git://github.com/bjorng/otp.git double_middle_endian > https://github.com/mikesperber/otp/compare/double_middle_endian > https://github.com/mikesperber/otp/compare/double_middle_endian.patch > > (This is the first time I'm submitting a fix to Erlang, and I needed our > resident git ninja to help me set up, so I hope you'll forgive me if I > did something wrong - let me know.) > From fhunleth@REDACTED Fri Mar 30 15:18:19 2012 From: fhunleth@REDACTED (Frank Hunleth) Date: Fri, 30 Mar 2012 09:18:19 -0400 Subject: [erlang-patches] Float endianness in 15B In-Reply-To: <4F75B040.4010205@erlang.org> References: <4F75B040.4010205@erlang.org> Message-ID: Michael and Gustav, On Fri, Mar 30, 2012 at 9:08 AM, Gustav Simonsson wrote: > Unfortunately we do not yet have an ARM machine in our daily builds & tests. > For some time we have discussed adding ARM to our test cluster, until then > we'll just add this one in our patch notes, preparing it for future testing. FWIW, my Beaglebone (ARM Cortex A8) does not appear to suffer from this issue. -Frank From gustav@REDACTED Fri Mar 30 15:51:35 2012 From: gustav@REDACTED (Gustav Simonsson) Date: Fri, 30 Mar 2012 15:51:35 +0200 Subject: [erlang-patches] Allow the source to be set when compiling forms In-Reply-To: References: Message-ID: <4F75BA67.3070507@erlang.org> Hi Jos?, We'll add this patch to the 'pu' branch. Thank you for the contribution! Regards, Gustav Simonsson Erlang/OTP team On 2012-03-23 15:00, Jos? Valim wrote: > Here is a patch that allows compile:forms() to receive a source option > that specifies the source value returned by module_info(compile). > Currently, there is no way to set the source and Erlang ends up > setting the source to the current directory. > > git fetch git://github.com/josevalim/otp.git > forms-source > > https://github.com/josevalim/otp/compare/forms-source > https://github.com/josevalim/otp/compare/forms-source.patch > > The patch includes code, tests and docs changes. > > For more information, the initial discussion in Erlang Questions > mailing list: > http://erlang.org/pipermail/erlang-questions/2012-March/065361.html > > Thanks! > > > * > *Jos? Valim* > www.plataformatec.com.br > Founder and Lead Developer > * > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From sperber@REDACTED Fri Mar 30 16:44:09 2012 From: sperber@REDACTED (Michael Sperber) Date: Fri, 30 Mar 2012 16:44:09 +0200 Subject: [erlang-patches] Float endianness in 15B In-Reply-To: <4F75B040.4010205@erlang.org> (Gustav Simonsson's message of "Fri, 30 Mar 2012 15:08:16 +0200") References: <4F75B040.4010205@erlang.org> Message-ID: Thanks for the quick reply! Gustav Simonsson writes: > Unfortunately we do not yet have an ARM machine in our daily builds & tests. > For some time we have discussed adding ARM to our test cluster, until then > we'll just add this one in our patch notes, preparing it for future testing. > As for the commit itself there was some trailing whitespaces and a dot > at the end of > the commit message. Should I prepare a fixed commit? > A review of the actual code will be done when we get hold of an ARM > machine for testing. So, while we do have ARM hardware, I developed the patch on a QEMU-emulated installation, which runs on just about any hardware. Is it feasible for you to set this kind of thing up? I'd be happy to contribute an image, if you can tell me what you need. -- Regards, Mike