From n.oxyde@REDACTED Mon Apr 1 18:34:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 1 Apr 2013 18:34:35 +0200 Subject: [erlang-patches] [erlang-bugs] R16 breaks dots In-Reply-To: <51576CF7.6010905@gmail.com> References: <20130329203406.GB1251@zushakon> <13603AE6-E8E6-4EAD-899F-35D9CD7D2187@gmail.com> <51576CF7.6010905@gmail.com> Message-ID: <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> Hello, I wrote a patch that allows dotted atoms everywhere in the syntax but record expressions, where they would be ambiguous. I wrote no tests as I have no idea where they should go. Furthermore, I think that maybe the pretty-printer should be patched to not quote dotted atoms outside record expressions. git fetch https://github.com/nox/otp.git restore-dotted-atoms https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms.patch Regards, -- Anthony Ramine Le 30 mars 2013 ? 23:53, Richard Carlsson a ?crit : > I think that many agree on this, and maybe the OTP team can be convinced to take this part back. It should be pretty simple to extract the relevant code from the commit that removes packages. From essen@REDACTED Mon Apr 1 20:47:45 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 01 Apr 2013 20:47:45 +0200 Subject: [erlang-patches] Small gen.erl optimizations Message-ID: <5159D651.7030104@ninenines.eu> Hello, I've been reading a lot of stdlib code recently and these two things have been bugging me. They're small changes, behavior is unchanged, and tests seem to pass. git fetch git://github.com/essen/otp.git otp-optims https://github.com/essen/otp/compare/erlang:maint...otp-optims https://github.com/essen/otp/compare/erlang:maint...otp-optims.patch Enjoy. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From fredrik@REDACTED Tue Apr 2 10:56:04 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Apr 2013 10:56:04 +0200 Subject: [erlang-patches] Corrected typo in erlsrv usage In-Reply-To: References: Message-ID: <515A9D24.9040001@erlang.org> On 03/29/2013 07:23 AM, Bryan Hunter wrote: > Hi. This is my first Erlang patch! It's a simple typo correction in > the usage message for erlsrv.exe > > git fetch git://github.com/bryanhunter/otp.git > fix-erlsrv-usage-typo > > https://github.com/bryanhunter/otp/compare/fix-erlsrv-usage-typo > https://github.com/bryanhunter/otp/compare/fix-erlsrv-usage-typo.patch > > -Bryan > > -- > Bryan Hunter > Partner & Senior Software Engineer > o: (615) 469-2236 ext.204 > m: (615) 500-1855 > Firefly Logic | @fireflylogic > | @bryan_hunter > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Fetched, thank you for your contribution -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Apr 2 11:01:42 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Apr 2013 11:01:42 +0200 Subject: [erlang-patches] ct_run: delete unused function In-Reply-To: References: Message-ID: <515A9E76.1020806@erlang.org> On 03/31/2013 01:34 PM, Tuncer Ayaz wrote: > git fetch git://github.com/tuncer/otp.git ct_run-unused-fun Fetched, currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Apr 2 10:59:13 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Apr 2013 10:59:13 +0200 Subject: [erlang-patches] Fix SNMP gitignore files In-Reply-To: <07AECAA8-43F6-4B64-ABBD-B1BB54B6CEFF@gmail.com> References: <07AECAA8-43F6-4B64-ABBD-B1BB54B6CEFF@gmail.com> Message-ID: <515A9DE1.9040300@erlang.org> On 03/31/2013 12:19 PM, Anthony Ramine wrote: > git fetchhttps://github.com/nox/otp.git fix-snmp-gitignore Fetched! Thanks Anthony, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Apr 2 11:07:42 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Apr 2013 11:07:42 +0200 Subject: [erlang-patches] Bit string generators, unsized binaries, modules and the REPL In-Reply-To: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> References: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> Message-ID: <515A9FDE.2050801@erlang.org> On 03/31/2013 04:22 PM, Anthony Ramine wrote: > Hello, > > People on IRC noticed a difference between compiled modules and the REPL in how some binary generators are handled. > > Compare: > > $ cat unsized_bin_gen_pat.erl > -module(unsized_bin_gen_pat). > -export([t/0]). > t() -> << <> ||<> <=<<1,2,3>> >>. > $ erlc unsized_bin_gen_pat.erl > $ erl > > 1> % compiled > 1> unsized_bin_gen_pat:t(). > <<1,2,3,2,3,3>> > 2> % evaluated > 2> << <> ||<> <=<<1,2,3>> >>. > <<1,2,3>> > > I don't think the compiler should be changed to behave like the REPL, nor I think the REPL should be changed to behave like the compiler. Instead, I think an unsized binary tail in the pattern of a binary generator does not make sense, and this should happen: > > $ erlc unsized_bin_gen_pat.erl > unsized_bin_gen_pat.erl:3: binary fields without size are not allowed in patterns of bit string generators > > This patch implements this new error and simplifies how v3_core works with forbidden unsized tail segments in patterns of bit string generators. > > git fetch https://github.com/nox/otp illegal-bitstring-gen-pattern > > https://github.com/nox/otp/compare/erlang:maint...illegal-bitstring-gen-pattern > https://github.com/nox/otp/compare/erlang:maint...illegal-bitstring-gen-pattern.patch > > Looking at the commit 5daa001 by Bj?rn Gustavsson "Don't generate multiple tail segments in binary matching", this patch will probably by rejected as it seems the compiler behaves as wanted by the OTP team. If this is indeed the case, erl_eval should be fixed. > > Regards, > Hello, I've fetched your branch and it is currently in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Apr 2 11:27:19 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Apr 2013 11:27:19 +0200 Subject: [erlang-patches] [erlang-bugs] R16 breaks dots In-Reply-To: <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> References: <20130329203406.GB1251@zushakon> <13603AE6-E8E6-4EAD-899F-35D9CD7D2187@gmail.com> <51576CF7.6010905@gmail.com> <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> Message-ID: <515AA477.9040202@erlang.org> On 04/01/2013 06:34 PM, Anthony Ramine wrote: > Hello, > > I wrote a patch that allows dotted atoms everywhere in the syntax but record expressions, where they would be ambiguous. I wrote no tests as I have no idea where they should go. Furthermore, I think that maybe the pretty-printer should be patched to not quote dotted atoms outside record expressions. > > git fetch https://github.com/nox/otp.git restore-dotted-atoms > > https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms > https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms.patch > > Regards, > I've assigned this patch on the responsible team! Thanks for your contribution. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Apr 2 11:30:04 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 2 Apr 2013 11:30:04 +0200 Subject: [erlang-patches] Small gen.erl optimizations In-Reply-To: <5159D651.7030104@ninenines.eu> References: <5159D651.7030104@ninenines.eu> Message-ID: <515AA51C.20706@erlang.org> On 04/01/2013 08:47 PM, Lo?c Hoguin wrote: > Hello, > > I've been reading a lot of stdlib code recently and these two things > have been bugging me. They're small changes, behavior is unchanged, > and tests seem to pass. > > git fetch git://github.com/essen/otp.git otp-optims > > https://github.com/essen/otp/compare/erlang:maint...otp-optims > https://github.com/essen/otp/compare/erlang:maint...otp-optims.patch > > Enjoy. > Hello, I've fetched your patch and it is currently in the 'pu' branch. Thanks for your contribution. -- BR Fredrik Gustafsson Erlang OTP Team From vinoski@REDACTED Wed Apr 3 02:20:42 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 2 Apr 2013 20:20:42 -0400 Subject: [erlang-patches] add sys:get_state/1,2 and sys:replace_state/2,3 Message-ID: At Erlang Factory 2013 there was discussion during one of the talks about the sys:get_status functions and how useful they were for debugging. Geoff Cant mentioned it would be very useful if the sys module also provided functions to use while debugging to get just the state of a process and also to be able to replace the state of a process, and many others in the audience appeared to agree. This patch adds the sys:get_state/1,2 and sys:replace_state/2,3 function to do what Geoff suggested. See the commit message for more details: https://github.com/vinoski/otp/commit/876b3644ecfac12accf36fbf0d0625e3ac4f6498 Patrik Nyblom was kind enough to already review the branch for me -- thanks Patrik. Note that there are two commits on this branch; the second one is described above. The first commit on the branch updates the documentation for sys:get_status/2,3 to note that it also works with gen_event. git fetch git://github.com/vinoski/otp.git sv-sys-get-state https://github.com/vinoski/otp/compare/erlang:maint...sv-sys-get-state https://github.com/vinoski/otp/compare/erlang:maint...sv-sys-get-state.patch --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew@REDACTED Wed Apr 3 04:29:44 2013 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 2 Apr 2013 22:29:44 -0400 Subject: [erlang-patches] add sys:get_state/1, 2 and sys:replace_state/2, 3 In-Reply-To: References: Message-ID: <20130403022944.GA18572@hijacked.us> I can't count the number of times I've abused sys:get_status and element and lists:nth to get the state of a process, so this is a very welcome change! Andrew From fredrik@REDACTED Wed Apr 3 10:19:20 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 3 Apr 2013 10:19:20 +0200 Subject: [erlang-patches] add sys:get_state/1, 2 and sys:replace_state/2, 3 In-Reply-To: References: Message-ID: <515BE608.2080709@erlang.org> On 04/03/2013 02:20 AM, Steve Vinoski wrote: > At Erlang Factory 2013 there was discussion during one of the talks > about the sys:get_status functions and how useful they were for > debugging. Geoff Cant mentioned it would be very useful if the sys > module also provided functions to use while debugging to get just the > state of a process and also to be able to replace the state of a > process, and many others in the audience appeared to agree. > > This patch adds the sys:get_state/1,2 and sys:replace_state/2,3 > function to do what Geoff suggested. See the commit message for more > details: > > https://github.com/vinoski/otp/commit/876b3644ecfac12accf36fbf0d0625e3ac4f6498 > > Patrik Nyblom was kind enough to already review the branch for me -- > thanks Patrik. > > Note that there are two commits on this branch; the second one is > described above. The first commit on the branch updates the > documentation for sys:get_status/2,3 to note that it also works with > gen_event. > > git fetch git://github.com/vinoski/otp.git > sv-sys-get-state > > https://github.com/vinoski/otp/compare/erlang:maint...sv-sys-get-state > https://github.com/vinoski/otp/compare/erlang:maint...sv-sys-get-state.patch > > --steve > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello and thanks for the patch. I'll put it into testing right away! I happened to see that you are using the '?line' macro, which we don't use anymore, but I can remove it for you. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Wed Apr 3 14:16:37 2013 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Apr 2013 17:46:37 +0530 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children Message-ID: <20130403121637.GB338@aluminium.local> git fetch git://github.com/vances/otp.git supervisor_child_limit https://github.com/vances/otp/commit/04f94f86e5495f29b61654d7f744ae3eeaca9297 With the addition of a Limit argument in start_child/3 the supervisor will either start a child or return {error,child_limit}. A supervisor behaviour process may have dynamically added children started by other processes. The count of the number of children could be retrieved from the process with count_children/1 before starting another with start_child/2 if a maximum number of children is to be maintained. This introduces an overhead of a round trip message and the possibility of a race condition. This is quite useful where a fixed size pool of processes might otherwise be used and is suitable for cases where child workers are started with high frequency. -- -Vance From carlsson.richard@REDACTED Wed Apr 3 14:23:31 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 03 Apr 2013 14:23:31 +0200 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130403121637.GB338@aluminium.local> References: <20130403121637.GB338@aluminium.local> Message-ID: <515C1F43.7000107@gmail.com> On 2013-04-03 14:16, Vance Shipley wrote: > git fetch git://github.com/vances/otp.git supervisor_child_limit > > https://github.com/vances/otp/commit/04f94f86e5495f29b61654d7f744ae3eeaca9297 > > With the addition of a Limit argument in start_child/3 the supervisor > will either start a child or return {error,child_limit}. > > A supervisor behaviour process may have dynamically added children > started by other processes. The count of the number of children > could be retrieved from the process with count_children/1 before > starting another with start_child/2 if a maximum number of children > is to be maintained. This introduces an overhead of a round trip > message and the possibility of a race condition. > > This is quite useful where a fixed size pool of processes might > otherwise be used and is suitable for cases where child workers are > started with high frequency. I think that if you're going to add start_child/3, then the third argument should be a list of options, rather than some specific thing, making it easy to add more options in the future without having to have start_child/4 etc. /Richard From fredrik@REDACTED Wed Apr 3 14:24:57 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 3 Apr 2013 14:24:57 +0200 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130403121637.GB338@aluminium.local> References: <20130403121637.GB338@aluminium.local> Message-ID: <515C1F99.3030903@erlang.org> On 04/03/2013 02:16 PM, Vance Shipley wrote: > git fetch git://github.com/vances/otp.git supervisor_child_limit > > https://github.com/vances/otp/commit/04f94f86e5495f29b61654d7f744ae3eeaca9297 > > With the addition of a Limit argument in start_child/3 the supervisor > will either start a child or return {error,child_limit}. > > A supervisor behaviour process may have dynamically added children > started by other processes. The count of the number of children > could be retrieved from the process with count_children/1 before > starting another with start_child/2 if a maximum number of children > is to be maintained. This introduces an overhead of a round trip > message and the possibility of a race condition. > > This is quite useful where a fixed size pool of processes might > otherwise be used and is suitable for cases where child workers are > started with high frequency. > Hello, I have fetched your patch and as this introduces a new feature I have assigned it to responsible team to decide if this a desired behaviour. Thanks for your contribution, -- BR Fredrik Gustafsson Erlang OTP Team From mononcqc@REDACTED Wed Apr 3 14:29:05 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 3 Apr 2013 08:29:05 -0400 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130403121637.GB338@aluminium.local> References: <20130403121637.GB338@aluminium.local> Message-ID: <20130403122904.GA82915@ferdair.local> Is the limit counted based on living children, or on the number of children specifications currently active? I am also not a fan of overloading the number '0' to mean "no limit" instead of "0 children allowed". We have atoms, and we should make use of them. Send in '{limited, N}' or 'unlimited', or 'infinity', or any other token value that is 100% explicit about the intent instead of just a '0' that people have to figure out what it means according to context rather than what it explicitly says. I think it would also be a good idea to check the type to be an integer greater than 0 (instead of just greater than 0, like a list or a tuple would be) at the call site rather than way too late, within the supervisor. If I were using limits like that to add a boundary to a pool, I'd worry about how the tracking happens. It seems to me that doing it all in the supervisor is surprisingly inefficient compared to having, say, a fixed pool, or a gen_server that monitors workers and starts them for you so the counter is implicit and direct rather than linear based on the number of children, and repeated on every single call. Just how often are you calling for new children to be added to the pool, and why does it happen so often as to be a problem? Does it happen frequently enough to be a problem, but infrequently enough for the supervisor to be able to do it without degrading its service? I don't have specific opinions for or against the feature itself and would defer to the OTP committee to judge its worth -- just gave your code a quick review :) Regards, Fred. On 04/03, Vance Shipley wrote: > git fetch git://github.com/vances/otp.git supervisor_child_limit > > https://github.com/vances/otp/commit/04f94f86e5495f29b61654d7f744ae3eeaca9297 > > With the addition of a Limit argument in start_child/3 the supervisor > will either start a child or return {error,child_limit}. > > A supervisor behaviour process may have dynamically added children > started by other processes. The count of the number of children > could be retrieved from the process with count_children/1 before > starting another with start_child/2 if a maximum number of children > is to be maintained. This introduces an overhead of a round trip > message and the possibility of a race condition. > > This is quite useful where a fixed size pool of processes might > otherwise be used and is suitable for cases where child workers are > started with high frequency. > > -- > -Vance > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From vances@REDACTED Wed Apr 3 14:39:17 2013 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Apr 2013 18:09:17 +0530 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <515C1F43.7000107@gmail.com> References: <20130403121637.GB338@aluminium.local> <515C1F43.7000107@gmail.com> Message-ID: <20130403123917.GC338@aluminium.local> On Wed, Apr 03, 2013 at 02:23:31PM +0200, Richard Carlsson wrote: } I think that if you're going to add start_child/3, then the third } argument should be a list of options, rather than some specific } thing, making it easy to add more options in the future without } having to have start_child/4 etc. That does seem like a reasonable approach. I'll reformat my contribution in that way if there's consensus on it's merit. -- -Vance From vances@REDACTED Wed Apr 3 14:53:25 2013 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Apr 2013 18:23:25 +0530 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130403122904.GA82915@ferdair.local> References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> Message-ID: <20130403125325.GD338@aluminium.local> On Wed, Apr 03, 2013 at 08:29:05AM -0400, Fred Hebert wrote: } Is the limit counted based on living children, or on the number of } children specifications currently active? Not living, just child specifications. Checking for living children is too heavy weight here. The supervisor had been enhanced to use dict() or sets() to store dynamic children with the addition of count_children/1. So checking the size of the child list is O(1). If you need to know how many are alive count_children/1 can be used. } I am also not a fan of overloading the number '0' to mean "no limit" } instead of "0 children allowed". We have atoms, and we should make use } of them. Send in '{limited, N}' or 'unlimited', or 'infinity', or any } other token value that is 100% explicit about the intent instead of just } a '0' that people have to figure out what it means according to context } rather than what it explicitly says. I only used '0' internally, the API insists on a pos_integer(). I did think the OTP team might want the internal interface to be backward compatibile so I was expecting some change there. } I think it would also be a good idea to check the type to be an integer } greater than 0 (instead of just greater than 0, like a list or a tuple } would be) at the call site rather than way too late, within the } supervisor. Yes, you are right about that. Noted. } If I were using limits like that to add a boundary to a pool, I'd worry } about how the tracking happens. It seems to me that doing it all in the } supervisor is surprisingly inefficient compared to having, say, a fixed } pool, or a gen_server that monitors workers and starts them for you so } the counter is implicit and direct rather than linear based on the } number of children, and repeated on every single call. Not at all! My sore spot involves high frequency spawning of short lived processes and I cannot afford the sort of overheads you are suggesting. My solution is quite low overhead, the intent is to have the lowest possible. } Just how often are you calling for new children to be added to the pool, } and why does it happen so often as to be a problem? Does it happen } frequently enough to be a problem, but infrequently enough for the } supervisor to be able to do it without degrading its service? To make the supervisor do it would require changing the SupSpec which isn't going to happen. Also it is more flexible to set a limit each time as it may change over time. -- -Vance From bombadil@REDACTED Thu Apr 4 10:35:45 2013 From: bombadil@REDACTED (Manuel A. Rubio "Bombadil") Date: Thu, 04 Apr 2013 10:35:45 +0200 Subject: [erlang-patches] fix a race condition when there're several applications in apps directory Message-ID: Hello, When use rebar with "apps" directory and enable cover for eunit or common_test, the change between apps has a race condition because the ETS is not killed when the new cover start (is a race condition but in several projects that I have it happends a lot of times). git fetch git://github.com/bosqueviejo/otp.git cover-fix https://github.com/bosqueviejo/otp/compare/erlang:maint...cover-fix https://github.com/bosqueviejo/otp/compare/erlang:maint...cover-fix.patch Thanks. Manuel Rubio. From fredrik@REDACTED Thu Apr 4 11:30:01 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 4 Apr 2013 11:30:01 +0200 Subject: [erlang-patches] fix a race condition when there're several applications in apps directory In-Reply-To: References: Message-ID: <515D4819.7030703@erlang.org> On 04/04/2013 10:35 AM, Manuel A. Rubio "Bombadil" wrote: > Hello, > > When use rebar with "apps" directory and enable cover for eunit or > common_test, the change between apps has a race condition because the > ETS is not killed when the new cover start (is a race condition but in > several projects that I have it happends a lot of times). > > > git fetch git://github.com/bosqueviejo/otp.git cover-fix > > > https://github.com/bosqueviejo/otp/compare/erlang:maint...cover-fix > > https://github.com/bosqueviejo/otp/compare/erlang:maint...cover-fix.patch > > Thanks. > Manuel Rubio. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, please rebase this upon the current 'maint' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Thu Apr 4 12:08:39 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 4 Apr 2013 12:08:39 +0200 Subject: [erlang-patches] fix a race condition when there're several applications in apps directory In-Reply-To: <6b5b59050473812efc49eb865fcf8154@bosqueviejo.net> References: <515D4819.7030703@erlang.org> <6b5b59050473812efc49eb865fcf8154@bosqueviejo.net> Message-ID: <515D5127.1090304@erlang.org> On 04/04/2013 12:06 PM, Manuel A. Rubio "Bombadil" wrote: > git fetch git://github.com/bosqueviejo/otp.git cover-fix Fetched. A reviewal process will start now. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From bombadil@REDACTED Thu Apr 4 12:06:45 2013 From: bombadil@REDACTED (Manuel A. Rubio "Bombadil") Date: Thu, 04 Apr 2013 12:06:45 +0200 Subject: [erlang-patches] fix a race condition when there're several applications in apps directory In-Reply-To: <515D4819.7030703@erlang.org> References: <515D4819.7030703@erlang.org> Message-ID: <6b5b59050473812efc49eb865fcf8154@bosqueviejo.net> Hi, El 2013-04-04 11:30, Fredrik escribi?: > Hello, please rebase this upon the current 'maint' branch. I did redo again only with maint. Check again: git fetch git://github.com/bosqueviejo/otp.git cover-fix https://github.com/bosqueviejo/otp/compare/erlang:maint...cover-fix https://github.com/bosqueviejo/otp/compare/erlang:maint...cover-fix.patch Thanks. Manuel Rubio. From james@REDACTED Thu Apr 4 14:05:49 2013 From: james@REDACTED (James Fish) Date: Thu, 4 Apr 2013 13:05:49 +0100 Subject: [erlang-patches] Fix one_for_all and rest_for_one supervisor multiple restarts Message-ID: Hi, When a child in a rest_for_one or one_for_all supervisor dies and is then restarted but a child later in the child specification fails to start - so that the restart fails - the restarted child's pid is ignored by the supervisor and is not terminated. The supervisor will then attempt to restart that child again - leaving the unaccounted for process alive! An example of this is available here: https://gist.github.com/fishcakez/5296408 In this patch the supervisor changes the restarting child to the one that failed to start. In the case of one_for_all this means that the successfully restarted child is terminated (along with the other successfully restarted children). In the case of rest_for_one all successfully restarted children remain, and restarting begins with the child that failed to start. Should this be document? The way a rest_for_one handles this case is not documented. git fetch git://github.com/fishcakez/otp.git fix-server-multi-restart https://github.com/fishcakez/otp/compare/fix-supervisor-multi-restart https://github.com/fishcakez/otp/compare/fix-supervisor-multi-restart.patch King Regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From james@REDACTED Thu Apr 4 14:09:15 2013 From: james@REDACTED (James Fish) Date: Thu, 4 Apr 2013 13:09:15 +0100 Subject: [erlang-patches] Fix one_for_all and rest_for_one supervisor multiple restarts In-Reply-To: References: Message-ID: Sorry that should be: git fetch git://github.com/fishcakez/otp.git fix-supervisor-multi-restart On 4 April 2013 13:05, James Fish wrote: > Hi, > > When a child in a rest_for_one or one_for_all supervisor dies and is then > restarted but a child later in the child specification fails to start - so > that the restart fails - the restarted child's pid is ignored by the > supervisor and is not terminated. The supervisor will then attempt to > restart that child again - leaving the unaccounted for process alive! > > An example of this is available here: > https://gist.github.com/fishcakez/5296408 > > In this patch the supervisor changes the restarting child to the one that > failed to start. In the case of one_for_all this means that the > successfully restarted child is terminated (along with the other > successfully restarted children). In the case of rest_for_one all > successfully restarted children remain, and restarting begins with the > child that failed to start. Should this be document? The way a rest_for_one > handles this case is not documented. > > git fetch git://github.com/fishcakez/otp.git fix-server-multi-restart > > https://github.com/fishcakez/otp/compare/fix-supervisor-multi-restart > https://github.com/fishcakez/otp/compare/fix-supervisor-multi-restart.patch > > King Regards, > James > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Thu Apr 4 14:21:39 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 4 Apr 2013 14:21:39 +0200 Subject: [erlang-patches] Fix one_for_all and rest_for_one supervisor multiple restarts In-Reply-To: References: Message-ID: <515D7053.4080202@erlang.org> On 04/04/2013 02:09 PM, James Fish wrote: > Sorry that should be: > git fetch git://github.com/fishcakez/otp.git > fix-supervisor-multi-restart > > > On 4 April 2013 13:05, James Fish > wrote: > > Hi, > > When a child in a rest_for_one or one_for_all supervisor dies and > is then restarted but a child later in the child specification > fails to start - so that the restart fails - the restarted child's > pid is ignored by the supervisor and is not terminated. The > supervisor will then attempt to restart that child again - leaving > the unaccounted for process alive! > > An example of this is available here: > https://gist.github.com/fishcakez/5296408 > > In this patch the supervisor changes the restarting child to the > one that failed to start. In the case of one_for_all this means > that the successfully restarted child is terminated (along with > the other successfully restarted children). In the case of > rest_for_one all successfully restarted children remain, and > restarting begins with the child that failed to start. Should this > be document? The way a rest_for_one handles this case is not > documented. > > git fetch git://github.com/fishcakez/otp.git > fix-server-multi-restart > > https://github.com/fishcakez/otp/compare/fix-supervisor-multi-restart > https://github.com/fishcakez/otp/compare/fix-supervisor-multi-restart.patch > > King Regards, > James > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello James, I have fetched your branch and a reviewing process will now start. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Apr 4 15:38:31 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 4 Apr 2013 15:38:31 +0200 Subject: [erlang-patches] [erlang-bugs] R16 breaks dots In-Reply-To: <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> References: <20130329203406.GB1251@zushakon> <13603AE6-E8E6-4EAD-899F-35D9CD7D2187@gmail.com> <51576CF7.6010905@gmail.com> <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> Message-ID: On Mon, Apr 1, 2013 at 6:34 PM, Anthony Ramine wrote: > Hello, > > I wrote a patch that allows dotted atoms everywhere in the syntax but > record expressions, where they would be ambiguous. I wrote no tests as I > have no idea where they should go. Furthermore, I think that maybe the > pretty-printer should be patched to not quote dotted atoms outside record > expressions. > > git fetch https://github.com/nox/otp.git restore-dotted-atoms > > > https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms > > https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms.patch > > Rejected. The Technical Board did discuss the matter of dots in atoms and decided that the support should be removed along with packages. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Apr 4 15:45:58 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 4 Apr 2013 15:45:58 +0200 Subject: [erlang-patches] [erlang-bugs] R16 breaks dots In-Reply-To: References: <20130329203406.GB1251@zushakon> <13603AE6-E8E6-4EAD-899F-35D9CD7D2187@gmail.com> <51576CF7.6010905@gmail.com> <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> Message-ID: <3F6CD158-AF0E-4F16-AB72-4DFE84118C0B@gmail.com> Hello Bj?rn, Could we have more details about why the Technical Board decided that? Regards, -- Anthony Ramine Le 4 avr. 2013 ? 15:38, Bj?rn Gustavsson a ?crit : > > On Mon, Apr 1, 2013 at 6:34 PM, Anthony Ramine wrote: > Hello, > > I wrote a patch that allows dotted atoms everywhere in the syntax but record expressions, where they would be ambiguous. I wrote no tests as I have no idea where they should go. Furthermore, I think that maybe the pretty-printer should be patched to not quote dotted atoms outside record expressions. > > git fetch https://github.com/nox/otp.git restore-dotted-atoms > > https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms > https://github.com/nox/otp/compare/erlang:maint...restore-dotted-atoms.patch > > > Rejected. > > The Technical Board did discuss the matter of dots in atoms and > decided that the support should be removed along with packages. > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Thu Apr 4 15:46:58 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 4 Apr 2013 15:46:58 +0200 Subject: [erlang-patches] Bit string generators, unsized binaries, modules and the REPL In-Reply-To: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> References: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> Message-ID: On Sun, Mar 31, 2013 at 4:22 PM, Anthony Ramine wrote: > > This patch implements this new error and simplifies how v3_core works with > forbidden unsized tail segments in patterns of bit string generators. > > git fetch https://github.com/nox/otp illegal-bitstring-gen-pattern > > > https://github.com/nox/otp/compare/erlang:maint...illegal-bitstring-gen-pattern > > https://github.com/nox/otp/compare/erlang:maint...illegal-bitstring-gen-pattern.patch > > Looking at the commit 5daa001 by Bj?rn Gustavsson "Don't generate multiple > tail segments in binary matching", this patch will probably by rejected as > it seems the compiler behaves as wanted by the OTP team. If this is indeed > the case, erl_eval should be fixed. > > Not really. I noticed that the implementation was flaky and fixed it. The Technical Board will discuss the matter. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Apr 4 15:56:57 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 4 Apr 2013 15:56:57 +0200 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> Message-ID: On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine wrote: > Hi, > > I rebased my patch against latest maint. It should be safe to merge it now > that > Kostis fixed the bug in HiPE. > > I have learned from my own experience that compiler optimizations are always much easier to get wrong than one would think. Therefore, we no longer include new compiler optimizations in minor releases. So, unfortunately, we can only include your patch in R17. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Apr 4 16:03:30 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 4 Apr 2013 16:03:30 +0200 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> <50F52480.9040100@erlang.org> <50F5325B.4010005@erlang.org> <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> <50FE512C.8020905@erlang.org> Message-ID: <185EEAD8-2C06-4BCB-8863-B6F8CC79460D@gmail.com> Will it be merged into master now or will I need to yet again submit it when R17 is around? -- Anthony Ramine Le 4 avr. 2013 ? 15:56, Bj?rn Gustavsson a ?crit : > On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine wrote: > Hi, > > I rebased my patch against latest maint. It should be safe to merge it now that > Kostis fixed the bug in HiPE. > > > I have learned from my own experience that compiler optimizations > are always much easier to get wrong than one would think. > > Therefore, we no longer include new compiler optimizations > in minor releases. > > So, unfortunately, we can only include your patch in R17. > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Apr 5 12:56:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 5 Apr 2013 12:56:16 +0200 Subject: [erlang-patches] Optimize communication with file io server Message-ID: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Hello, This patch adds the monitor references to the file io protocol to optimize the receive expressions in the 'file' module. git fetch https://github.com/nox/otp.git file-receive-optim https://github.com/nox/otp/compare/erlang:maint...file-receive-optim https://github.com/nox/otp/compare/erlang:maint...file-receive-optim.patch Regards, -- Anthony Ramine From essen@REDACTED Fri Apr 5 13:10:54 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 05 Apr 2013 13:10:54 +0200 Subject: [erlang-patches] Use erlang:demonitor(Ref, [flush]) where applicable Message-ID: <515EB13E.1050205@ninenines.eu> Hello, This patch complements Anthony Ramine's by replacing erlang:demonitor/1 calls with erlang:demonitor(Ref, [flush]) where applicable, except in the 'file' module where a better optimization was done in his patch. A define test on SNMP_R10 was removed as this probably isn't used anymore. The token wasn't found anywhere else in the repository. git fetch https://github.com/essen/otp.git demonitor-flush https://github.com/essen/otp/compare/erlang:maint...demonitor-flush https://github.com/essen/otp/compare/erlang:maint...demonitor-flush.patch Enjoy! -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From egil@REDACTED Fri Apr 5 13:27:44 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 5 Apr 2013 13:27:44 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: <515EB530.3050902@erlang.org> On 2013-04-05 12:56, Anthony Ramine wrote: > Hello, > > This patch adds the monitor references to the file io protocol to optimize the receive expressions in the 'file' module. > > git fetch https://github.com/nox/otp.git file-receive-optim > > https://github.com/nox/otp/compare/erlang:maint...file-receive-optim > https://github.com/nox/otp/compare/erlang:maint...file-receive-optim.patch > > Regards, > Out of curiosity: have you any measurements on speedup with your optimization? // Bj?rn-Egil From fredrik@REDACTED Fri Apr 5 13:28:57 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 5 Apr 2013 13:28:57 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: <515EB579.7070802@erlang.org> On 04/05/2013 12:56 PM, Anthony Ramine wrote: > Hello, > > This patch adds the monitor references to the file io protocol to optimize the receive expressions in the 'file' module. > > git fetch https://github.com/nox/otp.git file-receive-optim > > https://github.com/nox/otp/compare/erlang:maint...file-receive-optim > https://github.com/nox/otp/compare/erlang:maint...file-receive-optim.patch > > Regards, > Fetched, It is now located in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Fri Apr 5 13:30:53 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 5 Apr 2013 13:30:53 +0200 Subject: [erlang-patches] Use erlang:demonitor(Ref, [flush]) where applicable In-Reply-To: <515EB13E.1050205@ninenines.eu> References: <515EB13E.1050205@ninenines.eu> Message-ID: <515EB5ED.8080906@erlang.org> On 04/05/2013 01:10 PM, Lo?c Hoguin wrote: > Hello, > > This patch complements Anthony Ramine's by replacing > erlang:demonitor/1 calls with erlang:demonitor(Ref, [flush]) where > applicable, except in the 'file' module where a better optimization > was done in his patch. > > A define test on SNMP_R10 was removed as this probably isn't used > anymore. The token wasn't found anywhere else in the repository. > > git fetch https://github.com/essen/otp.git demonitor-flush > > https://github.com/essen/otp/compare/erlang:maint...demonitor-flush > https://github.com/essen/otp/compare/erlang:maint...demonitor-flush.patch > > > Enjoy! > Fetched, Your patch is now located in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Fri Apr 5 13:44:48 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 5 Apr 2013 13:44:48 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <515EB530.3050902@erlang.org> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> <515EB530.3050902@erlang.org> Message-ID: <84465956-953B-4366-9A55-3D99517C2C3D@gmail.com> Hello Bj?rn, I'll be honest and admit that I'm too lazy to measure anything for that. Do you think it could actually be slower? Why would it be? Regards, -- Anthony Ramine Le 5 avr. 2013 ? 13:27, Bj?rn-Egil Dahlberg a ?crit : > On 2013-04-05 12:56, Anthony Ramine wrote: >> Hello, >> >> This patch adds the monitor references to the file io protocol to optimize the receive expressions in the 'file' module. >> >> git fetch https://github.com/nox/otp.git file-receive-optim >> >> https://github.com/nox/otp/compare/erlang:maint...file-receive-optim >> https://github.com/nox/otp/compare/erlang:maint...file-receive-optim.patch >> >> Regards, >> > Out of curiosity: have you any measurements on speedup with your optimization? > > // Bj?rn-Egil > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From egil@REDACTED Fri Apr 5 14:40:24 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 5 Apr 2013 14:40:24 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <84465956-953B-4366-9A55-3D99517C2C3D@gmail.com> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> <515EB530.3050902@erlang.org> <84465956-953B-4366-9A55-3D99517C2C3D@gmail.com> Message-ID: <515EC638.9080206@erlang.org> On 2013-04-05 13:44, Anthony Ramine wrote: > Hello Bj?rn, > > I'll be honest and admit that I'm too lazy to measure anything for that. Do you think it could actually be slower? Why would it be? I wasn't implying anything negative like slower performance. =) I was more curious if you had seen any pathological cases, and how much performance increase it had with your patch. I guess it was more a "we don't use this optimization here, let's add it." ^^ // Bj?rn-Egil From erlangsiri@REDACTED Fri Apr 5 15:40:38 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 5 Apr 2013 15:40:38 +0200 Subject: [erlang-patches] fix a race condition when there're several applications in apps directory In-Reply-To: <515D5127.1090304@erlang.org> References: <515D4819.7030703@erlang.org> <6b5b59050473812efc49eb865fcf8154@bosqueviejo.net> <515D5127.1090304@erlang.org> Message-ID: Manuel - you need to do the same for the remote cover server in cover:remote_process_loop/1 (only two tables to remove there). Regards /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkondratenko@REDACTED Fri Apr 5 20:33:44 2013 From: alkondratenko@REDACTED (Aliaksey Kandratsenka) Date: Fri, 5 Apr 2013 11:33:44 -0700 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server Message-ID: Hi. I've recently found that timer_server actually does busy waits sometimes. Patch can be found here: git fetch git://github.com/alk/otp.git fix-cpu-overhead-of-timer-server https://github.com/alk/otp/compare/erlang:maint...fix-cpu-overhead-of-timer-server https://github.com/alk/otp/compare/erlang:maint...fix-cpu-overhead-of-timer-server.patch Please apply. Thanks. From andrew@REDACTED Sun Apr 7 11:14:41 2013 From: andrew@REDACTED (Andrew Tunnell-Jones) Date: Sun, 7 Apr 2013 19:14:41 +1000 Subject: [erlang-patches] Typo in type: erlang:process_info_item() Message-ID: The type for erlang:process_info_item() refers to 'message_que_len' rather than 'message_queue_len'. git fetch git://github.com/andrewtj/otp.git atj-fix-message_que_len-typo Best, Andrew From andrew@REDACTED Mon Apr 8 02:40:40 2013 From: andrew@REDACTED (Andrew Thompson) Date: Sun, 7 Apr 2013 20:40:40 -0400 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <515EB579.7070802@erlang.org> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> <515EB579.7070802@erlang.org> Message-ID: <20130408004040.GA24105@hijacked.us> This patch looks very good. I've been thinking of doing something similar for prim_file as well, so files opened in raw mode can also benefit from this optimization. Andrew From n.oxyde@REDACTED Mon Apr 8 08:06:21 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 8 Apr 2013 08:06:21 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <20130408004040.GA24105@hijacked.us> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> <515EB579.7070802@erlang.org> <20130408004040.GA24105@hijacked.us> Message-ID: <03FE488B-8BCC-4016-8921-74F8A7F4263F@gmail.com> Hello Andrew, I don't see any make_ref/1 call nor any monitor use in prim_file.erl, what are you talking about? Regards, -- Anthony Ramine Le 8 avr. 2013 ? 02:40, Andrew Thompson a ?crit : > This patch looks very good. I've been thinking of doing something > similar for prim_file as well, so files opened in raw mode can also > benefit from this optimization. > > Andrew From fredrik@REDACTED Mon Apr 8 10:21:49 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 8 Apr 2013 10:21:49 +0200 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: <51627E1D.80805@erlang.org> On 04/05/2013 08:33 PM, Aliaksey Kandratsenka wrote: > Hi. > > I've recently found that timer_server actually does busy waits > sometimes. Patch can be found here: > > git fetch git://github.com/alk/otp.git fix-cpu-overhead-of-timer-server > > https://github.com/alk/otp/compare/erlang:maint...fix-cpu-overhead-of-timer-server > https://github.com/alk/otp/compare/erlang:maint...fix-cpu-overhead-of-timer-server.patch > > Please apply. Thanks. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Aliaksey, Your patch is sent to review by responsible development team. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Apr 8 10:32:28 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 8 Apr 2013 10:32:28 +0200 Subject: [erlang-patches] Typo in type: erlang:process_info_item() In-Reply-To: References: Message-ID: <5162809C.20309@erlang.org> On 04/07/2013 11:14 AM, Andrew Tunnell-Jones wrote: > The type for erlang:process_info_item() refers to 'message_que_len' > rather than 'message_queue_len'. > > git fetch git://github.com/andrewtj/otp.git atj-fix-message_que_len-typo > > Best, > Andrew > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, This patch is now in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From aronisstav@REDACTED Mon Apr 8 11:31:41 2013 From: aronisstav@REDACTED (Stavros Aronis) Date: Mon, 8 Apr 2013 11:31:41 +0200 Subject: [erlang-patches] Dialyzer: Bitstring type inference and duplicate module error message fixes Message-ID: Hi! This branch includes the fix proposed by Maxim Treskin for the error message when duplicate modules are given as input to Dialyzer, together with a fix in the type inference algorithm, related to bitstrings. git fetch git://github.com/aronisstav/otp.git dialyzer-bitstring-fixes Cheers, Stavros From fredrik@REDACTED Mon Apr 8 11:33:51 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 8 Apr 2013 11:33:51 +0200 Subject: [erlang-patches] Dialyzer: Bitstring type inference and duplicate module error message fixes In-Reply-To: References: Message-ID: <51628EFF.7060505@erlang.org> On 04/08/2013 11:31 AM, Stavros Aronis wrote: > Hi! > > This branch includes the fix proposed by Maxim Treskin for the error > message when duplicate modules are given as input to Dialyzer, > together with a fix in the type inference algorithm, related to > bitstrings. > > git fetch git://github.com/aronisstav/otp.git dialyzer-bitstring-fixes > > Cheers, > > Stavros > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Stavros, I am including it in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From bgustavsson@REDACTED Mon Apr 8 16:04:02 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 8 Apr 2013 16:04:02 +0200 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: Thanks for the bug report and patch! The patch, however, is not acceptable since it replaces a call to erlang:now/0 with a call to os:timestamp/0. os:timestamp/0 does no time correction while erlang:now/0 does, so there will be trouble if time correction is being done. Did you have any particular reason to use os:timestamp/0? It seems to me that using erlang:now/0 should work just as well. How did you find the bug? Do you have a test case or a program to provoke the bug? /Bjorn On Fri, Apr 5, 2013 at 8:33 PM, Aliaksey Kandratsenka < alkondratenko@REDACTED> wrote: > Hi. > > I've recently found that timer_server actually does busy waits > sometimes. Patch can be found here: > > git fetch git://github.com/alk/otp.git fix-cpu-overhead-of-timer-server > > > https://github.com/alk/otp/compare/erlang:maint...fix-cpu-overhead-of-timer-server > > https://github.com/alk/otp/compare/erlang:maint...fix-cpu-overhead-of-timer-server.patch > > Please apply. Thanks. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkondratenko@REDACTED Mon Apr 8 16:40:19 2013 From: alkondratenko@REDACTED (Aliaksey Kandratsenka) Date: Mon, 8 Apr 2013 07:40:19 -0700 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Mon, Apr 8, 2013 at 7:04 AM, Bj?rn Gustavsson wrote: > Thanks for the bug report and patch! > > The patch, however, is not acceptable since > it replaces a call to erlang:now/0 with a call to > os:timestamp/0. os:timestamp/0 does no > time correction while erlang:now/0 does, so there > will be trouble if time correction is being done. > > Did you have any particular reason to use > os:timestamp/0? It seems to me that using > erlang:now/0 should work just as well. > It would work reasonably well. But here's my thinking. If wall clock time jumps backward then os:timestamp will also jump backwards and we're screwed. I.e. no ticks will happen until time will naturally advance to a time before jump. erlang:now will not jump backwards, but it will not do any "time correction" either. It'll just "crawl forward" by 1 microsecond per erlang:now call which is in my definition screwed either. If wall clock time jumps forward same behavior of both time reading functions is same. We'll tick all missed ticks in that jumped interval. Which is btw a behavior we should consider fixing either. But that's a separate topic. Overall I believe exposing OS monotonic clock is best option for handling clock jumps. Which is a separate topic. Anyway let me know if you insist on erlang:now > How did you find the bug? Do you have a > test case or a program to provoke the bug? > I've spotted timer_server in etop in highest position in our program (management layer of couchbase server) that has few tens of interval timers and started tracing it. Which is how I discovered those weird sequences of timeouts at same timestamp. So no I don't have a test case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkondratenko@REDACTED Mon Apr 8 16:55:26 2013 From: alkondratenko@REDACTED (Aliaksey Kandratsenka) Date: Mon, 8 Apr 2013 07:55:26 -0700 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Mon, Apr 8, 2013 at 7:40 AM, Aliaksey Kandratsenka < alkondratenko@REDACTED> wrote: > > > > On Mon, Apr 8, 2013 at 7:04 AM, Bj?rn Gustavsson wrote: > >> Thanks for the bug report and patch! >> >> The patch, however, is not acceptable since >> it replaces a call to erlang:now/0 with a call to >> os:timestamp/0. os:timestamp/0 does no >> time correction while erlang:now/0 does, so there >> will be trouble if time correction is being done. >> >> Did you have any particular reason to use >> os:timestamp/0? It seems to me that using >> erlang:now/0 should work just as well. >> > > It would work reasonably well. > > But here's my thinking. > > If wall clock time jumps backward then os:timestamp will also jump > backwards and we're screwed. I.e. no ticks will happen until time will > naturally advance to a time before jump. erlang:now will not jump > backwards, but it will not do any "time correction" either. It'll just > "crawl forward" by 1 microsecond per erlang:now call which is in my > definition screwed either. > Actually I forgot but my thinking was a bit more elaborate. If we use erlang:now and time jumps backwards. We'll have time as seen by receive X -> X after AfterMillis -> ok end flow normally, but erlang:now will crawl. Which can be seen to cause same busy wait in timer server but just for much longer (i.e. until erlang:now overtakes os:timestamp where that "never go back" code path stops being hit and time flows normal again). I should have noted that in git comment but forgot. Let me know if you need anything more from me. Like adjusted git comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Tue Apr 9 11:58:48 2013 From: pan@REDACTED (Patrik Nyblom) Date: Tue, 9 Apr 2013 11:58:48 +0200 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: <5163E658.5080408@erlang.org> On 04/08/2013 04:55 PM, Aliaksey Kandratsenka wrote: > > > > On Mon, Apr 8, 2013 at 7:40 AM, Aliaksey Kandratsenka > > wrote: > > > > > On Mon, Apr 8, 2013 at 7:04 AM, Bj?rn Gustavsson > > wrote: > > Thanks for the bug report and patch! > > The patch, however, is not acceptable since > it replaces a call to erlang:now/0 with a call to > os:timestamp/0. os:timestamp/0 does no > time correction while erlang:now/0 does, so there > will be trouble if time correction is being done. > > Did you have any particular reason to use > os:timestamp/0? It seems to me that using > erlang:now/0 should work just as well. > > > It would work reasonably well. > > But here's my thinking. > > If wall clock time jumps backward then os:timestamp will also jump > backwards and we're screwed. I.e. no ticks will happen until time > will naturally advance to a time before jump. erlang:now will not > jump backwards, but it will not do any "time correction" either. > It'll just "crawl forward" by 1 microsecond per erlang:now call > which is in my definition screwed either. > > > Actually I forgot but my thinking was a bit more elaborate. > > If we use erlang:now and time jumps backwards. We'll have time as seen > by receive X -> X after AfterMillis -> ok end flow normally, but > erlang:now will crawl. Which can be seen to cause same busy wait in > timer server but just for much longer (i.e. until erlang:now overtakes > os:timestamp where that "never go back" code path stops being hit and > time flows normal again). Erlang:now() will not crawl. It will move forward at a steady pace which is the best approximation of time moving forward, exactly as the timers. It will very slowly *converge* with the wall clock time. Time, as now() presents it, might move one percent slower or faster than what your wall-clock shows, but it will never "crawl". now() is the best approximation of the time in the system. If the wall clock moves it will try to converge, as the assumption is the wall clock has moved for a reason. now() uses a monotonic timer together with the wall clock to estimate a "real" time, which is the best we can get given normal hardware. Unfortunately someone also thought that now() should give unique values, which makes it a bottleneck and has prompted more use of os:timestamp() than what's really good. timestamp() will jump around like crazy if someone decides to "fix the time" on the box, giving all kinds of troubles. It can be used for logging, debugging, profiling etc, but never for real timeouts. Best regards, /Patrik > > I should have noted that in git comment but forgot. > > Let me know if you need anything more from me. Like adjusted git comment. > > > _______________________________________________ > 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 Tue Apr 9 12:00:05 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 9 Apr 2013 12:00:05 +0200 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Mon, Apr 8, 2013 at 4:55 PM, Aliaksey Kandratsenka < alkondratenko@REDACTED> wrote: > > > If we use erlang:now and time jumps backwards. We'll have time as seen by > receive X -> X after AfterMillis -> ok end flow normally, but erlang:now > will crawl. Which can be seen to cause same busy wait in timer server but > just for much longer (i.e. until erlang:now overtakes os:timestamp where > that "never go back" code path stops being hit and time flows normal again). > > That should not happen. Time correction means that the time returned by erlang:now/0 (and most other time functions) will move one per cent slower or faster until the correct wall-clock time has been reached. The time used internally by 'receive after' will also use the corrected time. We have been thinking about documenting the time correction mechanism in one place, describing how it works and listing all time functions and whether they used the corrected time or not. I should have noted that in git comment but forgot. > > Let me know if you need anything more from me. Like adjusted git comment. > I suggest that you change your patch to use erlang:now/0 and verify that it solves the problem in your application. Alternately, edit your commit message to give us *very* compelling reasons why os:timestamp/0 would work better than erlang:now/0. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Tue Apr 9 12:12:00 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 9 Apr 2013 12:12:00 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: The patch looks fine and it would be a good thing to do. Unfortunately, there is the pesky question of backward compatibility. Someone can open a file on an R15 system, send the file descriptor (=a pid) to an R16B01 system with your patch and the R16B01 system will attempt to do file operations on the file. The backward compatible way to do this is to first introduce a file_io_server module that can handle both the new and the old messages. Two releases later the file module can be changed to use the new message format. Strictly speaking, two releases forward means R19 to allow the original R16B release to communicate with an R18 release. /Bjorn On Fri, Apr 5, 2013 at 12:56 PM, Anthony Ramine wrote: > Hello, > > This patch adds the monitor references to the file io protocol to optimize > the receive expressions in the 'file' module. > > git fetch https://github.com/nox/otp.git file-receive-optim > > > https://github.com/nox/otp/compare/erlang:maint...file-receive-optim > > https://github.com/nox/otp/compare/erlang:maint...file-receive-optim.patch > > Regards, > > -- > Anthony Ramine > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc@REDACTED Tue Apr 9 14:27:52 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Tue, 9 Apr 2013 08:27:52 -0400 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler In-Reply-To: References: <513F372D.9090106@erlang.org> Message-ID: Following changes have been made.. error_logger_SUITE tests added. error_logger module specs updated. better explanation added to commit message. Branch rebased and updated. Thanks. On Tue, Mar 12, 2013 at 11:03 AM, Pedram Nimreezi wrote: > Thank you for the update, I'll make the proper changes. > > On Tue, Mar 12, 2013 at 10:09 AM, Fredrik wrote: > > On 03/01/2013 08:15 PM, Pedram Nimreezi wrote: > >> > >> Hi, > >> > >> This patch adds add_report_sup_handler to the error_logger module > >> > >> To eliminate the need to go around the error_logger api, this patch > >> allows for a report_handler to be added via add_sup_handler. > >> > >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch > >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler > >> > >> git fetch git://github.com/DeadZen/otp.git error-logger-sup_handler > >> > > Hello again, > > I've got some feedback on your patch. > > *The patch needs tests and documentation > > *The spec for add_report_sup_handler/1 is not sufficient, should it be > > "any()" really? > > *Your commit message is to short and needs further explanation. > > > > > > -- > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Apr 9 14:33:26 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 9 Apr 2013 14:33:26 +0200 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler In-Reply-To: References: <513F372D.9090106@erlang.org> Message-ID: <51640A96.2080509@erlang.org> On 04/09/2013 02:27 PM, Pedram Nimreezi wrote: > Following changes have been made.. > error_logger_SUITE tests added. > error_logger module specs updated. > better explanation added to commit message. > > Branch rebased and updated. Thanks. > > > On Tue, Mar 12, 2013 at 11:03 AM, Pedram Nimreezi > > wrote: > > Thank you for the update, I'll make the proper changes. > > On Tue, Mar 12, 2013 at 10:09 AM, Fredrik > wrote: > > On 03/01/2013 08:15 PM, Pedram Nimreezi wrote: > >> > >> Hi, > >> > >> This patch adds add_report_sup_handler to the error_logger module > >> > >> To eliminate the need to go around the error_logger api, this patch > >> allows for a report_handler to be added via add_sup_handler. > >> > >> > https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch > >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler > >> > >> git fetch git://github.com/DeadZen/otp.git > error-logger-sup_handler > >> > > Hello again, > > I've got some feedback on your patch. > > *The patch needs tests and documentation > > *The spec for add_report_sup_handler/1 is not sufficient, should > it be > > "any()" really? > > *Your commit message is to short and needs further explanation. > > > > > > -- > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald > Norman > > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > > Great, Re-fetched and assigned it for review again. -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue Apr 9 16:10:27 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 9 Apr 2013 16:10:27 +0200 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130403125325.GD338@aluminium.local> References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> <20130403125325.GD338@aluminium.local> Message-ID: Hi Vance! Is this feature mostly for use with simple_one_for_one supervisors? I believe (possibly faulty??) that these are the most common supervisor for which many children are repeatedly restarted as a part of normal execution. Could you say something more about your use case? Other input on this? Regarding the implementation, one could say that the behavior differs a little bit for different types of supervisors and child restart types. (This is of course due to the nature of the supervisor/child types): * simple_one_for_one supervisor (all child restart types) -> Limit is compared to the number of alive children. * other supervisor type, temporary children -> Limit is compared to the number of alive children. * other supervisor type, non-temporary children -> Limit is compared to the number of child specs. The very least we need to consider is if this is the correct behavior, and if so I think it needs to be mentioned in the documentation. Or should the feature be restricted to simple_one_for_one supervisors (or is it only me?)? Regards siri@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkondratenko@REDACTED Tue Apr 9 21:27:49 2013 From: alkondratenko@REDACTED (Aliaksey Kandratsenka) Date: Tue, 9 Apr 2013 12:27:49 -0700 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 3:00 AM, Bj?rn Gustavsson wrote: > > On Mon, Apr 8, 2013 at 4:55 PM, Aliaksey Kandratsenka < > alkondratenko@REDACTED> wrote: >> >> >> If we use erlang:now and time jumps backwards. We'll have time as seen by >> receive X -> X after AfterMillis -> ok end flow normally, but erlang:now >> will crawl. Which can be seen to cause same busy wait in timer server but >> just for much longer (i.e. until erlang:now overtakes os:timestamp where >> that "never go back" code path stops being hit and time flows normal again). >> >> > That should not happen. > > Time correction means that the time returned by erlang:now/0 > (and most other time functions) will move one per cent slower > or faster until the correct wall-clock time has been reached. The > time used internally by 'receive after' will also use the corrected time. > > We have been thinking about documenting the time > correction mechanism in one place, describing how it works and listing all > time functions and whether they used the corrected time or not. > Thanks for pointing this out. Indeed I don't know how I managed but I misread the code. I've updated patch to use erlang:now instead of os:timestamp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Apr 9 23:40:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 9 Apr 2013 23:40:03 +0200 Subject: [erlang-patches] Move let expressions into sequences Message-ID: <53915A78-30EF-40B5-832A-C2D754FB56B5@gmail.com> Hello, The Core Erlang compiler simplifies let expressions by moving them into their argument when it is another let or a case expression. It can then perform other optimizations such as removing the let expressions altogether, sometimes saving BEAM registers later in the process. This patch teaches sys_core_fold how to move let expressions into sequence arguments. git fetch https://github.com/nox/otp.git move-let-into-seq https://github.com/nox/otp/compare/erlang:maint...move-let-into-seq https://github.com/nox/otp/compare/erlang:maint...move-let-into-seq.patch For the record, I managed to encounter this while working on the file optimization in branch file-receive-optim. You can find a short file showing seq in let in the following gist: https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-core-L14 https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-erl Regards, -- Anthony Ramine From n.oxyde@REDACTED Wed Apr 10 00:19:31 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 10 Apr 2013 00:19:31 +0200 Subject: [erlang-patches] Use a set to store ref registers in beam_receive Message-ID: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> Hello, In some circumstances, as when inlining code, when some optimization passes are disabled or with hand-written but semantically correct Core Erlang or BEAM assembly, a fresh reference may be live in more than one register: ... {allocate_zero,2,2}. ... {call_ext,0,{extfunc,erlang,make_ref,0}}. % Ref in [x0] ... {move,{x,0},{y,0}}. % Ref in [x0,y0] {move,{y,1},{x,0}}. % Ref in [y0] ... {move,{y,0},{x,0}}. % Ref in [x0,y0] {move,{x,0},{y,1}}. % Ref in [x0,y0,y1] {label,5}. {loop_rec,{f,6},{x,0}}. % Ref in [y0,y1] ... {loop_rec_end,{f,5}}. {label,6}. {wait,{f,5}}. ... Pass beam_receive expects a single live register for the ref when it encounters the loop_rec instruction and crashes with the following reason: $ erlc t.S ... crash reason: {{case_clause, {'EXIT', {{case_clause,[{y,1},{y,0}]}, [{beam_receive,opt_recv,5, [{file,"beam_receive.erl"},{line,154}]}, ...]}}}, ...} This patch teaches beam_receive how to use a set of registers instead of a single one when tracking fresh references, thus avoiding the crash. git fetch https://github.com/nox/otp.git fix-multiple-ref-regs https://github.com/nox/otp/compare/erlang:maint...fix-multiple-ref-regs https://github.com/nox/otp/compare/erlang:maint...fix-multiple-ref-regs.patch This is yet again something that I encountered while working on the file optimization branch file-receive-optim: https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-codegen Regards, -- Anthony Ramine From n.oxyde@REDACTED Wed Apr 10 00:29:02 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 10 Apr 2013 00:29:02 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: Hello Bj?rn, I found a way to make it backwards compatible with the old protocol right now. The file module communicates with a file io server with the following protocol for file operations: > {file_request,From,ReplyAs,Request} < {file_reply,ReplyAs,Reply} The ReplyAs value is sent by the client side to match against when receiving the reply and is otherwise left untouched and passed as is by the server. The amended commit changes the protocol to: > {file_request,From,MonitorRef,Request} < {file_reply,MonitorRef,Reply} As the shape of the messages is not changed, backwards compatibility is not a concern. Unfortunately, the following patch fails to compile because of a bug in the optimization pass. I've submitted two other patches; the first fixes beam_receive by teaching it how to track a set of registers instead of a single one, making it able to cope with the Core Erlang code generated by the inliner, the second improves sys_core_fold and makes it simplifies what is outputted by said inliner. Please refetch. Regards, -- Anthony Ramine Le 9 avr. 2013 ? 12:12, Bj?rn Gustavsson a ?crit : > The patch looks fine and it would be a good thing to do. > > Unfortunately, there is the pesky question of backward > compatibility. > > Someone can open a file on an R15 system, send the > file descriptor (=a pid) to an R16B01 system with your > patch and the R16B01 system will attempt to do file > operations on the file. > > The backward compatible way to do this is to first introduce > a file_io_server module that can handle both the new > and the old messages. Two releases later the file module > can be changed to use the new message format. > > Strictly speaking, two releases forward means R19 > to allow the original R16B release to communicate > with an R18 release. > > /Bjorn From fredrik@REDACTED Wed Apr 10 09:55:58 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 10 Apr 2013 09:55:58 +0200 Subject: [erlang-patches] Move let expressions into sequences In-Reply-To: <53915A78-30EF-40B5-832A-C2D754FB56B5@gmail.com> References: <53915A78-30EF-40B5-832A-C2D754FB56B5@gmail.com> Message-ID: <51651B0E.7090208@erlang.org> On 04/09/2013 11:40 PM, Anthony Ramine wrote: > Hello, > > The Core Erlang compiler simplifies let expressions by moving them into their argument when it is another let or a case expression. It can then perform other optimizations such as removing the let expressions altogether, sometimes saving BEAM registers later in the process. > > This patch teaches sys_core_fold how to move let expressions into sequence arguments. > > git fetch https://github.com/nox/otp.git move-let-into-seq > > https://github.com/nox/otp/compare/erlang:maint...move-let-into-seq > https://github.com/nox/otp/compare/erlang:maint...move-let-into-seq.patch > > For the record, I managed to encounter this while working on the file optimization in branch file-receive-optim. You can find a short file showing seq in let in the following gist: > > https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-core-L14 > https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-erl > > Regards, > Hello Anthony, Fetched your branch and currently in the 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Wed Apr 10 10:02:05 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 10 Apr 2013 10:02:05 +0200 Subject: [erlang-patches] Use a set to store ref registers in beam_receive In-Reply-To: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> References: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> Message-ID: <51651C7D.8080307@erlang.org> On 04/10/2013 12:19 AM, Anthony Ramine wrote: > Hello, > > In some circumstances, as when inlining code, when some optimization passes are disabled or with hand-written but semantically correct Core Erlang or BEAM assembly, a fresh reference may be live in more than one register: > > ... > {allocate_zero,2,2}. > ... > {call_ext,0,{extfunc,erlang,make_ref,0}}. % Ref in [x0] > ... > {move,{x,0},{y,0}}. % Ref in [x0,y0] > {move,{y,1},{x,0}}. % Ref in [y0] > ... > {move,{y,0},{x,0}}. % Ref in [x0,y0] > {move,{x,0},{y,1}}. % Ref in [x0,y0,y1] > {label,5}. > {loop_rec,{f,6},{x,0}}. % Ref in [y0,y1] > ... > {loop_rec_end,{f,5}}. > {label,6}. > {wait,{f,5}}. > ... > > Pass beam_receive expects a single live register for the ref when it encounters the loop_rec instruction and crashes with the following reason: > > $ erlc t.S > ... > crash reason: {{case_clause, > {'EXIT', > {{case_clause,[{y,1},{y,0}]}, > [{beam_receive,opt_recv,5, > [{file,"beam_receive.erl"},{line,154}]}, > ...]}}}, > ...} > > This patch teaches beam_receive how to use a set of registers instead of a single one when tracking fresh references, thus avoiding the crash. > > git fetch https://github.com/nox/otp.git fix-multiple-ref-regs > > https://github.com/nox/otp/compare/erlang:maint...fix-multiple-ref-regs > https://github.com/nox/otp/compare/erlang:maint...fix-multiple-ref-regs.patch > > This is yet again something that I encountered while working on the file optimization branch file-receive-optim: > > https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-codegen > > Regards, > Hello Anthony, Fetched your branch. Currently in the review state and in 'pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From erlangsiri@REDACTED Wed Apr 10 12:02:19 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 10 Apr 2013 12:02:19 +0200 Subject: [erlang-patches] Implement add_report_sup_handler which calls gen_event:add_sup_handler In-Reply-To: <51640A96.2080509@erlang.org> References: <513F372D.9090106@erlang.org> <51640A96.2080509@erlang.org> Message-ID: Hi Pedram! After looking closer at what gen_event:add_sup_handler does, I see that it sends a message if the handler is deleted. To avoid growing message queues, this would have to be taken care of in the error_logger - which would introduce the need to keep a state in the error_logger to know if the deleted handler is supervised (and a message should be flushed) or not. Could you please let us know a bit more about which problem the patch should solve and possible use cases? Regards /siri 2013/4/9 Fredrik > On 04/09/2013 02:27 PM, Pedram Nimreezi wrote: > > Following changes have been made.. > error_logger_SUITE tests added. > error_logger module specs updated. > better explanation added to commit message. > > Branch rebased and updated. Thanks. > > > On Tue, Mar 12, 2013 at 11:03 AM, Pedram Nimreezi wrote: > >> Thank you for the update, I'll make the proper changes. >> >> On Tue, Mar 12, 2013 at 10:09 AM, Fredrik wrote: >> > On 03/01/2013 08:15 PM, Pedram Nimreezi wrote: >> >> >> >> Hi, >> >> >> >> This patch adds add_report_sup_handler to the error_logger module >> >> >> >> To eliminate the need to go around the error_logger api, this patch >> >> allows for a report_handler to be added via add_sup_handler. >> >> >> >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler.patch >> >> https://github.com/DeadZen/otp/compare/error-logger-sup_handler >> >> >> >> git fetch git://github.com/DeadZen/otp.git error-logger-sup_handler >> >> >> > Hello again, >> > I've got some feedback on your patch. >> > *The patch needs tests and documentation >> > *The spec for add_report_sup_handler/1 is not sufficient, should it be >> > "any()" really? >> > *Your commit message is to short and needs further explanation. >> > >> > >> > -- >> > >> > BR Fredrik Gustafsson >> > Erlang OTP Team >> > >> > _______________________________________________ >> > erlang-patches mailing list >> > erlang-patches@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-patches >> >> >> >> -- >> /* Sincerely >> -------------------------------------------------------------- >> Pedram Nimreezi - Chief Technology Officer */ >> >> // The hardest part of design ? is keeping features out. - Donald Norman >> > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > > > Great, > Re-fetched and assigned it for review again. > > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Wed Apr 10 12:19:17 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 10 Apr 2013 12:19:17 +0200 Subject: [erlang-patches] [erlang-bugs] Use a set to store ref registers in beam_receive In-Reply-To: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> References: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> Message-ID: On Wed, Apr 10, 2013 at 12:19 AM, Anthony Ramine wrote: > > This patch teaches beam_receive how to use a set of registers instead of a > single one when tracking fresh references, thus avoiding the crash. > > git fetch https://github.com/nox/otp.git fix-multiple-ref-regs > > > https://github.com/nox/otp/compare/erlang:maint...fix-multiple-ref-regs > > https://github.com/nox/otp/compare/erlang:maint...fix-multiple-ref-regs.patch > > Could you write a test case? A copy of the receive_SUITE will be compiled with the inline option. If the inlining is not aggressive enough to provoke the bug, you can add the test case to inline_SUITE. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Apr 10 12:22:38 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 10 Apr 2013 12:22:38 +0200 Subject: [erlang-patches] [erlang-bugs] Use a set to store ref registers in beam_receive In-Reply-To: References: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> Message-ID: Hello Bj?rn, I'm not sure I understand what you mean, should I add my example function into receive_SUITE.erl as is to test that? I'm not sure that would demonstrate anything in the long term as my other cooking patch move-let-into-seq makes the culprit code where a reference is live in two Y registers disappear. Regards, -- Anthony Ramine Le 10 avr. 2013 ? 12:19, Bj?rn Gustavsson a ?crit : > Could you write a test case? > > A copy of the receive_SUITE will be compiled with the inline option. > If the inlining is not aggressive enough to provoke the bug, you can > add the test case to inline_SUITE. > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From vances@REDACTED Wed Apr 10 14:08:12 2013 From: vances@REDACTED (Vance Shipley) Date: Wed, 10 Apr 2013 17:38:12 +0530 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> <20130403125325.GD338@aluminium.local> Message-ID: <20130410120812.GB99642@aluminium.local> On Tue, Apr 09, 2013 at 04:10:27PM +0200, Siri Hansen wrote: } Is this feature mostly for use with simple_one_for_one supervisors? My current use case scenario is, yes. } I believe (possibly faulty??) that these are the most common supervisor for } which many children are repeatedly restarted as a part of normal execution. Yes, I would agree. } Could you say something more about your use case? Other input on this? In my case we are creating a child worker process to manage the lifecycle of a transaction. We process thousands of transactions per second. A transaction may take tens of milliseconds or tens of seconds. We require a limit on the number of possible ongoing transactions. } Regarding the implementation, one could say that the behavior differs a } little bit for different types of supervisors and child restart types. It differs a little bit. My description was: "If Limit or more children are already specified for the supervisor start_child/3 returns {error,child_limit}." My implementation counts the child specifications. } * simple_one_for_one supervisor (all child restart types) -> Limit is } compared to the number of alive children. } * other supervisor type, temporary children -> Limit is compared to the } number of alive children. } * other supervisor type, non-temporary children -> Limit is compared to the } number of child specs. Effectively yes, however it's really just the number of child_spec() as we are not using is_process_alive/1 to prove it. Really it's a limit on the number of child_spec() which may exist. } The very least we need to consider is if this is the correct behavior, and } if so I think it needs to be mentioned in the documentation. Or should the } feature be restricted to simple_one_for_one supervisors (or is it only me?)? I didn't see any reason to restrict it to simple_one_for_one supervisors. You could use supervisor:start_child/2 to add thousands of children to a one_for_one supervisor. If you were doing that you might just want to limit the number of such child_spec() being added. What do you think about Richard's suggestion that start_child/3 should take an Options::list() argument instead with {child_limit, N::pos_integer()} as the only currently defined option? -- -Vance From mononcqc@REDACTED Wed Apr 10 14:51:11 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 10 Apr 2013 08:51:11 -0400 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130410120812.GB99642@aluminium.local> References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> <20130403125325.GD338@aluminium.local> <20130410120812.GB99642@aluminium.local> Message-ID: <20130410125109.GA24064@ferdair.local> On 04/10, Vance Shipley wrote: > > In my case we are creating a child worker process to manage the lifecycle > of a transaction. We process thousands of transactions per second. A > transaction may take tens of milliseconds or tens of seconds. We require > a limit on the number of possible ongoing transactions. > Have you considered using ETS counters, and possibly a monitor process? The idea being that if you have thousands of connections, trying to increment an ETS counter outside of the supervision structure? In my experience with whatever ended up being high throughput or low latency, what could kill you was not the fact that the counter was necessarily high, but how much contention there is to it. If you're in the kind of position where you need to limit the number of transactions to avoid falling over, it will *not* reduce the number of messages sent to the supervisor, and if you start going over the top, you'll time out no matter what, just because the supervisor won't be able to keep up with the demand. It takes a while before reaching that level, but in these cases, what I end up doing most of the time is holding an ETS counter that maintains itself at most to the max level given. Increment the counter as an atomic operation (a write operation that also reads, so you benefit from {read_concurrency,true} as an option). Assuming an entry of the form {transactions, N}: -spec can_start(ets:tid()) -> boolean(). can_start(Table) -> %% the counter should start at 0 when initiating things MaxValue = application:get_env(your_app, max_trans), MaxValue > ets:update_counter(Table, transactions, {2, 1, MaxValue, MaxValue}). Using that command, the max value will be easily configurable, will keep a ceiling set to the max value in there, and will be much, much faster to deny (and accept) requests while keeping your supervisor less loaded. Now what you'll need is a monitor process that will be able to decrement the counter for you when you're done, but only with processes that managed to get started. The management stuff can forget all about the processes that couldn't get in there. In practices, it works very well, and I've used a similar architecture for dispcount (https://github.com/ferd/dispcount), which has been used in production for over a year for low-latency scenarios. Now dispcount uses a fixed pool size and *is* a pool, but the same mechanisms can be applied to a more central system where one main counter is used. This will, in my experience, be more scalable as an approach than modifying supervisors' internal state and relying on it. In the benchmarks we ran at the job where I wrote dispcount, a single process could chug on maybe 9000 messages a second before starting to get swamped and using more resources than necessary (I can't remember what hardware I used for the benchmark). Using the ETS approach on the same hardware, I wasn't able to even get to the point where it was problematic -- allocation of processes to generate contention and gathering statistics turned out to be a bigger bottleneck. That's without counting that using ETS counters, getting a response back was a matter of microseconds, or had peak times under 5ms. Using messages, it was very easy to see roundtrip times well above 70ms, and those were with dedicated processes, not processes like supervisors that also need to do a lot of other stuff. As I said, it is more scalable and more performant. It is, however, not available out of the box. Regards, Fred. From mononcqc@REDACTED Wed Apr 10 15:03:37 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 10 Apr 2013 09:03:37 -0400 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130410125109.GA24064@ferdair.local> References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> <20130403125325.GD338@aluminium.local> <20130410120812.GB99642@aluminium.local> <20130410125109.GA24064@ferdair.local> Message-ID: <20130410130334.GB24064@ferdair.local> On 04/10, Fred Hebert wrote: > [...] Increment the counter as an atomic operation (a write operation > that also reads, so you benefit from {read_concurrency,true} as an > option). Assuming an entry of the form {transactions, N}: > Sorry, this should read {write_concurrency,true}. Using update_counter/3 is a write-only operation that both lets you change and get the value of the counter. I tend to segregate such counters to their own table (or use read operations very, very selectively) as to keep the switching between read and write modes as low as possible. Regards, Fred. From vances@REDACTED Thu Apr 11 07:47:42 2013 From: vances@REDACTED (Vance Shipley) Date: Thu, 11 Apr 2013 11:17:42 +0530 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130410125109.GA24064@ferdair.local> References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> <20130403125325.GD338@aluminium.local> <20130410120812.GB99642@aluminium.local> <20130410125109.GA24064@ferdair.local> Message-ID: <20130411054741.GC99642@aluminium.local> On Wed, Apr 10, 2013 at 08:51:11AM -0400, Fred Hebert wrote: } Have you considered using ETS counters, and possibly a monitor process? ... } If you're in the kind of position where you need to limit the number of } transactions to avoid falling over, it will *not* reduce the number of } messages sent to the supervisor, and if you start going over the top, } you'll time out no matter what, just because the supervisor won't be } able to keep up with the demand. Fred, Your approach is quite valid however it addresses an issue I am not as yet considering. I am concerned not about overload protection but in policy enforcement. The supervisor should have no more than N workers. The correct place to address that issue is in the supervisor. True, I could address it otherwise but I propose a small change to support this in the OTP implementation. The alternative solution which my coworkers have historically used is long lived pools of processes. I believe that the Erlang way is to have a process with a life cycle matching the transaction's. It makes me much happier to eliminate the pools. -- -Vance From bgustavsson@REDACTED Thu Apr 11 12:36:48 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 11 Apr 2013 12:36:48 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: Good work on making the optimization compatible. To make this patch independent of the compiler patches, may I suggest that you remove wait_file_reply/1 and rewrite file_request/2 like this: file_request(Io, Request) -> Ref = erlang:monitor(process, Io), Io ! {file_request,self(),Ref,Request}, receive {file_reply,Ref,Reply} -> erlang:demonitor(Ref, [flush]), Reply; {'DOWN', Ref, _, _, _} -> {error, terminated} end. On Wed, Apr 10, 2013 at 12:29 AM, Anthony Ramine wrote: > Hello Bj?rn, > > I found a way to make it backwards compatible with the old protocol right > now. > > The file module communicates with a file io server with the following > protocol for file operations: > > > {file_request,From,ReplyAs,Request} > < {file_reply,ReplyAs,Reply} > > The ReplyAs value is sent by the client side to match against when > receiving the reply and is otherwise left untouched and passed as is by the > server. > > The amended commit changes the protocol to: > > > {file_request,From,MonitorRef,Request} > < {file_reply,MonitorRef,Reply} > > As the shape of the messages is not changed, backwards compatibility is > not a concern. > > Unfortunately, the following patch fails to compile because of a bug in > the optimization pass. I've submitted two other patches; the first fixes > beam_receive by teaching it how to track a set of registers instead of a > single one, making it able to cope with the Core Erlang code generated by > the inliner, the second improves sys_core_fold and makes it simplifies what > is outputted by said inliner. > > Please refetch. > > Regards, > > -- > Anthony Ramine > > Le 9 avr. 2013 ? 12:12, Bj?rn Gustavsson a ?crit : > > > The patch looks fine and it would be a good thing to do. > > > > Unfortunately, there is the pesky question of backward > > compatibility. > > > > Someone can open a file on an R15 system, send the > > file descriptor (=a pid) to an R16B01 system with your > > patch and the R16B01 system will attempt to do file > > operations on the file. > > > > The backward compatible way to do this is to first introduce > > a file_io_server module that can handle both the new > > and the old messages. Two releases later the file module > > can be changed to use the new message format. > > > > Strictly speaking, two releases forward means R19 > > to allow the original R16B release to communicate > > with an R18 release. > > > > /Bjorn > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Apr 11 13:16:19 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 11 Apr 2013 13:16:19 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: Fine with me but I hope that doesn't mean the two other patches will be ignored :p I've amended the commit, please refetch. Regards, -- Anthony Ramine Le 11 avr. 2013 ? 12:36, Bj?rn Gustavsson a ?crit : > Good work on making the optimization compatible. > > To make this patch independent of the compiler > patches, may I suggest that you remove wait_file_reply/1 > and rewrite file_request/2 like this: > > file_request(Io, Request) -> > Ref = erlang:monitor(process, Io), > Io ! {file_request,self(),Ref,Request}, > receive > {file_reply,Ref,Reply} -> > erlang:demonitor(Ref, [flush]), > Reply; > {'DOWN', Ref, _, _, _} -> > {error, terminated} > end. > > > > On Wed, Apr 10, 2013 at 12:29 AM, Anthony Ramine wrote: > Hello Bj?rn, > > I found a way to make it backwards compatible with the old protocol right now. > > The file module communicates with a file io server with the following protocol for file operations: > > > {file_request,From,ReplyAs,Request} > < {file_reply,ReplyAs,Reply} > > The ReplyAs value is sent by the client side to match against when receiving the reply and is otherwise left untouched and passed as is by the server. > > The amended commit changes the protocol to: > > > {file_request,From,MonitorRef,Request} > < {file_reply,MonitorRef,Reply} > > As the shape of the messages is not changed, backwards compatibility is not a concern. > > Unfortunately, the following patch fails to compile because of a bug in the optimization pass. I've submitted two other patches; the first fixes beam_receive by teaching it how to track a set of registers instead of a single one, making it able to cope with the Core Erlang code generated by the inliner, the second improves sys_core_fold and makes it simplifies what is outputted by said inliner. > > Please refetch. > > Regards, > > -- > Anthony Ramine > > Le 9 avr. 2013 ? 12:12, Bj?rn Gustavsson a ?crit : > > > The patch looks fine and it would be a good thing to do. > > > > Unfortunately, there is the pesky question of backward > > compatibility. > > > > Someone can open a file on an R15 system, send the > > file descriptor (=a pid) to an R16B01 system with your > > patch and the R16B01 system will attempt to do file > > operations on the file. > > > > The backward compatible way to do this is to first introduce > > a file_io_server module that can handle both the new > > and the old messages. Two releases later the file module > > can be changed to use the new message format. > > > > Strictly speaking, two releases forward means R19 > > to allow the original R16B release to communicate > > with an R18 release. > > > > /Bjorn > > > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Thu Apr 11 14:20:05 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 11 Apr 2013 14:20:05 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: Looks good except that the comment needs to be updated too: diff --git a/lib/kernel/src/file.erl b/lib/kernel/src/file.erl index 7023340..3628905 100644 --- a/lib/kernel/src/file.erl +++ b/lib/kernel/src/file.erl @@ -1488,7 +1488,7 @@ check_args([]) -> ok. %%----------------------------------------------------------------- -%% Functions for communicating with a file io server. +%% Function for communicating with a file io server. %% The messages sent have the following formats: %% %% {file_request,From,ReplyAs,Request} Do you want us to amend the commit for you? We will start testing your patch in the daily builds. The compiler patches will not be ignored. On Thu, Apr 11, 2013 at 1:16 PM, Anthony Ramine wrote: > Fine with me but I hope that doesn't mean the two other patches will be > ignored :p > > I've amended the commit, please refetch. > > Regards, > > -- > Anthony Ramine > > Le 11 avr. 2013 ? 12:36, Bj?rn Gustavsson a ?crit : > > > Good work on making the optimization compatible. > > > > To make this patch independent of the compiler > > patches, may I suggest that you remove wait_file_reply/1 > > and rewrite file_request/2 like this: > > > > file_request(Io, Request) -> > > Ref = erlang:monitor(process, Io), > > Io ! {file_request,self(),Ref,Request}, > > receive > > {file_reply,Ref,Reply} -> > > erlang:demonitor(Ref, [flush]), > > Reply; > > {'DOWN', Ref, _, _, _} -> > > {error, terminated} > > end. > > > > > > > > On Wed, Apr 10, 2013 at 12:29 AM, Anthony Ramine > wrote: > > Hello Bj?rn, > > > > I found a way to make it backwards compatible with the old protocol > right now. > > > > The file module communicates with a file io server with the following > protocol for file operations: > > > > > {file_request,From,ReplyAs,Request} > > < {file_reply,ReplyAs,Reply} > > > > The ReplyAs value is sent by the client side to match against when > receiving the reply and is otherwise left untouched and passed as is by the > server. > > > > The amended commit changes the protocol to: > > > > > {file_request,From,MonitorRef,Request} > > < {file_reply,MonitorRef,Reply} > > > > As the shape of the messages is not changed, backwards compatibility is > not a concern. > > > > Unfortunately, the following patch fails to compile because of a bug in > the optimization pass. I've submitted two other patches; the first fixes > beam_receive by teaching it how to track a set of registers instead of a > single one, making it able to cope with the Core Erlang code generated by > the inliner, the second improves sys_core_fold and makes it simplifies what > is outputted by said inliner. > > > > Please refetch. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 9 avr. 2013 ? 12:12, Bj?rn Gustavsson a ?crit : > > > > > The patch looks fine and it would be a good thing to do. > > > > > > Unfortunately, there is the pesky question of backward > > > compatibility. > > > > > > Someone can open a file on an R15 system, send the > > > file descriptor (=a pid) to an R16B01 system with your > > > patch and the R16B01 system will attempt to do file > > > operations on the file. > > > > > > The backward compatible way to do this is to first introduce > > > a file_io_server module that can handle both the new > > > and the old messages. Two releases later the file module > > > can be changed to use the new message format. > > > > > > Strictly speaking, two releases forward means R19 > > > to allow the original R16B release to communicate > > > with an R18 release. > > > > > > /Bjorn > > > > > > > > > > -- > > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Apr 11 14:29:20 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 11 Apr 2013 14:29:20 +0200 Subject: [erlang-patches] Optimize communication with file io server In-Reply-To: References: <71C840D4-62A1-4E7D-B61A-13D73D3C7055@gmail.com> Message-ID: <2DEC0E3E-2E92-4301-9E5E-5191DE853B8D@gmail.com> Amended again! Please refetch. -- Anthony Ramine Le 11 avr. 2013 ? 14:20, Bj?rn Gustavsson a ?crit : > Looks good except that the comment needs to > be updated too: > > diff --git a/lib/kernel/src/file.erl b/lib/kernel/src/file.erl > index 7023340..3628905 100644 > --- a/lib/kernel/src/file.erl > +++ b/lib/kernel/src/file.erl > @@ -1488,7 +1488,7 @@ check_args([]) -> > ok. > > %%----------------------------------------------------------------- > -%% Functions for communicating with a file io server. > +%% Function for communicating with a file io server. > %% The messages sent have the following formats: > %% > %% {file_request,From,ReplyAs,Request} From bgustavsson@REDACTED Thu Apr 11 16:01:31 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 11 Apr 2013 16:01:31 +0200 Subject: [erlang-patches] [erlang-bugs] Use a set to store ref registers in beam_receive In-Reply-To: References: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> Message-ID: On Wed, Apr 10, 2013 at 12:22 PM, Anthony Ramine wrote: > Hello Bj?rn, > > I'm not sure I understand what you mean, should I add my example function > into receive_SUITE.erl as is to test that? I'm not sure that would > demonstrate anything in the long term as my other cooking patch > move-let-into-seq makes the culprit code where a reference is live in two Y > registers disappear. > > OK. I realize that it is hard or impossible to construct a test case that would test something that is not already tested by existing test cases. Your patch correctly fixes the bug, but I have some comments and suggestions for further simplification: The name of the RefReg variable is now misleading, since it contains a register set. (Suggested new name: RefRegSet, RefRegs, or RefSet.) The comment for opt_ref_used/4 needs to be updated. In opt_recv/5, my original code looked like: case regs_to_list(R) of [{y,_}=RefReg] -> ... The matching of {y,_} is just a cheap assertion (only added because it was almost free). Since your new code sends the register set to the opt_ref_used/4, there is no longer any need to convert the register set to a list. Thus we can write: case regs_empty(R) of false -> ... and remove the regs_to_list/1 function. Finally, for clarity I would add parenthesis in is_ref_msg_comparison/3: is_ref_msg_comparison([R1,R2], RefReg, Regs) -> (regs_is_member(R2, RefReg) andalso regs_is_member(R1, Regs)) orelse (regs_is_member(R1, RefReg) andalso regs_is_member(R2, Regs)). -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Apr 11 16:49:35 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 11 Apr 2013 16:49:35 +0200 Subject: [erlang-patches] Move let expressions into sequences In-Reply-To: <53915A78-30EF-40B5-832A-C2D754FB56B5@gmail.com> References: <53915A78-30EF-40B5-832A-C2D754FB56B5@gmail.com> Message-ID: Looks good, but since it is an optimization we will merge it to master (after testing it in our daily builds a few days). On Tue, Apr 9, 2013 at 11:40 PM, Anthony Ramine wrote: > Hello, > > The Core Erlang compiler simplifies let expressions by moving them into > their argument when it is another let or a case expression. It can then > perform other optimizations such as removing the let expressions > altogether, sometimes saving BEAM registers later in the process. > > This patch teaches sys_core_fold how to move let expressions into sequence > arguments. > > git fetch https://github.com/nox/otp.git move-let-into-seq > > > https://github.com/nox/otp/compare/erlang:maint...move-let-into-seq > > https://github.com/nox/otp/compare/erlang:maint...move-let-into-seq.patch > > For the record, I managed to encounter this while working on the file > optimization in branch file-receive-optim. You can find a short file > showing seq in let in the following gist: > > https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-core-L14 > https://gist.github.com/nox/2e33fe9a85e035caadda#file-t-erl > > Regards, > > -- > Anthony Ramine > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Thu Apr 11 17:12:37 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 11 Apr 2013 17:12:37 +0200 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 9:27 PM, Aliaksey Kandratsenka < alkondratenko@REDACTED> wrote: > > I've updated patch to use erlang:now instead of os:timestamp. > > Thanks! We have now reviewed the code and have found a minor potential issue. The thing is that if two timers are set to the same value, they are now guaranteed to expire in the same order that they were set. That is because erlang:now/0 returns unique values. (See timer_timeout/1.) With your patch, timers set to the same timeout within the same millisecond will have identical target times. Since the key in the ets table (at least for one shot timers) is tuple with the second element a reference, the ordering of the refs will determine which key that erts:first/1 will return if the target times are identical. In the current implementation, it *happens* to be true that if only and if Ref1 < Ref2, then Ref1 was created before Ref2. But that property is not guaranteed by the language definition and it may be changed in a future release (e.g. to reduce contention of the lock that is taken when refs are created). Therefore, I suggest fixing the bug by keeping the original system_time/0 function and round up when dividing by 1000. (The easiest way to round up is to add 999 before dividing by 1000.) -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From alkondratenko@REDACTED Thu Apr 11 19:32:04 2013 From: alkondratenko@REDACTED (Aliaksey Kandratsenka) Date: Thu, 11 Apr 2013 10:32:04 -0700 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 8:12 AM, Bj?rn Gustavsson wrote: > On Tue, Apr 9, 2013 at 9:27 PM, Aliaksey Kandratsenka < > alkondratenko@REDACTED> wrote: > >> >> I've updated patch to use erlang:now instead of os:timestamp. >> >> > Thanks! We have now reviewed the code and have > found a minor potential issue. > > The thing is that if two timers are set to the same > value, they are now guaranteed to expire in the same > order that they were set. That is because erlang:now/0 > returns unique values. (See timer_timeout/1.) > > With your patch, timers set to the same timeout > within the same millisecond will have identical > target times. Since the key in the ets table > (at least for one shot timers) is tuple with the > second element a reference, the ordering of the > refs will determine which key that erts:first/1 will > return if the target times are identical. > > In the current implementation, it *happens* to > be true that if only and if Ref1 < Ref2, then > Ref1 was created before Ref2. But that property > is not guaranteed by the language definition and it > may be changed in a future release (e.g. to reduce > contention of the lock that is taken when refs are > created). > > Therefore, I suggest fixing the bug by keeping > the original system_time/0 function and > round up when dividing by 1000. (The easiest > way to round up is to add 999 before dividing > by 1000.) > That makes sense. Thanks for thorough review. I've updated patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Thu Apr 11 20:05:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 11 Apr 2013 20:05:53 +0200 Subject: [erlang-patches] [erlang-bugs] Use a set to store ref registers in beam_receive In-Reply-To: References: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> Message-ID: <8FB19F99-1CA0-429A-A2A6-CDBA51BB7191@gmail.com> I added a test and clarified the code following your suggestions. I noticed that RefReg wasn't a descriptive enough name but I am ashamed to admit I optimized for diff shortness, sorry. Regards, -- Anthony Ramine Le 11 avr. 2013 ? 16:01, Bj?rn Gustavsson a ?crit : > On Wed, Apr 10, 2013 at 12:22 PM, Anthony Ramine wrote: > Hello Bj?rn, > > I'm not sure I understand what you mean, should I add my example function into receive_SUITE.erl as is to test that? I'm not sure that would demonstrate anything in the long term as my other cooking patch move-let-into-seq makes the culprit code where a reference is live in two Y registers disappear. > > > OK. I realize that it is hard or impossible to > construct a test case that would test something > that is not already tested by existing test cases. > > Your patch correctly fixes the bug, but I > have some comments and suggestions > for further simplification: > > The name of the RefReg variable is now > misleading, since it contains a register set. > (Suggested new name: RefRegSet, RefRegs, > or RefSet.) > > The comment for opt_ref_used/4 needs to > be updated. > > In opt_recv/5, my original code looked like: > > case regs_to_list(R) of > [{y,_}=RefReg] -> ... > > The matching of {y,_} is just a cheap > assertion (only added because it was > almost free). > > Since your new code sends the register > set to the opt_ref_used/4, there is no > longer any need to convert the register > set to a list. Thus we can write: > > case regs_empty(R) of > false -> ... > > and remove the regs_to_list/1 function. > > Finally, for clarity I would add parenthesis > in is_ref_msg_comparison/3: > > is_ref_msg_comparison([R1,R2], RefReg, Regs) -> > (regs_is_member(R2, RefReg) andalso regs_is_member(R1, Regs)) orelse > (regs_is_member(R1, RefReg) andalso regs_is_member(R2, Regs)). > > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Fri Apr 12 07:20:55 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 12 Apr 2013 07:20:55 +0200 Subject: [erlang-patches] [erlang-bugs] Use a set to store ref registers in beam_receive In-Reply-To: <8FB19F99-1CA0-429A-A2A6-CDBA51BB7191@gmail.com> References: <312DC303-E319-48DA-A035-AEFCE3976B7D@gmail.com> <8FB19F99-1CA0-429A-A2A6-CDBA51BB7191@gmail.com> Message-ID: Looks good! Good work on the test case. We will test for a few days in our daily builds before merging it to maint. On Thu, Apr 11, 2013 at 8:05 PM, Anthony Ramine wrote: > I added a test and clarified the code following your suggestions. > > I noticed that RefReg wasn't a descriptive enough name but I am ashamed to > admit I optimized for diff shortness, sorry. > > Regards, > > -- > Anthony Ramine > > Le 11 avr. 2013 ? 16:01, Bj?rn Gustavsson a ?crit : > > > On Wed, Apr 10, 2013 at 12:22 PM, Anthony Ramine > wrote: > > Hello Bj?rn, > > > > I'm not sure I understand what you mean, should I add my example > function into receive_SUITE.erl as is to test that? I'm not sure that would > demonstrate anything in the long term as my other cooking patch > move-let-into-seq makes the culprit code where a reference is live in two Y > registers disappear. > > > > > > OK. I realize that it is hard or impossible to > > construct a test case that would test something > > that is not already tested by existing test cases. > > > > Your patch correctly fixes the bug, but I > > have some comments and suggestions > > for further simplification: > > > > The name of the RefReg variable is now > > misleading, since it contains a register set. > > (Suggested new name: RefRegSet, RefRegs, > > or RefSet.) > > > > The comment for opt_ref_used/4 needs to > > be updated. > > > > In opt_recv/5, my original code looked like: > > > > case regs_to_list(R) of > > [{y,_}=RefReg] -> ... > > > > The matching of {y,_} is just a cheap > > assertion (only added because it was > > almost free). > > > > Since your new code sends the register > > set to the opt_ref_used/4, there is no > > longer any need to convert the register > > set to a list. Thus we can write: > > > > case regs_empty(R) of > > false -> ... > > > > and remove the regs_to_list/1 function. > > > > Finally, for clarity I would add parenthesis > > in is_ref_msg_comparison/3: > > > > is_ref_msg_comparison([R1,R2], RefReg, Regs) -> > > (regs_is_member(R2, RefReg) andalso regs_is_member(R1, Regs)) orelse > > (regs_is_member(R1, RefReg) andalso regs_is_member(R2, Regs)). > > > > > > -- > > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Fri Apr 12 07:22:58 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 12 Apr 2013 07:22:58 +0200 Subject: [erlang-patches] [patch] fix excessive CPU consumption of timer_server In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 7:32 PM, Aliaksey Kandratsenka < alkondratenko@REDACTED> wrote: > > That makes sense. Thanks for thorough review. > > I've updated patch. > > Thanks! We will run your patch in our daily builds for a few days before merging it. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Fri Apr 12 10:55:09 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Fri, 12 Apr 2013 10:55:09 +0200 (CEST) Subject: [erlang-patches] [patch] fix srp_anon suite in maint/master In-Reply-To: <1172091492.171697.1365756531010.JavaMail.root@tpip.net> Message-ID: <1208666772.173232.1365756909646.JavaMail.root@tpip.net> Hi, Pavel Slechta found a problem with the srp_anon suites, without a certificate they would always fail. The actuall fix is a one-liner and I also changed the test suites to catch the problem. Tree is based on maint, but should apply to master as well. git fetch git://github.com/RoadRunnr/otp.git fix-srp-psk-anon https://github.com/RoadRunnr/otp/compare/maint...fix-srp-psk-anon https://github.com/RoadRunnr/otp/compare/maint...fix-srp-psk-anon.patch Andreas -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------ managed broadband access ------------------ Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: HRB21276 Handelsregistergericht Chemnitz Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From n.oxyde@REDACTED Fri Apr 12 13:01:38 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 12 Apr 2013 13:01:38 +0200 Subject: [erlang-patches] [erlang-bugs] R16 breaks dots In-Reply-To: <3F6CD158-AF0E-4F16-AB72-4DFE84118C0B@gmail.com> References: <20130329203406.GB1251@zushakon> <13603AE6-E8E6-4EAD-899F-35D9CD7D2187@gmail.com> <51576CF7.6010905@gmail.com> <3E8948CA-EBD7-48EC-A9B8-6CEB8FF9C96F@gmail.com> <3F6CD158-AF0E-4F16-AB72-4DFE84118C0B@gmail.com> Message-ID: <0664E7BF-C7C1-4F3C-8E2F-64945D1F18C2@gmail.com> Ping? -- Anthony Ramine Le 4 avr. 2013 ? 15:45, Anthony Ramine a ?crit : > Hello Bj?rn, > > Could we have more details about why the Technical Board decided that? > > Regards, > > Le 4 avr. 2013 ? 15:38, Bj?rn Gustavsson a ?crit : > >> Rejected. >> >> The Technical Board did discuss the matter of dots in atoms and >> decided that the support should be removed along with packages. >> >> /Bjorn From erlangsiri@REDACTED Fri Apr 12 18:53:07 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 12 Apr 2013 18:53:07 +0200 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130411054741.GC99642@aluminium.local> References: <20130403121637.GB338@aluminium.local> <20130403122904.GA82915@ferdair.local> <20130403125325.GD338@aluminium.local> <20130410120812.GB99642@aluminium.local> <20130410125109.GA24064@ferdair.local> <20130411054741.GC99642@aluminium.local> Message-ID: Hi Vance, sorry for the delayed answer. We have had some discussions within our team and we do find your idea interesting. We do, however, not really like the idea of setting the limit in the call to supervisor:start_child, but rather think it should be possible to set such a property on the supervisor or in the child spec. The drawback of this, as you say in an earlier mail, is that it would require changing the supervisor spec - and that is a much bigger change. We do, however, plan to make the supervisor API a bit more flexible and by that adding the possibility of introducing new properties. The timeframe for this is not yet set, and a contribution would of course help speeding things up :) We already got a patch a good year ago ( http://erlang.org/pipermail/erlang-patches/2012-January/002574.html) but it was never completed... /siri 2013/4/11 Vance Shipley > On Wed, Apr 10, 2013 at 08:51:11AM -0400, Fred Hebert wrote: > } Have you considered using ETS counters, and possibly a monitor process? > ... > } If you're in the kind of position where you need to limit the number of > } transactions to avoid falling over, it will *not* reduce the number of > } messages sent to the supervisor, and if you start going over the top, > } you'll time out no matter what, just because the supervisor won't be > } able to keep up with the demand. > > Fred, > > Your approach is quite valid however it addresses an issue I am not as > yet considering. I am concerned not about overload protection but in > policy enforcement. The supervisor should have no more than N workers. > The correct place to address that issue is in the supervisor. True, I > could address it otherwise but I propose a small change to support this > in the OTP implementation. > > The alternative solution which my coworkers have historically used is > long lived pools of processes. I believe that the Erlang way is to have > a process with a life cycle matching the transaction's. It makes me much > happier to eliminate the pools. > > -- > -Vance > -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Fri Apr 12 21:31:30 2013 From: freza@REDACTED (Jachym Holecek) Date: Fri, 12 Apr 2013 15:31:30 -0400 Subject: [erlang-patches] Add supervisor:start_child/3 to limit the number of children In-Reply-To: <20130403121637.GB338@aluminium.local> References: <20130403121637.GB338@aluminium.local> Message-ID: <20130412193130.GA9824@circlewave.net> # Vance Shipley 2013-04-03: > git fetch git://github.com/vances/otp.git supervisor_child_limit > > https://github.com/vances/otp/commit/04f94f86e5495f29b61654d7f744ae3eeaca9297 > > With the addition of a Limit argument in start_child/3 the supervisor > will either start a child or return {error,child_limit}. > > A supervisor behaviour process may have dynamically added children > started by other processes. The count of the number of children > could be retrieved from the process with count_children/1 before > starting another with start_child/2 if a maximum number of children > is to be maintained. This introduces an overhead of a round trip > message and the possibility of a race condition. > > This is quite useful where a fixed size pool of processes might > otherwise be used and is suitable for cases where child workers are > started with high frequency. This is very easy to do with a custom gen_server, literarily a few lines of code, for the common case that the "child spec" is known in advance and fixed, and worker processes are relatively short-lived. Simulatenously it gives you a convenient place for some management logic, often handy. I imagine this (the above constraints) might be your case? Can isolate a minimal example if desired. To be clear: by "a few lines of code" I'm referring to a version that does spawn rate limiting, fault rate limiting and concurrency control. For cases that need to do more involved regulation a gen_fsm works better, but the general approach is the same. Just wondering if it's worth further increasing supervisor(3) complexity. BTW The same argument and concern also applies to simple_one_for_one, or at least to its prevalent use cases. But that's already in. BTW For cases where child processes are spawned at high frequencies I find it counterproductive to use supervisors -- SASL log gets flooded with what in practice tends to be pure noise, obscuring any important going ons. One more small argument for tailor-made solution. BR, -- Jachym From nmarino@REDACTED Fri Apr 12 22:34:34 2013 From: nmarino@REDACTED (Nick Marino) Date: Fri, 12 Apr 2013 16:34:34 -0400 Subject: [erlang-patches] Speed up index creation for Mnesia set tables Message-ID: <51686FDA.9010205@shoretel.com> Hello, I've developed a small, simple patch against the mnesia_index code that can greatly speed up index creation under certain circumstances. Specifically, this improves index creation on columns with a lot of duplicate values in Mnesia tables of type 'set'. Because Mnesia currently uses ETS bag tables to store its indexes, the insert performance drops drastically when you have lots of duplicate values in an indexed column, since for bag tables ETS has to check to make sure it's not inserting any duplicate elements. However, for Mnesia set tables we can use duplicate_bag tables instead: it will never insert any duplicate values into the index anyway, since every insert into an index is preceded by an explicit call to del_ixes for any entries in the index that it's replacing (for reference, take a look at the add_index2 function in the mnesia_index module). For bag tables, or for cases without lots of duplicate values in an indexed column, this change won't make any appreciable difference. But in a real world test for an application that hits this particular situation, I've seen Mnesia startup times jump from 30+ minutes to 15 seconds, so it can provide some major improvements in the right scenario. The one downside I've found is that deletion of indexes can be slightly slower, since ETS will no longer short-circuit out of ets:match_delete when it finds a match while iterating over the list of values for a specific key. But, this is only a small, linear slowdown compared to the large, super linear speedup we get on index creation; and as with the speedup, it only kicks in when you have lots of duplicate values in an indexed column, so this seems like an obvious net win. It might be possible to extend this optimization to Mnesia bag tables, but we'd need to make some additional changes to ensure we don't insert duplicate values into the index. It's not clear to me whether that would be doable without degrading performance in other less predictable ways. Anyway, the changeset can be found here: git fetch git://github.com/nickelization/otp.git mnesia_idx_insert_speedup https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup.patch This is my first ever contribution to Erlang/OTP, so I tried to follow the patch submission guidelines carefully, but please let me know if I've done anything incorrectly, or if you need anything else :-) Thanks, Nick This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From fredrik@REDACTED Mon Apr 15 09:52:28 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 15 Apr 2013 09:52:28 +0200 Subject: [erlang-patches] Speed up index creation for Mnesia set tables In-Reply-To: <51686FDA.9010205@shoretel.com> References: <51686FDA.9010205@shoretel.com> Message-ID: <516BB1BC.6010401@erlang.org> On 04/12/2013 10:34 PM, Nick Marino wrote: > Hello, > > I've developed a small, simple patch against the mnesia_index code that > can greatly speed up index creation under certain circumstances. > Specifically, this improves index creation on columns with a lot of > duplicate values in Mnesia tables of type 'set'. > > Because Mnesia currently uses ETS bag tables to store its indexes, the > insert performance drops drastically when you have lots of duplicate > values in an indexed column, since for bag tables ETS has to check to > make sure it's not inserting any duplicate elements. However, for Mnesia > set tables we can use duplicate_bag tables instead: it will never insert > any duplicate values into the index anyway, since every insert into an > index is preceded by an explicit call to del_ixes for any entries in the > index that it's replacing (for reference, take a look at the add_index2 > function in the mnesia_index module). > > For bag tables, or for cases without lots of duplicate values in an > indexed column, this change won't make any appreciable difference. But > in a real world test for an application that hits this particular > situation, I've seen Mnesia startup times jump from 30+ minutes to 15 > seconds, so it can provide some major improvements in the right > scenario. The one downside I've found is that deletion of indexes can be > slightly slower, since ETS will no longer short-circuit out of > ets:match_delete when it finds a match while iterating over the list of > values for a specific key. But, this is only a small, linear slowdown > compared to the large, super linear speedup we get on index creation; > and as with the speedup, it only kicks in when you have lots of > duplicate values in an indexed column, so this seems like an obvious net > win. > > It might be possible to extend this optimization to Mnesia bag tables, > but we'd need to make some additional changes to ensure we don't insert > duplicate values into the index. It's not clear to me whether that would > be doable without degrading performance in other less predictable ways. > > Anyway, the changeset can be found here: > > git fetch git://github.com/nickelization/otp.git > mnesia_idx_insert_speedup > > https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup > > https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup.patch > > > This is my first ever contribution to Erlang/OTP, so I tried to follow > the patch submission guidelines carefully, but please let me know if > I've done anything incorrectly, or if you need anything else :-) > > Thanks, > Nick > > This e-mail and any attachments are confidential. If it is not > intended for you, please notify the sender, and please erase and > ignore the contents. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Nick, Thanks for your contribution, a review process has started. -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Mon Apr 15 10:04:56 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 15 Apr 2013 10:04:56 +0200 Subject: [erlang-patches] Fix a bug in some binary comprehensions In-Reply-To: References: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> <515013FE.70903@erlang.org> <02ACE89B-1AF0-4A46-8B31-E1497838C71F@gmail.com> Message-ID: Ping? -- Anthony Ramine Le 28 mars 2013 ? 11:36, Anthony Ramine a ?crit : > Hello Bj?rn, > > I amended my patch with the modifications you suggested; please refetch. > > Regards, > > -- > Anthony Ramine > > Le 27 mars 2013 ? 15:43, Bj?rn Gustavsson a ?crit : > >> Thanks for the patch! >> >> I have reviewed your patch and have a few comments: >> >> The following line: >> >> Vs = [V||{_,#c_var{name=V}}<-Vars0] >> >> should be written with spaces around || and <-: >> >> Vs = [V || {_,#c_var{name=V}} <- Vars0] >> >> to match the style in the rest of the compiler. >> >> >> The following is a matter of taste, but I would >> prefer to avoid giving mul_pairs() an extra argument >> just so that it can build it into the return tuple >> (and otherwise unused). >> >> Thus, I would prefer bc_elem_size() to end like this: >> >> {E,Pre,St} = bc_mul_pairs(F, #c_literal{val=Bits}, [], St0), >> {E,Pre,Vs,St}. >> >> to avoid making bc_mul_pairs() harder to read. >> >> >> There are no test cases. Could you please add >> a test case (making sure that both of the new throw(impossible) >> in bc_verify_non_filtering/1 are covered)? >> >> bc_bincomp_SUITE.erl should be a good place. >> (Remember, new test cases should not have any ?line >> macros addes.) >> >> /Bjorn >> >> >> >> >> On Wed, Mar 27, 2013 at 10:09 AM, Anthony Ramine wrote: >> Hello, >> >> I amended my second commit and to make +clint0 run the Core Erlang linting pass just before any optimisation pass. >> >> Please refetch. >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 25 mars 2013 ? 10:08, Fredrik a ?crit : >> >>> On 03/24/2013 06:50 PM, Anthony Ramine wrote: >>>> git fetch https://github.com/nox/otp.git fix-bc-optim >>> Fetched and currently in the 'pu' branch. >>> Thanks, >>> >>> -- >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> >> >> -- >> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > From fredrik@REDACTED Mon Apr 15 10:09:32 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 15 Apr 2013 10:09:32 +0200 Subject: [erlang-patches] Fix a bug in some binary comprehensions In-Reply-To: References: <93249178-4D54-4D52-BEE9-057E13326244@gmail.com> <515013FE.70903@erlang.org> <02ACE89B-1AF0-4A46-8B31-E1497838C71F@gmail.com> Message-ID: <516BB5BC.2010805@erlang.org> On 04/15/2013 10:04 AM, Anthony Ramine wrote: > Ping? > Graduated! -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Tue Apr 16 12:38:44 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 16 Apr 2013 12:38:44 +0200 Subject: [erlang-patches] Bit string generators, unsized binaries, modules and the REPL In-Reply-To: References: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> Message-ID: <8F53233D-010C-499F-A4C9-073F5E9A37D1@gmail.com> Ping? -- Anthony Ramine Le 4 avr. 2013 ? 15:46, Bj?rn Gustavsson a ?crit : > Not really. I noticed that the implementation was flaky and > fixed it. > > The Technical Board will discuss the matter. From tomi@REDACTED Thu Apr 18 14:20:57 2013 From: tomi@REDACTED (=?utf-8?B?VG9tw6HFoSBKYW5vdcWhZWs=?=) Date: Thu, 18 Apr 2013 14:20:57 +0200 Subject: [erlang-patches] erl_pp: fix printing of invalid forms Message-ID: <20130418122057.GA20220@nomi.cz> Hello, git fetch git://github.com/liskin/otp.git erl_pp_options https://github.com/liskin/otp/compare/erl_pp_options https://github.com/liskin/otp/compare/erl_pp_options.patch Regards, -- Tom?? Janou?ek, a.k.a. Liskni_si, http://work.lisk.in/ From fredrik@REDACTED Thu Apr 18 14:24:23 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 18 Apr 2013 14:24:23 +0200 Subject: [erlang-patches] erl_pp: fix printing of invalid forms In-Reply-To: <20130418122057.GA20220@nomi.cz> References: <20130418122057.GA20220@nomi.cz> Message-ID: <516FE5F7.2070500@erlang.org> On 04/18/2013 02:20 PM, Tom?? Janou?ek wrote: > Hello, > > git fetch git://github.com/liskin/otp.git erl_pp_options > > https://github.com/liskin/otp/compare/erl_pp_options > https://github.com/liskin/otp/compare/erl_pp_options.patch > > Regards, Hello Tomas, I'll fetch the patch and run it in the 'pu' branch, and a review process will start. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Thu Apr 18 14:27:06 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 18 Apr 2013 14:27:06 +0200 Subject: [erlang-patches] Speed up index creation for Mnesia set tables In-Reply-To: <51686FDA.9010205@shoretel.com> References: <51686FDA.9010205@shoretel.com> Message-ID: <516FE69A.6040806@erlang.org> On 04/12/2013 10:34 PM, Nick Marino wrote: > Hello, > > I've developed a small, simple patch against the mnesia_index code that > can greatly speed up index creation under certain circumstances. > Specifically, this improves index creation on columns with a lot of > duplicate values in Mnesia tables of type 'set'. > > Because Mnesia currently uses ETS bag tables to store its indexes, the > insert performance drops drastically when you have lots of duplicate > values in an indexed column, since for bag tables ETS has to check to > make sure it's not inserting any duplicate elements. However, for Mnesia > set tables we can use duplicate_bag tables instead: it will never insert > any duplicate values into the index anyway, since every insert into an > index is preceded by an explicit call to del_ixes for any entries in the > index that it's replacing (for reference, take a look at the add_index2 > function in the mnesia_index module). > > For bag tables, or for cases without lots of duplicate values in an > indexed column, this change won't make any appreciable difference. But > in a real world test for an application that hits this particular > situation, I've seen Mnesia startup times jump from 30+ minutes to 15 > seconds, so it can provide some major improvements in the right > scenario. The one downside I've found is that deletion of indexes can be > slightly slower, since ETS will no longer short-circuit out of > ets:match_delete when it finds a match while iterating over the list of > values for a specific key. But, this is only a small, linear slowdown > compared to the large, super linear speedup we get on index creation; > and as with the speedup, it only kicks in when you have lots of > duplicate values in an indexed column, so this seems like an obvious net > win. > > It might be possible to extend this optimization to Mnesia bag tables, > but we'd need to make some additional changes to ensure we don't insert > duplicate values into the index. It's not clear to me whether that would > be doable without degrading performance in other less predictable ways. > > Anyway, the changeset can be found here: > > git fetch git://github.com/nickelization/otp.git > mnesia_idx_insert_speedup > > https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup > > https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup.patch > > > This is my first ever contribution to Erlang/OTP, so I tried to follow > the patch submission guidelines carefully, but please let me know if > I've done anything incorrectly, or if you need anything else :-) > > Thanks, > Nick > > This e-mail and any attachments are confidential. If it is not > intended for you, please notify the sender, and please erase and > ignore the contents. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello, Your patch seems to fail suite: mnesia_evil_coverage and testcase: sorted_ets. Please run the suite and fix the problem. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Fri Apr 19 14:33:28 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 19 Apr 2013 14:33:28 +0200 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <510659DB.3060800@erlang.org> References: <51044F0A.6070902@gmail.com> <51064C32.3030309@erlang.org> <51065297.3060300@gmail.com> <510659DB.3060800@erlang.org> Message-ID: <51713998.4020609@erlang.org> On 01/28/2013 11:58 AM, Fredrik wrote: > On 01/28/2013 11:27 AM, Richard Carlsson wrote: >> Done, please refetch. >> >> /Richard >> >> On 2013-01-28 11:00 , Fredrik wrote: >>> On 01/26/2013 10:47 PM, Richard Carlsson wrote: >>>> (New attempt with this branch, freshly rebased on master.) >>>> >>>> Several people have requested that the assert macros in eunit >>>> should be >>>> moved out to a separate header file. The following branch puts them in >>>> stdlib/include/assert.hrl: >>>> >>>> git fetch git://github.com/richcarl/otp.git break-out-asserts >>>> >>>> I added a test, but there is no documentation: I don't know quite >>>> where >>>> to put that, since it's just a header file and no module. However, >>>> they >>>> are described in the EUnit documentation. >>>> >>>> /Richard >>> Hello, >>> Your patch fails to build: >>> >>> stdlib_test ../stdlib_test/stdlib_SUITE.erl:140: can't find include lib >>> "stdlib/include/assert.hrl" >>> ../stdlib_test/stdlib_SUITE.erl:141: can't find include lib >>> "stdlib/include/assert.hrl" >>> ../stdlib_test/stdlib_SUITE.erl:147: undefined macro 'assert/1' >>> ../stdlib_test/stdlib_SUITE.erl:36: function assert_test/1 undefined >>> >>> >>> We distinguished that the hrl file needs to be included in >>> lib/stdlib/src/Makefile >>> >>> Could you fix this? >>> > Refetched, > Thanks. > Hello Richard, I've got some feedback on your patch: *We need documentation regarding this in the STDLIB ref. man. *More tests, the ones that are there right now is only testing that any of the macro's crashes. ( and also, we need testing of fault scenarios, does these getting catched as they should?) -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Fri Apr 19 14:55:26 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 19 Apr 2013 14:55:26 +0200 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <51713998.4020609@erlang.org> References: <51044F0A.6070902@gmail.com> <51064C32.3030309@erlang.org> <51065297.3060300@gmail.com> <510659DB.3060800@erlang.org> <51713998.4020609@erlang.org> Message-ID: <51713EBE.4070801@erlang.org> On 04/19/2013 02:33 PM, Fredrik wrote: > On 01/28/2013 11:58 AM, Fredrik wrote: >> On 01/28/2013 11:27 AM, Richard Carlsson wrote: >>> Done, please refetch. >>> >>> /Richard >>> >>> On 2013-01-28 11:00 , Fredrik wrote: >>>> On 01/26/2013 10:47 PM, Richard Carlsson wrote: >>>>> (New attempt with this branch, freshly rebased on master.) >>>>> >>>>> Several people have requested that the assert macros in eunit >>>>> should be >>>>> moved out to a separate header file. The following branch puts >>>>> them in >>>>> stdlib/include/assert.hrl: >>>>> >>>>> git fetch git://github.com/richcarl/otp.git break-out-asserts >>>>> >>>>> I added a test, but there is no documentation: I don't know quite >>>>> where >>>>> to put that, since it's just a header file and no module. However, >>>>> they >>>>> are described in the EUnit documentation. >>>>> >>>>> /Richard >>>> Hello, >>>> Your patch fails to build: >>>> >>>> stdlib_test ../stdlib_test/stdlib_SUITE.erl:140: can't find include >>>> lib >>>> "stdlib/include/assert.hrl" >>>> ../stdlib_test/stdlib_SUITE.erl:141: can't find include lib >>>> "stdlib/include/assert.hrl" >>>> ../stdlib_test/stdlib_SUITE.erl:147: undefined macro 'assert/1' >>>> ../stdlib_test/stdlib_SUITE.erl:36: function assert_test/1 undefined >>>> >>>> >>>> We distinguished that the hrl file needs to be included in >>>> lib/stdlib/src/Makefile >>>> >>>> Could you fix this? >>>> >> Refetched, >> Thanks. >> > Hello Richard, > I've got some feedback on your patch: > *We need documentation regarding this in the STDLIB ref. man. > *More tests, the ones that are there right now is only testing that > any of the macro's crashes. ( and also, we need testing of fault > scenarios, does these getting catched as they should?) > Okey, That came out wrong, You'll need to create a new man page and the tests that exists right now is only successful tests, we need expect-to-fail tests also. -- BR Fredrik Gustafsson Erlang OTP Team From carlsson.richard@REDACTED Sat Apr 20 22:24:31 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sat, 20 Apr 2013 22:24:31 +0200 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <51713998.4020609@erlang.org> References: <51044F0A.6070902@gmail.com> <51064C32.3030309@erlang.org> <51065297.3060300@gmail.com> <510659DB.3060800@erlang.org> <51713998.4020609@erlang.org> Message-ID: <5172F97F.2070000@gmail.com> On 2013-04-19 14:33 , Fredrik wrote: > On 01/28/2013 11:58 AM, Fredrik wrote: > Hello Richard, > I've got some feedback on your patch: > *We need documentation regarding this in the STDLIB ref. man. Please advice in which documentation file I should put the text. /Richard From klaus_trainer@REDACTED Sun Apr 21 20:19:13 2013 From: klaus_trainer@REDACTED (Klaus Trainer) Date: Sun, 21 Apr 2013 20:19:13 +0200 Subject: [erlang-patches] crypto: Fix typo in documentation Message-ID: <1366568353.25138.88.camel@devil> Hi. This is my first Erlang patch! It's a simple typo correction in the documentation for crypto:srp_compute_key/6,7,8. git fetch https://github.com/KlausTrainer/otp.git fix-crypto-doc-typo https://github.com/KlausTrainer/otp/compare/erlang:maint...fix-crypto-doc-typo https://github.com/KlausTrainer/otp/compare/erlang:maint...fix-crypto-doc-typo.patch Regards, Klaus From n.oxyde@REDACTED Sun Apr 21 22:15:28 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 21 Apr 2013 22:15:28 +0200 Subject: [erlang-patches] Scan "=<<" as something useful Message-ID: Hello, I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, b} is rather written as {a,b}. Then there is the occasional Bin= <<42>> with a space because erl_scan will scans "=<<" as '=<','<' instead of '=','<<'. This patch teaches erl_scan how to not do that. There is no backwards compatibility problem as '=<','<' can't appear in valid code. git fetch https://github.com/nox/otp.git disambiguate-equal-binary https://github.com/nox/otp/compare/disambiguate-equal-binary https://github.com/nox/otp/compare/disambiguate-equal-binary.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Sun Apr 21 22:17:22 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 21 Apr 2013 22:17:22 +0200 Subject: [erlang-patches] EEP37: Funs with names In-Reply-To: <5149C8AE.8030509@erlang.org> References: <50A4FAA9.1070706@erlang.org> <466D4B3A-8B3C-4AA7-9A2B-B85EA5EA2A90@gmail.com> <819C7547-3B43-4F8E-A4E0-91B77C547600@gmail.com> <514981E0.9030209@erlang.org> <806DFCE7-CC09-46F9-8B71-F97CE9E04A39@gmail.com> <5149C8AE.8030509@erlang.org> Message-ID: Hello, Any ETA for a review? Regards, On Wed, Mar 20, 2013 at 3:33 PM, Fredrik wrote: > On 03/20/2013 03:30 PM, Anthony Ramine wrote: >> >> Rebased! :) >> >> Does it mean it may be included before R17? Branch maint is for minor >> releases, right? >> > Right now im collecting all the patches active at the moment in pu. That > does not mean it will be included in a minor release. :) > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From vinoski@REDACTED Mon Apr 22 02:23:40 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Sun, 21 Apr 2013 20:23:40 -0400 Subject: [erlang-patches] fix valgrind error in erts/emulator/drivers/unix/ttsl_drv.c Message-ID: On Linux I noticed the following complaint while doing some valgrind testing: ==18040== Thread 6: ==18040== Source and destination overlap in memcpy(0xf3f3f04, 0xf3f3f08, 52) ==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18040== by 0x5CF527: del_chars (ttsl_drv.c:845) ==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658) ==18040== by 0x4982E3: erts_write_to_port (io.c:1235) ==18040== by 0x49A2BD: erts_port_command (io.c:2223) ==18040== by 0x48C054: do_send (bif.c:1962) ==18040== by 0x48CB6E: erl_send (bif.c:2162) ==18040== by 0x566599: process_main (beam_emu.c:1665) ==18040== by 0x4B1A95: sched_thread_func (erl_process.c:4834) ==18040== by 0x6075E2: thr_wrapper (ethread.c:106) ==18040== by 0x5560E99: start_thread (pthread_create.c:308) This patch fixes the problem. git fetch git://github.com/vinoski/otp.git sv-ttsl-valgrind https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind.patch --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Mon Apr 22 06:21:57 2013 From: sean@REDACTED (Sean Cribbs) Date: Mon, 22 Apr 2013 07:21:57 +0300 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: Message-ID: I can't count how many times this has bitten me, kudos. On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine wrote: > Hello, > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > b} is rather written as {a,b}. Then there is the occasional Bin= > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > instead of '=','<<'. This patch teaches erl_scan how to not do that. > > There is no backwards compatibility problem as '=<','<' can't appear > in valid code. > > git fetch https://github.com/nox/otp.git disambiguate-equal-binary > > https://github.com/nox/otp/compare/disambiguate-equal-binary > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > Regards, > > -- > Anthony Ramine > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Apr 22 09:32:46 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 22 Apr 2013 09:32:46 +0200 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <5172F97F.2070000@gmail.com> References: <51044F0A.6070902@gmail.com> <51064C32.3030309@erlang.org> <51065297.3060300@gmail.com> <510659DB.3060800@erlang.org> <51713998.4020609@erlang.org> <5172F97F.2070000@gmail.com> Message-ID: <5174E79E.4070803@erlang.org> Hello Richard! Please create a new reference doc file for the assert macros in stdlib. A suitable template for the file would be the shell_default ref man[1]. Don't forget to add the new file to ref_man.xml[2]. Lukas [1]: https://github.com/erlang/otp/blob/maint/lib/stdlib/doc/src/shell_default.xml [2]: https://github.com/erlang/otp/blob/maint/lib/stdlib/doc/src/ref_man.xml On 20/04/13 22:24, Richard Carlsson wrote: > On 2013-04-19 14:33 , Fredrik wrote: >> On 01/28/2013 11:58 AM, Fredrik wrote: >> Hello Richard, >> I've got some feedback on your patch: >> *We need documentation regarding this in the STDLIB ref. man. > > Please advice in which documentation file I should put the text. > > /Richard > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From lukas@REDACTED Mon Apr 22 10:01:48 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 22 Apr 2013 10:01:48 +0200 Subject: [erlang-patches] crypto: Fix typo in documentation In-Reply-To: <1366568353.25138.88.camel@devil> References: <1366568353.25138.88.camel@devil> Message-ID: <5174EE6C.6050406@erlang.org> Hello, Thanks for the patch. It will be included in R16B01. Lukas On 21/04/13 20:19, Klaus Trainer wrote: > Hi. This is my first Erlang patch! It's a simple typo correction in the > documentation for crypto:srp_compute_key/6,7,8. > > git fetch https://github.com/KlausTrainer/otp.git fix-crypto-doc-typo > > https://github.com/KlausTrainer/otp/compare/erlang:maint...fix-crypto-doc-typo > https://github.com/KlausTrainer/otp/compare/erlang:maint...fix-crypto-doc-typo.patch > > Regards, > Klaus > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From lukas@REDACTED Mon Apr 22 10:45:18 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 22 Apr 2013 10:45:18 +0200 Subject: [erlang-patches] fix valgrind error in erts/emulator/drivers/unix/ttsl_drv.c In-Reply-To: References: Message-ID: <5174F89E.10901@erlang.org> Hello Steve! Thanks for the patch. I had to use ctrl-H in the middle of a term in the terminal to trigger the report, was this the case for you as well? Lukas On 22/04/13 02:23, Steve Vinoski wrote: > On Linux I noticed the following complaint while doing some valgrind > testing: > > ==18040== Thread 6: > ==18040== Source and destination overlap in memcpy(0xf3f3f04, > 0xf3f3f08, 52) > ==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==18040== by 0x5CF527: del_chars (ttsl_drv.c:845) > ==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658) > ==18040== by 0x4982E3: erts_write_to_port (io.c:1235) > ==18040== by 0x49A2BD: erts_port_command (io.c:2223) > ==18040== by 0x48C054: do_send (bif.c:1962) > ==18040== by 0x48CB6E: erl_send (bif.c:2162) > ==18040== by 0x566599: process_main (beam_emu.c:1665) > ==18040== by 0x4B1A95: sched_thread_func (erl_process.c:4834) > ==18040== by 0x6075E2: thr_wrapper (ethread.c:106) > ==18040== by 0x5560E99: start_thread (pthread_create.c:308) > > This patch fixes the problem. > > git fetch git://github.com/vinoski/otp.git > sv-ttsl-valgrind > > https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind > https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind.patch > > --steve > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Mon Apr 22 10:53:03 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 22 Apr 2013 10:53:03 +0200 Subject: [erlang-patches] fix valgrind error in erts/emulator/drivers/unix/ttsl_drv.c In-Reply-To: <5174F89E.10901@erlang.org> References: <5174F89E.10901@erlang.org> Message-ID: <5174FA6F.4060509@erix.ericsson.se> The other call to memcpy in the same function del_chars() seems to have the same problem. Probably possible to trigger with ctrl-D. /Sverker Lukas Larsson wrote: > Hello Steve! > > Thanks for the patch. > > I had to use ctrl-H in the middle of a term in the terminal to trigger > the report, was this the case for you as well? > > Lukas > > On 22/04/13 02:23, Steve Vinoski wrote: >> On Linux I noticed the following complaint while doing some valgrind >> testing: >> >> ==18040== Thread 6: >> ==18040== Source and destination overlap in memcpy(0xf3f3f04, >> 0xf3f3f08, 52) >> ==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in >> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==18040== by 0x5CF527: del_chars (ttsl_drv.c:845) >> ==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658) >> ==18040== by 0x4982E3: erts_write_to_port (io.c:1235) >> ==18040== by 0x49A2BD: erts_port_command (io.c:2223) >> ==18040== by 0x48C054: do_send (bif.c:1962) >> ==18040== by 0x48CB6E: erl_send (bif.c:2162) >> ==18040== by 0x566599: process_main (beam_emu.c:1665) >> ==18040== by 0x4B1A95: sched_thread_func (erl_process.c:4834) >> ==18040== by 0x6075E2: thr_wrapper (ethread.c:106) >> ==18040== by 0x5560E99: start_thread (pthread_create.c:308) >> >> This patch fixes the problem. >> >> git fetch git://github.com/vinoski/otp.git >> sv-ttsl-valgrind >> >> https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind >> https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind.patch >> >> >> --steve >> >> >> _______________________________________________ >> 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 vinoski@REDACTED Mon Apr 22 13:15:10 2013 From: vinoski@REDACTED (Steve Vinoski) Date: Mon, 22 Apr 2013 07:15:10 -0400 Subject: [erlang-patches] fix valgrind error in erts/emulator/drivers/unix/ttsl_drv.c In-Reply-To: <5174FA6F.4060509@erix.ericsson.se> References: <5174F89E.10901@erlang.org> <5174FA6F.4060509@erix.ericsson.se> Message-ID: Hi Lukas and Sverker, No, I wasn't hitting ctrl-H. I was just running some eunit tests (with [verbose]) in a shell and when the tests finished and the shell went to print the next prompt, valgrind reported this error. One of my Basho colleagues, though, says he has seen errors that seem related to this when hitting ctrl-D after a sequence of cursor movements on the shell command line, but I was never able to reproduce that. Perhaps he was hitting the problem Sverker refers to. If you want me to change the patch to fix the other memcpy, just let me know. --steve On Mon, Apr 22, 2013 at 4:53 AM, Sverker Eriksson < sverker.eriksson@REDACTED> wrote: > The other call to memcpy in the same function del_chars() seems to have > the same problem. > Probably possible to trigger with ctrl-D. > > /Sverker > > Lukas Larsson wrote: > >> Hello Steve! >> >> Thanks for the patch. >> >> I had to use ctrl-H in the middle of a term in the terminal to trigger >> the report, was this the case for you as well? >> >> Lukas >> >> On 22/04/13 02:23, Steve Vinoski wrote: >> >>> On Linux I noticed the following complaint while doing some valgrind >>> testing: >>> >>> ==18040== Thread 6: >>> ==18040== Source and destination overlap in memcpy(0xf3f3f04, 0xf3f3f08, >>> 52) >>> ==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in >>> /usr/lib/valgrind/vgpreload_**memcheck-amd64-linux.so) >>> ==18040== by 0x5CF527: del_chars (ttsl_drv.c:845) >>> ==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658) >>> ==18040== by 0x4982E3: erts_write_to_port (io.c:1235) >>> ==18040== by 0x49A2BD: erts_port_command (io.c:2223) >>> ==18040== by 0x48C054: do_send (bif.c:1962) >>> ==18040== by 0x48CB6E: erl_send (bif.c:2162) >>> ==18040== by 0x566599: process_main (beam_emu.c:1665) >>> ==18040== by 0x4B1A95: sched_thread_func (erl_process.c:4834) >>> ==18040== by 0x6075E2: thr_wrapper (ethread.c:106) >>> ==18040== by 0x5560E99: start_thread (pthread_create.c:308) >>> >>> This patch fixes the problem. >>> >>> git fetch git://github.com/vinoski/otp.**git< >>> http://github.com/vinoski/**otp.git > >>> sv-ttsl-valgrind >>> >>> >>> https://github.com/vinoski/**otp/compare/erlang:maint...sv-** >>> ttsl-valgrind >>> https://github.com/vinoski/**otp/compare/erlang:maint...sv-** >>> ttsl-valgrind.patch >>> >>> --steve >>> >>> >>> ______________________________**_________________ >>> 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 >> >> > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Apr 22 13:38:22 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 22 Apr 2013 13:38:22 +0200 Subject: [erlang-patches] Print column numbers when compiling In-Reply-To: References: <4FCE3186.3000202@erlang.org> <5034FB10.7090804@erlang.org> <503CC79B.2020009@erlang.org> <50471240.3060005@erlang.org> <504DF309.2040900@erlang.org> <415229C2-452E-45FF-A207-69BD2212E2F5@gmail.com> <50519F42.7000109@erlang.org> <50598C38.8060506@erlang.org> <77306113-0789-4B6F-A45D-8304FFED5C39@gmail.com> <513DE767.90700@erlang.org> Message-ID: <9EB6A04F-AB90-480F-B2FB-E1A8B7CBCC1F@gmail.com> Ping? -- Anthony Ramine Le 18 mars 2013 ? 14:07, Anthony Ramine a ?crit : > Hi, > > Just rebased against latest maint. > > Please refetch. > > -- > Anthony Ramine > > Le 11 mars 2013 ? 15:17, Fredrik a ?crit : > >> On 12/02/2012 11:07 AM, Anthony Ramine wrote: >>> Hi, >>> >>> I've made column numbers a non-optional thing in compile but still an >>> option in epp; so that tools like edoc which don't need the full >>> locations can get only the line numbers. >>> >>> Please refetch. >>> >>> -- >>> Anthony Ramine >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> Hello, >> Could you please rebase this patch upon the current 'maint' branch? >> Thanks. >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> > From Alexey.Saltanov@REDACTED Mon Apr 22 13:43:09 2013 From: Alexey.Saltanov@REDACTED (Saltanov, Alexey) Date: Mon, 22 Apr 2013 11:43:09 +0000 Subject: [erlang-patches] Fix odbc in non-standart location error (--with-odbc). Message-ID: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F73@SRV-EXCHMBX2.billing.ru> When I build OTP with "-with-odbc" flag odbc configure script fails. Script fails when it checking for odbc in standart locations because my server has one ODBC in the standart location and another one in the user HOME directory, and I build OTP with ODBC in the user HOME. Here is my fix. git fetch git://github.com/saltos/otp.git odbc_in_non_standard_location https://github.com/saltos/otp/compare/erlang:maint...odbc_in_non_standard_location https://github.com/saltos/otp/compare/erlang:maint...odbc_in_non_standard_location.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexey.Saltanov@REDACTED Mon Apr 22 13:43:10 2013 From: Alexey.Saltanov@REDACTED (Saltanov, Alexey) Date: Mon, 22 Apr 2013 11:43:10 +0000 Subject: [erlang-patches] Fix reltool copy_file "not owner" error. Message-ID: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F7A@SRV-EXCHMBX2.billing.ru> When I build rebar release (rebar generate) in the user HOME directory on the NFS (network file system) I always get an error: ==> rel (generate) ERROR: Failed to generate target from spec: "write file info /nfs/home/user/src/rel/sep_rpr/erts-5.9.3.1/bin/erlexec: not owner" ERROR: Unexpected error: rebar_abort ERROR: generate failed while processing /nfs/home/user/src/rel: rebar_abort make: *** [rel] Error 1 I found that the write_file_info() with "FromInfo" does owner the file "rel/sep_rpr/erts-5.9.3.1/bin/erlexec" as root and setting file mode fails with error "not owner". Here is my fix. git fetch git://github.com/saltos/otp.git reltool_copy_file_not_owner_fix https://github.com/saltos/otp/compare/erlang:maint...reltool_copy_file_not_owner_fix https://github.com/saltos/otp/compare/erlang:maint...reltool_copy_file_not_owner_fix.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Mon Apr 22 15:29:48 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 22 Apr 2013 15:29:48 +0200 Subject: [erlang-patches] Bit string generators, unsized binaries, modules and the REPL In-Reply-To: <8F53233D-010C-499F-A4C9-073F5E9A37D1@gmail.com> References: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> <8F53233D-010C-499F-A4C9-073F5E9A37D1@gmail.com> Message-ID: On Tue, Apr 16, 2013 at 12:38 PM, Anthony Ramine wrote: > Ping? > > pong. (R17) It still remains to review the patch in the usual way. Have you looked in erl_eval and eval_bits to see whether any code there can be simplified or removed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Mon Apr 22 15:40:00 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 22 Apr 2013 15:40:00 +0200 Subject: [erlang-patches] Bit string generators, unsized binaries, modules and the REPL In-Reply-To: References: <649B6ECF-85AD-40BB-9CB1-C04DC348C499@gmail.com> <8F53233D-010C-499F-A4C9-073F5E9A37D1@gmail.com> Message-ID: Thanks for the reply. I've looked into both when I wrote the patch and didn't notice anything that could be simplified or removed. Regards, -- Anthony Ramine Le 22 avr. 2013 ? 15:29, Bj?rn Gustavsson a ?crit : > On Tue, Apr 16, 2013 at 12:38 PM, Anthony Ramine wrote: > Ping? > > > pong. (R17) > > It still remains to review the patch in the > usual way. > > Have you looked in erl_eval and eval_bits to > see whether any code there can be simplified or > removed? > From mc@REDACTED Mon Apr 22 17:06:24 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Mon, 22 Apr 2013 11:06:24 -0400 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: Message-ID: Good erlang wart to remove... +1 On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs wrote: > I can't count how many times this has bitten me, kudos. > > > On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine wrote: > >> Hello, >> >> I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, >> b} is rather written as {a,b}. Then there is the occasional Bin= >> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' >> instead of '=','<<'. This patch teaches erl_scan how to not do that. >> >> There is no backwards compatibility problem as '=<','<' can't appear >> in valid code. >> >> git fetch https://github.com/nox/otp.gitdisambiguate-equal-binary >> >> https://github.com/nox/otp/compare/disambiguate-equal-binary >> >> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch >> >> Regards, >> >> -- >> Anthony Ramine >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Apr 22 17:46:59 2013 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 22 Apr 2013 17:46:59 +0200 Subject: [erlang-patches] fix valgrind error in erts/emulator/drivers/unix/ttsl_drv.c In-Reply-To: References: <5174F89E.10901@erlang.org> <5174FA6F.4060509@erix.ericsson.se> Message-ID: <51755B73.50007@erlang.org> Hello, I added a commit with the other memcopy to your patch. It is now running in the nightly tests. Lukas On 22/04/13 13:15, Steve Vinoski wrote: > Hi Lukas and Sverker, > > No, I wasn't hitting ctrl-H. I was just running some eunit tests (with > [verbose]) in a shell and when the tests finished and the shell went > to print the next prompt, valgrind reported this error. > > One of my Basho colleagues, though, says he has seen errors that seem > related to this when hitting ctrl-D after a sequence of cursor > movements on the shell command line, but I was never able to reproduce > that. Perhaps he was hitting the problem Sverker refers to. > > If you want me to change the patch to fix the other memcpy, just let > me know. > > --steve > > > > On Mon, Apr 22, 2013 at 4:53 AM, Sverker Eriksson > > > wrote: > > The other call to memcpy in the same function del_chars() seems to > have the same problem. > Probably possible to trigger with ctrl-D. > > /Sverker > > Lukas Larsson wrote: > > Hello Steve! > > Thanks for the patch. > > I had to use ctrl-H in the middle of a term in the terminal to > trigger the report, was this the case for you as well? > > Lukas > > On 22/04/13 02:23, Steve Vinoski wrote: > > On Linux I noticed the following complaint while doing > some valgrind testing: > > ==18040== Thread 6: > ==18040== Source and destination overlap in > memcpy(0xf3f3f04, 0xf3f3f08, 52) > ==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==18040== by 0x5CF527: del_chars (ttsl_drv.c:845) > ==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658) > ==18040== by 0x4982E3: erts_write_to_port (io.c:1235) > ==18040== by 0x49A2BD: erts_port_command (io.c:2223) > ==18040== by 0x48C054: do_send (bif.c:1962) > ==18040== by 0x48CB6E: erl_send (bif.c:2162) > ==18040== by 0x566599: process_main (beam_emu.c:1665) > ==18040== by 0x4B1A95: sched_thread_func > (erl_process.c:4834) > ==18040== by 0x6075E2: thr_wrapper (ethread.c:106) > ==18040== by 0x5560E99: start_thread (pthread_create.c:308) > > This patch fixes the problem. > > git fetch git://github.com/vinoski/otp.git > > sv-ttsl-valgrind > > > https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind > https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind.patch > > > --steve > > > _______________________________________________ > 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 > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Wed Apr 24 14:35:31 2013 From: lukas@REDACTED (Lukas Larsson) Date: Wed, 24 Apr 2013 14:35:31 +0200 Subject: [erlang-patches] fix valgrind error in erts/emulator/drivers/unix/ttsl_drv.c In-Reply-To: <51755B73.50007@erlang.org> References: <5174F89E.10901@erlang.org> <5174FA6F.4060509@erix.ericsson.se> <51755B73.50007@erlang.org> Message-ID: <5177D193.9020703@erlang.org> Hello, I've just merged this into maint so it will be part of the R16B01 release. Lukas On 22/04/13 17:46, Lukas Larsson wrote: > Hello, > > I added a commit with the other memcopy to your patch. It is now > running in the nightly tests. > > Lukas > > On 22/04/13 13:15, Steve Vinoski wrote: >> Hi Lukas and Sverker, >> >> No, I wasn't hitting ctrl-H. I was just running some eunit tests >> (with [verbose]) in a shell and when the tests finished and the shell >> went to print the next prompt, valgrind reported this error. >> >> One of my Basho colleagues, though, says he has seen errors that seem >> related to this when hitting ctrl-D after a sequence of cursor >> movements on the shell command line, but I was never able to >> reproduce that. Perhaps he was hitting the problem Sverker refers to. >> >> If you want me to change the patch to fix the other memcpy, just let >> me know. >> >> --steve >> >> >> >> On Mon, Apr 22, 2013 at 4:53 AM, Sverker Eriksson >> > > wrote: >> >> The other call to memcpy in the same function del_chars() seems >> to have the same problem. >> Probably possible to trigger with ctrl-D. >> >> /Sverker >> >> Lukas Larsson wrote: >> >> Hello Steve! >> >> Thanks for the patch. >> >> I had to use ctrl-H in the middle of a term in the terminal >> to trigger the report, was this the case for you as well? >> >> Lukas >> >> On 22/04/13 02:23, Steve Vinoski wrote: >> >> On Linux I noticed the following complaint while doing >> some valgrind testing: >> >> ==18040== Thread 6: >> ==18040== Source and destination overlap in >> memcpy(0xf3f3f04, 0xf3f3f08, 52) >> ==18040== at 0x4C2CFA0: memcpy@@GLIBC_2.14 (in >> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) >> ==18040== by 0x5CF527: del_chars (ttsl_drv.c:845) >> ==18040== by 0x5CED5E: ttysl_from_erlang (ttsl_drv.c:658) >> ==18040== by 0x4982E3: erts_write_to_port (io.c:1235) >> ==18040== by 0x49A2BD: erts_port_command (io.c:2223) >> ==18040== by 0x48C054: do_send (bif.c:1962) >> ==18040== by 0x48CB6E: erl_send (bif.c:2162) >> ==18040== by 0x566599: process_main (beam_emu.c:1665) >> ==18040== by 0x4B1A95: sched_thread_func >> (erl_process.c:4834) >> ==18040== by 0x6075E2: thr_wrapper (ethread.c:106) >> ==18040== by 0x5560E99: start_thread >> (pthread_create.c:308) >> >> This patch fixes the problem. >> >> git fetch git://github.com/vinoski/otp.git >> >> sv-ttsl-valgrind >> >> >> https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind >> https://github.com/vinoski/otp/compare/erlang:maint...sv-ttsl-valgrind.patch >> >> >> --steve >> >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmarino@REDACTED Wed Apr 24 20:15:58 2013 From: nmarino@REDACTED (Nick Marino) Date: Wed, 24 Apr 2013 14:15:58 -0400 Subject: [erlang-patches] Speed up index creation for Mnesia set tables In-Reply-To: <516FE69A.6040806@erlang.org> References: <51686FDA.9010205@shoretel.com> <516FE69A.6040806@erlang.org> Message-ID: <5178215E.9070506@shoretel.com> Hi Fredrik, Thanks for your response. I looked into this, and it turned out I simply failed to add a case clause for Mnesia tables of type ordered_set. I had forgotten that ordered_set was a valid table type in Mnesia, and had only been testing my changes with set and bag tables. I've added a new commit to my GitHub repository to fix this, and the unit test you cited now runs fine. As before, you can view all my changes here: git fetch git://github.com/nickelization/otp.git mnesia_idx_insert_speedup https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup.patch Or, if you'd prefer to just view the new patch I added to address the problems with ordered_set tables, you can view it here: https://github.com/nickelization/otp/commit/fb8cbfa5db65f4bb9dcb133de9414c78aa49d9e7 https://github.com/nickelization/otp/commit/fb8cbfa5db65f4bb9dcb133de9414c78aa49d9e7.patch Thanks again, Nick On 04/18/2013 08:27 AM, Fredrik wrote: > On 04/12/2013 10:34 PM, Nick Marino wrote: >> Hello, >> >> I've developed a small, simple patch against the mnesia_index code that >> can greatly speed up index creation under certain circumstances. >> Specifically, this improves index creation on columns with a lot of >> duplicate values in Mnesia tables of type 'set'. >> >> Because Mnesia currently uses ETS bag tables to store its indexes, the >> insert performance drops drastically when you have lots of duplicate >> values in an indexed column, since for bag tables ETS has to check to >> make sure it's not inserting any duplicate elements. However, for Mnesia >> set tables we can use duplicate_bag tables instead: it will never insert >> any duplicate values into the index anyway, since every insert into an >> index is preceded by an explicit call to del_ixes for any entries in the >> index that it's replacing (for reference, take a look at the add_index2 >> function in the mnesia_index module). >> >> For bag tables, or for cases without lots of duplicate values in an >> indexed column, this change won't make any appreciable difference. But >> in a real world test for an application that hits this particular >> situation, I've seen Mnesia startup times jump from 30+ minutes to 15 >> seconds, so it can provide some major improvements in the right >> scenario. The one downside I've found is that deletion of indexes can be >> slightly slower, since ETS will no longer short-circuit out of >> ets:match_delete when it finds a match while iterating over the list of >> values for a specific key. But, this is only a small, linear slowdown >> compared to the large, super linear speedup we get on index creation; >> and as with the speedup, it only kicks in when you have lots of >> duplicate values in an indexed column, so this seems like an obvious net >> win. >> >> It might be possible to extend this optimization to Mnesia bag tables, >> but we'd need to make some additional changes to ensure we don't insert >> duplicate values into the index. It's not clear to me whether that would >> be doable without degrading performance in other less predictable ways. >> >> Anyway, the changeset can be found here: >> >> git fetch git://github.com/nickelization/otp.git >> mnesia_idx_insert_speedup >> >> https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup >> >> https://github.com/nickelization/otp/compare/erlang:maint...mnesia_idx_insert_speedup.patch >> >> >> This is my first ever contribution to Erlang/OTP, so I tried to follow >> the patch submission guidelines carefully, but please let me know if >> I've done anything incorrectly, or if you need anything else :-) >> >> Thanks, >> Nick >> >> This e-mail and any attachments are confidential. If it is not >> intended for you, please notify the sender, and please erase and >> ignore the contents. >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > Hello, > Your patch seems to fail suite: mnesia_evil_coverage and testcase: > sorted_ets. > Please run the suite and fix the problem. > This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. From hanssv@REDACTED Thu Apr 25 17:12:36 2013 From: hanssv@REDACTED (Hans Svensson) Date: Thu, 25 Apr 2013 17:12:36 +0200 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it Message-ID: <517947E4.2040504@gmail.com> Hi, Yesterday I implemented, for the umpteenth time, the init-function. (I guess being taught Haskell at one point could be blamed partly for the coding style requiring this function...) It is a trivial function that I think should be part of the standard lists module. This patch adds the function, tests in lists_SUITE, and documentation of the function. The implementation is trivial: reverse(tl(reverse(List))). If I've missed some religious reason for not having this function feel free to drop the patch ;-) Cheers, Hans git fetch git://github.com/hanssv/otp.git add_init_to_lists https://github.com/hanssv/otp/compare/erlang:maint...add_init_to_lists https://github.com/hanssv/otp/compare/erlang:maint...add_init_to_lists.patch From mononcqc@REDACTED Thu Apr 25 17:54:10 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 25 Apr 2013 11:54:10 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <517947E4.2040504@gmail.com> References: <517947E4.2040504@gmail.com> Message-ID: Sounds to me like it would have been better implemented as something like: init([_]) -> []; init([H|T]) -> [H|init(T)]. As this would avoid re-building the list twice, once on each reversal. Regards, Fred. On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: > Hi, > > Yesterday I implemented, for the umpteenth time, the init-function. (I > guess being taught Haskell at one point could be blamed partly for the > coding style requiring this function...) It is a trivial function that I > think should be part of the standard lists module. This patch adds the > function, tests in lists_SUITE, and documentation of the function. > > The implementation is trivial: reverse(tl(reverse(List))). > > If I've missed some religious reason for not having this function feel > free to drop the patch ;-) > > Cheers, > Hans > > git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists > > https://github.com/hanssv/otp/**compare/erlang:maint...add_**init_to_lists > https://github.com/hanssv/otp/**compare/erlang:maint...add_** > init_to_lists.patch > ______________________________**_________________ > 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 Thu Apr 25 17:57:48 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Thu, 25 Apr 2013 08:57:48 -0700 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> Message-ID: What about non-tail-recursiveness, though? On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert wrote: > Sounds to me like it would have been better implemented as something like: > > init([_]) -> []; > init([H|T]) -> [H|init(T)]. > > As this would avoid re-building the list twice, once on each reversal. > > Regards, > Fred. > > > On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: > >> Hi, >> >> Yesterday I implemented, for the umpteenth time, the init-function. (I >> guess being taught Haskell at one point could be blamed partly for the >> coding style requiring this function...) It is a trivial function that I >> think should be part of the standard lists module. This patch adds the >> function, tests in lists_SUITE, and documentation of the function. >> >> The implementation is trivial: reverse(tl(reverse(List))). >> >> If I've missed some religious reason for not having this function feel >> free to drop the patch ;-) >> >> Cheers, >> Hans >> >> git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists >> >> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >> init_to_lists >> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >> init_to_lists.patch >> ______________________________**_________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/**listinfo/erlang-patches >> > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From datacompboy@REDACTED Thu Apr 25 18:05:30 2013 From: datacompboy@REDACTED (Anton Fedorov) Date: Thu, 25 Apr 2013 23:05:30 +0700 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> Message-ID: <590c85dc4d7384e8044ff4cba1076cd7.squirrel@webmail.call2ru.com> Hmm... if add new functions into lists, think about this one too: %% -------------------------------------------- %% @spec lists_first(Pred,List) -> {Element, List} %% %% @doc Pick first element from List, for which Pred return true. %% @end --------------------------------------- lists_first(_Pred,[]) -> undefined; lists_first(Pred,[Element|Rest]) -> case Pred(Element) of true -> Element; _ -> lists_first(Pred, Rest) end. %% -------------------------------------------- %% @spec lists_nth(Pred,N,List) -> {Element, List} %% %% @doc Pick Nth element from List, for which Pred return true. %% @end --------------------------------------- lists_nth(_Pred,_N,[]) -> undefined; lists_nth(Pred,N,[Element|Rest]) -> case Pred(Element) of true -> case N of 0 -> Element; _ -> lists_nth(Pred, N-1, Rest) end; _ -> lists_nth(Pred, N, Rest) end. also have tired of copying in several projects. ? ?????? ?? ???, 25 ??? 2013, 22:54 Fred Hebert ?????: > Sounds to me like it would have been better implemented as something like: > > init([_]) -> []; > init([H|T]) -> [H|init(T)]. > > As this would avoid re-building the list twice, once on each reversal. > > Regards, > Fred. > > > On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: > >> Hi, >> >> Yesterday I implemented, for the umpteenth time, the init-function. (I >> guess being taught Haskell at one point could be blamed partly for the >> coding style requiring this function...) It is a trivial function that I >> think should be part of the standard lists module. This patch adds the >> function, tests in lists_SUITE, and documentation of the function. >> >> The implementation is trivial: reverse(tl(reverse(List))). >> >> If I've missed some religious reason for not having this function feel >> free to drop the patch ;-) >> >> Cheers, >> Hans >> >> git fetch >> git://github.com/hanssv/otp.**gitadd_init_to_lists >> >> https://github.com/hanssv/otp/**compare/erlang:maint...add_**init_to_lists >> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >> init_to_lists.patch >> ______________________________**_________________ >> 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 > -- Regards, Anton Fedorov Call2ru service E-Mail: datacompboy@REDACTED Jabber: datacompboy@REDACTED Skype: datacompboy ICQ: 272-35-262 Mobile: +7-913-925-7974 [SMS 24h, Call 05:00-19:00 MSKT (GMT+3)] From mononcqc@REDACTED Thu Apr 25 18:18:34 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Thu, 25 Apr 2013 12:18:34 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> Message-ID: <20130425161833.GA90528@ferdair.local> I don't think there's any benefit in tail-recursion when you're rebuilding an entirely new list. Given the limited number of arguments, the list you're creating by not being tail-recursive is in all points similar to the one you would have to maintain on the stack through tail recursions. Maybe a bit larger, but given you don't have to trash it, you're likely to avoid GC costs by doing it that way. See http://erlang.2086793.n4.nabble.com/Efficiency-of-a-list-construction-td3538122.html#a3538379 and http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html for more information. What I would worry about in my implementation is adding a clause of 'init([]) -> error(badarg)' to be consequent in failures with the rest of the lists module, and not get a 'function_clause' error there when someone passes in an empty list. On 04/25, Yurii Rashkovskii wrote: > What about non-tail-recursiveness, though? > > > On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert wrote: > > > Sounds to me like it would have been better implemented as something like: > > > > init([_]) -> []; > > init([H|T]) -> [H|init(T)]. > > > > As this would avoid re-building the list twice, once on each reversal. > > > > Regards, > > Fred. > > > > > > On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: > > > >> Hi, > >> > >> Yesterday I implemented, for the umpteenth time, the init-function. (I > >> guess being taught Haskell at one point could be blamed partly for the > >> coding style requiring this function...) It is a trivial function that I > >> think should be part of the standard lists module. This patch adds the > >> function, tests in lists_SUITE, and documentation of the function. > >> > >> The implementation is trivial: reverse(tl(reverse(List))). > >> > >> If I've missed some religious reason for not having this function feel > >> free to drop the patch ;-) > >> > >> Cheers, > >> Hans > >> > >> git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists > >> > >> https://github.com/hanssv/otp/**compare/erlang:maint...add_** > >> init_to_lists > >> https://github.com/hanssv/otp/**compare/erlang:maint...add_** > >> init_to_lists.patch > >> ______________________________**_________________ > >> 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 > > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From daniel@REDACTED Thu Apr 25 19:17:44 2013 From: daniel@REDACTED (Daniel Luna) Date: Thu, 25 Apr 2013 13:17:44 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <590c85dc4d7384e8044ff4cba1076cd7.squirrel@webmail.call2ru.com> References: <517947E4.2040504@gmail.com> <590c85dc4d7384e8044ff4cba1076cd7.squirrel@webmail.call2ru.com> Message-ID: lists_first can easily be implemented by using dropwhile and hd. Which is how I would use it if I would ever need it in a project. On Apr 25, 2013 12:05 PM, "Anton Fedorov" wrote: > Hmm... if add new functions into lists, think about this one too: > > %% -------------------------------------------- > %% @spec lists_first(Pred,List) -> {Element, List} > %% > %% @doc Pick first element from List, for which Pred return true. > %% @end --------------------------------------- > lists_first(_Pred,[]) -> > undefined; > lists_first(Pred,[Element|Rest]) -> > case Pred(Element) of > true -> Element; > _ -> lists_first(Pred, Rest) > end. > > %% -------------------------------------------- > %% @spec lists_nth(Pred,N,List) -> {Element, List} > %% > %% @doc Pick Nth element from List, for which Pred return true. > %% @end --------------------------------------- > lists_nth(_Pred,_N,[]) -> > undefined; > lists_nth(Pred,N,[Element|Rest]) -> > case Pred(Element) of > true -> case N of > 0 -> Element; > _ -> lists_nth(Pred, N-1, Rest) > end; > _ -> lists_nth(Pred, N, Rest) > end. > > also have tired of copying in several projects. > > ? ?????? ?? ???, 25 ??? 2013, 22:54 Fred Hebert ?????: > > Sounds to me like it would have been better implemented as something > like: > > > > init([_]) -> []; > > init([H|T]) -> [H|init(T)]. > > > > As this would avoid re-building the list twice, once on each reversal. > > > > Regards, > > Fred. > > > > > > On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson > wrote: > > > >> Hi, > >> > >> Yesterday I implemented, for the umpteenth time, the init-function. (I > >> guess being taught Haskell at one point could be blamed partly for the > >> coding style requiring this function...) It is a trivial function that I > >> think should be part of the standard lists module. This patch adds the > >> function, tests in lists_SUITE, and documentation of the function. > >> > >> The implementation is trivial: reverse(tl(reverse(List))). > >> > >> If I've missed some religious reason for not having this function feel > >> free to drop the patch ;-) > >> > >> Cheers, > >> Hans > >> > >> git fetch > >> git://github.com/hanssv/otp.**git >add_init_to_lists > >> > >> > https://github.com/hanssv/otp/**compare/erlang:maint...add_**init_to_lists > > >> https://github.com/hanssv/otp/**compare/erlang:maint...add_** > >> init_to_lists.patch< > https://github.com/hanssv/otp/compare/erlang:maint...add_init_to_lists.patch > > > >> ______________________________**_________________ > >> erlang-patches mailing list > >> erlang-patches@REDACTED > >> http://erlang.org/mailman/**listinfo/erlang-patches< > http://erlang.org/mailman/listinfo/erlang-patches> > >> > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > -- > Regards, > Anton Fedorov > Call2ru service > E-Mail: datacompboy@REDACTED > Jabber: datacompboy@REDACTED > Skype: datacompboy > ICQ: 272-35-262 > Mobile: +7-913-925-7974 [SMS 24h, Call 05:00-19:00 MSKT (GMT+3)] > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hanssv@REDACTED Fri Apr 26 11:33:16 2013 From: hanssv@REDACTED (Hans Svensson) Date: Fri, 26 Apr 2013 11:33:16 +0200 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <20130425161833.GA90528@ferdair.local> References: <517947E4.2040504@gmail.com> <20130425161833.GA90528@ferdair.local> Message-ID: <517A49DC.4080409@gmail.com> You are absolutely right about the 'badarg', it is better to have a consistent failure! However on performance, the suggested implementation is somewhat surprisingly the best option (I admit, I did measure before writing the patch ;-) ) For lists up to 3000 elements, it is on average ~x1.8 faster than a (tail-)recursive implementation! So a better version would probably be: init([]) -> error(badarg); init(List = [_ | _]) -> lists:reverse(tl(lists:reverse(List))); init(_) -> error(badarg). /Hans On 2013-04-25 18:18, Fred Hebert wrote: > I don't think there's any benefit in tail-recursion when you're > rebuilding an entirely new list. Given the limited number of arguments, > the list you're creating by not being tail-recursive is in all points > similar to the one you would have to maintain on the stack through tail > recursions. Maybe a bit larger, but given you don't have to trash it, > you're likely to avoid GC costs by doing it that way. > > See http://erlang.2086793.n4.nabble.com/Efficiency-of-a-list-construction-td3538122.html#a3538379 > and http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html > for more information. > > What I would worry about in my implementation is adding a clause > of 'init([]) -> error(badarg)' to be consequent in failures with the rest > of the lists module, and not get a 'function_clause' error there when > someone passes in an empty list. > > On 04/25, Yurii Rashkovskii wrote: >> What about non-tail-recursiveness, though? >> >> >> On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert wrote: >> >>> Sounds to me like it would have been better implemented as something like: >>> >>> init([_]) -> []; >>> init([H|T]) -> [H|init(T)]. >>> >>> As this would avoid re-building the list twice, once on each reversal. >>> >>> Regards, >>> Fred. >>> >>> >>> On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: >>> >>>> Hi, >>>> >>>> Yesterday I implemented, for the umpteenth time, the init-function. (I >>>> guess being taught Haskell at one point could be blamed partly for the >>>> coding style requiring this function...) It is a trivial function that I >>>> think should be part of the standard lists module. This patch adds the >>>> function, tests in lists_SUITE, and documentation of the function. >>>> >>>> The implementation is trivial: reverse(tl(reverse(List))). >>>> >>>> If I've missed some religious reason for not having this function feel >>>> free to drop the patch ;-) >>>> >>>> Cheers, >>>> Hans >>>> >>>> git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists >>>> >>>> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >>>> init_to_lists >>>> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >>>> init_to_lists.patch >>>> ______________________________**_________________ >>>> 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 >>> >>> >> _______________________________________________ >> 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 mononcqc@REDACTED Fri Apr 26 15:41:56 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 26 Apr 2013 09:41:56 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <517A49DC.4080409@gmail.com> References: <517947E4.2040504@gmail.com> <20130425161833.GA90528@ferdair.local> <517A49DC.4080409@gmail.com> Message-ID: <20130426134155.GA97541@ferdair.local> Ah yeah, the version that reverses twice is more likely to be fast due to the fact that lists:reverse/1 calls lists:reverse/2, which is now a NIF. Thus the traversal and building is gonna be made in C rather than in Erlang. Testing with a 'homemade' lists:reverse/2 tends to bring things back to the more expected N vs. 2N for traversals. Regards, Fred. On 04/26, Hans Svensson wrote: > You are absolutely right about the 'badarg', it is better to have a > consistent failure! > > However on performance, the suggested implementation is somewhat > surprisingly the best option (I admit, I did measure before writing > the patch ;-) ) For lists up to 3000 elements, it is on average > ~x1.8 faster than a (tail-)recursive implementation! > > So a better version would probably be: > init([]) -> error(badarg); > init(List = [_ | _]) -> > lists:reverse(tl(lists:reverse(List))); > init(_) -> error(badarg). > > /Hans > > On 2013-04-25 18:18, Fred Hebert wrote: > >I don't think there's any benefit in tail-recursion when you're > >rebuilding an entirely new list. Given the limited number of arguments, > >the list you're creating by not being tail-recursive is in all points > >similar to the one you would have to maintain on the stack through tail > >recursions. Maybe a bit larger, but given you don't have to trash it, > >you're likely to avoid GC costs by doing it that way. > > > >See http://erlang.2086793.n4.nabble.com/Efficiency-of-a-list-construction-td3538122.html#a3538379 > >and http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html > >for more information. > > > >What I would worry about in my implementation is adding a clause > >of 'init([]) -> error(badarg)' to be consequent in failures with the rest > >of the lists module, and not get a 'function_clause' error there when > >someone passes in an empty list. > > > >On 04/25, Yurii Rashkovskii wrote: > >>What about non-tail-recursiveness, though? > >> > >> > >>On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert wrote: > >> > >>>Sounds to me like it would have been better implemented as something like: > >>> > >>>init([_]) -> []; > >>>init([H|T]) -> [H|init(T)]. > >>> > >>>As this would avoid re-building the list twice, once on each reversal. > >>> > >>>Regards, > >>>Fred. > >>> > >>> > >>>On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: > >>> > >>>>Hi, > >>>> > >>>>Yesterday I implemented, for the umpteenth time, the init-function. (I > >>>>guess being taught Haskell at one point could be blamed partly for the > >>>>coding style requiring this function...) It is a trivial function that I > >>>>think should be part of the standard lists module. This patch adds the > >>>>function, tests in lists_SUITE, and documentation of the function. > >>>> > >>>>The implementation is trivial: reverse(tl(reverse(List))). > >>>> > >>>>If I've missed some religious reason for not having this function feel > >>>>free to drop the patch ;-) > >>>> > >>>>Cheers, > >>>>Hans > >>>> > >>>>git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists > >>>> > >>>>https://github.com/hanssv/otp/**compare/erlang:maint...add_** > >>>>init_to_lists > >>>>https://github.com/hanssv/otp/**compare/erlang:maint...add_** > >>>>init_to_lists.patch > >>>>______________________________**_________________ > >>>>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 > >>> > >>> > >>_______________________________________________ > >>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 serge@REDACTED Fri Apr 26 16:17:25 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 26 Apr 2013 10:17:25 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <20130426134155.GA97541@ferdair.local> References: <517947E4.2040504@gmail.com> <20130425161833.GA90528@ferdair.local> <517A49DC.4080409@gmail.com> <20130426134155.GA97541@ferdair.local> Message-ID: <517A8C75.1000105@aleynikov.org> The name of this function seems to be misleading though. Since init/1 usually refers to initialization of something (e.g. gen behaviors), perhaps a better choice of the name would be: drop_tail/1. On 4/26/2013 9:41 AM, Fred Hebert wrote: > Ah yeah, the version that reverses twice is more likely to be fast due > to the fact that lists:reverse/1 calls lists:reverse/2, which is now a > NIF. Thus the traversal and building is gonna be made in C rather than > in Erlang. Testing with a 'homemade' lists:reverse/2 tends to bring > things back to the more expected N vs. 2N for traversals. > > Regards, > Fred. > > On 04/26, Hans Svensson wrote: >> You are absolutely right about the 'badarg', it is better to have a >> consistent failure! >> >> However on performance, the suggested implementation is somewhat >> surprisingly the best option (I admit, I did measure before writing >> the patch ;-) ) For lists up to 3000 elements, it is on average >> ~x1.8 faster than a (tail-)recursive implementation! >> >> So a better version would probably be: >> init([]) -> error(badarg); >> init(List = [_ | _]) -> >> lists:reverse(tl(lists:reverse(List))); >> init(_) -> error(badarg). >> >> /Hans >> >> On 2013-04-25 18:18, Fred Hebert wrote: >>> I don't think there's any benefit in tail-recursion when you're >>> rebuilding an entirely new list. Given the limited number of arguments, >>> the list you're creating by not being tail-recursive is in all points >>> similar to the one you would have to maintain on the stack through tail >>> recursions. Maybe a bit larger, but given you don't have to trash it, >>> you're likely to avoid GC costs by doing it that way. >>> >>> See http://erlang.2086793.n4.nabble.com/Efficiency-of-a-list-construction-td3538122.html#a3538379 >>> and http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html >>> for more information. >>> >>> What I would worry about in my implementation is adding a clause >>> of 'init([]) -> error(badarg)' to be consequent in failures with the rest >>> of the lists module, and not get a 'function_clause' error there when >>> someone passes in an empty list. >>> >>> On 04/25, Yurii Rashkovskii wrote: >>>> What about non-tail-recursiveness, though? >>>> >>>> >>>> On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert wrote: >>>> >>>>> Sounds to me like it would have been better implemented as something like: >>>>> >>>>> init([_]) -> []; >>>>> init([H|T]) -> [H|init(T)]. >>>>> >>>>> As this would avoid re-building the list twice, once on each reversal. >>>>> >>>>> Regards, >>>>> Fred. >>>>> >>>>> >>>>> On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Yesterday I implemented, for the umpteenth time, the init-function. (I >>>>>> guess being taught Haskell at one point could be blamed partly for the >>>>>> coding style requiring this function...) It is a trivial function that I >>>>>> think should be part of the standard lists module. This patch adds the >>>>>> function, tests in lists_SUITE, and documentation of the function. >>>>>> >>>>>> The implementation is trivial: reverse(tl(reverse(List))). >>>>>> >>>>>> If I've missed some religious reason for not having this function feel >>>>>> free to drop the patch ;-) >>>>>> >>>>>> Cheers, >>>>>> Hans >>>>>> >>>>>> git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists >>>>>> >>>>>> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >>>>>> init_to_lists >>>>>> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >>>>>> init_to_lists.patch >>>>>> ______________________________**_________________ >>>>>> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From serge@REDACTED Fri Apr 26 17:46:27 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 26 Apr 2013 11:46:27 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <517A8C75.1000105@aleynikov.org> References: <517947E4.2040504@gmail.com> <20130425161833.GA90528@ferdair.local> <517A49DC.4080409@gmail.com> <20130426134155.GA97541@ferdair.local> <517A8C75.1000105@aleynikov.org> Message-ID: <517AA153.5020607@aleynikov.org> Apologies, the recommended name should be lists:drop_last/1 (rather than what I wrote in the email below). On 4/26/2013 10:17 AM, Serge Aleynikov wrote: > The name of this function seems to be misleading though. Since init/1 > usually refers to initialization of something (e.g. gen behaviors), > perhaps a better choice of the name would be: drop_tail/1. > > > On 4/26/2013 9:41 AM, Fred Hebert wrote: >> Ah yeah, the version that reverses twice is more likely to be fast due >> to the fact that lists:reverse/1 calls lists:reverse/2, which is now a >> NIF. Thus the traversal and building is gonna be made in C rather than >> in Erlang. Testing with a 'homemade' lists:reverse/2 tends to bring >> things back to the more expected N vs. 2N for traversals. >> >> Regards, >> Fred. >> >> On 04/26, Hans Svensson wrote: >>> You are absolutely right about the 'badarg', it is better to have a >>> consistent failure! >>> >>> However on performance, the suggested implementation is somewhat >>> surprisingly the best option (I admit, I did measure before writing >>> the patch ;-) ) For lists up to 3000 elements, it is on average >>> ~x1.8 faster than a (tail-)recursive implementation! >>> >>> So a better version would probably be: >>> init([]) -> error(badarg); >>> init(List = [_ | _]) -> >>> lists:reverse(tl(lists:reverse(List))); >>> init(_) -> error(badarg). >>> >>> /Hans >>> >>> On 2013-04-25 18:18, Fred Hebert wrote: >>>> I don't think there's any benefit in tail-recursion when you're >>>> rebuilding an entirely new list. Given the limited number of arguments, >>>> the list you're creating by not being tail-recursive is in all points >>>> similar to the one you would have to maintain on the stack through tail >>>> recursions. Maybe a bit larger, but given you don't have to trash it, >>>> you're likely to avoid GC costs by doing it that way. >>>> >>>> See http://erlang.2086793.n4.nabble.com/Efficiency-of-a-list-construction-td3538122.html#a3538379 >>>> and http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html >>>> for more information. >>>> >>>> What I would worry about in my implementation is adding a clause >>>> of 'init([]) -> error(badarg)' to be consequent in failures with the rest >>>> of the lists module, and not get a 'function_clause' error there when >>>> someone passes in an empty list. >>>> >>>> On 04/25, Yurii Rashkovskii wrote: >>>>> What about non-tail-recursiveness, though? >>>>> >>>>> >>>>> On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert wrote: >>>>> >>>>>> Sounds to me like it would have been better implemented as something like: >>>>>> >>>>>> init([_]) -> []; >>>>>> init([H|T]) -> [H|init(T)]. >>>>>> >>>>>> As this would avoid re-building the list twice, once on each reversal. >>>>>> >>>>>> Regards, >>>>>> Fred. >>>>>> >>>>>> >>>>>> On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yesterday I implemented, for the umpteenth time, the init-function. (I >>>>>>> guess being taught Haskell at one point could be blamed partly for the >>>>>>> coding style requiring this function...) It is a trivial function that I >>>>>>> think should be part of the standard lists module. This patch adds the >>>>>>> function, tests in lists_SUITE, and documentation of the function. >>>>>>> >>>>>>> The implementation is trivial: reverse(tl(reverse(List))). >>>>>>> >>>>>>> If I've missed some religious reason for not having this function feel >>>>>>> free to drop the patch ;-) >>>>>>> >>>>>>> Cheers, >>>>>>> Hans >>>>>>> >>>>>>> git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists >>>>>>> >>>>>>> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >>>>>>> init_to_lists >>>>>>> https://github.com/hanssv/otp/**compare/erlang:maint...add_** >>>>>>> init_to_lists.patch >>>>>>> ______________________________**_________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> From n.oxyde@REDACTED Sat Apr 27 13:23:16 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 27 Apr 2013 13:23:16 +0200 Subject: [erlang-patches] Fix an inconsistent state in epp Message-ID: Hello, When entering an included file, epp doesn't properly set #epp.name2 like it does on init, generating a malformed file attribute with file name "" when it leaves the file. git fetch https://github.com/nox/otp.git fix-epp-file-attrs https://github.com/nox/otp/compare/erlang:maint...fix-epp-file-attrs https://github.com/nox/otp/compare/erlang:maint...fix-epp-file-attrs.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Sat Apr 27 13:36:06 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 27 Apr 2013 13:36:06 +0200 Subject: [erlang-patches] Fix some Makefile rules that didn't support silent rules Message-ID: <255174D9-671F-40B4-8EBD-412A57C15FBD@gmail.com> Hello, This patch fixes some Makefile rules that didn't support silent rules. git fetch https://github.com/nox/otp.git fix-silent-rules https://github.com/nox/otp/compare/erlang:maint...fix-silent-rules https://github.com/nox/otp/compare/erlang:maint...fix-silent-rules.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Sat Apr 27 13:48:29 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 27 Apr 2013 13:48:29 +0200 Subject: [erlang-patches] Fix some compilation warnings Message-ID: Hello, This branch removes some compilation warnings I noticed while using silent rules. git fetch https://github.com/nox/otp.git fix-warnings https://github.com/nox/otp/compare/erlang:maint...fix-warnings https://github.com/nox/otp/compare/erlang:maint...fix-warnings.patch Regards, -- Anthony Ramine From n.oxyde@REDACTED Sat Apr 27 15:01:17 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 27 Apr 2013 15:01:17 +0200 Subject: [erlang-patches] [erlang-bugs] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> References: <51098739.8020308@ninenines.eu> <5118C033.5050301@erlang.org> <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> Message-ID: <17102F61-F233-4E8B-8D0D-4038571DD1A3@gmail.com> Hello, I removed wcwidth from the win32 driver and added an autoconf check for the function presence, please refetch. Regards, -- Anthony Ramine Le 11 f?vr. 2013 ? 11:58, Anthony Ramine a ?crit : > Hi, > > There is no wcwidth() in Windows, I'll add some autoconf magic to conditionally > use it. > > -- > Anthony Ramine > > Le 11 f?vr. 2013 ? 10:56, Fredrik a ?crit : > >> On 02/09/2013 02:01 PM, Anthony Ramine wrote: >>> Hi, >>> >>> I've got a fix: >>> >>> git fetch https://github.com/nox/otp.git wide-chars >>> >>> https://github.com/nox/otp/compare/erlang:master...wide-chars >>> https://github.com/nox/otp/compare/erlang:master...wide-chars.patch >>> >>> I can't test the win32 part though. >>> >>> Bj?rn, should I add some autoconf machinery to know whether wcwidth() is >>> available? >>> >>> Regards, >>> >> Your patch is failing on windows: >> >> error LNK2019: unresolved external symbol wcwidth referenced in function check_buf_size >> >> >> Could you please have a look at this? >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> > From robert.virding@REDACTED Sun Apr 28 04:57:16 2013 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 28 Apr 2013 03:57:16 +0100 (BST) Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <20130426134155.GA97541@ferdair.local> Message-ID: <1869237098.86655291.1367117836292.JavaMail.root@erlang-solutions.com> But it creates more garbage so it will cause the collector to run more often, which costs. Robert ----- Original Message ----- > From: "Fred Hebert" > > Ah yeah, the version that reverses twice is more likely to be fast > due > to the fact that lists:reverse/1 calls lists:reverse/2, which is now > a > NIF. Thus the traversal and building is gonna be made in C rather > than > in Erlang. Testing with a 'homemade' lists:reverse/2 tends to bring > things back to the more expected N vs. 2N for traversals. > > Regards, > Fred. > > On 04/26, Hans Svensson wrote: > > You are absolutely right about the 'badarg', it is better to have a > > consistent failure! > > > > However on performance, the suggested implementation is somewhat > > surprisingly the best option (I admit, I did measure before writing > > the patch ;-) ) For lists up to 3000 elements, it is on average > > ~x1.8 faster than a (tail-)recursive implementation! > > > > So a better version would probably be: > > init([]) -> error(badarg); > > init(List = [_ | _]) -> > > lists:reverse(tl(lists:reverse(List))); > > init(_) -> error(badarg). > > > > /Hans > > > > On 2013-04-25 18:18, Fred Hebert wrote: > > >I don't think there's any benefit in tail-recursion when you're > > >rebuilding an entirely new list. Given the limited number of > > >arguments, > > >the list you're creating by not being tail-recursive is in all > > >points > > >similar to the one you would have to maintain on the stack through > > >tail > > >recursions. Maybe a bit larger, but given you don't have to trash > > >it, > > >you're likely to avoid GC costs by doing it that way. > > > > > >See > > >http://erlang.2086793.n4.nabble.com/Efficiency-of-a-list-construction-td3538122.html#a3538379 > > >and > > >http://ferd.ca/erlang-s-tail-recursion-is-not-a-silver-bullet.html > > >for more information. > > > > > >What I would worry about in my implementation is adding a clause > > >of 'init([]) -> error(badarg)' to be consequent in failures with > > >the rest > > >of the lists module, and not get a 'function_clause' error there > > >when > > >someone passes in an empty list. > > > > > >On 04/25, Yurii Rashkovskii wrote: > > >>What about non-tail-recursiveness, though? > > >> > > >> > > >>On Thu, Apr 25, 2013 at 8:54 AM, Fred Hebert > > >>wrote: > > >> > > >>>Sounds to me like it would have been better implemented as > > >>>something like: > > >>> > > >>>init([_]) -> []; > > >>>init([H|T]) -> [H|init(T)]. > > >>> > > >>>As this would avoid re-building the list twice, once on each > > >>>reversal. > > >>> > > >>>Regards, > > >>>Fred. > > >>> > > >>> > > >>>On Thu, Apr 25, 2013 at 11:12 AM, Hans Svensson > > >>> wrote: > > >>> > > >>>>Hi, > > >>>> > > >>>>Yesterday I implemented, for the umpteenth time, the > > >>>>init-function. (I > > >>>>guess being taught Haskell at one point could be blamed partly > > >>>>for the > > >>>>coding style requiring this function...) It is a trivial > > >>>>function that I > > >>>>think should be part of the standard lists module. This patch > > >>>>adds the > > >>>>function, tests in lists_SUITE, and documentation of the > > >>>>function. > > >>>> > > >>>>The implementation is trivial: reverse(tl(reverse(List))). > > >>>> > > >>>>If I've missed some religious reason for not having this > > >>>>function feel > > >>>>free to drop the patch ;-) > > >>>> > > >>>>Cheers, > > >>>>Hans > > >>>> > > >>>>git fetch > > >>>>git://github.com/hanssv/otp.**gitadd_init_to_lists > > >>>> > > >>>>https://github.com/hanssv/otp/**compare/erlang:maint...add_** > > >>>>init_to_lists > > >>>>https://github.com/hanssv/otp/**compare/erlang:maint...add_** > > >>>>init_to_lists.patch > > >>>>______________________________**_________________ > > >>>>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 > > >>> > > >>> > > >>_______________________________________________ > > >>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 > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From robert.virding@REDACTED Sun Apr 28 05:09:49 2013 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 28 Apr 2013 04:09:49 +0100 (BST) Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: Message-ID: <338846430.86670951.1367118589795.JavaMail.root@erlang-solutions.com> I don't want to be a wet blanket but I feel that in general having blanks between operators is a Good Thing which improves legibility. So I don't really like a syntax change which supports not having blanks between operators. Robert ----- Original Message ----- > From: "Pedram Nimreezi" > To: "Sean Cribbs" > Cc: "Erlang Patches" > Sent: Monday, 22 April, 2013 11:06:24 AM > Subject: Re: [erlang-patches] Scan "=<<" as something useful > Good erlang wart to remove... +1 > On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs < sean@REDACTED > > wrote: > > I can't count how many times this has bitten me, kudos. > > > On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine < > > n.oxyde@REDACTED > > > wrote: > > > > Hello, > > > > > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. > > > {a, > > > > > > b} is rather written as {a,b}. Then there is the occasional Bin= > > > > > > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > > > > > > instead of '=','<<'. This patch teaches erl_scan how to not do > > > that. > > > > > > There is no backwards compatibility problem as '=<','<' can't > > > appear > > > > > > in valid code. > > > > > > git fetch https://github.com/nox/otp.git > > > disambiguate-equal-binary > > > > > > https://github.com/nox/otp/compare/disambiguate-equal-binary > > > > > > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > > > > > Regards, > > > > > > -- > > > > > > Anthony Ramine > > > > > > _______________________________________________ > > > > > > erlang-patches mailing list > > > > > > erlang-patches@REDACTED > > > > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > -- > > > Sean Cribbs < sean@REDACTED > > > > Software Engineer > > > Basho Technologies, Inc. > > > http://basho.com/ > > > _______________________________________________ > > > erlang-patches mailing list > > > erlang-patches@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-patches > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > // The hardest part of design ? is keeping features out. - Donald > Norman > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc@REDACTED Sun Apr 28 05:36:11 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Sat, 27 Apr 2013 23:36:11 -0400 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <338846430.86670951.1367118589795.JavaMail.root@erlang-solutions.com> References: <338846430.86670951.1367118589795.JavaMail.root@erlang-solutions.com> Message-ID: While I completely agree with this sentiment- I don't agree the good outweighs the bad here.. - I think it is a real language wart. - I think it is inconsistent with other types. - I think time spent looking for this error is wasted time. - I believe that at best this should warn and not error. Lastly, I consider this a byproduct of incomplete scanning and should be corrected not celebrated.. On Sat, Apr 27, 2013 at 11:09 PM, Robert Virding < robert.virding@REDACTED> wrote: > I don't want to be a wet blanket but I feel that in general having blanks > between operators is a Good Thing which improves legibility. So I don't > really like a syntax change which supports not having blanks between > operators. > > Robert > > ------------------------------ > > *From: *"Pedram Nimreezi" > *To: *"Sean Cribbs" > *Cc: *"Erlang Patches" > *Sent: *Monday, 22 April, 2013 11:06:24 AM > *Subject: *Re: [erlang-patches] Scan "=<<" as something useful > > > Good erlang wart to remove... +1 > > > On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs wrote: > >> I can't count how many times this has bitten me, kudos. >> >> >> On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine wrote: >> >>> Hello, >>> >>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, >>> b} is rather written as {a,b}. Then there is the occasional Bin= >>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' >>> instead of '=','<<'. This patch teaches erl_scan how to not do that. >>> >>> There is no backwards compatibility problem as '=<','<' can't appear >>> in valid code. >>> >>> git fetch https://github.com/nox/otp.gitdisambiguate-equal-binary >>> >>> https://github.com/nox/otp/compare/disambiguate-equal-binary >>> >>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> >> >> >> -- >> Sean Cribbs >> Software Engineer >> Basho Technologies, Inc. >> http://basho.com/ >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> >> > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Sun Apr 28 06:40:29 2013 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 28 Apr 2013 06:40:29 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <338846430.86670951.1367118589795.JavaMail.root@erlang-solutions.com> References: <338846430.86670951.1367118589795.JavaMail.root@erlang-solutions.com> Message-ID: <7E39D040-F282-46DF-9C07-467D39317786@feuerlabs.com> Well, the rest of the syntax *does* support not having spaces between operators, and It's a common enough style too. BR, Ulf W Ulf Wiger, Feuerlabs, Inc. http://www.feuerlabs.com 28 apr 2013 kl. 05:09 skrev Robert Virding : > I don't want to be a wet blanket but I feel that in general having blanks between operators is a Good Thing which improves legibility. So I don't really like a syntax change which supports not having blanks between operators. > > Robert > > From: "Pedram Nimreezi" > To: "Sean Cribbs" > Cc: "Erlang Patches" > Sent: Monday, 22 April, 2013 11:06:24 AM > Subject: Re: [erlang-patches] Scan "=<<" as something useful > > Good erlang wart to remove... +1 > > > On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs wrote: >> I can't count how many times this has bitten me, kudos. >> >> >> On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine wrote: >>> Hello, >>> >>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, >>> b} is rather written as {a,b}. Then there is the occasional Bin= >>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' >>> instead of '=','<<'. This patch teaches erl_scan how to not do that. >>> >>> There is no backwards compatibility problem as '=<','<' can't appear >>> in valid code. >>> >>> git fetch https://github.com/nox/otp.git disambiguate-equal-binary >>> >>> https://github.com/nox/otp/compare/disambiguate-equal-binary >>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> >> >> -- >> Sean Cribbs >> Software Engineer >> Basho Technologies, Inc. >> http://basho.com/ >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Apr 28 10:59:06 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 28 Apr 2013 10:59:06 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: <338846430.86670951.1367118589795.JavaMail.root@erlang-solutions.com> Message-ID: <4EFFC2A0-314D-4F3A-99E0-F660B08098EF@gmail.com> Hello Pedram, I will also add that most often I get hit by that bug in the shell, not in compiled modules. It is quite annoying to encounter an avoidable syntax error in the REPL while testing new things and doing "Bin=<<>>". Regards -- Anthony Ramine Le 28 avr. 2013 ? 05:36, Pedram Nimreezi a ?crit : > While I completely agree with this sentiment- I don't agree the good outweighs the bad here.. > > - I think it is a real language wart. > - I think it is inconsistent with other types. > - I think time spent looking for this error is wasted time. > - I believe that at best this should warn and not error. > > Lastly, I consider this a byproduct of incomplete scanning and should be corrected not celebrated.. > > > On Sat, Apr 27, 2013 at 11:09 PM, Robert Virding wrote: > I don't want to be a wet blanket but I feel that in general having blanks between operators is a Good Thing which improves legibility. So I don't really like a syntax change which supports not having blanks between operators. > > Robert > > From: "Pedram Nimreezi" > To: "Sean Cribbs" > Cc: "Erlang Patches" > Sent: Monday, 22 April, 2013 11:06:24 AM > Subject: Re: [erlang-patches] Scan "=<<" as something useful > > > Good erlang wart to remove... +1 > > > On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs wrote: > I can't count how many times this has bitten me, kudos. > > > On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine wrote: > Hello, > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > b} is rather written as {a,b}. Then there is the occasional Bin= > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > instead of '=','<<'. This patch teaches erl_scan how to not do that. > > There is no backwards compatibility problem as '=<','<' can't appear > in valid code. > > git fetch https://github.com/nox/otp.git disambiguate-equal-binary > > https://github.com/nox/otp/compare/disambiguate-equal-binary > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > Regards, > > -- > Anthony Ramine > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > Sean Cribbs > Software Engineer > Basho Technologies, Inc. > http://basho.com/ > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > > > > -- > /* Sincerely > -------------------------------------------------------------- > Pedram Nimreezi - Chief Technology Officer */ > > // The hardest part of design ? is keeping features out. - Donald Norman > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From robert.virding@REDACTED Mon Apr 29 06:29:11 2013 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 29 Apr 2013 05:29:11 +0100 (BST) Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <4EFFC2A0-314D-4F3A-99E0-F660B08098EF@gmail.com> Message-ID: <262226227.88551570.1367209751108.JavaMail.root@erlang-solutions.com> Well, I can honestly say I never encounter it so that doesn't prove anything either way. Just put spaces around = and you will get easier to read code as well. IMAO Robert ----- Original Message ----- > From: "Anthony Ramine" > To: mc@REDACTED > Cc: "Robert Virding" , "Erlang Patches" > Sent: Sunday, 28 April, 2013 4:59:06 AM > Subject: Re: [erlang-patches] Scan "=<<" as something useful > > Hello Pedram, > > I will also add that most often I get hit by that bug in the shell, > not in compiled modules. It is quite annoying to encounter an > avoidable syntax error in the REPL while testing new things and > doing "Bin=<<>>". > > Regards > > -- > Anthony Ramine > > Le 28 avr. 2013 ? 05:36, Pedram Nimreezi a ?crit : > > > While I completely agree with this sentiment- I don't agree the > > good outweighs the bad here.. > > > > - I think it is a real language wart. > > - I think it is inconsistent with other types. > > - I think time spent looking for this error is wasted time. > > - I believe that at best this should warn and not error. > > > > Lastly, I consider this a byproduct of incomplete scanning and > > should be corrected not celebrated.. > > > > > > On Sat, Apr 27, 2013 at 11:09 PM, Robert Virding > > wrote: > > I don't want to be a wet blanket but I feel that in general having > > blanks between operators is a Good Thing which improves > > legibility. So I don't really like a syntax change which supports > > not having blanks between operators. > > > > Robert > > > > From: "Pedram Nimreezi" > > To: "Sean Cribbs" > > Cc: "Erlang Patches" > > Sent: Monday, 22 April, 2013 11:06:24 AM > > Subject: Re: [erlang-patches] Scan "=<<" as something useful > > > > > > Good erlang wart to remove... +1 > > > > > > On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs > > wrote: > > I can't count how many times this has bitten me, kudos. > > > > > > On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine > > wrote: > > Hello, > > > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. > > {a, > > b} is rather written as {a,b}. Then there is the occasional Bin= > > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > > instead of '=','<<'. This patch teaches erl_scan how to not do > > that. > > > > There is no backwards compatibility problem as '=<','<' can't > > appear > > in valid code. > > > > git fetch https://github.com/nox/otp.git > > disambiguate-equal-binary > > > > https://github.com/nox/otp/compare/disambiguate-equal-binary > > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > > > Regards, > > > > -- > > Anthony Ramine > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > -- > > Sean Cribbs > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > -- > > /* Sincerely > > -------------------------------------------------------------- > > Pedram Nimreezi - Chief Technology Officer */ > > > > // The hardest part of design ? is keeping features out. - Donald > > Norman > > > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > > > -- > > /* Sincerely > > -------------------------------------------------------------- > > Pedram Nimreezi - Chief Technology Officer */ > > > > // The hardest part of design ? is keeping features out. - Donald > > Norman > > > > > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > From fredrik@REDACTED Mon Apr 29 09:14:06 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:14:06 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: Message-ID: <517E1DBE.80807@erlang.org> On 04/21/2013 10:15 PM, Anthony Ramine wrote: > Hello, > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > b} is rather written as {a,b}. Then there is the occasional Bin= > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > instead of '=','<<'. This patch teaches erl_scan how to not do that. > > There is no backwards compatibility problem as '=<','<' can't appear > in valid code. > > git fetch https://github.com/nox/otp.git disambiguate-equal-binary > > https://github.com/nox/otp/compare/disambiguate-equal-binary > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > Regards, > > -- > Anthony Ramine > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Anthony, I've fetched your branch and it is now in the 'pu' branch. A review process has started. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Apr 29 09:17:21 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:17:21 +0200 Subject: [erlang-patches] Fix odbc in non-standart location error (--with-odbc). In-Reply-To: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F73@SRV-EXCHMBX2.billing.ru> References: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F73@SRV-EXCHMBX2.billing.ru> Message-ID: <517E1E81.2050208@erlang.org> On 04/22/2013 01:43 PM, Saltanov, Alexey wrote: > git fetch git://github.com/saltos/otp.git odbc_in_non_standard_location Hello, Could you please rebase your patch upon the current maint branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Mon Apr 29 09:18:16 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:18:16 +0200 Subject: [erlang-patches] Fix reltool copy_file "not owner" error. In-Reply-To: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F7A@SRV-EXCHMBX2.billing.ru> References: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F7A@SRV-EXCHMBX2.billing.ru> Message-ID: <517E1EB8.3070208@erlang.org> On 04/22/2013 01:43 PM, Saltanov, Alexey wrote: > git fetch git://github.com/saltos/otp.git reltool_copy_file_not_owner_fix Hello, Could you please rebase this patch upon the current maint branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Mon Apr 29 09:21:45 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:21:45 +0200 Subject: [erlang-patches] Speed up index creation for Mnesia set tables In-Reply-To: <5178215E.9070506@shoretel.com> References: <51686FDA.9010205@shoretel.com> <516FE69A.6040806@erlang.org> <5178215E.9070506@shoretel.com> Message-ID: <517E1F89.5070104@erlang.org> On 04/24/2013 08:15 PM, Nick Marino wrote: > git fetch git://github.com/nickelization/otp.git > mnesia_idx_insert_speedup Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Apr 29 09:24:02 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:24:02 +0200 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <517947E4.2040504@gmail.com> References: <517947E4.2040504@gmail.com> Message-ID: <517E2012.9030009@erlang.org> On 04/25/2013 05:12 PM, Hans Svensson wrote: > git fetch git://github.com/hanssv/otp.git add_init_to_lists Fetched, it is currently located in the 'pu' branch. A review process has started. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Apr 29 09:42:06 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:42:06 +0200 Subject: [erlang-patches] Fix an inconsistent state in epp In-Reply-To: References: Message-ID: <517E244E.4050307@erlang.org> On 04/27/2013 01:23 PM, Anthony Ramine wrote: > Hello, > > When entering an included file, epp doesn't properly set #epp.name2 like it does on init, generating a malformed file attribute with file name "" when it leaves the file. > > git fetch https://github.com/nox/otp.git fix-epp-file-attrs > > https://github.com/nox/otp/compare/erlang:maint...fix-epp-file-attrs > https://github.com/nox/otp/compare/erlang:maint...fix-epp-file-attrs.patch > > Regards, > Hello, I've fetched your patch it is now located in the 'pu' branch. A review process has started. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Apr 29 09:44:19 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:44:19 +0200 Subject: [erlang-patches] Fix some Makefile rules that didn't support silent rules In-Reply-To: <255174D9-671F-40B4-8EBD-412A57C15FBD@gmail.com> References: <255174D9-671F-40B4-8EBD-412A57C15FBD@gmail.com> Message-ID: <517E24D3.1020607@erlang.org> On 04/27/2013 01:36 PM, Anthony Ramine wrote: > Hello, > > This patch fixes some Makefile rules that didn't support silent rules. > > git fetch https://github.com/nox/otp.git fix-silent-rules > > https://github.com/nox/otp/compare/erlang:maint...fix-silent-rules > https://github.com/nox/otp/compare/erlang:maint...fix-silent-rules.patch > > Regards, > Hello Anthony, I've fetched your patch, it is now located in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Apr 29 09:53:26 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 29 Apr 2013 09:53:26 +0200 Subject: [erlang-patches] Fix some compilation warnings In-Reply-To: References: Message-ID: <517E26F6.5010103@erlang.org> On 04/27/2013 01:48 PM, Anthony Ramine wrote: > Hello, > > This branch removes some compilation warnings I noticed while using silent rules. > > git fetch https://github.com/nox/otp.git fix-warnings > > https://github.com/nox/otp/compare/erlang:maint...fix-warnings > https://github.com/nox/otp/compare/erlang:maint...fix-warnings.patch > > Regards, > Hello, I've fetched your branch and it is now located in the 'pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From Alexey.Saltanov@REDACTED Mon Apr 29 10:34:11 2013 From: Alexey.Saltanov@REDACTED (Saltanov, Alexey) Date: Mon, 29 Apr 2013 08:34:11 +0000 Subject: [erlang-patches] Fix odbc in non-standart location error (--with-odbc). In-Reply-To: <517E1E81.2050208@erlang.org> References: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F73@SRV-EXCHMBX2.billing.ru> <517E1E81.2050208@erlang.org> Message-ID: <0589296B5BCDDA4A8F5CEB3F8739A8153AF4A41B@SRV-EXCHMBX2.billing.ru> Hello, Ok, done. From: Fredrik [mailto:fredrik@REDACTED] Sent: Monday, April 29, 2013 11:17 AM To: Saltanov, Alexey Cc: erlang-patches@REDACTED Subject: Re: [erlang-patches] Fix odbc in non-standart location error (--with-odbc). On 04/22/2013 01:43 PM, Saltanov, Alexey wrote: git fetch git://github.com/saltos/otp.git odbc_in_non_standard_location Hello, Could you please rebase your patch upon the current maint branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexey.Saltanov@REDACTED Mon Apr 29 10:34:20 2013 From: Alexey.Saltanov@REDACTED (Saltanov, Alexey) Date: Mon, 29 Apr 2013 08:34:20 +0000 Subject: [erlang-patches] Fix reltool copy_file "not owner" error. In-Reply-To: <517E1EB8.3070208@erlang.org> References: <0589296B5BCDDA4A8F5CEB3F8739A8153AE42F7A@SRV-EXCHMBX2.billing.ru> <517E1EB8.3070208@erlang.org> Message-ID: <0589296B5BCDDA4A8F5CEB3F8739A8153AF4B422@SRV-EXCHMBX2.billing.ru> Hello, Ok, done. From: Fredrik [mailto:fredrik@REDACTED] Sent: Monday, April 29, 2013 11:18 AM To: Saltanov, Alexey Cc: erlang-patches@REDACTED Subject: Re: [erlang-patches] Fix reltool copy_file "not owner" error. On 04/22/2013 01:43 PM, Saltanov, Alexey wrote: git fetch git://github.com/saltos/otp.git reltool_copy_file_not_owner_fix Hello, Could you please rebase this patch upon the current maint branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-patches@REDACTED Mon Apr 29 10:53:42 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 10:53:42 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: Message-ID: <20130429085342.GA7639@erix.ericsson.se> On Sun, Apr 21, 2013 at 10:15:28PM +0200, Anthony Ramine wrote: > Hello, > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > b} is rather written as {a,b}. Then there is the occasional Bin= > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > instead of '=','<<'. This patch teaches erl_scan how to not do that. > > There is no backwards compatibility problem as '=<','<' can't appear > in valid code. When I tried to fix this years ago while rewriting the scanner just after the binary syntax was introduced I got lecutured (I think by Robert) that it was a bad change because it introduces syntax knowledge into the scanner. The scanner is today greedy so it collects as many characters as it can into a valid token, and "=<" is a valid token. When it is followed by "<" that becomes a syntax error in the parser. I kind of miss this argument this time around... > > git fetch https://github.com/nox/otp.git disambiguate-equal-binary > > https://github.com/nox/otp/compare/disambiguate-equal-binary > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > Regards, > > -- > Anthony Ramine > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-patches@REDACTED Mon Apr 29 11:18:33 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 11:18:33 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429085342.GA7639@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> Message-ID: <20130429091833.GA8431@erix.ericsson.se> On Mon, Apr 29, 2013 at 10:53:42AM +0200, Raimo Niskanen wrote: > On Sun, Apr 21, 2013 at 10:15:28PM +0200, Anthony Ramine wrote: > > Hello, > > > > I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > > b} is rather written as {a,b}. Then there is the occasional Bin= > > <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > > instead of '=','<<'. This patch teaches erl_scan how to not do that. > > > > There is no backwards compatibility problem as '=<','<' can't appear > > in valid code. > > When I tried to fix this years ago while rewriting the scanner just after > the binary syntax was introduced I got lecutured (I think by Robert) > that it was a bad change because it introduces syntax knowledge > into the scanner. > > The scanner is today greedy so it collects as many characters as it > can into a valid token, and "=<" is a valid token. When it is > followed by "<" that becomes a syntax error in the parser. > > I kind of miss this argument this time around... > If I read your patch correctly you also fix this variant: B=<<<<1>>/binary,2>>. which means the scanner reads an arbitrary number of "<" after "=<" and then based on if they are odd or even decides to be greedy or not, and that is really much and ugly syntax knowledge for a scanner... I got a big NO for this change. > > > > git fetch https://github.com/nox/otp.git disambiguate-equal-binary > > > > https://github.com/nox/otp/compare/disambiguate-equal-binary > > https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > > > Regards, > > > > -- > > Anthony Ramine > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Mon Apr 29 11:41:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Apr 2013 11:41:35 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429091833.GA8431@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> Message-ID: Hello Raimo, If I read the documentation, I don't see anywhere where it is written that erl_scan is supposed to be greedy. Nor I see any syntax knowledge if we just say that erl_scan will avoid returning two consecutive comparison operators if it can. That is just knowledge that '=<' '<' makes no sense, and I can't think of any language where it does. Erlang is and has always been pragmatic, letting such an embarrassing syntax wart for the sake of beauty isn't what should be done here, in my opinion. Pragmatism is what allows us to have a nice syntax for specs and callbacks; which wouldn't be possible without an ugly hack too[1]. What would break if that patch is accepted? The answer is nothing. Regards, [1] https://github.com/nox/otp/blob/master/lib/stdlib/src/erl_parse.yrl#L543-552 -- Anthony Ramine Le 29 avr. 2013 ? 11:18, Raimo Niskanen a ?crit : > On Mon, Apr 29, 2013 at 10:53:42AM +0200, Raimo Niskanen wrote: >> On Sun, Apr 21, 2013 at 10:15:28PM +0200, Anthony Ramine wrote: >>> Hello, >>> >>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, >>> b} is rather written as {a,b}. Then there is the occasional Bin= >>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' >>> instead of '=','<<'. This patch teaches erl_scan how to not do that. >>> >>> There is no backwards compatibility problem as '=<','<' can't appear >>> in valid code. >> >> When I tried to fix this years ago while rewriting the scanner just after >> the binary syntax was introduced I got lecutured (I think by Robert) >> that it was a bad change because it introduces syntax knowledge >> into the scanner. >> >> The scanner is today greedy so it collects as many characters as it >> can into a valid token, and "=<" is a valid token. When it is >> followed by "<" that becomes a syntax error in the parser. >> >> I kind of miss this argument this time around... >> > > If I read your patch correctly you also fix this variant: > > B=<<<<1>>/binary,2>>. > > which means the scanner reads an arbitrary number of "<" after > "=<" and then based on if they are odd or even decides to be > greedy or not, and that is really much and ugly syntax knowledge > for a scanner... > > I got a big NO for this change. > >>> >>> git fetch https://github.com/nox/otp.git disambiguate-equal-binary >>> >>> https://github.com/nox/otp/compare/disambiguate-equal-binary >>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> -- >> >> / Raimo Niskanen, Erlang/OTP, Ericsson AB >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From essen@REDACTED Mon Apr 29 13:59:11 2013 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 29 Apr 2013 13:59:11 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <262226227.88551570.1367209751108.JavaMail.root@erlang-solutions.com> References: <262226227.88551570.1367209751108.JavaMail.root@erlang-solutions.com> Message-ID: <517E608F.3030606@ninenines.eu> I don't encounter it often anymore because I got used to it being broken, and put an extra space, but that doesn't mean it shouldn't be fixed, it would relieve the many new developers from making the mistake and then losing time asking about it. On 04/29/2013 06:29 AM, Robert Virding wrote: > Well, I can honestly say I never encounter it so that doesn't prove anything either way. Just put spaces around = and you will get easier to read code as well. IMAO > > Robert > > ----- Original Message ----- >> From: "Anthony Ramine" >> To: mc@REDACTED >> Cc: "Robert Virding" , "Erlang Patches" >> Sent: Sunday, 28 April, 2013 4:59:06 AM >> Subject: Re: [erlang-patches] Scan "=<<" as something useful >> >> Hello Pedram, >> >> I will also add that most often I get hit by that bug in the shell, >> not in compiled modules. It is quite annoying to encounter an >> avoidable syntax error in the REPL while testing new things and >> doing "Bin=<<>>". >> >> Regards >> >> -- >> Anthony Ramine >> >> Le 28 avr. 2013 ? 05:36, Pedram Nimreezi a ?crit : >> >>> While I completely agree with this sentiment- I don't agree the >>> good outweighs the bad here.. >>> >>> - I think it is a real language wart. >>> - I think it is inconsistent with other types. >>> - I think time spent looking for this error is wasted time. >>> - I believe that at best this should warn and not error. >>> >>> Lastly, I consider this a byproduct of incomplete scanning and >>> should be corrected not celebrated.. >>> >>> >>> On Sat, Apr 27, 2013 at 11:09 PM, Robert Virding >>> wrote: >>> I don't want to be a wet blanket but I feel that in general having >>> blanks between operators is a Good Thing which improves >>> legibility. So I don't really like a syntax change which supports >>> not having blanks between operators. >>> >>> Robert >>> >>> From: "Pedram Nimreezi" >>> To: "Sean Cribbs" >>> Cc: "Erlang Patches" >>> Sent: Monday, 22 April, 2013 11:06:24 AM >>> Subject: Re: [erlang-patches] Scan "=<<" as something useful >>> >>> >>> Good erlang wart to remove... +1 >>> >>> >>> On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs >>> wrote: >>> I can't count how many times this has bitten me, kudos. >>> >>> >>> On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine >>> wrote: >>> Hello, >>> >>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. >>> {a, >>> b} is rather written as {a,b}. Then there is the occasional Bin= >>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' >>> instead of '=','<<'. This patch teaches erl_scan how to not do >>> that. >>> >>> There is no backwards compatibility problem as '=<','<' can't >>> appear >>> in valid code. >>> >>> git fetch https://github.com/nox/otp.git >>> disambiguate-equal-binary >>> >>> https://github.com/nox/otp/compare/disambiguate-equal-binary >>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >>> >>> -- >>> Sean Cribbs >>> Software Engineer >>> Basho Technologies, Inc. >>> http://basho.com/ >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >>> >>> >>> -- >>> /* Sincerely >>> -------------------------------------------------------------- >>> Pedram Nimreezi - Chief Technology Officer */ >>> >>> // The hardest part of design ? is keeping features out. - Donald >>> Norman >>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >>> >>> >>> -- >>> /* Sincerely >>> -------------------------------------------------------------- >>> Pedram Nimreezi - Chief Technology Officer */ >>> >>> // The hardest part of design ? is keeping features out. - Donald >>> Norman >>> >>> >>> _______________________________________________ >>> 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 > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From g@REDACTED Mon Apr 29 14:11:13 2013 From: g@REDACTED (Garrett Smith) Date: Mon, 29 Apr 2013 07:11:13 -0500 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <517E608F.3030606@ninenines.eu> References: <262226227.88551570.1367209751108.JavaMail.root@erlang-solutions.com> <517E608F.3030606@ninenines.eu> Message-ID: FWIW I don't use spaces between record bindings: #user{name="Stan", age=25} I personally find this convention more readable than with spaces. Having to do so for binaries: #user{name= <<"Stan">>, age=25} causes me to toss and turn in my sleep, occasionally waking with night terrors. I'm quite happy to see this land. On Mon, Apr 29, 2013 at 6:59 AM, Lo?c Hoguin wrote: > I don't encounter it often anymore because I got used to it being broken, > and put an extra space, but that doesn't mean it shouldn't be fixed, it > would relieve the many new developers from making the mistake and then > losing time asking about it. > > > On 04/29/2013 06:29 AM, Robert Virding wrote: >> >> Well, I can honestly say I never encounter it so that doesn't prove >> anything either way. Just put spaces around = and you will get easier to >> read code as well. IMAO >> >> Robert >> >> ----- Original Message ----- >>> >>> From: "Anthony Ramine" >>> To: mc@REDACTED >>> Cc: "Robert Virding" , "Erlang >>> Patches" >>> Sent: Sunday, 28 April, 2013 4:59:06 AM >>> Subject: Re: [erlang-patches] Scan "=<<" as something useful >>> >>> Hello Pedram, >>> >>> I will also add that most often I get hit by that bug in the shell, >>> not in compiled modules. It is quite annoying to encounter an >>> avoidable syntax error in the REPL while testing new things and >>> doing "Bin=<<>>". >>> >>> Regards >>> >>> -- >>> Anthony Ramine >>> >>> Le 28 avr. 2013 ? 05:36, Pedram Nimreezi a ?crit : >>> >>>> While I completely agree with this sentiment- I don't agree the >>>> good outweighs the bad here.. >>>> >>>> - I think it is a real language wart. >>>> - I think it is inconsistent with other types. >>>> - I think time spent looking for this error is wasted time. >>>> - I believe that at best this should warn and not error. >>>> >>>> Lastly, I consider this a byproduct of incomplete scanning and >>>> should be corrected not celebrated.. >>>> >>>> >>>> On Sat, Apr 27, 2013 at 11:09 PM, Robert Virding >>>> wrote: >>>> I don't want to be a wet blanket but I feel that in general having >>>> blanks between operators is a Good Thing which improves >>>> legibility. So I don't really like a syntax change which supports >>>> not having blanks between operators. >>>> >>>> Robert >>>> >>>> From: "Pedram Nimreezi" >>>> To: "Sean Cribbs" >>>> Cc: "Erlang Patches" >>>> Sent: Monday, 22 April, 2013 11:06:24 AM >>>> Subject: Re: [erlang-patches] Scan "=<<" as something useful >>>> >>>> >>>> Good erlang wart to remove... +1 >>>> >>>> >>>> On Mon, Apr 22, 2013 at 12:21 AM, Sean Cribbs >>>> wrote: >>>> I can't count how many times this has bitten me, kudos. >>>> >>>> >>>> On Sun, Apr 21, 2013 at 11:15 PM, Anthony Ramine >>>> wrote: >>>> Hello, >>>> >>>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. >>>> {a, >>>> b} is rather written as {a,b}. Then there is the occasional Bin= >>>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' >>>> instead of '=','<<'. This patch teaches erl_scan how to not do >>>> that. >>>> >>>> There is no backwards compatibility problem as '=<','<' can't >>>> appear >>>> in valid code. >>>> >>>> git fetch https://github.com/nox/otp.git >>>> disambiguate-equal-binary >>>> >>>> https://github.com/nox/otp/compare/disambiguate-equal-binary >>>> >>>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch >>>> >>>> Regards, >>>> >>>> -- >>>> Anthony Ramine >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>>> >>>> >>>> -- >>>> Sean Cribbs >>>> Software Engineer >>>> Basho Technologies, Inc. >>>> http://basho.com/ >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>>> >>>> >>>> >>>> -- >>>> /* Sincerely >>>> -------------------------------------------------------------- >>>> Pedram Nimreezi - Chief Technology Officer */ >>>> >>>> // The hardest part of design ? is keeping features out. - Donald >>>> Norman >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> >>>> >>>> >>>> >>>> -- >>>> /* Sincerely >>>> -------------------------------------------------------------- >>>> Pedram Nimreezi - Chief Technology Officer */ >>>> >>>> // The hardest part of design ? is keeping features out. - Donald >>>> Norman >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From per@REDACTED Mon Apr 29 14:37:41 2013 From: per@REDACTED (Per Hedeland) Date: Mon, 29 Apr 2013 14:37:41 +0200 (CEST) Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: Message-ID: <201304291237.r3TCbf8D060343@pluto.hedeland.org> Anthony Ramine wrote: > >If I read the documentation, I don't see anywhere where it is written that erl_scan is supposed to be greedy. Nor I see any syntax knowledge if we just say that erl_scan will avoid returning two consecutive comparison operators if it can. That is just knowledge that '=<' '<' makes no sense, and I can't think of any language where it does. 1> A = <<17>>. <<17>> 2> A=<<<42>>. true So will this useful:-) syntax break with the patch? (I haven't looked at it). --Per Hedeland From n.oxyde@REDACTED Mon Apr 29 14:45:10 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Apr 2013 14:45:10 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <201304291237.r3TCbf8D060343@pluto.hedeland.org> References: <201304291237.r3TCbf8D060343@pluto.hedeland.org> Message-ID: <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> Hello Per, It counts the number of < characters and scans a '=<' token if the number is odd; so that still works. Regards, -- Anthony Ramine Le 29 avr. 2013 ? 14:37, Per Hedeland a ?crit : > Anthony Ramine wrote: >> >> If I read the documentation, I don't see anywhere where it is written that erl_scan is supposed to be greedy. Nor I see any syntax knowledge if we just say that erl_scan will avoid returning two consecutive comparison operators if it can. That is just knowledge that '=<' '<' makes no sense, and I can't think of any language where it does. > > 1> A = <<17>>. > <<17>> > 2> A=<<<42>>. > true > > So will this useful:-) syntax break with the patch? (I haven't looked at > it). > > --Per Hedeland > From raimo+erlang-patches@REDACTED Mon Apr 29 15:05:45 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 15:05:45 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> Message-ID: <20130429130545.GA12647@erix.ericsson.se> On Mon, Apr 29, 2013 at 11:41:35AM +0200, Anthony Ramine wrote: > Hello Raimo, > > If I read the documentation, I don't see anywhere where it is written that erl_scan is supposed to be greedy. Nor I see any syntax knowledge if we just say that erl_scan will avoid returning two consecutive comparison operators if it can. That is just knowledge that '=<' '<' makes no sense, and I can't think of any language where it does. But that knowledge is aquired by doing an infinite look-ahead for this operator, and knowing that =< and < are both comparision operators _is_ syntax knowledge as are all other reasons for knowing that =< and < are not allowed in sequence. > > Erlang is and has always been pragmatic, letting such an embarrassing syntax wart for the sake of beauty isn't what should be done here, in my opinion. Pragmatism is what allows us to have a nice syntax for specs and callbacks; which wouldn't be possible without an ugly hack too[1]. > > What would break if that patch is accepted? The answer is nothing. Here are the old arguments: http://erlang.org/pipermail/erlang-questions/2003-May/008751.html It heats up at: http://erlang.org/pipermail/erlang-questions/2003-May/008923.html ...and the subject pops up occasionally: http://erlang.org/pipermail/erlang-questions/2010-July/052587.html One final straw back then was this: the typo "A=<<<1>>" accidentally becomes valid syntax with the proposed change. > > Regards, > > [1] https://github.com/nox/otp/blob/master/lib/stdlib/src/erl_parse.yrl#L543-552 > > -- > Anthony Ramine > > Le 29 avr. 2013 ? 11:18, Raimo Niskanen a ?crit : > > > On Mon, Apr 29, 2013 at 10:53:42AM +0200, Raimo Niskanen wrote: > >> On Sun, Apr 21, 2013 at 10:15:28PM +0200, Anthony Ramine wrote: > >>> Hello, > >>> > >>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > >>> b} is rather written as {a,b}. Then there is the occasional Bin= > >>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > >>> instead of '=','<<'. This patch teaches erl_scan how to not do that. > >>> > >>> There is no backwards compatibility problem as '=<','<' can't appear > >>> in valid code. > >> > >> When I tried to fix this years ago while rewriting the scanner just after > >> the binary syntax was introduced I got lecutured (I think by Robert) > >> that it was a bad change because it introduces syntax knowledge > >> into the scanner. > >> > >> The scanner is today greedy so it collects as many characters as it > >> can into a valid token, and "=<" is a valid token. When it is > >> followed by "<" that becomes a syntax error in the parser. > >> > >> I kind of miss this argument this time around... > >> > > > > If I read your patch correctly you also fix this variant: > > > > B=<<<<1>>/binary,2>>. > > > > which means the scanner reads an arbitrary number of "<" after > > "=<" and then based on if they are odd or even decides to be > > greedy or not, and that is really much and ugly syntax knowledge > > for a scanner... > > > > I got a big NO for this change. > > > >>> > >>> git fetch https://github.com/nox/otp.git disambiguate-equal-binary > >>> > >>> https://github.com/nox/otp/compare/disambiguate-equal-binary > >>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > >>> > >>> Regards, > >>> > >>> -- > >>> Anthony Ramine > >>> _______________________________________________ > >>> erlang-patches mailing list > >>> erlang-patches@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-patches > >> > >> -- > >> > >> / Raimo Niskanen, Erlang/OTP, Ericsson AB > >> _______________________________________________ > >> erlang-patches mailing list > >> erlang-patches@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > _______________________________________________ > > erlang-patches mailing list > > erlang-patches@REDACTED > > http://erlang.org/mailman/listinfo/erlang-patches > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Mon Apr 29 15:11:44 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Apr 2013 15:11:44 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429130545.GA12647@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> Message-ID: <410DB75B-3587-41C0-89C4-E5B49E9C5F59@gmail.com> I don't understand how is that a typo, as "A=<<<1>>" is valid syntax with or without my patch. -- Anthony Ramine Le 29 avr. 2013 ? 15:05, Raimo Niskanen a ?crit : > One final straw back then was this: the typo "A=<<<1>>" accidentally > becomes valid syntax with the proposed change. From raimo+erlang-patches@REDACTED Mon Apr 29 15:14:58 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 15:14:58 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429130545.GA12647@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> Message-ID: <20130429131458.GB12647@erix.ericsson.se> On Mon, Apr 29, 2013 at 03:05:45PM +0200, Raimo Niskanen wrote: > On Mon, Apr 29, 2013 at 11:41:35AM +0200, Anthony Ramine wrote: > > Hello Raimo, > > > > If I read the documentation, I don't see anywhere where it is written that erl_scan is supposed to be greedy. Nor I see any syntax knowledge if we just say that erl_scan will avoid returning two consecutive comparison operators if it can. That is just knowledge that '=<' '<' makes no sense, and I can't think of any language where it does. > > But that knowledge is aquired by doing an infinite look-ahead > for this operator, and knowing that =< and < are both comparision > operators _is_ syntax knowledge as are all other reasons for > knowing that =< and < are not allowed in sequence. > > > > > Erlang is and has always been pragmatic, letting such an embarrassing syntax wart for the sake of beauty isn't what should be done here, in my opinion. Pragmatism is what allows us to have a nice syntax for specs and callbacks; which wouldn't be possible without an ugly hack too[1]. > > > > What would break if that patch is accepted? The answer is nothing. > > Here are the old arguments: > http://erlang.org/pipermail/erlang-questions/2003-May/008751.html > > It heats up at: > http://erlang.org/pipermail/erlang-questions/2003-May/008923.html > > ...and the subject pops up occasionally: > http://erlang.org/pipermail/erlang-questions/2010-July/052587.html > > One final straw back then was this: the typo "A=<<<1>>" accidentally > becomes valid syntax with the proposed change. ...that was wrong; rather that intending to write "A =< << 1 >>" without spaces as "A=<<<1>>" and misspelling to "A=<<1>>" would give no compiler error and unexpected runtime behaviour... > > > > > Regards, > > > > [1] https://github.com/nox/otp/blob/master/lib/stdlib/src/erl_parse.yrl#L543-552 > > > > -- > > Anthony Ramine > > > > Le 29 avr. 2013 ? 11:18, Raimo Niskanen a ?crit : > > > > > On Mon, Apr 29, 2013 at 10:53:42AM +0200, Raimo Niskanen wrote: > > >> On Sun, Apr 21, 2013 at 10:15:28PM +0200, Anthony Ramine wrote: > > >>> Hello, > > >>> > > >>> I've noticed that Erlang/OTP own code tend to be space-free, e.g. {a, > > >>> b} is rather written as {a,b}. Then there is the occasional Bin= > > >>> <<42>> with a space because erl_scan will scans "=<<" as '=<','<' > > >>> instead of '=','<<'. This patch teaches erl_scan how to not do that. > > >>> > > >>> There is no backwards compatibility problem as '=<','<' can't appear > > >>> in valid code. > > >> > > >> When I tried to fix this years ago while rewriting the scanner just after > > >> the binary syntax was introduced I got lecutured (I think by Robert) > > >> that it was a bad change because it introduces syntax knowledge > > >> into the scanner. > > >> > > >> The scanner is today greedy so it collects as many characters as it > > >> can into a valid token, and "=<" is a valid token. When it is > > >> followed by "<" that becomes a syntax error in the parser. > > >> > > >> I kind of miss this argument this time around... > > >> > > > > > > If I read your patch correctly you also fix this variant: > > > > > > B=<<<<1>>/binary,2>>. > > > > > > which means the scanner reads an arbitrary number of "<" after > > > "=<" and then based on if they are odd or even decides to be > > > greedy or not, and that is really much and ugly syntax knowledge > > > for a scanner... > > > > > > I got a big NO for this change. > > > > > >>> > > >>> git fetch https://github.com/nox/otp.git disambiguate-equal-binary > > >>> > > >>> https://github.com/nox/otp/compare/disambiguate-equal-binary > > >>> https://github.com/nox/otp/compare/disambiguate-equal-binary.patch > > >>> > > >>> Regards, > > >>> > > >>> -- > > >>> Anthony Ramine > > >>> _______________________________________________ > > >>> erlang-patches mailing list > > >>> erlang-patches@REDACTED > > >>> http://erlang.org/mailman/listinfo/erlang-patches > > >> > > >> -- > > >> > > >> / Raimo Niskanen, Erlang/OTP, Ericsson AB > > >> _______________________________________________ > > >> erlang-patches mailing list > > >> erlang-patches@REDACTED > > >> http://erlang.org/mailman/listinfo/erlang-patches > > > > > > -- > > > > > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > _______________________________________________ > > > erlang-patches mailing list > > > erlang-patches@REDACTED > > > http://erlang.org/mailman/listinfo/erlang-patches > > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From essen@REDACTED Mon Apr 29 15:23:58 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 29 Apr 2013 15:23:58 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429131458.GB12647@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> <20130429131458.GB12647@erix.ericsson.se> Message-ID: <517E746E.4090000@ninenines.eu> On 04/29/2013 03:14 PM, Raimo Niskanen wrote: >> One final straw back then was this: the typo "A=<<<1>>" accidentally >> becomes valid syntax with the proposed change. > > ...that was wrong; rather that intending to write "A =< << 1 >>" without > spaces as "A=<<<1>>" and misspelling to "A=<<1>>" would give no compiler > error and unexpected runtime behaviour... How often have you encountered code that had this form? I never have, and I use binaries everyday. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From n.oxyde@REDACTED Mon Apr 29 15:30:52 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Apr 2013 15:30:52 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429131458.GB12647@erix.ericsson.se> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> <20130429131458.GB12647@erix.ericsson.se> Message-ID: <26011E52-6378-4B83-BE78-1CA5B1C05D23@gmail.com> Comparing a variable with a binary literal must be very unusual code. Using your argument, I could also argue that epp concatenating strings literals together is harmful, because I could write ["foo"\n"bar"] instead of ["foo",\n"bar"] and that give no compilation error and unexpected runtime behaviour. Should we remove concatenation of consecutive string literals? Regards, -- Anthony Ramine Le 29 avr. 2013 ? 15:14, Raimo Niskanen a ?crit : > ...that was wrong; rather that intending to write "A =< << 1 >>" without > spaces as "A=<<<1>>" and misspelling to "A=<<1>>" would give no compiler > error and unexpected runtime behaviour... From egil@REDACTED Mon Apr 29 15:32:08 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 29 Apr 2013 15:32:08 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> References: <201304291237.r3TCbf8D060343@pluto.hedeland.org> <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> Message-ID: <517E7658.80406@erlang.org> On 2013-04-29 14:45, Anthony Ramine wrote: > Hello Per, > > It counts the number of < characters and scans a '=<' token if the number is odd; so that still works. > > Regards, > Since I love these discussions I would like to add some questions, Would it be more suitable to add '=<<' as a token to erl_scan.erl and then add appropriate grammar to erl_parse.yrl? I get the feeling that erl_scan should be a tokenizer and not handle grammar. // Bj?rn-Egil From raimo+erlang-patches@REDACTED Mon Apr 29 15:32:26 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 15:32:26 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <410DB75B-3587-41C0-89C4-E5B49E9C5F59@gmail.com> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <20130429130545.GA12647@erix.ericsson.se> <410DB75B-3587-41C0-89C4-E5B49E9C5F59@gmail.com> Message-ID: <20130429133226.GA14490@erix.ericsson.se> On Mon, Apr 29, 2013 at 03:11:44PM +0200, Anthony Ramine wrote: > I don't understand how is that a typo, as "A=<<<1>>" is valid syntax with or without my patch. ...i misread the old arguments; rather that intending to write "A =< << 1 >>" without spaces as "A=<<<1>>" and misspelling to "A=<<1>>" would give no compiler error and unexpected runtime behaviour... > > -- > Anthony Ramine > > Le 29 avr. 2013 ? 15:05, Raimo Niskanen a ?crit : > > > One final straw back then was this: the typo "A=<<<1>>" accidentally > > becomes valid syntax with the proposed change. > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Mon Apr 29 15:39:36 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Apr 2013 15:39:36 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <517E7658.80406@erlang.org> References: <201304291237.r3TCbf8D060343@pluto.hedeland.org> <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> <517E7658.80406@erlang.org> Message-ID: <77617440-4E10-47EE-B678-13405E229683@gmail.com> That would complicate things and introduce more issues than it would fix. It would then be hard to properly parse comparisons of values with binaries. -- Anthony Ramine Le 29 avr. 2013 ? 15:32, Bj?rn-Egil Dahlberg a ?crit : > Would it be more suitable to add '=<<' as a token to erl_scan.erl and then add appropriate grammar to erl_parse.yrl? From raimo+erlang-patches@REDACTED Mon Apr 29 15:48:01 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 15:48:01 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <77617440-4E10-47EE-B678-13405E229683@gmail.com> References: <201304291237.r3TCbf8D060343@pluto.hedeland.org> <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> <517E7658.80406@erlang.org> <77617440-4E10-47EE-B678-13405E229683@gmail.com> Message-ID: <20130429134801.GA15214@erix.ericsson.se> On Mon, Apr 29, 2013 at 03:39:36PM +0200, Anthony Ramine wrote: > That would complicate things and introduce more issues than it would fix. It would then be hard to properly parse comparisons of values with binaries. How come? > > -- > Anthony Ramine > > Le 29 avr. 2013 ? 15:32, Bj?rn-Egil Dahlberg a ?crit : > > > Would it be more suitable to add '=<<' as a token to erl_scan.erl and then add appropriate grammar to erl_parse.yrl? > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From n.oxyde@REDACTED Mon Apr 29 15:50:38 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 29 Apr 2013 15:50:38 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <20130429134801.GA15214@erix.ericsson.se> References: <201304291237.r3TCbf8D060343@pluto.hedeland.org> <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> <517E7658.80406@erlang.org> <77617440-4E10-47EE-B678-13405E229683@gmail.com> <20130429134801.GA15214@erix.ericsson.se> Message-ID: If '=<<' is a token, "A=<<<42>>" is now scanned as 'A' '=<<' '<' '42' '>>', which would fail, even though my patch wouldn't. -- Anthony Ramine Le 29 avr. 2013 ? 15:48, Raimo Niskanen a ?crit : > How come? From raimo+erlang-patches@REDACTED Mon Apr 29 16:09:16 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Mon, 29 Apr 2013 16:09:16 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: <201304291237.r3TCbf8D060343@pluto.hedeland.org> <04F746A9-AE48-44DD-8716-9AE8626A0213@gmail.com> <517E7658.80406@erlang.org> <77617440-4E10-47EE-B678-13405E229683@gmail.com> <20130429134801.GA15214@erix.ericsson.se> Message-ID: <20130429140916.GA15949@erix.ericsson.se> On Mon, Apr 29, 2013 at 03:50:38PM +0200, Anthony Ramine wrote: > If '=<<' is a token, "A=<<<42>>" is now scanned as 'A' '=<<' '<' '42' '>>', which would fail, even though my patch wouldn't. Yes. That seems familiar. Either it was on the argumentation of 2003 or never was out on the list. Having '=<<' as a token meaning '=' '<<' would break the currently valid code "A=<<<42>>". > > -- > Anthony Ramine > > Le 29 avr. 2013 ? 15:48, Raimo Niskanen a ?crit : > > > How come? > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From sverker.eriksson@REDACTED Mon Apr 29 16:22:32 2013 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 29 Apr 2013 16:22:32 +0200 Subject: [erlang-patches] Add 'global' driver option to erl_ddll:try_load/3 In-Reply-To: References: <51497F4C.1030106@erlang.org> <5149EB4C.2070608@erlang.org> <5149EDFD.8040909@erlang.org> <5149F517.7050508@erlang.org> <514C2DC7.40208@erlang.org> <514C8295.80506@erlang.org> <51501E7A.4070000@erlang.org> <515073B9.8020101@erlang.org> Message-ID: <517E8228.9010407@erix.ericsson.se> Olivier Girondel wrote: > This patch enables one to set the RTLD_GLOBAL flag when loading a driver > > What is the use case for the patch? The RTLD_GLOBAL option will enable calls between drivers which is discouraged. From http://www.erlang.org/doc/man/erl_driver.html: "It is assumed that drivers do not access other drivers. If drivers should access each other they have to provide their own mechanism for thread safe synchronization. Such "inter driver communication" is strongly discouraged." Apart from thread safety, doing unloading of drivers in a safe way cannot be guaranteed by the VM if the driver to be unloaded is called by another driver. /Sverker, Erlang/OTP From kostis@REDACTED Mon Apr 29 22:07:48 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 29 Apr 2013 22:07:48 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> Message-ID: <517ED314.90705@cs.ntua.gr> On 04/29/2013 11:41 AM, Anthony Ramine wrote: > Hello Raimo, > > If I read the documentation, I don't see anywhere where it is written that erl_scan is supposed to be greedy. Nor I see any syntax knowledge if we just say that erl_scan will avoid returning two consecutive comparison operators if it can. That is just knowledge that '=<''<' makes no sense, and I can't think of any language where it does. > > Erlang is and has always been pragmatic, letting such an embarrassing syntax wart for the sake of beauty isn't what should be done here, in my opinion. Pragmatism is what allows us to have a nice syntax for specs and callbacks; which wouldn't be possible without an ugly hack too[1]. > > What would break if that patch is accepted? The answer is nothing. I do not have any strong opinion on the issue under discussion but as a bystander I can only state that I see some validity in the arguments of both sides: - In the "pragmatic" argument/stand taken by Anthony and in all the support from poor souls that have been bitten by this language feature. - In the technical argument that says that lexical analyzers implement what's called "maximal munch"[1] when scanning the input from left to right and it would be weird to change and special-case the case where = is immediately followed by < depending on (arbitrary) lookahead. (Aside: on the other hand I find the "this has never bitten me; always put a space there" response, not particularly constructive...) But I also have something technical to add to the discussion: If the patch is to be accepted and some machinery is to be added to the scanner to intelligently break occurrences of =<<, =<<<<, ... into tokens, the same cleverness needs to be introduced to the cases of <<<, <<<<<, ... which currently also result in syntax errors: Eshell V5.10.2 (abort with ^G) 1> 42=<<<42>>. true 2> 42<<<42>>. * 1: syntax error before: '<<' 2> 42< <<42>>. true 3> 42<<<<<42>>/binary>>. * 1: syntax error before: '<<' 3> 42< <<<<42>>/binary>>. true The above is also a side-effect of maximal munch from left to right, which Anthony's current patch does not handle, if I am not mistaken. Otherwise, it would be inconsistent. Kostis [1] http://en.wikipedia.org/wiki/Maximal_munch From n.oxyde@REDACTED Tue Apr 30 10:12:58 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 30 Apr 2013 10:12:58 +0200 Subject: [erlang-patches] Fix some compilation warnings In-Reply-To: <517E26F6.5010103@erlang.org> References: <517E26F6.5010103@erlang.org> Message-ID: <888C16EC-7A35-410B-B2A7-1A609A5CE368@gmail.com> Hello Fredrik, I missed one constant when patching big.c, I amended the related commit; please refetch. Regards, -- Anthony Ramine Le 29 avr. 2013 ? 09:53, Fredrik a ?crit : > On 04/27/2013 01:48 PM, Anthony Ramine wrote: >> Hello, >> >> This branch removes some compilation warnings I noticed while using silent rules. >> >> git fetch https://github.com/nox/otp.git fix-warnings >> >> https://github.com/nox/otp/compare/erlang:maint...fix-warnings >> https://github.com/nox/otp/compare/erlang:maint...fix-warnings.patch >> >> Regards, >> > Hello, > I've fetched your branch and it is now located in the 'pu' branch. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > From fredrik@REDACTED Tue Apr 30 10:12:57 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 30 Apr 2013 10:12:57 +0200 Subject: [erlang-patches] [erlang-bugs] R16A: Small inconvenience with Unicode strings in the shell In-Reply-To: <17102F61-F233-4E8B-8D0D-4038571DD1A3@gmail.com> References: <51098739.8020308@ninenines.eu> <5118C033.5050301@erlang.org> <31E120F8-73EB-4BF3-86AE-CBBC9085E2A1@gmail.com> <17102F61-F233-4E8B-8D0D-4038571DD1A3@gmail.com> Message-ID: <517F7D09.2030306@erlang.org> On 04/27/2013 03:01 PM, Anthony Ramine wrote: > Hello, > > I removed wcwidth from the win32 driver and added an autoconf check for the function presence, please refetch. > > Regards, > Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Apr 30 10:34:34 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 30 Apr 2013 10:34:34 +0200 Subject: [erlang-patches] Fix some compilation warnings In-Reply-To: <888C16EC-7A35-410B-B2A7-1A609A5CE368@gmail.com> References: <517E26F6.5010103@erlang.org> <888C16EC-7A35-410B-B2A7-1A609A5CE368@gmail.com> Message-ID: <517F821A.4040305@erlang.org> On 04/30/2013 10:12 AM, Anthony Ramine wrote: > git fetchhttps://github.com/nox/otp.git fix-warnings Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From n.oxyde@REDACTED Tue Apr 30 11:23:14 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 30 Apr 2013 11:23:14 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <517ED314.90705@cs.ntua.gr> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <517ED314.90705@cs.ntua.gr> Message-ID: <80FE0A84-AE52-4054-A9B2-A9A80F00D74C@gmail.com> Hello Kostis, Do you really think this need to be changed if my patch is accepted? I wanted to fix an ambiguity that surprises people, not an ambiguity nobody encounters. Regards, -- Anthony Ramine Le 29 avr. 2013 ? 22:07, Kostis Sagonas a ?crit : > If the patch is to be accepted and some machinery is to be added to the scanner to intelligently break occurrences of =<<, =<<<<, ... into tokens, the same cleverness needs to be introduced to the cases of <<<, <<<<<, ... which currently also result in syntax errors: > > Eshell V5.10.2 (abort with ^G) > 1> 42=<<<42>>. > true > 2> 42<<<42>>. > * 1: syntax error before: '<<' > 2> 42< <<42>>. > true > 3> 42<<<<<42>>/binary>>. > * 1: syntax error before: '<<' > 3> 42< <<<<42>>/binary>>. > true > > The above is also a side-effect of maximal munch from left to right, which Anthony's current patch does not handle, if I am not mistaken. Otherwise, it would be inconsistent. From erlangsiri@REDACTED Tue Apr 30 12:05:29 2013 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 30 Apr 2013 12:05:29 +0200 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: <517E2012.9030009@erlang.org> References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> Message-ID: We haven't yet made any decision regarding this patch, but we have had some discussions in the team and we are not totally convinced about the general need for this function. Thus we would appreciate some input from the list. So - disregarding the name and the implementation for a second - is this functionality a good addition to the lists module? Is it often needed? If so, would it be even better to do a more general version which removes the N last elements from the list? Hans, could you also possibly describe some of your use cases? Regards siri@REDACTED 2013/4/29 Fredrik > On 04/25/2013 05:12 PM, Hans Svensson wrote: > >> git fetch git://github.com/hanssv/otp.**gitadd_init_to_lists >> > Fetched, it is currently located in the 'pu' branch. > A review process has started. > Thanks, > > -- > > BR Fredrik Gustafsson > Erlang OTP Team > > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Apr 30 12:47:53 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 30 Apr 2013 12:47:53 +0200 Subject: [erlang-patches] Rename and document lists:zf/2 as lists:filtermap/2 Message-ID: <82D1AAB0-1CD5-4F8A-ABBA-3AB745A4E4F9@gmail.com> Hello, I am tired of seeing lists:zf/2 hidden and unused outside of OTP even though it could help in some places, so I decided to rename it to a more useful name and document it. git fetch https://github.com/nox/otp.git lists-filtermap https://github.com/nox/otp/compare/erlang:maint...lists-filtermap https://github.com/nox/otp/compare/erlang:maint...lists-filtermap.patch Regards, -- Anthony Ramine From fredrik@REDACTED Tue Apr 30 14:24:37 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 30 Apr 2013 14:24:37 +0200 Subject: [erlang-patches] Rename and document lists:zf/2 as lists:filtermap/2 In-Reply-To: <82D1AAB0-1CD5-4F8A-ABBA-3AB745A4E4F9@gmail.com> References: <82D1AAB0-1CD5-4F8A-ABBA-3AB745A4E4F9@gmail.com> Message-ID: <517FB805.1010000@erlang.org> On 04/30/2013 12:47 PM, Anthony Ramine wrote: > Hello, > > I am tired of seeing lists:zf/2 hidden and unused outside of OTP even though it could help in some places, so I decided to rename it to a more useful name and document it. > > git fetch https://github.com/nox/otp.git lists-filtermap > > https://github.com/nox/otp/compare/erlang:maint...lists-filtermap > https://github.com/nox/otp/compare/erlang:maint...lists-filtermap.patch > > Regards, > Hello Anthony, A review process regarding this issue has started. I've fetched your patch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From g@REDACTED Tue Apr 30 15:32:22 2013 From: g@REDACTED (Garrett Smith) Date: Tue, 30 Apr 2013 08:32:22 -0500 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> Message-ID: I would use lists:sublist(L, 1, length(L) - 1) for this. I wouldn't have given it a second thought. Presumably there's a concern about performance -- why else would we need yet-another-function? Here's a simple benchmark program that people can experiment with (or improve): https://github.com/gar1t/erlang-bench/blob/master/drop-last.escript It includes the original implementation, Fred's, and what I would use (sublist). Personally, I don't see a problem that warrants a new function in the lists module. On Tue, Apr 30, 2013 at 5:05 AM, Siri Hansen wrote: > We haven't yet made any decision regarding this patch, but we have had some > discussions in the team and we are not totally convinced about the general > need for this function. Thus we would appreciate some input from the list. > > So - disregarding the name and the implementation for a second - is this > functionality a good addition to the lists module? Is it often needed? > > If so, would it be even better to do a more general version which removes > the N last elements from the list? > > Hans, could you also possibly describe some of your use cases? > > Regards > siri@REDACTED > > > 2013/4/29 Fredrik >> >> On 04/25/2013 05:12 PM, Hans Svensson wrote: >>> >>> git fetch git://github.com/hanssv/otp.git add_init_to_lists >> >> Fetched, it is currently located in the 'pu' branch. >> A review process has started. >> Thanks, >> >> -- >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From kostis@REDACTED Tue Apr 30 18:23:59 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 30 Apr 2013 18:23:59 +0200 Subject: [erlang-patches] Scan "=<<" as something useful In-Reply-To: <80FE0A84-AE52-4054-A9B2-A9A80F00D74C@gmail.com> References: <20130429085342.GA7639@erix.ericsson.se> <20130429091833.GA8431@erix.ericsson.se> <517ED314.90705@cs.ntua.gr> <80FE0A84-AE52-4054-A9B2-A9A80F00D74C@gmail.com> Message-ID: <517FF01F.3070400@cs.ntua.gr> On 04/30/2013 11:23 AM, Anthony Ramine wrote: > Hello Kostis, > > Do you really think this need to be changed if my patch is accepted? I wanted to fix an ambiguity that surprises people, not an ambiguity nobody encounters. I think I made it pretty clear that I think that the breaking of <<< into tokens should also be changed in a similar way. Granted this case might surprise less people, but I tend to prefer technical arguments rather than "suprise" ones. Technically the issues involved in how to break =<< vs <<< into tokens are very very similar if not the same as far as erl_scan is concerned -- and are unrelated to people's surprise level. Kostis From freza@REDACTED Tue Apr 30 19:08:45 2013 From: freza@REDACTED (Jachym Holecek) Date: Tue, 30 Apr 2013 13:08:45 -0400 Subject: [erlang-patches] Add lists:init/1 - got tired of implementing it In-Reply-To: References: <517947E4.2040504@gmail.com> <517E2012.9030009@erlang.org> Message-ID: <20130430170844.GA5664@circlewave.net> # Siri Hansen 2013-04-30: > We haven't yet made any decision regarding this patch, but we have had some > discussions in the team and we are not totally convinced about the general > need for this function. Thus we would appreciate some input from the list. > > So - disregarding the name and the implementation for a second - is this > functionality a good addition to the lists module? Is it often needed? Personally: no, not that I recall. My first thought upon seeing it (leaving naming aside) was that somebody was using a plain list where they really needed a queue(3) (or some more appropriate data structure, don't know what the actual use case is). BR, -- Jachym