From fredrik@REDACTED Wed Jan 2 10:03:48 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 2 Jan 2013 10:03:48 +0100 Subject: [erlang-patches] Add RIPEMD160 digest support to crypto In-Reply-To: References: <50D185C7.60805@erlang.org> <50D43F4C.7070205@erlang.org> Message-ID: <50E3F7F4.7000800@erlang.org> Hello Michael! I have re-fetched and it is now again in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 12/21/2012 07:38 PM, Michael Loftis wrote: > I added the ripemd160 atom to the documentation, removed the exports, > and added the bits to the hash and hash_init family....There's a > info/0 function that returns ?FUNC_LIST -- and I'm actually not clear > on it's use/behavior, but it appears that it is intended to indicate > exported crypto functions, so I've omitted the now non-exported > functions from that define. Hopefully this is right, as this appears > to be the first "example" of a hash only function. > > > On Fri, Dec 21, 2012 at 2:51 AM, Fredrik > wrote: > > Hello Michael! > The patch has been into review and the feedback: > " > > New functions hash,hash_init,hash_update,hash_final has been added > in master for R16. You should use them instead and not export your > ripemd160 functions. > > Documentation is missing." > > Please fix this and I will fetch again. > > > BR Fredrik Gustafsson > Erlang OTP Team > > On 12/19/2012 07:05 PM, Michael Loftis wrote: >> Entirely my fault, I missed two #define's when I moved the patch >> from the crypto module I forked back at R13 back into the R15 >> source. I only got R15 to compile today, R15 and my javac do not >> get along (but I don't use any of that anyway). >> >> I've updated the github repo, same branch. >> >> >> https://github.com/mloftis/otp/compare/master-pu...crypto-add-ripemd160-digest >> https://github.com/mloftis/otp/compare/master-pu...crypto-add-ripemd160-digest.patch >> >> git fetch git://github.com/mloftis/otp.git >> crypto-add-ripemd160-digest >> >> >> >> On Wed, Dec 19, 2012 at 1:15 AM, Fredrik > > wrote: >> >> Hello Michael, >> It does not build: >> crypto.c: In function ?ripemd160?: >> crypto.c:621:28: error: ?RIPEMD160_LEN? undeclared (first use >> in this function) >> crypto.c:621:28: note: each undeclared identifier is reported >> only once for each function it appears in >> crypto.c: In function ?ripemd160_init?: >> crypto.c:627:64: error: ?RIPEMD160_CTX_LEN? undeclared (first >> use in this function) >> crypto.c: In function ?ripemd160_update?: >> crypto.c:636:22: error: ?RIPEMD160_CTX_LEN? undeclared (first >> use in this function) >> crypto.c: In function ?ripemd160_final?: >> crypto.c:650:73: error: ?RIPEMD160_CTX_LEN? undeclared (first >> use in this function) >> crypto.c:654:47: error: ?RIPEMD160_LEN? undeclared (first use >> in this function) >> >> Please take a look at this and give me a notice. >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 12/18/2012 11:10 PM, Michael Loftis wrote: >>> Apologies, done... >>> >>> https://github.com/mloftis/otp/compare/master...crypto-add-ripemd160-digest >>> https://github.com/mloftis/otp/compare/master...crypto-add-ripemd160-digest.patch >>> >>> git fetch git://github.com/mloftis/otp.git >>> crypto-add-ripemd160-digest >>> >>> >>> >>> >>> On Tue, Dec 18, 2012 at 1:45 PM, Tuncer Ayaz >>> > wrote: >>> >>> On Tue, Dec 18, 2012 at 10:35 PM, Michael Loftis wrote: >>> > >>> > Add ripemd160 digest support to crypto. Includes a >>> couple test >>> > cases. >>> > >>> > >>> > git fetch git://github.com/mloftis/otp.git >>> >>> crypto-add-ripemd160-digest >>> > >>> > This is based off of master-pu as of a few moments >>> ago, my read of >>> > the requirements tells me that should be the correct >>> spot since I'm >>> > adding a new feature to the crypto module. >>> >>> A patch for 'master-pu' has to be based off 'master'. >>> >>> > Not fully tested with the current erlang since >>> jinterface has >>> > completely broken my build on all platforms -- even if >>> it is >>> > disabled it still kills my build on most platforms >>> because it's >>> > using sh with scripts that have bash semantics. Might >>> have a chance >>> > to clean up that separate issue today and submit patches. >>> >>> >>> >>> >>> -- >>> >>> "Genius might be described as a supreme capacity for getting >>> its possessors >>> into trouble of all kinds." >>> -- Samuel Butler >>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> >> >> >> -- >> >> "Genius might be described as a supreme capacity for getting its >> possessors >> into trouble of all kinds." >> -- Samuel Butler >> > > > > > -- > > "Genius might be described as a supreme capacity for getting its > possessors > into trouble of all kinds." > -- Samuel Butler -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Wed Jan 2 10:19:54 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 2 Jan 2013 10:19:54 +0100 Subject: [erlang-patches] Shell history search In-Reply-To: <20121222224128.GA941@ferdmbp.local> References: <20121222224128.GA941@ferdmbp.local> Message-ID: <50E3FBBA.6050208@erlang.org> Hello Fred, I have included your patch in the 'master-pu' branch. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 12/22/2012 11:41 PM, Fred Hebert wrote: > git fetch git://github.com/ferd/otp.git shell_history_search From fredrik@REDACTED Wed Jan 2 10:32:47 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 2 Jan 2013 10:32:47 +0100 Subject: [erlang-patches] Selectively receive system messages in gen_server and gen_fsm In-Reply-To: References: Message-ID: <50E3FEBF.1080508@erlang.org> Hello Pedram! I have included your patch in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 12/26/2012 04:35 PM, Pedram Nimreezi wrote: > git fetch git://github.com/DeadZen/otp.git system-selective-receive From ulf@REDACTED Wed Jan 2 11:13:36 2013 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 2 Jan 2013 11:13:36 +0100 Subject: [erlang-patches] Selectively receive system messages in gen_server and gen_fsm In-Reply-To: References: Message-ID: The optimizations cannot kick in here*, and I don't see that using selective receive in this case even makes a difference. Given that each receive clause has a catch-all clause, the first message in the queue will always match, which is arguably the way it should be (and must be, for backward compatibility reasons if nothing else). Thus, there is no need for the optimization, which serves to avoid scanning all messages in a possibly very long message queue. BR, Ulf W * The trick of the optimization is that if a unique reference is created *in the same scope* and just before the receive statement, the compiler can mark the end of the message queue and jump right to it - but only if the receive clauses all pattern-match on the newly created unique reference. Here, there is no such reference, and the receive statement contains a catch-all. On 26 Dec 2012, at 16:35, Pedram Nimreezi wrote: > The gen_server and gen_fsm modules do not selectively receive system messages. > > This commit addresses that and allows for them to be consistent with gen_event, > as well as possibly taking advantage of the recent improvements to > selective receive. > > https://github.com/DeadZen/otp/compare/maint...system-selective-receive > https://github.com/DeadZen/otp/compare/maint...system-selective-receive.patch > > git fetch git://github.com/DeadZen/otp.git system-selective-receive > > Supplemental Questions... > 1. I believe, but I am not sure if the selective receive call > optimization triggers... seems like it should. > 2. I see that gen_event does do a selective receive, and I believe > this is more correct.. is that true? > https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_event.erl#L231 > <- does > https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_fsm.erl#L424 > <- does not > https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_server.erl#L374 > <- does not > 3. Is gen_event a more recent erlang behaviour than gen_server and gen_fsm? > > > > -- > /* 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 Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From fredrik@REDACTED Fri Jan 4 09:07:54 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 4 Jan 2013 09:07:54 +0100 Subject: [erlang-patches] Shell history search In-Reply-To: <20121222224128.GA941@ferdmbp.local> References: <20121222224128.GA941@ferdmbp.local> Message-ID: <50E68DDA.7080803@erlang.org> Hello Fred, Must have missed to reply to you, your patch has been in 'master-pu' branch since wednesday. Thanks for your contribution. BR Fredrik Gustafsson Erlang OTP Team On 12/22/2012 11:41 PM, Fred Hebert wrote: > Hi, the following patch adds functionality to group.erl and edlin.erl in > order to allow the user to search history. > > Search mode can be entered by pressing ctrl-r. Enter terms and press > ctrl-r again to search backwards, or ctrl-s to then search forward (if > you terminal doesn't eat up that one). Press enter to execute the line, > or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to > exit search mode while remaining on the last found line. > > The search mode is a simpler version of the one available in bash or > zsh shells. > > This adds a few modes to the shell (search, on top of none and meta) in > group.erl for history search, and a few more in edlin.erl to change the > meaning of control sequences while searching. > > This patch has been tested on OSX and some linux variants and worked > fine. > I tested it on Windows, and neither do werl.exe, or erl.exe (under > PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not > work there, but will not break any existing functionality. As far as I'm > aware, this is more likely a driver issue than an issue with the patch > (^G is not captured in cmd.exe, ctrl+C works in none of the above, for > example). > > git fetch git://github.com/ferd/otp.git shell_history_search > > Compare at: > > https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search > https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch > > Regards, > Fred. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Fri Jan 4 09:08:50 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 4 Jan 2013 09:08:50 +0100 Subject: [erlang-patches] Selectively receive system messages in gen_server and gen_fsm In-Reply-To: References: Message-ID: <50E68E12.3030401@erlang.org> Hello Pedram, must have missed reply to you, your patch has been in the 'master-pu' branch since wednesday. Thanks for your contribution, BR Fredrik Gustafsson Erlang OTP Team On 12/26/2012 04:35 PM, Pedram Nimreezi wrote: > The gen_server and gen_fsm modules do not selectively receive system messages. > > This commit addresses that and allows for them to be consistent with gen_event, > as well as possibly taking advantage of the recent improvements to > selective receive. > > https://github.com/DeadZen/otp/compare/maint...system-selective-receive > https://github.com/DeadZen/otp/compare/maint...system-selective-receive.patch > > git fetch git://github.com/DeadZen/otp.git system-selective-receive > > Supplemental Questions... > 1. I believe, but I am not sure if the selective receive call > optimization triggers... seems like it should. > 2. I see that gen_event does do a selective receive, and I believe > this is more correct.. is that true? > https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_event.erl#L231 > <- does > https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_fsm.erl#L424 > <- does not > https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_server.erl#L374 > <- does not > 3. Is gen_event a more recent erlang behaviour than gen_server and gen_fsm? > > > From pan@REDACTED Mon Jan 7 11:48:17 2013 From: pan@REDACTED (Patrik Nyblom) Date: Mon, 7 Jan 2013 11:48:17 +0100 Subject: [erlang-patches] Selectively receive system messages in gen_server and gen_fsm In-Reply-To: References: Message-ID: <50EAA7F1.2030201@erlang.org> You're absolutely right, the optimization can kick in on the client side, not on the server side. The server handles messages in order of arrival. The change is mute, the messages will still be handled in order, so the patch should be withdrawn. To clarify: Selective receive kicks in (as Ulf explained) only if there no catch-all. Each message is conceptually matched against *the whole* receive clause before moving on to the next message in the queue. A catch-all always matches the first message, so there will be no "selective receive" or rather, the "selective receive" will select the first matching message, which is always the first message. As Ulf also pointed out, system messaages should also be handled in-order, that should not be changed, as for example code change is a system message that shall not be reordered. Cheers, /Patrik On 01/02/2013 11:13 AM, Ulf Wiger wrote: > The optimizations cannot kick in here*, and I don't see that using selective receive in this case even makes a difference. Given that each receive clause has a catch-all clause, the first message in the queue will always match, which is arguably the way it should be (and must be, for backward compatibility reasons if nothing else). Thus, there is no need for the optimization, which serves to avoid scanning all messages in a possibly very long message queue. > > BR, > Ulf W > > * The trick of the optimization is that if a unique reference is created *in the same scope* and just before the receive statement, the compiler can mark the end of the message queue and jump right to it - but only if the receive clauses all pattern-match on the newly created unique reference. Here, there is no such reference, and the receive statement contains a catch-all. > > On 26 Dec 2012, at 16:35, Pedram Nimreezi wrote: > >> The gen_server and gen_fsm modules do not selectively receive system messages. >> >> This commit addresses that and allows for them to be consistent with gen_event, >> as well as possibly taking advantage of the recent improvements to >> selective receive. >> >> https://github.com/DeadZen/otp/compare/maint...system-selective-receive >> https://github.com/DeadZen/otp/compare/maint...system-selective-receive.patch >> >> git fetch git://github.com/DeadZen/otp.git system-selective-receive >> >> Supplemental Questions... >> 1. I believe, but I am not sure if the selective receive call >> optimization triggers... seems like it should. >> 2. I see that gen_event does do a selective receive, and I believe >> this is more correct.. is that true? >> https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_event.erl#L231 >> <- does >> https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_fsm.erl#L424 >> <- does not >> https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_server.erl#L374 >> <- does not >> 3. Is gen_event a more recent erlang behaviour than gen_server and gen_fsm? >> >> >> >> -- >> /* 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 > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Mon Jan 7 15:29:49 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 7 Jan 2013 15:29:49 +0100 Subject: [erlang-patches] [patch] small correction to cover html output In-Reply-To: <50C886A3.4030106@erlang.org> References: <50C886A3.4030106@erlang.org> Message-ID: <50EADBDD.3000105@erlang.org> Hello Philip, Your patch has been into review and the response was: "This functionality is modified for R16 when introducing more unicode support. We have done similar (equivalent) changes there and will therefore not take this patch." Thanks anyway for taking time to write this patch and keep contributing to Erlang/OTP BR Fredrik Gustafsson Erlang OTP Team On 12/12/2012 02:29 PM, Henrik Nord wrote: > Hello > I have added your patch to 'master-pu' > > I would also like to point out that there are instructions for sending > in patches here: > https://github.com/erlang/otp/wiki/Submitting-patches > > as we would like you to include a git fetch ulr as well as a preview url > > as such: > git fetch https://github.com/exterm/otp correct_cover_html > > https://github.com/exterm/otp/compare/correct_cover_html > https://github.com/exterm/otp/compare/correct_cover_html.patch > > > Thank you for your contribution! > > > On 12/12/2012 01:37 PM, Philip M?ller wrote: >> Hi everyone, >> >> somehow it bugged my that the cover html output isn't valid html. >> >> So I made this little patch: >> >> https://github.com/exterm/otp/commit/1cf989f81bd4299270416815d899974950a72ce1 >> >> >> I would be most humbled should it be accepted. >> >> Best regards >> Philip >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From mc@REDACTED Mon Jan 7 18:02:14 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Mon, 7 Jan 2013 12:02:14 -0500 Subject: [erlang-patches] Selectively receive system messages in gen_server and gen_fsm In-Reply-To: <50EAA7F1.2030201@erlang.org> References: <50EAA7F1.2030201@erlang.org> Message-ID: Good points, and I of course do not disagree, however, the purpose of this patch was to begin this discussion. I'd like to get some info and possibly see how a couple of things could be addressed.. And Thank you for bringing up the code change point. I agree that particular case should happen in the order in which it is received. However, a few questions, that I'm pondering are: - Why is gen_event already in the format that I've patched gen_fsm and gen_server to be in. (this seems inconsistent, is there a reason?) - Would it make sense to allow?at least get_status system messages to have priority, ie: so inspection is not impeded by queue size. - Could it make sense for a process to have two queues, to separate system messages into its own queue.. - When you say catch all, does that mean the first pattern matches are irrelevant for selective receive if the last match is a catch all, does this implicitly invalidate the selective receive optimization? - Is it the intention of sys:get_status to only work when an OTP process is unencumbered with a pretty small message queue and why? - When I look at yes_5.erl and do a beam_disasm:file on that code, as well as on gen.erl, (as well as copying yes_5 into some test gen_server) doing a call(?MODULE, system, get_status) I see recv_mark's/recv_sets showing that at least the monitor/gen:call semantics have the selective receive optimization, could this be extended to get_status? ----- I do believe it is important to maintain the ability to inspect the state of an OTP process, be consistent while maintaining backwards compatibility.. I'm willing to work on this more and understand it may not be an easy or even completely valid issue, but somethings didn't add up, and I figured I'd put the issue on the table. Thank you for the consideration On Mon, Jan 7, 2013 at 5:48 AM, Patrik Nyblom wrote: > You're absolutely right, the optimization can kick in on the client side, > not on the server side. The server handles messages in order of arrival. > > The change is mute, the messages will still be handled in order, so the > patch should be withdrawn. > > To clarify: Selective receive kicks in (as Ulf explained) only if there no > catch-all. Each message is conceptually matched against *the whole* receive > clause before moving on to the next message in the queue. A catch-all always > matches the first message, so there will be no "selective receive" or > rather, the "selective receive" will select the first matching message, > which is always the first message. As Ulf also pointed out, system messaages > should also be handled in-order, that should not be changed, as for example > code change is a system message that shall not be reordered. > > Cheers, > /Patrik > > > On 01/02/2013 11:13 AM, Ulf Wiger wrote: >> >> The optimizations cannot kick in here*, and I don't see that using >> selective receive in this case even makes a difference. Given that each >> receive clause has a catch-all clause, the first message in the queue will >> always match, which is arguably the way it should be (and must be, for >> backward compatibility reasons if nothing else). Thus, there is no need for >> the optimization, which serves to avoid scanning all messages in a possibly >> very long message queue. >> >> BR, >> Ulf W >> >> * The trick of the optimization is that if a unique reference is created >> *in the same scope* and just before the receive statement, the compiler can >> mark the end of the message queue and jump right to it - but only if the >> receive clauses all pattern-match on the newly created unique reference. >> Here, there is no such reference, and the receive statement contains a >> catch-all. >> >> On 26 Dec 2012, at 16:35, Pedram Nimreezi wrote: >> >>> The gen_server and gen_fsm modules do not selectively receive system >>> messages. >>> >>> This commit addresses that and allows for them to be consistent with >>> gen_event, >>> as well as possibly taking advantage of the recent improvements to >>> selective receive. >>> >>> >>> https://github.com/DeadZen/otp/compare/maint...system-selective-receive >>> >>> https://github.com/DeadZen/otp/compare/maint...system-selective-receive.patch >>> >>> git fetch git://github.com/DeadZen/otp.git system-selective-receive >>> >>> Supplemental Questions... >>> 1. I believe, but I am not sure if the selective receive call >>> optimization triggers... seems like it should. >>> 2. I see that gen_event does do a selective receive, and I believe >>> this is more correct.. is that true? >>> >>> https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_event.erl#L231 >>> <- does >>> >>> https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_fsm.erl#L424 >>> <- does not >>> >>> https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_server.erl#L374 >>> <- does not >>> 3. Is gen_event a more recent erlang behaviour than gen_server and >>> gen_fsm? >>> >>> >>> >>> -- >>> /* 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 >> >> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. >> http://feuerlabs.com >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From jesper.louis.andersen@REDACTED Mon Jan 7 19:03:07 2013 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 7 Jan 2013 19:03:07 +0100 Subject: [erlang-patches] Selectively receive system messages in gen_server and gen_fsm In-Reply-To: References: <50EAA7F1.2030201@erlang.org> Message-ID: On Mon, Jan 7, 2013 at 6:02 PM, Pedram Nimreezi wrote: > - When you say catch all, does that mean the first pattern matches are > irrelevant for selective receive if the last match is a catch all, > does this implicitly invalidate the selective receive optimization? > Suppose you have patterns P1 and P2 and Messages M1 and M2 in that order in the mailbox and receive clause. Let PmM mean match pattern P against message M. Now two orders are possible: A: P1mM1 P2mM1 P1mM2 P2mM2 and B: P1mM1 P1mM2 P2mM1 P2mM2 Erlang uses A as the match style, so if P1 or P2 is a catch all, M1 will always be picked before M2. Had Elrang used match style B then the order would matter, but it doesn't. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kino@REDACTED Tue Jan 8 02:12:48 2013 From: kino@REDACTED (satoshi kinoshita) Date: Tue, 08 Jan 2013 10:12:48 +0900 Subject: [erlang-patches] odbcserver.c 64bit support In-Reply-To: <50BC8F7A.6080209@erlang.org> References: <50BC8F7A.6080209@erlang.org> Message-ID: At Mon, 3 Dec 2012 12:39:38 +0100, Henrik Nord wrote: > > > On 11/29/2012 08:22 AM, satoshi kinoshita wrote: > > I found antoher 64bit related bug in odbcserver.c. > > It affects only param_query for stored-procedure > > with OUT parameter of SQL_C_SLONG type. > Can you add a testcase for this problem? Is there any document to run test cases for odbcserver? I'd like to run existing test cases first and then add some new cases for this 64bit issue. thanks, kinoshita From fredrik@REDACTED Tue Jan 8 11:06:56 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 8 Jan 2013 11:06:56 +0100 Subject: [erlang-patches] Shell history search In-Reply-To: <50E68DDA.7080803@erlang.org> References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> Message-ID: <50EBEFC0.7040101@erlang.org> Hello Fred, You need to rebase upon 'master' branch and make changes to your patch, it fails to build on 'group.erl:536: function prompt_bytes/1 undefined' Let me know when you are done, BR Fredrik Gustafsson Erlang OTP Team On 01/04/2013 09:07 AM, Fredrik wrote: > Hello Fred, > Must have missed to reply to you, your patch has been in 'master-pu' > branch since wednesday. > Thanks for your contribution. > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/22/2012 11:41 PM, Fred Hebert wrote: >> Hi, the following patch adds functionality to group.erl and edlin.erl in >> order to allow the user to search history. >> >> Search mode can be entered by pressing ctrl-r. Enter terms and press >> ctrl-r again to search backwards, or ctrl-s to then search forward (if >> you terminal doesn't eat up that one). Press enter to execute the line, >> or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to >> exit search mode while remaining on the last found line. >> >> The search mode is a simpler version of the one available in bash or >> zsh shells. >> >> This adds a few modes to the shell (search, on top of none and meta) in >> group.erl for history search, and a few more in edlin.erl to change the >> meaning of control sequences while searching. >> >> This patch has been tested on OSX and some linux variants and worked >> fine. >> I tested it on Windows, and neither do werl.exe, or erl.exe (under >> PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not >> work there, but will not break any existing functionality. As far as I'm >> aware, this is more likely a driver issue than an issue with the patch >> (^G is not captured in cmd.exe, ctrl+C works in none of the above, for >> example). >> >> git fetch git://github.com/ferd/otp.git shell_history_search >> >> Compare at: >> >> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search >> >> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch >> >> >> Regards, >> Fred. >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From fdmanana@REDACTED Tue Jan 8 11:46:58 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Tue, 8 Jan 2013 10:46:58 +0000 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: References: Message-ID: Any reason for no feedback on this submission? It's quite critical imho, it affects all file:open/2 calls that specify the 'compressed' option, even for files that are not compressed. For example, file_sorter always opens file with the 'compressed' option, and shutting down a process that uses it, leads to these crashes when using the async thread pool. Thanks. On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana wrote: > https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch > https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash > > git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From fredrik@REDACTED Tue Jan 8 11:54:09 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 8 Jan 2013 11:54:09 +0100 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: References: Message-ID: <50EBFAD1.4040103@erlang.org> Hello Filipe! I'm sorry for the delay, Your patch is now in the 'master-pu' branch. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/08/2013 11:46 AM, Filipe David Manana wrote: > Any reason for no feedback on this submission? It's quite critical > imho, it affects all file:open/2 calls that specify the 'compressed' > option, even for files that are not compressed. For example, > file_sorter always opens file with the 'compressed' option, and > shutting down a process that uses it, leads to these crashes when > using the async thread pool. > > Thanks. > > On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana wrote: >> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch >> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash >> >> git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." > > From mononcqc@REDACTED Tue Jan 8 13:49:37 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 8 Jan 2013 07:49:37 -0500 Subject: [erlang-patches] Shell history search In-Reply-To: <50EBEFC0.7040101@erlang.org> References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> <50EBEFC0.7040101@erlang.org> Message-ID: <20130108124936.GA25258@ferdmbp.local> Hi Fredrik, It's done. From my understanding of the code, I simply needed to pass in the encoding to the prompt_bytes/2 functions, and it seems to work fine. Regards, Fred. On 01/08, Fredrik wrote: > Hello Fred, > You need to rebase upon 'master' branch and make changes to your > patch, it fails to build on > 'group.erl:536: function prompt_bytes/1 undefined' > > Let me know when you are done, > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/04/2013 09:07 AM, Fredrik wrote: > >Hello Fred, > >Must have missed to reply to you, your patch has been in > >'master-pu' branch since wednesday. > >Thanks for your contribution. > > > >BR Fredrik Gustafsson > >Erlang OTP Team > >On 12/22/2012 11:41 PM, Fred Hebert wrote: > >>Hi, the following patch adds functionality to group.erl and edlin.erl in > >>order to allow the user to search history. > >> > >>Search mode can be entered by pressing ctrl-r. Enter terms and press > >>ctrl-r again to search backwards, or ctrl-s to then search forward (if > >>you terminal doesn't eat up that one). Press enter to execute the line, > >>or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to > >>exit search mode while remaining on the last found line. > >> > >>The search mode is a simpler version of the one available in bash or > >>zsh shells. > >> > >>This adds a few modes to the shell (search, on top of none and meta) in > >>group.erl for history search, and a few more in edlin.erl to change the > >>meaning of control sequences while searching. > >> > >>This patch has been tested on OSX and some linux variants and worked > >>fine. > >>I tested it on Windows, and neither do werl.exe, or erl.exe (under > >>PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not > >>work there, but will not break any existing functionality. As far as I'm > >>aware, this is more likely a driver issue than an issue with the patch > >>(^G is not captured in cmd.exe, ctrl+C works in none of the above, for > >>example). > >> > >>git fetch git://github.com/ferd/otp.git shell_history_search > >> > >>Compare at: > >> > >>https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search > >> > >>https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch > >> > >> > >>Regards, > >>Fred. > >>_______________________________________________ > >>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 fredrik@REDACTED Tue Jan 8 14:06:15 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 8 Jan 2013 14:06:15 +0100 Subject: [erlang-patches] Shell history search In-Reply-To: <20130108124936.GA25258@ferdmbp.local> References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> <50EBEFC0.7040101@erlang.org> <20130108124936.GA25258@ferdmbp.local> Message-ID: <50EC19C7.90507@erlang.org> Great, I have re-fetched and building it in master-pu branch now. Thanks! BR Fredrik Gustafsson Erlang OTP Team On 01/08/2013 01:49 PM, Fred Hebert wrote: > Hi Fredrik, > > It's done. From my understanding of the code, I simply needed to pass in > the encoding to the prompt_bytes/2 functions, and it seems to work fine. > > Regards, > Fred. > > On 01/08, Fredrik wrote: >> Hello Fred, >> You need to rebase upon 'master' branch and make changes to your >> patch, it fails to build on >> 'group.erl:536: function prompt_bytes/1 undefined' >> >> Let me know when you are done, >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/04/2013 09:07 AM, Fredrik wrote: >>> Hello Fred, >>> Must have missed to reply to you, your patch has been in >>> 'master-pu' branch since wednesday. >>> Thanks for your contribution. >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/22/2012 11:41 PM, Fred Hebert wrote: >>>> Hi, the following patch adds functionality to group.erl and edlin.erl in >>>> order to allow the user to search history. >>>> >>>> Search mode can be entered by pressing ctrl-r. Enter terms and press >>>> ctrl-r again to search backwards, or ctrl-s to then search forward (if >>>> you terminal doesn't eat up that one). Press enter to execute the line, >>>> or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to >>>> exit search mode while remaining on the last found line. >>>> >>>> The search mode is a simpler version of the one available in bash or >>>> zsh shells. >>>> >>>> This adds a few modes to the shell (search, on top of none and meta) in >>>> group.erl for history search, and a few more in edlin.erl to change the >>>> meaning of control sequences while searching. >>>> >>>> This patch has been tested on OSX and some linux variants and worked >>>> fine. >>>> I tested it on Windows, and neither do werl.exe, or erl.exe (under >>>> PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not >>>> work there, but will not break any existing functionality. As far as I'm >>>> aware, this is more likely a driver issue than an issue with the patch >>>> (^G is not captured in cmd.exe, ctrl+C works in none of the above, for >>>> example). >>>> >>>> git fetch git://github.com/ferd/otp.git shell_history_search >>>> >>>> Compare at: >>>> >>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search >>>> >>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch >>>> >>>> >>>> Regards, >>>> Fred. >>>> _______________________________________________ >>>> 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 magnus@REDACTED Tue Jan 8 19:50:27 2013 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 08 Jan 2013 18:50:27 +0000 Subject: [erlang-patches] escript to accept emulator flags in scripts without shebang Message-ID: The documentation for escript says that if the second or third line of the script starts with %%!, the rest of the line will be used as emulator arguments. However, currently this is only the case if the first line starts with #!. I couldn't see any reason for that, so here is a patch that removes this undocumented limitation. git fetch git://github.com/legoscia/otp.git escript_emulator_flags_vs_shebang https://github.com/legoscia/otp/compare/erlang:master...legoscia:escript_emulator_flags_vs_shebang https://github.com/legoscia/otp/compare/erlang:master...legoscia:escript_emulator_flags_vs_shebang.patch Regards, Magnus From alevandal@REDACTED Wed Jan 9 09:53:16 2013 From: alevandal@REDACTED (Kernel Panic) Date: Wed, 9 Jan 2013 16:53:16 +0800 Subject: [erlang-patches] Patch for ODBC module Message-ID: Hi, folks. I created a patch for erlang odbc module which solves the problem with setup autocommit mode for connections established by Oracle ODBC driver in Linux. The issue: Oracle ODBC driver for Linux ignores setup autocommit mode during driver initialization before a connection to database has been established (in odbc module autocommit is set this way). My patch solves this problem by setting autocommit mode after a connection to database has been established. Actually it's an Oracle ODBC driver problem, but it could be very useful to add this fix to erlang odbc module, because this module allow to set autocommit mode only at the moment of connection creation. I sent this patch earlier in October 2012 but I didn't receive any feedback. My updates: git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch Danil Onishchenko, alevandal@REDACTED From alevandal@REDACTED Wed Jan 9 10:29:27 2013 From: alevandal@REDACTED (Kernel Panic) Date: Wed, 9 Jan 2013 17:29:27 +0800 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 Message-ID: A little patch for odbc:param_query/3 and odbc:param_query/4. Issue: Calling odbc:param_query/3 and odbc:param_query/4 with unparameterized query string and empty parameters list causes error in pattern matching in function param_values/1. This patch fixes this problem and allow to do things such as odbc:param_query(ConRef, "select * from some_table", []). git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params https://github.com/RubberCthulhu/otp/compare/odbc-empty-params https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch From fredrik@REDACTED Wed Jan 9 11:41:09 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 9 Jan 2013 11:41:09 +0100 Subject: [erlang-patches] Patch for ODBC module In-Reply-To: References: Message-ID: <50ED4945.9060907@erlang.org> Hello Kernel! Your patch is now cooking in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 01/09/2013 09:53 AM, Kernel Panic wrote: > Hi, folks. > I created a patch for erlang odbc module which solves the problem with > setup autocommit mode for connections established by Oracle ODBC > driver in Linux. > The issue: Oracle ODBC driver for Linux ignores setup autocommit mode > during driver initialization before a connection to database has been > established (in odbc module autocommit is set this way). My patch > solves this problem by setting autocommit mode after a connection to > database has been established. > Actually it's an Oracle ODBC driver problem, but it could be very > useful to add this fix to erlang odbc module, because this module > allow to set autocommit mode only at the moment of connection > creation. > I sent this patch earlier in October 2012 but I didn't receive any feedback. > > My updates: > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix > > https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix > https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch > > Danil Onishchenko, alevandal@REDACTED > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Wed Jan 9 11:44:12 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 9 Jan 2013 11:44:12 +0100 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 In-Reply-To: References: Message-ID: <50ED49FC.8060106@erlang.org> Hello Kernel! Your patch is now cooking in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 01/09/2013 10:29 AM, Kernel Panic wrote: > A little patch for odbc:param_query/3 and odbc:param_query/4. > > Issue: Calling odbc:param_query/3 and odbc:param_query/4 with > unparameterized query string and empty parameters list causes error in > pattern matching in function param_values/1. > > This patch fixes this problem and allow to do things such as > odbc:param_query(ConRef, "select * from some_table", []). > > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params > > https://github.com/RubberCthulhu/otp/compare/odbc-empty-params > https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Wed Jan 9 13:37:15 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 9 Jan 2013 13:37:15 +0100 Subject: [erlang-patches] Patch for ODBC module In-Reply-To: References: Message-ID: <50ED647B.6000705@erlang.org> Hello again, This patch fails to build: " odbcserver.c: In function ?db_connect?: odbcserver.c:538:2: error: too few arguments to function ?get_diagnos? odbcserver.c:250:16: note: declared here odbcserver.c:541:2: error: too few arguments to function ?encode_error_message? odbcserver.c:157:22: note: declared here " Please fix this and give notice when it is done. BR Fredrik Gustafsson Erlang OTP Team On 01/09/2013 09:53 AM, Kernel Panic wrote: > Hi, folks. > I created a patch for erlang odbc module which solves the problem with > setup autocommit mode for connections established by Oracle ODBC > driver in Linux. > The issue: Oracle ODBC driver for Linux ignores setup autocommit mode > during driver initialization before a connection to database has been > established (in odbc module autocommit is set this way). My patch > solves this problem by setting autocommit mode after a connection to > database has been established. > Actually it's an Oracle ODBC driver problem, but it could be very > useful to add this fix to erlang odbc module, because this module > allow to set autocommit mode only at the moment of connection > creation. > I sent this patch earlier in October 2012 but I didn't receive any feedback. > > My updates: > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix > > https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix > https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch > > Danil Onishchenko, alevandal@REDACTED > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Wed Jan 9 16:33:17 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 9 Jan 2013 16:33:17 +0100 Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <5077E4FA.9060609@erlang.org> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <506D7CF9.8050005@erlang.org> <1357439793.128073.1349368141231.JavaMail.root@tpip.net> <5072D75B.7060601@erlang.org> <50731907.3090802@erix.ericsson.se> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> Message-ID: <50ED8DBD.8080305@erlang.org> Hello Andreas, Your patch has finally been into review and the response was: " * The patch introduces new API options without documenting them. * The patch introduces new include file ssl_srp.hrl that I think shall be internal and put in src. It is undesirable to have records in the user API as it makes the user application compile time dependent on our code, better to use a proplist and then create the record internally. (Yes "sslsocket" is a record due to legacy) * The patch introduces new include file ssl_srp_primes.hrl I think it feels better to input such values as atoms and internaly uses the macros defined in this file, that would be more consistent with the rest of the API. * Functions in crypto being named TLS something seems a little strange, is this necessary?! " Please correct this and give me a notice when it is done. BR Fredrik Gustafsson Erlang OTP Team On 10/12/2012 11:38 AM, Henrik Nord wrote: > refetching > > On 10/12/2012 10:27 AM, Andreas Schultz wrote: >> Hi Henrik, >> >> When I rebased my changes to the current master, a change crept in that >> shouldn't have: >> >> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 >> >> >> I have removed it from my tree and pushed it. >> >> Andreas >> >> ----- Original Message ----- >>> Thanks, I will refetch! >>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: >>>> Hi, >>>> >>>> I have pushed a change that should fix the compile error. The >>>> buffer has >>>> a fixed length now. >>>> >>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 >>>> >>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch >>>> >>>> >>>> Andreas >>>> >>>> ----- Original Message ----- >>>>> Does not compile on Windows. >>>>> >>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with >>>>> dynamic >>>>> size is not supported by the C standard we use. >>>>> Use a static array instead, presuming that there is a reasonable >>>>> upper >>>>> limit of its size. >>>>> >>>>> /Sverker, Erlang/OTP >>>>> >>>>> >>>>> >>>>> Henrik Nord wrote: >>>>>> Hi >>>>>> >>>>>> I have added your branch to 'master'pu' for testing. >>>>>> Thank you for your contribution! >>>>>> >>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Tree is rebased onto latest master. >>>>>>> >>>>>>> Andreas >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Would you be so kind as to rebase this branch upon the latest >>>>>>>> 'master' >>>>>>>> >>>>>>>> Thank you for your contribution! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC >>>>>>>>> 5487 >>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and >>>>>>>>> usefulness >>>>>>>>> of those ciphers is rather limited, the one notable exception >>>>>>>>> being >>>>>>>>> the eID server protocol for German national identity cards >>>>>>>>> (nPA). >>>>>>>>> >>>>>>>>> The test suite can only verify some PSK suites against openssl >>>>>>>>> as >>>>>>>>> currently no openssl version supports them all. There is patch >>>>>>>>> that add some to openssl, but it has not been incorporated >>>>>>>>> into >>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK >>>>>>>>> suites >>>>>>>>> and I have manually tested interoperability. >>>>>>>>> >>>>>>>>> Patch info: >>>>>>>>> >>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git >>>>>>>>> tls-psk-srp-suites >>>>>>>>> >>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>>>>>>>> >>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Andreas >>>>>>>> -- >>>>>>>> /Henrik Nord Erlang/OTP >>>>>>>> >>>>>>>> >>> -- >>> /Henrik Nord Erlang/OTP >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Wed Jan 9 16:51:42 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 9 Jan 2013 16:51:42 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> Message-ID: <50ED920E.5060706@erlang.org> Hello Anthony, Your patch is failing the following suites and tests; trace_local_SUITE, exception_apply_function trace_local_SUITE, exception_function trace_local_SUITE, exception_meta_apply_function trace_local_SUITE, exception_meta_function trace_local_SUITE, exception_meta_nocatch_apply_function trace_local_SUITE, exception_meta_nocatch_function trace_local_SUITE, exception_nocatch_apply_function trace_local_SUITE, exception_nocatch_function Could you please fix this and then give me a notice, BR Fredrik Gustafsson Erlang OTP Team On 12/03/2012 11:28 AM, Anthony Ramine wrote: > I've removed the second commit of this branch because I'm not happy with it and because it makes the mnesia test suites fail. Enabling propagatation of local function names should be another patch on its own, let's not put that in this branch. > > Please refetch. > From wallentin.dahlberg@REDACTED Wed Jan 9 17:18:53 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Wed, 9 Jan 2013 17:18:53 +0100 Subject: [erlang-patches] Fix file descriptor leak when using async thread pool In-Reply-To: References: <50C5BD01.2060503@erlang.org> Message-ID: Results confirmed. Rebased branch and placed patch into opu. Great commit msg =) // Bj?rn-Egil 2012/12/10 Filipe David Manana > Rebased on top of master branch, as requested. > > New links: > > > https://github.com/fdmanana/otp/compare/master...fix_fd_leak_async_thread_pool.patch > > https://github.com/fdmanana/otp/compare/master...fix_fd_leak_async_thread_pool > > git fetch git://github.com/fdmanana/otp.git fix_fd_leak_async_thread_pool > > > On Mon, Dec 10, 2012 at 10:44 AM, Henrik Nord wrote: > > can you rebase this ontop of master > > Thank you! > > > > > > > > On 12/09/2012 11:55 PM, Filipe David Manana wrote: > >> > >> > >> > https://github.com/fdmanana/otp/compare/maint...fix_fd_leak_async_thread_pool.patch > >> > >> > https://github.com/fdmanana/otp/compare/maint...fix_fd_leak_async_thread_pool > >> > >> git fetch git://github.com/fdmanana/otp.git > >> fix_fd_leak_async_thread_pool > >> > >> > > > > -- > > /Henrik Nord Erlang/OTP > > > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdmanana@REDACTED Wed Jan 9 17:26:21 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Wed, 9 Jan 2013 16:26:21 +0000 Subject: [erlang-patches] Fix file descriptor leak when using async thread pool In-Reply-To: References: <50C5BD01.2060503@erlang.org> Message-ID: Thank you. Glad to help. On Wed, Jan 9, 2013 at 4:18 PM, Bj?rn-Egil Dahlberg wrote: > Results confirmed. > Rebased branch and placed patch into opu. > Great commit msg =) > > // Bj?rn-Egil > > 2012/12/10 Filipe David Manana >> >> Rebased on top of master branch, as requested. >> >> New links: >> >> >> https://github.com/fdmanana/otp/compare/master...fix_fd_leak_async_thread_pool.patch >> >> https://github.com/fdmanana/otp/compare/master...fix_fd_leak_async_thread_pool >> >> git fetch git://github.com/fdmanana/otp.git >> fix_fd_leak_async_thread_pool >> >> >> On Mon, Dec 10, 2012 at 10:44 AM, Henrik Nord wrote: >> > can you rebase this ontop of master >> > Thank you! >> > >> > >> > >> > On 12/09/2012 11:55 PM, Filipe David Manana wrote: >> >> >> >> >> >> >> >> https://github.com/fdmanana/otp/compare/maint...fix_fd_leak_async_thread_pool.patch >> >> >> >> >> >> https://github.com/fdmanana/otp/compare/maint...fix_fd_leak_async_thread_pool >> >> >> >> git fetch git://github.com/fdmanana/otp.git >> >> fix_fd_leak_async_thread_pool >> >> >> >> >> > >> > -- >> > /Henrik Nord Erlang/OTP >> > >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From bgustavsson@REDACTED Wed Jan 9 17:32:53 2013 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Wed, 9 Jan 2013 17:32:53 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <50ED920E.5060706@erlang.org> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> Message-ID: The code looks fine. I have only one comment for this part of the patch: @@ -1663,6 +1655,19 @@ uexpr(#ifun{anno=A,vars=Vs,body=B0}, {break,Rs}, St0) -> #k_int{val=Index},#k_int{val=Uniq}|Fvs], ret=Rs}, Free,add_local_function(Fun, St)}; +uexpr(#k_local{anno=A,name=Name,arity=Arity}, {break,Rs}, St) -> + Fs = get_free(Name, Arity, St), + FsCount = length(Fs), + Free = lit_list_vars(Fs), + %% Set dummy values for Index and Uniq -- the real values will + %% be assigned by beam_asm. + Index = Uniq = 0, + Bif = #k_bif{anno=#k{us=Free,ns=lit_list_vars(Rs),a=A}, + op=#k_internal{name=make_fun,arity=FsCount+3}, + args=[#k_atom{val=Name},#k_int{val=FsCount+Arity}, + #k_int{val=Index},#k_int{val=Uniq}|Fs], + ret=Rs}, + {Bif,Free,St}; uexpr(Lit, {break,Rs0}, St0) -> %% Transform literals to puts here. %%ok = io:fwrite("uexpr ~w:~p~n", [?LINE,Lit]), The code handles free variables. As far as I can understand, there can be no free variables in this case, so you should simplify the code. On Wed, Jan 9, 2013 at 4:51 PM, Fredrik wrote: > Hello Anthony, > Your patch is failing the following suites and tests; > trace_local_SUITE, exception_apply_function > trace_local_SUITE, exception_function > trace_local_SUITE, exception_meta_apply_function > trace_local_SUITE, exception_meta_function > trace_local_SUITE, exception_meta_nocatch_apply_**function > trace_local_SUITE, exception_meta_nocatch_**function > trace_local_SUITE, exception_nocatch_apply_**function > trace_local_SUITE, exception_nocatch_function > > Could you please fix this and then give me a notice, > > BR Fredrik Gustafsson > Erlang OTP Team > > On 12/03/2012 11:28 AM, Anthony Ramine wrote: > >> I've removed the second commit of this branch because I'm not happy with >> it and because it makes the mnesia test suites fail. Enabling propagatation >> of local function names should be another patch on its own, let's not put >> that in this branch. >> >> Please refetch. >> >> > ______________________________**_________________ > 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 wallentin.dahlberg@REDACTED Wed Jan 9 17:38:53 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Wed, 9 Jan 2013 17:38:53 +0100 Subject: [erlang-patches] Support ANSI in the console In-Reply-To: References: <50A4DE26.30402@erlang.org> <50ADEB64.6060601@erlang.org> <50ADED14.6030404@erlang.org> Message-ID: I have placed this patch into opu - i.e. a final integration test through our daily builds. I've reconsidered its impact. It should not have any impact if you don't use control sequences, which probably is the case in legacy code since those were filtered anyways. I also agree that not resetting the console is a user error. An easy way to reset the console if problems arise might be a nice future addition though. Your patch will probably be merged later this week if it passes final integration, shouldn't be a problem though. // Bj?rn-Egil 2012/12/18 Pedram Nimreezi > Yes that was intentionally omitted, as a small percentage of the time > it affected the ( ) brace matching (in smaller terminals).. > Also not properly resetting ANSI colors once a color is set is > technically a user error. > Would agree always resetting is the way to go, if it doesn't affect > anything else. > > On Tue, Dec 18, 2012 at 9:36 AM, Bj?rn-Egil Dahlberg > wrote: > > This seems nice. > > > > I use colors directly in the bash shell normally. Also via Erlang. Could > be > > nice with colors in erlang shell also. Seems more modern =) > > > > Is: > > --- a/lib/stdlib/src/shell.erl 2011-11-22 08:57:01.000000000 -0500 > > +++ b/lib/stdlib/src/shell.erl 2011-12-10 14:25:58.000000000 -0500 > > @@ -674,6 +674,7 @@ exprs([E0|Es], Bs1, RT, Lf, Ef, Bs0, W) > > [io:requests([{put_chars, VS}, nl]) || W =:= cmd], > > %% Don't send the result back if it will be > > %% discarded anyway. > > + io:fwrite("\e[0m"), > > V = if > > W =:= pmt -> > > {W,V0}; > > > > intentionally omitted? > > Always clearing the shell might be the way to go =) > > > > // Bj?rn-Egil > > > > 2012/11/22 Henrik Nord > >> > >> This mailing list + github is the only way atm. > >> > >> We are considering letting a view of our daily build result page show up > >> to the public via erlang.org > >> That would increase transparency and possible decrease the turnaround > time > >> for patches as the authors themselves could check the test results of > their > >> patches. > >> > >> > >> On 2012-11-22 10:11, Yurii Rashkovskii wrote: > >> > >> Is there any *reliable* way to track what's in pu/master-pu? > >> > >> > >> On Thu, Nov 22, 2012 at 1:07 AM, Henrik Nord wrote: > >>> > >>> No its in there, it was just removed temporary from the push > >>> > >>> > >>> > >>> On 2012-11-21 19:01, Yurii Rashkovskii wrote: > >>> > >>> Forgive me if I am missing something, but did this patch somehow not > make > >>> it to master-pu? > >>> > >>> > >>> > https://github.com/erlang/otp/blob/master-pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 > >>> > >>> (pu doesn't have it either > >>> > https://github.com/erlang/otp/blob/pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 > ) > >>> > >>> Is it intentional or is it an omission? > >>> > >>> > >>> On Thu, Nov 15, 2012 at 4:20 AM, Henrik Nord > wrote: > >>>> > >>>> Thank you for your contribution, I have added the patch to 'master-pu' > >>>> > >>>> > >>>> > >>>> On 2012-11-14 14:49, Pedram Nimreezi wrote: > >>>>> > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L901 > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L599 > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L609 > >>>> > >>>> > >>>> -- > >>>> /Henrik Nord Erlang/OTP > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-patches mailing list > >>>> erlang-patches@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-patches > >>> > >>> > >>> > >>> -- > >>> /Henrik Nord Erlang/OTP > >> > >> > >> > >> -- > >> /Henrik Nord Erlang/OTP > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > /* 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 wallentin.dahlberg@REDACTED Wed Jan 9 18:11:03 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Wed, 9 Jan 2013 18:11:03 +0100 Subject: [erlang-patches] Updates to file:allocate/2 (currently in master-pu) In-Reply-To: <50CEDDEC.5070301@erlang.org> References: <50CB3CCE.2010407@erlang.org> <50CEDDEC.5070301@erlang.org> Message-ID: I think this patch has passed through here in various incarnations the last two years. I get the feeling that it got missed in some hand over between people. I'm truly sorry about that. This will happen now, * I will add the patch to integration, i.e. master-opu * If it passes the final step, i will merge it to master and will be part of beta testing in R16A release. * If R16A is fine it will of course also be included in the proper R16B release. // Bj?rn-Egil 2012/12/17 Fredrik > Hello Filipe! > The patch is now in the 'master-pu' branch. > > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/14/2012 04:41 PM, Filipe David Manana wrote: > >> On Fri, Dec 14, 2012 at 2:50 PM, Fredrik wrote: >> >>> Hello Filipe, >>> Create a new branch and mail me back the fetch command and links, and I >>> will >>> fetch and put them into master-pu. >>> >> Fredrik, >> >> I squashed all the commits into a new branch: >> >> git fetch git://github.com/fdmanana/otp.**git file_allocate_squashed >> >> https://github.com/fdmanana/**otp/compare/master...file_** >> allocate_squashed.patch >> https://github.com/fdmanana/**otp/compare/master...file_** >> allocate_squashed >> >> Thank you >> >> >> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >>> On 12/14/2012 03:46 PM, Filipe David Manana wrote: >>> >>>> Hello, >>>> >>>> I added 2 commits on top of the existing ones for the file:allocate/2 >>>> patch, currently in master-pu branch. >>>> >>>> They can be found in the following branch: >>>> >>>> git fetch git://github.com/fdmanana/otp.**git file_allocate >>>> >>>> >>>> These commits are the most recent: >>>> >>>> https://github.com/fdmanana/**otp/commits/file_allocate >>>> >>>> Can you pick them, or shall I create a new branch with all of them >>>> squashed into a single commit? >>>> >>>> Thank you >>>> >>>> >>>> >> >> > ______________________________**_________________ > 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 Wed Jan 9 18:59:02 2013 From: yrashk@REDACTED (Yurii Rashkovskii) Date: Wed, 9 Jan 2013 09:59:02 -0800 Subject: [erlang-patches] Support ANSI in the console In-Reply-To: References: <50A4DE26.30402@erlang.org> <50ADEB64.6060601@erlang.org> <50ADED14.6030404@erlang.org> Message-ID: While we are at it, would the OTP team considering merging a patch that adds isatty functionality to Erlang, in relation to this ANSI improvement? It would allow developers to print ANSI sequences only when the program is using an actual terminal. On Wed, Jan 9, 2013 at 8:38 AM, Bj?rn-Egil Dahlberg < wallentin.dahlberg@REDACTED> wrote: > I have placed this patch into opu - i.e. a final integration test through > our daily builds. > > I've reconsidered its impact. It should not have any impact if you don't > use control sequences, which probably is the case in legacy code since > those were filtered anyways. I also agree that not resetting the console is > a user error. > > An easy way to reset the console if problems arise might be a nice future > addition though. > > Your patch will probably be merged later this week if it passes final > integration, shouldn't be a problem though. > > // Bj?rn-Egil > > 2012/12/18 Pedram Nimreezi > >> Yes that was intentionally omitted, as a small percentage of the time >> it affected the ( ) brace matching (in smaller terminals).. >> Also not properly resetting ANSI colors once a color is set is >> technically a user error. >> Would agree always resetting is the way to go, if it doesn't affect >> anything else. >> >> On Tue, Dec 18, 2012 at 9:36 AM, Bj?rn-Egil Dahlberg >> wrote: >> > This seems nice. >> > >> > I use colors directly in the bash shell normally. Also via Erlang. >> Could be >> > nice with colors in erlang shell also. Seems more modern =) >> > >> > Is: >> > --- a/lib/stdlib/src/shell.erl 2011-11-22 08:57:01.000000000 -0500 >> > +++ b/lib/stdlib/src/shell.erl 2011-12-10 14:25:58.000000000 -0500 >> > @@ -674,6 +674,7 @@ exprs([E0|Es], Bs1, RT, Lf, Ef, Bs0, W) >> > [io:requests([{put_chars, VS}, nl]) || W =:= cmd], >> > %% Don't send the result back if it will be >> > %% discarded anyway. >> > + io:fwrite("\e[0m"), >> > V = if >> > W =:= pmt -> >> > {W,V0}; >> > >> > intentionally omitted? >> > Always clearing the shell might be the way to go =) >> > >> > // Bj?rn-Egil >> > >> > 2012/11/22 Henrik Nord >> >> >> >> This mailing list + github is the only way atm. >> >> >> >> We are considering letting a view of our daily build result page show >> up >> >> to the public via erlang.org >> >> That would increase transparency and possible decrease the turnaround >> time >> >> for patches as the authors themselves could check the test results of >> their >> >> patches. >> >> >> >> >> >> On 2012-11-22 10:11, Yurii Rashkovskii wrote: >> >> >> >> Is there any *reliable* way to track what's in pu/master-pu? >> >> >> >> >> >> On Thu, Nov 22, 2012 at 1:07 AM, Henrik Nord >> wrote: >> >>> >> >>> No its in there, it was just removed temporary from the push >> >>> >> >>> >> >>> >> >>> On 2012-11-21 19:01, Yurii Rashkovskii wrote: >> >>> >> >>> Forgive me if I am missing something, but did this patch somehow not >> make >> >>> it to master-pu? >> >>> >> >>> >> >>> >> https://github.com/erlang/otp/blob/master-pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 >> >>> >> >>> (pu doesn't have it either >> >>> >> https://github.com/erlang/otp/blob/pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 >> ) >> >>> >> >>> Is it intentional or is it an omission? >> >>> >> >>> >> >>> On Thu, Nov 15, 2012 at 4:20 AM, Henrik Nord >> wrote: >> >>>> >> >>>> Thank you for your contribution, I have added the patch to >> 'master-pu' >> >>>> >> >>>> >> >>>> >> >>>> On 2012-11-14 14:49, Pedram Nimreezi wrote: >> >>>>> >> >>>>> >> >>>>> >> https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L901 >> >>>>> >> >>>>> >> https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L599 >> >>>>> >> >>>>> >> https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L609 >> >>>> >> >>>> >> >>>> -- >> >>>> /Henrik Nord Erlang/OTP >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> erlang-patches mailing list >> >>>> erlang-patches@REDACTED >> >>>> http://erlang.org/mailman/listinfo/erlang-patches >> >>> >> >>> >> >>> >> >>> -- >> >>> /Henrik Nord Erlang/OTP >> >> >> >> >> >> >> >> -- >> >> /Henrik Nord Erlang/OTP >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> /* 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 egil@REDACTED Wed Jan 9 19:24:40 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 9 Jan 2013 19:24:40 +0100 Subject: [erlang-patches] Support ANSI in the console In-Reply-To: References: <50A4DE26.30402@erlang.org> <50ADEB64.6060601@erlang.org> <50ADED14.6030404@erlang.org> Message-ID: <50EDB5E8.8040101@erlang.org> On 2013-01-09 18:59, Yurii Rashkovskii wrote: > While we are at it, would the OTP team considering merging a patch > that adds isatty functionality to Erlang, in relation to this ANSI > improvement? > > It would allow developers to print ANSI sequences only when the > program is using an actual terminal. We would certainly review it but I have no other thoughts on the matter right now. It seems like a good thing to do. We are getting pressed for time. Code freeze for R16A is 23/1 and we have a lot of other things that needs to get done. If you have a patch ready - send it. Nothing to lose. I can't guarantee we have the time to review it though, depends on complexity =) // Bj?rn-Egil > > > On Wed, Jan 9, 2013 at 8:38 AM, Bj?rn-Egil Dahlberg > > > wrote: > > I have placed this patch into opu - i.e. a final integration test > through our daily builds. > > I've reconsidered its impact. It should not have any impact if you > don't use control sequences, which probably is the case in legacy > code since those were filtered anyways. I also agree that not > resetting the console is a user error. > > An easy way to reset the console if problems arise might be a nice > future addition though. > > Your patch will probably be merged later this week if it passes > final integration, shouldn't be a problem though. > > // Bj?rn-Egil > > 2012/12/18 Pedram Nimreezi > > > Yes that was intentionally omitted, as a small percentage of > the time > it affected the ( ) brace matching (in smaller terminals).. > Also not properly resetting ANSI colors once a color is set is > technically a user error. > Would agree always resetting is the way to go, if it doesn't > affect > anything else. > > On Tue, Dec 18, 2012 at 9:36 AM, Bj?rn-Egil Dahlberg > > wrote: > > This seems nice. > > > > I use colors directly in the bash shell normally. Also via > Erlang. Could be > > nice with colors in erlang shell also. Seems more modern =) > > > > Is: > > --- a/lib/stdlib/src/shell.erl 2011-11-22 08:57:01.000000000 > -0500 > > +++ b/lib/stdlib/src/shell.erl 2011-12-10 14:25:58.000000000 > -0500 > > @@ -674,6 +674,7 @@ exprs([E0|Es], Bs1, RT, Lf, Ef, Bs0, W) > > [io:requests([{put_chars, VS}, nl]) || W =:= cmd], > > %% Don't send the result back if it will be > > %% discarded anyway. > > + io:fwrite("\e[0m"), > > V = if > > W =:= pmt -> > > {W,V0}; > > > > intentionally omitted? > > Always clearing the shell might be the way to go =) > > > > // Bj?rn-Egil > > > > 2012/11/22 Henrik Nord > > >> > >> This mailing list + github is the only way atm. > >> > >> We are considering letting a view of our daily build result > page show up > >> to the public via erlang.org > >> That would increase transparency and possible decrease the > turnaround time > >> for patches as the authors themselves could check the test > results of their > >> patches. > >> > >> > >> On 2012-11-22 10:11, Yurii Rashkovskii wrote: > >> > >> Is there any *reliable* way to track what's in pu/master-pu? > >> > >> > >> On Thu, Nov 22, 2012 at 1:07 AM, Henrik Nord > > wrote: > >>> > >>> No its in there, it was just removed temporary from the push > >>> > >>> > >>> > >>> On 2012-11-21 19:01, Yurii Rashkovskii wrote: > >>> > >>> Forgive me if I am missing something, but did this patch > somehow not make > >>> it to master-pu? > >>> > >>> > >>> > https://github.com/erlang/otp/blob/master-pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 > >>> > >>> (pu doesn't have it either > >>> > https://github.com/erlang/otp/blob/pu/erts/emulator/drivers/unix/ttsl_drv.c#L915) > >>> > >>> Is it intentional or is it an omission? > >>> > >>> > >>> On Thu, Nov 15, 2012 at 4:20 AM, Henrik Nord > > wrote: > >>>> > >>>> Thank you for your contribution, I have added the patch > to 'master-pu' > >>>> > >>>> > >>>> > >>>> On 2012-11-14 14:49, Pedram Nimreezi wrote: > >>>>> > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L901 > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L599 > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L609 > >>>> > >>>> > >>>> -- > >>>> /Henrik Nord Erlang/OTP > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-patches mailing list > >>>> erlang-patches@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-patches > >>> > >>> > >>> > >>> -- > >>> /Henrik Nord Erlang/OTP > >> > >> > >> > >> -- > >> /Henrik Nord Erlang/OTP > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > /* 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 alevandal@REDACTED Thu Jan 10 05:19:16 2013 From: alevandal@REDACTED (Danil Onishchenko) Date: Thu, 10 Jan 2013 12:19:16 +0800 Subject: [erlang-patches] Patch for ODBC module In-Reply-To: <50ED647B.6000705@erlang.org> References: <50ED647B.6000705@erlang.org> Message-ID: Hi, Fredrik. When I was working on my patch I used the branch "maint" of OTP repository as a base because in the guide for submitting patches it was writed "Base your patch on maint if you are fixing a bug...". I compared the source file odbcserver.c in the branches "maint" and "master-pu" and found out that definitions of functions ?get_diagnos? and ?encode_error_message? in those branches are different. In "maint" they are static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle); static db_result_msg encode_error_message(char *reason); and in "master" static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle, Boolean extendedErrors); static db_result_msg encode_error_message(char *reason, char *errCode, SQLINTEGER nativeError); So my patch is proper for the "maint" branch and it is not for "master" branch. Is my choise of the branch wrong? Should I use "master" as a base instead of "maint"? Also I sent a patch "odbc:param_query/3 and odbc:param_query/4" which I based on the branch "maint" too. Should I fix it for "master"? 2013/1/9 Fredrik : > Hello again, > This patch fails to build: > " > > odbcserver.c: In function ?db_connect?: > odbcserver.c:538:2: error: too few arguments to function ?get_diagnos? > odbcserver.c:250:16: note: declared here > odbcserver.c:541:2: error: too few arguments to function > ?encode_error_message? > odbcserver.c:157:22: note: declared here > > " > Please fix this and give notice when it is done. > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/09/2013 09:53 AM, Kernel Panic wrote: >> >> Hi, folks. >> I created a patch for erlang odbc module which solves the problem with >> setup autocommit mode for connections established by Oracle ODBC >> driver in Linux. >> The issue: Oracle ODBC driver for Linux ignores setup autocommit mode >> during driver initialization before a connection to database has been >> established (in odbc module autocommit is set this way). My patch >> solves this problem by setting autocommit mode after a connection to >> database has been established. >> Actually it's an Oracle ODBC driver problem, but it could be very >> useful to add this fix to erlang odbc module, because this module >> allow to set autocommit mode only at the moment of connection >> creation. >> I sent this patch earlier in October 2012 but I didn't receive any >> feedback. >> >> My updates: >> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix >> >> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix >> >> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch >> >> Danil Onishchenko, alevandal@REDACTED >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > From kino@REDACTED Thu Jan 10 08:54:15 2013 From: kino@REDACTED (satoshi kinoshita) Date: Thu, 10 Jan 2013 16:54:15 +0900 Subject: [erlang-patches] odbcserver.c 64bit support In-Reply-To: <50BC8F7A.6080209@erlang.org> References: <50BC8F7A.6080209@erlang.org> Message-ID: At Mon, 3 Dec 2012 12:39:38 +0100, Henrik Nord wrote: > > > On 11/29/2012 08:22 AM, satoshi kinoshita wrote: > > I found antoher 64bit related bug in odbcserver.c. > > It affects only param_query for stored-procedure > > with OUT parameter of SQL_C_SLONG type. > Can you add a testcase for this problem? The branch now includes both fix and some test cases. - The original bug I found is for 64 bit gcc(used to compile odbcserver.c). Test cases should succeed with odbcserver compiled using 32 bit gcc even without the fix. - oracle test case may need to set scrollable_cursors option to off depending on the driver(I tested with Oracle ODBC driver from following rpm package on centos6: oracle-instantclient11.2-odbc-11.2.0.3.0-1.x86_64, which seems like *not* supporting srollabel_cursors). - postgresql test case is not actually checking the values of OUT params of the stored function. Though I'm still trying to write some more test cases to check actual out values, I think it's enough because it's checking the fix (I mean this test case succeeds with my fix and fails without it). - I have no time to setup and test this fix with mysql:). It just skips the test cases when the RDBMS macro is defined as 'mysql'. ---Patch-------------------------------------------------- git fetch git://github.com/kinogmt/otp.git odbc64 https://github.com/kinogmt/otp/compare/maint...odbc64 https://github.com/kinogmt/otp/compare/maint...odbc64.patch ----------------------------------------------------------- Thanks, Kinoshtia From fredrik@REDACTED Thu Jan 10 09:34:51 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 09:34:51 +0100 Subject: [erlang-patches] Patch for ODBC module In-Reply-To: References: <50ED647B.6000705@erlang.org> Message-ID: <50EE7D2B.1080300@erlang.org> Hello Danil! Please rebase this patch on current 'master' branch and fix the problem. From what is written in the 'how-to submit patches' on github you have done the right thing, we will update the wiki soon. BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 05:19 AM, Danil Onishchenko wrote: > Hi, Fredrik. > When I was working on my patch I used the branch "maint" of OTP > repository as a base because in the guide for submitting patches it > was writed "Base your patch on maint if you are fixing a bug...". I > compared the source file odbcserver.c in the branches "maint" and > "master-pu" and found out that definitions of functions ?get_diagnos? > and ?encode_error_message? in those branches are different. > In "maint" they are > static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle); > static db_result_msg encode_error_message(char *reason); > > and in "master" > static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle, > Boolean extendedErrors); > static db_result_msg encode_error_message(char *reason, char *errCode, > SQLINTEGER nativeError); > > So my patch is proper for the "maint" branch and it is not for > "master" branch. Is my choise of the branch wrong? Should I use > "master" as a base instead of "maint"? > > Also I sent a patch "odbc:param_query/3 and odbc:param_query/4" which > I based on the branch "maint" too. Should I fix it for "master"? > > 2013/1/9 Fredrik: >> Hello again, >> This patch fails to build: >> " >> >> odbcserver.c: In function ?db_connect?: >> odbcserver.c:538:2: error: too few arguments to function ?get_diagnos? >> odbcserver.c:250:16: note: declared here >> odbcserver.c:541:2: error: too few arguments to function >> ?encode_error_message? >> odbcserver.c:157:22: note: declared here >> >> " >> Please fix this and give notice when it is done. >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/09/2013 09:53 AM, Kernel Panic wrote: >>> Hi, folks. >>> I created a patch for erlang odbc module which solves the problem with >>> setup autocommit mode for connections established by Oracle ODBC >>> driver in Linux. >>> The issue: Oracle ODBC driver for Linux ignores setup autocommit mode >>> during driver initialization before a connection to database has been >>> established (in odbc module autocommit is set this way). My patch >>> solves this problem by setting autocommit mode after a connection to >>> database has been established. >>> Actually it's an Oracle ODBC driver problem, but it could be very >>> useful to add this fix to erlang odbc module, because this module >>> allow to set autocommit mode only at the moment of connection >>> creation. >>> I sent this patch earlier in October 2012 but I didn't receive any >>> feedback. >>> >>> My updates: >>> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix >>> >>> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix >>> >>> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch >>> >>> Danil Onishchenko, alevandal@REDACTED >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> From fredrik@REDACTED Thu Jan 10 10:21:56 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 10:21:56 +0100 Subject: [erlang-patches] Reclaim the 'query' keyword In-Reply-To: <50CF68D4.90504@ninenines.eu> References: <50B660BF.6060507@ninenines.eu> <50CF68D4.90504@ninenines.eu> Message-ID: <50EE8834.3070300@erlang.org> Hello, Could you please rebase this on the current 'master' branch and fix the problems it is facing. BR Fredrik Gustafsson Erlang OTP Team On 12/17/2012 07:47 PM, Lo?c Hoguin wrote: > On 11/28/2012 08:06 PM, Lo?c Hoguin wrote: >> git fetch git://github.com/essen/otp.git forget-mnemosyne >> >> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne >> >> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne.patch >> > > Please refetch. Amended the last commit with the proper fixes. Tests > should pass and warning introduced has been removed. > > Issue came from this: > % gg -i mnemosyne > src/mnesia.erl:119: %% Mnemosyne exclusive > src/mnesia.erl:2885:%% Mnemosyne exclusive > > Which says it's Mnemosyne exclusive but is clearly not as it's used by > a few tests. I'll leave this for someone with better Mnesia knowledge > to decide what to do. > > Thanks! > From fredrik@REDACTED Thu Jan 10 10:41:29 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 10:41:29 +0100 Subject: [erlang-patches] odbcserver.c 64bit support In-Reply-To: References: <50BC8F7A.6080209@erlang.org> Message-ID: <50EE8CC9.5070607@erlang.org> Hello, I have re-fetched and your branch is again in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 08:54 AM, satoshi kinoshita wrote: > At Mon, 3 Dec 2012 12:39:38 +0100, > Henrik Nord wrote: >> >> On 11/29/2012 08:22 AM, satoshi kinoshita wrote: >>> I found antoher 64bit related bug in odbcserver.c. >>> It affects only param_query for stored-procedure >>> with OUT parameter of SQL_C_SLONG type. >> Can you add a testcase for this problem? > The branch now includes both fix and some test cases. > > - The original bug I found is for 64 bit gcc(used to compile odbcserver.c). > Test cases should succeed with odbcserver compiled using 32 bit gcc > even without the fix. > > - oracle test case may need to set scrollable_cursors option to off > depending on the driver(I tested with Oracle ODBC driver from > following rpm package on > centos6: oracle-instantclient11.2-odbc-11.2.0.3.0-1.x86_64, > which seems like *not* supporting srollabel_cursors). > > > - postgresql test case is not actually checking the values of OUT params > of the stored function. > Though I'm still trying to write some more test cases to > check actual out values, > I think it's enough because it's checking > the fix (I mean this test case succeeds with my fix > and fails without it). > > - I have no time to setup and test this fix with mysql:). > It just skips the test cases when the RDBMS macro is defined as 'mysql'. > > > > > ---Patch-------------------------------------------------- > git fetch git://github.com/kinogmt/otp.git odbc64 > https://github.com/kinogmt/otp/compare/maint...odbc64 > https://github.com/kinogmt/otp/compare/maint...odbc64.patch > ----------------------------------------------------------- > > Thanks, > Kinoshtia > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Thu Jan 10 10:45:20 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 10:45:20 +0100 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: References: Message-ID: <50EE8DB0.4020906@erlang.org> Hello, Your patch has been into review and the feedback you got back was that everything looks good but you have to remove the '?line' macros, because they are not used and thus has no effect anymore. Please fix this and give me a notice when it is done BR Fredrik Gustafsson Erlang OTP Team On 11/28/2012 02:11 PM, Jos? Valim wrote: > Hello, > > I am sending a couple bug fixes for cover. > > I have broken those fixes into three granular commits. > The commit messages contains the rationale behind them. > > One of the commits changes cover to get the source from > "Module:module_info(compile)" if the current heuristic that > traverses directories fails. In my opinion, we could rely > solely on the source information and remove the heuristic > completely but I have kept the current heuristic as the first > mechanism in order to minimize the impact of the changes. > > As such, I would appreciate if those changes could be merged > into maint. :) > > git fetch git://github.com/josevalim/otp.git > cover-patches > > https://github.com/josevalim/otp/compare/cover-patches > https://github.com/josevalim/otp/compare/cover-patches.patch > > Thank you, > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Thu Jan 10 10:53:37 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Thu, 10 Jan 2013 10:53:37 +0100 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: <50EE8DB0.4020906@erlang.org> References: <50EE8DB0.4020906@erlang.org> Message-ID: I have added ?line to keep consistent with the remaining of the test file. Do you want me to go ahead and remove ?line from the whole * lib/tools/test/cover_SUITE.erl* file or this is something you have already done internally and I should remove just the ones in my patch? *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Thu, Jan 10, 2013 at 10:45 AM, Fredrik wrote: > Hello, > Your patch has been into review and the feedback you got back was that > everything looks good but you have to remove the '?line' macros, because > they are not used and thus has no effect anymore. > Please fix this and give me a notice when it is done > > BR Fredrik Gustafsson > Erlang OTP Team > > On 11/28/2012 02:11 PM, Jos? Valim wrote: > > Hello, > > I am sending a couple bug fixes for cover. > > I have broken those fixes into three granular commits. > The commit messages contains the rationale behind them. > > One of the commits changes cover to get the source from > "Module:module_info(compile)" if the current heuristic that > traverses directories fails. In my opinion, we could rely > solely on the source information and remove the heuristic > completely but I have kept the current heuristic as the first > mechanism in order to minimize the impact of the changes. > > As such, I would appreciate if those changes could be merged > into maint. :) > > git fetch git://github.com/josevalim/otp.git cover-patches > > https://github.com/josevalim/otp/compare/cover-patches > https://github.com/josevalim/otp/compare/cover-patches.patch > > Thank you, > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > > _______________________________________________ > erlang-patches mailing listerlang-patches@REDACTED://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 jose.valim@REDACTED Thu Jan 10 11:04:16 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Thu, 10 Jan 2013 11:04:16 +0100 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: References: <50EE8DB0.4020906@erlang.org> Message-ID: Anyway, here are the patches without ?line. git fetch git://github.com/josevalim/otp.git cover-patches-no-line https://github.com/josevalim/otp/compare/cover-patches-no-line https://github.com/josevalim/otp/compare/cover-patches-no-line.patch *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Thu, Jan 10, 2013 at 10:53 AM, Jos? Valim < jose.valim@REDACTED> wrote: > I have added ?line to keep consistent with the remaining of the test file. > Do you want me to go ahead and remove ?line from the whole * > lib/tools/test/cover_SUITE.erl* file or this is something you have > already done internally and I should remove just the ones in my patch? > > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jan 10, 2013 at 10:45 AM, Fredrik wrote: > >> Hello, >> Your patch has been into review and the feedback you got back was that >> everything looks good but you have to remove the '?line' macros, because >> they are not used and thus has no effect anymore. >> Please fix this and give me a notice when it is done >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> On 11/28/2012 02:11 PM, Jos? Valim wrote: >> >> Hello, >> >> I am sending a couple bug fixes for cover. >> >> I have broken those fixes into three granular commits. >> The commit messages contains the rationale behind them. >> >> One of the commits changes cover to get the source from >> "Module:module_info(compile)" if the current heuristic that >> traverses directories fails. In my opinion, we could rely >> solely on the source information and remove the heuristic >> completely but I have kept the current heuristic as the first >> mechanism in order to minimize the impact of the changes. >> >> As such, I would appreciate if those changes could be merged >> into maint. :) >> >> git fetch git://github.com/josevalim/otp.git cover-patches >> >> https://github.com/josevalim/otp/compare/cover-patches >> https://github.com/josevalim/otp/compare/cover-patches.patch >> >> Thank you, >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> >> _______________________________________________ >> erlang-patches mailing listerlang-patches@REDACTED://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 fredrik@REDACTED Thu Jan 10 11:08:00 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 11:08:00 +0100 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: References: <50EE8DB0.4020906@erlang.org> Message-ID: <50EE9300.9090002@erlang.org> Hello, No you just have to remove it for the lines you added or changed. BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 10:53 AM, Jos? Valim wrote: > I have added ?line to keep consistent with the remaining of the test > file. Do you want me to go ahead and remove ?line from the whole > /lib/tools/test/cover_SUITE.erl/ file or this is something you have > already done internally and I should remove just the ones in my patch? > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jan 10, 2013 at 10:45 AM, Fredrik > wrote: > > Hello, > Your patch has been into review and the feedback you got back was > that everything looks good but you have to remove the '?line' > macros, because they are not used and thus has no effect anymore. > Please fix this and give me a notice when it is done > > BR Fredrik Gustafsson > Erlang OTP Team > > On 11/28/2012 02:11 PM, Jos? Valim wrote: >> Hello, >> >> I am sending a couple bug fixes for cover. >> >> I have broken those fixes into three granular commits. >> The commit messages contains the rationale behind them. >> >> One of the commits changes cover to get the source from >> "Module:module_info(compile)" if the current heuristic that >> traverses directories fails. In my opinion, we could rely >> solely on the source information and remove the heuristic >> completely but I have kept the current heuristic as the first >> mechanism in order to minimize the impact of the changes. >> >> As such, I would appreciate if those changes could be merged >> into maint. :) >> >> git fetch git://github.com/josevalim/otp.git >> cover-patches >> >> https://github.com/josevalim/otp/compare/cover-patches >> https://github.com/josevalim/otp/compare/cover-patches.patch >> >> Thank you, >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> >> _______________________________________________ >> 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 fredrik@REDACTED Thu Jan 10 11:08:40 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 11:08:40 +0100 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: References: <50EE8DB0.4020906@erlang.org> Message-ID: <50EE9328.30402@erlang.org> Great, I'll re-fetch this. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 11:04 AM, Jos? Valim wrote: > Anyway, here are the patches without ?line. > > git fetch git://github.com/josevalim/otp.git > cover-patches-no-line > > https://github.com/josevalim/otp/compare/cover-patches-no-line > https://github.com/josevalim/otp/compare/cover-patches-no-line.patch > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jan 10, 2013 at 10:53 AM, Jos? Valim > > wrote: > > I have added ?line to keep consistent with the remaining of the > test file. Do you want me to go ahead and remove ?line from the > whole /lib/tools/test/cover_SUITE.erl/ file or this is something > you have already done internally and I should remove just the ones > in my patch? > > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jan 10, 2013 at 10:45 AM, Fredrik > wrote: > > Hello, > Your patch has been into review and the feedback you got back > was that everything looks good but you have to remove the > '?line' macros, because they are not used and thus has no > effect anymore. > Please fix this and give me a notice when it is done > > BR Fredrik Gustafsson > Erlang OTP Team > > On 11/28/2012 02:11 PM, Jos? Valim wrote: >> Hello, >> >> I am sending a couple bug fixes for cover. >> >> I have broken those fixes into three granular commits. >> The commit messages contains the rationale behind them. >> >> One of the commits changes cover to get the source from >> "Module:module_info(compile)" if the current heuristic that >> traverses directories fails. In my opinion, we could rely >> solely on the source information and remove the heuristic >> completely but I have kept the current heuristic as the first >> mechanism in order to minimize the impact of the changes. >> >> As such, I would appreciate if those changes could be merged >> into maint. :) >> >> git fetch git://github.com/josevalim/otp.git >> cover-patches >> >> https://github.com/josevalim/otp/compare/cover-patches >> https://github.com/josevalim/otp/compare/cover-patches.patch >> >> Thank you, >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> >> _______________________________________________ >> 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 Thu Jan 10 13:33:03 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 10 Jan 2013 13:33:03 +0100 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> Message-ID: <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit : > The code handles free variables. As far as I can understand, there > can be no free variables in this case, so you should simplify the code. You're right and wrong :) There can be no free variables if the Core Erlang code comes from a current Erlang module, but there can be if the Core Erlang was handwritten or generated by my EEP37 patch, for example: module 'foo' ['bar'/1, 'module_info'/0, 'module_info'/1] attributes [] 'bar'/1 = %% Line 4 fun (_cor0) -> letrec 'Bar'/1 = %% Line 5 ( fun (_cor4) -> let = 'Bar'/1 in case _cor4 of <1> when 'true' -> 1 when 'true' -> let <_cor3> = call 'erlang':'*' (N, _cor0) in let <_cor1> = call 'erlang':'-' (N, 1) in let <_cor2> = apply Bar (_cor1) in call 'erlang':'*' (_cor3, _cor2) end -| [{'id',{0,0,'Bar'}}] ) in 'Bar'/1 'module_info'/0 = fun () -> call 'erlang':'get_module_info' ('foo') 'module_info'/1 = fun (_cor0) -> call 'erlang':'get_module_info' ('foo', _cor0) end In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need to be handled to remove the reverse eta conversion in a future-proof way. The differences between master and my patch when running erlc +to_kernel foo.core are: --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100 +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100 @@ -5,18 +5,16 @@ attributes [] fdef 'bar'/1(_Xcor0) = do - bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0) >> <_ker2> + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0) >> <_ker1> then - <<_ker2>> + <<_ker1>> fdef 'module_info'/0() = enter (remote 'erlang':'get_module_info'/1)('foo') fdef 'module_info'/1(_Xcor0) = enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0) -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) = - enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0) fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) = do - bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0) >> + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0) >> then match _Xcor4 alt @@ -34,10 +32,8 @@ call (Bar)(_Xcor1) >> <_Xcor2> then do - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2) >> <_ker1> + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2) >> <_ker0> then - <<_ker1>> + <<_ker0>> end >> <> -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) = - enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0) end \ No newline at end of file Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you when I'm done. Thanks for the feedback. Regards, -- Anthony Ramine From fredrik@REDACTED Thu Jan 10 14:46:06 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 14:46:06 +0100 Subject: [erlang-patches] Fix public_key module document little typo In-Reply-To: References: Message-ID: <50EEC61E.4080905@erlang.org> Hello Ryosuke, I don't see a reply on this patch from us, but the patch has been through tests and review and I am merging to master today. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 12/12/2012 02:38 PM, Ryosuke Nakai wrote: > Hi, > > A subjectPublicKeyInfo type of OTPTBSCertificate record is properly > OTPSubjectPublicKeyInfo. > > Defined in the OTP-PKIX.asn1 are as follows. > > OTP-PKIX.asn1:: > > OTPTBSCertificate ::= SEQUENCE { > ... > subjectPublicKeyInfo OTPSubjectPublicKeyInfo, > > git fetch git://github.com/voluntas/otp.git vo-fix-doc-cert-records > > https://github.com/voluntas/otp/compare/fix-doc-cert-records > https://github.com/voluntas/otp/compare/fix-doc-cert-records.patch > > __ > NAKAI Ryosuke > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From serge@REDACTED Thu Jan 10 15:31:41 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 09:31:41 -0500 Subject: [erlang-patches] [patch] Added application:get_env/3 Message-ID: <50EED0CD.3080603@aleynikov.org> Added an application:get_env/3 function variant that provides a default value for a configuration parameter: application:get_env(App, Key, Default) -> Value. git fetch git://github.com/saleyn/otp.git get_env https://github.com/saleyn/otp/compare/erlang:master...get_env https://github.com/saleyn/otp/compare/erlang:master...get_env.patch From egil@REDACTED Thu Jan 10 15:55:53 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 10 Jan 2013 15:55:53 +0100 Subject: [erlang-patches] Updates to file:allocate/2 (currently in master-opu) In-Reply-To: References: <50CB3CCE.2010407@erlang.org> <50CEDDEC.5070301@erlang.org> Message-ID: <50EED679.3060100@erlang.org> On 2013-01-09 18:11, Bj?rn-Egil Dahlberg wrote: > I think this patch has passed through here in various incarnations the > last two years. I get the feeling that it got missed in some hand over > between people. I'm truly sorry about that. > > This will happen now, > * I will add the patch to integration, i.e. master-opu > * If it passes the final step, i will merge it to master and will be > part of beta testing in R16A release. > * If R16A is fine it will of course also be included in the proper > R16B release. So .. this broke during cross-compilation test AC_TRY_RUN did not have an cross-compilation option. * Added the safer default option 'no' in cross-compilation See: https://github.com/psyeugenic/otp/commits/fdm/file-allocate Do you a better solution or should we stick with this? I will test this option a bit more still. Could be reproduced with: ./otp_build autoconf ./otp_build configure --enable-sctp --xcomp-conf=xcomp/erl-xcomp-powerpc-dso-linux-gnu.conf (Needs powerpc gcc toolchain for cross compilation in path) > > // Bj?rn-Egil > > 2012/12/17 Fredrik > > > Hello Filipe! > The patch is now in the 'master-pu' branch. > > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/14/2012 04:41 PM, Filipe David Manana wrote: > > On Fri, Dec 14, 2012 at 2:50 PM, Fredrik > wrote: > > Hello Filipe, > Create a new branch and mail me back the fetch command and > links, and I will > fetch and put them into master-pu. > > Fredrik, > > I squashed all the commits into a new branch: > > git fetch git://github.com/fdmanana/otp.git > file_allocate_squashed > > https://github.com/fdmanana/otp/compare/master...file_allocate_squashed.patch > https://github.com/fdmanana/otp/compare/master...file_allocate_squashed > > Thank you > > > BR Fredrik Gustafsson > Erlang OTP Team > > On 12/14/2012 03:46 PM, Filipe David Manana wrote: > > Hello, > > I added 2 commits on top of the existing ones for the > file:allocate/2 > patch, currently in master-pu branch. > > They can be found in the following branch: > > git fetch git://github.com/fdmanana/otp.git > file_allocate > > > These commits are the most recent: > > https://github.com/fdmanana/otp/commits/file_allocate > > Can you pick them, or shall I create a new branch with > all of them > squashed into a single commit? > > Thank you > > > > > > _______________________________________________ > 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 fredrik@REDACTED Thu Jan 10 16:03:27 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 16:03:27 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50EED0CD.3080603@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> Message-ID: <50EED83F.8060702@erlang.org> Hello Serge, Your patch is now in the 'master-pu' branch. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 03:31 PM, Serge Aleynikov wrote: > Added an application:get_env/3 function variant that provides a default > value for a configuration parameter: > > application:get_env(App, Key, Default) -> Value. > > git fetch git://github.com/saleyn/otp.git get_env > > https://github.com/saleyn/otp/compare/erlang:master...get_env > https://github.com/saleyn/otp/compare/erlang:master...get_env.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fdmanana@REDACTED Thu Jan 10 16:05:08 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 10 Jan 2013 15:05:08 +0000 Subject: [erlang-patches] Updates to file:allocate/2 (currently in master-opu) In-Reply-To: <50EED679.3060100@erlang.org> References: <50CB3CCE.2010407@erlang.org> <50CEDDEC.5070301@erlang.org> <50EED679.3060100@erlang.org> Message-ID: Looks good to me. Thanks On Thu, Jan 10, 2013 at 2:55 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-09 18:11, Bj?rn-Egil Dahlberg wrote: > > I think this patch has passed through here in various incarnations the last > two years. I get the feeling that it got missed in some hand over between > people. I'm truly sorry about that. > > This will happen now, > * I will add the patch to integration, i.e. master-opu > * If it passes the final step, i will merge it to master and will be part > of beta testing in R16A release. > * If R16A is fine it will of course also be included in the proper R16B > release. > > > > > So .. this broke during cross-compilation test AC_TRY_RUN did not have an > cross-compilation option. > * Added the safer default option 'no' in cross-compilation > > See: https://github.com/psyeugenic/otp/commits/fdm/file-allocate > > Do you a better solution or should we stick with this? I will test this > option a bit more still. > > Could be reproduced with: > ./otp_build autoconf > ./otp_build configure --enable-sctp > --xcomp-conf=xcomp/erl-xcomp-powerpc-dso-linux-gnu.conf > > (Needs powerpc gcc toolchain for cross compilation in path) > > > > > // Bj?rn-Egil > > 2012/12/17 Fredrik >> >> Hello Filipe! >> The patch is now in the 'master-pu' branch. >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 12/14/2012 04:41 PM, Filipe David Manana wrote: >>> >>> On Fri, Dec 14, 2012 at 2:50 PM, Fredrik wrote: >>>> >>>> Hello Filipe, >>>> Create a new branch and mail me back the fetch command and links, and I >>>> will >>>> fetch and put them into master-pu. >>> >>> Fredrik, >>> >>> I squashed all the commits into a new branch: >>> >>> git fetch git://github.com/fdmanana/otp.git file_allocate_squashed >>> >>> >>> https://github.com/fdmanana/otp/compare/master...file_allocate_squashed.patch >>> https://github.com/fdmanana/otp/compare/master...file_allocate_squashed >>> >>> Thank you >>> >>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> >>>> On 12/14/2012 03:46 PM, Filipe David Manana wrote: >>>>> >>>>> Hello, >>>>> >>>>> I added 2 commits on top of the existing ones for the file:allocate/2 >>>>> patch, currently in master-pu branch. >>>>> >>>>> They can be found in the following branch: >>>>> >>>>> git fetch git://github.com/fdmanana/otp.git file_allocate >>>>> >>>>> >>>>> These commits are the most recent: >>>>> >>>>> https://github.com/fdmanana/otp/commits/file_allocate >>>>> >>>>> Can you pick them, or shall I create a new branch with all of them >>>>> squashed into a single commit? >>>>> >>>>> Thank you >>>>> >>>>> >>> >>> >> >> _______________________________________________ >> 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 > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From fredrik@REDACTED Thu Jan 10 16:06:53 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 16:06:53 +0100 Subject: [erlang-patches] minor ftp and application_controller fixes In-Reply-To: <50BF63FD.6000408@aleynikov.org> References: <50779821.8000307@aleynikov.org> <50BF24A7.8040400@erlang.org> <50BF63FD.6000408@aleynikov.org> Message-ID: <50EED90D.2050101@erlang.org> Hello, I have noticed in our system that we are waiting for tests for this patch. I'm just checking that you have got this info? BR Fredrik Gustafsson Erlang OTP Team On 12/05/2012 04:10 PM, Serge Aleynikov wrote: > It makes sense. Thanks. > > On 12/5/2012 5:40 AM, Henrik Nord wrote: >> Hello >> >> Since ~p causes line breaks that we don't want in the crash dump slogan, >> we don't want to take this directly, but the formatting of strings is >> still so tempting that we would really like a ~p with no line beak... >> Since there is no way to set line length to infinity, we need to just >> set it to "very long" - e.g. >> >> | lists:flatten(io_lib:format("~134217728p", [Term])) >> >> >> ||| >> >> I will update your patch accordingly, Thank you for your contribution! >> >> >> |||| >> >> On 10/12/2012 06:10 AM, Serge Aleynikov wrote: >>> 2. Fixed printout of application crash message on startup. >>> >>> git fetch git@REDACTED:saleyn/otp.git app_controller >>> >>> https://github.com/saleyn/otp/compare/app_controller >>> https://github.com/saleyn/otp/compare/app_controller.patch >>> >>> Regards, >>> >>> Serge >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> -- >> /Henrik Nord Erlang/OTP >> > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From serge@REDACTED Thu Jan 10 16:24:06 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 10:24:06 -0500 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50EED83F.8060702@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> Message-ID: <50EEDD16.2010502@aleynikov.org> That was the fastest acceptance of a patch I ever submitted. ;-) On 1/10/2013 10:03 AM, Fredrik wrote: > Hello Serge, > Your patch is now in the 'master-pu' branch. > Thanks for your contribution! > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >> Added an application:get_env/3 function variant that provides a default >> value for a configuration parameter: >> >> application:get_env(App, Key, Default) -> Value. >> >> git fetch git://github.com/saleyn/otp.git get_env >> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From serge@REDACTED Thu Jan 10 16:30:55 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 10:30:55 -0500 Subject: [erlang-patches] minor ftp and application_controller fixes In-Reply-To: <50EED90D.2050101@erlang.org> References: <50779821.8000307@aleynikov.org> <50BF24A7.8040400@erlang.org> <50BF63FD.6000408@aleynikov.org> <50EED90D.2050101@erlang.org> Message-ID: <50EEDEAF.8000309@aleynikov.org> I am not certain if either of the two bug fixes require me to provide test cases. Neither one of the two functionalities currently have test cases. The application_controller fix is merely a formatting change, and the ftp fix is an introduction of error handling of a missing error code. The later was discussed with Henric Nord, and my last (attached) email on the subject was unanswered. Regards, Serge On 1/10/2013 10:06 AM, Fredrik wrote: > Hello, > I have noticed in our system that we are waiting for tests for this > patch. I'm just checking that you have got this info? > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/05/2012 04:10 PM, Serge Aleynikov wrote: >> It makes sense. Thanks. >> >> On 12/5/2012 5:40 AM, Henrik Nord wrote: >>> Hello >>> >>> Since ~p causes line breaks that we don't want in the crash dump slogan, >>> we don't want to take this directly, but the formatting of strings is >>> still so tempting that we would really like a ~p with no line beak... >>> Since there is no way to set line length to infinity, we need to just >>> set it to "very long" - e.g. >>> >>> | lists:flatten(io_lib:format("~134217728p", [Term])) >>> >>> >>> ||| >>> >>> I will update your patch accordingly, Thank you for your contribution! >>> >>> >>> |||| >>> >>> On 10/12/2012 06:10 AM, Serge Aleynikov wrote: >>>> 2. Fixed printout of application crash message on startup. >>>> >>>> git fetch git@REDACTED:saleyn/otp.git app_controller >>>> >>>> https://github.com/saleyn/otp/compare/app_controller >>>> https://github.com/saleyn/otp/compare/app_controller.patch >>>> >>>> Regards, >>>> >>>> Serge -------------- next part -------------- An embedded message was scrubbed... From: Serge Aleynikov Subject: Re: [erlang-patches] minor ftp and application_controller fixes Date: Tue, 27 Nov 2012 10:17:42 -0500 Size: 3579 URL: From fredrik@REDACTED Thu Jan 10 16:49:24 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 16:49:24 +0100 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> Message-ID: <50EEE304.3030309@erlang.org> Thanks, Re-fetched and I am building it now. BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 04:42 PM, Anthony Ramine wrote: > I've pushed a fix on the tip of the branch, please refetch. > > Regards, > From max.lapshin@REDACTED Thu Jan 10 16:51:08 2013 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 10 Jan 2013 18:51:08 +0300 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50EEDD16.2010502@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> Message-ID: Serge, you seems to be a fast way to pull patch into upstream =) On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov wrote: > That was the fastest acceptance of a patch I ever submitted. ;-) > > On 1/10/2013 10:03 AM, Fredrik wrote: > > Hello Serge, > > Your patch is now in the 'master-pu' branch. > > Thanks for your contribution! > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: > >> Added an application:get_env/3 function variant that provides a default > >> value for a configuration parameter: > >> > >> application:get_env(App, Key, Default) -> Value. > >> > >> git fetch git://github.com/saleyn/otp.git get_env > >> > >> https://github.com/saleyn/otp/compare/erlang:master...get_env > >> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 fredrik@REDACTED Thu Jan 10 16:53:40 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 16:53:40 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> Message-ID: <50EEE404.8070606@erlang.org> The 'master-pu' branch is only for building and testing it with the other pu branches. The real decision for a patch is taken after review. I'm just the first link in the chain ;) BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 04:51 PM, Max Lapshin wrote: > Serge, you seems to be a fast way to pull patch into upstream =) > > > On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov > wrote: > > That was the fastest acceptance of a patch I ever submitted. ;-) > > On 1/10/2013 10:03 AM, Fredrik wrote: > > Hello Serge, > > Your patch is now in the 'master-pu' branch. > > Thanks for your contribution! > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: > >> Added an application:get_env/3 function variant that provides a > default > >> value for a configuration parameter: > >> > >> application:get_env(App, Key, Default) -> Value. > >> > >> git fetch git://github.com/saleyn/otp.git > get_env > >> > >> https://github.com/saleyn/otp/compare/erlang:master...get_env > >> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 fredrik@REDACTED Thu Jan 10 16:54:54 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 16:54:54 +0100 Subject: [erlang-patches] minor ftp and application_controller fixes In-Reply-To: <50EEDEAF.8000309@aleynikov.org> References: <50779821.8000307@aleynikov.org> <50BF24A7.8040400@erlang.org> <50BF63FD.6000408@aleynikov.org> <50EED90D.2050101@erlang.org> <50EEDEAF.8000309@aleynikov.org> Message-ID: <50EEE44E.5060502@erlang.org> I see, I will discuss with responsible developers and get back to you. It is now in 'master-pu' again, for tests to be examined. BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 04:30 PM, Serge Aleynikov wrote: > I am not certain if either of the two bug fixes require me to provide > test cases. Neither one of the two functionalities currently have test > cases. The application_controller fix is merely a formatting change, > and the ftp fix is an introduction of error handling of a missing error > code. The later was discussed with Henric Nord, and my last (attached) > email on the subject was unanswered. > > Regards, > > Serge > > On 1/10/2013 10:06 AM, Fredrik wrote: >> Hello, >> I have noticed in our system that we are waiting for tests for this >> patch. I'm just checking that you have got this info? >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 12/05/2012 04:10 PM, Serge Aleynikov wrote: >>> It makes sense. Thanks. >>> >>> On 12/5/2012 5:40 AM, Henrik Nord wrote: >>>> Hello >>>> >>>> Since ~p causes line breaks that we don't want in the crash dump slogan, >>>> we don't want to take this directly, but the formatting of strings is >>>> still so tempting that we would really like a ~p with no line beak... >>>> Since there is no way to set line length to infinity, we need to just >>>> set it to "very long" - e.g. >>>> >>>> | lists:flatten(io_lib:format("~134217728p", [Term])) >>>> >>>> >>>> ||| >>>> >>>> I will update your patch accordingly, Thank you for your contribution! >>>> >>>> >>>> |||| >>>> >>>> On 10/12/2012 06:10 AM, Serge Aleynikov wrote: >>>>> 2. Fixed printout of application crash message on startup. >>>>> >>>>> git fetch git@REDACTED:saleyn/otp.git app_controller >>>>> >>>>> https://github.com/saleyn/otp/compare/app_controller >>>>> https://github.com/saleyn/otp/compare/app_controller.patch >>>>> >>>>> Regards, >>>>> >>>>> Serge From wallentin.dahlberg@REDACTED Thu Jan 10 17:01:42 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Thu, 10 Jan 2013 17:01:42 +0100 Subject: [erlang-patches] Fix file descriptor leak when using async thread pool In-Reply-To: References: <50C5BD01.2060503@erlang.org> Message-ID: Patch merged Closing issue One down .. several fdm patches to go =) 2013/1/9 Filipe David Manana > Thank you. > Glad to help. > > On Wed, Jan 9, 2013 at 4:18 PM, Bj?rn-Egil Dahlberg > wrote: > > Results confirmed. > > Rebased branch and placed patch into opu. > > Great commit msg =) > > > > // Bj?rn-Egil > > > > 2012/12/10 Filipe David Manana > >> > >> Rebased on top of master branch, as requested. > >> > >> New links: > >> > >> > >> > https://github.com/fdmanana/otp/compare/master...fix_fd_leak_async_thread_pool.patch > >> > >> > https://github.com/fdmanana/otp/compare/master...fix_fd_leak_async_thread_pool > >> > >> git fetch git://github.com/fdmanana/otp.git > >> fix_fd_leak_async_thread_pool > >> > >> > >> On Mon, Dec 10, 2012 at 10:44 AM, Henrik Nord > wrote: > >> > can you rebase this ontop of master > >> > Thank you! > >> > > >> > > >> > > >> > On 12/09/2012 11:55 PM, Filipe David Manana wrote: > >> >> > >> >> > >> >> > >> >> > https://github.com/fdmanana/otp/compare/maint...fix_fd_leak_async_thread_pool.patch > >> >> > >> >> > >> >> > https://github.com/fdmanana/otp/compare/maint...fix_fd_leak_async_thread_pool > >> >> > >> >> git fetch git://github.com/fdmanana/otp.git > >> >> fix_fd_leak_async_thread_pool > >> >> > >> >> > >> > > >> > -- > >> > /Henrik Nord Erlang/OTP > >> > > >> > >> > >> > >> -- > >> Filipe David Manana, > >> > >> "Reasonable men adapt themselves to the world. > >> Unreasonable men adapt the world to themselves. > >> That's why all progress depends on unreasonable men." > >> _______________________________________________ > >> erlang-patches mailing list > >> erlang-patches@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-patches > > > > > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Thu Jan 10 17:19:10 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 10 Jan 2013 17:19:10 +0100 Subject: [erlang-patches] minor ftp and application_controller fixes In-Reply-To: <50EEE44E.5060502@erlang.org> References: <50779821.8000307@aleynikov.org> <50BF24A7.8040400@erlang.org> <50BF63FD.6000408@aleynikov.org> <50EED90D.2050101@erlang.org> <50EEDEAF.8000309@aleynikov.org> <50EEE44E.5060502@erlang.org> Message-ID: <50EEE9FE.80302@erlang.org> Hello, I don't think the reason why no failures is tested is because the reason you are giving. If you are not going to write testcase for this, I will do it when I get time. Maybe I will do it for more scenarios than yours also. Don't know the timeframe for this, but I'll do it when I get time. Is this OK with you? BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 04:54 PM, Fredrik wrote: > I see, > I will discuss with responsible developers and get back to you. > It is now in 'master-pu' again, for tests to be examined. > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 04:30 PM, Serge Aleynikov wrote: >> I am not certain if either of the two bug fixes require me to provide >> test cases. Neither one of the two functionalities currently have test >> cases. The application_controller fix is merely a formatting change, >> and the ftp fix is an introduction of error handling of a missing error >> code. The later was discussed with Henric Nord, and my last (attached) >> email on the subject was unanswered. >> >> Regards, >> >> Serge >> >> On 1/10/2013 10:06 AM, Fredrik wrote: >>> Hello, >>> I have noticed in our system that we are waiting for tests for this >>> patch. I'm just checking that you have got this info? >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/05/2012 04:10 PM, Serge Aleynikov wrote: >>>> It makes sense. Thanks. >>>> >>>> On 12/5/2012 5:40 AM, Henrik Nord wrote: >>>>> Hello >>>>> >>>>> Since ~p causes line breaks that we don't want in the crash dump >>>>> slogan, >>>>> we don't want to take this directly, but the formatting of strings is >>>>> still so tempting that we would really like a ~p with no line beak... >>>>> Since there is no way to set line length to infinity, we need to just >>>>> set it to "very long" - e.g. >>>>> >>>>> | lists:flatten(io_lib:format("~134217728p", [Term])) >>>>> >>>>> >>>>> ||| >>>>> >>>>> I will update your patch accordingly, Thank you for your >>>>> contribution! >>>>> >>>>> >>>>> |||| >>>>> >>>>> On 10/12/2012 06:10 AM, Serge Aleynikov wrote: >>>>>> 2. Fixed printout of application crash message on startup. >>>>>> >>>>>> git fetch git@REDACTED:saleyn/otp.git app_controller >>>>>> >>>>>> https://github.com/saleyn/otp/compare/app_controller >>>>>> https://github.com/saleyn/otp/compare/app_controller.patch >>>>>> >>>>>> Regards, >>>>>> >>>>>> Serge > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From serge@REDACTED Thu Jan 10 18:05:27 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 12:05:27 -0500 Subject: [erlang-patches] minor ftp and application_controller fixes In-Reply-To: <50EEE9FE.80302@erlang.org> References: <50779821.8000307@aleynikov.org> <50BF24A7.8040400@erlang.org> <50BF63FD.6000408@aleynikov.org> <50EED90D.2050101@erlang.org> <50EEDEAF.8000309@aleynikov.org> <50EEE44E.5060502@erlang.org> <50EEE9FE.80302@erlang.org> Message-ID: <50EEF4D7.5080104@aleynikov.org> Sure, please go ahead and do that - it certainly makes sense to write test cases covering many more scenarios than the two ones I fixed. I wrote these patches a while back and wouldn't be able to get to writing the ftp tests for some time. On 1/10/2013 11:19 AM, Fredrik wrote: > Hello, > I don't think the reason why no failures is tested is because the reason > you are giving. > If you are not going to write testcase for this, I will do it when I get > time. > Maybe I will do it for more scenarios than yours also. > Don't know the timeframe for this, but I'll do it when I get time. > Is this OK with you? > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 04:54 PM, Fredrik wrote: >> I see, >> I will discuss with responsible developers and get back to you. >> It is now in 'master-pu' again, for tests to be examined. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/10/2013 04:30 PM, Serge Aleynikov wrote: >>> I am not certain if either of the two bug fixes require me to provide >>> test cases. Neither one of the two functionalities currently have test >>> cases. The application_controller fix is merely a formatting change, >>> and the ftp fix is an introduction of error handling of a missing error >>> code. The later was discussed with Henric Nord, and my last (attached) >>> email on the subject was unanswered. >>> >>> Regards, >>> >>> Serge >>> >>> On 1/10/2013 10:06 AM, Fredrik wrote: >>>> Hello, >>>> I have noticed in our system that we are waiting for tests for this >>>> patch. I'm just checking that you have got this info? >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 12/05/2012 04:10 PM, Serge Aleynikov wrote: >>>>> It makes sense. Thanks. >>>>> >>>>> On 12/5/2012 5:40 AM, Henrik Nord wrote: >>>>>> Hello >>>>>> >>>>>> Since ~p causes line breaks that we don't want in the crash dump >>>>>> slogan, >>>>>> we don't want to take this directly, but the formatting of strings is >>>>>> still so tempting that we would really like a ~p with no line beak... >>>>>> Since there is no way to set line length to infinity, we need to just >>>>>> set it to "very long" - e.g. >>>>>> >>>>>> | lists:flatten(io_lib:format("~134217728p", [Term])) >>>>>> >>>>>> >>>>>> ||| >>>>>> >>>>>> I will update your patch accordingly, Thank you for your >>>>>> contribution! >>>>>> >>>>>> >>>>>> |||| >>>>>> >>>>>> On 10/12/2012 06:10 AM, Serge Aleynikov wrote: >>>>>>> 2. Fixed printout of application crash message on startup. >>>>>>> >>>>>>> git fetch git@REDACTED:saleyn/otp.git app_controller >>>>>>> >>>>>>> https://github.com/saleyn/otp/compare/app_controller >>>>>>> https://github.com/saleyn/otp/compare/app_controller.patch >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Serge >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From serge@REDACTED Thu Jan 10 18:08:17 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 12:08:17 -0500 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> Message-ID: <50EEF581.7060008@aleynikov.org> Not quite - in two days my "new float_to_list/2" patch is celebrating its 2 year anniversary sitting in the awaiting mode. ;-) On 1/10/2013 10:51 AM, Max Lapshin wrote: > Serge, you seems to be a fast way to pull patch into upstream =) > > > On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov > wrote: > > That was the fastest acceptance of a patch I ever submitted. ;-) > > On 1/10/2013 10:03 AM, Fredrik wrote: > > Hello Serge, > > Your patch is now in the 'master-pu' branch. > > Thanks for your contribution! > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: > >> Added an application:get_env/3 function variant that provides a > default > >> value for a configuration parameter: > >> > >> application:get_env(App, Key, Default) -> Value. > >> > >> git fetch git://github.com/saleyn/otp.git > get_env > >> > >> https://github.com/saleyn/otp/compare/erlang:master...get_env > >> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 > > From egil@REDACTED Thu Jan 10 18:41:43 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 10 Jan 2013 18:41:43 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50EEF581.7060008@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> Message-ID: <50EEFD57.20702@erlang.org> On 2013-01-10 18:08, Serge Aleynikov wrote: > Not quite - in two days my "new float_to_list/2" patch is celebrating > its 2 year anniversary sitting in the awaiting mode. ;-) Nice =o However, it is not really as you imply. A simple patch that has been ignored for two years =) I checked in Monitor/OTP: * sal/float_to_list_2 * status: unassigned * location: limbo (not present in any active backlog) * notes: waiting for response from author (noted by Lukas) Lukas is currently on a mountain somewhere in south america so I can't really ask him about it. As I recall, your patch had some controversy about precision? And the last mail conversation mention something about modifications needed and if we were to do it we had to prioritize it along with already planned work. Needless to say, it hasn't been prioritized. http://erlang.org/pipermail/erlang-patches/2012-August/002980.html Personally trying to find time to get binary (text) <-> integer conversions into the backlog. Being realistic, neither your float conversion nor mine will make it to r16. *sadface* // Bj?rn-Egil > > On 1/10/2013 10:51 AM, Max Lapshin wrote: >> Serge, you seems to be a fast way to pull patch into upstream =) >> >> >> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov > > wrote: >> >> That was the fastest acceptance of a patch I ever submitted. ;-) >> >> On 1/10/2013 10:03 AM, Fredrik wrote: >> > Hello Serge, >> > Your patch is now in the 'master-pu' branch. >> > Thanks for your contribution! >> > >> > BR Fredrik Gustafsson >> > Erlang OTP Team >> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >> >> Added an application:get_env/3 function variant that provides a >> default >> >> value for a configuration parameter: >> >> >> >> application:get_env(App, Key, Default) -> Value. >> >> >> >> git fetch git://github.com/saleyn/otp.git >> get_env >> >> >> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >> >> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 egil@REDACTED Thu Jan 10 18:44:52 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 10 Jan 2013 18:44:52 +0100 Subject: [erlang-patches] Support ANSI in the console In-Reply-To: References: <50A4DE26.30402@erlang.org> <50ADEB64.6060601@erlang.org> <50ADED14.6030404@erlang.org> Message-ID: <50EEFE14.7050101@erlang.org> Merged to master as-is. Closing issue. // Bj?rn-Egil On 2013-01-09 17:38, Bj?rn-Egil Dahlberg wrote: > I have placed this patch into opu - i.e. a final integration test > through our daily builds. > > I've reconsidered its impact. It should not have any impact if you > don't use control sequences, which probably is the case in legacy code > since those were filtered anyways. I also agree that not resetting the > console is a user error. > > An easy way to reset the console if problems arise might be a nice > future addition though. > > Your patch will probably be merged later this week if it passes final > integration, shouldn't be a problem though. > > // Bj?rn-Egil > > 2012/12/18 Pedram Nimreezi > > > Yes that was intentionally omitted, as a small percentage of the time > it affected the ( ) brace matching (in smaller terminals).. > Also not properly resetting ANSI colors once a color is set is > technically a user error. > Would agree always resetting is the way to go, if it doesn't affect > anything else. > > On Tue, Dec 18, 2012 at 9:36 AM, Bj?rn-Egil Dahlberg > > wrote: > > This seems nice. > > > > I use colors directly in the bash shell normally. Also via > Erlang. Could be > > nice with colors in erlang shell also. Seems more modern =) > > > > Is: > > --- a/lib/stdlib/src/shell.erl 2011-11-22 08:57:01.000000000 -0500 > > +++ b/lib/stdlib/src/shell.erl 2011-12-10 14:25:58.000000000 -0500 > > @@ -674,6 +674,7 @@ exprs([E0|Es], Bs1, RT, Lf, Ef, Bs0, W) > > [io:requests([{put_chars, VS}, nl]) || W > =:= cmd], > > %% Don't send the result back if it will be > > %% discarded anyway. > > + io:fwrite("\e[0m"), > > V = if > > W =:= pmt -> > > {W,V0}; > > > > intentionally omitted? > > Always clearing the shell might be the way to go =) > > > > // Bj?rn-Egil > > > > 2012/11/22 Henrik Nord > > >> > >> This mailing list + github is the only way atm. > >> > >> We are considering letting a view of our daily build result > page show up > >> to the public via erlang.org > >> That would increase transparency and possible decrease the > turnaround time > >> for patches as the authors themselves could check the test > results of their > >> patches. > >> > >> > >> On 2012-11-22 10:11, Yurii Rashkovskii wrote: > >> > >> Is there any *reliable* way to track what's in pu/master-pu? > >> > >> > >> On Thu, Nov 22, 2012 at 1:07 AM, Henrik Nord > wrote: > >>> > >>> No its in there, it was just removed temporary from the push > >>> > >>> > >>> > >>> On 2012-11-21 19:01, Yurii Rashkovskii wrote: > >>> > >>> Forgive me if I am missing something, but did this patch > somehow not make > >>> it to master-pu? > >>> > >>> > >>> > https://github.com/erlang/otp/blob/master-pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 > >>> > >>> (pu doesn't have it either > >>> > https://github.com/erlang/otp/blob/pu/erts/emulator/drivers/unix/ttsl_drv.c#L915) > >>> > >>> Is it intentional or is it an omission? > >>> > >>> > >>> On Thu, Nov 15, 2012 at 4:20 AM, Henrik Nord > > wrote: > >>>> > >>>> Thank you for your contribution, I have added the patch to > 'master-pu' > >>>> > >>>> > >>>> > >>>> On 2012-11-14 14:49, Pedram Nimreezi wrote: > >>>>> > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L901 > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L599 > >>>>> > >>>>> > https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L609 > >>>> > >>>> > >>>> -- > >>>> /Henrik Nord Erlang/OTP > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-patches mailing list > >>>> erlang-patches@REDACTED > >>>> http://erlang.org/mailman/listinfo/erlang-patches > >>> > >>> > >>> > >>> -- > >>> /Henrik Nord Erlang/OTP > >> > >> > >> > >> -- > >> /Henrik Nord Erlang/OTP > >> > >> > >> _______________________________________________ > >> 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 > > > > > > -- > /* 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 serge@REDACTED Thu Jan 10 18:55:42 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 12:55:42 -0500 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50EEFD57.20702@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> Message-ID: <50EF009E.1080102@aleynikov.org> I was under impression that Lucas would take care of modifications he proposed in the thread you quoted. Meanwhile I'll see if I can find time to do this. Do you already have an implementation of binary <-> integer? If not, maybe I could look at that one as well when I poke around the BIFs, since this is also something very commonly needed. On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-10 18:08, Serge Aleynikov wrote: >> Not quite - in two days my "new float_to_list/2" patch is celebrating >> its 2 year anniversary sitting in the awaiting mode. ;-) > Nice =o > However, it is not really as you imply. A simple patch that has been > ignored for two years =) > > I checked in Monitor/OTP: > * sal/float_to_list_2 > * status: unassigned > * location: limbo (not present in any active backlog) > * notes: waiting for response from author (noted by Lukas) > > Lukas is currently on a mountain somewhere in south america so I can't > really ask him about it. > > As I recall, your patch had some controversy about precision? > > And the last mail conversation mention something about modifications > needed and if we were to do it we had to prioritize it along with > already planned work. Needless to say, it hasn't been prioritized. > > http://erlang.org/pipermail/erlang-patches/2012-August/002980.html > > Personally trying to find time to get binary (text) <-> integer > conversions into the backlog. > > Being realistic, neither your float conversion nor mine will make it to > r16. *sadface* > > > // Bj?rn-Egil > >> >> On 1/10/2013 10:51 AM, Max Lapshin wrote: >>> Serge, you seems to be a fast way to pull patch into upstream =) >>> >>> >>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov >> > wrote: >>> >>> That was the fastest acceptance of a patch I ever submitted. ;-) >>> >>> On 1/10/2013 10:03 AM, Fredrik wrote: >>> > Hello Serge, >>> > Your patch is now in the 'master-pu' branch. >>> > Thanks for your contribution! >>> > >>> > BR Fredrik Gustafsson >>> > Erlang OTP Team >>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>> >> Added an application:get_env/3 function variant that provides a >>> default >>> >> value for a configuration parameter: >>> >> >>> >> application:get_env(App, Key, Default) -> Value. >>> >> >>> >> git fetch git://github.com/saleyn/otp.git >>> get_env >>> >> >>> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >>> >> >>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 aschultz@REDACTED Thu Jan 10 19:07:31 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Thu, 10 Jan 2013 19:07:31 +0100 (CET) Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <50ED8DBD.8080305@erlang.org> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <5072D75B.7060601@erlang.org> <50731907.3090802@erix.ericsson.se> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> Message-ID: <70947956.120394.1357841251485.JavaMail.root@tpip.net> Hi, I'll work on this over the weekend, I expect to have a new version ready on Monday. Andreas ----- Original Message ----- > Hello Andreas, > Your patch has finally been into review and the response was: > " > > * The patch introduces new API options without documenting them. > * The patch introduces new include file ssl_srp.hrl that I think shall > be internal and put in src. It is undesirable to have records in the > user API as it makes the user application compile time dependent on > our code, better to use a proplist and then create the record > internally. (Yes "sslsocket" is a record due to legacy) > * The patch introduces new include file ssl_srp_primes.hrl I think it > feels better to input such values as atoms and internaly uses the > macros defined in this file, that would be more consistent with the > rest of the API. > * Functions in crypto being named TLS something seems a little > strange, is this necessary?! > > " > Please correct this and give me a notice when it is done. > > BR Fredrik Gustafsson > Erlang OTP Team > On 10/12/2012 11:38 AM, Henrik Nord wrote: > > refetching > > > > On 10/12/2012 10:27 AM, Andreas Schultz wrote: > >> Hi Henrik, > >> > >> When I rebased my changes to the current master, a change crept in that > >> shouldn't have: > >> > >> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 > >> > >> > >> I have removed it from my tree and pushed it. > >> > >> Andreas > >> > >> ----- Original Message ----- > >>> Thanks, I will refetch! > >>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: > >>>> Hi, > >>>> > >>>> I have pushed a change that should fix the compile error. The > >>>> buffer has > >>>> a fixed length now. > >>>> > >>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 > >>>> > >>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch > >>>> > >>>> > >>>> Andreas > >>>> > >>>> ----- Original Message ----- > >>>>> Does not compile on Windows. > >>>>> > >>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with > >>>>> dynamic > >>>>> size is not supported by the C standard we use. > >>>>> Use a static array instead, presuming that there is a reasonable > >>>>> upper > >>>>> limit of its size. > >>>>> > >>>>> /Sverker, Erlang/OTP > >>>>> > >>>>> > >>>>> > >>>>> Henrik Nord wrote: > >>>>>> Hi > >>>>>> > >>>>>> I have added your branch to 'master'pu' for testing. > >>>>>> Thank you for your contribution! > >>>>>> > >>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Tree is rebased onto latest master. > >>>>>>> > >>>>>>> Andreas > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> Would you be so kind as to rebase this branch upon the latest > >>>>>>>> 'master' > >>>>>>>> > >>>>>>>> Thank you for your contribution! > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC > >>>>>>>>> 5487 > >>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and > >>>>>>>>> usefulness > >>>>>>>>> of those ciphers is rather limited, the one notable exception > >>>>>>>>> being > >>>>>>>>> the eID server protocol for German national identity cards > >>>>>>>>> (nPA). > >>>>>>>>> > >>>>>>>>> The test suite can only verify some PSK suites against openssl > >>>>>>>>> as > >>>>>>>>> currently no openssl version supports them all. There is patch > >>>>>>>>> that add some to openssl, but it has not been incorporated > >>>>>>>>> into > >>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK > >>>>>>>>> suites > >>>>>>>>> and I have manually tested interoperability. > >>>>>>>>> > >>>>>>>>> Patch info: > >>>>>>>>> > >>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>> tls-psk-srp-suites > >>>>>>>>> > >>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>>>>>>>> > >>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Andreas > >>>>>>>> -- > >>>>>>>> /Henrik Nord Erlang/OTP > >>>>>>>> > >>>>>>>> > >>> -- > >>> /Henrik Nord Erlang/OTP > >>> > >>> > > > > -- -- 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 mc@REDACTED Thu Jan 10 19:26:15 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Thu, 10 Jan 2013 13:26:15 -0500 Subject: [erlang-patches] Support ANSI in the console In-Reply-To: <50EEFE14.7050101@erlang.org> References: <50A4DE26.30402@erlang.org> <50ADEB64.6060601@erlang.org> <50ADED14.6030404@erlang.org> <50EEFE14.7050101@erlang.org> Message-ID: Excellent! On Thu, Jan 10, 2013 at 12:44 PM, Bj?rn-Egil Dahlberg wrote: > Merged to master as-is. > Closing issue. > > // Bj?rn-Egil > > On 2013-01-09 17:38, Bj?rn-Egil Dahlberg wrote: > > I have placed this patch into opu - i.e. a final integration test through > our daily builds. > > I've reconsidered its impact. It should not have any impact if you don't use > control sequences, which probably is the case in legacy code since those > were filtered anyways. I also agree that not resetting the console is a user > error. > > An easy way to reset the console if problems arise might be a nice future > addition though. > > Your patch will probably be merged later this week if it passes final > integration, shouldn't be a problem though. > > // Bj?rn-Egil > > 2012/12/18 Pedram Nimreezi >> >> Yes that was intentionally omitted, as a small percentage of the time >> it affected the ( ) brace matching (in smaller terminals).. >> Also not properly resetting ANSI colors once a color is set is >> technically a user error. >> Would agree always resetting is the way to go, if it doesn't affect >> anything else. >> >> On Tue, Dec 18, 2012 at 9:36 AM, Bj?rn-Egil Dahlberg >> wrote: >> > This seems nice. >> > >> > I use colors directly in the bash shell normally. Also via Erlang. Could >> > be >> > nice with colors in erlang shell also. Seems more modern =) >> > >> > Is: >> > --- a/lib/stdlib/src/shell.erl 2011-11-22 08:57:01.000000000 -0500 >> > +++ b/lib/stdlib/src/shell.erl 2011-12-10 14:25:58.000000000 -0500 >> > @@ -674,6 +674,7 @@ exprs([E0|Es], Bs1, RT, Lf, Ef, Bs0, W) >> > [io:requests([{put_chars, VS}, nl]) || W =:= cmd], >> > %% Don't send the result back if it will be >> > %% discarded anyway. >> > + io:fwrite("\e[0m"), >> > V = if >> > W =:= pmt -> >> > {W,V0}; >> > >> > intentionally omitted? >> > Always clearing the shell might be the way to go =) >> > >> > // Bj?rn-Egil >> > >> > 2012/11/22 Henrik Nord >> >> >> >> This mailing list + github is the only way atm. >> >> >> >> We are considering letting a view of our daily build result page show >> >> up >> >> to the public via erlang.org >> >> That would increase transparency and possible decrease the turnaround >> >> time >> >> for patches as the authors themselves could check the test results of >> >> their >> >> patches. >> >> >> >> >> >> On 2012-11-22 10:11, Yurii Rashkovskii wrote: >> >> >> >> Is there any *reliable* way to track what's in pu/master-pu? >> >> >> >> >> >> On Thu, Nov 22, 2012 at 1:07 AM, Henrik Nord wrote: >> >>> >> >>> No its in there, it was just removed temporary from the push >> >>> >> >>> >> >>> >> >>> On 2012-11-21 19:01, Yurii Rashkovskii wrote: >> >>> >> >>> Forgive me if I am missing something, but did this patch somehow not >> >>> make >> >>> it to master-pu? >> >>> >> >>> >> >>> >> >>> https://github.com/erlang/otp/blob/master-pu/erts/emulator/drivers/unix/ttsl_drv.c#L915 >> >>> >> >>> (pu doesn't have it either >> >>> >> >>> https://github.com/erlang/otp/blob/pu/erts/emulator/drivers/unix/ttsl_drv.c#L915) >> >>> >> >>> Is it intentional or is it an omission? >> >>> >> >>> >> >>> On Thu, Nov 15, 2012 at 4:20 AM, Henrik Nord >> >>> wrote: >> >>>> >> >>>> Thank you for your contribution, I have added the patch to >> >>>> 'master-pu' >> >>>> >> >>>> >> >>>> >> >>>> On 2012-11-14 14:49, Pedram Nimreezi wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L901 >> >>>>> >> >>>>> >> >>>>> https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L599 >> >>>>> >> >>>>> >> >>>>> https://github.com/DeadZen/otp/blob/d3e3d51dbb21f0fdb125becacb80e34d0565fff7/erts/emulator/drivers/unix/ttsl_drv.c#L609 >> >>>> >> >>>> >> >>>> -- >> >>>> /Henrik Nord Erlang/OTP >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> erlang-patches mailing list >> >>>> erlang-patches@REDACTED >> >>>> http://erlang.org/mailman/listinfo/erlang-patches >> >>> >> >>> >> >>> >> >>> -- >> >>> /Henrik Nord Erlang/OTP >> >> >> >> >> >> >> >> -- >> >> /Henrik Nord Erlang/OTP >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> /* 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 > -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From egil@REDACTED Thu Jan 10 19:50:47 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 10 Jan 2013 19:50:47 +0100 Subject: [erlang-patches] [patch] binary to/from integer (was: Added application:get_env/3) In-Reply-To: <50EF009E.1080102@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> Message-ID: <50EF0D87.1040405@erlang.org> On 2013-01-10 18:55, Serge Aleynikov wrote: > I was under impression that Lucas would take care of modifications he > proposed in the thread you quoted. Meanwhile I'll see if I can find > time to do this. I think the key words were "if it gets prioritized" =) Granted, we could be more clear on intention. I think in this case we supposedly had time which drastically changed at some point .. > > Do you already have an implementation of binary <-> integer? If not, > maybe I could look at that one as well when I poke around the BIFs, > since this is also something very commonly needed. Right, what I did was to take the list conversions to integer and made it binary comprehensible. That was the easy bit. However, Now I have * erlang:binary_to_integer/1 and * erlang:integer_to_binary/1 which seems fine. The compiler will auto-import them as well. After I did that I began to reconsider this choice. Perhaps it should be * binary:to_integer/1 and binary:from_integer/1 instead? Or, * binary:string_from_integer/1 and binary:string_to_integer/1, emphasizing that this is a textual representation of integer in binary format. Then I got a headache. The arguments for the first one (current) is: * list_to_integer has same type of ideas, same type of behavior. Avoids confusion. The arguments against the first one, * Clutters the erlang module with yet more BIF's * We already have a binary module, let's use it! * And finally: avoid confusion! Does erlang:integer_to_binary(102341) mean <<0,1,143,197>> or <<"102341">> ? I'm leaning towards the latter. Also, I didn't implement base conversion, so that needs doing. I think the list conversion is done in Erlang which seems backwards. Anyways, the current implementation is at: https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer But the real work is taking a position on the API and consider the different ramifications. I still have that headache .. Yet another also, perhaps this implementation isn't the way to go. From what I remember erlang:binary_to_integer didn't have the speedup I first envisioned. Ofc, it was faster than doing binary_to_list(list_to_integer(X)) but binary_to_integer was on par with this list_to_integer .. which seemed a bit off. I want to refrain from using strtol directly (I think that implementation is similar anyways and we still need to handle bignums). I think I want to change the current implementation to taking the base as argument to the BIF and perhaps using arity one function as an erlang wrapper. (And doing the same for list_to_integer). The arguments against that is, surely the arity one functions is far more used and it should be slightly faster to that call directly. // Bj?rn-Egil > > On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-10 18:08, Serge Aleynikov wrote: >>> Not quite - in two days my "new float_to_list/2" patch is celebrating >>> its 2 year anniversary sitting in the awaiting mode. ;-) >> Nice =o >> However, it is not really as you imply. A simple patch that has been >> ignored for two years =) >> >> I checked in Monitor/OTP: >> * sal/float_to_list_2 >> * status: unassigned >> * location: limbo (not present in any active backlog) >> * notes: waiting for response from author (noted by Lukas) >> >> Lukas is currently on a mountain somewhere in south america so I can't >> really ask him about it. >> >> As I recall, your patch had some controversy about precision? >> >> And the last mail conversation mention something about modifications >> needed and if we were to do it we had to prioritize it along with >> already planned work. Needless to say, it hasn't been prioritized. >> >> http://erlang.org/pipermail/erlang-patches/2012-August/002980.html >> >> Personally trying to find time to get binary (text) <-> integer >> conversions into the backlog. >> >> Being realistic, neither your float conversion nor mine will make it to >> r16. *sadface* >> >> >> // Bj?rn-Egil >> >>> On 1/10/2013 10:51 AM, Max Lapshin wrote: >>>> Serge, you seems to be a fast way to pull patch into upstream =) >>>> >>>> >>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov >>> > wrote: >>>> >>>> That was the fastest acceptance of a patch I ever submitted. ;-) >>>> >>>> On 1/10/2013 10:03 AM, Fredrik wrote: >>>> > Hello Serge, >>>> > Your patch is now in the 'master-pu' branch. >>>> > Thanks for your contribution! >>>> > >>>> > BR Fredrik Gustafsson >>>> > Erlang OTP Team >>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>> >> Added an application:get_env/3 function variant that provides a >>>> default >>>> >> value for a configuration parameter: >>>> >> >>>> >> application:get_env(App, Key, Default) -> Value. >>>> >> >>>> >> git fetch git://github.com/saleyn/otp.git >>>> get_env >>>> >> >>>> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>> >> >>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 Thu Jan 10 20:31:34 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 14:31:34 -0500 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <50EF0D87.1040405@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> Message-ID: <50EF1716.5050402@aleynikov.org> Thanks for the explanation! The API naming is a headache indeed. It does make sense to define these functions in the binary module. Though while binary:string_to_integer/1 is intuitive, I think binary:integer_to_string/1 would be a more intuitive name than binary:string_from_integer/1 (this also would be more consistent with binary:{bin,list}_to_{list,bin}. On 1/10/2013 1:50 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-10 18:55, Serge Aleynikov wrote: >> I was under impression that Lucas would take care of modifications he >> proposed in the thread you quoted. Meanwhile I'll see if I can find >> time to do this. > I think the key words were "if it gets prioritized" =) > Granted, we could be more clear on intention. I think in this case we > supposedly had time which drastically changed at some point .. > >> >> Do you already have an implementation of binary <-> integer? If not, >> maybe I could look at that one as well when I poke around the BIFs, >> since this is also something very commonly needed. > Right, what I did was to take the list conversions to integer and made > it binary comprehensible. > > That was the easy bit. > > However, > Now I have > * erlang:binary_to_integer/1 and > * erlang:integer_to_binary/1 > which seems fine. The compiler will auto-import them as well. > > After I did that I began to reconsider this choice. Perhaps it should be > > * binary:to_integer/1 and binary:from_integer/1 instead? Or, > * binary:string_from_integer/1 and binary:string_to_integer/1, > emphasizing that this is a textual representation of integer in binary > format. Then I got a headache. > > The arguments for the first one (current) is: > * list_to_integer has same type of ideas, same type of behavior. Avoids > confusion. > The arguments against the first one, > * Clutters the erlang module with yet more BIF's > * We already have a binary module, let's use it! > * And finally: avoid confusion! Does erlang:integer_to_binary(102341) > mean <<0,1,143,197>> or <<"102341">> ? > > I'm leaning towards the latter. > > Also, I didn't implement base conversion, so that needs doing. I think > the list conversion is done in Erlang which seems backwards. > > Anyways, the current implementation is at: > https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer > > But the real work is taking a position on the API and consider the > different ramifications. I still have that headache .. > > Yet another also, perhaps this implementation isn't the way to go. From > what I remember erlang:binary_to_integer didn't have the speedup I first > envisioned. Ofc, it was faster than doing > binary_to_list(list_to_integer(X)) but binary_to_integer was on par with > this list_to_integer .. which seemed a bit off. > > I want to refrain from using strtol directly (I think that > implementation is similar anyways and we still need to handle bignums). > > I think I want to change the current implementation to taking the base > as argument to the BIF and perhaps using arity one function as an erlang > wrapper. (And doing the same for list_to_integer). The arguments against > that is, surely the arity one functions is far more used and it should > be slightly faster to that call directly. > > // Bj?rn-Egil > >> >> On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: >>> On 2013-01-10 18:08, Serge Aleynikov wrote: >>>> Not quite - in two days my "new float_to_list/2" patch is celebrating >>>> its 2 year anniversary sitting in the awaiting mode. ;-) >>> Nice =o >>> However, it is not really as you imply. A simple patch that has been >>> ignored for two years =) >>> >>> I checked in Monitor/OTP: >>> * sal/float_to_list_2 >>> * status: unassigned >>> * location: limbo (not present in any active backlog) >>> * notes: waiting for response from author (noted by Lukas) >>> >>> Lukas is currently on a mountain somewhere in south america so I can't >>> really ask him about it. >>> >>> As I recall, your patch had some controversy about precision? >>> >>> And the last mail conversation mention something about modifications >>> needed and if we were to do it we had to prioritize it along with >>> already planned work. Needless to say, it hasn't been prioritized. >>> >>> http://erlang.org/pipermail/erlang-patches/2012-August/002980.html >>> >>> Personally trying to find time to get binary (text) <-> integer >>> conversions into the backlog. >>> >>> Being realistic, neither your float conversion nor mine will make it to >>> r16. *sadface* >>> >>> >>> // Bj?rn-Egil >>> >>>> On 1/10/2013 10:51 AM, Max Lapshin wrote: >>>>> Serge, you seems to be a fast way to pull patch into upstream =) >>>>> >>>>> >>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov >>>> > wrote: >>>>> >>>>> That was the fastest acceptance of a patch I ever submitted. >>>>> ;-) >>>>> >>>>> On 1/10/2013 10:03 AM, Fredrik wrote: >>>>> > Hello Serge, >>>>> > Your patch is now in the 'master-pu' branch. >>>>> > Thanks for your contribution! >>>>> > >>>>> > BR Fredrik Gustafsson >>>>> > Erlang OTP Team >>>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>> >> Added an application:get_env/3 function variant that >>>>> provides a >>>>> default >>>>> >> value for a configuration parameter: >>>>> >> >>>>> >> application:get_env(App, Key, Default) -> Value. >>>>> >> >>>>> >> git fetch git://github.com/saleyn/otp.git >>>>> get_env >>>>> >> >>>>> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>>> >> >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 essen@REDACTED Thu Jan 10 23:05:30 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Thu, 10 Jan 2013 23:05:30 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <50EF1716.5050402@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> Message-ID: <50EF3B2A.50500@ninenines.eu> binary:integer_to_string/1 is hardly intuitive. Especially if you write it like this: Module = binary, %% ... Module:integer_to_string(123) Do you get a binary() or a string()? If you create a function type1_to_type2 it's much better if type1 and type2 correspond to actual types. Wherever you place it I don't think it should be named anything other than integer_to_binary. However it should be autoimported, because writing integer_to_binary first and then remembering the function doesn't exist is what many of us do regularly. We already have the reflex, we only miss the call to be available. On 01/10/2013 08:31 PM, Serge Aleynikov wrote: > Thanks for the explanation! The API naming is a headache indeed. > > It does make sense to define these functions in the binary module. > Though while binary:string_to_integer/1 is intuitive, I think > binary:integer_to_string/1 would be a more intuitive name than > binary:string_from_integer/1 (this also would be more consistent with > binary:{bin,list}_to_{list,bin}. > > On 1/10/2013 1:50 PM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-10 18:55, Serge Aleynikov wrote: >>> I was under impression that Lucas would take care of modifications he >>> proposed in the thread you quoted. Meanwhile I'll see if I can find >>> time to do this. >> I think the key words were "if it gets prioritized" =) >> Granted, we could be more clear on intention. I think in this case we >> supposedly had time which drastically changed at some point .. >> >>> >>> Do you already have an implementation of binary <-> integer? If not, >>> maybe I could look at that one as well when I poke around the BIFs, >>> since this is also something very commonly needed. >> Right, what I did was to take the list conversions to integer and made >> it binary comprehensible. >> >> That was the easy bit. >> >> However, >> Now I have >> * erlang:binary_to_integer/1 and >> * erlang:integer_to_binary/1 >> which seems fine. The compiler will auto-import them as well. >> >> After I did that I began to reconsider this choice. Perhaps it should be >> >> * binary:to_integer/1 and binary:from_integer/1 instead? Or, >> * binary:string_from_integer/1 and binary:string_to_integer/1, >> emphasizing that this is a textual representation of integer in binary >> format. Then I got a headache. >> >> The arguments for the first one (current) is: >> * list_to_integer has same type of ideas, same type of behavior. Avoids >> confusion. >> The arguments against the first one, >> * Clutters the erlang module with yet more BIF's >> * We already have a binary module, let's use it! >> * And finally: avoid confusion! Does erlang:integer_to_binary(102341) >> mean <<0,1,143,197>> or <<"102341">> ? >> >> I'm leaning towards the latter. >> >> Also, I didn't implement base conversion, so that needs doing. I think >> the list conversion is done in Erlang which seems backwards. >> >> Anyways, the current implementation is at: >> https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer >> >> But the real work is taking a position on the API and consider the >> different ramifications. I still have that headache .. >> >> Yet another also, perhaps this implementation isn't the way to go. From >> what I remember erlang:binary_to_integer didn't have the speedup I first >> envisioned. Ofc, it was faster than doing >> binary_to_list(list_to_integer(X)) but binary_to_integer was on par with >> this list_to_integer .. which seemed a bit off. >> >> I want to refrain from using strtol directly (I think that >> implementation is similar anyways and we still need to handle bignums). >> >> I think I want to change the current implementation to taking the base >> as argument to the BIF and perhaps using arity one function as an erlang >> wrapper. (And doing the same for list_to_integer). The arguments against >> that is, surely the arity one functions is far more used and it should >> be slightly faster to that call directly. >> >> // Bj?rn-Egil >> >>> >>> On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: >>>> On 2013-01-10 18:08, Serge Aleynikov wrote: >>>>> Not quite - in two days my "new float_to_list/2" patch is celebrating >>>>> its 2 year anniversary sitting in the awaiting mode. ;-) >>>> Nice =o >>>> However, it is not really as you imply. A simple patch that has been >>>> ignored for two years =) >>>> >>>> I checked in Monitor/OTP: >>>> * sal/float_to_list_2 >>>> * status: unassigned >>>> * location: limbo (not present in any active backlog) >>>> * notes: waiting for response from author (noted by Lukas) >>>> >>>> Lukas is currently on a mountain somewhere in south america so I can't >>>> really ask him about it. >>>> >>>> As I recall, your patch had some controversy about precision? >>>> >>>> And the last mail conversation mention something about modifications >>>> needed and if we were to do it we had to prioritize it along with >>>> already planned work. Needless to say, it hasn't been prioritized. >>>> >>>> http://erlang.org/pipermail/erlang-patches/2012-August/002980.html >>>> >>>> Personally trying to find time to get binary (text) <-> integer >>>> conversions into the backlog. >>>> >>>> Being realistic, neither your float conversion nor mine will make it to >>>> r16. *sadface* >>>> >>>> >>>> // Bj?rn-Egil >>>> >>>>> On 1/10/2013 10:51 AM, Max Lapshin wrote: >>>>>> Serge, you seems to be a fast way to pull patch into upstream =) >>>>>> >>>>>> >>>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov >>>>> > wrote: >>>>>> >>>>>> That was the fastest acceptance of a patch I ever submitted. >>>>>> ;-) >>>>>> >>>>>> On 1/10/2013 10:03 AM, Fredrik wrote: >>>>>> > Hello Serge, >>>>>> > Your patch is now in the 'master-pu' branch. >>>>>> > Thanks for your contribution! >>>>>> > >>>>>> > BR Fredrik Gustafsson >>>>>> > Erlang OTP Team >>>>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>>> >> Added an application:get_env/3 function variant that >>>>>> provides a >>>>>> default >>>>>> >> value for a configuration parameter: >>>>>> >> >>>>>> >> application:get_env(App, Key, Default) -> Value. >>>>>> >> >>>>>> >> git fetch git://github.com/saleyn/otp.git >>>>>> get_env >>>>>> >> >>>>>> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>>>> >> >>>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From bob@REDACTED Thu Jan 10 23:13:32 2013 From: bob@REDACTED (Bob Ippolito) Date: Thu, 10 Jan 2013 14:13:32 -0800 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <50EF3B2A.50500@ninenines.eu> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> Message-ID: The purpose of integer_to_binary still isn't totally obvious from the name or output type, maybe it's digits, maybe it's the big endian encoding of that integer (which is closer to the behavior of binary_to_term / term_to_binary). For the more seasoned Erlang developer, I think they would expect it to behave like integer_to_string, but what about newer users? On Thu, Jan 10, 2013 at 2:05 PM, Lo?c Hoguin wrote: > binary:integer_to_string/1 is hardly intuitive. Especially if you write it > like this: > > Module = binary, > %% ... > Module:integer_to_string(123) > > Do you get a binary() or a string()? > > If you create a function type1_to_type2 it's much better if type1 and > type2 correspond to actual types. > > Wherever you place it I don't think it should be named anything other than > integer_to_binary. However it should be autoimported, because writing > integer_to_binary first and then remembering the function doesn't exist is > what many of us do regularly. We already have the reflex, we only miss the > call to be available. > > > On 01/10/2013 08:31 PM, Serge Aleynikov wrote: > >> Thanks for the explanation! The API naming is a headache indeed. >> >> It does make sense to define these functions in the binary module. >> Though while binary:string_to_integer/1 is intuitive, I think >> binary:integer_to_string/1 would be a more intuitive name than >> binary:string_from_integer/1 (this also would be more consistent with >> binary:{bin,list}_to_{list,**bin}. >> >> On 1/10/2013 1:50 PM, Bj?rn-Egil Dahlberg wrote: >> >>> On 2013-01-10 18:55, Serge Aleynikov wrote: >>> >>>> I was under impression that Lucas would take care of modifications he >>>> proposed in the thread you quoted. Meanwhile I'll see if I can find >>>> time to do this. >>>> >>> I think the key words were "if it gets prioritized" =) >>> Granted, we could be more clear on intention. I think in this case we >>> supposedly had time which drastically changed at some point .. >>> >>> >>>> Do you already have an implementation of binary <-> integer? If not, >>>> maybe I could look at that one as well when I poke around the BIFs, >>>> since this is also something very commonly needed. >>>> >>> Right, what I did was to take the list conversions to integer and made >>> it binary comprehensible. >>> >>> That was the easy bit. >>> >>> However, >>> Now I have >>> * erlang:binary_to_integer/1 and >>> * erlang:integer_to_binary/1 >>> which seems fine. The compiler will auto-import them as well. >>> >>> After I did that I began to reconsider this choice. Perhaps it should be >>> >>> * binary:to_integer/1 and binary:from_integer/1 instead? Or, >>> * binary:string_from_integer/1 and binary:string_to_integer/1, >>> emphasizing that this is a textual representation of integer in binary >>> format. Then I got a headache. >>> >>> The arguments for the first one (current) is: >>> * list_to_integer has same type of ideas, same type of behavior. Avoids >>> confusion. >>> The arguments against the first one, >>> * Clutters the erlang module with yet more BIF's >>> * We already have a binary module, let's use it! >>> * And finally: avoid confusion! Does erlang:integer_to_binary(**102341) >>> mean <<0,1,143,197>> or <<"102341">> ? >>> >>> I'm leaning towards the latter. >>> >>> Also, I didn't implement base conversion, so that needs doing. I think >>> the list conversion is done in Erlang which seems backwards. >>> >>> Anyways, the current implementation is at: >>> https://github.com/psyeugenic/**otp/commits/egil/r16/binary_**to_integer >>> >>> But the real work is taking a position on the API and consider the >>> different ramifications. I still have that headache .. >>> >>> Yet another also, perhaps this implementation isn't the way to go. From >>> what I remember erlang:binary_to_integer didn't have the speedup I first >>> envisioned. Ofc, it was faster than doing >>> binary_to_list(list_to_**integer(X)) but binary_to_integer was on par >>> with >>> this list_to_integer .. which seemed a bit off. >>> >>> I want to refrain from using strtol directly (I think that >>> implementation is similar anyways and we still need to handle bignums). >>> >>> I think I want to change the current implementation to taking the base >>> as argument to the BIF and perhaps using arity one function as an erlang >>> wrapper. (And doing the same for list_to_integer). The arguments against >>> that is, surely the arity one functions is far more used and it should >>> be slightly faster to that call directly. >>> >>> // Bj?rn-Egil >>> >>> >>>> On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: >>>> >>>>> On 2013-01-10 18:08, Serge Aleynikov wrote: >>>>> >>>>>> Not quite - in two days my "new float_to_list/2" patch is celebrating >>>>>> its 2 year anniversary sitting in the awaiting mode. ;-) >>>>>> >>>>> Nice =o >>>>> However, it is not really as you imply. A simple patch that has been >>>>> ignored for two years =) >>>>> >>>>> I checked in Monitor/OTP: >>>>> * sal/float_to_list_2 >>>>> * status: unassigned >>>>> * location: limbo (not present in any active backlog) >>>>> * notes: waiting for response from author (noted by Lukas) >>>>> >>>>> Lukas is currently on a mountain somewhere in south america so I can't >>>>> really ask him about it. >>>>> >>>>> As I recall, your patch had some controversy about precision? >>>>> >>>>> And the last mail conversation mention something about modifications >>>>> needed and if we were to do it we had to prioritize it along with >>>>> already planned work. Needless to say, it hasn't been prioritized. >>>>> >>>>> http://erlang.org/pipermail/**erlang-patches/2012-August/**002980.html >>>>> >>>>> Personally trying to find time to get binary (text) <-> integer >>>>> conversions into the backlog. >>>>> >>>>> Being realistic, neither your float conversion nor mine will make it to >>>>> r16. *sadface* >>>>> >>>>> >>>>> // Bj?rn-Egil >>>>> >>>>> On 1/10/2013 10:51 AM, Max Lapshin wrote: >>>>>> >>>>>>> Serge, you seems to be a fast way to pull patch into upstream =) >>>>>>> >>>>>>> >>>>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov < >>>>>>> serge@REDACTED >>>>>>> > wrote: >>>>>>> >>>>>>> That was the fastest acceptance of a patch I ever submitted. >>>>>>> ;-) >>>>>>> >>>>>>> On 1/10/2013 10:03 AM, Fredrik wrote: >>>>>>> > Hello Serge, >>>>>>> > Your patch is now in the 'master-pu' branch. >>>>>>> > Thanks for your contribution! >>>>>>> > >>>>>>> > BR Fredrik Gustafsson >>>>>>> > Erlang OTP Team >>>>>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>>>> >> Added an application:get_env/3 function variant that >>>>>>> provides a >>>>>>> default >>>>>>> >> value for a configuration parameter: >>>>>>> >> >>>>>>> >> application:get_env(App, Key, Default) -> Value. >>>>>>> >> >>>>>>> >> git fetch git://github.com/saleyn/otp.**git >>>>>>> > >>>>>>> get_env >>>>>>> >> >>>>>>> >> https://github.com/saleyn/otp/** >>>>>>> compare/erlang:master...get_**env >>>>>>> >> >>>>>>> https://github.com/saleyn/otp/**compare/erlang:master...get_** >>>>>>> env.patch >>>>>>> >> ______________________________**_________________ >>>>>>> >> erlang-patches mailing list >>>>>>> >> erlang-patches@REDACTED >>>>>> org > >>>>>>> >> 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 >> >> > > -- > Lo?c Hoguin > Erlang Cowboy > Nine Nines > http://ninenines.eu > > ______________________________**_________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/**listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge@REDACTED Thu Jan 10 23:32:25 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 17:32:25 -0500 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> Message-ID: <50EF4179.3090703@aleynikov.org> This is exactly what Bj?rn-Egil was talking about below ("Does erlang:integer_to_binary(102341) mean <<0,1,143,197>> or <<"102341">>"). I can think of two other alternatives: binary:integer_to_binstring/1 & binary:binstring_to_integer/1 binary:integer_to_text/1 & binary:text_to_integer/1 On 1/10/2013 5:13 PM, Bob Ippolito wrote: > The purpose of integer_to_binary still isn't totally obvious from the > name or output type, maybe it's digits, maybe it's the big endian > encoding of that integer (which is closer to the behavior of > binary_to_term / term_to_binary). For the more seasoned Erlang > developer, I think they would expect it to behave like > integer_to_string, but what about newer users? > > > > On Thu, Jan 10, 2013 at 2:05 PM, Lo?c Hoguin > wrote: > > binary:integer_to_string/1 is hardly intuitive. Especially if you > write it like this: > > Module = binary, > %% ... > Module:integer_to_string(123) > > Do you get a binary() or a string()? > > If you create a function type1_to_type2 it's much better if type1 > and type2 correspond to actual types. > > Wherever you place it I don't think it should be named anything > other than integer_to_binary. However it should be autoimported, > because writing integer_to_binary first and then remembering the > function doesn't exist is what many of us do regularly. We already > have the reflex, we only miss the call to be available. > > > On 01/10/2013 08:31 PM, Serge Aleynikov wrote: > > Thanks for the explanation! The API naming is a headache indeed. > > It does make sense to define these functions in the binary module. > Though while binary:string_to_integer/1 is intuitive, I think > binary:integer_to_string/1 would be a more intuitive name than > binary:string_from_integer/1 (this also would be more consistent > with > binary:{bin,list}_to_{list,__bin}. > > On 1/10/2013 1:50 PM, Bj?rn-Egil Dahlberg wrote: > > On 2013-01-10 18:55, Serge Aleynikov wrote: > > I was under impression that Lucas would take care of > modifications he > proposed in the thread you quoted. Meanwhile I'll see > if I can find > time to do this. > > I think the key words were "if it gets prioritized" =) > Granted, we could be more clear on intention. I think in > this case we > supposedly had time which drastically changed at some point .. > > > Do you already have an implementation of binary <-> > integer? If not, > maybe I could look at that one as well when I poke > around the BIFs, > since this is also something very commonly needed. > > Right, what I did was to take the list conversions to > integer and made > it binary comprehensible. > > That was the easy bit. > > However, > Now I have > * erlang:binary_to_integer/1 and > * erlang:integer_to_binary/1 > which seems fine. The compiler will auto-import them as well. > > After I did that I began to reconsider this choice. Perhaps > it should be > > * binary:to_integer/1 and binary:from_integer/1 instead? Or, > * binary:string_from_integer/1 and binary:string_to_integer/1, > emphasizing that this is a textual representation of integer > in binary > format. Then I got a headache. > > The arguments for the first one (current) is: > * list_to_integer has same type of ideas, same type of > behavior. Avoids > confusion. > The arguments against the first one, > * Clutters the erlang module with yet more BIF's > * We already have a binary module, let's use it! > * And finally: avoid confusion! Does > erlang:integer_to_binary(__102341) > mean <<0,1,143,197>> or <<"102341">> ? > > I'm leaning towards the latter. > > Also, I didn't implement base conversion, so that needs > doing. I think > the list conversion is done in Erlang which seems backwards. > > Anyways, the current implementation is at: > https://github.com/psyeugenic/__otp/commits/egil/r16/binary___to_integer > > > But the real work is taking a position on the API and > consider the > different ramifications. I still have that headache .. > > Yet another also, perhaps this implementation isn't the way > to go. From > what I remember erlang:binary_to_integer didn't have the > speedup I first > envisioned. Ofc, it was faster than doing > binary_to_list(list_to___integer(X)) but binary_to_integer > was on par with > this list_to_integer .. which seemed a bit off. > > I want to refrain from using strtol directly (I think that > implementation is similar anyways and we still need to > handle bignums). > > I think I want to change the current implementation to > taking the base > as argument to the BIF and perhaps using arity one function > as an erlang > wrapper. (And doing the same for list_to_integer). The > arguments against > that is, surely the arity one functions is far more used and > it should > be slightly faster to that call directly. > > // Bj?rn-Egil > > > On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: > > On 2013-01-10 18:08, Serge Aleynikov wrote: > > Not quite - in two days my "new float_to_list/2" > patch is celebrating > its 2 year anniversary sitting in the awaiting > mode. ;-) > > Nice =o > However, it is not really as you imply. A simple > patch that has been > ignored for two years =) > > I checked in Monitor/OTP: > * sal/float_to_list_2 > * status: unassigned > * location: limbo (not present in any active backlog) > * notes: waiting for response from author (noted by > Lukas) > > Lukas is currently on a mountain somewhere in south > america so I can't > really ask him about it. > > As I recall, your patch had some controversy about > precision? > > And the last mail conversation mention something > about modifications > needed and if we were to do it we had to prioritize > it along with > already planned work. Needless to say, it hasn't > been prioritized. > > http://erlang.org/pipermail/__erlang-patches/2012-August/__002980.html > > > Personally trying to find time to get binary (text) > <-> integer > conversions into the backlog. > > Being realistic, neither your float conversion nor > mine will make it to > r16. *sadface* > > > // Bj?rn-Egil > > On 1/10/2013 10:51 AM, Max Lapshin wrote: > > Serge, you seems to be a fast way to pull > patch into upstream =) > > > On Thu, Jan 10, 2013 at 7:24 PM, Serge > Aleynikov > >> wrote: > > That was the fastest acceptance of a > patch I ever submitted. > ;-) > > On 1/10/2013 10:03 AM, Fredrik wrote: > > Hello Serge, > > Your patch is now in the > 'master-pu' branch. > > Thanks for your contribution! > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 01/10/2013 03:31 PM, Serge > Aleynikov wrote: > >> Added an application:get_env/3 > function variant that > provides a > default > >> value for a configuration parameter: > >> > >> application:get_env(App, Key, > Default) -> Value. > >> > >> git fetch > git://github.com/saleyn/otp.__git > > > get_env > >> > >> > https://github.com/saleyn/otp/__compare/erlang:master...get___env > > >> > https://github.com/saleyn/otp/__compare/erlang:master...get___env.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 > > > > > -- > 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 serge@REDACTED Fri Jan 11 04:06:47 2013 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 10 Jan 2013 22:06:47 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <5035F382.5090203@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> Message-ID: <50EF81C7.4020703@aleynikov.org> I implemented Lukas's recommendations that were presenting an acceptance issue of the new function, so the current version of the patch does: 1. float_to_list/1 is backwards compatible. 2. float_to_list(X,[]) gives the same result as float_to_list(X). 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation (with the optional compact option). 4. float_to_list(X,[{scientific,M}]) gives the same result as float_to_list(X) with the ability to control the number of decimals. The only item from Lucas's list that I left unchanged was the modification to erts/lib_src/common/erl_printf_format.c to take advantage of the speed improvement of the new implementation. I am including a patch in this email that implements this logic, but I decided to leave the integration task to the OTP team since erl_printf_format.c is actually compiled into a liberts_internal.a library and I didn't want to introduce a dependency of it on other code - this should be decided by maintainers. The test cases of float_to_list/{1,2} have been updated. git fetch https://github.com/saleyn/otp/tree/float_to_list_2 https://github.com/saleyn/otp/compare/maint...float_to_list_2 https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch Regards, Serge On 8/23/2012 5:10 AM, Lukas Larsson wrote: > Hi, > > I'll put it in the backlog and we'll see if it gets prioritized for R16B. > > As always if you (or someone else) wants make sure it gets in, the best > way to ensure that is to send an updated patch. > > Lukas > > > On 22/08/12 21:17, Serge Aleynikov wrote: >> I am certainly very happy to hear that you finally agreed to include >> this in the distribution. The changes proposed below seem reasonable >> and simple. Will the OTP team be able to modify my patch to implement >> them? >> >> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>> Hello Serge! >>> >>> I think we have finally agreed how we want this functionality to work. >>> >>> float_to_list/1 should be left as it is now for backwards compatibility. >>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>> float_to_list(1.0,[{decimals,X}]) should use your faster implementation >>> (with the optional compact option). >>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>> float_to_list(1.0) if Y is 20. >>> >>> We would also like the string rendering part of sys_double_to_chars_fast >>> to be put into erts/lib_src/common/erl_printf_format.c:fmt_double. This >>> way other parts of the vm which print floats will benefit from your >>> changes! >>> >>> I hope our indecisiveness have not caused you to shy away from taking >>> this feature into Erlang/OTP. If you have any further questions or >>> ponderings just let me know. >>> >>> Lukas >>> >>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>> However, I would also like the fast functionality to be used by >>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>> compatible? Hopefully you just have to shift the comma and add e+XX at >>>>> the end of the optimized case and call sys_double_to_chars for the >>>>> unoptimized. >>>> See my comments below regarding 'scientific' option. Since >>>> float_to_list_2 is a new function I would think that you are >>>> questioning >>>> the issue of backward compatibility only in terms of converting >>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>> think >>>> that this will have adverse performance tax on float_to_list_2, which >>>> will diminish the benefit. It's been a while however, since I wrote >>>> that patch, perhaps there's a way to retrofit scientific notation >>>> without a performance penalty. >>>> >>>> It's more than simple shifting of the comma, since there's also >>>> rounding >>>> involved. >>>> >>>> This case is easy: >>>> >>>> 4> float_to_list(1.01234). >>>> "1.01234000000000001762e+00" >>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>> "1.01234000000000001762" >>>> >>>> This case is a bit more complex (illustration of rounding impact): >>>> >>>> 7> float_to_list(10123412345.0123451234). >>>> "1.01234123450123443604e+10" >>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>> "10123412345.01234436035156250000" >>>> >>>>> Also float_to_list(1.0) should return the same thing as >>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent with how >>>>> other such APIs work. >>>> Actually if you trace this subject back there was another request that >>>> the default number of decimals is chosen to be consistent with what >>>> printf() does, so I changed the implementation to accommodate that >>>> request: >>>> >>>> Eshell V5.9 (abort with ^G) >>>> 1> float_to_list(1.0, []). >>>> "1.000000" >>>> >>>> Which is different from the default of float_to_list/1: >>>> >>>> 2> float_to_list(1.0). >>>> "1.00000000000000000000e+00" >>>> >>>> Maybe one could introduce a 'scientific' option to float_to_list/2, to >>>> use the float_to_list/1 implementation? >>>> >>>> Serge >>>> >>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>> Henrik, >>>>>> >>>>>> Fetch: git fetch >>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>> >>>>>> I added the definition for the new BIF to make the type checker >>>>>> happy: >>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>> suites >>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I tried the >>>>>> following but all tests fail: >>>>>> >>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>> test_server_ctrl >>>>>> run_test DIR "." -s erlang halt >>>>>> >>>>>> I did however run individual tests in bif_SUIT:types to make sure my >>>>>> patch didn't break anything. >>>>>> >>>>>> >>>>>> >>>>>> Serge >>>>>> >>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>> Hi again. >>>>>>> >>>>>>> >>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>> >>>>>>> No type information: >>>>>>> >>>>>>> [{erlang,float_to_list,2}] >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>> _______________________________________________ >>>>>> 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 -------------- --- erts/lib_src/common/erl_printf_format.c 2013-01-10 20:28:02.865909745 -0500 +++ erts/lib_src/common/erl_printf_format.c.new 2013-01-10 20:27:41.987369169 -0500 @@ -383,7 +383,7 @@ } /* fall through ... */ case FMTC_f: - format_str[fi++] = 'f'; + /* format_str[fi++] = 'f'; */ max_size += exp > 0 ? exp : 1; max_size++; if (precision) @@ -435,6 +435,9 @@ } } + if ((fmt & FMTC_MASK) == FMTC_f) + size = sys_double_to_chars_fast(val, bufp, max_size, precision, 0); + else size = sprintf(bufp, format_str, precision, val); if (size < 0) { if (errno > 0) From alevandal@REDACTED Fri Jan 11 07:47:15 2013 From: alevandal@REDACTED (Danil Onishchenko) Date: Fri, 11 Jan 2013 14:47:15 +0800 Subject: [erlang-patches] Patch for ODBC module In-Reply-To: <50EE7D2B.1080300@erlang.org> References: <50ED647B.6000705@erlang.org> <50EE7D2B.1080300@erlang.org> Message-ID: Hello. That's the patch rebased on 'master' branch. git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix-master https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-oracle-autocommit-fix-master https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-oracle-autocommit-fix-master.patch 2013/1/10 Fredrik : > Hello Danil! > Please rebase this patch on current 'master' branch and fix the problem. > From what is written in the 'how-to submit patches' on github you have done > the right thing, we will update the wiki soon. > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 05:19 AM, Danil Onishchenko wrote: >> >> Hi, Fredrik. >> When I was working on my patch I used the branch "maint" of OTP >> repository as a base because in the guide for submitting patches it >> was writed "Base your patch on maint if you are fixing a bug...". I >> compared the source file odbcserver.c in the branches "maint" and >> "master-pu" and found out that definitions of functions ?get_diagnos? >> and ?encode_error_message? in those branches are different. >> In "maint" they are >> static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle); >> static db_result_msg encode_error_message(char *reason); >> >> and in "master" >> static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle, >> Boolean extendedErrors); >> static db_result_msg encode_error_message(char *reason, char *errCode, >> SQLINTEGER nativeError); >> >> So my patch is proper for the "maint" branch and it is not for >> "master" branch. Is my choise of the branch wrong? Should I use >> "master" as a base instead of "maint"? >> >> Also I sent a patch "odbc:param_query/3 and odbc:param_query/4" which >> I based on the branch "maint" too. Should I fix it for "master"? >> >> 2013/1/9 Fredrik: >>> >>> Hello again, >>> This patch fails to build: >>> " >>> >>> odbcserver.c: In function ?db_connect?: >>> odbcserver.c:538:2: error: too few arguments to function ?get_diagnos? >>> odbcserver.c:250:16: note: declared here >>> odbcserver.c:541:2: error: too few arguments to function >>> ?encode_error_message? >>> odbcserver.c:157:22: note: declared here >>> >>> " >>> Please fix this and give notice when it is done. >>> >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/09/2013 09:53 AM, Kernel Panic wrote: >>>> >>>> Hi, folks. >>>> I created a patch for erlang odbc module which solves the problem with >>>> setup autocommit mode for connections established by Oracle ODBC >>>> driver in Linux. >>>> The issue: Oracle ODBC driver for Linux ignores setup autocommit mode >>>> during driver initialization before a connection to database has been >>>> established (in odbc module autocommit is set this way). My patch >>>> solves this problem by setting autocommit mode after a connection to >>>> database has been established. >>>> Actually it's an Oracle ODBC driver problem, but it could be very >>>> useful to add this fix to erlang odbc module, because this module >>>> allow to set autocommit mode only at the moment of connection >>>> creation. >>>> I sent this patch earlier in October 2012 but I didn't receive any >>>> feedback. >>>> >>>> My updates: >>>> git fetch git@REDACTED:RubberCthulhu/otp.git >>>> odbc-oracle-autocommit-fix >>>> >>>> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix >>>> >>>> >>>> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch >>>> >>>> Danil Onishchenko, alevandal@REDACTED >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> > From alevandal@REDACTED Fri Jan 11 07:50:42 2013 From: alevandal@REDACTED (Danil Onishchenko) Date: Fri, 11 Jan 2013 14:50:42 +0800 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 In-Reply-To: <50ED49FC.8060106@erlang.org> References: <50ED49FC.8060106@erlang.org> Message-ID: Hello, Fredrik. I rebased that patch on 'master' branch. The previous version was based on 'maint'. git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch 2013/1/9 Fredrik : > Hello Kernel! > Your patch is now cooking in the 'master-pu' branch. > > BR Fredrik Gustafsson > Erlang OTP Team > > On 01/09/2013 10:29 AM, Kernel Panic wrote: >> >> A little patch for odbc:param_query/3 and odbc:param_query/4. >> >> Issue: Calling odbc:param_query/3 and odbc:param_query/4 with >> unparameterized query string and empty parameters list causes error in >> pattern matching in function param_values/1. >> >> This patch fixes this problem and allow to do things such as >> odbc:param_query(ConRef, "select * from some_table", []). >> >> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params >> >> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params >> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > From bengt.kleberg@REDACTED Fri Jan 11 09:33:48 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 11 Jan 2013 09:33:48 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <50EF3B2A.50500@ninenines.eu> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> Message-ID: <1357893228.4818.2.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, FWIW I would like to not autoimport any more functions. The existing ones are confusing enough when reading up on new code. bengt On Thu, 2013-01-10 at 23:05 +0100, Lo?c Hoguin wrote: > binary:integer_to_string/1 is hardly intuitive. Especially if you write > it like this: > > Module = binary, > %% ... > Module:integer_to_string(123) > > Do you get a binary() or a string()? > > If you create a function type1_to_type2 it's much better if type1 and > type2 correspond to actual types. > > Wherever you place it I don't think it should be named anything other > than integer_to_binary. However it should be autoimported, because > writing integer_to_binary first and then remembering the function > doesn't exist is what many of us do regularly. We already have the > reflex, we only miss the call to be available. > > On 01/10/2013 08:31 PM, Serge Aleynikov wrote: > > Thanks for the explanation! The API naming is a headache indeed. > > > > It does make sense to define these functions in the binary module. > > Though while binary:string_to_integer/1 is intuitive, I think > > binary:integer_to_string/1 would be a more intuitive name than > > binary:string_from_integer/1 (this also would be more consistent with > > binary:{bin,list}_to_{list,bin}. > > > > On 1/10/2013 1:50 PM, Bj?rn-Egil Dahlberg wrote: > >> On 2013-01-10 18:55, Serge Aleynikov wrote: > >>> I was under impression that Lucas would take care of modifications he > >>> proposed in the thread you quoted. Meanwhile I'll see if I can find > >>> time to do this. > >> I think the key words were "if it gets prioritized" =) > >> Granted, we could be more clear on intention. I think in this case we > >> supposedly had time which drastically changed at some point .. > >> > >>> > >>> Do you already have an implementation of binary <-> integer? If not, > >>> maybe I could look at that one as well when I poke around the BIFs, > >>> since this is also something very commonly needed. > >> Right, what I did was to take the list conversions to integer and made > >> it binary comprehensible. > >> > >> That was the easy bit. > >> > >> However, > >> Now I have > >> * erlang:binary_to_integer/1 and > >> * erlang:integer_to_binary/1 > >> which seems fine. The compiler will auto-import them as well. > >> > >> After I did that I began to reconsider this choice. Perhaps it should be > >> > >> * binary:to_integer/1 and binary:from_integer/1 instead? Or, > >> * binary:string_from_integer/1 and binary:string_to_integer/1, > >> emphasizing that this is a textual representation of integer in binary > >> format. Then I got a headache. > >> > >> The arguments for the first one (current) is: > >> * list_to_integer has same type of ideas, same type of behavior. Avoids > >> confusion. > >> The arguments against the first one, > >> * Clutters the erlang module with yet more BIF's > >> * We already have a binary module, let's use it! > >> * And finally: avoid confusion! Does erlang:integer_to_binary(102341) > >> mean <<0,1,143,197>> or <<"102341">> ? > >> > >> I'm leaning towards the latter. > >> > >> Also, I didn't implement base conversion, so that needs doing. I think > >> the list conversion is done in Erlang which seems backwards. > >> > >> Anyways, the current implementation is at: > >> https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer > >> > >> But the real work is taking a position on the API and consider the > >> different ramifications. I still have that headache .. > >> > >> Yet another also, perhaps this implementation isn't the way to go. From > >> what I remember erlang:binary_to_integer didn't have the speedup I first > >> envisioned. Ofc, it was faster than doing > >> binary_to_list(list_to_integer(X)) but binary_to_integer was on par with > >> this list_to_integer .. which seemed a bit off. > >> > >> I want to refrain from using strtol directly (I think that > >> implementation is similar anyways and we still need to handle bignums). > >> > >> I think I want to change the current implementation to taking the base > >> as argument to the BIF and perhaps using arity one function as an erlang > >> wrapper. (And doing the same for list_to_integer). The arguments against > >> that is, surely the arity one functions is far more used and it should > >> be slightly faster to that call directly. > >> > >> // Bj?rn-Egil > >> > >>> > >>> On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: > >>>> On 2013-01-10 18:08, Serge Aleynikov wrote: > >>>>> Not quite - in two days my "new float_to_list/2" patch is celebrating > >>>>> its 2 year anniversary sitting in the awaiting mode. ;-) > >>>> Nice =o > >>>> However, it is not really as you imply. A simple patch that has been > >>>> ignored for two years =) > >>>> > >>>> I checked in Monitor/OTP: > >>>> * sal/float_to_list_2 > >>>> * status: unassigned > >>>> * location: limbo (not present in any active backlog) > >>>> * notes: waiting for response from author (noted by Lukas) > >>>> > >>>> Lukas is currently on a mountain somewhere in south america so I can't > >>>> really ask him about it. > >>>> > >>>> As I recall, your patch had some controversy about precision? > >>>> > >>>> And the last mail conversation mention something about modifications > >>>> needed and if we were to do it we had to prioritize it along with > >>>> already planned work. Needless to say, it hasn't been prioritized. > >>>> > >>>> http://erlang.org/pipermail/erlang-patches/2012-August/002980.html > >>>> > >>>> Personally trying to find time to get binary (text) <-> integer > >>>> conversions into the backlog. > >>>> > >>>> Being realistic, neither your float conversion nor mine will make it to > >>>> r16. *sadface* > >>>> > >>>> > >>>> // Bj?rn-Egil > >>>> > >>>>> On 1/10/2013 10:51 AM, Max Lapshin wrote: > >>>>>> Serge, you seems to be a fast way to pull patch into upstream =) > >>>>>> > >>>>>> > >>>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov >>>>>> > wrote: > >>>>>> > >>>>>> That was the fastest acceptance of a patch I ever submitted. > >>>>>> ;-) > >>>>>> > >>>>>> On 1/10/2013 10:03 AM, Fredrik wrote: > >>>>>> > Hello Serge, > >>>>>> > Your patch is now in the 'master-pu' branch. > >>>>>> > Thanks for your contribution! > >>>>>> > > >>>>>> > BR Fredrik Gustafsson > >>>>>> > Erlang OTP Team > >>>>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: > >>>>>> >> Added an application:get_env/3 function variant that > >>>>>> provides a > >>>>>> default > >>>>>> >> value for a configuration parameter: > >>>>>> >> > >>>>>> >> application:get_env(App, Key, Default) -> Value. > >>>>>> >> > >>>>>> >> git fetch git://github.com/saleyn/otp.git > >>>>>> get_env > >>>>>> >> > >>>>>> >> https://github.com/saleyn/otp/compare/erlang:master...get_env > >>>>>> >> > >>>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 fredrik@REDACTED Fri Jan 11 09:49:29 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 09:49:29 +0100 Subject: [erlang-patches] Add RIPEMD160 digest support to crypto In-Reply-To: <50E3F7F4.7000800@erlang.org> References: <50D185C7.60805@erlang.org> <50D43F4C.7070205@erlang.org> <50E3F7F4.7000800@erlang.org> Message-ID: <50EFD219.8010909@erlang.org> Graduated to master, Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/02/2013 10:03 AM, Fredrik wrote: > Hello Michael! > I have re-fetched and it is now again in the 'master-pu' branch. > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/21/2012 07:38 PM, Michael Loftis wrote: >> I added the ripemd160 atom to the documentation, removed the exports, >> and added the bits to the hash and hash_init family....There's a >> info/0 function that returns ?FUNC_LIST -- and I'm actually not clear >> on it's use/behavior, but it appears that it is intended to indicate >> exported crypto functions, so I've omitted the now non-exported >> functions from that define. Hopefully this is right, as this appears >> to be the first "example" of a hash only function. >> >> >> On Fri, Dec 21, 2012 at 2:51 AM, Fredrik > > wrote: >> >> Hello Michael! >> The patch has been into review and the feedback: >> " >> >> New functions hash,hash_init,hash_update,hash_final has been >> added in master for R16. You should use them instead and not >> export your ripemd160 functions. >> >> Documentation is missing." >> >> Please fix this and I will fetch again. >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> On 12/19/2012 07:05 PM, Michael Loftis wrote: >>> Entirely my fault, I missed two #define's when I moved the patch >>> from the crypto module I forked back at R13 back into the R15 >>> source. I only got R15 to compile today, R15 and my javac do >>> not get along (but I don't use any of that anyway). >>> >>> I've updated the github repo, same branch. >>> >>> >>> https://github.com/mloftis/otp/compare/master-pu...crypto-add-ripemd160-digest >>> https://github.com/mloftis/otp/compare/master-pu...crypto-add-ripemd160-digest.patch >>> >>> git fetch git://github.com/mloftis/otp.git >>> crypto-add-ripemd160-digest >>> >>> >>> >>> On Wed, Dec 19, 2012 at 1:15 AM, Fredrik >> > wrote: >>> >>> Hello Michael, >>> It does not build: >>> crypto.c: In function 'ripemd160': >>> crypto.c:621:28: error: 'RIPEMD160_LEN' undeclared (first >>> use in this function) >>> crypto.c:621:28: note: each undeclared identifier is >>> reported only once for each function it appears in >>> crypto.c: In function 'ripemd160_init': >>> crypto.c:627:64: error: 'RIPEMD160_CTX_LEN' undeclared >>> (first use in this function) >>> crypto.c: In function 'ripemd160_update': >>> crypto.c:636:22: error: 'RIPEMD160_CTX_LEN' undeclared >>> (first use in this function) >>> crypto.c: In function 'ripemd160_final': >>> crypto.c:650:73: error: 'RIPEMD160_CTX_LEN' undeclared >>> (first use in this function) >>> crypto.c:654:47: error: 'RIPEMD160_LEN' undeclared (first >>> use in this function) >>> >>> Please take a look at this and give me a notice. >>> >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/18/2012 11:10 PM, Michael Loftis wrote: >>>> Apologies, done... >>>> >>>> https://github.com/mloftis/otp/compare/master...crypto-add-ripemd160-digest >>>> https://github.com/mloftis/otp/compare/master...crypto-add-ripemd160-digest.patch >>>> >>>> git fetch git://github.com/mloftis/otp.git >>>> crypto-add-ripemd160-digest >>>> >>>> >>>> >>>> >>>> On Tue, Dec 18, 2012 at 1:45 PM, Tuncer Ayaz >>>> > wrote: >>>> >>>> On Tue, Dec 18, 2012 at 10:35 PM, Michael Loftis wrote: >>>> > >>>> > Add ripemd160 digest support to crypto. Includes a >>>> couple test >>>> > cases. >>>> > >>>> > >>>> > git fetch git://github.com/mloftis/otp.git >>>> >>>> crypto-add-ripemd160-digest >>>> > >>>> > This is based off of master-pu as of a few moments >>>> ago, my read of >>>> > the requirements tells me that should be the correct >>>> spot since I'm >>>> > adding a new feature to the crypto module. >>>> >>>> A patch for 'master-pu' has to be based off 'master'. >>>> >>>> > Not fully tested with the current erlang since >>>> jinterface has >>>> > completely broken my build on all platforms -- even >>>> if it is >>>> > disabled it still kills my build on most platforms >>>> because it's >>>> > using sh with scripts that have bash semantics. Might >>>> have a chance >>>> > to clean up that separate issue today and submit patches. >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> "Genius might be described as a supreme capacity for >>>> getting its possessors >>>> into trouble of all kinds." >>>> -- Samuel Butler >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> >>> >>> >>> -- >>> >>> "Genius might be described as a supreme capacity for getting its >>> possessors >>> into trouble of all kinds." >>> -- Samuel Butler >>> >> >> >> >> >> -- >> >> "Genius might be described as a supreme capacity for getting its >> possessors >> into trouble of all kinds." >> -- Samuel Butler > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Fri Jan 11 09:52:47 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 09:52:47 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50EF81C7.4020703@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> Message-ID: <50EFD2DF.5000407@erlang.org> Hey, Could you please rebase this on current 'master' branch? BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 04:06 AM, Serge Aleynikov wrote: > I implemented Lukas's recommendations that were presenting an acceptance > issue of the new function, so the current version of the patch does: > > 1. float_to_list/1 is backwards compatible. > 2. float_to_list(X,[]) gives the same result as float_to_list(X). > 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation > (with the optional compact option). > 4. float_to_list(X,[{scientific,M}]) gives the same result as > float_to_list(X) with the ability to control the number of decimals. > > The only item from Lucas's list that I left unchanged was the > modification to erts/lib_src/common/erl_printf_format.c to take > advantage of the speed improvement of the new implementation. I am > including a patch in this email that implements this logic, but I > decided to leave the integration task to the OTP team since > erl_printf_format.c is actually compiled into a liberts_internal.a > library and I didn't want to introduce a dependency of it on other code > - this should be decided by maintainers. > > The test cases of float_to_list/{1,2} have been updated. > > git fetch https://github.com/saleyn/otp/tree/float_to_list_2 > > https://github.com/saleyn/otp/compare/maint...float_to_list_2 > https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch > > Regards, > > Serge > > On 8/23/2012 5:10 AM, Lukas Larsson wrote: >> Hi, >> >> I'll put it in the backlog and we'll see if it gets prioritized for R16B. >> >> As always if you (or someone else) wants make sure it gets in, the best >> way to ensure that is to send an updated patch. >> >> Lukas >> >> >> On 22/08/12 21:17, Serge Aleynikov wrote: >>> I am certainly very happy to hear that you finally agreed to include >>> this in the distribution. The changes proposed below seem reasonable >>> and simple. Will the OTP team be able to modify my patch to implement >>> them? >>> >>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>> Hello Serge! >>>> >>>> I think we have finally agreed how we want this functionality to work. >>>> >>>> float_to_list/1 should be left as it is now for backwards compatibility. >>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>> float_to_list(1.0,[{decimals,X}]) should use your faster implementation >>>> (with the optional compact option). >>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>> float_to_list(1.0) if Y is 20. >>>> >>>> We would also like the string rendering part of sys_double_to_chars_fast >>>> to be put into erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>> way other parts of the vm which print floats will benefit from your >>>> changes! >>>> >>>> I hope our indecisiveness have not caused you to shy away from taking >>>> this feature into Erlang/OTP. If you have any further questions or >>>> ponderings just let me know. >>>> >>>> Lukas >>>> >>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>> However, I would also like the fast functionality to be used by >>>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>>> compatible? Hopefully you just have to shift the comma and add e+XX at >>>>>> the end of the optimized case and call sys_double_to_chars for the >>>>>> unoptimized. >>>>> See my comments below regarding 'scientific' option. Since >>>>> float_to_list_2 is a new function I would think that you are >>>>> questioning >>>>> the issue of backward compatibility only in terms of converting >>>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>>> think >>>>> that this will have adverse performance tax on float_to_list_2, which >>>>> will diminish the benefit. It's been a while however, since I wrote >>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>> without a performance penalty. >>>>> >>>>> It's more than simple shifting of the comma, since there's also >>>>> rounding >>>>> involved. >>>>> >>>>> This case is easy: >>>>> >>>>> 4> float_to_list(1.01234). >>>>> "1.01234000000000001762e+00" >>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>> "1.01234000000000001762" >>>>> >>>>> This case is a bit more complex (illustration of rounding impact): >>>>> >>>>> 7> float_to_list(10123412345.0123451234). >>>>> "1.01234123450123443604e+10" >>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>> "10123412345.01234436035156250000" >>>>> >>>>>> Also float_to_list(1.0) should return the same thing as >>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent with how >>>>>> other such APIs work. >>>>> Actually if you trace this subject back there was another request that >>>>> the default number of decimals is chosen to be consistent with what >>>>> printf() does, so I changed the implementation to accommodate that >>>>> request: >>>>> >>>>> Eshell V5.9 (abort with ^G) >>>>> 1> float_to_list(1.0, []). >>>>> "1.000000" >>>>> >>>>> Which is different from the default of float_to_list/1: >>>>> >>>>> 2> float_to_list(1.0). >>>>> "1.00000000000000000000e+00" >>>>> >>>>> Maybe one could introduce a 'scientific' option to float_to_list/2, to >>>>> use the float_to_list/1 implementation? >>>>> >>>>> Serge >>>>> >>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>> Henrik, >>>>>>> >>>>>>> Fetch: git fetch >>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>> >>>>>>> I added the definition for the new BIF to make the type checker >>>>>>> happy: >>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>> suites >>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I tried the >>>>>>> following but all tests fail: >>>>>>> >>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>> test_server_ctrl >>>>>>> run_test DIR "." -s erlang halt >>>>>>> >>>>>>> I did however run individual tests in bif_SUIT:types to make sure my >>>>>>> patch didn't break anything. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Serge >>>>>>> >>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>> Hi again. >>>>>>>> >>>>>>>> >>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>> >>>>>>>> No type information: >>>>>>>> >>>>>>>> [{erlang,float_to_list,2}] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>> _______________________________________________ >>>>>>> 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 fredrik@REDACTED Fri Jan 11 10:56:57 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 10:56:57 +0100 Subject: [erlang-patches] Patch for ODBC module In-Reply-To: References: <50ED647B.6000705@erlang.org> <50EE7D2B.1080300@erlang.org> Message-ID: <50EFE1E9.9020308@erlang.org> Thanks, I have re-fetched and it is now in 'master-pu'. BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 07:47 AM, Danil Onishchenko wrote: > Hello. > That's the patch rebased on 'master' branch. > > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-oracle-autocommit-fix-master > > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-oracle-autocommit-fix-master > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-oracle-autocommit-fix-master.patch > > 2013/1/10 Fredrik: >> Hello Danil! >> Please rebase this patch on current 'master' branch and fix the problem. >> From what is written in the 'how-to submit patches' on github you have done >> the right thing, we will update the wiki soon. >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/10/2013 05:19 AM, Danil Onishchenko wrote: >>> Hi, Fredrik. >>> When I was working on my patch I used the branch "maint" of OTP >>> repository as a base because in the guide for submitting patches it >>> was writed "Base your patch on maint if you are fixing a bug...". I >>> compared the source file odbcserver.c in the branches "maint" and >>> "master-pu" and found out that definitions of functions ?get_diagnos? >>> and ?encode_error_message? in those branches are different. >>> In "maint" they are >>> static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle); >>> static db_result_msg encode_error_message(char *reason); >>> >>> and in "master" >>> static diagnos get_diagnos(SQLSMALLINT handleType, SQLHANDLE handle, >>> Boolean extendedErrors); >>> static db_result_msg encode_error_message(char *reason, char *errCode, >>> SQLINTEGER nativeError); >>> >>> So my patch is proper for the "maint" branch and it is not for >>> "master" branch. Is my choise of the branch wrong? Should I use >>> "master" as a base instead of "maint"? >>> >>> Also I sent a patch "odbc:param_query/3 and odbc:param_query/4" which >>> I based on the branch "maint" too. Should I fix it for "master"? >>> >>> 2013/1/9 Fredrik: >>>> Hello again, >>>> This patch fails to build: >>>> " >>>> >>>> odbcserver.c: In function ?db_connect?: >>>> odbcserver.c:538:2: error: too few arguments to function ?get_diagnos? >>>> odbcserver.c:250:16: note: declared here >>>> odbcserver.c:541:2: error: too few arguments to function >>>> ?encode_error_message? >>>> odbcserver.c:157:22: note: declared here >>>> >>>> " >>>> Please fix this and give notice when it is done. >>>> >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/09/2013 09:53 AM, Kernel Panic wrote: >>>>> Hi, folks. >>>>> I created a patch for erlang odbc module which solves the problem with >>>>> setup autocommit mode for connections established by Oracle ODBC >>>>> driver in Linux. >>>>> The issue: Oracle ODBC driver for Linux ignores setup autocommit mode >>>>> during driver initialization before a connection to database has been >>>>> established (in odbc module autocommit is set this way). My patch >>>>> solves this problem by setting autocommit mode after a connection to >>>>> database has been established. >>>>> Actually it's an Oracle ODBC driver problem, but it could be very >>>>> useful to add this fix to erlang odbc module, because this module >>>>> allow to set autocommit mode only at the moment of connection >>>>> creation. >>>>> I sent this patch earlier in October 2012 but I didn't receive any >>>>> feedback. >>>>> >>>>> My updates: >>>>> git fetch git@REDACTED:RubberCthulhu/otp.git >>>>> odbc-oracle-autocommit-fix >>>>> >>>>> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix >>>>> >>>>> >>>>> https://github.com/RubberCthulhu/otp/compare/odbc-oracle-autocommit-fix.patch >>>>> >>>>> Danil Onishchenko, alevandal@REDACTED >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> From fredrik@REDACTED Fri Jan 11 10:59:23 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 10:59:23 +0100 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 In-Reply-To: References: <50ED49FC.8060106@erlang.org> Message-ID: <50EFE27B.8060809@erlang.org> Thanks, I have re-fetched and it is now again in 'master-pu' BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 07:50 AM, Danil Onishchenko wrote: > Hello, Fredrik. > I rebased that patch on 'master' branch. The previous version was > based on 'maint'. > > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master > > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch > > 2013/1/9 Fredrik: >> Hello Kernel! >> Your patch is now cooking in the 'master-pu' branch. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> On 01/09/2013 10:29 AM, Kernel Panic wrote: >>> A little patch for odbc:param_query/3 and odbc:param_query/4. >>> >>> Issue: Calling odbc:param_query/3 and odbc:param_query/4 with >>> unparameterized query string and empty parameters list causes error in >>> pattern matching in function param_values/1. >>> >>> This patch fixes this problem and allow to do things such as >>> odbc:param_query(ConRef, "select * from some_table", []). >>> >>> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params >>> >>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params >>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> From fredrik@REDACTED Fri Jan 11 11:22:27 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 11:22:27 +0100 Subject: [erlang-patches] Deep list argument error under Windows in os:cmd/1 In-Reply-To: <50C8756B.3000309@erlang.org> References: <50C8756B.3000309@erlang.org> Message-ID: <50EFE7E3.2080703@erlang.org> Hey Aleksandr, Any updates on this testcase problem? BR Fredrik Gustafsson Erlang OTP Team On 12/12/2012 01:15 PM, Henrik Nord wrote: > Hi your test fails with: **** User 2012-12-10 23:03:01.060 **** > os_SUITE:deep_list_command failed Reason: undef > > > > > On 11/22/2012 09:02 AM, Aleksandr Vinokurov wrote: >> Hi all, >> >> Maybe I'm doing smth. wrong -- why there is no reply to my patch? >> >> WBR, >> Aleksandr Vinokurov >> >> >> On 8 November 2012 14:11, Aleksandr Vinokurov >> > wrote: >> >> Because of leeway in implementing os:cmd/1 under different OS there is >> a difference in results when calling it with deep list >> argument. os:cmd/1 specifies io_lib:chars() type for its argument and >> io_lib functions can produce deep lists inspite of io_lib:chars() >> result type specification. This commit flattens the argument for >> erlang:open_port/2 (which is used under Windows) and expands the >> os_SUITE to regress the bug. >> >> git fetch git://github.com/aleksandr-vin/otp.git maint-fix-os-cmd-win >> >> or viewed here: >> >> https://github.com/aleksandr-vin/otp/compare/maint-fix-os-cmd-win >> https://github.com/aleksandr-vin/otp/compare/maint-fix-os-cmd-win.patch >> >> -- >> Aleksandr Vinokurov >> +7 (921) 982-21-43 >> @aleksandrvin >> >> >> >> >> -- >> ????????? ????????? >> +7 (921) 982-21-43 >> @aleksandrvin >> >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -- > /Henrik Nord Erlang/OTP > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Jan 11 11:42:45 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 11 Jan 2013 11:42:45 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> Message-ID: I disagree. Making it the big endian encoding of that integer is something that is already covered by OTP (binary:encode_unsigned/1 and its friends), and as you say, it's a *encoding* operation, not a type conversion. Naming this new BIF "integer_to_binary" isn't more confusing than "atom_to_binary". -- Anthony Ramine Le 10 janv. 2013 ? 23:13, Bob Ippolito a ?crit : > The purpose of integer_to_binary still isn't totally obvious from the name or output type, maybe it's digits, maybe it's the big endian encoding of that integer (which is closer to the behavior of binary_to_term / term_to_binary). For the more seasoned Erlang developer, I think they would expect it to behave like integer_to_string, but what about newer users? From robert.virding@REDACTED Fri Jan 11 13:09:48 2013 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 11 Jan 2013 12:09:48 +0000 (GMT) Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: Message-ID: <722572900.2787369.1357906188551.JavaMail.root@erlang-solutions.com> I missed the beginning of this discussion but is it supposed to do list_to_binary(integer_to_list(I))? If so I fail to see a pressing need. Robert ----- Original Message ----- > From: "Anthony Ramine" > To: "Bob Ippolito" > Cc: "erlang patches" > Sent: Friday, 11 January, 2013 11:42:45 AM > Subject: Re: [erlang-patches] [patch] binary to/from integer > > I disagree. Making it the big endian encoding of that integer is > something > that is already covered by OTP (binary:encode_unsigned/1 and its > friends), > and as you say, it's a *encoding* operation, not a type conversion. > Naming > this new BIF "integer_to_binary" isn't more confusing than > "atom_to_binary". > > -- > Anthony Ramine > > Le 10 janv. 2013 ? 23:13, Bob Ippolito a ?crit : > > > The purpose of integer_to_binary still isn't totally obvious from > > the name or output type, maybe it's digits, maybe it's the big > > endian encoding of that integer (which is closer to the behavior > > of binary_to_term / term_to_binary). For the more seasoned Erlang > > developer, I think they would expect it to behave like > > integer_to_string, but what about newer users? > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From robert.virding@REDACTED Fri Jan 11 13:21:19 2013 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 11 Jan 2013 12:21:19 +0000 (GMT) Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <722572900.2787369.1357906188551.JavaMail.root@erlang-solutions.com> Message-ID: <1102474262.2787660.1357906879805.JavaMail.root@erlang-solutions.com> And if it's supposed to create a binary representation of the integer as in <> then I really don't see the need. Robert ----- Original Message ----- > From: "Robert Virding" > To: "Anthony Ramine" > Cc: "erlang patches" > Sent: Friday, 11 January, 2013 1:09:48 PM > Subject: Re: [erlang-patches] [patch] binary to/from integer > > I missed the beginning of this discussion but is it supposed to do > > list_to_binary(integer_to_list(I))? > > If so I fail to see a pressing need. > > Robert > > ----- Original Message ----- > > From: "Anthony Ramine" > > To: "Bob Ippolito" > > Cc: "erlang patches" > > Sent: Friday, 11 January, 2013 11:42:45 AM > > Subject: Re: [erlang-patches] [patch] binary to/from integer > > > > I disagree. Making it the big endian encoding of that integer is > > something > > that is already covered by OTP (binary:encode_unsigned/1 and its > > friends), > > and as you say, it's a *encoding* operation, not a type conversion. > > Naming > > this new BIF "integer_to_binary" isn't more confusing than > > "atom_to_binary". > > > > -- > > Anthony Ramine > > > > Le 10 janv. 2013 ? 23:13, Bob Ippolito a ?crit : > > > > > The purpose of integer_to_binary still isn't totally obvious from > > > the name or output type, maybe it's digits, maybe it's the big > > > endian encoding of that integer (which is closer to the behavior > > > of binary_to_term / term_to_binary). For the more seasoned Erlang > > > developer, I think they would expect it to behave like > > > integer_to_string, but what about newer users? > > > > _______________________________________________ > > 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 Jan 11 14:24:37 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 11 Jan 2013 08:24:37 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50EFD2DF.5000407@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> Message-ID: <50F01295.6010203@aleynikov.org> While looking at this I see that the code in folder "erts/emulator/sys/vxworks" is present in maint but missing in the master branch. Is this intentional? If so, should I remove the part of the patch designed for vxworks? On 1/11/2013 3:52 AM, Fredrik wrote: > Hey, > Could you please rebase this on current 'master' branch? > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >> I implemented Lukas's recommendations that were presenting an acceptance >> issue of the new function, so the current version of the patch does: >> >> 1. float_to_list/1 is backwards compatible. >> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >> (with the optional compact option). >> 4. float_to_list(X,[{scientific,M}]) gives the same result as >> float_to_list(X) with the ability to control the number of decimals. >> >> The only item from Lucas's list that I left unchanged was the >> modification to erts/lib_src/common/erl_printf_format.c to take >> advantage of the speed improvement of the new implementation. I am >> including a patch in this email that implements this logic, but I >> decided to leave the integration task to the OTP team since >> erl_printf_format.c is actually compiled into a liberts_internal.a >> library and I didn't want to introduce a dependency of it on other code >> - this should be decided by maintainers. >> >> The test cases of float_to_list/{1,2} have been updated. >> >> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >> >> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >> >> Regards, >> >> Serge >> >> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>> Hi, >>> >>> I'll put it in the backlog and we'll see if it gets prioritized for R16B. >>> >>> As always if you (or someone else) wants make sure it gets in, the best >>> way to ensure that is to send an updated patch. >>> >>> Lukas >>> >>> >>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>> I am certainly very happy to hear that you finally agreed to include >>>> this in the distribution. The changes proposed below seem reasonable >>>> and simple. Will the OTP team be able to modify my patch to implement >>>> them? >>>> >>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>> Hello Serge! >>>>> >>>>> I think we have finally agreed how we want this functionality to work. >>>>> >>>>> float_to_list/1 should be left as it is now for backwards compatibility. >>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>> float_to_list(1.0,[{decimals,X}]) should use your faster implementation >>>>> (with the optional compact option). >>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>> float_to_list(1.0) if Y is 20. >>>>> >>>>> We would also like the string rendering part of sys_double_to_chars_fast >>>>> to be put into erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>> way other parts of the vm which print floats will benefit from your >>>>> changes! >>>>> >>>>> I hope our indecisiveness have not caused you to shy away from taking >>>>> this feature into Erlang/OTP. If you have any further questions or >>>>> ponderings just let me know. >>>>> >>>>> Lukas >>>>> >>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>> However, I would also like the fast functionality to be used by >>>>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>>>> compatible? Hopefully you just have to shift the comma and add e+XX at >>>>>>> the end of the optimized case and call sys_double_to_chars for the >>>>>>> unoptimized. >>>>>> See my comments below regarding 'scientific' option. Since >>>>>> float_to_list_2 is a new function I would think that you are >>>>>> questioning >>>>>> the issue of backward compatibility only in terms of converting >>>>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>>>> think >>>>>> that this will have adverse performance tax on float_to_list_2, which >>>>>> will diminish the benefit. It's been a while however, since I wrote >>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>> without a performance penalty. >>>>>> >>>>>> It's more than simple shifting of the comma, since there's also >>>>>> rounding >>>>>> involved. >>>>>> >>>>>> This case is easy: >>>>>> >>>>>> 4> float_to_list(1.01234). >>>>>> "1.01234000000000001762e+00" >>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>> "1.01234000000000001762" >>>>>> >>>>>> This case is a bit more complex (illustration of rounding impact): >>>>>> >>>>>> 7> float_to_list(10123412345.0123451234). >>>>>> "1.01234123450123443604e+10" >>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>> "10123412345.01234436035156250000" >>>>>> >>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent with how >>>>>>> other such APIs work. >>>>>> Actually if you trace this subject back there was another request that >>>>>> the default number of decimals is chosen to be consistent with what >>>>>> printf() does, so I changed the implementation to accommodate that >>>>>> request: >>>>>> >>>>>> Eshell V5.9 (abort with ^G) >>>>>> 1> float_to_list(1.0, []). >>>>>> "1.000000" >>>>>> >>>>>> Which is different from the default of float_to_list/1: >>>>>> >>>>>> 2> float_to_list(1.0). >>>>>> "1.00000000000000000000e+00" >>>>>> >>>>>> Maybe one could introduce a 'scientific' option to float_to_list/2, to >>>>>> use the float_to_list/1 implementation? >>>>>> >>>>>> Serge >>>>>> >>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>> Henrik, >>>>>>>> >>>>>>>> Fetch: git fetch >>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>> >>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>> happy: >>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>> suites >>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I tried the >>>>>>>> following but all tests fail: >>>>>>>> >>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>> test_server_ctrl >>>>>>>> run_test DIR "." -s erlang halt >>>>>>>> >>>>>>>> I did however run individual tests in bif_SUIT:types to make sure my >>>>>>>> patch didn't break anything. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Serge >>>>>>>> >>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>> Hi again. >>>>>>>>> >>>>>>>>> >>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>> >>>>>>>>> No type information: >>>>>>>>> >>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>> _______________________________________________ >>>>>>>> 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 egil@REDACTED Fri Jan 11 14:51:57 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 11 Jan 2013 14:51:57 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <722572900.2787369.1357906188551.JavaMail.root@erlang-solutions.com> References: <722572900.2787369.1357906188551.JavaMail.root@erlang-solutions.com> Message-ID: <50F018FD.5030907@erlang.org> On 2013-01-11 13:09, Robert Virding wrote: > I missed the beginning of this discussion but is it supposed to do > > list_to_binary(integer_to_list(I))? > > If so I fail to see a pressing need. Let me educate you. =) We are mainly talking about binary_to_list(list_to_integer(I)). In this time of web-services we frequently do encoding and decoding on text-based protocols. It is preferable that these encode and decode transformations are fast. Since we migrated from mainly having text as list to mostly binaries we are lacking a solid and fast binary to integer function. (In addition, it always seems stupid that I have to do: "b2i(I) -> binary_to_list(list_to_integer(I)).") It has never been a pressing need. It still isn't. It is more in the "would be nice to have" category. Yet another way to go would be to have: erlang:iodata_to_integer/1 erlang:iodata_to_float/1 Just fire and forget. and ofc (!) erlang:float_to_iodata/1 erlang:integer_to_iodata/1 The two latter function would naturally produce iodata in an arbitrary fashion but satisfying the textual iodata representation of the float or integer we used as input. for convenience we should also have erlang:number_to_iodata/1 erlang:iodata_to_number/1 // Bj?rn-Egil > > Robert > > ----- Original Message ----- >> From: "Anthony Ramine" >> To: "Bob Ippolito" >> Cc: "erlang patches" >> Sent: Friday, 11 January, 2013 11:42:45 AM >> Subject: Re: [erlang-patches] [patch] binary to/from integer >> >> I disagree. Making it the big endian encoding of that integer is >> something >> that is already covered by OTP (binary:encode_unsigned/1 and its >> friends), >> and as you say, it's a *encoding* operation, not a type conversion. >> Naming >> this new BIF "integer_to_binary" isn't more confusing than >> "atom_to_binary". >> >> -- >> Anthony Ramine >> >> Le 10 janv. 2013 ? 23:13, Bob Ippolito a ?crit : >> >>> The purpose of integer_to_binary still isn't totally obvious from >>> the name or output type, maybe it's digits, maybe it's the big >>> endian encoding of that integer (which is closer to the behavior >>> of binary_to_term / term_to_binary). For the more seasoned Erlang >>> developer, I think they would expect it to behave like >>> integer_to_string, but what about newer users? >> _______________________________________________ >> 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 egil@REDACTED Fri Jan 11 14:53:53 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 11 Jan 2013 14:53:53 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F01295.6010203@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> Message-ID: <50F01971.7070009@erlang.org> On 2013-01-11 14:24, Serge Aleynikov wrote: > While looking at this I see that the code in folder > "erts/emulator/sys/vxworks" is present in maint but missing in the > master branch. Is this intentional? If so, should I remove the part of > the patch designed for vxworks? Yes. Any and all vxworks support has been removed in R16 from OTP except for epmd, erl_interface and ic. // Bj?rn-Egil > > On 1/11/2013 3:52 AM, Fredrik wrote: >> Hey, >> Could you please rebase this on current 'master' branch? >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>> I implemented Lukas's recommendations that were presenting an acceptance >>> issue of the new function, so the current version of the patch does: >>> >>> 1. float_to_list/1 is backwards compatible. >>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>> (with the optional compact option). >>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>> float_to_list(X) with the ability to control the number of decimals. >>> >>> The only item from Lucas's list that I left unchanged was the >>> modification to erts/lib_src/common/erl_printf_format.c to take >>> advantage of the speed improvement of the new implementation. I am >>> including a patch in this email that implements this logic, but I >>> decided to leave the integration task to the OTP team since >>> erl_printf_format.c is actually compiled into a liberts_internal.a >>> library and I didn't want to introduce a dependency of it on other code >>> - this should be decided by maintainers. >>> >>> The test cases of float_to_list/{1,2} have been updated. >>> >>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>> >>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>> >>> Regards, >>> >>> Serge >>> >>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>> Hi, >>>> >>>> I'll put it in the backlog and we'll see if it gets prioritized for R16B. >>>> >>>> As always if you (or someone else) wants make sure it gets in, the best >>>> way to ensure that is to send an updated patch. >>>> >>>> Lukas >>>> >>>> >>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>> I am certainly very happy to hear that you finally agreed to include >>>>> this in the distribution. The changes proposed below seem reasonable >>>>> and simple. Will the OTP team be able to modify my patch to implement >>>>> them? >>>>> >>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>> Hello Serge! >>>>>> >>>>>> I think we have finally agreed how we want this functionality to work. >>>>>> >>>>>> float_to_list/1 should be left as it is now for backwards compatibility. >>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster implementation >>>>>> (with the optional compact option). >>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>> float_to_list(1.0) if Y is 20. >>>>>> >>>>>> We would also like the string rendering part of sys_double_to_chars_fast >>>>>> to be put into erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>> way other parts of the vm which print floats will benefit from your >>>>>> changes! >>>>>> >>>>>> I hope our indecisiveness have not caused you to shy away from taking >>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>> ponderings just let me know. >>>>>> >>>>>> Lukas >>>>>> >>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>>>>> compatible? Hopefully you just have to shift the comma and add e+XX at >>>>>>>> the end of the optimized case and call sys_double_to_chars for the >>>>>>>> unoptimized. >>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>> questioning >>>>>>> the issue of backward compatibility only in terms of converting >>>>>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>>>>> think >>>>>>> that this will have adverse performance tax on float_to_list_2, which >>>>>>> will diminish the benefit. It's been a while however, since I wrote >>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>> without a performance penalty. >>>>>>> >>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>> rounding >>>>>>> involved. >>>>>>> >>>>>>> This case is easy: >>>>>>> >>>>>>> 4> float_to_list(1.01234). >>>>>>> "1.01234000000000001762e+00" >>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>> "1.01234000000000001762" >>>>>>> >>>>>>> This case is a bit more complex (illustration of rounding impact): >>>>>>> >>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>> "1.01234123450123443604e+10" >>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>> "10123412345.01234436035156250000" >>>>>>> >>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent with how >>>>>>>> other such APIs work. >>>>>>> Actually if you trace this subject back there was another request that >>>>>>> the default number of decimals is chosen to be consistent with what >>>>>>> printf() does, so I changed the implementation to accommodate that >>>>>>> request: >>>>>>> >>>>>>> Eshell V5.9 (abort with ^G) >>>>>>> 1> float_to_list(1.0, []). >>>>>>> "1.000000" >>>>>>> >>>>>>> Which is different from the default of float_to_list/1: >>>>>>> >>>>>>> 2> float_to_list(1.0). >>>>>>> "1.00000000000000000000e+00" >>>>>>> >>>>>>> Maybe one could introduce a 'scientific' option to float_to_list/2, to >>>>>>> use the float_to_list/1 implementation? >>>>>>> >>>>>>> Serge >>>>>>> >>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>> Henrik, >>>>>>>>> >>>>>>>>> Fetch: git fetch >>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>> >>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>> happy: >>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>> suites >>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I tried the >>>>>>>>> following but all tests fail: >>>>>>>>> >>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>> test_server_ctrl >>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>> >>>>>>>>> I did however run individual tests in bif_SUIT:types to make sure my >>>>>>>>> patch didn't break anything. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Serge >>>>>>>>> >>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>> Hi again. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>> >>>>>>>>>> No type information: >>>>>>>>>> >>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>> _______________________________________________ >>>>>>>>> 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 egil@REDACTED Fri Jan 11 15:01:31 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 11 Jan 2013 15:01:31 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <1357893228.4818.2.camel@sekic1152.rnd.ki.sw.ericsson.se> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> <1357893228.4818.2.camel@sekic1152.rnd.ki.sw.ericsson.se> Message-ID: <50F01B3B.2010000@erlang.org> On 2013-01-11 09:33, Bengt Kleberg wrote: > Greetings, > > FWIW I would like to not autoimport any more functions. The existing > ones are confusing enough when reading up on new code. I agree. Hence why I would like to put new BIF functions in other modules. The only argument for having a binary_to_integer and friend auto-imported is by friendship to list_to_integer and such functions. Since those functions are auto-imported these ones should be too. The argument is mute if we change the module I think. // Bj?rn-Egil > > > bengt > > On Thu, 2013-01-10 at 23:05 +0100, Lo?c Hoguin wrote: >> binary:integer_to_string/1 is hardly intuitive. Especially if you write >> it like this: >> >> Module = binary, >> %% ... >> Module:integer_to_string(123) >> >> Do you get a binary() or a string()? >> >> If you create a function type1_to_type2 it's much better if type1 and >> type2 correspond to actual types. >> >> Wherever you place it I don't think it should be named anything other >> than integer_to_binary. However it should be autoimported, because >> writing integer_to_binary first and then remembering the function >> doesn't exist is what many of us do regularly. We already have the >> reflex, we only miss the call to be available. >> >> On 01/10/2013 08:31 PM, Serge Aleynikov wrote: >>> Thanks for the explanation! The API naming is a headache indeed. >>> >>> It does make sense to define these functions in the binary module. >>> Though while binary:string_to_integer/1 is intuitive, I think >>> binary:integer_to_string/1 would be a more intuitive name than >>> binary:string_from_integer/1 (this also would be more consistent with >>> binary:{bin,list}_to_{list,bin}. >>> >>> On 1/10/2013 1:50 PM, Bj?rn-Egil Dahlberg wrote: >>>> On 2013-01-10 18:55, Serge Aleynikov wrote: >>>>> I was under impression that Lucas would take care of modifications he >>>>> proposed in the thread you quoted. Meanwhile I'll see if I can find >>>>> time to do this. >>>> I think the key words were "if it gets prioritized" =) >>>> Granted, we could be more clear on intention. I think in this case we >>>> supposedly had time which drastically changed at some point .. >>>> >>>>> Do you already have an implementation of binary <-> integer? If not, >>>>> maybe I could look at that one as well when I poke around the BIFs, >>>>> since this is also something very commonly needed. >>>> Right, what I did was to take the list conversions to integer and made >>>> it binary comprehensible. >>>> >>>> That was the easy bit. >>>> >>>> However, >>>> Now I have >>>> * erlang:binary_to_integer/1 and >>>> * erlang:integer_to_binary/1 >>>> which seems fine. The compiler will auto-import them as well. >>>> >>>> After I did that I began to reconsider this choice. Perhaps it should be >>>> >>>> * binary:to_integer/1 and binary:from_integer/1 instead? Or, >>>> * binary:string_from_integer/1 and binary:string_to_integer/1, >>>> emphasizing that this is a textual representation of integer in binary >>>> format. Then I got a headache. >>>> >>>> The arguments for the first one (current) is: >>>> * list_to_integer has same type of ideas, same type of behavior. Avoids >>>> confusion. >>>> The arguments against the first one, >>>> * Clutters the erlang module with yet more BIF's >>>> * We already have a binary module, let's use it! >>>> * And finally: avoid confusion! Does erlang:integer_to_binary(102341) >>>> mean <<0,1,143,197>> or <<"102341">> ? >>>> >>>> I'm leaning towards the latter. >>>> >>>> Also, I didn't implement base conversion, so that needs doing. I think >>>> the list conversion is done in Erlang which seems backwards. >>>> >>>> Anyways, the current implementation is at: >>>> https://github.com/psyeugenic/otp/commits/egil/r16/binary_to_integer >>>> >>>> But the real work is taking a position on the API and consider the >>>> different ramifications. I still have that headache .. >>>> >>>> Yet another also, perhaps this implementation isn't the way to go. From >>>> what I remember erlang:binary_to_integer didn't have the speedup I first >>>> envisioned. Ofc, it was faster than doing >>>> binary_to_list(list_to_integer(X)) but binary_to_integer was on par with >>>> this list_to_integer .. which seemed a bit off. >>>> >>>> I want to refrain from using strtol directly (I think that >>>> implementation is similar anyways and we still need to handle bignums). >>>> >>>> I think I want to change the current implementation to taking the base >>>> as argument to the BIF and perhaps using arity one function as an erlang >>>> wrapper. (And doing the same for list_to_integer). The arguments against >>>> that is, surely the arity one functions is far more used and it should >>>> be slightly faster to that call directly. >>>> >>>> // Bj?rn-Egil >>>> >>>>> On 1/10/2013 12:41 PM, Bj?rn-Egil Dahlberg wrote: >>>>>> On 2013-01-10 18:08, Serge Aleynikov wrote: >>>>>>> Not quite - in two days my "new float_to_list/2" patch is celebrating >>>>>>> its 2 year anniversary sitting in the awaiting mode. ;-) >>>>>> Nice =o >>>>>> However, it is not really as you imply. A simple patch that has been >>>>>> ignored for two years =) >>>>>> >>>>>> I checked in Monitor/OTP: >>>>>> * sal/float_to_list_2 >>>>>> * status: unassigned >>>>>> * location: limbo (not present in any active backlog) >>>>>> * notes: waiting for response from author (noted by Lukas) >>>>>> >>>>>> Lukas is currently on a mountain somewhere in south america so I can't >>>>>> really ask him about it. >>>>>> >>>>>> As I recall, your patch had some controversy about precision? >>>>>> >>>>>> And the last mail conversation mention something about modifications >>>>>> needed and if we were to do it we had to prioritize it along with >>>>>> already planned work. Needless to say, it hasn't been prioritized. >>>>>> >>>>>> http://erlang.org/pipermail/erlang-patches/2012-August/002980.html >>>>>> >>>>>> Personally trying to find time to get binary (text) <-> integer >>>>>> conversions into the backlog. >>>>>> >>>>>> Being realistic, neither your float conversion nor mine will make it to >>>>>> r16. *sadface* >>>>>> >>>>>> >>>>>> // Bj?rn-Egil >>>>>> >>>>>>> On 1/10/2013 10:51 AM, Max Lapshin wrote: >>>>>>>> Serge, you seems to be a fast way to pull patch into upstream =) >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 10, 2013 at 7:24 PM, Serge Aleynikov >>>>>>> > wrote: >>>>>>>> >>>>>>>> That was the fastest acceptance of a patch I ever submitted. >>>>>>>> ;-) >>>>>>>> >>>>>>>> On 1/10/2013 10:03 AM, Fredrik wrote: >>>>>>>> > Hello Serge, >>>>>>>> > Your patch is now in the 'master-pu' branch. >>>>>>>> > Thanks for your contribution! >>>>>>>> > >>>>>>>> > BR Fredrik Gustafsson >>>>>>>> > Erlang OTP Team >>>>>>>> > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>>>>> >> Added an application:get_env/3 function variant that >>>>>>>> provides a >>>>>>>> default >>>>>>>> >> value for a configuration parameter: >>>>>>>> >> >>>>>>>> >> application:get_env(App, Key, Default) -> Value. >>>>>>>> >> >>>>>>>> >> git fetch git://github.com/saleyn/otp.git >>>>>>>> get_env >>>>>>>> >> >>>>>>>> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>>>>>> >> >>>>>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 >>> >> > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From serge@REDACTED Fri Jan 11 15:11:57 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 11 Jan 2013 09:11:57 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F01971.7070009@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> Message-ID: <50F01DAD.50101@aleynikov.org> Ok. Here's the patch rebased to master: git fetch https://github.com/saleyn/otp/tree/float_to_list_2 https://github.com/saleyn/otp/compare/master...float_to_list_2 https://github.com/saleyn/otp/compare/master...float_to_list_2.patch Regards, Serge On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-11 14:24, Serge Aleynikov wrote: >> While looking at this I see that the code in folder >> "erts/emulator/sys/vxworks" is present in maint but missing in the >> master branch. Is this intentional? If so, should I remove the part of >> the patch designed for vxworks? > Yes. Any and all vxworks support has been removed in R16 from OTP except > for epmd, erl_interface and ic. > > // Bj?rn-Egil >> >> On 1/11/2013 3:52 AM, Fredrik wrote: >>> Hey, >>> Could you please rebase this on current 'master' branch? >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>> I implemented Lukas's recommendations that were presenting an >>>> acceptance >>>> issue of the new function, so the current version of the patch does: >>>> >>>> 1. float_to_list/1 is backwards compatible. >>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>> (with the optional compact option). >>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>> float_to_list(X) with the ability to control the number of decimals. >>>> >>>> The only item from Lucas's list that I left unchanged was the >>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>> advantage of the speed improvement of the new implementation. I am >>>> including a patch in this email that implements this logic, but I >>>> decided to leave the integration task to the OTP team since >>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>> library and I didn't want to introduce a dependency of it on other code >>>> - this should be decided by maintainers. >>>> >>>> The test cases of float_to_list/{1,2} have been updated. >>>> >>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>> >>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>> >>>> Regards, >>>> >>>> Serge >>>> >>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>> Hi, >>>>> >>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>> R16B. >>>>> >>>>> As always if you (or someone else) wants make sure it gets in, the >>>>> best >>>>> way to ensure that is to send an updated patch. >>>>> >>>>> Lukas >>>>> >>>>> >>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>> I am certainly very happy to hear that you finally agreed to include >>>>>> this in the distribution. The changes proposed below seem reasonable >>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>> implement >>>>>> them? >>>>>> >>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>> Hello Serge! >>>>>>> >>>>>>> I think we have finally agreed how we want this functionality to >>>>>>> work. >>>>>>> >>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>> compatibility. >>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>> implementation >>>>>>> (with the optional compact option). >>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>> float_to_list(1.0) if Y is 20. >>>>>>> >>>>>>> We would also like the string rendering part of >>>>>>> sys_double_to_chars_fast >>>>>>> to be put into >>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>> way other parts of the vm which print floats will benefit from your >>>>>>> changes! >>>>>>> >>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>> taking >>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>> ponderings just let me know. >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>> e+XX at >>>>>>>>> the end of the optimized case and call sys_double_to_chars for the >>>>>>>>> unoptimized. >>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>> questioning >>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>>>>>> think >>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>> which >>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>> wrote >>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>> without a performance penalty. >>>>>>>> >>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>> rounding >>>>>>>> involved. >>>>>>>> >>>>>>>> This case is easy: >>>>>>>> >>>>>>>> 4> float_to_list(1.01234). >>>>>>>> "1.01234000000000001762e+00" >>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>> "1.01234000000000001762" >>>>>>>> >>>>>>>> This case is a bit more complex (illustration of rounding impact): >>>>>>>> >>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>> "1.01234123450123443604e+10" >>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>> "10123412345.01234436035156250000" >>>>>>>> >>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>> with how >>>>>>>>> other such APIs work. >>>>>>>> Actually if you trace this subject back there was another >>>>>>>> request that >>>>>>>> the default number of decimals is chosen to be consistent with what >>>>>>>> printf() does, so I changed the implementation to accommodate that >>>>>>>> request: >>>>>>>> >>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>> 1> float_to_list(1.0, []). >>>>>>>> "1.000000" >>>>>>>> >>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>> >>>>>>>> 2> float_to_list(1.0). >>>>>>>> "1.00000000000000000000e+00" >>>>>>>> >>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>> float_to_list/2, to >>>>>>>> use the float_to_list/1 implementation? >>>>>>>> >>>>>>>> Serge >>>>>>>> >>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>> Henrik, >>>>>>>>>> >>>>>>>>>> Fetch: git fetch >>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>> >>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>> happy: >>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>> suites >>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>> tried the >>>>>>>>>> following but all tests fail: >>>>>>>>>> >>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>> test_server_ctrl >>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>> >>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>> sure my >>>>>>>>>> patch didn't break anything. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Serge >>>>>>>>>> >>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>> Hi again. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>> >>>>>>>>>>> No type information: >>>>>>>>>>> >>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 fredrik@REDACTED Fri Jan 11 15:22:50 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 15:22:50 +0100 Subject: [erlang-patches] escript does not parse supplied vm args on Windows In-Reply-To: References: Message-ID: <50F0203A.2050602@erlang.org> Hello Dave, Could you submit your patch this way: https://github.com/erlang/otp/wiki/submitting-patches and scroll down to "Sending the patch" Thanks! BR Fredrik Gustafsson Erlang OTP Team On 12/18/2012 12:14 PM, Dave Cottlehuber wrote: > Bumping, is there anything you'd like differently so this could go > into R16 please? > > Gist has been updated according to the thread, > https://gist.github.com/4189389ecd2bf1ca8163 I am not confident I have > the whitespacing right, the escript.c style seems to vary a lot. > > We are very close to escript perfection on Windows! > > A+ > Dave > > On 27 November 2012 14:40, Dave Cottlehuber wrote: >> On Windows, the vmargs are not passed through from the 2nd or 3rd >> line of the escript file if the shebang syntax is not the unix shell >> style. Which it often isn't, as you'd expect. >> >> On unix, this produces the expected output of init-debug before requesting beer: >> >> ## ./icanhaz >> >> #!/usr/bin/env escript >> %% -*- erlang -*- >> %%! -init_debug -smp enable >> main(_) -> io:format("I CAN HAZ BEER?~n", []). >> >> On Windows, only the BEER is requested: >> >> ## icanhaz.cmd >> >> @echo off& setlocal& path=%~dp0;%path%;& escript.exe >> "%~dpn0.cmd" %*& goto :eof >> %% -*- erlang -*- >> %%! -init_debug -smp enable >> main(_) -> io:format("I CAN HAZ BEER?~n", []). >> >> NB: the somewhat cryptic sequence above tells a windows .cmd script to >> suppress printing the batch file commands as they are processed, so >> this @ would be a very common approach on windows. The path juggling >> inside allows you distribute an escript with a NIF-based DLL alongside >> in the same directory and have it "just work" without altering the >> system or shell path. >> >> Here's a small patch, accepting that the @ format is common on windows >> https://gist.github.com/4189389ecd2bf1ca8163 >> >> diff --git i/erts/etc/common/escript.c w/erts/etc/common/escript.c >> index 9e80ec6..dcb1c85 100644 >> --- i/erts/etc/common/escript.c >> +++ w/erts/etc/common/escript.c >> @@ -264,7 +264,8 @@ append_shebang_args(char* scriptname) >> static char linebuf[LINEBUFSZ]; >> char* ptr = fgets(linebuf, LINEBUFSZ, fd); >> >> - if (ptr != NULL&& linebuf[0] == '#'&& linebuf[1] == '!') { >> + /* Acceptable Shebang syntax is #/ for unix or @ for windows */ >> + if (ptr != NULL&& ((linebuf[0] == '#'&& linebuf[1] == '!') || >> linebuf[0] == '@')) { >> /* Try to find args on second or third line */ >> ptr = fgets(linebuf, LINEBUFSZ, fd); >> if (ptr != NULL&& linebuf[0] == '%'&& linebuf[1] == '%'&& >> linebuf[2] == '!') { >> >> NBB: the whitespace in escript.c is inconsistent. The patch reflects this. >> >> NBBB: This yak was brought to you fully shaved whilst trying to >> understand why `-detached` wasn't working in escript on Windows. >> >> A+ >> Dave > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Fri Jan 11 15:27:57 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 15:27:57 +0100 Subject: [erlang-patches] escript to accept emulator flags in scripts without shebang In-Reply-To: References: Message-ID: <50F0216D.2040203@erlang.org> Hello Magnus, I have fetched and I am now building it in 'master-pu' branch. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/08/2013 07:50 PM, Magnus Henoch wrote: > The documentation for escript says that if the second or third line of > the script starts with %%!, the rest of the line will be used as > emulator arguments. However, currently this is only the case if the > first line starts with #!. I couldn't see any reason for that, so here > is a patch that removes this undocumented limitation. > > git fetch git://github.com/legoscia/otp.git escript_emulator_flags_vs_shebang > > https://github.com/legoscia/otp/compare/erlang:master...legoscia:escript_emulator_flags_vs_shebang > https://github.com/legoscia/otp/compare/erlang:master...legoscia:escript_emulator_flags_vs_shebang.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Fri Jan 11 15:29:55 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 15:29:55 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F01DAD.50101@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> Message-ID: <50F021E3.9020904@erlang.org> Thanks, It's building in 'master-pu' now! BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 03:11 PM, Serge Aleynikov wrote: > Ok. Here's the patch rebased to master: > > git fetch https://github.com/saleyn/otp/tree/float_to_list_2 > > https://github.com/saleyn/otp/compare/master...float_to_list_2 > https://github.com/saleyn/otp/compare/master...float_to_list_2.patch > > Regards, > > Serge > > On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-11 14:24, Serge Aleynikov wrote: >>> While looking at this I see that the code in folder >>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>> master branch. Is this intentional? If so, should I remove the part of >>> the patch designed for vxworks? >> Yes. Any and all vxworks support has been removed in R16 from OTP except >> for epmd, erl_interface and ic. >> >> // Bj?rn-Egil >>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>> Hey, >>>> Could you please rebase this on current 'master' branch? >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>> I implemented Lukas's recommendations that were presenting an >>>>> acceptance >>>>> issue of the new function, so the current version of the patch does: >>>>> >>>>> 1. float_to_list/1 is backwards compatible. >>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>> (with the optional compact option). >>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>> float_to_list(X) with the ability to control the number of decimals. >>>>> >>>>> The only item from Lucas's list that I left unchanged was the >>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>> advantage of the speed improvement of the new implementation. I am >>>>> including a patch in this email that implements this logic, but I >>>>> decided to leave the integration task to the OTP team since >>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>> library and I didn't want to introduce a dependency of it on other code >>>>> - this should be decided by maintainers. >>>>> >>>>> The test cases of float_to_list/{1,2} have been updated. >>>>> >>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>> >>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>> >>>>> Regards, >>>>> >>>>> Serge >>>>> >>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>> R16B. >>>>>> >>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>> best >>>>>> way to ensure that is to send an updated patch. >>>>>> >>>>>> Lukas >>>>>> >>>>>> >>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>> I am certainly very happy to hear that you finally agreed to include >>>>>>> this in the distribution. The changes proposed below seem reasonable >>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>> implement >>>>>>> them? >>>>>>> >>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>> Hello Serge! >>>>>>>> >>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>> work. >>>>>>>> >>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>> compatibility. >>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>> implementation >>>>>>>> (with the optional compact option). >>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>> >>>>>>>> We would also like the string rendering part of >>>>>>>> sys_double_to_chars_fast >>>>>>>> to be put into >>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>> way other parts of the vm which print floats will benefit from your >>>>>>>> changes! >>>>>>>> >>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>> taking >>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>> ponderings just let me know. >>>>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>> e+XX at >>>>>>>>>> the end of the optimized case and call sys_double_to_chars for the >>>>>>>>>> unoptimized. >>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>> questioning >>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>>>>>>> think >>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>> which >>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>> wrote >>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>> without a performance penalty. >>>>>>>>> >>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>> rounding >>>>>>>>> involved. >>>>>>>>> >>>>>>>>> This case is easy: >>>>>>>>> >>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>> "1.01234000000000001762" >>>>>>>>> >>>>>>>>> This case is a bit more complex (illustration of rounding impact): >>>>>>>>> >>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>> >>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>> with how >>>>>>>>>> other such APIs work. >>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>> request that >>>>>>>>> the default number of decimals is chosen to be consistent with what >>>>>>>>> printf() does, so I changed the implementation to accommodate that >>>>>>>>> request: >>>>>>>>> >>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>> "1.000000" >>>>>>>>> >>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>> >>>>>>>>> 2> float_to_list(1.0). >>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>> >>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>> float_to_list/2, to >>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>> >>>>>>>>> Serge >>>>>>>>> >>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>> Henrik, >>>>>>>>>>> >>>>>>>>>>> Fetch: git fetch >>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>> >>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>> happy: >>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>> suites >>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>> tried the >>>>>>>>>>> following but all tests fail: >>>>>>>>>>> >>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>> test_server_ctrl >>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>> >>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>> sure my >>>>>>>>>>> patch didn't break anything. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Serge >>>>>>>>>>> >>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>> Hi again. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>> >>>>>>>>>>>> No type information: >>>>>>>>>>>> >>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 dch@REDACTED Fri Jan 11 15:48:49 2013 From: dch@REDACTED (Dave Cottlehuber) Date: Fri, 11 Jan 2013 15:48:49 +0100 Subject: [erlang-patches] escript does not parse supplied vm args on Windows In-Reply-To: <50F0203A.2050602@erlang.org> References: <50F0203A.2050602@erlang.org> Message-ID: Hi Fredrik, Thanks for looking at this. Magnus has proposed a more general patch: http://permalink.gmane.org/gmane.comp.lang.erlang.patches/3273 I'm happy to withdraw mine in favour of his. Thanks Dave On 11 January 2013 15:22, Fredrik wrote: > Hello Dave, > Could you submit your patch this way: > https://github.com/erlang/otp/wiki/submitting-patches and scroll down to > "Sending the patch" > Thanks! > > BR Fredrik Gustafsson > Erlang OTP Team > > On 12/18/2012 12:14 PM, Dave Cottlehuber wrote: > > Bumping, is there anything you'd like differently so this could go > into R16 please? > > Gist has been updated according to the thread, > https://gist.github.com/4189389ecd2bf1ca8163 I am not confident I have > the whitespacing right, the escript.c style seems to vary a lot. > > We are very close to escript perfection on Windows! > > A+ > Dave > > On 27 November 2012 14:40, Dave Cottlehuber wrote: > > On Windows, the vmargs are not passed through from the 2nd or 3rd > line of the escript file if the shebang syntax is not the unix shell > style. Which it often isn't, as you'd expect. > > On unix, this produces the expected output of init-debug before requesting > beer: > > ## ./icanhaz > > #!/usr/bin/env escript > %% -*- erlang -*- > %%! -init_debug -smp enable > main(_) -> io:format("I CAN HAZ BEER?~n", []). > > On Windows, only the BEER is requested: > > ## icanhaz.cmd > > @echo off & setlocal & path=%~dp0;%path%; & escript.exe > "%~dpn0.cmd" %* & goto :eof > %% -*- erlang -*- > %%! -init_debug -smp enable > main(_) -> io:format("I CAN HAZ BEER?~n", []). > > NB: the somewhat cryptic sequence above tells a windows .cmd script to > suppress printing the batch file commands as they are processed, so > this @ would be a very common approach on windows. The path juggling > inside allows you distribute an escript with a NIF-based DLL alongside > in the same directory and have it "just work" without altering the > system or shell path. > > Here's a small patch, accepting that the @ format is common on windows > https://gist.github.com/4189389ecd2bf1ca8163 > > diff --git i/erts/etc/common/escript.c w/erts/etc/common/escript.c > index 9e80ec6..dcb1c85 100644 > --- i/erts/etc/common/escript.c > +++ w/erts/etc/common/escript.c > @@ -264,7 +264,8 @@ append_shebang_args(char* scriptname) > static char linebuf[LINEBUFSZ]; > char* ptr = fgets(linebuf, LINEBUFSZ, fd); > > - if (ptr != NULL && linebuf[0] == '#' && linebuf[1] == '!') { > + /* Acceptable Shebang syntax is #/ for unix or @ for windows */ > + if (ptr != NULL && ((linebuf[0] == '#' && linebuf[1] == '!') || > linebuf[0] == '@')) { > /* Try to find args on second or third line */ > ptr = fgets(linebuf, LINEBUFSZ, fd); > if (ptr != NULL && linebuf[0] == '%' && linebuf[1] == '%' && > linebuf[2] == '!') { > > NBB: the whitespace in escript.c is inconsistent. The patch reflects this. > > NBBB: This yak was brought to you fully shaved whilst trying to > understand why `-detached` wasn't working in escript on Windows. > > A+ > Dave > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From fredrik@REDACTED Fri Jan 11 15:53:11 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 15:53:11 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: Message-ID: <50F02757.4070304@erlang.org> Hello Anthony, I don't see a reply on this patch, but it is in our systems and currently being reviewed. You will get an answer when I know more about it. BR Fredrik Gustafsson Erlang OTP Team On 11/10/2012 04:28 PM, Anthony Ramine wrote: > Hi, > > This branch adds a new option "end" to erl_scan. If set, it tracks and > returns end locations of each scanned token in their attributes as > `{'end', {EndLine, EndCol}}`. > > https://github.com/nox/otp/compare/scan-end-locations > https://github.com/nox/otp/compare/scan-end-locations.patch > > git fetch https://github.com/nox/otp scan-end-locations > > Regards, > From fredrik@REDACTED Fri Jan 11 15:59:04 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 15:59:04 +0100 Subject: [erlang-patches] Additional error-handling file:path_open/3 In-Reply-To: References: Message-ID: <50F028B8.5060407@erlang.org> Hello, I don't see a reply on this, but I am happy to tell you that this patch was merged to master the 13th of December! Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 11/04/2012 03:54 PM, Thomas J?rvstrand wrote: > Hi! > > file:path_open/3 currently doesn't handle eisdir or enotdir return > values from file:open/2. Suppose we want to do path_open(["dir1", > "dir2"], "sub/file") and dir2/sub/file is the actual path of the file > that we are looking for. The effect of not handling these error cases > is that the call will fail if dir1 happens to contain either a regular > file called sub (file:open/2 returns enotdir) or a directory sub that > in turn contains a directory file (file:open/2 return eisdir). > > This patch handles these extra error cases in file:path_open/3 > > Repo: > git fetch git@REDACTED:tjarvstrand/otp.git > additional-error-cases-in-path_open > > Comparison: > https://github.com/tjarvstrand/otp/compare/additional-error-cases-in-path_open > https://github.com/tjarvstrand/otp/compare/additional-error-cases-in-path_open.patch > > Regards > Thomas J?rvstrand > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Fri Jan 11 16:29:50 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 16:29:50 +0100 Subject: [erlang-patches] use a proper way to pull ssize_t definition In-Reply-To: <20121116023021.F0E5714A1B4@mail.netbsd.org> References: <20121116023021.F0E5714A1B4@mail.netbsd.org> Message-ID: <50F02FEE.6020905@erlang.org> Hello, Sorry for the late answer, your patch is now in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 11/16/2012 03:30 AM, YAMAMOTO Takashi wrote: > hi, > > this change is necessary at least on netbsd. > i noticed this when building erlang-lz4. > > https://github.com/yamt/otp/compare/erlang:master...ssize_t > https://github.com/yamt/otp/compare/erlang:master...ssize_t.patch > > git fetch https://github.com/yamt/otp ssize_t > > YAMAMOTO Takashi > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From egil@REDACTED Fri Jan 11 16:37:05 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 11 Jan 2013 16:37:05 +0100 Subject: [erlang-patches] Updates to file:allocate/2 (currently in master-opu) In-Reply-To: References: <50CB3CCE.2010407@erlang.org> <50CEDDEC.5070301@erlang.org> <50EED679.3060100@erlang.org> Message-ID: <50F031A1.5090708@erlang.org> Merged patch. Closing issue designated OTP-10680. // Bj?rn-Egil On 2013-01-10 16:05, Filipe David Manana wrote: > Looks good to me. > Thanks > > On Thu, Jan 10, 2013 at 2:55 PM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-09 18:11, Bj?rn-Egil Dahlberg wrote: >> >> I think this patch has passed through here in various incarnations the last >> two years. I get the feeling that it got missed in some hand over between >> people. I'm truly sorry about that. >> >> This will happen now, >> * I will add the patch to integration, i.e. master-opu >> * If it passes the final step, i will merge it to master and will be part >> of beta testing in R16A release. >> * If R16A is fine it will of course also be included in the proper R16B >> release. >> >> >> >> >> So .. this broke during cross-compilation test AC_TRY_RUN did not have an >> cross-compilation option. >> * Added the safer default option 'no' in cross-compilation >> >> See: https://github.com/psyeugenic/otp/commits/fdm/file-allocate >> >> Do you a better solution or should we stick with this? I will test this >> option a bit more still. >> >> Could be reproduced with: >> ./otp_build autoconf >> ./otp_build configure --enable-sctp >> --xcomp-conf=xcomp/erl-xcomp-powerpc-dso-linux-gnu.conf >> >> (Needs powerpc gcc toolchain for cross compilation in path) >> >> >> >> >> // Bj?rn-Egil >> >> 2012/12/17 Fredrik >>> Hello Filipe! >>> The patch is now in the 'master-pu' branch. >>> >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/14/2012 04:41 PM, Filipe David Manana wrote: >>>> On Fri, Dec 14, 2012 at 2:50 PM, Fredrik wrote: >>>>> Hello Filipe, >>>>> Create a new branch and mail me back the fetch command and links, and I >>>>> will >>>>> fetch and put them into master-pu. >>>> Fredrik, >>>> >>>> I squashed all the commits into a new branch: >>>> >>>> git fetch git://github.com/fdmanana/otp.git file_allocate_squashed >>>> >>>> >>>> https://github.com/fdmanana/otp/compare/master...file_allocate_squashed.patch >>>> https://github.com/fdmanana/otp/compare/master...file_allocate_squashed >>>> >>>> Thank you >>>> >>>> >>>>> BR Fredrik Gustafsson >>>>> Erlang OTP Team >>>>> >>>>> On 12/14/2012 03:46 PM, Filipe David Manana wrote: >>>>>> Hello, >>>>>> >>>>>> I added 2 commits on top of the existing ones for the file:allocate/2 >>>>>> patch, currently in master-pu branch. >>>>>> >>>>>> They can be found in the following branch: >>>>>> >>>>>> git fetch git://github.com/fdmanana/otp.git file_allocate >>>>>> >>>>>> >>>>>> These commits are the most recent: >>>>>> >>>>>> https://github.com/fdmanana/otp/commits/file_allocate >>>>>> >>>>>> Can you pick them, or shall I create a new branch with all of them >>>>>> squashed into a single commit? >>>>>> >>>>>> Thank you >>>>>> >>>>>> >>>> >>> _______________________________________________ >>> 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 fredrik@REDACTED Fri Jan 11 16:44:25 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 11 Jan 2013 16:44:25 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F01DAD.50101@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> Message-ID: <50F03359.1080800@erlang.org> Hey, Your patch does not build: " emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern " Please have a look at it, and give me notice when you are done. BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 03:11 PM, Serge Aleynikov wrote: > Ok. Here's the patch rebased to master: > > git fetch https://github.com/saleyn/otp/tree/float_to_list_2 > > https://github.com/saleyn/otp/compare/master...float_to_list_2 > https://github.com/saleyn/otp/compare/master...float_to_list_2.patch > > Regards, > > Serge > > On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-11 14:24, Serge Aleynikov wrote: >>> While looking at this I see that the code in folder >>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>> master branch. Is this intentional? If so, should I remove the part of >>> the patch designed for vxworks? >> Yes. Any and all vxworks support has been removed in R16 from OTP except >> for epmd, erl_interface and ic. >> >> // Bj?rn-Egil >>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>> Hey, >>>> Could you please rebase this on current 'master' branch? >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>> I implemented Lukas's recommendations that were presenting an >>>>> acceptance >>>>> issue of the new function, so the current version of the patch does: >>>>> >>>>> 1. float_to_list/1 is backwards compatible. >>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>> (with the optional compact option). >>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>> float_to_list(X) with the ability to control the number of decimals. >>>>> >>>>> The only item from Lucas's list that I left unchanged was the >>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>> advantage of the speed improvement of the new implementation. I am >>>>> including a patch in this email that implements this logic, but I >>>>> decided to leave the integration task to the OTP team since >>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>> library and I didn't want to introduce a dependency of it on other code >>>>> - this should be decided by maintainers. >>>>> >>>>> The test cases of float_to_list/{1,2} have been updated. >>>>> >>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>> >>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>> >>>>> Regards, >>>>> >>>>> Serge >>>>> >>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>> R16B. >>>>>> >>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>> best >>>>>> way to ensure that is to send an updated patch. >>>>>> >>>>>> Lukas >>>>>> >>>>>> >>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>> I am certainly very happy to hear that you finally agreed to include >>>>>>> this in the distribution. The changes proposed below seem reasonable >>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>> implement >>>>>>> them? >>>>>>> >>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>> Hello Serge! >>>>>>>> >>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>> work. >>>>>>>> >>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>> compatibility. >>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>> implementation >>>>>>>> (with the optional compact option). >>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>> >>>>>>>> We would also like the string rendering part of >>>>>>>> sys_double_to_chars_fast >>>>>>>> to be put into >>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>> way other parts of the vm which print floats will benefit from your >>>>>>>> changes! >>>>>>>> >>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>> taking >>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>> ponderings just let me know. >>>>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>> float_to_list_1 as well, is possible to do this and stay backwards >>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>> e+XX at >>>>>>>>>> the end of the optimized case and call sys_double_to_chars for the >>>>>>>>>> unoptimized. >>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>> questioning >>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. However, I >>>>>>>>> think >>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>> which >>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>> wrote >>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>> without a performance penalty. >>>>>>>>> >>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>> rounding >>>>>>>>> involved. >>>>>>>>> >>>>>>>>> This case is easy: >>>>>>>>> >>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>> "1.01234000000000001762" >>>>>>>>> >>>>>>>>> This case is a bit more complex (illustration of rounding impact): >>>>>>>>> >>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>> >>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>> with how >>>>>>>>>> other such APIs work. >>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>> request that >>>>>>>>> the default number of decimals is chosen to be consistent with what >>>>>>>>> printf() does, so I changed the implementation to accommodate that >>>>>>>>> request: >>>>>>>>> >>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>> "1.000000" >>>>>>>>> >>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>> >>>>>>>>> 2> float_to_list(1.0). >>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>> >>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>> float_to_list/2, to >>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>> >>>>>>>>> Serge >>>>>>>>> >>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>> Henrik, >>>>>>>>>>> >>>>>>>>>>> Fetch: git fetch >>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>> >>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>> happy: >>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>> suites >>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>> tried the >>>>>>>>>>> following but all tests fail: >>>>>>>>>>> >>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>> test_server_ctrl >>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>> >>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>> sure my >>>>>>>>>>> patch didn't break anything. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Serge >>>>>>>>>>> >>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>> Hi again. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>> >>>>>>>>>>>> No type information: >>>>>>>>>>>> >>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 essen@REDACTED Fri Jan 11 16:44:32 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 11 Jan 2013 16:44:32 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <50F01B3B.2010000@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> <1357893228.4818.2.camel@sekic1152.rnd.ki.sw.ericsson.se> <50F01B3B.2010000@erlang.org> Message-ID: <50F03360.70203@ninenines.eu> On 01/11/2013 03:01 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-11 09:33, Bengt Kleberg wrote: >> Greetings, >> >> FWIW I would like to not autoimport any more functions. The existing >> ones are confusing enough when reading up on new code. > I agree. > > Hence why I would like to put new BIF functions in other modules. > > The only argument for having a binary_to_integer and friend > auto-imported is by friendship to list_to_integer and such functions. > Since those functions are auto-imported these ones should be too. > > The argument is mute if we change the module I think. By friendship? That's a weird way to say it. This is *consistency*. There are a number of base types in Erlang, including atom(), integer(), float(), list() and binary(). (list() here is generally thought to be string() when it is converted from/to other types, integer_to_list/1 really isn't the best name for it). One would expect conversion from one type to another to be easy to use, efficient and also fast. One would also expect some cases to be edge cases, for example atom to integer, so these do not need a direct conversion mechanism. A developer surely understands that if he does something unusual he'll have to go through more hoops to get his job done. Let's take a look at these types and the current state of the API. atom() to_integer: edge case to_float: edge case to_list: available, but means to_string to_binary: available, encoding is required as a 2nd argument When we get UTF-8 atoms, people will start expecting an atom_to_binary/1 that aliases atom_to_binary/2 with utf8 as default argument. integer() to_atom: edge case to_float: edge case to_list: available, but means to_string, can also specify base to_binary: list_to_binary(integer_to_list(I)), inconvenient float() to_atom: edge case to_float: edge case to_list: available, but means to_string to_binary: list_to_binary(float_to_list(F)), inconvenient Of note is that floats are rarely used in Erlang, so perhaps float_to_binary/1 isn't really needed. list() to_atom: available, also in a safe form to_float: yep to_integer: yep, also with base to_binary: yep You can convert everything to list, but in all cases it means string(). binary() to_atom: available, need to specify encoding, safe form available to_float: list_to_float(binary_to_list(B)), inconvenient to_integer: list_to_integer(binary_to_list(B)), inconvenient to_list: available, but means to_string This shows a number of issues and shortcomings. The biggest one is that when you write 'list' when converting from one type to another, you always mean 'string'. I suppose this is historical, but it's part of what makes string handling in Erlang so difficult. Another is that today, I need to think when converting binary strings to integer, because you write it: intermediate_to_final(initial_to_intermediate(Value)) So everytime I perform a double conversion I have high chances to introduce a bug and waste time. Tomorrow, I could be using these functions: * list_to_atom/1 * list_to_integer/1 * list_to_float/1 * binary:from_list/1 One would expect list_to_binary/1 here. Because that would be consistent (but semantically not exact as you convert a string(), not any list()). If auto-imported BIFs are a problem, perhaps a slow move to a single BIF for example to(ToType, Value) could be beneficial. I'd much rather write to(binary, 123) than any of the alternatives or current proposals including integer_to_binary. It loses the feature that integer_to_binary would check that the value is an integer first, but I don't think it's often counted on in people's code so that could be done separately for the rare cases where it's actually needed. It would also fix the consistency issues, would allow fixing the semantics of list actually meaning string, and a to/3 version could take options as a third argument for the cases where encoding or checking for atom existence are necessary. It would also be easier to add another type later on. -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From serge@REDACTED Fri Jan 11 16:55:53 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 11 Jan 2013 10:55:53 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F03359.1080800@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> Message-ID: <50F03609.6000809@aleynikov.org> Sorry the test case line was the "last moment" add on. It is fixed now in my branch below. On 1/11/2013 10:44 AM, Fredrik wrote: > Hey, > Your patch does not build: > " > > emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern > " > > > Please have a look at it, and give me notice when you are done. > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/11/2013 03:11 PM, Serge Aleynikov wrote: >> Ok. Here's the patch rebased to master: >> >> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >> >> https://github.com/saleyn/otp/compare/master...float_to_list_2 >> https://github.com/saleyn/otp/compare/master...float_to_list_2.patch >> >> Regards, >> >> Serge >> >> On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >>> On 2013-01-11 14:24, Serge Aleynikov wrote: >>>> While looking at this I see that the code in folder >>>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>>> master branch. Is this intentional? If so, should I remove the >>>> part of >>>> the patch designed for vxworks? >>> Yes. Any and all vxworks support has been removed in R16 from OTP except >>> for epmd, erl_interface and ic. >>> >>> // Bj?rn-Egil >>>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>>> Hey, >>>>> Could you please rebase this on current 'master' branch? >>>>> >>>>> BR Fredrik Gustafsson >>>>> Erlang OTP Team >>>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>>> I implemented Lukas's recommendations that were presenting an >>>>>> acceptance >>>>>> issue of the new function, so the current version of the patch does: >>>>>> >>>>>> 1. float_to_list/1 is backwards compatible. >>>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>>> (with the optional compact option). >>>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>>> float_to_list(X) with the ability to control the number of decimals. >>>>>> >>>>>> The only item from Lucas's list that I left unchanged was the >>>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>>> advantage of the speed improvement of the new implementation. I am >>>>>> including a patch in this email that implements this logic, but I >>>>>> decided to leave the integration task to the OTP team since >>>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>>> library and I didn't want to introduce a dependency of it on other >>>>>> code >>>>>> - this should be decided by maintainers. >>>>>> >>>>>> The test cases of float_to_list/{1,2} have been updated. >>>>>> >>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>> >>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>>> >>>>>> Regards, >>>>>> >>>>>> Serge >>>>>> >>>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>>> R16B. >>>>>>> >>>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>>> best >>>>>>> way to ensure that is to send an updated patch. >>>>>>> >>>>>>> Lukas >>>>>>> >>>>>>> >>>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>>> I am certainly very happy to hear that you finally agreed to >>>>>>>> include >>>>>>>> this in the distribution. The changes proposed below seem >>>>>>>> reasonable >>>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>>> implement >>>>>>>> them? >>>>>>>> >>>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>>> Hello Serge! >>>>>>>>> >>>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>>> work. >>>>>>>>> >>>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>>> compatibility. >>>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>>> implementation >>>>>>>>> (with the optional compact option). >>>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>>> >>>>>>>>> We would also like the string rendering part of >>>>>>>>> sys_double_to_chars_fast >>>>>>>>> to be put into >>>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>>> way other parts of the vm which print floats will benefit from >>>>>>>>> your >>>>>>>>> changes! >>>>>>>>> >>>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>>> taking >>>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>>> ponderings just let me know. >>>>>>>>> >>>>>>>>> Lukas >>>>>>>>> >>>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>>> float_to_list_1 as well, is possible to do this and stay >>>>>>>>>>> backwards >>>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>>> e+XX at >>>>>>>>>>> the end of the optimized case and call sys_double_to_chars >>>>>>>>>>> for the >>>>>>>>>>> unoptimized. >>>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>>> questioning >>>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. >>>>>>>>>> However, I >>>>>>>>>> think >>>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>>> which >>>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>>> wrote >>>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>>> without a performance penalty. >>>>>>>>>> >>>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>>> rounding >>>>>>>>>> involved. >>>>>>>>>> >>>>>>>>>> This case is easy: >>>>>>>>>> >>>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>>> "1.01234000000000001762" >>>>>>>>>> >>>>>>>>>> This case is a bit more complex (illustration of rounding >>>>>>>>>> impact): >>>>>>>>>> >>>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>>> >>>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>>> with how >>>>>>>>>>> other such APIs work. >>>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>>> request that >>>>>>>>>> the default number of decimals is chosen to be consistent with >>>>>>>>>> what >>>>>>>>>> printf() does, so I changed the implementation to accommodate >>>>>>>>>> that >>>>>>>>>> request: >>>>>>>>>> >>>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>>> "1.000000" >>>>>>>>>> >>>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>>> >>>>>>>>>> 2> float_to_list(1.0). >>>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>>> >>>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>>> float_to_list/2, to >>>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>>> >>>>>>>>>> Serge >>>>>>>>>> >>>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>>> Henrik, >>>>>>>>>>>> >>>>>>>>>>>> Fetch: git fetch >>>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>>> >>>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>>> happy: >>>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>>> suites >>>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>>> tried the >>>>>>>>>>>> following but all tests fail: >>>>>>>>>>>> >>>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>>> test_server_ctrl >>>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>>> >>>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>>> sure my >>>>>>>>>>>> patch didn't break anything. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Serge >>>>>>>>>>>> >>>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>>> Hi again. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>>> >>>>>>>>>>>>> No type information: >>>>>>>>>>>>> >>>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 Fri Jan 11 17:12:37 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 11 Jan 2013 17:12:37 +0100 Subject: [erlang-patches] Local function names in Core Erlang guards In-Reply-To: <6BADBA9E-8FD4-4051-B960-A13B64A20B53@gmail.com> References: <6BADBA9E-8FD4-4051-B960-A13B64A20B53@gmail.com> Message-ID: Hi, I wrote a really small patch to forbid local fun variables in Core Erlang guards. There is no test case as there is no test suite for core_lint. I know the code freeze for R16 is soon but this is really a very small thing. git fetch https://github.com/nox/otp.git forbid-locals-in-core-guards https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch Regards, -- Anthony Ramine Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : > Hi, > > While patching the compiler to allow substitutions of variables which values are > local function names [1], I discovered that core_lint doesn't forbid them in guards, > even though that makes the compiler passes further down the road generate badly-formed > BEAM code. > > Is that a bug in core_lint or a bug in the BEAM code generation? Should local function > names be allowed in guards? > > If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM > code generation I would love to fix it and remove the code I wrote to avoid the > substitution in guards... but I lack knowledge about the BEAM innards. > > Regards, > > [1] http://erlang.org/pipermail/erlang-patches/2012-November/003137.html > > -- > Anthony Ramine > From egil@REDACTED Fri Jan 11 17:28:49 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 11 Jan 2013 17:28:49 +0100 Subject: [erlang-patches] [patch] binary to/from integer In-Reply-To: <50F03360.70203@ninenines.eu> References: <50EED0CD.3080603@aleynikov.org> <50EED83F.8060702@erlang.org> <50EEDD16.2010502@aleynikov.org> <50EEF581.7060008@aleynikov.org> <50EEFD57.20702@erlang.org> <50EF009E.1080102@aleynikov.org> <50EF0D87.1040405@erlang.org> <50EF1716.5050402@aleynikov.org> <50EF3B2A.50500@ninenines.eu> <1357893228.4818.2.camel@sekic1152.rnd.ki.sw.ericsson.se> <50F01B3B.2010000@erlang.org> <50F03360.70203@ninenines.eu> Message-ID: <50F03DC1.9060700@erlang.org> On 2013-01-11 16:44, Lo?c Hoguin wrote: > On 01/11/2013 03:01 PM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-11 09:33, Bengt Kleberg wrote: >>> Greetings, >>> >>> FWIW I would like to not autoimport any more functions. The existing >>> ones are confusing enough when reading up on new code. >> I agree. >> >> Hence why I would like to put new BIF functions in other modules. >> >> The only argument for having a binary_to_integer and friend >> auto-imported is by friendship to list_to_integer and such functions. >> Since those functions are auto-imported these ones should be too. >> >> The argument is mute if we change the module I think. > > By friendship? That's a weird way to say it. > > This is *consistency*. Nitpicking - I thought consistency was implied since it is the sole reason for this whole thread. =) The thread began, and to be clear I'm paraphrasing here, - "I don't really have time to do this but .. " And I do agree with most of what you say below, if not all. Weird prolog string legacy and type conversions thereof. But that's the thing right. In the erlang module we talk about type conversions and we don't have a string type. Hence integer_to_list and float_to_list. By *consistency* it should be integer_to_binary and binary_to_integer since it is types we talk about in those functions. I'm feeling that headache again. Perhaps gradually moving conversions to other modules is the way forward. Perhaps a string datatype is necessary. Neither will happen right now. // Bj?rn-Egil > There are a number of base types in Erlang, including atom(), > integer(), float(), list() and binary(). (list() here is generally > thought to be string() when it is converted from/to other types, > integer_to_list/1 really isn't the best name for it). > > One would expect conversion from one type to another to be easy to > use, efficient and also fast. One would also expect some cases to be > edge cases, for example atom to integer, so these do not need a direct > conversion mechanism. A developer surely understands that if he does > something unusual he'll have to go through more hoops to get his job > done. > > Let's take a look at these types and the current state of the API. > > atom() > to_integer: edge case > to_float: edge case > to_list: available, but means to_string > to_binary: available, encoding is required as a 2nd argument > > When we get UTF-8 atoms, people will start expecting an > atom_to_binary/1 that aliases atom_to_binary/2 with utf8 as default > argument. > > integer() > to_atom: edge case > to_float: edge case > to_list: available, but means to_string, can also specify base > to_binary: list_to_binary(integer_to_list(I)), inconvenient > > float() > to_atom: edge case > to_float: edge case > to_list: available, but means to_string > to_binary: list_to_binary(float_to_list(F)), inconvenient > > Of note is that floats are rarely used in Erlang, so perhaps > float_to_binary/1 isn't really needed. > > list() > to_atom: available, also in a safe form > to_float: yep > to_integer: yep, also with base > to_binary: yep > > You can convert everything to list, but in all cases it means string(). > > binary() > to_atom: available, need to specify encoding, safe form available > to_float: list_to_float(binary_to_list(B)), inconvenient > to_integer: list_to_integer(binary_to_list(B)), inconvenient > to_list: available, but means to_string > > This shows a number of issues and shortcomings. > > The biggest one is that when you write 'list' when converting from one > type to another, you always mean 'string'. I suppose this is > historical, but it's part of what makes string handling in Erlang so > difficult. > > Another is that today, I need to think when converting binary strings > to integer, because you write it: > > intermediate_to_final(initial_to_intermediate(Value)) > > So everytime I perform a double conversion I have high chances to > introduce a bug and waste time. > > Tomorrow, I could be using these functions: > > * list_to_atom/1 > * list_to_integer/1 > * list_to_float/1 > * binary:from_list/1 > > One would expect list_to_binary/1 here. Because that would be > consistent (but semantically not exact as you convert a string(), not > any list()). > > If auto-imported BIFs are a problem, perhaps a slow move to a single > BIF for example to(ToType, Value) could be beneficial. > > I'd much rather write to(binary, 123) than any of the alternatives or > current proposals including integer_to_binary. It loses the feature > that integer_to_binary would check that the value is an integer first, > but I don't think it's often counted on in people's code so that could > be done separately for the rare cases where it's actually needed. > > It would also fix the consistency issues, would allow fixing the > semantics of list actually meaning string, and a to/3 version could > take options as a third argument for the cases where encoding or > checking for atom existence are necessary. It would also be easier to > add another type later on. > From egil@REDACTED Fri Jan 11 18:06:41 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 11 Jan 2013 18:06:41 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> Message-ID: <50F046A1.6010706@erlang.org> In review. This looks nice and the make output looks crisp and clear. Ehum .. apparently warnings is easier to see as well =o Did you consider doing something like moving the sed rules to make/otp.mk.in instead of changing all the files? $(APP_TARGET): $(APP_SRC) ../vsn.mk $(vsn_verbose)sed -e 's;%VSN%;$(VSN);' $< > $@ $(APPUP_TARGET): $(APPUP_SRC) ../vsn.mk $(vsn_verbose)sed -e 's;%VSN%;$(VSN);' $< > $@ I'm not sure if it would be best or if it even works, just like to hear your thoughts on it. // Bj?rn-Egil On 2012-11-29 10:49, Anthony Ramine wrote: > Le 28 nov. 2012 ? 17:31, Jachym Holecek a ?crit : > >> # Tuncer Ayaz 2012-11-28: >>> On Wed, Nov 28, 2012 at 3:39 PM, Anthony Ramine wrote: >>>> I got bored of the too verbose output of the build process, >> The output isn't there to amuse you but to give you information for >> troubleshooting in case things go wrong. ;-) > I never said I did this patch to have a fancy output or to be amused by it. > > In my quest to EEP20: Split the atoms [1], I need to update a lot of files without ever messing with the Makefiles nor adding any file to the build process or even to the Git repository. Should I be bothered by obscure GCC flags that don't concern me while doing so? Should I not be able to view the various warnings caused by my changes with just a glance? I could use GCC's -Werror but what should I do about warnings that are independent of my tinkering? > >>>> so I added automake's silent rules to Erlang/OTP. >> I never understood the point of a build process generating incomplete >> progress report. Either I wan't all the details (almost always) or >> just the final outcome -- something you can do without any patching: >> >> $ if ! make > /tmp/build.log 2>&1 ;then echo "BUILD FAILED!!!" ; fi > I could just do make "2>&1 | tee make.log" but it is still a pain to find the relevant warnings in the produced make.log file. > >>>> Here is an example of output produced with silent rules: >>>> https://gist.github.com/4160201 >>>> >>>> I may have missed some build tools' invocations as I can only compile >>>> Erlang on my Mac. >>>> >>>> https://github.com/nox/otp/compare/erlang:master...enable-silent-rules >>>> https://github.com/nox/otp/compare/erlang:master...enable-silent-rules.patch >>>> >>>> git fetch https://github.com/nox/otp enable-silent-rules >>> Nice patch, but I would prefer to make the default be silent. >> That's actively harmful -- a build failing on you with useless output >> is already bad enough, having to re-run the build is annoying on its >> own, having to additionally figure out the option that will give you >> useful output is almost insulting. > > I'm with you on letting it non-default; I sometimes yell at rebar for this very reason when I want to see its erlc invocations. > > [1] You can follow my progress on this on https://github.com/nox/otp/compare/erlang:master...eep20 > From n.oxyde@REDACTED Fri Jan 11 18:12:44 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 11 Jan 2013 18:12:44 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F046A1.6010706@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> Message-ID: <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> I could do that, it would make things easier. The patch doesn't yet handle all the things but I submitted it anyway to have a feedback earlier and to know whether I should bother finishing it. I guess your answer is positive enough for me to finish it :) I'll do that this weekend. Regards, -- Anthony Ramine Le 11 janv. 2013 ? 18:06, Bj?rn-Egil Dahlberg a ?crit : > In review. > > This looks nice and the make output looks crisp and clear. Ehum .. apparently warnings is easier to see as well =o > > Did you consider doing something like moving the sed rules to make/otp.mk.in instead of changing all the files? > > $(APP_TARGET): $(APP_SRC) ../vsn.mk > $(vsn_verbose)sed -e 's;%VSN%;$(VSN);' $< > $@ > > $(APPUP_TARGET): $(APPUP_SRC) ../vsn.mk > $(vsn_verbose)sed -e 's;%VSN%;$(VSN);' $< > $@ > > I'm not sure if it would be best or if it even works, just like to hear your thoughts on it. > > // Bj?rn-Egil > > > On 2012-11-29 10:49, Anthony Ramine wrote: >> Le 28 nov. 2012 ? 17:31, Jachym Holecek a ?crit : >> >>> # Tuncer Ayaz 2012-11-28: >>>> On Wed, Nov 28, 2012 at 3:39 PM, Anthony Ramine wrote: >>>>> I got bored of the too verbose output of the build process, >>> The output isn't there to amuse you but to give you information for >>> troubleshooting in case things go wrong. ;-) >> I never said I did this patch to have a fancy output or to be amused by it. >> >> In my quest to EEP20: Split the atoms [1], I need to update a lot of files without ever messing with the Makefiles nor adding any file to the build process or even to the Git repository. Should I be bothered by obscure GCC flags that don't concern me while doing so? Should I not be able to view the various warnings caused by my changes with just a glance? I could use GCC's -Werror but what should I do about warnings that are independent of my tinkering? >> >>>>> so I added automake's silent rules to Erlang/OTP. >>> I never understood the point of a build process generating incomplete >>> progress report. Either I wan't all the details (almost always) or >>> just the final outcome -- something you can do without any patching: >>> >>> $ if ! make > /tmp/build.log 2>&1 ;then echo "BUILD FAILED!!!" ; fi >> I could just do make "2>&1 | tee make.log" but it is still a pain to find the relevant warnings in the produced make.log file. >> >>>>> Here is an example of output produced with silent rules: >>>>> https://gist.github.com/4160201 >>>>> >>>>> I may have missed some build tools' invocations as I can only compile >>>>> Erlang on my Mac. >>>>> >>>>> https://github.com/nox/otp/compare/erlang:master...enable-silent-rules >>>>> https://github.com/nox/otp/compare/erlang:master...enable-silent-rules.patch >>>>> >>>>> git fetch https://github.com/nox/otp enable-silent-rules >>>> Nice patch, but I would prefer to make the default be silent. >>> That's actively harmful -- a build failing on you with useless output >>> is already bad enough, having to re-run the build is annoying on its >>> own, having to additionally figure out the option that will give you >>> useful output is almost insulting. >> >> I'm with you on letting it non-default; I sometimes yell at rebar for this very reason when I want to see its erlc invocations. >> >> [1] You can follow my progress on this on https://github.com/nox/otp/compare/erlang:master...eep20 >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From egil@REDACTED Fri Jan 11 18:40:28 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 11 Jan 2013 18:40:28 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> Message-ID: <50F04E8C.1080800@erlang.org> On 2013-01-11 18:12, Anthony Ramine wrote: > I could do that, it would make things easier. The patch doesn't yet handle all the things but I > submitted it anyway to have a feedback earlier and to know whether I should bother finishing it. > > I guess your answer is positive enough for me to finish it :) I'll do that this weekend. > > Regards, > I realized when hitting send that you still have change all the files by the move. My first thought was actually changing the compiler or gen environment variables to include i.e. instead of doing $(erlc_verbose)$(ERLC) and the like, doing for instance ERLC = $(erlc_verbose)erlc $(ERLC_WFLAGS) $(ERLC_FLAGS) But since all (?) ERLC rules are covered in otp.mk.in, that particular example seems redundant. =) sadly sed doesn't have and environment variables .. it would have simplified things greatly. Caution - I'm positive to the change, but since it changes all the build things this close to r16 I will be more hesitant to include it. If it will be included I will include it in R16A (release candidate), and not between A and B (production). The fewer changed files the better. If you decide to work on it more rebase it to current master. The following files needs special care: # both modified: erts/emulator/Makefile.in # both modified: lib/crypto/c_src/Makefile.in # both modified: lib/diameter/doc/src/Makefile # both modified: lib/eldap/src/Makefile # both modified: lib/megaco/src/binary/depend.mk # both modified: lib/public_key/asn1/Makefile I will continue the review once I hear from you. // Bj?rn-Egil From n.oxyde@REDACTED Fri Jan 11 19:09:17 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 11 Jan 2013 19:09:17 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F04E8C.1080800@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> Message-ID: <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> What Automake does is define variables like this: V_ERLC = $(erlc_verbose)$(ERLC) I could do that. I don't like including $(ERLC_FLAGS) in it though, it's not common practice. I don't mind not including it in R16 and I think it's probably for the best. I have other improvements in mind for the build process anyway so I'll rebase this on current master and work on it. Thanks for the feedback, that's all I wanted ;) -- Anthony Ramine Le 11 janv. 2013 ? 18:40, Bj?rn-Egil Dahlberg a ?crit : > On 2013-01-11 18:12, Anthony Ramine wrote: >> I could do that, it would make things easier. The patch doesn't yet handle all the things but I >> submitted it anyway to have a feedback earlier and to know whether I should bother finishing it. >> >> I guess your answer is positive enough for me to finish it :) I'll do that this weekend. >> >> Regards, >> > I realized when hitting send that you still have change all the files by the move. > > My first thought was actually changing the compiler or gen environment variables to include > > i.e. instead of doing $(erlc_verbose)$(ERLC) and the like, doing for instance > ERLC = $(erlc_verbose)erlc $(ERLC_WFLAGS) $(ERLC_FLAGS) > > But since all (?) ERLC rules are covered in otp.mk.in, that particular example seems redundant. =) > > sadly sed doesn't have and environment variables .. it would have simplified things greatly. > > Caution - I'm positive to the change, but since it changes all the build things this close to r16 I will be more hesitant to include it. If it will be included I will include it in R16A (release candidate), and not between A and B (production). The fewer changed files the better. > > If you decide to work on it more rebase it to current master. The following files needs special care: > > # both modified: erts/emulator/Makefile.in > # both modified: lib/crypto/c_src/Makefile.in > # both modified: lib/diameter/doc/src/Makefile > # both modified: lib/eldap/src/Makefile > # both modified: lib/megaco/src/binary/depend.mk > # both modified: lib/public_key/asn1/Makefile > > I will continue the review once I hear from you. > > // Bj?rn-Egil From egil@REDACTED Fri Jan 11 19:34:05 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 11 Jan 2013 19:34:05 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> Message-ID: <50F05B1D.3090906@erlang.org> On 2013-01-11 19:09, Anthony Ramine wrote: > What Automake does is define variables like this: > > V_ERLC = $(erlc_verbose)$(ERLC) > > I could do that. I don't like including $(ERLC_FLAGS) in it though, it's not common practice. Ah ok! Common practice is usually the best practice. I'm not sure I want to change ERLC_FLAGS though. If you decide to do that change, do it in a separate commit. > I don't mind not including it in R16 and I think it's probably for the best. I have other improvements in mind for the build process anyway so I'll rebase this on current master and work on it. Ok, if thats the case I will drop the review completely until after R16. > Thanks for the feedback, that's all I wanted ;) =) // Bj?rn-Egil From tuncer.ayaz@REDACTED Fri Jan 11 19:38:46 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Fri, 11 Jan 2013 19:38:46 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F05B1D.3090906@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> Message-ID: On Fri, Jan 11, 2013 at 7:34 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-11 19:09, Anthony Ramine wrote: >> >> What Automake does is define variables like this: >> >> V_ERLC = $(erlc_verbose)$(ERLC) >> >> I could do that. I don't like including $(ERLC_FLAGS) in it though, >> it's not common practice. > > Ah ok! Common practice is usually the best practice. > > I'm not sure I want to change ERLC_FLAGS though. If you decide to do > that change, do it in a separate commit. > >> I don't mind not including it in R16 and I think it's probably for >> the best. I have other improvements in mind for the build process >> anyway so I'll rebase this on current master and work on it. > > Ok, if thats the case I will drop the review completely until after > R16. I'd highly prefer merging support for the silent rules into R16A and iterate upon it for R16B. It's too useful to postpone. >> Thanks for the feedback, that's all I wanted ;) > > =) From fdmanana@REDACTED Fri Jan 11 19:43:20 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 11 Jan 2013 18:43:20 +0000 Subject: [erlang-patches] Updates to file:allocate/2 (currently in master-opu) In-Reply-To: <50F031A1.5090708@erlang.org> References: <50CB3CCE.2010407@erlang.org> <50CEDDEC.5070301@erlang.org> <50EED679.3060100@erlang.org> <50F031A1.5090708@erlang.org> Message-ID: On Fri, Jan 11, 2013 at 3:37 PM, Bj?rn-Egil Dahlberg wrote: > Merged patch. > Closing issue designated OTP-10680. Cool, thanks :) > > // Bj?rn-Egil > > > > On 2013-01-10 16:05, Filipe David Manana wrote: >> >> Looks good to me. >> Thanks >> >> On Thu, Jan 10, 2013 at 2:55 PM, Bj?rn-Egil Dahlberg >> wrote: >>> >>> On 2013-01-09 18:11, Bj?rn-Egil Dahlberg wrote: >>> >>> I think this patch has passed through here in various incarnations the >>> last >>> two years. I get the feeling that it got missed in some hand over between >>> people. I'm truly sorry about that. >>> >>> This will happen now, >>> * I will add the patch to integration, i.e. master-opu >>> * If it passes the final step, i will merge it to master and will be >>> part >>> of beta testing in R16A release. >>> * If R16A is fine it will of course also be included in the proper >>> R16B >>> release. >>> >>> >>> >>> >>> So .. this broke during cross-compilation test AC_TRY_RUN did not have an >>> cross-compilation option. >>> * Added the safer default option 'no' in cross-compilation >>> >>> See: https://github.com/psyeugenic/otp/commits/fdm/file-allocate >>> >>> Do you a better solution or should we stick with this? I will test this >>> option a bit more still. >>> >>> Could be reproduced with: >>> ./otp_build autoconf >>> ./otp_build configure --enable-sctp >>> --xcomp-conf=xcomp/erl-xcomp-powerpc-dso-linux-gnu.conf >>> >>> (Needs powerpc gcc toolchain for cross compilation in path) >>> >>> >>> >>> >>> // Bj?rn-Egil >>> >>> 2012/12/17 Fredrik >>>> >>>> Hello Filipe! >>>> The patch is now in the 'master-pu' branch. >>>> >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 12/14/2012 04:41 PM, Filipe David Manana wrote: >>>>> >>>>> On Fri, Dec 14, 2012 at 2:50 PM, Fredrik wrote: >>>>>> >>>>>> Hello Filipe, >>>>>> Create a new branch and mail me back the fetch command and links, and >>>>>> I >>>>>> will >>>>>> fetch and put them into master-pu. >>>>> >>>>> Fredrik, >>>>> >>>>> I squashed all the commits into a new branch: >>>>> >>>>> git fetch git://github.com/fdmanana/otp.git file_allocate_squashed >>>>> >>>>> >>>>> >>>>> https://github.com/fdmanana/otp/compare/master...file_allocate_squashed.patch >>>>> https://github.com/fdmanana/otp/compare/master...file_allocate_squashed >>>>> >>>>> Thank you >>>>> >>>>> >>>>>> BR Fredrik Gustafsson >>>>>> Erlang OTP Team >>>>>> >>>>>> On 12/14/2012 03:46 PM, Filipe David Manana wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I added 2 commits on top of the existing ones for the file:allocate/2 >>>>>>> patch, currently in master-pu branch. >>>>>>> >>>>>>> They can be found in the following branch: >>>>>>> >>>>>>> git fetch git://github.com/fdmanana/otp.git file_allocate >>>>>>> >>>>>>> >>>>>>> These commits are the most recent: >>>>>>> >>>>>>> https://github.com/fdmanana/otp/commits/file_allocate >>>>>>> >>>>>>> Can you pick them, or shall I create a new branch with all of them >>>>>>> squashed into a single commit? >>>>>>> >>>>>>> Thank you >>>>>>> >>>>>>> >>>>> >>>> _______________________________________________ >>>> 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 >>> >> >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From egil@REDACTED Fri Jan 11 21:00:28 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 11 Jan 2013 21:00:28 +0100 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: References: Message-ID: <50F06F5C.6040403@erlang.org> On 2013-01-08 11:46, Filipe David Manana wrote: > Any reason for no feedback on this submission? It's quite critical > imho, it affects all file:open/2 calls that specify the 'compressed' > option, even for files that are not compressed. For example, > file_sorter always opens file with the 'compressed' option, and > shutting down a process that uses it, leads to these crashes when > using the async thread pool. Though your patch probably solves this (crucial) issue something is off. We have mechanisms in place to guard against exactly this but apparently the guards are unsuccessful in this case, so therein lies a bug. I, or someone else from the VM team, needs to look closer at this. // Bj?rn-Egil > > Thanks. > > On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana wrote: >> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch >> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash >> >> git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." > > From fdmanana@REDACTED Fri Jan 11 21:12:12 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Fri, 11 Jan 2013 20:12:12 +0000 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: <50F06F5C.6040403@erlang.org> References: <50F06F5C.6040403@erlang.org> Message-ID: On Fri, Jan 11, 2013 at 8:00 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-08 11:46, Filipe David Manana wrote: >> >> Any reason for no feedback on this submission? It's quite critical >> imho, it affects all file:open/2 calls that specify the 'compressed' >> option, even for files that are not compressed. For example, >> file_sorter always opens file with the 'compressed' option, and >> shutting down a process that uses it, leads to these crashes when >> using the async thread pool. > > > Though your patch probably solves this (crucial) issue something is off. Have been trying it in loops lasting several hours, without no more crashes nor memory/fd leaks, for a few weeks now. > > We have mechanisms in place to guard against exactly this but apparently the > guards are unsuccessful in this case, so therein lies a bug. Which guards? In the allocator for the double gzFile close() call? For the reads for example, there doesn't seem to be any guard at all. > > I, or someone else from the VM team, needs to look closer at this. Thanks. > > // Bj?rn-Egil > > > >> >> Thanks. >> >> On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana >> wrote: >>> >>> >>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch >>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash >>> >>> git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash >>> >>> >>> >>> -- >>> Filipe David Manana, >>> >>> "Reasonable men adapt themselves to the world. >>> Unreasonable men adapt the world to themselves. >>> That's why all progress depends on unreasonable men." >> >> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From essen@REDACTED Fri Jan 11 22:59:31 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Fri, 11 Jan 2013 22:59:31 +0100 Subject: [erlang-patches] Reclaim the 'query' keyword In-Reply-To: <50EE8834.3070300@erlang.org> References: <50B660BF.6060507@ninenines.eu> <50CF68D4.90504@ninenines.eu> <50EE8834.3070300@erlang.org> Message-ID: <50F08B43.9010409@ninenines.eu> Please refetch. On 01/10/2013 10:21 AM, Fredrik wrote: > Hello, > Could you please rebase this on the current 'master' branch and fix the > problems it is facing. > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/17/2012 07:47 PM, Lo?c Hoguin wrote: >> On 11/28/2012 08:06 PM, Lo?c Hoguin wrote: >>> git fetch git://github.com/essen/otp.git forget-mnemosyne >>> >>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne >>> >>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne.patch >>> >> >> Please refetch. Amended the last commit with the proper fixes. Tests >> should pass and warning introduced has been removed. >> >> Issue came from this: >> % gg -i mnemosyne >> src/mnesia.erl:119: %% Mnemosyne exclusive >> src/mnesia.erl:2885:%% Mnemosyne exclusive >> >> Which says it's Mnemosyne exclusive but is clearly not as it's used by >> a few tests. I'll leave this for someone with better Mnesia knowledge >> to decide what to do. >> >> Thanks! >> > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From tuncer.ayaz@REDACTED Sat Jan 12 15:38:27 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 12 Jan 2013 15:38:27 +0100 Subject: [erlang-patches] make/fakefop fixes Message-ID: git fetch git://github.com/tuncer/otp.git fakefop https://github.com/tuncer/otp/compare/master...fakefop https://github.com/tuncer/otp/compare/master...fakefop.patch From tuncer.ayaz@REDACTED Sat Jan 12 15:38:35 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 12 Jan 2013 15:38:35 +0100 Subject: [erlang-patches] Update .gitignore (lib/hipe/boot_ebin) Message-ID: * ignore /lib/hipe/boot_ebin/hipe.app * ignore /lib/hipe/boot_ebin/hipe.appup git fetch git://github.com/tuncer/otp.git gitignore https://github.com/tuncer/otp/compare/master...gitignore https://github.com/tuncer/otp/compare/master...gitignore.patch From fredrik@REDACTED Mon Jan 14 09:56:30 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 09:56:30 +0100 Subject: [erlang-patches] Reclaim the 'query' keyword In-Reply-To: <50F08B43.9010409@ninenines.eu> References: <50B660BF.6060507@ninenines.eu> <50CF68D4.90504@ninenines.eu> <50EE8834.3070300@erlang.org> <50F08B43.9010409@ninenines.eu> Message-ID: <50F3C83E.80906@erlang.org> Hello, I have re-fetched and it now builds in 'master-pu', BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 10:59 PM, Lo?c Hoguin wrote: > Please refetch. > > On 01/10/2013 10:21 AM, Fredrik wrote: >> Hello, >> Could you please rebase this on the current 'master' branch and fix the >> problems it is facing. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 12/17/2012 07:47 PM, Lo?c Hoguin wrote: >>> On 11/28/2012 08:06 PM, Lo?c Hoguin wrote: >>>> git fetch git://github.com/essen/otp.git forget-mnemosyne >>>> >>>> >>>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne >>>> >>>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne.patch >>>> >>>> >>> >>> Please refetch. Amended the last commit with the proper fixes. Tests >>> should pass and warning introduced has been removed. >>> >>> Issue came from this: >>> % gg -i mnemosyne >>> src/mnesia.erl:119: %% Mnemosyne exclusive >>> src/mnesia.erl:2885:%% Mnemosyne exclusive >>> >>> Which says it's Mnemosyne exclusive but is clearly not as it's used by >>> a few tests. I'll leave this for someone with better Mnesia knowledge >>> to decide what to do. >>> >>> Thanks! >>> >> > > From fredrik@REDACTED Mon Jan 14 10:06:04 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 10:06:04 +0100 Subject: [erlang-patches] make/fakefop fixes In-Reply-To: References: Message-ID: <50F3CA7C.1080804@erlang.org> Hello Tuncer, The patch is now in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 01/12/2013 03:38 PM, Tuncer Ayaz wrote: > git fetch git://github.com/tuncer/otp.git fakefop > > https://github.com/tuncer/otp/compare/master...fakefop > https://github.com/tuncer/otp/compare/master...fakefop.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Mon Jan 14 10:10:15 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 10:10:15 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F03609.6000809@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> Message-ID: <50F3CB77.8020508@erlang.org> Hello, This testcase is failing: Suite: bif_SUITE Testcase: specs Reason: The following BIFs don't have specs: erlang:float_to_list/2 Give me notice when this is done, BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 04:55 PM, Serge Aleynikov wrote: > Sorry the test case line was the "last moment" add on. It is fixed now > in my branch below. > > On 1/11/2013 10:44 AM, Fredrik wrote: >> Hey, >> Your patch does not build: >> " >> >> emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern >> " >> >> >> Please have a look at it, and give me notice when you are done. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/11/2013 03:11 PM, Serge Aleynikov wrote: >>> Ok. Here's the patch rebased to master: >>> >>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>> >>> https://github.com/saleyn/otp/compare/master...float_to_list_2 >>> https://github.com/saleyn/otp/compare/master...float_to_list_2.patch >>> >>> Regards, >>> >>> Serge >>> >>> On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >>>> On 2013-01-11 14:24, Serge Aleynikov wrote: >>>>> While looking at this I see that the code in folder >>>>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>>>> master branch. Is this intentional? If so, should I remove the >>>>> part of >>>>> the patch designed for vxworks? >>>> Yes. Any and all vxworks support has been removed in R16 from OTP except >>>> for epmd, erl_interface and ic. >>>> >>>> // Bj?rn-Egil >>>>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>>>> Hey, >>>>>> Could you please rebase this on current 'master' branch? >>>>>> >>>>>> BR Fredrik Gustafsson >>>>>> Erlang OTP Team >>>>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>>>> I implemented Lukas's recommendations that were presenting an >>>>>>> acceptance >>>>>>> issue of the new function, so the current version of the patch does: >>>>>>> >>>>>>> 1. float_to_list/1 is backwards compatible. >>>>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>>>> (with the optional compact option). >>>>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>>>> float_to_list(X) with the ability to control the number of decimals. >>>>>>> >>>>>>> The only item from Lucas's list that I left unchanged was the >>>>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>>>> advantage of the speed improvement of the new implementation. I am >>>>>>> including a patch in this email that implements this logic, but I >>>>>>> decided to leave the integration task to the OTP team since >>>>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>>>> library and I didn't want to introduce a dependency of it on other >>>>>>> code >>>>>>> - this should be decided by maintainers. >>>>>>> >>>>>>> The test cases of float_to_list/{1,2} have been updated. >>>>>>> >>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>> >>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Serge >>>>>>> >>>>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>>>> R16B. >>>>>>>> >>>>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>>>> best >>>>>>>> way to ensure that is to send an updated patch. >>>>>>>> >>>>>>>> Lukas >>>>>>>> >>>>>>>> >>>>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>>>> I am certainly very happy to hear that you finally agreed to >>>>>>>>> include >>>>>>>>> this in the distribution. The changes proposed below seem >>>>>>>>> reasonable >>>>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>>>> implement >>>>>>>>> them? >>>>>>>>> >>>>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>>>> Hello Serge! >>>>>>>>>> >>>>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>>>> work. >>>>>>>>>> >>>>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>>>> compatibility. >>>>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>>>> implementation >>>>>>>>>> (with the optional compact option). >>>>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>>>> >>>>>>>>>> We would also like the string rendering part of >>>>>>>>>> sys_double_to_chars_fast >>>>>>>>>> to be put into >>>>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>>>> way other parts of the vm which print floats will benefit from >>>>>>>>>> your >>>>>>>>>> changes! >>>>>>>>>> >>>>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>>>> taking >>>>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>>>> ponderings just let me know. >>>>>>>>>> >>>>>>>>>> Lukas >>>>>>>>>> >>>>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>>>> float_to_list_1 as well, is possible to do this and stay >>>>>>>>>>>> backwards >>>>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>>>> e+XX at >>>>>>>>>>>> the end of the optimized case and call sys_double_to_chars >>>>>>>>>>>> for the >>>>>>>>>>>> unoptimized. >>>>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>>>> questioning >>>>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. >>>>>>>>>>> However, I >>>>>>>>>>> think >>>>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>>>> which >>>>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>>>> wrote >>>>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>>>> without a performance penalty. >>>>>>>>>>> >>>>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>>>> rounding >>>>>>>>>>> involved. >>>>>>>>>>> >>>>>>>>>>> This case is easy: >>>>>>>>>>> >>>>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>>>> "1.01234000000000001762" >>>>>>>>>>> >>>>>>>>>>> This case is a bit more complex (illustration of rounding >>>>>>>>>>> impact): >>>>>>>>>>> >>>>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>>>> >>>>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>>>> with how >>>>>>>>>>>> other such APIs work. >>>>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>>>> request that >>>>>>>>>>> the default number of decimals is chosen to be consistent with >>>>>>>>>>> what >>>>>>>>>>> printf() does, so I changed the implementation to accommodate >>>>>>>>>>> that >>>>>>>>>>> request: >>>>>>>>>>> >>>>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>>>> "1.000000" >>>>>>>>>>> >>>>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>>>> >>>>>>>>>>> 2> float_to_list(1.0). >>>>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>>>> >>>>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>>>> float_to_list/2, to >>>>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>>>> >>>>>>>>>>> Serge >>>>>>>>>>> >>>>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>>>> Henrik, >>>>>>>>>>>>> >>>>>>>>>>>>> Fetch: git fetch >>>>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>>>> >>>>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>>>> happy: >>>>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>>>> suites >>>>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>>>> tried the >>>>>>>>>>>>> following but all tests fail: >>>>>>>>>>>>> >>>>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>>>> test_server_ctrl >>>>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>>>> >>>>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>>>> sure my >>>>>>>>>>>>> patch didn't break anything. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Serge >>>>>>>>>>>>> >>>>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>>>> Hi again. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>>>> >>>>>>>>>>>>>> No type information: >>>>>>>>>>>>>> >>>>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 fredrik@REDACTED Mon Jan 14 10:25:36 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 10:25:36 +0100 Subject: [erlang-patches] Update .gitignore (lib/hipe/boot_ebin) In-Reply-To: References: Message-ID: <50F3CF10.6040009@erlang.org> Hello Tuncer, It is now in the 'master-pu' branch, BR Fredrik Gustafsson Erlang OTP Team On 01/12/2013 03:38 PM, Tuncer Ayaz wrote: > * ignore /lib/hipe/boot_ebin/hipe.app > * ignore /lib/hipe/boot_ebin/hipe.appup > > git fetch git://github.com/tuncer/otp.git gitignore > > https://github.com/tuncer/otp/compare/master...gitignore > https://github.com/tuncer/otp/compare/master...gitignore.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Mon Jan 14 11:10:20 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 11:10:20 +0100 Subject: [erlang-patches] Promote compiler option 'inline_list_funcs' In-Reply-To: References: Message-ID: <50F3D98C.4050107@erlang.org> Hello, This patch is still under review, But I noticed that you are using that you are using the '?line' macro in the testcase file which is not used anymore and therefore should not be there. Could you fix this? (Just your additions of '?line'). BR Fredrik Gustafsson Erlang OTP Team On 11/03/2012 07:35 PM, Anthony Ramine wrote: > I've fixed a small typo, the HEAD commit is now > d790aefafa81afbf14d210629d1f178e457337c5. > > Regards, > > On Sat, Nov 3, 2012 at 7:02 PM, Anthony Ramine wrote: >> The compiler option inline_list_funcs has been present in Erlang/OTP >> since at least release R9B0. It enables the inlining of the most used >> list manipulation functions of the stdlib's lists module. >> >> This couple of commits fix some wrong warnings triggered by the option >> if the result of the inlined function is not actually used and mention >> it in the documentation. >> >> https://github.com/nox/otp/compare/promote-inline_list_funcs >> https://github.com/nox/otp/compare/promote-inline_list_funcs.patch >> >> Regards, >> >> >> The following changes since commit d5733bc3e34449affde2594d85b905c8ab440d42: >> >> Merge branch 'egil/ensure-erl_crash.dump/OTP-10422' into maint >> (2012-10-24 14:20:26 +0200) >> >> are available in the git repository at: >> >> https://github.com/nox/otp promote-inline_list_funcs >> >> for you to fetch changes up to 6ac8429cbe1072af6d615f668523237a2d040ed0: >> >> Document compiler option 'inline_list_funcs' (2012-11-03 18:55:07 +0100) >> >> ---------------------------------------------------------------- >> Anthony Ramine (2): >> Silence some wrong warnings triggered by inline_list_funcs >> Document compiler option 'inline_list_funcs' >> >> lib/compiler/doc/src/compile.xml | 26 ++++++++++++++++++++++++++ >> lib/compiler/src/sys_core_fold.erl | 20 ++++++++++++++------ >> 2 files changed, 40 insertions(+), 6 deletions(-) > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Mon Jan 14 11:13:15 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 11:13:15 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50EED0CD.3080603@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> Message-ID: <50F3DA3B.7090602@erlang.org> Hello Serge, Your patch is under review but I noticed during examination that you are using the ?line macro in your testcase provided. This is not used anymore and therefore should not be included, could you fix this? BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 03:31 PM, Serge Aleynikov wrote: > Added an application:get_env/3 function variant that provides a default > value for a configuration parameter: > > application:get_env(App, Key, Default) -> Value. > > git fetch git://github.com/saleyn/otp.git get_env > > https://github.com/saleyn/otp/compare/erlang:master...get_env > https://github.com/saleyn/otp/compare/erlang:master...get_env.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From n.oxyde@REDACTED Mon Jan 14 11:46:11 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 14 Jan 2013 11:46:11 +0100 Subject: [erlang-patches] Promote compiler option 'inline_list_funcs' In-Reply-To: <50F3D98C.4050107@erlang.org> References: <50F3D98C.4050107@erlang.org> Message-ID: <63FFF77A-F200-44B1-A7AB-2C2C8F62F4F2@gmail.com> Done, please refetch. -- Anthony Ramine Le 14 janv. 2013 ? 11:10, Fredrik a ?crit : > Hello, > This patch is still under review, > But I noticed that you are using that you are using the '?line' macro in the testcase file which is not used anymore and therefore should not be there. > Could you fix this? (Just your additions of '?line'). > > BR Fredrik Gustafsson > Erlang OTP Team > On 11/03/2012 07:35 PM, Anthony Ramine wrote: >> I've fixed a small typo, the HEAD commit is now >> d790aefafa81afbf14d210629d1f178e457337c5. >> >> Regards, >> >> On Sat, Nov 3, 2012 at 7:02 PM, Anthony Ramine wrote: >>> The compiler option inline_list_funcs has been present in Erlang/OTP >>> since at least release R9B0. It enables the inlining of the most used >>> list manipulation functions of the stdlib's lists module. >>> >>> This couple of commits fix some wrong warnings triggered by the option >>> if the result of the inlined function is not actually used and mention >>> it in the documentation. >>> >>> https://github.com/nox/otp/compare/promote-inline_list_funcs >>> https://github.com/nox/otp/compare/promote-inline_list_funcs.patch >>> >>> Regards, >>> >>> >>> The following changes since commit d5733bc3e34449affde2594d85b905c8ab440d42: >>> >>> Merge branch 'egil/ensure-erl_crash.dump/OTP-10422' into maint >>> (2012-10-24 14:20:26 +0200) >>> >>> are available in the git repository at: >>> >>> https://github.com/nox/otp promote-inline_list_funcs >>> >>> for you to fetch changes up to 6ac8429cbe1072af6d615f668523237a2d040ed0: >>> >>> Document compiler option 'inline_list_funcs' (2012-11-03 18:55:07 +0100) >>> >>> ---------------------------------------------------------------- >>> Anthony Ramine (2): >>> Silence some wrong warnings triggered by inline_list_funcs >>> Document compiler option 'inline_list_funcs' >>> >>> lib/compiler/doc/src/compile.xml | 26 ++++++++++++++++++++++++++ >>> lib/compiler/src/sys_core_fold.erl | 20 ++++++++++++++------ >>> 2 files changed, 40 insertions(+), 6 deletions(-) >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From fredrik@REDACTED Mon Jan 14 13:41:37 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 13:41:37 +0100 Subject: [erlang-patches] Promote compiler option 'inline_list_funcs' In-Reply-To: <63FFF77A-F200-44B1-A7AB-2C2C8F62F4F2@gmail.com> References: <50F3D98C.4050107@erlang.org> <63FFF77A-F200-44B1-A7AB-2C2C8F62F4F2@gmail.com> Message-ID: <50F3FD01.80909@erlang.org> Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/14/2013 11:46 AM, Anthony Ramine wrote: > Done, please refetch. > From n.oxyde@REDACTED Mon Jan 14 14:28:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 14 Jan 2013 14:28:35 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F05B1D.3090906@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> Message-ID: <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> Hi, I amended my commit and made some new shorter variables V_ERLC, V_MAKE etc as I said I would do. Please refetch. Everything in "./otp_build boot -a" path should be covered, the other targets like clean, documentation building and tests and releases aren't. If your various builds succeed, this could be included into R16A. Regards, -- Anthony Ramine Le 11 janv. 2013 ? 19:34, Bj?rn-Egil Dahlberg a ?crit : > On 2013-01-11 19:09, Anthony Ramine wrote: >> What Automake does is define variables like this: >> >> V_ERLC = $(erlc_verbose)$(ERLC) >> >> I could do that. I don't like including $(ERLC_FLAGS) in it though, it's not common practice. > Ah ok! Common practice is usually the best practice. > > I'm not sure I want to change ERLC_FLAGS though. If you decide to do that change, do it in a separate commit. >> I don't mind not including it in R16 and I think it's probably for the best. I have other improvements in mind for the build process anyway so I'll rebase this on current master and work on it. > Ok, if thats the case I will drop the review completely until after R16. >> Thanks for the feedback, that's all I wanted ;) > =) > > // Bj?rn-Egil From egil@REDACTED Mon Jan 14 15:30:55 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 14 Jan 2013 15:30:55 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> Message-ID: <50F4169F.1010703@erlang.org> On 2013-01-14 14:28, Anthony Ramine wrote: > Hi, > > I amended my commit and made some new shorter variables V_ERLC, V_MAKE etc > as I said I would do. Please refetch. Goody! I'll take a look. > > Everything in "./otp_build boot -a" path should be covered, the other targets > like clean, documentation building and tests and releases aren't. > > If your various builds succeed, this could be included into R16A. > > Regards, > From egil@REDACTED Mon Jan 14 15:32:56 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 14 Jan 2013 15:32:56 +0100 Subject: [erlang-patches] autoconf: if GCC is used, treat -Wreturn-type as error In-Reply-To: <50ACD9D7.2050703@erlang.org> References: <50ACD9D7.2050703@erlang.org> Message-ID: <50F41718.5030407@erlang.org> On 2012-11-21 14:40, Henrik Nord wrote: > currently in "master-pu" Issue closed. Patch designated OTP-10683 merged to master. // Bj?rn-Egil > On 2012-10-11 19:21, Tuncer Ayaz wrote: >> https://github.com/tuncer/otp/compare/maint...werror-return-type >> https://github.com/tuncer/otp/compare/maint...werror-return-type.patch >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From serge@REDACTED Mon Jan 14 15:52:53 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 14 Jan 2013 09:52:53 -0500 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F3DA3B.7090602@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> Message-ID: <50F41BC5.8060802@aleynikov.org> Fredrik, What should be used in place of the ?line macro? All test cases in that file use the ?line macro, e.g. see application_SUITE:get_key/1. Serge On 1/14/2013 5:13 AM, Fredrik wrote: > Hello Serge, > Your patch is under review but I noticed during examination that you are > using the ?line macro in your testcase provided. This is not used > anymore and therefore should not be included, could you fix this? > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >> Added an application:get_env/3 function variant that provides a default >> value for a configuration parameter: >> >> application:get_env(App, Key, Default) -> Value. >> >> git fetch git://github.com/saleyn/otp.git get_env >> >> https://github.com/saleyn/otp/compare/erlang:master...get_env >> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From fredrik@REDACTED Mon Jan 14 15:55:38 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 14 Jan 2013 15:55:38 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F41BC5.8060802@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> <50F41BC5.8060802@aleynikov.org> Message-ID: <50F41C6A.1070401@erlang.org> Hello, The answer is nothing. Just remove the '?line' that you've added. The principle is that if we adding code we don't include the ?line and if we are changing the code we are removing ?line from the lines we are changing. Not removing anything else right now. BR Fredrik Gustafsson Erlang OTP Team On 01/14/2013 03:52 PM, Serge Aleynikov wrote: > Fredrik, > > What should be used in place of the ?line macro? All test cases in that > file use the ?line macro, e.g. see application_SUITE:get_key/1. > > Serge > > On 1/14/2013 5:13 AM, Fredrik wrote: >> Hello Serge, >> Your patch is under review but I noticed during examination that you are >> using the ?line macro in your testcase provided. This is not used >> anymore and therefore should not be included, could you fix this? >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>> Added an application:get_env/3 function variant that provides a default >>> value for a configuration parameter: >>> >>> application:get_env(App, Key, Default) -> Value. >>> >>> git fetch git://github.com/saleyn/otp.git get_env >>> >>> https://github.com/saleyn/otp/compare/erlang:master...get_env >>> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches From egil@REDACTED Mon Jan 14 16:00:09 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 14 Jan 2013 16:00:09 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F41C6A.1070401@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> <50F41BC5.8060802@aleynikov.org> <50F41C6A.1070401@erlang.org> Message-ID: <50F41D79.4070904@erlang.org> On 2013-01-14 15:55, Fredrik wrote: > Hello, > The answer is nothing. Just remove the '?line' that you've added. The > principle is that if we adding code we don't include the ?line and if > we are changing the code we are removing ?line from the lines we are > changing. Not removing anything else right now. I usually remove the rest of the "?line" macros in a separate commit when I'm changing the file anyways. However, we want to keep patches from the community as small as possible, i.e. just remove them on the lines you change. Leave the rest to us as Fredrik says. =) > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/14/2013 03:52 PM, Serge Aleynikov wrote: >> Fredrik, >> >> What should be used in place of the ?line macro? All test cases in that >> file use the ?line macro, e.g. see application_SUITE:get_key/1. >> >> Serge >> >> On 1/14/2013 5:13 AM, Fredrik wrote: >>> Hello Serge, >>> Your patch is under review but I noticed during examination that you >>> are >>> using the ?line macro in your testcase provided. This is not used >>> anymore and therefore should not be included, could you fix this? >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>> Added an application:get_env/3 function variant that provides a >>>> default >>>> value for a configuration parameter: >>>> >>>> application:get_env(App, Key, Default) -> Value. >>>> >>>> git fetch git://github.com/saleyn/otp.git get_env >>>> >>>> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 > > From egil@REDACTED Mon Jan 14 16:13:51 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 14 Jan 2013 16:13:51 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F4169F.1010703@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> Message-ID: <50F420AF.8080605@erlang.org> On 2013-01-14 15:30, Bj?rn-Egil Dahlberg wrote: > On 2013-01-14 14:28, Anthony Ramine wrote: >> Hi, >> >> I amended my commit and made some new shorter variables V_ERLC, >> V_MAKE etc >> as I said I would do. Please refetch. > Goody! I'll take a look. *boom* nox/enable-silent-rules egil@REDACTED /ldisk/egil/git/otp $ git clean -fxd nox/enable-silent-rules egil@REDACTED /ldisk/egil/git/otp $ *./otp_build setup -a* ... === Entering application jinterface ... CLASSPATH=/ldisk/egil/git/otp/lib/jinterface/java_src/ javac -d /ldisk/egil/git/otp/lib/jinterface/priv/ OtpSystem.java OtpErlang.jar : Det finns ingen s?dan fil eller katalog. (No such file or directory) gmake[4]: *** [/ldisk/egil/git/otp/lib/jinterface/priv/OtpErlang.jar] Error 1 gmake[4]: Leaving directory `/ldisk/egil/git/otp/lib/jinterface/java_src/com/ericsson/otp/erlang' gmake[3]: *** [opt] Error 2 gmake[3]: Leaving directory `/ldisk/egil/git/otp/lib/jinterface/java_src' gmake[2]: *** [opt] Error 2 gmake[2]: Leaving directory `/ldisk/egil/git/otp/lib/jinterface' gmake[1]: *** [opt] Error 2 gmake[1]: Leaving directory `/ldisk/egil/git/otp/lib' gmake: *** [tertiary_bootstrap_build] Error 2 This fails on master-opu integration and also on my machine with your branch only. Please try to replicate error and investigate. // Bj?rn-Egil >> >> Everything in "./otp_build boot -a" path should be covered, the other >> targets >> like clean, documentation building and tests and releases aren't. >> >> If your various builds succeed, this could be included into R16A. >> >> Regards, >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Mon Jan 14 17:47:51 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 14 Jan 2013 17:47:51 +0100 Subject: [erlang-patches] use a proper way to pull ssize_t definition In-Reply-To: <50F02FEE.6020905@erlang.org> References: <20121116023021.F0E5714A1B4@mail.netbsd.org> <50F02FEE.6020905@erlang.org> Message-ID: <50F436B7.9000104@erlang.org> On 2013-01-11 16:29, Fredrik wrote: > Hello, > Sorry for the late answer, your patch is now in the 'master-pu' branch. > > BR Fredrik Gustafsson > Erlang OTP Team > On 11/16/2012 03:30 AM, YAMAMOTO Takashi wrote: >> hi, >> >> this change is necessary at least on netbsd. >> i noticed this when building erlang-lz4. In review - placed in master-opu I did some tweaks, will get back to you once it passes daily builds. >> >> https://github.com/yamt/otp/compare/erlang:master...ssize_t >> https://github.com/yamt/otp/compare/erlang:master...ssize_t.patch >> >> git fetch https://github.com/yamt/otp ssize_t >> >> YAMAMOTO Takashi >> _______________________________________________ >> 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 Mon Jan 14 19:28:38 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 14 Jan 2013 13:28:38 -0500 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F41C6A.1070401@erlang.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> <50F41BC5.8060802@aleynikov.org> <50F41C6A.1070401@erlang.org> Message-ID: <50F44E56.4040203@aleynikov.org> Please refetch both branches. Removed ?line macro in new test cases and fixed the missing spec. On 1/14/2013 9:55 AM, Fredrik wrote: > Hello, > The answer is nothing. Just remove the '?line' that you've added. The > principle is that if we adding code we don't include the ?line and if we > are changing the code we are removing ?line from the lines we are > changing. Not removing anything else right now. > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/14/2013 03:52 PM, Serge Aleynikov wrote: >> Fredrik, >> >> What should be used in place of the ?line macro? All test cases in that >> file use the ?line macro, e.g. see application_SUITE:get_key/1. >> >> Serge >> >> On 1/14/2013 5:13 AM, Fredrik wrote: >>> Hello Serge, >>> Your patch is under review but I noticed during examination that you are >>> using the ?line macro in your testcase provided. This is not used >>> anymore and therefore should not be included, could you fix this? >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>> Added an application:get_env/3 function variant that provides a default >>>> value for a configuration parameter: >>>> >>>> application:get_env(App, Key, Default) -> Value. >>>> >>>> git fetch git://github.com/saleyn/otp.git get_env >>>> >>>> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches > From dgud@REDACTED Tue Jan 15 10:19:03 2013 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 15 Jan 2013 10:19:03 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F44E56.4040203@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> <50F41BC5.8060802@aleynikov.org> <50F41C6A.1070401@erlang.org> <50F44E56.4040203@aleynikov.org> Message-ID: Hi Since the return value differs in get_env/2 and get_env/3 it should be documented as separate function. /Dan On Mon, Jan 14, 2013 at 7:28 PM, Serge Aleynikov wrote: > Please refetch both branches. Removed ?line macro in new test cases and > fixed the missing spec. > > On 1/14/2013 9:55 AM, Fredrik wrote: >> Hello, >> The answer is nothing. Just remove the '?line' that you've added. The >> principle is that if we adding code we don't include the ?line and if we >> are changing the code we are removing ?line from the lines we are >> changing. Not removing anything else right now. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/14/2013 03:52 PM, Serge Aleynikov wrote: >>> Fredrik, >>> >>> What should be used in place of the ?line macro? All test cases in that >>> file use the ?line macro, e.g. see application_SUITE:get_key/1. >>> >>> Serge >>> >>> On 1/14/2013 5:13 AM, Fredrik wrote: >>>> Hello Serge, >>>> Your patch is under review but I noticed during examination that you are >>>> using the ?line macro in your testcase provided. This is not used >>>> anymore and therefore should not be included, could you fix this? >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>> Added an application:get_env/3 function variant that provides a default >>>>> value for a configuration parameter: >>>>> >>>>> application:get_env(App, Key, Default) -> Value. >>>>> >>>>> git fetch git://github.com/saleyn/otp.git get_env >>>>> >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.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 From fredrik@REDACTED Tue Jan 15 10:42:24 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 10:42:24 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> References: <50B87C69.1030406@erlang.org> <9FE06E4A-CFF9-4542-B22F-687F7D43CE7B@gmail.com> <50ED920E.5060706@erlang.org> <8D1C563A-E65D-4544-9635-78F0B7A3596D@gmail.com> Message-ID: <50F52480.9040100@erlang.org> After further research we can see that the patch is also failing these testcases in tools, cover_SUITE, modules cover_SUITE, on_load Please fix this and give me notice, BR Fredrik Gustafsson Erlang OTP Team On 01/10/2013 01:33 PM, Anthony Ramine wrote: > Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit : > >> The code handles free variables. As far as I can understand, there >> can be no free variables in this case, so you should simplify the code. > You're right and wrong :) There can be no free variables if the Core Erlang > code comes from a current Erlang module, but there can be if the Core Erlang > was handwritten or generated by my EEP37 patch, for example: > > module 'foo' ['bar'/1, > 'module_info'/0, > 'module_info'/1] > attributes [] > 'bar'/1 = > %% Line 4 > fun (_cor0) -> > letrec > 'Bar'/1 = > %% Line 5 > ( fun (_cor4) -> > let = 'Bar'/1 > in case _cor4 of > <1> when 'true' -> > 1 > when 'true' -> > let<_cor3> = > call 'erlang':'*' > (N, _cor0) > in let<_cor1> = > call 'erlang':'-' > (N, 1) > in let<_cor2> = > apply Bar > (_cor1) > in call 'erlang':'*' > (_cor3, _cor2) > end > -| [{'id',{0,0,'Bar'}}] ) > in 'Bar'/1 > 'module_info'/0 = > fun () -> > call 'erlang':'get_module_info' > ('foo') > 'module_info'/1 = > fun (_cor0) -> > call 'erlang':'get_module_info' > ('foo', _cor0) > end > > In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need > to be handled to remove the reverse eta conversion in a future-proof way. > > The differences between master and my patch when running erlc +to_kernel foo.core > are: > > --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100 > +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100 > @@ -5,18 +5,16 @@ > attributes [] > fdef 'bar'/1(_Xcor0) = > do > - bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0)>> <_ker2> > + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>> <_ker1> > then > -<<_ker2>> > +<<_ker1>> > fdef 'module_info'/0() = > enter (remote 'erlang':'get_module_info'/1)('foo') > fdef 'module_info'/1(_Xcor0) = > enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0) > -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) = > - enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0) > fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) = > do > - bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0)>> > + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>> > then > match _Xcor4 > alt > @@ -34,10 +32,8 @@ > call (Bar)(_Xcor1)>> <_Xcor2> > then > do > - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>> <_ker1> > + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>> <_ker0> > then > -<<_ker1>> > +<<_ker0>> > end>> <> > -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) = > - enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0) > end > \ No newline at end of file > > Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you > when I'm done. Thanks for the feedback. > > Regards, > From fredrik@REDACTED Tue Jan 15 10:54:10 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 10:54:10 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F44E56.4040203@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> <50F41BC5.8060802@aleynikov.org> <50F41C6A.1070401@erlang.org> <50F44E56.4040203@aleynikov.org> Message-ID: <50F52742.2040702@erlang.org> Re-fetched this patch and float_to_list_2 BR Fredrik Gustafsson Erlang OTP Team On 01/14/2013 07:28 PM, Serge Aleynikov wrote: > Please refetch both branches. Removed ?line macro in new test cases and > fixed the missing spec. > > On 1/14/2013 9:55 AM, Fredrik wrote: >> Hello, >> The answer is nothing. Just remove the '?line' that you've added. The >> principle is that if we adding code we don't include the ?line and if we >> are changing the code we are removing ?line from the lines we are >> changing. Not removing anything else right now. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/14/2013 03:52 PM, Serge Aleynikov wrote: >>> Fredrik, >>> >>> What should be used in place of the ?line macro? All test cases in that >>> file use the ?line macro, e.g. see application_SUITE:get_key/1. >>> >>> Serge >>> >>> On 1/14/2013 5:13 AM, Fredrik wrote: >>>> Hello Serge, >>>> Your patch is under review but I noticed during examination that you are >>>> using the ?line macro in your testcase provided. This is not used >>>> anymore and therefore should not be included, could you fix this? >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>> Added an application:get_env/3 function variant that provides a default >>>>> value for a configuration parameter: >>>>> >>>>> application:get_env(App, Key, Default) -> Value. >>>>> >>>>> git fetch git://github.com/saleyn/otp.git get_env >>>>> >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches From n.oxyde@REDACTED Tue Jan 15 11:28:30 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 11:28:30 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards References: Message-ID: Repost on only erlang-patches so that Fredrik's MUA see it ;) -- Anthony Ramine D?but du message r?exp?di? : > De : Anthony Ramine > Objet : R?p : Local function names in Core Erlang guards > Date : 11 janvier 2013 17:12:37 HNEC > ? : erlang-bugs Bugs , erlang patches > Cc : Bjorn Gustavsson > > Hi, > > I wrote a really small patch to forbid local fun variables in Core Erlang guards. > There is no test case as there is no test suite for core_lint. > > I know the code freeze for R16 is soon but this is really a very small thing. > > git fetch https://github.com/nox/otp.git forbid-locals-in-core-guards > > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch > > Regards, > > -- > Anthony Ramine > > Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : > >> Hi, >> >> While patching the compiler to allow substitutions of variables which values are >> local function names [1], I discovered that core_lint doesn't forbid them in guards, >> even though that makes the compiler passes further down the road generate badly-formed >> BEAM code. >> >> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >> names be allowed in guards? >> >> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >> code generation I would love to fix it and remove the code I wrote to avoid the >> substitution in guards... but I lack knowledge about the BEAM innards. >> >> Regards, >> >> [1] http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >> >> -- >> Anthony Ramine >> > From n.oxyde@REDACTED Tue Jan 15 11:33:44 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 11:33:44 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F420AF.8080605@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> Message-ID: <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> Fixed, I had messed up the JARFLAGS variables. Please refetch -- Anthony Ramine Le 14 janv. 2013 ? 16:13, Bj?rn-Egil Dahlberg a ?crit : > On 2013-01-14 15:30, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-14 14:28, Anthony Ramine wrote: >>> Hi, >>> >>> I amended my commit and made some new shorter variables V_ERLC, V_MAKE etc >>> as I said I would do. Please refetch. >> Goody! I'll take a look. > *boom* > > nox/enable-silent-rules egil@REDACTED /ldisk/egil/git/otp $ git clean -fxd > nox/enable-silent-rules egil@REDACTED /ldisk/egil/git/otp $ ./otp_build setup -a > ... > === Entering application jinterface > ... > CLASSPATH=/ldisk/egil/git/otp/lib/jinterface/java_src/ javac -d /ldisk/egil/git/otp/lib/jinterface/priv/ OtpSystem.java > OtpErlang.jar : Det finns ingen s?dan fil eller katalog. (No such file or directory) > gmake[4]: *** [/ldisk/egil/git/otp/lib/jinterface/priv/OtpErlang.jar] Error 1 > gmake[4]: Leaving directory `/ldisk/egil/git/otp/lib/jinterface/java_src/com/ericsson/otp/erlang' > gmake[3]: *** [opt] Error 2 > gmake[3]: Leaving directory `/ldisk/egil/git/otp/lib/jinterface/java_src' > gmake[2]: *** [opt] Error 2 > gmake[2]: Leaving directory `/ldisk/egil/git/otp/lib/jinterface' > gmake[1]: *** [opt] Error 2 > gmake[1]: Leaving directory `/ldisk/egil/git/otp/lib' > gmake: *** [tertiary_bootstrap_build] Error 2 > > This fails on master-opu integration and also on my machine with your branch only. > > Please try to replicate error and investigate. > > // Bj?rn-Egil >>> >>> Everything in "./otp_build boot -a" path should be covered, the other targets >>> like clean, documentation building and tests and releases aren't. >>> >>> If your various builds succeed, this could be included into R16A. >>> >>> Regards, >>> >> >> _______________________________________________ >> 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 Tue Jan 15 11:39:38 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 11:39:38 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <50F52480.9040100@erlang.org> 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> Message-ID: Hi Fredrik, I can't find any modules nor on_load cases in cover_SUITE. Regards, -- Anthony Ramine Le 15 janv. 2013 ? 10:42, Fredrik a ?crit : > After further research we can see that the patch is also failing these testcases in tools, > cover_SUITE, modules > cover_SUITE, on_load > > Please fix this and give me notice, > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 01:33 PM, Anthony Ramine wrote: >> Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit : >> >>> The code handles free variables. As far as I can understand, there >>> can be no free variables in this case, so you should simplify the code. >> You're right and wrong :) There can be no free variables if the Core Erlang >> code comes from a current Erlang module, but there can be if the Core Erlang >> was handwritten or generated by my EEP37 patch, for example: >> >> module 'foo' ['bar'/1, >> 'module_info'/0, >> 'module_info'/1] >> attributes [] >> 'bar'/1 = >> %% Line 4 >> fun (_cor0) -> >> letrec >> 'Bar'/1 = >> %% Line 5 >> ( fun (_cor4) -> >> let = 'Bar'/1 >> in case _cor4 of >> <1> when 'true' -> >> 1 >> when 'true' -> >> let<_cor3> = >> call 'erlang':'*' >> (N, _cor0) >> in let<_cor1> = >> call 'erlang':'-' >> (N, 1) >> in let<_cor2> = >> apply Bar >> (_cor1) >> in call 'erlang':'*' >> (_cor3, _cor2) >> end >> -| [{'id',{0,0,'Bar'}}] ) >> in 'Bar'/1 >> 'module_info'/0 = >> fun () -> >> call 'erlang':'get_module_info' >> ('foo') >> 'module_info'/1 = >> fun (_cor0) -> >> call 'erlang':'get_module_info' >> ('foo', _cor0) >> end >> >> In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need >> to be handled to remove the reverse eta conversion in a future-proof way. >> >> The differences between master and my patch when running erlc +to_kernel foo.core >> are: >> >> --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100 >> +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100 >> @@ -5,18 +5,16 @@ >> attributes [] >> fdef 'bar'/1(_Xcor0) = >> do >> - bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0)>> <_ker2> >> + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>> <_ker1> >> then >> -<<_ker2>> >> +<<_ker1>> >> fdef 'module_info'/0() = >> enter (remote 'erlang':'get_module_info'/1)('foo') >> fdef 'module_info'/1(_Xcor0) = >> enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0) >> -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) = >> - enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0) >> fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) = >> do >> - bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0)>> >> + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>> >> then >> match _Xcor4 >> alt >> @@ -34,10 +32,8 @@ >> call (Bar)(_Xcor1)>> <_Xcor2> >> then >> do >> - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>> <_ker1> >> + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>> <_ker0> >> then >> -<<_ker1>> >> +<<_ker0>> >> end>> <> >> -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) = >> - enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0) >> end >> \ No newline at end of file >> >> Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you >> when I'm done. Thanks for the feedback. >> >> Regards, >> > From fredrik@REDACTED Tue Jan 15 11:40:38 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 11:40:38 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: References: Message-ID: <50F53226.1040208@erlang.org> Hello Anthony ;) It is now in the 'master-pu' branch. Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 11:28 AM, Anthony Ramine wrote: > Repost on only erlang-patches so that Fredrik's MUA see it;) > > -- Anthony Ramine D?but du message r?exp?di? : >> > De : Anthony Ramine >> > Objet : R?p : Local function names in Core Erlang guards >> > Date : 11 janvier 2013 17:12:37 HNEC >> > ? : erlang-bugs Bugs, erlang patches >> > Cc : Bjorn Gustavsson >> > >> > Hi, >> > >> > I wrote a really small patch to forbid local fun variables in Core Erlang guards. >> > There is no test case as there is no test suite for core_lint. >> > >> > I know the code freeze for R16 is soon but this is really a very small thing. >> > >> > git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >> > >> > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >> > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >> > >> > Regards, >> > >> > -- >> > Anthony Ramine >> > >> > Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >> > >>> >> Hi, >>> >> >>> >> While patching the compiler to allow substitutions of variables which values are >>> >> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>> >> even though that makes the compiler passes further down the road generate badly-formed >>> >> BEAM code. >>> >> >>> >> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>> >> names be allowed in guards? >>> >> >>> >> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>> >> code generation I would love to fix it and remove the code I wrote to avoid the >>> >> substitution in guards... but I lack knowledge about the BEAM innards. >>> >> >>> >> Regards, >>> >> >>> >> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>> >> >>> >> -- >>> >> Anthony Ramine >>> >> >> > From fredrik@REDACTED Tue Jan 15 11:41:31 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 11:41:31 +0100 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> Message-ID: <50F5325B.4010005@erlang.org> My bad, cprof_SUITE for both BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 11:39 AM, Anthony Ramine wrote: > Hi Fredrik, > > I can't find any modules nor on_load cases in cover_SUITE. > > Regards, > From fredrik@REDACTED Tue Jan 15 11:50:16 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 11:50:16 +0100 Subject: [erlang-patches] Dialyzer's record field type warnings In-Reply-To: References: Message-ID: <50F53468.5050001@erlang.org> Graduated to 'master'. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 11/30/2012 10:48 AM, Stavros Aronis wrote: > Sometimes Dialyzer would report violations of the expected types in > some record fields when this was not guaranteed to be the case. This > patch fixes this problem. > > git fetch git://github.com/aronisstav/otp.git > dialyzer-record-pattern > > Regards, > > Stavros > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Jan 15 12:03:26 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 12:03:26 +0100 Subject: [erlang-patches] Reclaim the 'query' keyword In-Reply-To: <50F08B43.9010409@ninenines.eu> References: <50B660BF.6060507@ninenines.eu> <50CF68D4.90504@ninenines.eu> <50EE8834.3070300@erlang.org> <50F08B43.9010409@ninenines.eu> Message-ID: <50F5377E.9040307@erlang.org> Hello, Your patch is introducing failure in following, test suite and testcase: otp_SUITE, undefined_functions With reason: [syntax_tools]erl_prettypr:lay_2/2 calls undefined erl_syntax:query_expr_body/1 BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 10:59 PM, Lo?c Hoguin wrote: > Please refetch. > > On 01/10/2013 10:21 AM, Fredrik wrote: >> Hello, >> Could you please rebase this on the current 'master' branch and fix the >> problems it is facing. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 12/17/2012 07:47 PM, Lo?c Hoguin wrote: >>> On 11/28/2012 08:06 PM, Lo?c Hoguin wrote: >>>> git fetch git://github.com/essen/otp.git forget-mnemosyne >>>> >>>> >>>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne >>>> >>>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne.patch >>>> >>>> >>> >>> Please refetch. Amended the last commit with the proper fixes. Tests >>> should pass and warning introduced has been removed. >>> >>> Issue came from this: >>> % gg -i mnemosyne >>> src/mnesia.erl:119: %% Mnemosyne exclusive >>> src/mnesia.erl:2885:%% Mnemosyne exclusive >>> >>> Which says it's Mnemosyne exclusive but is clearly not as it's used by >>> a few tests. I'll leave this for someone with better Mnesia knowledge >>> to decide what to do. >>> >>> Thanks! >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Tue Jan 15 12:30:57 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 12:30:57 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: References: Message-ID: <50F53DF1.4090309@erlang.org> In the meantime could you please rebase it on master? BR Fredrik Gustafsson Erlang OTP Team On 11/10/2012 04:28 PM, Anthony Ramine wrote: > Hi, > > This branch adds a new option "end" to erl_scan. If set, it tracks and > returns end locations of each scanned token in their attributes as > `{'end', {EndLine, EndCol}}`. > > https://github.com/nox/otp/compare/scan-end-locations > https://github.com/nox/otp/compare/scan-end-locations.patch > > git fetch https://github.com/nox/otp scan-end-locations > > Regards, > From n.oxyde@REDACTED Tue Jan 15 13:17:35 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 13:17:35 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <50F5325B.4010005@erlang.org> 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> Message-ID: <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> Fixed by not using fun references in the two test cases. Please refetch. -- Anthony Ramine Le 15 janv. 2013 ? 11:41, Fredrik a ?crit : > My bad, cprof_SUITE for both > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/15/2013 11:39 AM, Anthony Ramine wrote: >> Hi Fredrik, >> >> I can't find any modules nor on_load cases in cover_SUITE. >> >> Regards, >> > From n.oxyde@REDACTED Tue Jan 15 14:05:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 14:05:59 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <50F53DF1.4090309@erlang.org> References: <50F53DF1.4090309@erlang.org> Message-ID: <93D7C987-9EA7-4C9D-9F59-C8AD2276EB45@gmail.com> I rebased it and made erl_scan_SUITE's otp_10302 test case handle end locations. Please refetch. -- Anthony Ramine Le 15 janv. 2013 ? 12:30, Fredrik a ?crit : > In the meantime could you please rebase it on master? > > BR Fredrik Gustafsson > Erlang OTP Team > On 11/10/2012 04:28 PM, Anthony Ramine wrote: >> Hi, >> >> This branch adds a new option "end" to erl_scan. If set, it tracks and >> returns end locations of each scanned token in their attributes as >> `{'end', {EndLine, EndCol}}`. >> >> https://github.com/nox/otp/compare/scan-end-locations >> https://github.com/nox/otp/compare/scan-end-locations.patch >> >> git fetch https://github.com/nox/otp scan-end-locations >> >> Regards, >> > From fredrik@REDACTED Tue Jan 15 14:13:19 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 14:13:19 +0100 Subject: [erlang-patches] Optimize handling of local fun variables in v3_kernel In-Reply-To: <39C10C4B-C8C6-4331-B7DD-43E8E0F23751@gmail.com> 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> Message-ID: <50F555EF.4090904@erlang.org> Re-fetched, Thanks. BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 01:17 PM, Anthony Ramine wrote: > Fixed by not using fun references in the two test cases. > > Please refetch. > From a.p.erofeev@REDACTED Tue Jan 15 17:09:51 2013 From: a.p.erofeev@REDACTED (Alex Erofeev) Date: Tue, 15 Jan 2013 19:09:51 +0300 Subject: [erlang-patches] [patch] Fix bug in stdlib/queue that can slow down out/out_r Message-ID: When applying out/out_r methods if one list of queue is empty can happen situation where big list will be copying each time, so instead on amortized linear time we'll get O(N^2). Example: https://gist.github.com/4539653 . Try running it with 100000, 1000000 and 10000000 elements and compare run times. So I changed internal functions r2f and f2r to copy each time only half of list instead of almost all of it. git fetch https://github.com/AlexErofeev/otp/tree/faster_queue https://github.com/AlexErofeev/otp/compare/faster_queue https://github.com/AlexErofeev/otp/compare/faster_queue.patch Regards, Alex Erofeev -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan@REDACTED Tue Jan 15 17:16:03 2013 From: pan@REDACTED (Patrik Nyblom) Date: Tue, 15 Jan 2013 17:16:03 +0100 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: References: <50F06F5C.6040403@erlang.org> Message-ID: <50F580C3.3030506@erlang.org> Hi Filipe! On 01/11/2013 09:12 PM, Filipe David Manana wrote: > On Fri, Jan 11, 2013 at 8:00 PM, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-08 11:46, Filipe David Manana wrote: >>> Any reason for no feedback on this submission? It's quite critical >>> imho, it affects all file:open/2 calls that specify the 'compressed' >>> option, even for files that are not compressed. For example, >>> file_sorter always opens file with the 'compressed' option, and >>> shutting down a process that uses it, leads to these crashes when >>> using the async thread pool. >> >> Though your patch probably solves this (crucial) issue something is off. > Have been trying it in loops lasting several hours, without no more > crashes nor memory/fd leaks, for a few weeks now. Yes, this certainly fixes the problem - many thanks for both the excellent test case and for pointing out the serious flaw in the code! >> We have mechanisms in place to guard against exactly this but apparently the >> guards are unsuccessful in this case, so therein lies a bug. > Which guards? In the allocator for the double gzFile close() call? > For the reads for example, there doesn't seem to be any guard at all. I mislead Egil into writing that :). What I was trying to say, was that the async file driver implementation relies on the fact that operations are carried out in order. This is maintained by simply giving all operations belonging to one single file to the same async thread, as you may have noticed in the code. However, when a port is closing, we need to guard the *write que* against deletion as it's coupled to the port, not the data sent to the async thread. If the port exits, an async operation can access the write que afterwards and - if no guard was there - *bang*. So, the port_data_lock guards against that, why write operations have to take the port data lock. As long as all operations on the file are queued to the async thread, the port data lock is all that's needed, as any close of the fd (regardless of if it's a gz-close or an ordinary close) will happen after the previously scheduled async operations on the file. Two async close operations cannot be scheduled as only one scheduler operates on a port at a time, so the simple setting of the FILE_FD_INVALID flag when scheduling a close should stop two close calls being scheduled. The only thing to be afraid of is data belonging to the port, not the file as such, why the port data lock should suffice to guard the writev que associated with the actual port. That was the supposed guards against simultaneous access to files etc happening... So what's the problem then? The problem is that the port_exit callback, which is invoked when you kill the port, does *not* schedule the close! It executes it directly in the scheduler thread. Your approach to make sure that all operations on the file are run, fixes that. However, this means a scheduler thread potentially waiting for an NFS operation or something to finish in an async thread, so that the port can be closed. This is exactly the thing we do not want to happen unless absolutely necessary. That's after all one of the purposes of async thread - do not let the scheduler thread wait for lengthy file operations. My suggestion is that in order to solve this, we should rather schedule the close onto the async thread when the port get's an exit signal. I suppose the direct call is there to make the close more synchronous, but as we have to wait for the other operations anyway, doing the close in the async thread would give roughly the same result but without making the scheduler wait on a condition variable. Even though file operations on ordinary files actually is harmless after a close (which is probably why we havent spotted this) I think we should also schedule close for *all* files in this situation, there seems to be no real benefit from treating regular files differently in this case - a future port of the VM may also be to a platform where operations on closed regular files also gives problems. Besides that, avoiding a 'close' call in the scheduler thread would be a good thing. I've tested this and your test cases pass, but I would like your thoughts on this! You're obviously using files a lot and also have a firm grasp on the implementation and has recently worked on the problem, so your input would be extremely valuable! I also supplied a test patch, that replaces your solution with the above mentioned and should fix the same problem with this other approach of mine. It's based on the current master (with your other patch for leaks included) and has your testcase included. Note that this new approach will not fix the fd leak you fixed in the other patch, that patch is still needed. Furthermore the approach of scheduling the close upon an async thread does not work in that situation as the port is really dead there, we cannot schedule async jobs. To make that close (the one you added to avoid the fd leaks) happen in another thread than the scheduler thread would be nice, but I cannot find a viable solution there, so the close (which is safe as there can be no other async jobs for that file) has to happen in the scheduler thread if we do not add a special thread to do such things - leading to (even more) code bloat in efile_drv. Please note that the test patch is only smoke tested (I've run the complete kernel suite, but more will be run this noght as I'll put it to internal testing). Think of it more as a sketch than a real patch for now :) And once again, thanks for the extreamly valuable bug report and fix! Cheers, /Patrik >> I, or someone else from the VM team, needs to look closer at this. > Thanks. > >> // Bj?rn-Egil >> >> >> >>> Thanks. >>> >>> On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana >>> wrote: >>>> >>>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch >>>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash >>>> >>>> git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash >>>> >>>> >>>> >>>> -- >>>> Filipe David Manana, >>>> >>>> "Reasonable men adapt themselves to the world. >>>> Unreasonable men adapt the world to themselves. >>>> That's why all progress depends on unreasonable men." >>> >>> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > > -------------- next part -------------- A non-text attachment was scrubbed... Name: file_drv_crash_suggestion.diff Type: text/x-patch Size: 6964 bytes Desc: not available URL: From fredrik@REDACTED Tue Jan 15 17:38:01 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 15 Jan 2013 17:38:01 +0100 Subject: [erlang-patches] [patch] Fix bug in stdlib/queue that can slow down out/out_r In-Reply-To: References: Message-ID: <50F585E9.6000202@erlang.org> Thanks, Will try to build and put it in the 'master-pu' branch if successful today. BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 05:09 PM, Alex Erofeev wrote: > When applying out/out_r methods if one list of queue is empty can > happen situation where big list will be copying each time, so instead > on amortized linear time we'll get O(N^2). Example: > https://gist.github.com/4539653 . Try running it with 100000, 1000000 > and 10000000 elements and compare run times. > So I changed internal functions r2f and f2r to copy each time only > half of list instead of almost all of it. > > git fetch https://github.com/AlexErofeev/otp/tree/faster_queue > https://github.com/AlexErofeev/otp/compare/faster_queue > https://github.com/AlexErofeev/otp/compare/faster_queue.patch > > Regards, > > Alex Erofeev > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From egil@REDACTED Tue Jan 15 19:06:57 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 15 Jan 2013 19:06:57 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> Message-ID: <50F59AC1.6050403@erlang.org> On 2013-01-15 11:33, Anthony Ramine wrote: > Fixed, I had messed up the JARFLAGS variables. Please refetch > Yep that works now. But .. Parallel make no longer works. I believe the following is a hint is the warning: make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. // Bj?rn-Egil From n.oxyde@REDACTED Tue Jan 15 19:35:29 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 19:35:29 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F59AC1.6050403@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> Message-ID: I'll look into it. Was it with silent rules enabled or not? Thanks. -- Anthony Ramine Le 15 janv. 2013 ? 19:06, Bj?rn-Egil Dahlberg a ?crit : > On 2013-01-15 11:33, Anthony Ramine wrote: >> Fixed, I had messed up the JARFLAGS variables. Please refetch > Yep that works now. But .. > > Parallel make no longer works. I believe the following is a hint is the warning: > > make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. > > // Bj?rn-Egil From wallentin.dahlberg@REDACTED Tue Jan 15 19:49:28 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Tue, 15 Jan 2013 19:49:28 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> Message-ID: <-4800465672858183043@unknownmsgid> It appeared in both cases. Easier to see with silent rules though :) // egil Sent from my iPhone 15 jan 2013 kl. 19:45 skrev Anthony Ramine : > I'll look into it. Was it with silent rules enabled or not? Thanks. > > -- > Anthony Ramine > > Le 15 janv. 2013 ? 19:06, Bj?rn-Egil Dahlberg a ?crit : > >> On 2013-01-15 11:33, Anthony Ramine wrote: >>> Fixed, I had messed up the JARFLAGS variables. Please refetch >> Yep that works now. But .. >> >> Parallel make no longer works. I believe the following is a hint is the warning: >> >> make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. >> >> // Bj?rn-Egil > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From aschultz@REDACTED Tue Jan 15 20:19:42 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Tue, 15 Jan 2013 20:19:42 +0100 (CET) Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <50ED8DBD.8080305@erlang.org> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <5072D75B.7060601@erlang.org> <50731907.3090802@erix.ericsson.se> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> Message-ID: <554152829.218007.1358277582556.JavaMail.root@tpip.net> Hi, I have address the issues: * documentation for SSL API options added * header files internalized * crypto function generalized and support for multiple SRP variants New version can be found here: https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch Even if the PSK and SRP do not make it into R16, could you consider the first two changesets from this series, please? They are mostly code consolidations, making adding new key exchange algorithms much simpler. https://github.com/RoadRunnr/otp/compare/master...cf4512a https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch Andreas ----- Original Message ----- > Hello Andreas, > Your patch has finally been into review and the response was: > " > > * The patch introduces new API options without documenting them. > * The patch introduces new include file ssl_srp.hrl that I think shall > be internal and put in src. It is undesirable to have records in the > user API as it makes the user application compile time dependent on > our code, better to use a proplist and then create the record > internally. (Yes "sslsocket" is a record due to legacy) > * The patch introduces new include file ssl_srp_primes.hrl I think it > feels better to input such values as atoms and internaly uses the > macros defined in this file, that would be more consistent with the > rest of the API. > * Functions in crypto being named TLS something seems a little > strange, is this necessary?! > > " > Please correct this and give me a notice when it is done. > > BR Fredrik Gustafsson > Erlang OTP Team > On 10/12/2012 11:38 AM, Henrik Nord wrote: > > refetching > > > > On 10/12/2012 10:27 AM, Andreas Schultz wrote: > >> Hi Henrik, > >> > >> When I rebased my changes to the current master, a change crept in that > >> shouldn't have: > >> > >> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 > >> > >> > >> I have removed it from my tree and pushed it. > >> > >> Andreas > >> > >> ----- Original Message ----- > >>> Thanks, I will refetch! > >>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: > >>>> Hi, > >>>> > >>>> I have pushed a change that should fix the compile error. The > >>>> buffer has > >>>> a fixed length now. > >>>> > >>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 > >>>> > >>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch > >>>> > >>>> > >>>> Andreas > >>>> > >>>> ----- Original Message ----- > >>>>> Does not compile on Windows. > >>>>> > >>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with > >>>>> dynamic > >>>>> size is not supported by the C standard we use. > >>>>> Use a static array instead, presuming that there is a reasonable > >>>>> upper > >>>>> limit of its size. > >>>>> > >>>>> /Sverker, Erlang/OTP > >>>>> > >>>>> > >>>>> > >>>>> Henrik Nord wrote: > >>>>>> Hi > >>>>>> > >>>>>> I have added your branch to 'master'pu' for testing. > >>>>>> Thank you for your contribution! > >>>>>> > >>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Tree is rebased onto latest master. > >>>>>>> > >>>>>>> Andreas > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> Would you be so kind as to rebase this branch upon the latest > >>>>>>>> 'master' > >>>>>>>> > >>>>>>>> Thank you for your contribution! > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC > >>>>>>>>> 5487 > >>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and > >>>>>>>>> usefulness > >>>>>>>>> of those ciphers is rather limited, the one notable exception > >>>>>>>>> being > >>>>>>>>> the eID server protocol for German national identity cards > >>>>>>>>> (nPA). > >>>>>>>>> > >>>>>>>>> The test suite can only verify some PSK suites against openssl > >>>>>>>>> as > >>>>>>>>> currently no openssl version supports them all. There is patch > >>>>>>>>> that add some to openssl, but it has not been incorporated > >>>>>>>>> into > >>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK > >>>>>>>>> suites > >>>>>>>>> and I have manually tested interoperability. > >>>>>>>>> > >>>>>>>>> Patch info: > >>>>>>>>> > >>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>> tls-psk-srp-suites > >>>>>>>>> > >>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>>>>>>>> > >>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> Andreas > >>>>>>>> -- > >>>>>>>> /Henrik Nord Erlang/OTP > >>>>>>>> > >>>>>>>> > >>> -- > >>> /Henrik Nord Erlang/OTP > >>> > >>> > > > > -- -- 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 Tue Jan 15 21:46:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 15 Jan 2013 21:46:59 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <-4800465672858183043@unknownmsgid> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> Message-ID: <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> I couldn't reproduce the bug here but apparently I've found the cause of it. I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): > Using the MAKE variable has the same effect as using a ?+? character > at the beginning of the recipe line. See Instead of Executing the > Recipes. This special feature is only enabled if the MAKE variable > appears directly in the recipe: it does not apply if the MAKE variable > is referenced through expansion of another variable. In the latter > case you must use the ?+? token to get these special effects. http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable Please refetch. Regards, -- Anthony Ramine Le 15 janv. 2013 ? 19:49, Bj?rn-Egil Dahlberg a ?crit : > It appeared in both cases. Easier to see with silent rules though :) > > // egil > Sent from my iPhone > > 15 jan 2013 kl. 19:45 skrev Anthony Ramine : > >> I'll look into it. Was it with silent rules enabled or not? Thanks. >> >> -- >> Anthony Ramine >> >> Le 15 janv. 2013 ? 19:06, Bj?rn-Egil Dahlberg a ?crit : >> >>> On 2013-01-15 11:33, Anthony Ramine wrote: >>>> Fixed, I had messed up the JARFLAGS variables. Please refetch >>> Yep that works now. But .. >>> >>> Parallel make no longer works. I believe the following is a hint is the warning: >>> >>> make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. >>> >>> // Bj?rn-Egil >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Wed Jan 16 10:01:32 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 10:01:32 +0100 Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <554152829.218007.1358277582556.JavaMail.root@tpip.net> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <5072D75B.7060601@erlang.org> <50731907.3090802@erix.ericsson.se> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> Message-ID: <50F66C6C.8000108@erlang.org> Thanks, I have re-fetched and building it now with the rest of the patches in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 08:19 PM, Andreas Schultz wrote: > Hi, > > I have address the issues: > > * documentation for SSL API options added > * header files internalized > * crypto function generalized and support for multiple SRP variants > > New version can be found here: > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > > > Even if the PSK and SRP do not make it into R16, could you consider the first two > changesets from this series, please? They are mostly code consolidations, making > adding new key exchange algorithms much simpler. > > https://github.com/RoadRunnr/otp/compare/master...cf4512a > https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch > > Andreas > > ----- Original Message ----- >> Hello Andreas, >> Your patch has finally been into review and the response was: >> " >> >> * The patch introduces new API options without documenting them. >> * The patch introduces new include file ssl_srp.hrl that I think shall >> be internal and put in src. It is undesirable to have records in the >> user API as it makes the user application compile time dependent on >> our code, better to use a proplist and then create the record >> internally. (Yes "sslsocket" is a record due to legacy) >> * The patch introduces new include file ssl_srp_primes.hrl I think it >> feels better to input such values as atoms and internaly uses the >> macros defined in this file, that would be more consistent with the >> rest of the API. >> * Functions in crypto being named TLS something seems a little >> strange, is this necessary?! >> >> " >> Please correct this and give me a notice when it is done. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 10/12/2012 11:38 AM, Henrik Nord wrote: >>> refetching >>> >>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: >>>> Hi Henrik, >>>> >>>> When I rebased my changes to the current master, a change crept in that >>>> shouldn't have: >>>> >>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 >>>> >>>> >>>> I have removed it from my tree and pushed it. >>>> >>>> Andreas >>>> >>>> ----- Original Message ----- >>>>> Thanks, I will refetch! >>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: >>>>>> Hi, >>>>>> >>>>>> I have pushed a change that should fix the compile error. The >>>>>> buffer has >>>>>> a fixed length now. >>>>>> >>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 >>>>>> >>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch >>>>>> >>>>>> >>>>>> Andreas >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Does not compile on Windows. >>>>>>> >>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with >>>>>>> dynamic >>>>>>> size is not supported by the C standard we use. >>>>>>> Use a static array instead, presuming that there is a reasonable >>>>>>> upper >>>>>>> limit of its size. >>>>>>> >>>>>>> /Sverker, Erlang/OTP >>>>>>> >>>>>>> >>>>>>> >>>>>>> Henrik Nord wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I have added your branch to 'master'pu' for testing. >>>>>>>> Thank you for your contribution! >>>>>>>> >>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Tree is rebased onto latest master. >>>>>>>>> >>>>>>>>> Andreas >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> Would you be so kind as to rebase this branch upon the latest >>>>>>>>>> 'master' >>>>>>>>>> >>>>>>>>>> Thank you for your contribution! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC >>>>>>>>>>> 5487 >>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and >>>>>>>>>>> usefulness >>>>>>>>>>> of those ciphers is rather limited, the one notable exception >>>>>>>>>>> being >>>>>>>>>>> the eID server protocol for German national identity cards >>>>>>>>>>> (nPA). >>>>>>>>>>> >>>>>>>>>>> The test suite can only verify some PSK suites against openssl >>>>>>>>>>> as >>>>>>>>>>> currently no openssl version supports them all. There is patch >>>>>>>>>>> that add some to openssl, but it has not been incorporated >>>>>>>>>>> into >>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK >>>>>>>>>>> suites >>>>>>>>>>> and I have manually tested interoperability. >>>>>>>>>>> >>>>>>>>>>> Patch info: >>>>>>>>>>> >>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git >>>>>>>>>>> tls-psk-srp-suites >>>>>>>>>>> >>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>>>>>>>>>> >>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Andreas >>>>>>>>>> -- >>>>>>>>>> /Henrik Nord Erlang/OTP >>>>>>>>>> >>>>>>>>>> >>>>> -- >>>>> /Henrik Nord Erlang/OTP >>>>> >>>>> >> From fdmanana@REDACTED Wed Jan 16 11:38:16 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Wed, 16 Jan 2013 10:38:16 +0000 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: <50F580C3.3030506@erlang.org> References: <50F06F5C.6040403@erlang.org> <50F580C3.3030506@erlang.org> Message-ID: Hello Patrik! Thank you very much for the better suggestion and all the important details of the async threads and file driver implementation. I agree with your suggestion. However the patch you've sent causes a memory leak. The new task of type FILE_CLOSE_ON_PORT_EXIT is indeed executed, closing the file descriptor. However, because it's executed after the port is closed (file_close invocation), the port's ready_async callback (file_async_ready) is not invoked, therefore the switch case for FILE_CLOSE_ON_PORT_EXIT in file_async_ready is never run (see [1], and confirmed via debugging), which causes the port data (file_descriptor struct) to never be freed. Again, thank you :) See my attached patch on this mail, works on top of the patch you sent previously. Also here: https://gist.github.com/4546241 [1] - https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_async.c#L394 On Tue, Jan 15, 2013 at 4:16 PM, Patrik Nyblom wrote: > Hi Filipe! > > > On 01/11/2013 09:12 PM, Filipe David Manana wrote: >> >> On Fri, Jan 11, 2013 at 8:00 PM, Bj?rn-Egil Dahlberg >> wrote: >>> >>> On 2013-01-08 11:46, Filipe David Manana wrote: >>>> >>>> Any reason for no feedback on this submission? It's quite critical >>>> imho, it affects all file:open/2 calls that specify the 'compressed' >>>> option, even for files that are not compressed. For example, >>>> file_sorter always opens file with the 'compressed' option, and >>>> shutting down a process that uses it, leads to these crashes when >>>> using the async thread pool. >>> >>> >>> Though your patch probably solves this (crucial) issue something is off. >> >> Have been trying it in loops lasting several hours, without no more >> crashes nor memory/fd leaks, for a few weeks now. > > Yes, this certainly fixes the problem - many thanks for both the excellent > test case and for pointing out the serious flaw in the code! > >>> We have mechanisms in place to guard against exactly this but apparently >>> the >>> guards are unsuccessful in this case, so therein lies a bug. >> >> Which guards? In the allocator for the double gzFile close() call? >> For the reads for example, there doesn't seem to be any guard at all. > > I mislead Egil into writing that :). > > What I was trying to say, was that the async file driver implementation > relies on the fact that operations are carried out in order. This is > maintained by simply giving all operations belonging to one single file to > the same async thread, as you may have noticed in the code. However, when a > port is closing, we need to guard the *write que* against deletion as it's > coupled to the port, not the data sent to the async thread. If the port > exits, an async operation can access the write que afterwards and - if no > guard was there - *bang*. So, the port_data_lock guards against that, why > write operations have to take the port data lock. > > As long as all operations on the file are queued to the async thread, the > port data lock is all that's needed, as any close of the fd (regardless of > if it's a gz-close or an ordinary close) will happen after the previously > scheduled async operations on the file. Two async close operations cannot be > scheduled as only one scheduler operates on a port at a time, so the simple > setting of the FILE_FD_INVALID flag when scheduling a close should stop two > close calls being scheduled. The only thing to be afraid of is data > belonging to the port, not the file as such, why the port data lock should > suffice to guard the writev que associated with the actual port. > > That was the supposed guards against simultaneous access to files etc > happening... > > So what's the problem then? The problem is that the port_exit callback, > which is invoked when you kill the port, does *not* schedule the close! It > executes it directly in the scheduler thread. Your approach to make sure > that all operations on the file are run, fixes that. However, this means a > scheduler thread potentially waiting for an NFS operation or something to > finish in an async thread, so that the port can be closed. This is exactly > the thing we do not want to happen unless absolutely necessary. That's after > all one of the purposes of async thread - do not let the scheduler thread > wait for lengthy file operations. > > My suggestion is that in order to solve this, we should rather schedule the > close onto the async thread when the port get's an exit signal. I suppose > the direct call is there to make the close more synchronous, but as we have > to wait for the other operations anyway, doing the close in the async thread > would give roughly the same result but without making the scheduler wait on > a condition variable. Even though file operations on ordinary files actually > is harmless after a close (which is probably why we havent spotted this) I > think we should also schedule close for *all* files in this situation, there > seems to be no real benefit from treating regular files differently in this > case - a future port of the VM may also be to a platform where operations on > closed regular files also gives problems. Besides that, avoiding a 'close' > call in the scheduler thread would be a good thing. > > I've tested this and your test cases pass, but I would like your thoughts on > this! You're obviously using files a lot and also have a firm grasp on the > implementation and has recently worked on the problem, so your input would > be extremely valuable! > > I also supplied a test patch, that replaces your solution with the above > mentioned and should fix the same problem with this other approach of mine. > It's based on the current master (with your other patch for leaks included) > and has your testcase included. Note that this new approach will not fix the > fd leak you fixed in the other patch, that patch is still needed. > Furthermore the approach of scheduling the close upon an async thread does > not work in that situation as the port is really dead there, we cannot > schedule async jobs. To make that close (the one you added to avoid the fd > leaks) happen in another thread than the scheduler thread would be nice, but > I cannot find a viable solution there, so the close (which is safe as there > can be no other async jobs for that file) has to happen in the scheduler > thread if we do not add a special thread to do such things - leading to > (even more) code bloat in efile_drv. > > > Please note that the test patch is only smoke tested (I've run the complete > kernel suite, but more will be run this noght as I'll put it to internal > testing). Think of it more as a sketch than a real patch for now :) > > And once again, thanks for the extreamly valuable bug report and fix! > > Cheers, > /Patrik > > >>> I, or someone else from the VM team, needs to look closer at this. >> >> Thanks. >> >>> // Bj?rn-Egil >>> >>> >>> >>>> Thanks. >>>> >>>> On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana >>>> >>>> wrote: >>>>> >>>>> >>>>> >>>>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch >>>>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash >>>>> >>>>> git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash >>>>> >>>>> >>>>> >>>>> -- >>>>> Filipe David Manana, >>>>> >>>>> "Reasonable men adapt themselves to the world. >>>>> Unreasonable men adapt the world to themselves. >>>>> That's why all progress depends on unreasonable men." >>>> >>>> >>>> >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> >> >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-memory-leak-in-efile_drv.patch Type: application/octet-stream Size: 3337 bytes Desc: not available URL: From fredrik@REDACTED Wed Jan 16 11:46:52 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 11:46:52 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <50F53226.1040208@erlang.org> References: <50F53226.1040208@erlang.org> Message-ID: <50F6851C.1060509@erlang.org> Hello Anthony, Your patch is failing the following testsuites and testcases: compilation_SUITE : self_compile inline_SUITE : decode1 inline_SUITE : pseudoknot Please correct and give me notice, BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 11:40 AM, Fredrik wrote: > Hello Anthony ;) > It is now in the 'master-pu' branch. > Thanks, > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/15/2013 11:28 AM, Anthony Ramine wrote: >> Repost on only erlang-patches so that Fredrik's MUA see it;) >> >> -- Anthony Ramine D?but du message r?exp?di? : >>> > De : Anthony Ramine >>> > Objet : R?p : Local function names in Core Erlang guards >>> > Date : 11 janvier 2013 17:12:37 HNEC >>> > ? : erlang-bugs Bugs, erlang >>> patches >>> > Cc : Bjorn Gustavsson >>> > > Hi, >>> > > I wrote a really small patch to forbid local fun variables in >>> Core Erlang guards. >>> > There is no test case as there is no test suite for core_lint. >>> > > I know the code freeze for R16 is soon but this is really a >>> very small thing. >>> > > git fetchhttps://github.com/nox/otp.git >>> forbid-locals-in-core-guards >>> > > >>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>> > >>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>> > > Regards, >>> > > -- > Anthony Ramine >>> > > Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>> > >>>> >> Hi, >>>> >> >> While patching the compiler to allow substitutions of >>>> variables which values are >>>> >> local function names [1], I discovered that core_lint doesn't >>>> forbid them in guards, >>>> >> even though that makes the compiler passes further down the >>>> road generate badly-formed >>>> >> BEAM code. >>>> >> >> Is that a bug in core_lint or a bug in the BEAM code >>>> generation? Should local function >>>> >> names be allowed in guards? >>>> >> >> If it is a bug in core_lint, I can make a patch for that; if >>>> it is a bug in the BEAM >>>> >> code generation I would love to fix it and remove the code I >>>> wrote to avoid the >>>> >> substitution in guards... but I lack knowledge about the BEAM >>>> innards. >>>> >> >> Regards, >>>> >> >> >>>> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>> >>>> >> >> -- >> Anthony Ramine >>>> >> >>> > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Wed Jan 16 11:48:22 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 11:48:22 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> Message-ID: <50F68576.2050806@erlang.org> Re-fetched, The patch is now in the 'master-pu' branch. BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 09:46 PM, Anthony Ramine wrote: > I couldn't reproduce the bug here but apparently I've found the cause of it. > > I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): > >> Using the MAKE variable has the same effect as using a ?+? character >> at the beginning of the recipe line. See Instead of Executing the >> Recipes. This special feature is only enabled if the MAKE variable >> appears directly in the recipe: it does not apply if the MAKE variable >> is referenced through expansion of another variable. In the latter >> case you must use the ?+? token to get these special effects. > http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable > > Please refetch. > > Regards, > From n.oxyde@REDACTED Wed Jan 16 12:02:56 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 16 Jan 2013 12:02:56 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <50F6851C.1060509@erlang.org> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> Message-ID: <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> I can't reproduce any of these failures. Could I have more informations about how they failed? My wild guess is that it is related (maybe) to the bootstrap compiler, but I'm probably wrong. Bj?rn, any idea? Regards, -- Anthony Ramine Le 16 janv. 2013 ? 11:46, Fredrik a ?crit : > Hello Anthony, > Your patch is failing the following testsuites and testcases: > compilation_SUITE : self_compile > inline_SUITE : decode1 > inline_SUITE : pseudoknot > > Please correct and give me notice, > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/15/2013 11:40 AM, Fredrik wrote: >> Hello Anthony ;) >> It is now in the 'master-pu' branch. >> Thanks, >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/15/2013 11:28 AM, Anthony Ramine wrote: >>> Repost on only erlang-patches so that Fredrik's MUA see it;) >>> >>> -- Anthony Ramine D?but du message r?exp?di? : >>>> > De : Anthony Ramine >>>> > Objet : R?p : Local function names in Core Erlang guards >>>> > Date : 11 janvier 2013 17:12:37 HNEC >>>> > ? : erlang-bugs Bugs, erlang patches >>>> > Cc : Bjorn Gustavsson >>>> > > Hi, >>>> > > I wrote a really small patch to forbid local fun variables in Core Erlang guards. >>>> > There is no test case as there is no test suite for core_lint. >>>> > > I know the code freeze for R16 is soon but this is really a very small thing. >>>> > > git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >>>> > > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>>> > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>>> > > Regards, >>>> > > -- > Anthony Ramine >>>> > > Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>>> > >>>>> >> Hi, >>>>> >> >> While patching the compiler to allow substitutions of variables which values are >>>>> >> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>>>> >> even though that makes the compiler passes further down the road generate badly-formed >>>>> >> BEAM code. >>>>> >> >> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>>>> >> names be allowed in guards? >>>>> >> >> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>>>> >> code generation I would love to fix it and remove the code I wrote to avoid the >>>>> >> substitution in guards... but I lack knowledge about the BEAM innards. >>>>> >> >> Regards, >>>>> >> >> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>>> >> >> -- >> Anthony Ramine >>>>> >> >>>> > >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From fredrik@REDACTED Wed Jan 16 12:09:35 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 12:09:35 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> Message-ID: <50F68A6F.5040609@erlang.org> I'll try update bootstrap and see if that helps ;) Thanks for the hint, BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 12:02 PM, Anthony Ramine wrote: > I can't reproduce any of these failures. > > Could I have more informations about how they failed? > > My wild guess is that it is related (maybe) to the bootstrap compiler, > but I'm probably wrong. > > Bj?rn, any idea? > > Regards, > From pan@REDACTED Wed Jan 16 12:24:42 2013 From: pan@REDACTED (Patrik Nyblom) Date: Wed, 16 Jan 2013 12:24:42 +0100 Subject: [erlang-patches] Fix efile_drv crash when using async thread pool In-Reply-To: References: <50F06F5C.6040403@erlang.org> <50F580C3.3030506@erlang.org> Message-ID: <50F68DFA.5000701@erlang.org> Hi Filipe! On 01/16/2013 11:38 AM, Filipe David Manana wrote: > Hello Patrik! > > Thank you very much for the better suggestion and all the important > details of the async threads and file driver implementation. > > I agree with your suggestion. > However the patch you've sent causes a memory leak. > > The new task of type FILE_CLOSE_ON_PORT_EXIT is indeed executed, > closing the file descriptor. > However, because it's executed after the port is closed (file_close > invocation), the port's ready_async callback (file_async_ready) is not > invoked, therefore the switch case for FILE_CLOSE_ON_PORT_EXIT in > file_async_ready is > never run (see [1], and confirmed via debugging), which causes the > port data (file_descriptor struct) to never be freed. Ah! Yes, hadn't thought of that. Thank you for pointing that out! > Again, thank you :) > > See my attached patch on this mail, works on top of the patch you sent > previously. Also here: https://gist.github.com/4546241 > > [1] - https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_async.c#L394 > Great! I'll include that in the test runs! Thank you for taking the time to look at it and test it! /Patrik > > > On Tue, Jan 15, 2013 at 4:16 PM, Patrik Nyblom wrote: >> Hi Filipe! >> >> >> On 01/11/2013 09:12 PM, Filipe David Manana wrote: >>> On Fri, Jan 11, 2013 at 8:00 PM, Bj?rn-Egil Dahlberg >>> wrote: >>>> On 2013-01-08 11:46, Filipe David Manana wrote: >>>>> Any reason for no feedback on this submission? It's quite critical >>>>> imho, it affects all file:open/2 calls that specify the 'compressed' >>>>> option, even for files that are not compressed. For example, >>>>> file_sorter always opens file with the 'compressed' option, and >>>>> shutting down a process that uses it, leads to these crashes when >>>>> using the async thread pool. >>>> >>>> Though your patch probably solves this (crucial) issue something is off. >>> Have been trying it in loops lasting several hours, without no more >>> crashes nor memory/fd leaks, for a few weeks now. >> Yes, this certainly fixes the problem - many thanks for both the excellent >> test case and for pointing out the serious flaw in the code! >> >>>> We have mechanisms in place to guard against exactly this but apparently >>>> the >>>> guards are unsuccessful in this case, so therein lies a bug. >>> Which guards? In the allocator for the double gzFile close() call? >>> For the reads for example, there doesn't seem to be any guard at all. >> I mislead Egil into writing that :). >> >> What I was trying to say, was that the async file driver implementation >> relies on the fact that operations are carried out in order. This is >> maintained by simply giving all operations belonging to one single file to >> the same async thread, as you may have noticed in the code. However, when a >> port is closing, we need to guard the *write que* against deletion as it's >> coupled to the port, not the data sent to the async thread. If the port >> exits, an async operation can access the write que afterwards and - if no >> guard was there - *bang*. So, the port_data_lock guards against that, why >> write operations have to take the port data lock. >> >> As long as all operations on the file are queued to the async thread, the >> port data lock is all that's needed, as any close of the fd (regardless of >> if it's a gz-close or an ordinary close) will happen after the previously >> scheduled async operations on the file. Two async close operations cannot be >> scheduled as only one scheduler operates on a port at a time, so the simple >> setting of the FILE_FD_INVALID flag when scheduling a close should stop two >> close calls being scheduled. The only thing to be afraid of is data >> belonging to the port, not the file as such, why the port data lock should >> suffice to guard the writev que associated with the actual port. >> >> That was the supposed guards against simultaneous access to files etc >> happening... >> >> So what's the problem then? The problem is that the port_exit callback, >> which is invoked when you kill the port, does *not* schedule the close! It >> executes it directly in the scheduler thread. Your approach to make sure >> that all operations on the file are run, fixes that. However, this means a >> scheduler thread potentially waiting for an NFS operation or something to >> finish in an async thread, so that the port can be closed. This is exactly >> the thing we do not want to happen unless absolutely necessary. That's after >> all one of the purposes of async thread - do not let the scheduler thread >> wait for lengthy file operations. >> >> My suggestion is that in order to solve this, we should rather schedule the >> close onto the async thread when the port get's an exit signal. I suppose >> the direct call is there to make the close more synchronous, but as we have >> to wait for the other operations anyway, doing the close in the async thread >> would give roughly the same result but without making the scheduler wait on >> a condition variable. Even though file operations on ordinary files actually >> is harmless after a close (which is probably why we havent spotted this) I >> think we should also schedule close for *all* files in this situation, there >> seems to be no real benefit from treating regular files differently in this >> case - a future port of the VM may also be to a platform where operations on >> closed regular files also gives problems. Besides that, avoiding a 'close' >> call in the scheduler thread would be a good thing. >> >> I've tested this and your test cases pass, but I would like your thoughts on >> this! You're obviously using files a lot and also have a firm grasp on the >> implementation and has recently worked on the problem, so your input would >> be extremely valuable! >> >> I also supplied a test patch, that replaces your solution with the above >> mentioned and should fix the same problem with this other approach of mine. >> It's based on the current master (with your other patch for leaks included) >> and has your testcase included. Note that this new approach will not fix the >> fd leak you fixed in the other patch, that patch is still needed. >> Furthermore the approach of scheduling the close upon an async thread does >> not work in that situation as the port is really dead there, we cannot >> schedule async jobs. To make that close (the one you added to avoid the fd >> leaks) happen in another thread than the scheduler thread would be nice, but >> I cannot find a viable solution there, so the close (which is safe as there >> can be no other async jobs for that file) has to happen in the scheduler >> thread if we do not add a special thread to do such things - leading to >> (even more) code bloat in efile_drv. >> >> >> Please note that the test patch is only smoke tested (I've run the complete >> kernel suite, but more will be run this noght as I'll put it to internal >> testing). Think of it more as a sketch than a real patch for now :) >> >> And once again, thanks for the extreamly valuable bug report and fix! >> >> Cheers, >> /Patrik >> >> >>>> I, or someone else from the VM team, needs to look closer at this. >>> Thanks. >>> >>>> // Bj?rn-Egil >>>> >>>> >>>> >>>>> Thanks. >>>>> >>>>> On Thu, Dec 27, 2012 at 1:07 PM, Filipe David Manana >>>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash.patch >>>>>> https://github.com/fdmanana/otp/compare/master...fix_efile_drv_crash >>>>>> >>>>>> git fetch git://github.com/fdmanana/otp.git fix_efile_drv_crash >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Filipe David Manana, >>>>>> >>>>>> "Reasonable men adapt themselves to the world. >>>>>> Unreasonable men adapt the world to themselves. >>>>>> That's why all progress depends on unreasonable men." >>>>> >>>>> >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> > > From essen@REDACTED Wed Jan 16 12:48:06 2013 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Wed, 16 Jan 2013 12:48:06 +0100 Subject: [erlang-patches] Reclaim the 'query' keyword In-Reply-To: <50F5377E.9040307@erlang.org> References: <50B660BF.6060507@ninenines.eu> <50CF68D4.90504@ninenines.eu> <50EE8834.3070300@erlang.org> <50F08B43.9010409@ninenines.eu> <50F5377E.9040307@erlang.org> Message-ID: <50F69376.4040704@ninenines.eu> Done, please refetch. Any more feedback on this? I'm guessing it won't be for R16. On 01/15/2013 12:03 PM, Fredrik wrote: > Hello, > Your patch is introducing failure in following, test suite and testcase: > otp_SUITE, undefined_functions > With reason: > > [syntax_tools]erl_prettypr:lay_2/2 calls undefined erl_syntax:query_expr_body/1 > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/11/2013 10:59 PM, Lo?c Hoguin wrote: >> Please refetch. >> >> On 01/10/2013 10:21 AM, Fredrik wrote: >>> Hello, >>> Could you please rebase this on the current 'master' branch and fix the >>> problems it is facing. >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/17/2012 07:47 PM, Lo?c Hoguin wrote: >>>> On 11/28/2012 08:06 PM, Lo?c Hoguin wrote: >>>>> git fetch git://github.com/essen/otp.git forget-mnemosyne >>>>> >>>>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne >>>>> >>>>> https://github.com/essen/otp/compare/erlang:master...forget-mnemosyne.patch >>>>> >>>>> >>>> >>>> Please refetch. Amended the last commit with the proper fixes. Tests >>>> should pass and warning introduced has been removed. >>>> >>>> Issue came from this: >>>> % gg -i mnemosyne >>>> src/mnesia.erl:119: %% Mnemosyne exclusive >>>> src/mnesia.erl:2885:%% Mnemosyne exclusive >>>> >>>> Which says it's Mnemosyne exclusive but is clearly not as it's used by >>>> a few tests. I'll leave this for someone with better Mnesia knowledge >>>> to decide what to do. >>>> >>>> Thanks! >>>> >>> >> >> > -- Lo?c Hoguin Erlang Cowboy Nine Nines http://ninenines.eu From aschultz@REDACTED Wed Jan 16 13:20:28 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 16 Jan 2013 13:20:28 +0100 (CET) Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <50F66C6C.8000108@erlang.org> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> <50F66C6C.8000108@erlang.org> Message-ID: <1636541866.231783.1358338828351.JavaMail.root@tpip.net> Hi Fredrik, I just realized that I'm still using the ?line macro in the new SRP crypto test. Should I remove it? Andreas ----- Original Message ----- > Thanks, > I have re-fetched and building it now with the rest of the patches in > the 'master-pu' branch. > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/15/2013 08:19 PM, Andreas Schultz wrote: > > Hi, > > > > I have address the issues: > > > > * documentation for SSL API options added > > * header files internalized > > * crypto function generalized and support for multiple SRP variants > > > > New version can be found here: > > > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > > > > > > Even if the PSK and SRP do not make it into R16, could you consider the > > first two > > changesets from this series, please? They are mostly code consolidations, > > making > > adding new key exchange algorithms much simpler. > > > > https://github.com/RoadRunnr/otp/compare/master...cf4512a > > https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch > > > > Andreas > > > > ----- Original Message ----- > >> Hello Andreas, > >> Your patch has finally been into review and the response was: > >> " > >> > >> * The patch introduces new API options without documenting them. > >> * The patch introduces new include file ssl_srp.hrl that I think shall > >> be internal and put in src. It is undesirable to have records in the > >> user API as it makes the user application compile time dependent on > >> our code, better to use a proplist and then create the record > >> internally. (Yes "sslsocket" is a record due to legacy) > >> * The patch introduces new include file ssl_srp_primes.hrl I think it > >> feels better to input such values as atoms and internaly uses the > >> macros defined in this file, that would be more consistent with the > >> rest of the API. > >> * Functions in crypto being named TLS something seems a little > >> strange, is this necessary?! > >> > >> " > >> Please correct this and give me a notice when it is done. > >> > >> BR Fredrik Gustafsson > >> Erlang OTP Team > >> On 10/12/2012 11:38 AM, Henrik Nord wrote: > >>> refetching > >>> > >>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: > >>>> Hi Henrik, > >>>> > >>>> When I rebased my changes to the current master, a change crept in that > >>>> shouldn't have: > >>>> > >>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 > >>>> > >>>> > >>>> I have removed it from my tree and pushed it. > >>>> > >>>> Andreas > >>>> > >>>> ----- Original Message ----- > >>>>> Thanks, I will refetch! > >>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I have pushed a change that should fix the compile error. The > >>>>>> buffer has > >>>>>> a fixed length now. > >>>>>> > >>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 > >>>>>> > >>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch > >>>>>> > >>>>>> > >>>>>> Andreas > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> Does not compile on Windows. > >>>>>>> > >>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with > >>>>>>> dynamic > >>>>>>> size is not supported by the C standard we use. > >>>>>>> Use a static array instead, presuming that there is a reasonable > >>>>>>> upper > >>>>>>> limit of its size. > >>>>>>> > >>>>>>> /Sverker, Erlang/OTP > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Henrik Nord wrote: > >>>>>>>> Hi > >>>>>>>> > >>>>>>>> I have added your branch to 'master'pu' for testing. > >>>>>>>> Thank you for your contribution! > >>>>>>>> > >>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Tree is rebased onto latest master. > >>>>>>>>> > >>>>>>>>> Andreas > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>>> Would you be so kind as to rebase this branch upon the latest > >>>>>>>>>> 'master' > >>>>>>>>>> > >>>>>>>>>> Thank you for your contribution! > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC > >>>>>>>>>>> 5487 > >>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and > >>>>>>>>>>> usefulness > >>>>>>>>>>> of those ciphers is rather limited, the one notable exception > >>>>>>>>>>> being > >>>>>>>>>>> the eID server protocol for German national identity cards > >>>>>>>>>>> (nPA). > >>>>>>>>>>> > >>>>>>>>>>> The test suite can only verify some PSK suites against openssl > >>>>>>>>>>> as > >>>>>>>>>>> currently no openssl version supports them all. There is patch > >>>>>>>>>>> that add some to openssl, but it has not been incorporated > >>>>>>>>>>> into > >>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK > >>>>>>>>>>> suites > >>>>>>>>>>> and I have manually tested interoperability. > >>>>>>>>>>> > >>>>>>>>>>> Patch info: > >>>>>>>>>>> > >>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>>>> tls-psk-srp-suites > >>>>>>>>>>> > >>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>>>>>>>>>> > >>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> Andreas > >>>>>>>>>> -- > >>>>>>>>>> /Henrik Nord Erlang/OTP > >>>>>>>>>> > >>>>>>>>>> > >>>>> -- > >>>>> /Henrik Nord Erlang/OTP > >>>>> > >>>>> > >> > > -- -- 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 fredrik@REDACTED Wed Jan 16 13:33:53 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 13:33:53 +0100 Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <1636541866.231783.1358338828351.JavaMail.root@tpip.net> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> <50F66C6C.8000108@erlang.org> <1636541866.231783.1358338828351.JavaMail.root@tpip.net> Message-ID: <50F69E31.6080300@erlang.org> Yes, please do so. Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 01:20 PM, Andreas Schultz wrote: > Hi Fredrik, > > I just realized that I'm still using the ?line macro in the new SRP crypto test. > > Should I remove it? > > Andreas > > ----- Original Message ----- >> Thanks, >> I have re-fetched and building it now with the rest of the patches in >> the 'master-pu' branch. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/15/2013 08:19 PM, Andreas Schultz wrote: >>> Hi, >>> >>> I have address the issues: >>> >>> * documentation for SSL API options added >>> * header files internalized >>> * crypto function generalized and support for multiple SRP variants >>> >>> New version can be found here: >>> >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>> >>> >>> Even if the PSK and SRP do not make it into R16, could you consider the >>> first two >>> changesets from this series, please? They are mostly code consolidations, >>> making >>> adding new key exchange algorithms much simpler. >>> >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch >>> >>> Andreas >>> >>> ----- Original Message ----- >>>> Hello Andreas, >>>> Your patch has finally been into review and the response was: >>>> " >>>> >>>> * The patch introduces new API options without documenting them. >>>> * The patch introduces new include file ssl_srp.hrl that I think shall >>>> be internal and put in src. It is undesirable to have records in the >>>> user API as it makes the user application compile time dependent on >>>> our code, better to use a proplist and then create the record >>>> internally. (Yes "sslsocket" is a record due to legacy) >>>> * The patch introduces new include file ssl_srp_primes.hrl I think it >>>> feels better to input such values as atoms and internaly uses the >>>> macros defined in this file, that would be more consistent with the >>>> rest of the API. >>>> * Functions in crypto being named TLS something seems a little >>>> strange, is this necessary?! >>>> >>>> " >>>> Please correct this and give me a notice when it is done. >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 10/12/2012 11:38 AM, Henrik Nord wrote: >>>>> refetching >>>>> >>>>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: >>>>>> Hi Henrik, >>>>>> >>>>>> When I rebased my changes to the current master, a change crept in that >>>>>> shouldn't have: >>>>>> >>>>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 >>>>>> >>>>>> >>>>>> I have removed it from my tree and pushed it. >>>>>> >>>>>> Andreas >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Thanks, I will refetch! >>>>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have pushed a change that should fix the compile error. The >>>>>>>> buffer has >>>>>>>> a fixed length now. >>>>>>>> >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 >>>>>>>> >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch >>>>>>>> >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> Does not compile on Windows. >>>>>>>>> >>>>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with >>>>>>>>> dynamic >>>>>>>>> size is not supported by the C standard we use. >>>>>>>>> Use a static array instead, presuming that there is a reasonable >>>>>>>>> upper >>>>>>>>> limit of its size. >>>>>>>>> >>>>>>>>> /Sverker, Erlang/OTP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Henrik Nord wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I have added your branch to 'master'pu' for testing. >>>>>>>>>> Thank you for your contribution! >>>>>>>>>> >>>>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Tree is rebased onto latest master. >>>>>>>>>>> >>>>>>>>>>> Andreas >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> Would you be so kind as to rebase this branch upon the latest >>>>>>>>>>>> 'master' >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your contribution! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC >>>>>>>>>>>>> 5487 >>>>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and >>>>>>>>>>>>> usefulness >>>>>>>>>>>>> of those ciphers is rather limited, the one notable exception >>>>>>>>>>>>> being >>>>>>>>>>>>> the eID server protocol for German national identity cards >>>>>>>>>>>>> (nPA). >>>>>>>>>>>>> >>>>>>>>>>>>> The test suite can only verify some PSK suites against openssl >>>>>>>>>>>>> as >>>>>>>>>>>>> currently no openssl version supports them all. There is patch >>>>>>>>>>>>> that add some to openssl, but it has not been incorporated >>>>>>>>>>>>> into >>>>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK >>>>>>>>>>>>> suites >>>>>>>>>>>>> and I have manually tested interoperability. >>>>>>>>>>>>> >>>>>>>>>>>>> Patch info: >>>>>>>>>>>>> >>>>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git >>>>>>>>>>>>> tls-psk-srp-suites >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Andreas >>>>>>>>>>>> -- >>>>>>>>>>>> /Henrik Nord Erlang/OTP >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> -- >>>>>>> /Henrik Nord Erlang/OTP >>>>>>> >>>>>>> >> From fredrik@REDACTED Wed Jan 16 13:38:05 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 13:38:05 +0100 Subject: [erlang-patches] Reclaim the 'query' keyword In-Reply-To: <50F69376.4040704@ninenines.eu> References: <50B660BF.6060507@ninenines.eu> <50CF68D4.90504@ninenines.eu> <50EE8834.3070300@erlang.org> <50F08B43.9010409@ninenines.eu> <50F5377E.9040307@erlang.org> <50F69376.4040704@ninenines.eu> Message-ID: <50F69F2D.30000@erlang.org> Thanks, Building in the 'master-pu' branch right now. BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 12:48 PM, Lo?c Hoguin wrote: > git fetch git://github.com/essen/otp.git forget-mnemosyne From aschultz@REDACTED Wed Jan 16 13:45:08 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 16 Jan 2013 13:45:08 +0100 (CET) Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <50F69E31.6080300@erlang.org> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> <50F66C6C.8000108@erlang.org> <1636541866.231783.1358338828351.JavaMail.root@tpip.net> <50F69E31.6080300@erlang.org> Message-ID: <1701320214.233111.1358340308633.JavaMail.root@tpip.net> done! https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch Andreas ----- Original Message ----- > Yes, please do so. > Thanks, > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/16/2013 01:20 PM, Andreas Schultz wrote: > > Hi Fredrik, > > > > I just realized that I'm still using the ?line macro in the new SRP crypto > > test. > > > > Should I remove it? > > > > Andreas > > > > ----- Original Message ----- > >> Thanks, > >> I have re-fetched and building it now with the rest of the patches in > >> the 'master-pu' branch. > >> > >> BR Fredrik Gustafsson > >> Erlang OTP Team > >> On 01/15/2013 08:19 PM, Andreas Schultz wrote: > >>> Hi, > >>> > >>> I have address the issues: > >>> > >>> * documentation for SSL API options added > >>> * header files internalized > >>> * crypto function generalized and support for multiple SRP variants > >>> > >>> New version can be found here: > >>> > >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>> > >>> > >>> Even if the PSK and SRP do not make it into R16, could you consider the > >>> first two > >>> changesets from this series, please? They are mostly code consolidations, > >>> making > >>> adding new key exchange algorithms much simpler. > >>> > >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a > >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch > >>> > >>> Andreas > >>> > >>> ----- Original Message ----- > >>>> Hello Andreas, > >>>> Your patch has finally been into review and the response was: > >>>> " > >>>> > >>>> * The patch introduces new API options without documenting them. > >>>> * The patch introduces new include file ssl_srp.hrl that I think > >>>> shall > >>>> be internal and put in src. It is undesirable to have records in > >>>> the > >>>> user API as it makes the user application compile time dependent > >>>> on > >>>> our code, better to use a proplist and then create the record > >>>> internally. (Yes "sslsocket" is a record due to legacy) > >>>> * The patch introduces new include file ssl_srp_primes.hrl I think > >>>> it > >>>> feels better to input such values as atoms and internaly uses the > >>>> macros defined in this file, that would be more consistent with > >>>> the > >>>> rest of the API. > >>>> * Functions in crypto being named TLS something seems a little > >>>> strange, is this necessary?! > >>>> > >>>> " > >>>> Please correct this and give me a notice when it is done. > >>>> > >>>> BR Fredrik Gustafsson > >>>> Erlang OTP Team > >>>> On 10/12/2012 11:38 AM, Henrik Nord wrote: > >>>>> refetching > >>>>> > >>>>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: > >>>>>> Hi Henrik, > >>>>>> > >>>>>> When I rebased my changes to the current master, a change crept in > >>>>>> that > >>>>>> shouldn't have: > >>>>>> > >>>>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 > >>>>>> > >>>>>> > >>>>>> I have removed it from my tree and pushed it. > >>>>>> > >>>>>> Andreas > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> Thanks, I will refetch! > >>>>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I have pushed a change that should fix the compile error. The > >>>>>>>> buffer has > >>>>>>>> a fixed length now. > >>>>>>>> > >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 > >>>>>>>> > >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch > >>>>>>>> > >>>>>>>> > >>>>>>>> Andreas > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> Does not compile on Windows. > >>>>>>>>> > >>>>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with > >>>>>>>>> dynamic > >>>>>>>>> size is not supported by the C standard we use. > >>>>>>>>> Use a static array instead, presuming that there is a reasonable > >>>>>>>>> upper > >>>>>>>>> limit of its size. > >>>>>>>>> > >>>>>>>>> /Sverker, Erlang/OTP > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Henrik Nord wrote: > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> I have added your branch to 'master'pu' for testing. > >>>>>>>>>> Thank you for your contribution! > >>>>>>>>>> > >>>>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Tree is rebased onto latest master. > >>>>>>>>>>> > >>>>>>>>>>> Andreas > >>>>>>>>>>> > >>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>> Would you be so kind as to rebase this branch upon the latest > >>>>>>>>>>>> 'master' > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you for your contribution! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC > >>>>>>>>>>>>> 5487 > >>>>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and > >>>>>>>>>>>>> usefulness > >>>>>>>>>>>>> of those ciphers is rather limited, the one notable exception > >>>>>>>>>>>>> being > >>>>>>>>>>>>> the eID server protocol for German national identity cards > >>>>>>>>>>>>> (nPA). > >>>>>>>>>>>>> > >>>>>>>>>>>>> The test suite can only verify some PSK suites against openssl > >>>>>>>>>>>>> as > >>>>>>>>>>>>> currently no openssl version supports them all. There is patch > >>>>>>>>>>>>> that add some to openssl, but it has not been incorporated > >>>>>>>>>>>>> into > >>>>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK > >>>>>>>>>>>>> suites > >>>>>>>>>>>>> and I have manually tested interoperability. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patch info: > >>>>>>>>>>>>> > >>>>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>>>>>> tls-psk-srp-suites > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> Andreas > >>>>>>>>>>>> -- > >>>>>>>>>>>> /Henrik Nord Erlang/OTP > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> -- > >>>>>>> /Henrik Nord Erlang/OTP > >>>>>>> > >>>>>>> > >> > > -- -- 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 fredrik@REDACTED Wed Jan 16 14:24:24 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 14:24:24 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> Message-ID: <50F6AA08.70405@erlang.org> It was not the bootstrap, I think you have to take a look at those testcases, Here's the reason's: compilation_SUITE:self_compile_1 failed on line 428 Reason: suite_failed inline_SUITE:try_inline failed on line 117 Reason: {badmatch,error} inline_SUITE:try_inline failed on line 117 Reason: {badmatch,error} BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 12:02 PM, Anthony Ramine wrote: > I can't reproduce any of these failures. > > Could I have more informations about how they failed? > > My wild guess is that it is related (maybe) to the bootstrap compiler, > but I'm probably wrong. > > Bj?rn, any idea? > > Regards, > > -- Anthony Ramine Le 16 janv. 2013 ? 11:46, Fredrik a ?crit : >> > Hello Anthony, >> > Your patch is failing the following testsuites and testcases: >> > compilation_SUITE : self_compile >> > inline_SUITE : decode1 >> > inline_SUITE : pseudoknot >> > >> > Please correct and give me notice, >> > >> > BR Fredrik Gustafsson >> > Erlang OTP Team >> > On 01/15/2013 11:40 AM, Fredrik wrote: >>> >> Hello Anthony;) >>> >> It is now in the 'master-pu' branch. >>> >> Thanks, >>> >> >>> >> BR Fredrik Gustafsson >>> >> Erlang OTP Team >>> >> On 01/15/2013 11:28 AM, Anthony Ramine wrote: >>>> >>> Repost on only erlang-patches so that Fredrik's MUA see it;) >>>> >>> >>>> >>> -- Anthony Ramine D?but du message r?exp?di? : >>>>>> >>>> > De : Anthony Ramine >>>>>> >>>> > Objet : R?p : Local function names in Core Erlang guards >>>>>> >>>> > Date : 11 janvier 2013 17:12:37 HNEC >>>>>> >>>> > ? : erlang-bugs Bugs, erlang patches >>>>>> >>>> > Cc : Bjorn Gustavsson >>>>>>> >>>> > > Hi, >>>>>>> >>>> > > I wrote a really small patch to forbid local fun variables in Core Erlang guards. >>>>>> >>>> > There is no test case as there is no test suite for core_lint. >>>>>>> >>>> > > I know the code freeze for R16 is soon but this is really a very small thing. >>>>>>> >>>> > > git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >>>>>>> >>>> > > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>>>>> >>>> > https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>>>>>> >>>> > > Regards, >>>>>>> >>>> > > -- > Anthony Ramine >>>>>>> >>>> > > Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>>>>> >>>> > >>>>>>>> >>>>> >> Hi, >>>>>>>>>> >>>>> >> >> While patching the compiler to allow substitutions of variables which values are >>>>>>>> >>>>> >> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>>>>>>> >>>>> >> even though that makes the compiler passes further down the road generate badly-formed >>>>>>>> >>>>> >> BEAM code. >>>>>>>>>> >>>>> >> >> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>>>>>>> >>>>> >> names be allowed in guards? >>>>>>>>>> >>>>> >> >> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>>>>>>> >>>>> >> code generation I would love to fix it and remove the code I wrote to avoid the >>>>>>>> >>>>> >> substitution in guards... but I lack knowledge about the BEAM innards. >>>>>>>>>> >>>>> >> >> Regards, >>>>>>>>>> >>>>> >> >> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>>>>>>>> >>>>> >> >> -- >> Anthony Ramine >>>>>>>> >>>>> >> >>>>>> >>>> > >>> >> >>> >> _______________________________________________ >>> >> erlang-patches mailing list >>> >> erlang-patches@REDACTED >>> >> http://erlang.org/mailman/listinfo/erlang-patches >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Wed Jan 16 14:28:53 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 14:28:53 +0100 Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <1701320214.233111.1358340308633.JavaMail.root@tpip.net> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> <50F66C6C.8000108@erlang.org> <1636541866.231783.1358338828351.JavaMail.root@tpip.net> <50F69E31.6080300@erlang.org> <1701320214.233111.1358340308633.JavaMail.root@tpip.net> Message-ID: <50F6AB15.3040401@erlang.org> Thanks, Building in 'master-pu'. BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 01:45 PM, Andreas Schultz wrote: > done! > > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > > Andreas > > ----- Original Message ----- >> Yes, please do so. >> Thanks, >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/16/2013 01:20 PM, Andreas Schultz wrote: >>> Hi Fredrik, >>> >>> I just realized that I'm still using the ?line macro in the new SRP crypto >>> test. >>> >>> Should I remove it? >>> >>> Andreas >>> >>> ----- Original Message ----- >>>> Thanks, >>>> I have re-fetched and building it now with the rest of the patches in >>>> the 'master-pu' branch. >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/15/2013 08:19 PM, Andreas Schultz wrote: >>>>> Hi, >>>>> >>>>> I have address the issues: >>>>> >>>>> * documentation for SSL API options added >>>>> * header files internalized >>>>> * crypto function generalized and support for multiple SRP variants >>>>> >>>>> New version can be found here: >>>>> >>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>>>> >>>>> >>>>> Even if the PSK and SRP do not make it into R16, could you consider the >>>>> first two >>>>> changesets from this series, please? They are mostly code consolidations, >>>>> making >>>>> adding new key exchange algorithms much simpler. >>>>> >>>>> https://github.com/RoadRunnr/otp/compare/master...cf4512a >>>>> https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch >>>>> >>>>> Andreas >>>>> >>>>> ----- Original Message ----- >>>>>> Hello Andreas, >>>>>> Your patch has finally been into review and the response was: >>>>>> " >>>>>> >>>>>> * The patch introduces new API options without documenting them. >>>>>> * The patch introduces new include file ssl_srp.hrl that I think >>>>>> shall >>>>>> be internal and put in src. It is undesirable to have records in >>>>>> the >>>>>> user API as it makes the user application compile time dependent >>>>>> on >>>>>> our code, better to use a proplist and then create the record >>>>>> internally. (Yes "sslsocket" is a record due to legacy) >>>>>> * The patch introduces new include file ssl_srp_primes.hrl I think >>>>>> it >>>>>> feels better to input such values as atoms and internaly uses the >>>>>> macros defined in this file, that would be more consistent with >>>>>> the >>>>>> rest of the API. >>>>>> * Functions in crypto being named TLS something seems a little >>>>>> strange, is this necessary?! >>>>>> >>>>>> " >>>>>> Please correct this and give me a notice when it is done. >>>>>> >>>>>> BR Fredrik Gustafsson >>>>>> Erlang OTP Team >>>>>> On 10/12/2012 11:38 AM, Henrik Nord wrote: >>>>>>> refetching >>>>>>> >>>>>>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: >>>>>>>> Hi Henrik, >>>>>>>> >>>>>>>> When I rebased my changes to the current master, a change crept in >>>>>>>> that >>>>>>>> shouldn't have: >>>>>>>> >>>>>>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 >>>>>>>> >>>>>>>> >>>>>>>> I have removed it from my tree and pushed it. >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> Thanks, I will refetch! >>>>>>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have pushed a change that should fix the compile error. The >>>>>>>>>> buffer has >>>>>>>>>> a fixed length now. >>>>>>>>>> >>>>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 >>>>>>>>>> >>>>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Andreas >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> Does not compile on Windows. >>>>>>>>>>> >>>>>>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with >>>>>>>>>>> dynamic >>>>>>>>>>> size is not supported by the C standard we use. >>>>>>>>>>> Use a static array instead, presuming that there is a reasonable >>>>>>>>>>> upper >>>>>>>>>>> limit of its size. >>>>>>>>>>> >>>>>>>>>>> /Sverker, Erlang/OTP >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Henrik Nord wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> I have added your branch to 'master'pu' for testing. >>>>>>>>>>>> Thank you for your contribution! >>>>>>>>>>>> >>>>>>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Tree is rebased onto latest master. >>>>>>>>>>>>> >>>>>>>>>>>>> Andreas >>>>>>>>>>>>> >>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>> Would you be so kind as to rebase this branch upon the latest >>>>>>>>>>>>>> 'master' >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you for your contribution! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC >>>>>>>>>>>>>>> 5487 >>>>>>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and >>>>>>>>>>>>>>> usefulness >>>>>>>>>>>>>>> of those ciphers is rather limited, the one notable exception >>>>>>>>>>>>>>> being >>>>>>>>>>>>>>> the eID server protocol for German national identity cards >>>>>>>>>>>>>>> (nPA). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The test suite can only verify some PSK suites against openssl >>>>>>>>>>>>>>> as >>>>>>>>>>>>>>> currently no openssl version supports them all. There is patch >>>>>>>>>>>>>>> that add some to openssl, but it has not been incorporated >>>>>>>>>>>>>>> into >>>>>>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK >>>>>>>>>>>>>>> suites >>>>>>>>>>>>>>> and I have manually tested interoperability. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Patch info: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git >>>>>>>>>>>>>>> tls-psk-srp-suites >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Andreas >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> /Henrik Nord Erlang/OTP >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> /Henrik Nord Erlang/OTP >>>>>>>>> >>>>>>>>> >> From n.oxyde@REDACTED Wed Jan 16 14:29:41 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 16 Jan 2013 14:29:41 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <50F6AA08.70405@erlang.org> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> <50F6AA08.70405@erlang.org> Message-ID: <77D40EC8-92A6-4160-A807-1EFF564A177C@gmail.com> Thanks for the details. I'll rebase against current master and try again, line 428 of compilation_SUITE can't fail that way in my current branch. -- Anthony Ramine Le 16 janv. 2013 ? 14:24, Fredrik a ?crit : > It was not the bootstrap, I think you have to take a look at those testcases, > Here's the reason's: > compilation_SUITE:self_compile_1 > failed on line 428 > Reason: suite_failed > > > > > > > > inline_SUITE:try_inline failed on line 117 > Reason: {badmatch,error} > > > > > > > > inline_SUITE:try_inline > failed on line 117 > Reason: {badmatch,error} > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/16/2013 12:02 PM, Anthony Ramine wrote: >> I can't reproduce any of these failures. >> >> Could I have more informations about how they failed? >> >> My wild guess is that it is related (maybe) to the bootstrap compiler, >> but I'm probably wrong. >> >> Bj?rn, any idea? >> >> Regards, >> >> >> -- >> Anthony Ramine >> >> Le 16 janv. 2013 ? 11:46, Fredrik a ?crit : >> >> >>>> >>> Hello Anthony, >>> >>>> >>> Your patch is failing the following testsuites and testcases: >>> >>>> >>> compilation_SUITE : self_compile >>> >>>> >>> inline_SUITE : decode1 >>> >>>> >>> inline_SUITE : pseudoknot >>> >>>> >>>> >>> Please correct and give me notice, >>> >>>> >>>> >>> BR Fredrik Gustafsson >>> >>>> >>> Erlang OTP Team >>> >>>> >>> On 01/15/2013 11:40 AM, Fredrik wrote: >>> >>>>>> Hello Anthony ;) >>>>>> >>>> It is now in the 'master-pu' branch. >>>> >>>>>> >>>> Thanks, >>>> >>>>>> >>>>>> >>>> BR Fredrik Gustafsson >>>> >>>>>> >>>> Erlang OTP Team >>>> >>>>>> >>>> On 01/15/2013 11:28 AM, Anthony Ramine wrote: >>>> >>>>>>>> >>>>> Repost on only erlang-patches so that Fredrik's MUA see it;) >>>>> >>>>>>>> >>>>>>>> >>>>> -- Anthony Ramine D?but du message r?exp?di? : >>>>> >>>>>>>>>>>> De : Anthony Ramine >>>>>>>>>>>> >>>>>>> Objet : R?p : Local function names in Core Erlang guards >>>>>>> >>>>>>>>>>>> >>>>>>> Date : 11 janvier 2013 17:12:37 HNEC >>>>>>> >>>>>>>>>>>> ? : erlang-bugs Bugs, erlang patches >>>>>>>>>>>> Cc : Bjorn Gustavsson >>>>>>>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> I wrote a really small patch to forbid local fun variables in Core Erlang guards. >>>>>>>> >>>>>>>>>>>> >>>>>>> There is no test case as there is no test suite for core_lint. >>>>>>> >>>>>>>>>>>>>> >>>>>>>> I know the code freeze for R16 is soon but this is really a very small thing. >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >>>>>>>> >>>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>>>>>>>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> -- > Anthony Ramine >>>>>>>> >>>>>>>>>>>>>> >>>>>>>> Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> While patching the compiler to allow substitutions of variables which values are >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> even though that makes the compiler passes further down the road generate badly-formed >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> BEAM code. >>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> names be allowed in guards? >>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> code generation I would love to fix it and remove the code I wrote to avoid the >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>> substitution in guards... but I lack knowledge about the BEAM innards. >>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> -- >> Anthony Ramine >>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> >>>> erlang-patches mailing list >>>> >>>>>> erlang-patches@REDACTED >>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> > From n.oxyde@REDACTED Wed Jan 16 14:47:10 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 16 Jan 2013 14:47:10 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <77D40EC8-92A6-4160-A807-1EFF564A177C@gmail.com> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> <50F6AA08.70405@erlang.org> <77D40EC8-92A6-4160-A807-1EFF564A177C@gmail.com> Message-ID: <86BA3528-B1ED-4C25-B34D-19E59BA1001C@gmail.com> Oops. I was simply trying to replicate this in my rm-reverse-eta-conversion branch. Will investigate on the proper branch now. Regards, -- Anthony Ramine Le 16 janv. 2013 ? 14:29, Anthony Ramine a ?crit : > Thanks for the details. > > I'll rebase against current master and try again, line 428 of compilation_SUITE > can't fail that way in my current branch. > > -- > Anthony Ramine > > Le 16 janv. 2013 ? 14:24, Fredrik a ?crit : > >> It was not the bootstrap, I think you have to take a look at those testcases, >> Here's the reason's: >> compilation_SUITE:self_compile_1 >> failed on line 428 >> Reason: suite_failed >> >> >> >> >> >> >> >> inline_SUITE:try_inline failed on line 117 >> Reason: {badmatch,error} >> >> >> >> >> >> >> >> inline_SUITE:try_inline >> failed on line 117 >> Reason: {badmatch,error} >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/16/2013 12:02 PM, Anthony Ramine wrote: >>> I can't reproduce any of these failures. >>> >>> Could I have more informations about how they failed? >>> >>> My wild guess is that it is related (maybe) to the bootstrap compiler, >>> but I'm probably wrong. >>> >>> Bj?rn, any idea? >>> >>> Regards, >>> >>> >>> -- >>> Anthony Ramine >>> >>> Le 16 janv. 2013 ? 11:46, Fredrik a ?crit : >>> >>> >>>>> >>>> Hello Anthony, >>>> >>>>> >>>> Your patch is failing the following testsuites and testcases: >>>> >>>>> >>>> compilation_SUITE : self_compile >>>> >>>>> >>>> inline_SUITE : decode1 >>>> >>>>> >>>> inline_SUITE : pseudoknot >>>> >>>>> >>>>> >>>> Please correct and give me notice, >>>> >>>>> >>>>> >>>> BR Fredrik Gustafsson >>>> >>>>> >>>> Erlang OTP Team >>>> >>>>> >>>> On 01/15/2013 11:40 AM, Fredrik wrote: >>>> >>>>>>> Hello Anthony ;) >>>>>>> >>>>> It is now in the 'master-pu' branch. >>>>> >>>>>>> >>>>> Thanks, >>>>> >>>>>>> >>>>>>> >>>>> BR Fredrik Gustafsson >>>>> >>>>>>> >>>>> Erlang OTP Team >>>>> >>>>>>> >>>>> On 01/15/2013 11:28 AM, Anthony Ramine wrote: >>>>> >>>>>>>>> >>>>>> Repost on only erlang-patches so that Fredrik's MUA see it;) >>>>>> >>>>>>>>> >>>>>>>>> >>>>>> -- Anthony Ramine D?but du message r?exp?di? : >>>>>> >>>>>>>>>>>>> De : Anthony Ramine >>>>>>>>>>>>> >>>>>>>> Objet : R?p : Local function names in Core Erlang guards >>>>>>>> >>>>>>>>>>>>> >>>>>>>> Date : 11 janvier 2013 17:12:37 HNEC >>>>>>>> >>>>>>>>>>>>> ? : erlang-bugs Bugs, erlang patches >>>>>>>>>>>>> Cc : Bjorn Gustavsson >>>>>>>>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> I wrote a really small patch to forbid local fun variables in Core Erlang guards. >>>>>>>>> >>>>>>>>>>>>> >>>>>>>> There is no test case as there is no test suite for core_lint. >>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> I know the code freeze for R16 is soon but this is really a very small thing. >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >>>>>>>>> >>>>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>>>>>>>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> -- > Anthony Ramine >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>> Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> While patching the compiler to allow substitutions of variables which values are >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> even though that makes the compiler passes further down the road generate badly-formed >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> BEAM code. >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> names be allowed in guards? >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> code generation I would love to fix it and remove the code I wrote to avoid the >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>> substitution in guards... but I lack knowledge about the BEAM innards. >>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> -- >> Anthony Ramine >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> >>>>>>> >>>>> erlang-patches mailing list >>>>> >>>>>>> erlang-patches@REDACTED >>>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>> >> > From egil@REDACTED Wed Jan 16 14:59:56 2013 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 16 Jan 2013 14:59:56 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> Message-ID: <50F6B25C.6090006@erlang.org> On 2013-01-15 21:46, Anthony Ramine wrote: > I couldn't reproduce the bug here but apparently I've found the cause of it. Looking good. Putting it into master-opu integration branch. Will be merged later this week if no other issues appear. // Bj?rn-Egil > > I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): > >> Using the MAKE variable has the same effect as using a ?+? character >> at the beginning of the recipe line. See Instead of Executing the >> Recipes. This special feature is only enabled if the MAKE variable >> appears directly in the recipe: it does not apply if the MAKE variable >> is referenced through expansion of another variable. In the latter >> case you must use the ?+? token to get these special effects. > http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable > > Please refetch. > > Regards, > From n.oxyde@REDACTED Wed Jan 16 15:09:39 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 16 Jan 2013 15:09:39 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <86BA3528-B1ED-4C25-B34D-19E59BA1001C@gmail.com> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> <50F6AA08.70405@erlang.org> <77D40EC8-92A6-4160-A807-1EFF564A177C@gmail.com> <86BA3528-B1ED-4C25-B34D-19E59BA1001C@gmail.com> Message-ID: <7B473E62-4CC8-4C5B-83B3-1E0B5D5A0D4C@gmail.com> The inliner seems to use integer for new variables. I amended my patch and its message accordingly, please refetch. -- Anthony Ramine Le 16 janv. 2013 ? 14:47, Anthony Ramine a ?crit : > Oops. > > I was simply trying to replicate this in my rm-reverse-eta-conversion branch. > > Will investigate on the proper branch now. > > Regards, > > -- > Anthony Ramine > > Le 16 janv. 2013 ? 14:29, Anthony Ramine a ?crit : > >> Thanks for the details. >> >> I'll rebase against current master and try again, line 428 of compilation_SUITE >> can't fail that way in my current branch. >> >> -- >> Anthony Ramine >> >> Le 16 janv. 2013 ? 14:24, Fredrik a ?crit : >> >>> It was not the bootstrap, I think you have to take a look at those testcases, >>> Here's the reason's: >>> compilation_SUITE:self_compile_1 >>> failed on line 428 >>> Reason: suite_failed >>> >>> >>> >>> >>> >>> >>> >>> inline_SUITE:try_inline failed on line 117 >>> Reason: {badmatch,error} >>> >>> >>> >>> >>> >>> >>> >>> inline_SUITE:try_inline >>> failed on line 117 >>> Reason: {badmatch,error} >>> >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/16/2013 12:02 PM, Anthony Ramine wrote: >>>> I can't reproduce any of these failures. >>>> >>>> Could I have more informations about how they failed? >>>> >>>> My wild guess is that it is related (maybe) to the bootstrap compiler, >>>> but I'm probably wrong. >>>> >>>> Bj?rn, any idea? >>>> >>>> Regards, >>>> >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 16 janv. 2013 ? 11:46, Fredrik a ?crit : >>>> >>>> >>>>>> >>>>> Hello Anthony, >>>>> >>>>>> >>>>> Your patch is failing the following testsuites and testcases: >>>>> >>>>>> >>>>> compilation_SUITE : self_compile >>>>> >>>>>> >>>>> inline_SUITE : decode1 >>>>> >>>>>> >>>>> inline_SUITE : pseudoknot >>>>> >>>>>> >>>>>> >>>>> Please correct and give me notice, >>>>> >>>>>> >>>>>> >>>>> BR Fredrik Gustafsson >>>>> >>>>>> >>>>> Erlang OTP Team >>>>> >>>>>> >>>>> On 01/15/2013 11:40 AM, Fredrik wrote: >>>>> >>>>>>>> Hello Anthony ;) >>>>>>>> >>>>>> It is now in the 'master-pu' branch. >>>>>> >>>>>>>> >>>>>> Thanks, >>>>>> >>>>>>>> >>>>>>>> >>>>>> BR Fredrik Gustafsson >>>>>> >>>>>>>> >>>>>> Erlang OTP Team >>>>>> >>>>>>>> >>>>>> On 01/15/2013 11:28 AM, Anthony Ramine wrote: >>>>>> >>>>>>>>>> >>>>>>> Repost on only erlang-patches so that Fredrik's MUA see it;) >>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> -- Anthony Ramine D?but du message r?exp?di? : >>>>>>> >>>>>>>>>>>>>> De : Anthony Ramine >>>>>>>>>>>>>> >>>>>>>>> Objet : R?p : Local function names in Core Erlang guards >>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> Date : 11 janvier 2013 17:12:37 HNEC >>>>>>>>> >>>>>>>>>>>>>> ? : erlang-bugs Bugs, erlang patches >>>>>>>>>>>>>> Cc : Bjorn Gustavsson >>>>>>>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> I wrote a really small patch to forbid local fun variables in Core Erlang guards. >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> There is no test case as there is no test suite for core_lint. >>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> I know the code freeze for R16 is soon but this is really a very small thing. >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>>>>>>>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> -- > Anthony Ramine >>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> While patching the compiler to allow substitutions of variables which values are >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> even though that makes the compiler passes further down the road generate badly-formed >>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> BEAM code. >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> names be allowed in guards? >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> code generation I would love to fix it and remove the code I wrote to avoid the >>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> substitution in guards... but I lack knowledge about the BEAM innards. >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> -- >> Anthony Ramine >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>>>> >>>>>> erlang-patches mailing list >>>>>> >>>>>>>> erlang-patches@REDACTED >>>>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>>> >>> >> > From fredrik@REDACTED Wed Jan 16 15:35:03 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 16 Jan 2013 15:35:03 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <7B473E62-4CC8-4C5B-83B3-1E0B5D5A0D4C@gmail.com> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> <50F6AA08.70405@erlang.org> <77D40EC8-92A6-4160-A807-1EFF564A177C@gmail.com> <86BA3528-B1ED-4C25-B34D-19E59BA1001C@gmail.com> <7B473E62-4CC8-4C5B-83B3-1E0B5D5A0D4C@gmail.com> Message-ID: <50F6BA97.6070908@erlang.org> Re-fetched and building in 'master-pu' right now. BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 03:09 PM, Anthony Ramine wrote: > The inliner seems to use integer for new variables. > > I amended my patch and its message accordingly, please refetch. > From egil@REDACTED Wed Jan 16 16:24:06 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 16 Jan 2013 16:24:06 +0100 Subject: [erlang-patches] use a proper way to pull ssize_t definition In-Reply-To: <50F436B7.9000104@erlang.org> References: <20121116023021.F0E5714A1B4@mail.netbsd.org> <50F02FEE.6020905@erlang.org> <50F436B7.9000104@erlang.org> Message-ID: <50F6C616.106@erlang.org> Patch has been merged to master. Closing issue designated OTP-10699. Thank you for your contribution! Bj?rn-Egil On 2013-01-14 17:47, Bj?rn-Egil Dahlberg wrote: > On 2013-01-11 16:29, Fredrik wrote: >> Hello, >> Sorry for the late answer, your patch is now in the 'master-pu' branch. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 11/16/2012 03:30 AM, YAMAMOTO Takashi wrote: >>> hi, >>> >>> this change is necessary at least on netbsd. >>> i noticed this when building erlang-lz4. > In review - placed in master-opu > > I did some tweaks, will get back to you once it passes daily builds. >>> >>> https://github.com/yamt/otp/compare/erlang:master...ssize_t >>> https://github.com/yamt/otp/compare/erlang:master...ssize_t.patch >>> >>> git fetch https://github.com/yamt/otp ssize_t >>> >>> YAMAMOTO Takashi >>> _______________________________________________ >>> 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 raimo+erlang-patches@REDACTED Thu Jan 17 11:40:04 2013 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Thu, 17 Jan 2013 11:40:04 +0100 Subject: [erlang-patches] odbcserver.c 64bit support In-Reply-To: References: <50BC8F7A.6080209@erlang.org> Message-ID: <20130117104004.GA5424@erix.ericsson.se> On Thu, Jan 10, 2013 at 04:54:15PM +0900, satoshi kinoshita wrote: > At Mon, 3 Dec 2012 12:39:38 +0100, > Henrik Nord wrote: > > > > > > On 11/29/2012 08:22 AM, satoshi kinoshita wrote: > > > I found antoher 64bit related bug in odbcserver.c. > > > It affects only param_query for stored-procedure > > > with OUT parameter of SQL_C_SLONG type. > > Can you add a testcase for this problem? > > The branch now includes both fix and some test cases. > > - The original bug I found is for 64 bit gcc(used to compile odbcserver.c). > Test cases should succeed with odbcserver compiled using 32 bit gcc > even without the fix. > > - oracle test case may need to set scrollable_cursors option to off > depending on the driver(I tested with Oracle ODBC driver from > following rpm package on > centos6: oracle-instantclient11.2-odbc-11.2.0.3.0-1.x86_64, > which seems like *not* supporting srollabel_cursors). > > > - postgresql test case is not actually checking the values of OUT params > of the stored function. > Though I'm still trying to write some more test cases to > check actual out values, > I think it's enough because it's checking > the fix (I mean this test case succeeds with my fix > and fails without it). > > - I have no time to setup and test this fix with mysql:). > It just skips the test cases when the RDBMS macro is defined as 'mysql'. I have added a comment explaining the postgres pecularity. https://github.com/RaimoNiskanen/otp/commit/3a8bd0f1e6c6b39082c13eea3f1ac3e49a4ac444 The branch looks a bit messy with commits for both "set scrollable_cursor to off for oracle driver" and "rollback disabling scrollable _cursor for oracle". Why not add the code as commented out? There are two "drop procedure after testing" that could be squashed. The last two commits "postgresql test case for 64bit bg for param_query" and bine "explain postgres pecularity for maram query out paramters" should be squashed. Can you do this cleanup or should I? It would be nice to have a better working test case for postgres, but I have pounded my forhead against a wall for a while trying to procuce one and it indeed seems that postgres does not return anything in out parameters, just in the result set. There are indications for that in the documentation for the procedural langguage 'sql', at least. It would also be nice if it was possible to procduce a test case that does not use stored procedures since they are so implementation specific. Do you think it would be possible to use something like "SELECT .. INTO ?" for that. I have tried with no success... > > > > > ---Patch-------------------------------------------------- > git fetch git://github.com/kinogmt/otp.git odbc64 > https://github.com/kinogmt/otp/compare/maint...odbc64 > https://github.com/kinogmt/otp/compare/maint...odbc64.patch > ----------------------------------------------------------- > > Thanks, > Kinoshtia > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From fredrik@REDACTED Thu Jan 17 12:00:51 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 17 Jan 2013 12:00:51 +0100 Subject: [erlang-patches] escript to accept emulator flags in scripts without shebang In-Reply-To: References: Message-ID: <50F7D9E3.9060702@erlang.org> Graduated to master. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/08/2013 07:50 PM, Magnus Henoch wrote: > The documentation for escript says that if the second or third line of > the script starts with %%!, the rest of the line will be used as > emulator arguments. However, currently this is only the case if the > first line starts with #!. I couldn't see any reason for that, so here > is a patch that removes this undocumented limitation. > > git fetch git://github.com/legoscia/otp.git escript_emulator_flags_vs_shebang > > https://github.com/legoscia/otp/compare/erlang:master...legoscia:escript_emulator_flags_vs_shebang > https://github.com/legoscia/otp/compare/erlang:master...legoscia:escript_emulator_flags_vs_shebang.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Thu Jan 17 12:22:43 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 17 Jan 2013 12:22:43 +0100 Subject: [erlang-patches] [patch] Fix bug in stdlib/queue that can slow down out/out_r In-Reply-To: References: Message-ID: <50F7DF03.3040403@erlang.org> Hello, Your patch has been to review, " The idea seems good but the list is broken apart and rebuilt. It should look like: r2f(List) -> {FF,RR} = lists:split(length(List) div 2 + 1, List), {FF,lists:reverse(RR, [])}." Could you fix this? BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 05:09 PM, Alex Erofeev wrote: > When applying out/out_r methods if one list of queue is empty can > happen situation where big list will be copying each time, so instead > on amortized linear time we'll get O(N^2). Example: > https://gist.github.com/4539653 . Try running it with 100000, 1000000 > and 10000000 elements and compare run times. > So I changed internal functions r2f and f2r to copy each time only > half of list instead of almost all of it. > > git fetch https://github.com/AlexErofeev/otp/tree/faster_queue > https://github.com/AlexErofeev/otp/compare/faster_queue > https://github.com/AlexErofeev/otp/compare/faster_queue.patch > > Regards, > > Alex Erofeev > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdmanana@REDACTED Thu Jan 17 12:29:22 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 17 Jan 2013 11:29:22 +0000 Subject: [erlang-patches] [PATCH] Use share flags for all file operations on Windows In-Reply-To: References: <5087AF84.5040404@erlang.org> Message-ID: Hello, Can you please refetch? https://github.com/fdmanana/otp/compare/master...windows_file_share_delete.patch https://github.com/fdmanana/otp/compare/master...windows_file_share_delete git fetch git://github.com/fdmanana/otp.git windows_file_share_delete thank you On Wed, Oct 24, 2012 at 1:09 PM, Filipe David Manana wrote: > On Wed, Oct 24, 2012 at 10:06 AM, Henrik Nord wrote: >> Hi >> >> I have added your patch to 'master-pu'. > > Thanks Henrik. > >> >> If you are able to reproduce this we would love tests for it. We do however >> understand if you are not able to reproduce it consistently as it may be >> dependent on timings and whatnot. > > Yes, it's very hard to reproduce it consistently. Basically what I > encountered was > that if an Erlang process is "in the middle of" a filelib:file_size/1 > (indirectly uses > efile_fileinfo C function) call (after it opened the file, with share > flags set to 0, > and before it closes the file), other processes attempting to delete, rename or > even open the file for read only mode, fail with eacces error. > > I noticed then that passing all the share flags to the CreateFileW > call in efile_fileinfo > was missing, as well as in a few other places other than efile_openfile. > >> >> However, there is a vague feeling that this may have been tried before, and >> strange errors with "ghost" files that did not exist, but could not be >> created as the names where taken. > > Yep, I think what you're mentioning relates to what is described in > these 2 pages: > > http://social.msdn.microsoft.com/Forums/nl-BE/vcgeneral/thread/54bef96f-3ca1-4dd7-a621-da2fa8d8b35b > (reply from Friday, October 28, 2011 12:39 PM) > > http://stackoverflow.com/questions/3764072/c-win32-how-to-wait-for-a-pending-delete-to-complete > > Seems the solution is to rename a file and then delete it. However > without FILE_SHARE_DELETE, the rename > operation fails (if the file is already open without share delete > flag), as I experienced and is mentioned in Microsoft's > documentation for FILE_SHARE_DELETE: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx > > It fails with ERROR_SHARING_VIOLATION, and then the win_efile module > translates it to EACCES. > Therefore I think this patch helps on that, but ultimately, due to > Windows specific file handling, the > rename + delete seems to be a common practice. > > best regards, > >> >> >> >> >> On 10/23/2012 07:56 PM, Filipe David Manana wrote: >>> >>> >>> https://github.com/fdmanana/otp/compare/maint...windows_file_share_delete.patch >>> https://github.com/fdmanana/otp/compare/maint...windows_file_share_delete >>> >>> git fetch git://github.com/fdmanana/otp.git windows_file_share_delete >>> >>> >> >> -- >> /Henrik Nord Erlang/OTP >> > > > > -- > Filipe David Manana, > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From fredrik@REDACTED Thu Jan 17 12:32:38 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 17 Jan 2013 12:32:38 +0100 Subject: [erlang-patches] [patch] Added application:get_env/3 In-Reply-To: <50F44E56.4040203@aleynikov.org> References: <50EED0CD.3080603@aleynikov.org> <50F3DA3B.7090602@erlang.org> <50F41BC5.8060802@aleynikov.org> <50F41C6A.1070401@erlang.org> <50F44E56.4040203@aleynikov.org> Message-ID: <50F7E156.8090903@erlang.org> Graduated to 'master'. Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/14/2013 07:28 PM, Serge Aleynikov wrote: > Please refetch both branches. Removed ?line macro in new test cases and > fixed the missing spec. > > On 1/14/2013 9:55 AM, Fredrik wrote: >> Hello, >> The answer is nothing. Just remove the '?line' that you've added. The >> principle is that if we adding code we don't include the ?line and if we >> are changing the code we are removing ?line from the lines we are >> changing. Not removing anything else right now. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/14/2013 03:52 PM, Serge Aleynikov wrote: >>> Fredrik, >>> >>> What should be used in place of the ?line macro? All test cases in that >>> file use the ?line macro, e.g. see application_SUITE:get_key/1. >>> >>> Serge >>> >>> On 1/14/2013 5:13 AM, Fredrik wrote: >>>> Hello Serge, >>>> Your patch is under review but I noticed during examination that you are >>>> using the ?line macro in your testcase provided. This is not used >>>> anymore and therefore should not be included, could you fix this? >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/10/2013 03:31 PM, Serge Aleynikov wrote: >>>>> Added an application:get_env/3 function variant that provides a default >>>>> value for a configuration parameter: >>>>> >>>>> application:get_env(App, Key, Default) -> Value. >>>>> >>>>> git fetch git://github.com/saleyn/otp.git get_env >>>>> >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env >>>>> https://github.com/saleyn/otp/compare/erlang:master...get_env.patch >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Thu Jan 17 13:53:55 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 17 Jan 2013 13:53:55 +0100 Subject: [erlang-patches] [PATCH] Use share flags for all file operations on Windows In-Reply-To: References: <5087AF84.5040404@erlang.org> Message-ID: <50F7F463.2020800@erlang.org> Re-fetched. The patch is currently under review. BR Fredrik Gustafsson Erlang OTP Team On 01/17/2013 12:29 PM, Filipe David Manana wrote: > git fetch git://github.com/fdmanana/otp.git windows_file_share_delete From egil@REDACTED Thu Jan 17 17:53:41 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 17 Jan 2013 17:53:41 +0100 Subject: [erlang-patches] Fix memory leak when stopping file driver In-Reply-To: <50CEDFFD.1010103@erlang.org> References: <50CEDFFD.1010103@erlang.org> Message-ID: <50F82C95.7020208@erlang.org> In review. This will probably be slightly changed due to changes made by you and Patrik in patch 'fix_efile_drv_crash'. I think we will drain the queue and then queue a close. I have to look at the other patch to be sure. On 2012-12-17 10:03, Fredrik wrote: > Hello Filipe! > Your patch is now in the 'master-pu' branch. > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/13/2012 06:00 AM, Filipe David Manana wrote: >> https://github.com/fdmanana/otp/compare/master...fix_file_driver_memory_leak.patch >> >> https://github.com/fdmanana/otp/compare/master...fix_file_driver_memory_leak >> >> >> git fetch git://github.com/fdmanana/otp.git >> fix_file_driver_memory_leak >> >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From fdmanana@REDACTED Thu Jan 17 18:31:40 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Thu, 17 Jan 2013 17:31:40 +0000 Subject: [erlang-patches] Fix memory leak when stopping file driver In-Reply-To: <50F82C95.7020208@erlang.org> References: <50CEDFFD.1010103@erlang.org> <50F82C95.7020208@erlang.org> Message-ID: On Thu, Jan 17, 2013 at 4:53 PM, Bj?rn-Egil Dahlberg wrote: > In review. > > This will probably be slightly changed due to changes made by you and Patrik > in patch 'fix_efile_drv_crash'. > > I think we will drain the queue and then queue a close. I have to look at > the other patch to be sure. Ah, yes true. I think after that other change, this one becomes irrelevant. thanks > > > On 2012-12-17 10:03, Fredrik wrote: >> >> Hello Filipe! >> Your patch is now in the 'master-pu' branch. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 12/13/2012 06:00 AM, Filipe David Manana wrote: >>> >>> >>> https://github.com/fdmanana/otp/compare/master...fix_file_driver_memory_leak.patch >>> >>> https://github.com/fdmanana/otp/compare/master...fix_file_driver_memory_leak >>> >>> git fetch git://github.com/fdmanana/otp.git fix_file_driver_memory_leak >>> >>> >> >> _______________________________________________ >> 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 -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From hanssv@REDACTED Thu Jan 17 23:25:24 2013 From: hanssv@REDACTED (Hans Svensson) Date: Thu, 17 Jan 2013 23:25:24 +0100 Subject: [erlang-patches] Auto-redirect should redirect also for POST on '303 See Other' Message-ID: <50F87A54.7020507@gmail.com> My first attempt to fix something in otp, so apologies on beforehand for errors in the process ;-) I tried following the instructions (https://github.com/erlang/otp/wiki/submitting-patches), and by the way those instructions should perhaps include a 'git push' somewhere (although that might be obvious if you are used to working with git...) otherwise the github page has a distinct lack of updates ;-) However, I noticed an error in httpc, where a POST request was not auto-redirected upon a '303 See Other' response as I believe it should be (see RFC2626 sect 10.3.4). Branch contains (failing) test case, as well as a suggested fix. git fetch git://github.com/hanssv/otp.git http_redirect_on_post_303 https://github.com/hanssv/otp/compare/http_redirect_on_post_303 https://github.com/hanssv/otp/compare/http_redirect_on_post_303.patch Cheers, Hans From fredrik@REDACTED Fri Jan 18 09:30:23 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 18 Jan 2013 09:30:23 +0100 Subject: [erlang-patches] Auto-redirect should redirect also for POST on '303 See Other' In-Reply-To: <50F87A54.7020507@gmail.com> References: <50F87A54.7020507@gmail.com> Message-ID: <50F9081F.7070901@erlang.org> Hello Hans, fun to see an old teacher posting patches ;) We are currently working on changing the wiki for submitting patches, thanks for noticing that! I am building your patch in the 'master-pu' branch now. Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/17/2013 11:25 PM, Hans Svensson wrote: > My first attempt to fix something in otp, so apologies on beforehand > for errors in the process ;-) I tried following the instructions > (https://github.com/erlang/otp/wiki/submitting-patches), and by the > way those instructions should perhaps include a 'git push' somewhere > (although that might be obvious if you are used to working with > git...) otherwise the github page has a distinct lack of updates ;-) > > However, I noticed an error in httpc, where a POST request was not > auto-redirected upon a '303 See Other' response as I believe it should > be (see RFC2626 sect 10.3.4). Branch contains (failing) test case, as > well as a suggested fix. > > git fetch git://github.com/hanssv/otp.git http_redirect_on_post_303 > > https://github.com/hanssv/otp/compare/http_redirect_on_post_303 > https://github.com/hanssv/otp/compare/http_redirect_on_post_303.patch > > Cheers, > > Hans > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Fri Jan 18 10:39:58 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 18 Jan 2013 10:39:58 +0100 Subject: [erlang-patches] Promote compiler option 'inline_list_funcs' In-Reply-To: <63FFF77A-F200-44B1-A7AB-2C2C8F62F4F2@gmail.com> References: <50F3D98C.4050107@erlang.org> <63FFF77A-F200-44B1-A7AB-2C2C8F62F4F2@gmail.com> Message-ID: <50F9186E.5030001@erlang.org> Graduated to master Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/14/2013 11:46 AM, Anthony Ramine wrote: > Done, please refetch. > > -- Anthony Ramine Le 14 janv. 2013 ? 11:10, Fredrik a ?crit : >> > Hello, >> > This patch is still under review, >> > But I noticed that you are using that you are using the '?line' macro in the testcase file which is not used anymore and therefore should not be there. >> > Could you fix this? (Just your additions of '?line'). >> > >> > BR Fredrik Gustafsson >> > Erlang OTP Team >> > On 11/03/2012 07:35 PM, Anthony Ramine wrote: >>> >> I've fixed a small typo, the HEAD commit is now >>> >> d790aefafa81afbf14d210629d1f178e457337c5. >>> >> >>> >> Regards, >>> >> >>> >> On Sat, Nov 3, 2012 at 7:02 PM, Anthony Ramine wrote: >>>> >>> The compiler option inline_list_funcs has been present in Erlang/OTP >>>> >>> since at least release R9B0. It enables the inlining of the most used >>>> >>> list manipulation functions of the stdlib's lists module. >>>> >>> >>>> >>> This couple of commits fix some wrong warnings triggered by the option >>>> >>> if the result of the inlined function is not actually used and mention >>>> >>> it in the documentation. >>>> >>> >>>> >>> https://github.com/nox/otp/compare/promote-inline_list_funcs >>>> >>> https://github.com/nox/otp/compare/promote-inline_list_funcs.patch >>>> >>> >>>> >>> Regards, >>>> >>> >>>> >>> >>>> >>> The following changes since commit d5733bc3e34449affde2594d85b905c8ab440d42: >>>> >>> >>>> >>> Merge branch 'egil/ensure-erl_crash.dump/OTP-10422' into maint >>>> >>> (2012-10-24 14:20:26 +0200) >>>> >>> >>>> >>> are available in the git repository at: >>>> >>> >>>> >>> https://github.com/nox/otp promote-inline_list_funcs >>>> >>> >>>> >>> for you to fetch changes up to 6ac8429cbe1072af6d615f668523237a2d040ed0: >>>> >>> >>>> >>> Document compiler option 'inline_list_funcs' (2012-11-03 18:55:07 +0100) >>>> >>> >>>> >>> ---------------------------------------------------------------- >>>> >>> Anthony Ramine (2): >>>> >>> Silence some wrong warnings triggered by inline_list_funcs >>>> >>> Document compiler option 'inline_list_funcs' >>>> >>> >>>> >>> lib/compiler/doc/src/compile.xml | 26 ++++++++++++++++++++++++++ >>>> >>> lib/compiler/src/sys_core_fold.erl | 20 ++++++++++++++------ >>>> >>> 2 files changed, 40 insertions(+), 6 deletions(-) >>> >> _______________________________________________ >>> >> erlang-patches mailing list >>> >> erlang-patches@REDACTED >>> >> http://erlang.org/mailman/listinfo/erlang-patches From fredrik@REDACTED Fri Jan 18 10:41:03 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 18 Jan 2013 10:41:03 +0100 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> Message-ID: <50F918AF.70206@erlang.org> Hello, Graduated to master! Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/15/2013 11:39 AM, Anthony Ramine wrote: > Hi Fredrik, > > I can't find any modules nor on_load cases in cover_SUITE. > > Regards, > > -- Anthony Ramine Le 15 janv. 2013 ? 10:42, Fredrik a ?crit : >> > After further research we can see that the patch is also failing these testcases in tools, >> > cover_SUITE, modules >> > cover_SUITE, on_load >> > >> > Please fix this and give me notice, >> > >> > BR Fredrik Gustafsson >> > Erlang OTP Team >> > On 01/10/2013 01:33 PM, Anthony Ramine wrote: >>> >> Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit : >>> >> >>>> >>> The code handles free variables. As far as I can understand, there >>>> >>> can be no free variables in this case, so you should simplify the code. >>> >> You're right and wrong:) There can be no free variables if the Core Erlang >>> >> code comes from a current Erlang module, but there can be if the Core Erlang >>> >> was handwritten or generated by my EEP37 patch, for example: >>> >> >>> >> module 'foo' ['bar'/1, >>> >> 'module_info'/0, >>> >> 'module_info'/1] >>> >> attributes [] >>> >> 'bar'/1 = >>> >> %% Line 4 >>> >> fun (_cor0) -> >>> >> letrec >>> >> 'Bar'/1 = >>> >> %% Line 5 >>> >> ( fun (_cor4) -> >>> >> let = 'Bar'/1 >>> >> in case _cor4 of >>> >> <1> when 'true' -> >>> >> 1 >>> >> when 'true' -> >>> >> let<_cor3> = >>> >> call 'erlang':'*' >>> >> (N, _cor0) >>> >> in let<_cor1> = >>> >> call 'erlang':'-' >>> >> (N, 1) >>> >> in let<_cor2> = >>> >> apply Bar >>> >> (_cor1) >>> >> in call 'erlang':'*' >>> >> (_cor3, _cor2) >>> >> end >>> >> -| [{'id',{0,0,'Bar'}}] ) >>> >> in 'Bar'/1 >>> >> 'module_info'/0 = >>> >> fun () -> >>> >> call 'erlang':'get_module_info' >>> >> ('foo') >>> >> 'module_info'/1 = >>> >> fun (_cor0) -> >>> >> call 'erlang':'get_module_info' >>> >> ('foo', _cor0) >>> >> end >>> >> >>> >> In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need >>> >> to be handled to remove the reverse eta conversion in a future-proof way. >>> >> >>> >> The differences between master and my patch when running erlc +to_kernel foo.core >>> >> are: >>> >> >>> >> --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100 >>> >> +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100 >>> >> @@ -5,18 +5,16 @@ >>> >> attributes [] >>> >> fdef 'bar'/1(_Xcor0) = >>> >> do >>> >> - bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0)>> <_ker2> >>> >> + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>> <_ker1> >>> >> then >>> >> -<<_ker2>> >>> >> +<<_ker1>> >>> >> fdef 'module_info'/0() = >>> >> enter (remote 'erlang':'get_module_info'/1)('foo') >>> >> fdef 'module_info'/1(_Xcor0) = >>> >> enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0) >>> >> -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) = >>> >> - enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0) >>> >> fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) = >>> >> do >>> >> - bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0)>> >>> >> + bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>> >>> >> then >>> >> match _Xcor4 >>> >> alt >>> >> @@ -34,10 +32,8 @@ >>> >> call (Bar)(_Xcor1)>> <_Xcor2> >>> >> then >>> >> do >>> >> - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>> <_ker1> >>> >> + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>> <_ker0> >>> >> then >>> >> -<<_ker1>> >>> >> +<<_ker0>> >>> >> end>> <> >>> >> -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) = >>> >> - enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0) >>> >> end >>> >> \ No newline at end of file >>> >> >>> >> Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you >>> >> when I'm done. Thanks for the feedback. >>> >> >>> >> Regards, >>> >> From fredrik@REDACTED Fri Jan 18 10:41:59 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 18 Jan 2013 10:41:59 +0100 Subject: [erlang-patches] Forbid local fun names in Core Erlang guards In-Reply-To: <7B473E62-4CC8-4C5B-83B3-1E0B5D5A0D4C@gmail.com> References: <50F53226.1040208@erlang.org> <50F6851C.1060509@erlang.org> <5E4FC9A7-A6C1-44AE-A217-987DD7782D1D@gmail.com> <50F6AA08.70405@erlang.org> <77D40EC8-92A6-4160-A807-1EFF564A177C@gmail.com> <86BA3528-B1ED-4C25-B34D-19E59BA1001C@gmail.com> <7B473E62-4CC8-4C5B-83B3-1E0B5D5A0D4C@gmail.com> Message-ID: <50F918E7.2090904@erlang.org> Graduated to master! Thanks for your contribution! BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 03:09 PM, Anthony Ramine wrote: > The inliner seems to use integer for new variables. > > I amended my patch and its message accordingly, please refetch. > > -- Anthony Ramine Le 16 janv. 2013 ? 14:47, Anthony Ramine a ?crit : >> > Oops. >> > >> > I was simply trying to replicate this in my rm-reverse-eta-conversion branch. >> > >> > Will investigate on the proper branch now. >> > >> > Regards, >> > >> > -- >> > Anthony Ramine >> > >> > Le 16 janv. 2013 ? 14:29, Anthony Ramine a ?crit : >> > >>> >> Thanks for the details. >>> >> >>> >> I'll rebase against current master and try again, line 428 of compilation_SUITE >>> >> can't fail that way in my current branch. >>> >> >>> >> -- >>> >> Anthony Ramine >>> >> >>> >> Le 16 janv. 2013 ? 14:24, Fredrik a ?crit : >>> >> >>>> >>> It was not the bootstrap, I think you have to take a look at those testcases, >>>> >>> Here's the reason's: >>>> >>> compilation_SUITE:self_compile_1 >>>> >>> failed on line 428 >>>> >>> Reason: suite_failed >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> inline_SUITE:try_inline failed on line 117 >>>> >>> Reason: {badmatch,error} >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> inline_SUITE:try_inline >>>> >>> failed on line 117 >>>> >>> Reason: {badmatch,error} >>>> >>> >>>> >>> >>>> >>> BR Fredrik Gustafsson >>>> >>> Erlang OTP Team >>>> >>> On 01/16/2013 12:02 PM, Anthony Ramine wrote: >>>>> >>>> I can't reproduce any of these failures. >>>>> >>>> >>>>> >>>> Could I have more informations about how they failed? >>>>> >>>> >>>>> >>>> My wild guess is that it is related (maybe) to the bootstrap compiler, >>>>> >>>> but I'm probably wrong. >>>>> >>>> >>>>> >>>> Bj?rn, any idea? >>>>> >>>> >>>>> >>>> Regards, >>>>> >>>> >>>>> >>>> >>>>> >>>> -- >>>>> >>>> Anthony Ramine >>>>> >>>> >>>>> >>>> Le 16 janv. 2013 ? 11:46, Fredrik a ?crit : >>>>> >>>> >>>>> >>>> >>>>>>> >>>>>> >>>>>> >>>>> Hello Anthony, >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>> Your patch is failing the following testsuites and testcases: >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>> compilation_SUITE : self_compile >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>> inline_SUITE : decode1 >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>> inline_SUITE : pseudoknot >>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>> Please correct and give me notice, >>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>> BR Fredrik Gustafsson >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>> Erlang OTP Team >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>> On 01/15/2013 11:40 AM, Fredrik wrote: >>>>>> >>>>> >>>>>>>>> >>>>>>>> Hello Anthony;) >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> It is now in the 'master-pu' branch. >>>>>>> >>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> Thanks, >>>>>>> >>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> BR Fredrik Gustafsson >>>>>>> >>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> Erlang OTP Team >>>>>>> >>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> On 01/15/2013 11:28 AM, Anthony Ramine wrote: >>>>>>> >>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> Repost on only erlang-patches so that Fredrik's MUA see it;) >>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> -- Anthony Ramine D?but du message r?exp?di? : >>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> De : Anthony Ramine >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Objet : R?p : Local function names in Core Erlang guards >>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> Date : 11 janvier 2013 17:12:37 HNEC >>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> ? : erlang-bugs Bugs, erlang patches >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Cc : Bjorn Gustavsson >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I wrote a really small patch to forbid local fun variables in Core Erlang guards. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> There is no test case as there is no test suite for core_lint. >>>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I know the code freeze for R16 is soon but this is really a very small thing. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> git fetchhttps://github.com/nox/otp.git forbid-locals-in-core-guards >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards >>>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/nox/otp/compare/erlang:master...forbid-locals-in-core-guards.patch >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- > Anthony Ramine >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Le 19 nov. 2012 ? 11:02, Anthony Ramine a ?crit : >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> While patching the compiler to allow substitutions of variables which values are >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> local function names [1], I discovered that core_lint doesn't forbid them in guards, >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> even though that makes the compiler passes further down the road generate badly-formed >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> BEAM code. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Is that a bug in core_lint or a bug in the BEAM code generation? Should local function >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> names be allowed in guards? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> If it is a bug in core_lint, I can make a patch for that; if it is a bug in the BEAM >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> code generation I would love to fix it and remove the code I wrote to avoid the >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> substitution in guards... but I lack knowledge about the BEAM innards. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1]http://erlang.org/pipermail/erlang-patches/2012-November/003137.html >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >> Anthony Ramine >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> erlang-patches mailing list >>>>>>> >>>>>> >>>>>>>>> >>>>>>>> erlang-patches@REDACTED >>>>>>>>> >>>>>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>>>>> >>>>>> >>>> >>> >>> >> >> > From egil@REDACTED Fri Jan 18 14:43:06 2013 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 18 Jan 2013 14:43:06 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F6B25C.6090006@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> Message-ID: <50F9516A.3080109@erlang.org> Patch merged. Closing issue designated OTP-10726. // Bj?rn-Egil On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: > On 2013-01-15 21:46, Anthony Ramine wrote: >> I couldn't reproduce the bug here but apparently I've found the cause >> of it. > Looking good. > > Putting it into master-opu integration branch. > > Will be merged later this week if no other issues appear. > > // Bj?rn-Egil > >> >> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): >> >>> Using the MAKE variable has the same effect as using a ?+? character >>> at the beginning of the recipe line. See Instead of Executing the >>> Recipes. This special feature is only enabled if the MAKE variable >>> appears directly in the recipe: it does not apply if the MAKE variable >>> is referenced through expansion of another variable. In the latter >>> case you must use the ?+? token to get these special effects. >> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable >> >> >> Please refetch. >> >> Regards, >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From dangud@REDACTED Fri Jan 18 15:16:32 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 18 Jan 2013 15:16:32 +0100 Subject: [erlang-patches] Shell History to Erlang In-Reply-To: <50D094B8.5090700@erlang.org> References: <4F38D7C1.3080502@erlang.org> <20121217192357.GF28537@hijacked.us> <50D03360.3060908@erlang.org> <20121218131517.GA57968@ferdmbp.local> <50D08959.90302@erlang.org> <20121218153126.GB57968@ferdmbp.local> <50D094B8.5090700@erlang.org> Message-ID: Starting to review this one, it might take awhile I don't know anything about edlin and group functionality. So have some patience with me..sigh scrum..:-) Some issues to start with. While testing this I used 'Esc' to abort the search, which works in bash. But here an hidden 'quote' get inserted and confuses the user (at least me). Also I guess it should be mentioned somewhere in the docs. Running a ssh shell to erlang's ssh deamon doesn't work, since the protocol is changed I guess. /Dan On Tue, Dec 18, 2012 at 5:07 PM, Fredrik wrote: > Since not anyone have had the time to look into it in detail, getting it > like a patch would put it in the "tasks queue" for us to review it. In that > way you would get a decision much faster. > We think it would be a cool feature but it needs to be reviewed and have > been run in all the tests before taking a decision. > > > BR Fredrik Gustafsson > Erlang OTP Team > On 12/18/2012 04:31 PM, Fred Hebert wrote: >> >> Does this mean it has a chance of making it there? The original thread I >> posted months ago asked if there were any chances for it to be included. >> If the OTP team is not interested in the solution in any way, it's no >> use losing my time formatting only to have it dismissed -- that's why I >> asked the question in the first place, and never got an answer. >> >> If there's a chances the OTP team is interested, I'll try and find the >> time to format things and send it as a proper patch. >> >> Regards, >> Fred. >> >> On 12/18, Fredrik wrote: >>> >>> Could you please follow the instructions here: >>> https://github.com/erlang/otp/wiki/submitting-patches >>> And we will review your patch. >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/18/2012 02:15 PM, Fred Hebert wrote: >>>> >>>> Here's the original description back from February: >>>> http://erlang.org/pipermail/erlang-patches/2012-February/002645.html >>>> >>>> Regards, >>>> Fred. >>>> >>>> On 12/18, Fredrik wrote: >>>>> >>>>> Hello Andrew! >>>>> What patch is this about? >>>>> >>>>> BR Fredrik Gustafsson >>>>> Erlang OTP Team >>>>> On 12/17/2012 08:23 PM, Andrew Thompson wrote: >>>>>> >>>>>> On Mon, Feb 13, 2012 at 10:28:33AM +0100, Henrik Nord wrote: >>>>>>> >>>>>>> This will have to wait for a technical board meeting. I will let you >>>>>>> know as soon as the meeting has been held. >>>>>> >>>>>> It's been 10 months, are there any updates on this? >>>>>> >>>>>> Andrew >>>>>> _______________________________________________ >>>>>> 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 Jan 18 15:22:27 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 18 Jan 2013 09:22:27 -0500 Subject: [erlang-patches] Shell History to Erlang In-Reply-To: References: <4F38D7C1.3080502@erlang.org> <20121217192357.GF28537@hijacked.us> <50D03360.3060908@erlang.org> <20121218131517.GA57968@ferdmbp.local> <50D08959.90302@erlang.org> <20121218153126.GB57968@ferdmbp.local> <50D094B8.5090700@erlang.org> Message-ID: <20130118142226.GA21286@ferdmbp.local> Hi Dan, There is no search functionality in this patch. I'm thinking this comment might have needed to go to http://erlang.org/pipermail/erlang-patches/2012-December/003242.html In any case, the use of 'Esc' is ambiguous to exit search because the character used in the escape sequence is the same one used while using meta (\e if I recall). Because the shell handles things in a character-per-character basis, there is no way for me to know whether I'm looking at a meta sequence or if I'm getting 'Esc' on its own. Supporting 'Esc' to escape search then means that I may leave garbage in the line when what I get is actually a meta sequence. Not sure how to work around this one. Regards, Fred. On 01/18, Dan Gudmundsson wrote: > Starting to review this one, it might take awhile I don't know > anything about edlin and group functionality. So have some patience > with me..sigh scrum..:-) > > Some issues to start with. > > While testing this I used 'Esc' to abort the search, which works in bash. > But here an hidden 'quote' get inserted and confuses the user (at least me). > > Also I guess it should be mentioned somewhere in the docs. > > Running a ssh shell to erlang's ssh deamon doesn't work, since the > protocol is changed I guess. > > /Dan > > On Tue, Dec 18, 2012 at 5:07 PM, Fredrik wrote: > > Since not anyone have had the time to look into it in detail, getting it > > like a patch would put it in the "tasks queue" for us to review it. In that > > way you would get a decision much faster. > > We think it would be a cool feature but it needs to be reviewed and have > > been run in all the tests before taking a decision. > > > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 12/18/2012 04:31 PM, Fred Hebert wrote: > >> > >> Does this mean it has a chance of making it there? The original thread I > >> posted months ago asked if there were any chances for it to be included. > >> If the OTP team is not interested in the solution in any way, it's no > >> use losing my time formatting only to have it dismissed -- that's why I > >> asked the question in the first place, and never got an answer. > >> > >> If there's a chances the OTP team is interested, I'll try and find the > >> time to format things and send it as a proper patch. > >> > >> Regards, > >> Fred. > >> > >> On 12/18, Fredrik wrote: > >>> > >>> Could you please follow the instructions here: > >>> https://github.com/erlang/otp/wiki/submitting-patches > >>> And we will review your patch. > >>> > >>> BR Fredrik Gustafsson > >>> Erlang OTP Team > >>> On 12/18/2012 02:15 PM, Fred Hebert wrote: > >>>> > >>>> Here's the original description back from February: > >>>> http://erlang.org/pipermail/erlang-patches/2012-February/002645.html > >>>> > >>>> Regards, > >>>> Fred. > >>>> > >>>> On 12/18, Fredrik wrote: > >>>>> > >>>>> Hello Andrew! > >>>>> What patch is this about? > >>>>> > >>>>> BR Fredrik Gustafsson > >>>>> Erlang OTP Team > >>>>> On 12/17/2012 08:23 PM, Andrew Thompson wrote: > >>>>>> > >>>>>> On Mon, Feb 13, 2012 at 10:28:33AM +0100, Henrik Nord wrote: > >>>>>>> > >>>>>>> This will have to wait for a technical board meeting. I will let you > >>>>>>> know as soon as the meeting has been held. > >>>>>> > >>>>>> It's been 10 months, are there any updates on this? > >>>>>> > >>>>>> Andrew > >>>>>> _______________________________________________ > >>>>>> 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 egil@REDACTED Fri Jan 18 15:22:53 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Fri, 18 Jan 2013 15:22:53 +0100 Subject: [erlang-patches] Fix memory leak when stopping file driver In-Reply-To: References: <50CEDFFD.1010103@erlang.org> <50F82C95.7020208@erlang.org> Message-ID: <50F95ABD.9020401@erlang.org> On 2013-01-17 18:31, Filipe David Manana wrote: > On Thu, Jan 17, 2013 at 4:53 PM, Bj?rn-Egil Dahlberg wrote: >> In review. >> >> This will probably be slightly changed due to changes made by you and Patrik >> in patch 'fix_efile_drv_crash'. >> >> I think we will drain the queue and then queue a close. I have to look at >> the other patch to be sure. > Ah, yes true. > I think after that other change, this one becomes irrelevant. Ok, I think we reached a consensus. We will drop this patch since the other patch solves the problem. // Bj?rn-Egil > > thanks > >> >> On 2012-12-17 10:03, Fredrik wrote: >>> Hello Filipe! >>> Your patch is now in the 'master-pu' branch. >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 12/13/2012 06:00 AM, Filipe David Manana wrote: >>>> >>>> https://github.com/fdmanana/otp/compare/master...fix_file_driver_memory_leak.patch >>>> >>>> https://github.com/fdmanana/otp/compare/master...fix_file_driver_memory_leak >>>> >>>> git fetch git://github.com/fdmanana/otp.git fix_file_driver_memory_leak >>>> >>>> >>> _______________________________________________ >>> 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 egil@REDACTED Fri Jan 18 15:59:16 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 18 Jan 2013 15:59:16 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F3CB77.8020508@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> Message-ID: <50F96344.9040504@erlang.org> In review .. again =) I think we have covered default behaviours. Is the following intended behaviour? =) 1> erlang:float_to_list(3/7, [{decimals, 314}, compact]). [48,46,52,50,56,53,55,49,52,50,56,53,55,49,52,50,56,53,52, 55,54,51,56,48,55,56,48,52,51|...] 2> erlang:float_to_list(3/7, [{scientific, 314}, compact]). "4.2857142857142854763807804374664556235074996948242187500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" ? // Bj?rn-Egil On 2013-01-14 10:10, Fredrik wrote: > Hello, > This testcase is failing: > Suite: bif_SUITE > Testcase: specs > Reason: > The following BIFs don't have specs: > > erlang:float_to_list/2 > Give me notice when this is done, > BR Fredrik Gustafsson > Erlang OTP Team > On 01/11/2013 04:55 PM, Serge Aleynikov wrote: >> Sorry the test case line was the "last moment" add on. It is fixed now >> in my branch below. >> >> On 1/11/2013 10:44 AM, Fredrik wrote: >>> Hey, >>> Your patch does not build: >>> " >>> >>> emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern >>> " >>> >>> >>> Please have a look at it, and give me notice when you are done. >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/11/2013 03:11 PM, Serge Aleynikov wrote: >>>> Ok. Here's the patch rebased to master: >>>> >>>> git fetchhttps://github.com/saleyn/otp/tree/float_to_list_2 >>>> >>>> https://github.com/saleyn/otp/compare/master...float_to_list_2 >>>> https://github.com/saleyn/otp/compare/master...float_to_list_2.patch >>>> >>>> Regards, >>>> >>>> Serge >>>> >>>> On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >>>>> On 2013-01-11 14:24, Serge Aleynikov wrote: >>>>>> While looking at this I see that the code in folder >>>>>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>>>>> master branch. Is this intentional? If so, should I remove the >>>>>> part of >>>>>> the patch designed for vxworks? >>>>> Yes. Any and all vxworks support has been removed in R16 from OTP except >>>>> for epmd, erl_interface and ic. >>>>> >>>>> // Bj?rn-Egil >>>>>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>>>>> Hey, >>>>>>> Could you please rebase this on current 'master' branch? >>>>>>> >>>>>>> BR Fredrik Gustafsson >>>>>>> Erlang OTP Team >>>>>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>>>>> I implemented Lukas's recommendations that were presenting an >>>>>>>> acceptance >>>>>>>> issue of the new function, so the current version of the patch does: >>>>>>>> >>>>>>>> 1. float_to_list/1 is backwards compatible. >>>>>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>>>>> (with the optional compact option). >>>>>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>>>>> float_to_list(X) with the ability to control the number of decimals. >>>>>>>> >>>>>>>> The only item from Lucas's list that I left unchanged was the >>>>>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>>>>> advantage of the speed improvement of the new implementation. I am >>>>>>>> including a patch in this email that implements this logic, but I >>>>>>>> decided to leave the integration task to the OTP team since >>>>>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>>>>> library and I didn't want to introduce a dependency of it on other >>>>>>>> code >>>>>>>> - this should be decided by maintainers. >>>>>>>> >>>>>>>> The test cases of float_to_list/{1,2} have been updated. >>>>>>>> >>>>>>>> git fetchhttps://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>> >>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Serge >>>>>>>> >>>>>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>>>>> R16B. >>>>>>>>> >>>>>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>>>>> best >>>>>>>>> way to ensure that is to send an updated patch. >>>>>>>>> >>>>>>>>> Lukas >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>>>>> I am certainly very happy to hear that you finally agreed to >>>>>>>>>> include >>>>>>>>>> this in the distribution. The changes proposed below seem >>>>>>>>>> reasonable >>>>>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>>>>> implement >>>>>>>>>> them? >>>>>>>>>> >>>>>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>>>>> Hello Serge! >>>>>>>>>>> >>>>>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>>>>> work. >>>>>>>>>>> >>>>>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>>>>> compatibility. >>>>>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>>>>> implementation >>>>>>>>>>> (with the optional compact option). >>>>>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>>>>> >>>>>>>>>>> We would also like the string rendering part of >>>>>>>>>>> sys_double_to_chars_fast >>>>>>>>>>> to be put into >>>>>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>>>>> way other parts of the vm which print floats will benefit from >>>>>>>>>>> your >>>>>>>>>>> changes! >>>>>>>>>>> >>>>>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>>>>> taking >>>>>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>>>>> ponderings just let me know. >>>>>>>>>>> >>>>>>>>>>> Lukas >>>>>>>>>>> >>>>>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>>>>> float_to_list_1 as well, is possible to do this and stay >>>>>>>>>>>>> backwards >>>>>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>>>>> e+XX at >>>>>>>>>>>>> the end of the optimized case and call sys_double_to_chars >>>>>>>>>>>>> for the >>>>>>>>>>>>> unoptimized. >>>>>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>>>>> questioning >>>>>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. >>>>>>>>>>>> However, I >>>>>>>>>>>> think >>>>>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>>>>> which >>>>>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>>>>> wrote >>>>>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>>>>> without a performance penalty. >>>>>>>>>>>> >>>>>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>>>>> rounding >>>>>>>>>>>> involved. >>>>>>>>>>>> >>>>>>>>>>>> This case is easy: >>>>>>>>>>>> >>>>>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>>>>> "1.01234000000000001762" >>>>>>>>>>>> >>>>>>>>>>>> This case is a bit more complex (illustration of rounding >>>>>>>>>>>> impact): >>>>>>>>>>>> >>>>>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>>>>> >>>>>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>>>>> with how >>>>>>>>>>>>> other such APIs work. >>>>>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>>>>> request that >>>>>>>>>>>> the default number of decimals is chosen to be consistent with >>>>>>>>>>>> what >>>>>>>>>>>> printf() does, so I changed the implementation to accommodate >>>>>>>>>>>> that >>>>>>>>>>>> request: >>>>>>>>>>>> >>>>>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>>>>> "1.000000" >>>>>>>>>>>> >>>>>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>>>>> >>>>>>>>>>>> 2> float_to_list(1.0). >>>>>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>>>>> >>>>>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>>>>> float_to_list/2, to >>>>>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>>>>> >>>>>>>>>>>> Serge >>>>>>>>>>>> >>>>>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>>>>> Henrik, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Fetch: git fetch >>>>>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>> Diff:https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>>>>> happy: >>>>>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>>>>> suites >>>>>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>>>>> tried the >>>>>>>>>>>>>> following but all tests fail: >>>>>>>>>>>>>> >>>>>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>>>>> test_server_ctrl >>>>>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>>>>> >>>>>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>>>>> sure my >>>>>>>>>>>>>> patch didn't break anything. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Serge >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>>>>> Hi again. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No type information: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>>>>> git fetchhttps://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangud@REDACTED Fri Jan 18 16:11:26 2013 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 18 Jan 2013 16:11:26 +0100 Subject: [erlang-patches] Shell history search In-Reply-To: <50EC19C7.90507@erlang.org> References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> <50EBEFC0.7040101@erlang.org> <20130108124936.GA25258@ferdmbp.local> <50EC19C7.90507@erlang.org> Message-ID: Switched to correct patch/thread. On Fri, Jan 18, 2013 at 3:22 PM, Fred Hebert wrote: > Hi Dan, > In any case, the use of 'Esc' is ambiguous to exit search because the > character used in the escape sequence is the same one used while using > meta (\e if I recall). Because the shell handles things in a > character-per-character basis, there is no way for me to know whether > I'm looking at a meta sequence or if I'm getting 'Esc' on its own. > > Supporting 'Esc' to escape search then means that I may leave garbage in > the line when what I get is actually a meta sequence. If you can not find a better solution then my initial reaction is to not support meta seq, jump out of search and display the garbage because this confused me and will confuse others. Can you not catch it higher up, i.e. in edit/5 case key_map(C, Prefix) of search_meta when CS =:= [] -> search_quit(). /Dan > Not sure how to work around this one. > > Regards, > Fred. > On Tue, Jan 8, 2013 at 2:06 PM, Fredrik wrote: > Great, > I have re-fetched and building it in master-pu branch now. > Thanks! > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/08/2013 01:49 PM, Fred Hebert wrote: >> >> Hi Fredrik, >> >> It's done. From my understanding of the code, I simply needed to pass in >> the encoding to the prompt_bytes/2 functions, and it seems to work fine. >> >> Regards, >> Fred. >> >> On 01/08, Fredrik wrote: >>> >>> Hello Fred, >>> You need to rebase upon 'master' branch and make changes to your >>> patch, it fails to build on >>> 'group.erl:536: function prompt_bytes/1 undefined' >>> >>> Let me know when you are done, >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/04/2013 09:07 AM, Fredrik wrote: >>>> >>>> Hello Fred, >>>> Must have missed to reply to you, your patch has been in >>>> 'master-pu' branch since wednesday. >>>> Thanks for your contribution. >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 12/22/2012 11:41 PM, Fred Hebert wrote: >>>>> >>>>> Hi, the following patch adds functionality to group.erl and edlin.erl >>>>> in >>>>> order to allow the user to search history. >>>>> >>>>> Search mode can be entered by pressing ctrl-r. Enter terms and press >>>>> ctrl-r again to search backwards, or ctrl-s to then search forward (if >>>>> you terminal doesn't eat up that one). Press enter to execute the line, >>>>> or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to >>>>> exit search mode while remaining on the last found line. >>>>> >>>>> The search mode is a simpler version of the one available in bash or >>>>> zsh shells. >>>>> >>>>> This adds a few modes to the shell (search, on top of none and meta) in >>>>> group.erl for history search, and a few more in edlin.erl to change the >>>>> meaning of control sequences while searching. >>>>> >>>>> This patch has been tested on OSX and some linux variants and worked >>>>> fine. >>>>> I tested it on Windows, and neither do werl.exe, or erl.exe (under >>>>> PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not >>>>> work there, but will not break any existing functionality. As far as >>>>> I'm >>>>> aware, this is more likely a driver issue than an issue with the patch >>>>> (^G is not captured in cmd.exe, ctrl+C works in none of the above, for >>>>> example). >>>>> >>>>> git fetch git://github.com/ferd/otp.git shell_history_search >>>>> >>>>> Compare at: >>>>> >>>>> >>>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search >>>>> >>>>> >>>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch >>>>> >>>>> >>>>> Regards, >>>>> Fred. >>>>> _______________________________________________ >>>>> 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 Jan 18 16:22:38 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 18 Jan 2013 10:22:38 -0500 Subject: [erlang-patches] Shell history search In-Reply-To: References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> <50EBEFC0.7040101@erlang.org> <20130108124936.GA25258@ferdmbp.local> <50EC19C7.90507@erlang.org> Message-ID: <20130118152237.GB21286@ferdmbp.local> I can do it that way if we can guarantee we'll always get the characters grouped in sequence, and not, say 'andIKeepGOing' sent as one continuous blob to the Erlang shell. I was not aware of any such guarantee so I decided not to assume anything. If we can get it, then I'll be able to look at the tail of the sequence and look for additional characters. Regarding the SSH shell, what are the steps for me to reproduce it, and what do you mean by breaking things? The shell doesn't work at all, or only the search? Regards, Fred. On 01/18, Dan Gudmundsson wrote: > Switched to correct patch/thread. > > On Fri, Jan 18, 2013 at 3:22 PM, Fred Hebert wrote: > > Hi Dan, > > In any case, the use of 'Esc' is ambiguous to exit search because the > > character used in the escape sequence is the same one used while using > > meta (\e if I recall). Because the shell handles things in a > > character-per-character basis, there is no way for me to know whether > > I'm looking at a meta sequence or if I'm getting 'Esc' on its own. > > > > Supporting 'Esc' to escape search then means that I may leave garbage in > > the line when what I get is actually a meta sequence. > > If you can not find a better solution then my initial reaction is to > not support meta seq, jump out of search and display the garbage > because this confused me and will confuse others. > > Can you not catch it higher up, i.e. in edit/5 > case key_map(C, Prefix) of > search_meta when CS =:= [] -> search_quit(). > > /Dan > > > Not sure how to work around this one. > > > > Regards, > > Fred. > > > > On Tue, Jan 8, 2013 at 2:06 PM, Fredrik wrote: > > Great, > > I have re-fetched and building it in master-pu branch now. > > Thanks! > > > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 01/08/2013 01:49 PM, Fred Hebert wrote: > >> > >> Hi Fredrik, > >> > >> It's done. From my understanding of the code, I simply needed to pass in > >> the encoding to the prompt_bytes/2 functions, and it seems to work fine. > >> > >> Regards, > >> Fred. > >> > >> On 01/08, Fredrik wrote: > >>> > >>> Hello Fred, > >>> You need to rebase upon 'master' branch and make changes to your > >>> patch, it fails to build on > >>> 'group.erl:536: function prompt_bytes/1 undefined' > >>> > >>> Let me know when you are done, > >>> > >>> BR Fredrik Gustafsson > >>> Erlang OTP Team > >>> On 01/04/2013 09:07 AM, Fredrik wrote: > >>>> > >>>> Hello Fred, > >>>> Must have missed to reply to you, your patch has been in > >>>> 'master-pu' branch since wednesday. > >>>> Thanks for your contribution. > >>>> > >>>> BR Fredrik Gustafsson > >>>> Erlang OTP Team > >>>> On 12/22/2012 11:41 PM, Fred Hebert wrote: > >>>>> > >>>>> Hi, the following patch adds functionality to group.erl and edlin.erl > >>>>> in > >>>>> order to allow the user to search history. > >>>>> > >>>>> Search mode can be entered by pressing ctrl-r. Enter terms and press > >>>>> ctrl-r again to search backwards, or ctrl-s to then search forward (if > >>>>> you terminal doesn't eat up that one). Press enter to execute the line, > >>>>> or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to > >>>>> exit search mode while remaining on the last found line. > >>>>> > >>>>> The search mode is a simpler version of the one available in bash or > >>>>> zsh shells. > >>>>> > >>>>> This adds a few modes to the shell (search, on top of none and meta) in > >>>>> group.erl for history search, and a few more in edlin.erl to change the > >>>>> meaning of control sequences while searching. > >>>>> > >>>>> This patch has been tested on OSX and some linux variants and worked > >>>>> fine. > >>>>> I tested it on Windows, and neither do werl.exe, or erl.exe (under > >>>>> PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not > >>>>> work there, but will not break any existing functionality. As far as > >>>>> I'm > >>>>> aware, this is more likely a driver issue than an issue with the patch > >>>>> (^G is not captured in cmd.exe, ctrl+C works in none of the above, for > >>>>> example). > >>>>> > >>>>> git fetch git://github.com/ferd/otp.git shell_history_search > >>>>> > >>>>> Compare at: > >>>>> > >>>>> > >>>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search > >>>>> > >>>>> > >>>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch > >>>>> > >>>>> > >>>>> Regards, > >>>>> Fred. > >>>>> _______________________________________________ > >>>>> 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 Fri Jan 18 17:18:54 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 18 Jan 2013 17:18:54 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <93D7C987-9EA7-4C9D-9F59-C8AD2276EB45@gmail.com> References: <50F53DF1.4090309@erlang.org> <93D7C987-9EA7-4C9D-9F59-C8AD2276EB45@gmail.com> Message-ID: <3FEC940C-95D7-42EB-895F-D64E65DE8BF1@gmail.com> Hi, I rebased against current master and resolved the conflicts related to the conversion to UTF-8 of erl_scan_SUITE.erl. Please refetch. -- Anthony Ramine Le 15 janv. 2013 ? 14:05, Anthony Ramine a ?crit : > I rebased it and made erl_scan_SUITE's otp_10302 test case handle end locations. > > Please refetch. > > -- > Anthony Ramine > > Le 15 janv. 2013 ? 12:30, Fredrik a ?crit : > >> In the meantime could you please rebase it on master? >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 11/10/2012 04:28 PM, Anthony Ramine wrote: >>> Hi, >>> >>> This branch adds a new option "end" to erl_scan. If set, it tracks and >>> returns end locations of each scanned token in their attributes as >>> `{'end', {EndLine, EndCol}}`. >>> >>> https://github.com/nox/otp/compare/scan-end-locations >>> https://github.com/nox/otp/compare/scan-end-locations.patch >>> >>> git fetch https://github.com/nox/otp scan-end-locations >>> >>> Regards, >>> >> > From fredrik@REDACTED Fri Jan 18 17:20:43 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 18 Jan 2013 17:20:43 +0100 Subject: [erlang-patches] Return end locations in erl_scan In-Reply-To: <3FEC940C-95D7-42EB-895F-D64E65DE8BF1@gmail.com> References: <50F53DF1.4090309@erlang.org> <93D7C987-9EA7-4C9D-9F59-C8AD2276EB45@gmail.com> <3FEC940C-95D7-42EB-895F-D64E65DE8BF1@gmail.com> Message-ID: <50F9765B.2060909@erlang.org> Re-fetched. Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/18/2013 05:18 PM, Anthony Ramine wrote: > Hi, > > I rebased against current master and resolved the conflicts related to > the conversion to UTF-8 of erl_scan_SUITE.erl. > > Please refetch. > From serge@REDACTED Fri Jan 18 17:25:26 2013 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 18 Jan 2013 11:25:26 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F96344.9040504@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DB65C.1090106@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F96344.9040504@erlang.org> Message-ID: <50F97776.80207@aleynikov.org> This is not intended. In both cases the issue is that the buffer used for formatting the numbers is fixed to 256 bytes. So essentially in case of {scientific, Decimals} option the C call looks like this: erts_snprintf(buffer, buffer_size, "%.*e", decimals, n) In case of {decimals, Decimals} option, when Decimals exceeds the buffer size, the call defaults to: erts_snprintf(buffer, buffer_size-1, "%.*f", Decimals, n); The question is what should be the function's behavior when the Decimals value is (too) large? Throw badarg? Reduce it to a set maximum? I think that documenting a max limit and throwing badarg would be the right approach. Thoughts? On 1/18/2013 9:59 AM, Bj?rn-Egil Dahlberg wrote: > In review .. again =) > > I think we have covered default behaviours. > > Is the following intended behaviour? =) > > 1> erlang:float_to_list(3/7, [{decimals, 314}, > compact]). > [48,46,52,50,56,53,55,49,52,50,56,53,55,49,52,50,56,53,52, > 55,54,51,56,48,55,56,48,52,51|...] > > 2> erlang:float_to_list(3/7, [{scientific, 314}, compact]). > "4.2857142857142854763807804374664556235074996948242187500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" > > ? > > // Bj?rn-Egil > > On 2013-01-14 10:10, Fredrik wrote: >> Hello, >> This testcase is failing: >> Suite: bif_SUITE >> Testcase: specs >> Reason: >> The following BIFs don't have specs: >> >> erlang:float_to_list/2 >> Give me notice when this is done, >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/11/2013 04:55 PM, Serge Aleynikov wrote: >>> Sorry the test case line was the "last moment" add on. It is fixed now >>> in my branch below. >>> >>> On 1/11/2013 10:44 AM, Fredrik wrote: >>>> Hey, >>>> Your patch does not build: >>>> " >>>> >>>> emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern >>>> " >>>> >>>> >>>> Please have a look at it, and give me notice when you are done. >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 01/11/2013 03:11 PM, Serge Aleynikov wrote: >>>>> Ok. Here's the patch rebased to master: >>>>> >>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>> >>>>> https://github.com/saleyn/otp/compare/master...float_to_list_2 >>>>> https://github.com/saleyn/otp/compare/master...float_to_list_2.patch >>>>> >>>>> Regards, >>>>> >>>>> Serge >>>>> >>>>> On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >>>>>> On 2013-01-11 14:24, Serge Aleynikov wrote: >>>>>>> While looking at this I see that the code in folder >>>>>>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>>>>>> master branch. Is this intentional? If so, should I remove the >>>>>>> part of >>>>>>> the patch designed for vxworks? >>>>>> Yes. Any and all vxworks support has been removed in R16 from OTP except >>>>>> for epmd, erl_interface and ic. >>>>>> >>>>>> // Bj?rn-Egil >>>>>>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>>>>>> Hey, >>>>>>>> Could you please rebase this on current 'master' branch? >>>>>>>> >>>>>>>> BR Fredrik Gustafsson >>>>>>>> Erlang OTP Team >>>>>>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>>>>>> I implemented Lukas's recommendations that were presenting an >>>>>>>>> acceptance >>>>>>>>> issue of the new function, so the current version of the patch does: >>>>>>>>> >>>>>>>>> 1. float_to_list/1 is backwards compatible. >>>>>>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>>>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>>>>>> (with the optional compact option). >>>>>>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>>>>>> float_to_list(X) with the ability to control the number of decimals. >>>>>>>>> >>>>>>>>> The only item from Lucas's list that I left unchanged was the >>>>>>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>>>>>> advantage of the speed improvement of the new implementation. I am >>>>>>>>> including a patch in this email that implements this logic, but I >>>>>>>>> decided to leave the integration task to the OTP team since >>>>>>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>>>>>> library and I didn't want to introduce a dependency of it on other >>>>>>>>> code >>>>>>>>> - this should be decided by maintainers. >>>>>>>>> >>>>>>>>> The test cases of float_to_list/{1,2} have been updated. >>>>>>>>> >>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>> >>>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Serge >>>>>>>>> >>>>>>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>>>>>> R16B. >>>>>>>>>> >>>>>>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>>>>>> best >>>>>>>>>> way to ensure that is to send an updated patch. >>>>>>>>>> >>>>>>>>>> Lukas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>>>>>> I am certainly very happy to hear that you finally agreed to >>>>>>>>>>> include >>>>>>>>>>> this in the distribution. The changes proposed below seem >>>>>>>>>>> reasonable >>>>>>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>>>>>> implement >>>>>>>>>>> them? >>>>>>>>>>> >>>>>>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>>>>>> Hello Serge! >>>>>>>>>>>> >>>>>>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>>>>>> work. >>>>>>>>>>>> >>>>>>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>>>>>> compatibility. >>>>>>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>>>>>> implementation >>>>>>>>>>>> (with the optional compact option). >>>>>>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>>>>>> >>>>>>>>>>>> We would also like the string rendering part of >>>>>>>>>>>> sys_double_to_chars_fast >>>>>>>>>>>> to be put into >>>>>>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>>>>>> way other parts of the vm which print floats will benefit from >>>>>>>>>>>> your >>>>>>>>>>>> changes! >>>>>>>>>>>> >>>>>>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>>>>>> taking >>>>>>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>>>>>> ponderings just let me know. >>>>>>>>>>>> >>>>>>>>>>>> Lukas >>>>>>>>>>>> >>>>>>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>>>>>> float_to_list_1 as well, is possible to do this and stay >>>>>>>>>>>>>> backwards >>>>>>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>>>>>> e+XX at >>>>>>>>>>>>>> the end of the optimized case and call sys_double_to_chars >>>>>>>>>>>>>> for the >>>>>>>>>>>>>> unoptimized. >>>>>>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>>>>>> questioning >>>>>>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. >>>>>>>>>>>>> However, I >>>>>>>>>>>>> think >>>>>>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>>>>>> which >>>>>>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>>>>>> wrote >>>>>>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>>>>>> without a performance penalty. >>>>>>>>>>>>> >>>>>>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>>>>>> rounding >>>>>>>>>>>>> involved. >>>>>>>>>>>>> >>>>>>>>>>>>> This case is easy: >>>>>>>>>>>>> >>>>>>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>>>>>> "1.01234000000000001762" >>>>>>>>>>>>> >>>>>>>>>>>>> This case is a bit more complex (illustration of rounding >>>>>>>>>>>>> impact): >>>>>>>>>>>>> >>>>>>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>>>>>> >>>>>>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>>>>>> with how >>>>>>>>>>>>>> other such APIs work. >>>>>>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>>>>>> request that >>>>>>>>>>>>> the default number of decimals is chosen to be consistent with >>>>>>>>>>>>> what >>>>>>>>>>>>> printf() does, so I changed the implementation to accommodate >>>>>>>>>>>>> that >>>>>>>>>>>>> request: >>>>>>>>>>>>> >>>>>>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>>>>>> "1.000000" >>>>>>>>>>>>> >>>>>>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>>>>>> >>>>>>>>>>>>> 2> float_to_list(1.0). >>>>>>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>>>>>> float_to_list/2, to >>>>>>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>>>>>> >>>>>>>>>>>>> Serge >>>>>>>>>>>>> >>>>>>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>>>>>> Henrik, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fetch: git fetch >>>>>>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>>>>>> happy: >>>>>>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>>>>>> suites >>>>>>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>>>>>> tried the >>>>>>>>>>>>>>> following but all tests fail: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>>>>>> test_server_ctrl >>>>>>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>>>>>> sure my >>>>>>>>>>>>>>> patch didn't break anything. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Serge >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>>>>>> Hi again. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No type information: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > From egil@REDACTED Fri Jan 18 17:41:09 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Fri, 18 Jan 2013 17:41:09 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F97776.80207@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F96344.9040504@erla ng.org> <50F97776.80207@aleynik! ov.org> Message-ID: <50F97B25.3020206@erlang.org> On 2013-01-18 17:25, Serge Aleynikov wrote: > This is not intended. > > In both cases the issue is that the buffer used for formatting the > numbers is fixed to 256 bytes. Figured the buffer when I saw fbuf[256]. > The question is what should be the function's behavior when the Decimals > value is (too) large? Throw badarg? Reduce it to a set maximum? I > think that documenting a max limit and throwing badarg would be the > right approach. > > Thoughts? I agree. Documenting and enforcing a max limit should be the appropriate thing to do. Also, test the error cases. // Bj?rn-Egil > > On 1/18/2013 9:59 AM, Bj?rn-Egil Dahlberg wrote: >> In review .. again =) >> >> I think we have covered default behaviours. >> >> Is the following intended behaviour? =) >> >> 1> erlang:float_to_list(3/7, [{decimals, 314}, >> compact]). >> [48,46,52,50,56,53,55,49,52,50,56,53,55,49,52,50,56,53,52, >> 55,54,51,56,48,55,56,48,52,51|...] >> >> 2> erlang:float_to_list(3/7, [{scientific, 314}, compact]). >> "4.2857142857142854763807804374664556235074996948242187500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" >> >> ? >> >> // Bj?rn-Egil >> >> On 2013-01-14 10:10, Fredrik wrote: >>> Hello, >>> This testcase is failing: >>> Suite: bif_SUITE >>> Testcase: specs >>> Reason: >>> The following BIFs don't have specs: >>> >>> erlang:float_to_list/2 >>> Give me notice when this is done, >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/11/2013 04:55 PM, Serge Aleynikov wrote: >>>> Sorry the test case line was the "last moment" add on. It is fixed now >>>> in my branch below. >>>> >>>> On 1/11/2013 10:44 AM, Fredrik wrote: >>>>> Hey, >>>>> Your patch does not build: >>>>> " >>>>> >>>>> emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern >>>>> " >>>>> >>>>> >>>>> Please have a look at it, and give me notice when you are done. >>>>> >>>>> BR Fredrik Gustafsson >>>>> Erlang OTP Team >>>>> On 01/11/2013 03:11 PM, Serge Aleynikov wrote: >>>>>> Ok. Here's the patch rebased to master: >>>>>> >>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>> >>>>>> https://github.com/saleyn/otp/compare/master...float_to_list_2 >>>>>> https://github.com/saleyn/otp/compare/master...float_to_list_2.patch >>>>>> >>>>>> Regards, >>>>>> >>>>>> Serge >>>>>> >>>>>> On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >>>>>>> On 2013-01-11 14:24, Serge Aleynikov wrote: >>>>>>>> While looking at this I see that the code in folder >>>>>>>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>>>>>>> master branch. Is this intentional? If so, should I remove the >>>>>>>> part of >>>>>>>> the patch designed for vxworks? >>>>>>> Yes. Any and all vxworks support has been removed in R16 from OTP except >>>>>>> for epmd, erl_interface and ic. >>>>>>> >>>>>>> // Bj?rn-Egil >>>>>>>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>>>>>>> Hey, >>>>>>>>> Could you please rebase this on current 'master' branch? >>>>>>>>> >>>>>>>>> BR Fredrik Gustafsson >>>>>>>>> Erlang OTP Team >>>>>>>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>>>>>>> I implemented Lukas's recommendations that were presenting an >>>>>>>>>> acceptance >>>>>>>>>> issue of the new function, so the current version of the patch does: >>>>>>>>>> >>>>>>>>>> 1. float_to_list/1 is backwards compatible. >>>>>>>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>>>>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>>>>>>> (with the optional compact option). >>>>>>>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>>>>>>> float_to_list(X) with the ability to control the number of decimals. >>>>>>>>>> >>>>>>>>>> The only item from Lucas's list that I left unchanged was the >>>>>>>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>>>>>>> advantage of the speed improvement of the new implementation. I am >>>>>>>>>> including a patch in this email that implements this logic, but I >>>>>>>>>> decided to leave the integration task to the OTP team since >>>>>>>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>>>>>>> library and I didn't want to introduce a dependency of it on other >>>>>>>>>> code >>>>>>>>>> - this should be decided by maintainers. >>>>>>>>>> >>>>>>>>>> The test cases of float_to_list/{1,2} have been updated. >>>>>>>>>> >>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>> >>>>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Serge >>>>>>>>>> >>>>>>>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>>>>>>> R16B. >>>>>>>>>>> >>>>>>>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>>>>>>> best >>>>>>>>>>> way to ensure that is to send an updated patch. >>>>>>>>>>> >>>>>>>>>>> Lukas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>>>>>>> I am certainly very happy to hear that you finally agreed to >>>>>>>>>>>> include >>>>>>>>>>>> this in the distribution. The changes proposed below seem >>>>>>>>>>>> reasonable >>>>>>>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>>>>>>> implement >>>>>>>>>>>> them? >>>>>>>>>>>> >>>>>>>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>>>>>>> Hello Serge! >>>>>>>>>>>>> >>>>>>>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>>>>>>> work. >>>>>>>>>>>>> >>>>>>>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>>>>>>> compatibility. >>>>>>>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>>>>>>> implementation >>>>>>>>>>>>> (with the optional compact option). >>>>>>>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>>>>>>> >>>>>>>>>>>>> We would also like the string rendering part of >>>>>>>>>>>>> sys_double_to_chars_fast >>>>>>>>>>>>> to be put into >>>>>>>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>>>>>>> way other parts of the vm which print floats will benefit from >>>>>>>>>>>>> your >>>>>>>>>>>>> changes! >>>>>>>>>>>>> >>>>>>>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>>>>>>> taking >>>>>>>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>>>>>>> ponderings just let me know. >>>>>>>>>>>>> >>>>>>>>>>>>> Lukas >>>>>>>>>>>>> >>>>>>>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>>>>>>> float_to_list_1 as well, is possible to do this and stay >>>>>>>>>>>>>>> backwards >>>>>>>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>>>>>>> e+XX at >>>>>>>>>>>>>>> the end of the optimized case and call sys_double_to_chars >>>>>>>>>>>>>>> for the >>>>>>>>>>>>>>> unoptimized. >>>>>>>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>>>>>>> questioning >>>>>>>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. >>>>>>>>>>>>>> However, I >>>>>>>>>>>>>> think >>>>>>>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>>>>>>> which >>>>>>>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>>>>>>> wrote >>>>>>>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>>>>>>> without a performance penalty. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>>>>>>> rounding >>>>>>>>>>>>>> involved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This case is easy: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>>>>>>> "1.01234000000000001762" >>>>>>>>>>>>>> >>>>>>>>>>>>>> This case is a bit more complex (illustration of rounding >>>>>>>>>>>>>> impact): >>>>>>>>>>>>>> >>>>>>>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>>>>>>> with how >>>>>>>>>>>>>>> other such APIs work. >>>>>>>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>>>>>>> request that >>>>>>>>>>>>>> the default number of decimals is chosen to be consistent with >>>>>>>>>>>>>> what >>>>>>>>>>>>>> printf() does, so I changed the implementation to accommodate >>>>>>>>>>>>>> that >>>>>>>>>>>>>> request: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>>>>>>> "1.000000" >>>>>>>>>>>>>> >>>>>>>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2> float_to_list(1.0). >>>>>>>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>>>>>>> float_to_list/2, to >>>>>>>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Serge >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>>>>>>> Henrik, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fetch: git fetch >>>>>>>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>>>>>>> happy: >>>>>>>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>>>>>>> suites >>>>>>>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>>>>>>> tried the >>>>>>>>>>>>>>>> following but all tests fail: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>>>>>>> test_server_ctrl >>>>>>>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>>>>>>> sure my >>>>>>>>>>>>>>>> patch didn't break anything. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Serge >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>>>>>>> Hi again. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No type information: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> 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 >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > From n.oxyde@REDACTED Sat Jan 19 12:15:24 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 19 Jan 2013 12:15:24 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50F9516A.3080109@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> Message-ID: Hi, I've recreated the branch with two new commits, adding support of silent rules in wx and when running ./otp_build tests. Please refetch. Regards, -- Anthony Ramine Le 18 janv. 2013 ? 14:43, Bj?rn-Egil Dahlberg a ?crit : > Patch merged. > Closing issue designated OTP-10726. > > // Bj?rn-Egil > > On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: >> On 2013-01-15 21:46, Anthony Ramine wrote: >>> I couldn't reproduce the bug here but apparently I've found the cause of it. >> Looking good. >> >> Putting it into master-opu integration branch. >> >> Will be merged later this week if no other issues appear. >> >> // Bj?rn-Egil >> >>> >>> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): >>> >>>> Using the MAKE variable has the same effect as using a ?+? character >>>> at the beginning of the recipe line. See Instead of Executing the >>>> Recipes. This special feature is only enabled if the MAKE variable >>>> appears directly in the recipe: it does not apply if the MAKE variable >>>> is referenced through expansion of another variable. In the latter >>>> case you must use the ?+? token to get these special effects. >>> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable >>> >>> Please refetch. >>> >>> Regards, >>> >> >> _______________________________________________ >> 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 Sat Jan 19 17:29:21 2013 From: mononcqc@REDACTED (Fred Hebert) Date: Sat, 19 Jan 2013 11:29:21 -0500 Subject: [erlang-patches] Shell history search In-Reply-To: References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> <50EBEFC0.7040101@erlang.org> <20130108124936.GA25258@ferdmbp.local> <50EC19C7.90507@erlang.org> Message-ID: <20130119162920.GA8314@ferdmbp.local> I just pushed a fix. Due to the issues explained, the shell can now be quitted using double-escape (). The problem is pushed a level deeper: followed by a meta sequence (like an arrow key) will still mess things up slightly (the prompt gets messed up, but it self-repairs afterwards, and the bad entry is a term, not a quote). I've also made it so followed by any other character (letter or digit) quits the search mode too, to avoid confusion if people forget about double-escaping. I've also fixed the works with ssh_cli. Turns out the C driver appears to be fine taking a length of the wrong sign and fixing it for you, but ssh_cli would crash on it. The sign has been fixed. Let me know if that's good enough. Regards, Fred. On 01/18, Dan Gudmundsson wrote: > Switched to correct patch/thread. > > On Fri, Jan 18, 2013 at 3:22 PM, Fred Hebert wrote: > > Hi Dan, > > In any case, the use of 'Esc' is ambiguous to exit search because the > > character used in the escape sequence is the same one used while using > > meta (\e if I recall). Because the shell handles things in a > > character-per-character basis, there is no way for me to know whether > > I'm looking at a meta sequence or if I'm getting 'Esc' on its own. > > > > Supporting 'Esc' to escape search then means that I may leave garbage in > > the line when what I get is actually a meta sequence. > > If you can not find a better solution then my initial reaction is to > not support meta seq, jump out of search and display the garbage > because this confused me and will confuse others. > > Can you not catch it higher up, i.e. in edit/5 > case key_map(C, Prefix) of > search_meta when CS =:= [] -> search_quit(). > > /Dan > > > Not sure how to work around this one. > > > > Regards, > > Fred. > > > > On Tue, Jan 8, 2013 at 2:06 PM, Fredrik wrote: > > Great, > > I have re-fetched and building it in master-pu branch now. > > Thanks! > > > > > > BR Fredrik Gustafsson > > Erlang OTP Team > > On 01/08/2013 01:49 PM, Fred Hebert wrote: > >> > >> Hi Fredrik, > >> > >> It's done. From my understanding of the code, I simply needed to pass in > >> the encoding to the prompt_bytes/2 functions, and it seems to work fine. > >> > >> Regards, > >> Fred. > >> > >> On 01/08, Fredrik wrote: > >>> > >>> Hello Fred, > >>> You need to rebase upon 'master' branch and make changes to your > >>> patch, it fails to build on > >>> 'group.erl:536: function prompt_bytes/1 undefined' > >>> > >>> Let me know when you are done, > >>> > >>> BR Fredrik Gustafsson > >>> Erlang OTP Team > >>> On 01/04/2013 09:07 AM, Fredrik wrote: > >>>> > >>>> Hello Fred, > >>>> Must have missed to reply to you, your patch has been in > >>>> 'master-pu' branch since wednesday. > >>>> Thanks for your contribution. > >>>> > >>>> BR Fredrik Gustafsson > >>>> Erlang OTP Team > >>>> On 12/22/2012 11:41 PM, Fred Hebert wrote: > >>>>> > >>>>> Hi, the following patch adds functionality to group.erl and edlin.erl > >>>>> in > >>>>> order to allow the user to search history. > >>>>> > >>>>> Search mode can be entered by pressing ctrl-r. Enter terms and press > >>>>> ctrl-r again to search backwards, or ctrl-s to then search forward (if > >>>>> you terminal doesn't eat up that one). Press enter to execute the line, > >>>>> or use tab, arrow keys, or other control sequences (^D, ^K, etc.) to > >>>>> exit search mode while remaining on the last found line. > >>>>> > >>>>> The search mode is a simpler version of the one available in bash or > >>>>> zsh shells. > >>>>> > >>>>> This adds a few modes to the shell (search, on top of none and meta) in > >>>>> group.erl for history search, and a few more in edlin.erl to change the > >>>>> meaning of control sequences while searching. > >>>>> > >>>>> This patch has been tested on OSX and some linux variants and worked > >>>>> fine. > >>>>> I tested it on Windows, and neither do werl.exe, or erl.exe (under > >>>>> PowerShell or cmd.exe) capture the ^R and ^S sequences -- it will not > >>>>> work there, but will not break any existing functionality. As far as > >>>>> I'm > >>>>> aware, this is more likely a driver issue than an issue with the patch > >>>>> (^G is not captured in cmd.exe, ctrl+C works in none of the above, for > >>>>> example). > >>>>> > >>>>> git fetch git://github.com/ferd/otp.git shell_history_search > >>>>> > >>>>> Compare at: > >>>>> > >>>>> > >>>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search > >>>>> > >>>>> > >>>>> https://github.com/ferd/otp/compare/erlang:master...ferd:shell_history_search.patch > >>>>> > >>>>> > >>>>> Regards, > >>>>> Fred. > >>>>> _______________________________________________ > >>>>> 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 egil@REDACTED Mon Jan 21 11:29:25 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 21 Jan 2013 11:29:25 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50F97776.80207@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <4D2DE13E.7040404@aleynikov.org> <4D33B762.3080202@aleynikov.org> <4D90ABBD.8050100@erix.ericsson.se> <4F58F46A.5050701@aleynikov.org> <4F5F52FE.7060003@erlang.org> <4F5F8097.5060003@erix.ericsson.se> <4F8EE138.60402@aleynikov.org> <4F9129B5.6020304@erlang.org> <4F924348.6070400@aleynikov.org> <4FBDFCB2.2050402@erlang.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F96344.9040504@erla ng.org> <50F97776.80207@aleynik! ov.org> Message-ID: <50FD1885.2070905@erlang.org> Refetching your branch and adding it to master-opu. On 2013-01-18 17:25, Serge Aleynikov wrote: > This is not intended. > > In both cases the issue is that the buffer used for formatting the > numbers is fixed to 256 bytes. > > So essentially in case of {scientific, Decimals} option the C call looks > like this: > > erts_snprintf(buffer, buffer_size, "%.*e", decimals, n) > > In case of {decimals, Decimals} option, when Decimals exceeds the buffer > size, the call defaults to: > > erts_snprintf(buffer, buffer_size-1, "%.*f", Decimals, n); > > The question is what should be the function's behavior when the Decimals > value is (too) large? Throw badarg? Reduce it to a set maximum? I > think that documenting a max limit and throwing badarg would be the > right approach. > > Thoughts? > > On 1/18/2013 9:59 AM, Bj?rn-Egil Dahlberg wrote: >> In review .. again =) >> >> I think we have covered default behaviours. >> >> Is the following intended behaviour? =) >> >> 1> erlang:float_to_list(3/7, [{decimals, 314}, >> compact]). >> [48,46,52,50,56,53,55,49,52,50,56,53,55,49,52,50,56,53,52, >> 55,54,51,56,48,55,56,48,52,51|...] >> >> 2> erlang:float_to_list(3/7, [{scientific, 314}, compact]). >> "4.2857142857142854763807804374664556235074996948242187500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" >> >> ? >> >> // Bj?rn-Egil >> >> On 2013-01-14 10:10, Fredrik wrote: >>> Hello, >>> This testcase is failing: >>> Suite: bif_SUITE >>> Testcase: specs >>> Reason: >>> The following BIFs don't have specs: >>> >>> erlang:float_to_list/2 >>> Give me notice when this is done, >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> On 01/11/2013 04:55 PM, Serge Aleynikov wrote: >>>> Sorry the test case line was the "last moment" add on. It is fixed now >>>> in my branch below. >>>> >>>> On 1/11/2013 10:44 AM, Fredrik wrote: >>>>> Hey, >>>>> Your patch does not build: >>>>> " >>>>> >>>>> emulator_test ../emulator_test/num_bif_SUITE.erl:130: illegal pattern >>>>> " >>>>> >>>>> >>>>> Please have a look at it, and give me notice when you are done. >>>>> >>>>> BR Fredrik Gustafsson >>>>> Erlang OTP Team >>>>> On 01/11/2013 03:11 PM, Serge Aleynikov wrote: >>>>>> Ok. Here's the patch rebased to master: >>>>>> >>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>> >>>>>> https://github.com/saleyn/otp/compare/master...float_to_list_2 >>>>>> https://github.com/saleyn/otp/compare/master...float_to_list_2.patch >>>>>> >>>>>> Regards, >>>>>> >>>>>> Serge >>>>>> >>>>>> On 1/11/2013 8:53 AM, Bj?rn-Egil Dahlberg wrote: >>>>>>> On 2013-01-11 14:24, Serge Aleynikov wrote: >>>>>>>> While looking at this I see that the code in folder >>>>>>>> "erts/emulator/sys/vxworks" is present in maint but missing in the >>>>>>>> master branch. Is this intentional? If so, should I remove the >>>>>>>> part of >>>>>>>> the patch designed for vxworks? >>>>>>> Yes. Any and all vxworks support has been removed in R16 from OTP except >>>>>>> for epmd, erl_interface and ic. >>>>>>> >>>>>>> // Bj?rn-Egil >>>>>>>> On 1/11/2013 3:52 AM, Fredrik wrote: >>>>>>>>> Hey, >>>>>>>>> Could you please rebase this on current 'master' branch? >>>>>>>>> >>>>>>>>> BR Fredrik Gustafsson >>>>>>>>> Erlang OTP Team >>>>>>>>> On 01/11/2013 04:06 AM, Serge Aleynikov wrote: >>>>>>>>>> I implemented Lukas's recommendations that were presenting an >>>>>>>>>> acceptance >>>>>>>>>> issue of the new function, so the current version of the patch does: >>>>>>>>>> >>>>>>>>>> 1. float_to_list/1 is backwards compatible. >>>>>>>>>> 2. float_to_list(X,[]) gives the same result as float_to_list(X). >>>>>>>>>> 3. float_to_list(X,[{decimals,N}]) uses the new fast implementation >>>>>>>>>> (with the optional compact option). >>>>>>>>>> 4. float_to_list(X,[{scientific,M}]) gives the same result as >>>>>>>>>> float_to_list(X) with the ability to control the number of decimals. >>>>>>>>>> >>>>>>>>>> The only item from Lucas's list that I left unchanged was the >>>>>>>>>> modification to erts/lib_src/common/erl_printf_format.c to take >>>>>>>>>> advantage of the speed improvement of the new implementation. I am >>>>>>>>>> including a patch in this email that implements this logic, but I >>>>>>>>>> decided to leave the integration task to the OTP team since >>>>>>>>>> erl_printf_format.c is actually compiled into a liberts_internal.a >>>>>>>>>> library and I didn't want to introduce a dependency of it on other >>>>>>>>>> code >>>>>>>>>> - this should be decided by maintainers. >>>>>>>>>> >>>>>>>>>> The test cases of float_to_list/{1,2} have been updated. >>>>>>>>>> >>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>> >>>>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2 >>>>>>>>>> https://github.com/saleyn/otp/compare/maint...float_to_list_2.patch >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Serge >>>>>>>>>> >>>>>>>>>> On 8/23/2012 5:10 AM, Lukas Larsson wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'll put it in the backlog and we'll see if it gets prioritized for >>>>>>>>>>> R16B. >>>>>>>>>>> >>>>>>>>>>> As always if you (or someone else) wants make sure it gets in, the >>>>>>>>>>> best >>>>>>>>>>> way to ensure that is to send an updated patch. >>>>>>>>>>> >>>>>>>>>>> Lukas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22/08/12 21:17, Serge Aleynikov wrote: >>>>>>>>>>>> I am certainly very happy to hear that you finally agreed to >>>>>>>>>>>> include >>>>>>>>>>>> this in the distribution. The changes proposed below seem >>>>>>>>>>>> reasonable >>>>>>>>>>>> and simple. Will the OTP team be able to modify my patch to >>>>>>>>>>>> implement >>>>>>>>>>>> them? >>>>>>>>>>>> >>>>>>>>>>>> On 8/22/2012 12:01 PM, Lukas Larsson wrote: >>>>>>>>>>>>> Hello Serge! >>>>>>>>>>>>> >>>>>>>>>>>>> I think we have finally agreed how we want this functionality to >>>>>>>>>>>>> work. >>>>>>>>>>>>> >>>>>>>>>>>>> float_to_list/1 should be left as it is now for backwards >>>>>>>>>>>>> compatibility. >>>>>>>>>>>>> float_to_list(1.0,[]) should give the same as float_to_list(1.0). >>>>>>>>>>>>> float_to_list(1.0,[{decimals,X}]) should use your faster >>>>>>>>>>>>> implementation >>>>>>>>>>>>> (with the optional compact option). >>>>>>>>>>>>> float_to_list(1.0,[{scientific,Y}]) should give the same as >>>>>>>>>>>>> float_to_list(1.0) if Y is 20. >>>>>>>>>>>>> >>>>>>>>>>>>> We would also like the string rendering part of >>>>>>>>>>>>> sys_double_to_chars_fast >>>>>>>>>>>>> to be put into >>>>>>>>>>>>> erts/lib_src/common/erl_printf_format.c:fmt_double. This >>>>>>>>>>>>> way other parts of the vm which print floats will benefit from >>>>>>>>>>>>> your >>>>>>>>>>>>> changes! >>>>>>>>>>>>> >>>>>>>>>>>>> I hope our indecisiveness have not caused you to shy away from >>>>>>>>>>>>> taking >>>>>>>>>>>>> this feature into Erlang/OTP. If you have any further questions or >>>>>>>>>>>>> ponderings just let me know. >>>>>>>>>>>>> >>>>>>>>>>>>> Lukas >>>>>>>>>>>>> >>>>>>>>>>>>> On 18/07/12 20:47, Serge Aleynikov wrote: >>>>>>>>>>>>>> On 7/18/2012 5:18 AM, Lukas Larsson wrote: >>>>>>>>>>>>>>> However, I would also like the fast functionality to be used by >>>>>>>>>>>>>>> float_to_list_1 as well, is possible to do this and stay >>>>>>>>>>>>>>> backwards >>>>>>>>>>>>>>> compatible? Hopefully you just have to shift the comma and add >>>>>>>>>>>>>>> e+XX at >>>>>>>>>>>>>>> the end of the optimized case and call sys_double_to_chars >>>>>>>>>>>>>>> for the >>>>>>>>>>>>>>> unoptimized. >>>>>>>>>>>>>> See my comments below regarding 'scientific' option. Since >>>>>>>>>>>>>> float_to_list_2 is a new function I would think that you are >>>>>>>>>>>>>> questioning >>>>>>>>>>>>>> the issue of backward compatibility only in terms of converting >>>>>>>>>>>>>> float_to_list_1 to use float_to_list_2 implementation. >>>>>>>>>>>>>> However, I >>>>>>>>>>>>>> think >>>>>>>>>>>>>> that this will have adverse performance tax on float_to_list_2, >>>>>>>>>>>>>> which >>>>>>>>>>>>>> will diminish the benefit. It's been a while however, since I >>>>>>>>>>>>>> wrote >>>>>>>>>>>>>> that patch, perhaps there's a way to retrofit scientific notation >>>>>>>>>>>>>> without a performance penalty. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's more than simple shifting of the comma, since there's also >>>>>>>>>>>>>> rounding >>>>>>>>>>>>>> involved. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This case is easy: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4> float_to_list(1.01234). >>>>>>>>>>>>>> "1.01234000000000001762e+00" >>>>>>>>>>>>>> 5> float_to_list(1.01234, [{decimals, 20}]). >>>>>>>>>>>>>> "1.01234000000000001762" >>>>>>>>>>>>>> >>>>>>>>>>>>>> This case is a bit more complex (illustration of rounding >>>>>>>>>>>>>> impact): >>>>>>>>>>>>>> >>>>>>>>>>>>>> 7> float_to_list(10123412345.0123451234). >>>>>>>>>>>>>> "1.01234123450123443604e+10" >>>>>>>>>>>>>> 8> float_to_list(10123412345.0123451234, [{decimals, 20}]). >>>>>>>>>>>>>> "10123412345.01234436035156250000" >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also float_to_list(1.0) should return the same thing as >>>>>>>>>>>>>>> float_to_list(1.0,[]), otherwise the API will be inconsistent >>>>>>>>>>>>>>> with how >>>>>>>>>>>>>>> other such APIs work. >>>>>>>>>>>>>> Actually if you trace this subject back there was another >>>>>>>>>>>>>> request that >>>>>>>>>>>>>> the default number of decimals is chosen to be consistent with >>>>>>>>>>>>>> what >>>>>>>>>>>>>> printf() does, so I changed the implementation to accommodate >>>>>>>>>>>>>> that >>>>>>>>>>>>>> request: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Eshell V5.9 (abort with ^G) >>>>>>>>>>>>>> 1> float_to_list(1.0, []). >>>>>>>>>>>>>> "1.000000" >>>>>>>>>>>>>> >>>>>>>>>>>>>> Which is different from the default of float_to_list/1: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2> float_to_list(1.0). >>>>>>>>>>>>>> "1.00000000000000000000e+00" >>>>>>>>>>>>>> >>>>>>>>>>>>>> Maybe one could introduce a 'scientific' option to >>>>>>>>>>>>>> float_to_list/2, to >>>>>>>>>>>>>> use the float_to_list/1 implementation? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Serge >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 24/05/12 16:02, Serge Aleynikov wrote: >>>>>>>>>>>>>>>> Henrik, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Fetch: git fetch >>>>>>>>>>>>>>>> https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>>>> Diff: https://github.com/saleyn/otp/compare/float_to_list_2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I added the definition for the new BIF to make the type checker >>>>>>>>>>>>>>>> happy: >>>>>>>>>>>>>>>> https://github.com/saleyn/otp/commit/f9ddbeda5426ca83cda03c06a9860220ea4a22c7 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Once you do the "otp_build tests", how do you execute all tests >>>>>>>>>>>>>>>> suites >>>>>>>>>>>>>>>> in $ERL_TOP or if possible only tests in a given SUITE? I >>>>>>>>>>>>>>>> tried the >>>>>>>>>>>>>>>> following but all tests fail: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [otp/erts/emulator/test]$ ../../../bin/erl -noshell -s >>>>>>>>>>>>>>>> test_server_ctrl >>>>>>>>>>>>>>>> run_test DIR "." -s erlang halt >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I did however run individual tests in bif_SUIT:types to make >>>>>>>>>>>>>>>> sure my >>>>>>>>>>>>>>>> patch didn't break anything. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Serge >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 5/24/2012 5:17 AM, Henrik Nord wrote: >>>>>>>>>>>>>>>>> Hi again. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This test is not passing: emulator/bif_SUIT:types >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No type information: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [{erlang,float_to_list,2}] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 04/21/2012 07:19 AM, Serge Aleynikov wrote: >>>>>>>>>>>>>>>>>> git fetch https://github.com/saleyn/otp/tree/float_to_list_2 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> 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 >> >> >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches >> > From fredrik@REDACTED Mon Jan 21 11:31:59 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 21 Jan 2013 11:31:59 +0100 Subject: [erlang-patches] Shell history search In-Reply-To: <20130119162920.GA8314@ferdmbp.local> References: <20121222224128.GA941@ferdmbp.local> <50E68DDA.7080803@erlang.org> <50EBEFC0.7040101@erlang.org> <20130108124936.GA25258@ferdmbp.local> <50EC19C7.90507@erlang.org> <20130119162920.GA8314@ferdmbp.local> Message-ID: <50FD191F.6070005@erlang.org> Re-fetched. Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/19/2013 05:29 PM, Fred Hebert wrote: > git fetch git://github.com/ferd/otp.git shell_history_search From fredrik@REDACTED Mon Jan 21 12:20:36 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 21 Jan 2013 12:20:36 +0100 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 In-Reply-To: References: <50ED49FC.8060106@erlang.org> Message-ID: <50FD2484.5000604@erlang.org> Hello again, Could you provide a testcase for this patch? BR Fredrik Gustafsson Erlang OTP Team On 01/11/2013 07:50 AM, Danil Onishchenko wrote: > Hello, Fredrik. > I rebased that patch on 'master' branch. The previous version was > based on 'maint'. > > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master > > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch > > 2013/1/9 Fredrik: >> Hello Kernel! >> Your patch is now cooking in the 'master-pu' branch. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> On 01/09/2013 10:29 AM, Kernel Panic wrote: >>> A little patch for odbc:param_query/3 and odbc:param_query/4. >>> >>> Issue: Calling odbc:param_query/3 and odbc:param_query/4 with >>> unparameterized query string and empty parameters list causes error in >>> pattern matching in function param_values/1. >>> >>> This patch fixes this problem and allow to do things such as >>> odbc:param_query(ConRef, "select * from some_table", []). >>> >>> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params >>> >>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params >>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> From fredrik@REDACTED Mon Jan 21 14:09:45 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 21 Jan 2013 14:09:45 +0100 Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <1636541866.231783.1358338828351.JavaMail.root@tpip.net> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <319046904.111229.1349952553937.JavaMail.root@tpip.net> <5076A530.7070709@erlang.org> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> <50F66C6C.8000108@erlang.org> <1636541866.231783.1358338828351.JavaMail.root@tpip.net> Message-ID: <50FD3E19.4050309@erlang.org> Hello, Could you rebase this patch upon the current 'master' branch? BR Fredrik Gustafsson Erlang OTP Team On 01/16/2013 01:20 PM, Andreas Schultz wrote: > Hi Fredrik, > > I just realized that I'm still using the ?line macro in the new SRP crypto test. > > Should I remove it? > > Andreas > > ----- Original Message ----- >> Thanks, >> I have re-fetched and building it now with the rest of the patches in >> the 'master-pu' branch. >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/15/2013 08:19 PM, Andreas Schultz wrote: >>> Hi, >>> >>> I have address the issues: >>> >>> * documentation for SSL API options added >>> * header files internalized >>> * crypto function generalized and support for multiple SRP variants >>> >>> New version can be found here: >>> >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>> >>> >>> Even if the PSK and SRP do not make it into R16, could you consider the >>> first two >>> changesets from this series, please? They are mostly code consolidations, >>> making >>> adding new key exchange algorithms much simpler. >>> >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch >>> >>> Andreas >>> >>> ----- Original Message ----- >>>> Hello Andreas, >>>> Your patch has finally been into review and the response was: >>>> " >>>> >>>> * The patch introduces new API options without documenting them. >>>> * The patch introduces new include file ssl_srp.hrl that I think shall >>>> be internal and put in src. It is undesirable to have records in the >>>> user API as it makes the user application compile time dependent on >>>> our code, better to use a proplist and then create the record >>>> internally. (Yes "sslsocket" is a record due to legacy) >>>> * The patch introduces new include file ssl_srp_primes.hrl I think it >>>> feels better to input such values as atoms and internaly uses the >>>> macros defined in this file, that would be more consistent with the >>>> rest of the API. >>>> * Functions in crypto being named TLS something seems a little >>>> strange, is this necessary?! >>>> >>>> " >>>> Please correct this and give me a notice when it is done. >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> On 10/12/2012 11:38 AM, Henrik Nord wrote: >>>>> refetching >>>>> >>>>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: >>>>>> Hi Henrik, >>>>>> >>>>>> When I rebased my changes to the current master, a change crept in that >>>>>> shouldn't have: >>>>>> >>>>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 >>>>>> >>>>>> >>>>>> I have removed it from my tree and pushed it. >>>>>> >>>>>> Andreas >>>>>> >>>>>> ----- Original Message ----- >>>>>>> Thanks, I will refetch! >>>>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have pushed a change that should fix the compile error. The >>>>>>>> buffer has >>>>>>>> a fixed length now. >>>>>>>> >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 >>>>>>>> >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch >>>>>>>> >>>>>>>> >>>>>>>> Andreas >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> Does not compile on Windows. >>>>>>>>> >>>>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with >>>>>>>>> dynamic >>>>>>>>> size is not supported by the C standard we use. >>>>>>>>> Use a static array instead, presuming that there is a reasonable >>>>>>>>> upper >>>>>>>>> limit of its size. >>>>>>>>> >>>>>>>>> /Sverker, Erlang/OTP >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Henrik Nord wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I have added your branch to 'master'pu' for testing. >>>>>>>>>> Thank you for your contribution! >>>>>>>>>> >>>>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Tree is rebased onto latest master. >>>>>>>>>>> >>>>>>>>>>> Andreas >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> Would you be so kind as to rebase this branch upon the latest >>>>>>>>>>>> 'master' >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your contribution! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC >>>>>>>>>>>>> 5487 >>>>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and >>>>>>>>>>>>> usefulness >>>>>>>>>>>>> of those ciphers is rather limited, the one notable exception >>>>>>>>>>>>> being >>>>>>>>>>>>> the eID server protocol for German national identity cards >>>>>>>>>>>>> (nPA). >>>>>>>>>>>>> >>>>>>>>>>>>> The test suite can only verify some PSK suites against openssl >>>>>>>>>>>>> as >>>>>>>>>>>>> currently no openssl version supports them all. There is patch >>>>>>>>>>>>> that add some to openssl, but it has not been incorporated >>>>>>>>>>>>> into >>>>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK >>>>>>>>>>>>> suites >>>>>>>>>>>>> and I have manually tested interoperability. >>>>>>>>>>>>> >>>>>>>>>>>>> Patch info: >>>>>>>>>>>>> >>>>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git >>>>>>>>>>>>> tls-psk-srp-suites >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards >>>>>>>>>>>>> Andreas >>>>>>>>>>>> -- >>>>>>>>>>>> /Henrik Nord Erlang/OTP >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> -- >>>>>>> /Henrik Nord Erlang/OTP >>>>>>> >>>>>>> >> From aschultz@REDACTED Mon Jan 21 14:16:24 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Mon, 21 Jan 2013 14:16:24 +0100 (CET) Subject: [erlang-patches] TLS: add PSK and SRP cipher suites In-Reply-To: <50FD3E19.4050309@erlang.org> References: <243075147.49636.1348679990473.JavaMail.root@tpip.net> <1804774539.132181.1350030426251.JavaMail.root@tpip.net> <5077E4FA.9060609@erlang.org> <50ED8DBD.8080305@erlang.org> <554152829.218007.1358277582556.JavaMail.root@tpip.net> <50F66C6C.8000108@erlang.org> <1636541866.231783.1358338828351.JavaMail.root@tpip.net> <50FD3E19.4050309@erlang.org> Message-ID: <397956462.337258.1358774184655.JavaMail.root@tpip.net> Hi, patch is rebased. Andreas ----- Original Message ----- > Hello, > Could you rebase this patch upon the current 'master' branch? > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/16/2013 01:20 PM, Andreas Schultz wrote: > > Hi Fredrik, > > > > I just realized that I'm still using the ?line macro in the new SRP crypto > > test. > > > > Should I remove it? > > > > Andreas > > > > ----- Original Message ----- > >> Thanks, > >> I have re-fetched and building it now with the rest of the patches in > >> the 'master-pu' branch. > >> > >> BR Fredrik Gustafsson > >> Erlang OTP Team > >> On 01/15/2013 08:19 PM, Andreas Schultz wrote: > >>> Hi, > >>> > >>> I have address the issues: > >>> > >>> * documentation for SSL API options added > >>> * header files internalized > >>> * crypto function generalized and support for multiple SRP variants > >>> > >>> New version can be found here: > >>> > >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>> > >>> > >>> Even if the PSK and SRP do not make it into R16, could you consider the > >>> first two > >>> changesets from this series, please? They are mostly code consolidations, > >>> making > >>> adding new key exchange algorithms much simpler. > >>> > >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a > >>> https://github.com/RoadRunnr/otp/compare/master...cf4512a.patch > >>> > >>> Andreas > >>> > >>> ----- Original Message ----- > >>>> Hello Andreas, > >>>> Your patch has finally been into review and the response was: > >>>> " > >>>> > >>>> * The patch introduces new API options without documenting them. > >>>> * The patch introduces new include file ssl_srp.hrl that I think > >>>> shall > >>>> be internal and put in src. It is undesirable to have records in > >>>> the > >>>> user API as it makes the user application compile time dependent > >>>> on > >>>> our code, better to use a proplist and then create the record > >>>> internally. (Yes "sslsocket" is a record due to legacy) > >>>> * The patch introduces new include file ssl_srp_primes.hrl I think > >>>> it > >>>> feels better to input such values as atoms and internaly uses the > >>>> macros defined in this file, that would be more consistent with > >>>> the > >>>> rest of the API. > >>>> * Functions in crypto being named TLS something seems a little > >>>> strange, is this necessary?! > >>>> > >>>> " > >>>> Please correct this and give me a notice when it is done. > >>>> > >>>> BR Fredrik Gustafsson > >>>> Erlang OTP Team > >>>> On 10/12/2012 11:38 AM, Henrik Nord wrote: > >>>>> refetching > >>>>> > >>>>> On 10/12/2012 10:27 AM, Andreas Schultz wrote: > >>>>>> Hi Henrik, > >>>>>> > >>>>>> When I rebased my changes to the current master, a change crept in > >>>>>> that > >>>>>> shouldn't have: > >>>>>> > >>>>>> https://github.com/erlang/otp/commit/747ce9191f4dc7558e12e2b6e5696396392ffbd8 > >>>>>> > >>>>>> > >>>>>> I have removed it from my tree and pushed it. > >>>>>> > >>>>>> Andreas > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> Thanks, I will refetch! > >>>>>>> On 10/11/2012 12:49 PM, Andreas Schultz wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I have pushed a change that should fix the compile error. The > >>>>>>>> buffer has > >>>>>>>> a fixed length now. > >>>>>>>> > >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2 > >>>>>>>> > >>>>>>>> https://github.com/RoadRunnr/otp/commit/ad73b09d948d0414132bfca2f67ff0de729fa7b2.patch > >>>>>>>> > >>>>>>>> > >>>>>>>> Andreas > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> Does not compile on Windows. > >>>>>>>>> > >>>>>>>>> Function SHA1_Update_PAD in crypto.c is not correct. Arrays with > >>>>>>>>> dynamic > >>>>>>>>> size is not supported by the C standard we use. > >>>>>>>>> Use a static array instead, presuming that there is a reasonable > >>>>>>>>> upper > >>>>>>>>> limit of its size. > >>>>>>>>> > >>>>>>>>> /Sverker, Erlang/OTP > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Henrik Nord wrote: > >>>>>>>>>> Hi > >>>>>>>>>> > >>>>>>>>>> I have added your branch to 'master'pu' for testing. > >>>>>>>>>> Thank you for your contribution! > >>>>>>>>>> > >>>>>>>>>> On 10/04/2012 06:29 PM, Andreas Schultz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Tree is rebased onto latest master. > >>>>>>>>>>> > >>>>>>>>>>> Andreas > >>>>>>>>>>> > >>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>> Would you be so kind as to rebase this branch upon the latest > >>>>>>>>>>>> 'master' > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you for your contribution! > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 09/26/2012 07:19 PM, Andreas Schultz wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have implemented the more interesting parts of RFC 4279, RFC > >>>>>>>>>>>>> 5487 > >>>>>>>>>>>>> and RFC 5054 (aka TLS PSK and SRP ciphers). The use and > >>>>>>>>>>>>> usefulness > >>>>>>>>>>>>> of those ciphers is rather limited, the one notable exception > >>>>>>>>>>>>> being > >>>>>>>>>>>>> the eID server protocol for German national identity cards > >>>>>>>>>>>>> (nPA). > >>>>>>>>>>>>> > >>>>>>>>>>>>> The test suite can only verify some PSK suites against openssl > >>>>>>>>>>>>> as > >>>>>>>>>>>>> currently no openssl version supports them all. There is patch > >>>>>>>>>>>>> that add some to openssl, but it has not been incorporated > >>>>>>>>>>>>> into > >>>>>>>>>>>>> upstream. GNU-TLS implements some more (but not all) PSK > >>>>>>>>>>>>> suites > >>>>>>>>>>>>> and I have manually tested interoperability. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Patch info: > >>>>>>>>>>>>> > >>>>>>>>>>>>> git fetch git://github.com/RoadRunnr/otp.git > >>>>>>>>>>>>> tls-psk-srp-suites > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://github.com/RoadRunnr/otp/compare/master...tls-psk-srp-suites.patch > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> Andreas > >>>>>>>>>>>> -- > >>>>>>>>>>>> /Henrik Nord Erlang/OTP > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> -- > >>>>>>> /Henrik Nord Erlang/OTP > >>>>>>> > >>>>>>> > >> > > -- -- 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 serge@REDACTED Mon Jan 21 15:42:02 2013 From: serge@REDACTED (Serge Aleynikov) Date: Mon, 21 Jan 2013 09:42:02 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50FD5102.80106@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <4FBE3F78.8050405@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F979F9.2070903@aleynikov.org> <50F97C40.9030303@erlang.org> <50FA0EB5.3060900@aleynikov.org> <50FCB35C.1030402@aleynikov.org> <50FD4D39.3000407@erlang.org> <50FD500D.7050002@aleynikov.org> <50FD5102.80106@erlang.org> Message-ID: <50FD53BA.2050209@aleynikov.org> Thanks for expediting this for the upcoming release! Just to make sure that Lukas suggestion doesn't go unnoticed - the only remaining point not included in the patch (that can be addressed in a later release) is taking advantage of the float formatting speedup in erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I addressed in the attached email earlier in this thread. On 1/21/2013 9:30 AM, Bj?rn-Egil Dahlberg wrote: > Great, I'll fetch and put into master-opu. > > Hopefully we have found all issues. *crossing fingers* >> For your convenience I repushed the change with this fix, that affected: >> >> bif.c >> erlang.xml (documented reference to badarg instead of internal_error) >> num_bif_SUITE.erl >> Commit message >> >> Serge >> >> On 1/21/2013 9:14 AM, Bj?rn-Egil Dahlberg wrote: >>> Ok, so regarding internal_error. >>> >>> It is clearly specially handled in the vm, and in the debug vm an >>> asserts checks for it *not* to be set, i.e.: >>> >>> Eshell V5.10 (abort with ^G) >>> 1> erlang:float_to_list(1.0e300, [{decimals, 1}]). >>> Assertion failed: Value != am_internal_error in beam/beam_emu.c, line >>> 5317 >>> Aborted (core dumped) >>> >>> >>> I asked Bj?rn and Patrik since they have been here the longest: >>> - "How is exception internal_error handled, and what is special about >>> it?" >>> - "The what now?" >>> >>> Anyhow, >>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | EXF_PANIC) >>> where EXF_PANIC means uncatchable. >>> >>> My take on it is, it is literally meant to be an internal error and >>> should not be recovered from. Thus those test cases will result in cores >>> in debug builds. Not great. More importantly, we can trigger this from >>> bad input. >>> >>> I'm sorry, but I have revert my previous statement and return BADARG >>> instead. >>> >>> I'll update the code and put it in master-opu. >>> >>> // egil >>> >>> On 2013-01-21 04:17, Serge Aleynikov wrote: >>>> On 1/19/2013 8:40 PM, Bj?rn-Egil Dahlberg wrote:> I don't think the >>>> 'compact' option is doing what is says. See the following: >>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]). >>>>> "2.3333" >>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]). >>>>> "2.333333" >>>>> >>>> Egil, >>>> >>>> I repushed the fix for this issue along with your recommendation to >>>> limit the range of Decimals. The only thing - the valid range is not >>>> 0..255, but 0..249, since we need to keep in mind that a properly >>>> formatted number includes "X." (minimally one digit before the decimal >>>> point) and "e+YY" (in case of scientific notation). >>>> >>>> We still could get internal_error, when the number is too large >>>> irrespective of the number of decimals: >>>> >>>> float_to_list(1.0e+300, [{decimals, 1}]). >>>> >>>> Here the number doesn't fit in the buffer irrespective of the tail >>>> after >>>> the decimal point. This brings me back to the question you raised >>>> earlier in the thread if 256 is indeed a good default for the buffer >>>> size or it needs to be increased. I still think it's good as when one >>>> deals with formatting such large numbers, he should use scientific >>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do just >>>> fine. >>>> >>>> Added appropriate test cases. >>>> >>>> While trying one test case, there's a weird issue that I don't >>>> understand (or maybe it's too late now and I am failing to see >>>> something >>>> silly). Why am I not able to catch the internal_error exception? >>>> >>>> This is expected: >>>> 7> (catch float_to_list(1.0, [{decimals, 250}])). >>>> {'EXIT',{badarg,[{erlang,float_to_list, >>>> [1.0,[{decimals,250}]], >>>> []}, >>>> ...} >>>> >>>> This is not expected. I should see the same >>>> {'EXIT', {internal_error, _}} result, no? >>>> >>>> 8> (catch float_to_list(1.0e300, [{decimals, 1}])). >>>> >>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 === >>>> Error in process <0.40.0> with exit value: >>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>> >>>> >>>> >>>> >>>> ** exception exit: internal_error >>>> in function float_to_list/2 >>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>> >>>> This doesn't catch the exception either: >>>> >>>> 9> try float_to_list(1.0e300, [{decimals, 1}]) catch _:W -> W end. >>>> >>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 === >>>> Error in process <0.45.0> with exit value: >>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>> >>>> >>>> >>>> >>>> ** exception exit: internal_error >>>> in function float_to_list/2 >>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>> >>>> Any idea why? Is there something special about internal_error? I >>>> wanted a simple test case, but it fails due to uncaught exception: >>>> >>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300, >>>> [{decimals, 1}])) >>>> >>>> Serge > -------------- next part -------------- An embedded message was scrubbed... From: Serge Aleynikov Subject: Re: [erlang-patches] new float_to_list/2 Date: Thu, 10 Jan 2013 22:06:47 -0500 Size: 9595 URL: From egil@REDACTED Tue Jan 22 11:08:01 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 22 Jan 2013 11:08:01 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50FD53BA.2050209@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <50067F49.4020206@erlang.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F979F9.2070903@aleynikov.org> <50F97C40.9030303@erlang.org> <50FA0EB5.3060900@aleynikov.org> <50FCB35C.1030402@aleynikov.org> <50FD4D39.3000407@erlang.org> <50FD500D.7050002@aleynikov.org> <50FD5102.80106@erlang.org> <50FD53BA.2050209@aleynikov.org> Message-ID: <50FE6501.7050102@erlang.org> Found an issue not caught in pu due to windows being down because of other issues in pu on windows. *** User 2013-01-21 22:53:27.711 *** num_bif_SUITE:t_float_to_list failed on line 126 Reason: {badmatch,"1.00000000000000000000e+000"} === Ended at 2013-01-21 22:53:27 === location [{num_bif_SUITE,t_float_to_list,126}, {test_server,ts_tc,1362}, {test_server,run_test_case_eval1,979}, {test_server,run_test_case_eval,928}] === reason = no match of right hand side value "1.00000000000000000000e+000" in function num_bif_SUITE:t_float_to_list/1 (num_bif_SUITE.erl, line 126) in call from test_server:ts_tc/3 (test_server.erl, line 1362) in call from test_server:run_test_case_eval1/6 (test_server.erl, line 979) in call from test_server:run_test_case_eval/9 (test_server.erl, line 928) 126: "1.00000000000000000000e+00" = float_to_list(1.0), <- this one This is on Windows XP. // Bj?rn-Egil On 2013-01-21 15:42, Serge Aleynikov wrote: > Thanks for expediting this for the upcoming release! > > Just to make sure that Lukas suggestion doesn't go unnoticed - the only > remaining point not included in the patch (that can be addressed in a > later release) is taking advantage of the float formatting speedup in > erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I > addressed in the attached email earlier in this thread. > > On 1/21/2013 9:30 AM, Bj?rn-Egil Dahlberg wrote: >> Great, I'll fetch and put into master-opu. >> >> Hopefully we have found all issues. *crossing fingers* >>> For your convenience I repushed the change with this fix, that affected: >>> >>> bif.c >>> erlang.xml (documented reference to badarg instead of internal_error) >>> num_bif_SUITE.erl >>> Commit message >>> >>> Serge >>> >>> On 1/21/2013 9:14 AM, Bj?rn-Egil Dahlberg wrote: >>>> Ok, so regarding internal_error. >>>> >>>> It is clearly specially handled in the vm, and in the debug vm an >>>> asserts checks for it *not* to be set, i.e.: >>>> >>>> Eshell V5.10 (abort with ^G) >>>> 1> erlang:float_to_list(1.0e300, [{decimals, 1}]). >>>> Assertion failed: Value != am_internal_error in beam/beam_emu.c, line >>>> 5317 >>>> Aborted (core dumped) >>>> >>>> >>>> I asked Bj?rn and Patrik since they have been here the longest: >>>> - "How is exception internal_error handled, and what is special about >>>> it?" >>>> - "The what now?" >>>> >>>> Anyhow, >>>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | EXF_PANIC) >>>> where EXF_PANIC means uncatchable. >>>> >>>> My take on it is, it is literally meant to be an internal error and >>>> should not be recovered from. Thus those test cases will result in cores >>>> in debug builds. Not great. More importantly, we can trigger this from >>>> bad input. >>>> >>>> I'm sorry, but I have revert my previous statement and return BADARG >>>> instead. >>>> >>>> I'll update the code and put it in master-opu. >>>> >>>> // egil >>>> >>>> On 2013-01-21 04:17, Serge Aleynikov wrote: >>>>> On 1/19/2013 8:40 PM, Bj?rn-Egil Dahlberg wrote:> I don't think the >>>>> 'compact' option is doing what is says. See the following: >>>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]). >>>>>> "2.3333" >>>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]). >>>>>> "2.333333" >>>>>> >>>>> Egil, >>>>> >>>>> I repushed the fix for this issue along with your recommendation to >>>>> limit the range of Decimals. The only thing - the valid range is not >>>>> 0..255, but 0..249, since we need to keep in mind that a properly >>>>> formatted number includes "X." (minimally one digit before the decimal >>>>> point) and "e+YY" (in case of scientific notation). >>>>> >>>>> We still could get internal_error, when the number is too large >>>>> irrespective of the number of decimals: >>>>> >>>>> float_to_list(1.0e+300, [{decimals, 1}]). >>>>> >>>>> Here the number doesn't fit in the buffer irrespective of the tail >>>>> after >>>>> the decimal point. This brings me back to the question you raised >>>>> earlier in the thread if 256 is indeed a good default for the buffer >>>>> size or it needs to be increased. I still think it's good as when one >>>>> deals with formatting such large numbers, he should use scientific >>>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do just >>>>> fine. >>>>> >>>>> Added appropriate test cases. >>>>> >>>>> While trying one test case, there's a weird issue that I don't >>>>> understand (or maybe it's too late now and I am failing to see >>>>> something >>>>> silly). Why am I not able to catch the internal_error exception? >>>>> >>>>> This is expected: >>>>> 7> (catch float_to_list(1.0, [{decimals, 250}])). >>>>> {'EXIT',{badarg,[{erlang,float_to_list, >>>>> [1.0,[{decimals,250}]], >>>>> []}, >>>>> ...} >>>>> >>>>> This is not expected. I should see the same >>>>> {'EXIT', {internal_error, _}} result, no? >>>>> >>>>> 8> (catch float_to_list(1.0e300, [{decimals, 1}])). >>>>> >>>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 === >>>>> Error in process <0.40.0> with exit value: >>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>> >>>>> >>>>> >>>>> >>>>> ** exception exit: internal_error >>>>> in function float_to_list/2 >>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>> >>>>> This doesn't catch the exception either: >>>>> >>>>> 9> try float_to_list(1.0e300, [{decimals, 1}]) catch _:W -> W end. >>>>> >>>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 === >>>>> Error in process <0.45.0> with exit value: >>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>> >>>>> >>>>> >>>>> >>>>> ** exception exit: internal_error >>>>> in function float_to_list/2 >>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>> >>>>> Any idea why? Is there something special about internal_error? I >>>>> wanted a simple test case, but it fails due to uncaught exception: >>>>> >>>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300, >>>>> [{decimals, 1}])) >>>>> >>>>> Serge From egil@REDACTED Tue Jan 22 11:37:49 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 22 Jan 2013 11:37:49 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50FE6501.7050102@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <500704BE.1090709@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F979F9.2070903@aleynikov.org> <50F97C40.9030303@erlang.org> <50FA0EB5.3060900@aleynikov.org> <50FCB35C.1030402@aleynikov.org> <50FD4D39.3000407@erlang.org> <50FD500D.7050002@aleynikov.org> <50FD5102.80106@erlang.org> <50FD53BA.2050209@aleynikov.org> <50FE6501.7050102@erlang.org> Message-ID: <50FE6BFD.3090900@erlang.org> Heh, so this is not your fault =) R15B03 has this behaviour, R13B has this behaviour as well. Your new testcase is too strict. // Bj?rn-Egil On 2013-01-22 11:08, Bj?rn-Egil Dahlberg wrote: > Found an issue not caught in pu due to windows being down because of > other issues in pu on windows. > > > *** User 2013-01-21 22:53:27.711 *** > num_bif_SUITE:t_float_to_list failed on line 126 > Reason: {badmatch,"1.00000000000000000000e+000"} > > > > > === Ended at 2013-01-21 22:53:27 > === location [{num_bif_SUITE,t_float_to_list,126}, > {test_server,ts_tc,1362}, > {test_server,run_test_case_eval1,979}, > {test_server,run_test_case_eval,928}] > === reason = no match of right hand side value > "1.00000000000000000000e+000" > in function num_bif_SUITE:t_float_to_list/1 (num_bif_SUITE.erl, > line 126) > in call from test_server:ts_tc/3 (test_server.erl, line 1362) > in call from test_server:run_test_case_eval1/6 (test_server.erl, > line 979) > in call from test_server:run_test_case_eval/9 (test_server.erl, line > 928) > > > 126: "1.00000000000000000000e+00" = float_to_list(1.0), <- this > one > > This is on Windows XP. > > // Bj?rn-Egil > > > On 2013-01-21 15:42, Serge Aleynikov wrote: >> Thanks for expediting this for the upcoming release! >> >> Just to make sure that Lukas suggestion doesn't go unnoticed - the only >> remaining point not included in the patch (that can be addressed in a >> later release) is taking advantage of the float formatting speedup in >> erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I >> addressed in the attached email earlier in this thread. >> >> On 1/21/2013 9:30 AM, Bj?rn-Egil Dahlberg wrote: >>> Great, I'll fetch and put into master-opu. >>> >>> Hopefully we have found all issues. *crossing fingers* >>>> For your convenience I repushed the change with this fix, that >>>> affected: >>>> >>>> bif.c >>>> erlang.xml (documented reference to badarg instead of internal_error) >>>> num_bif_SUITE.erl >>>> Commit message >>>> >>>> Serge >>>> >>>> On 1/21/2013 9:14 AM, Bj?rn-Egil Dahlberg wrote: >>>>> Ok, so regarding internal_error. >>>>> >>>>> It is clearly specially handled in the vm, and in the debug vm an >>>>> asserts checks for it *not* to be set, i.e.: >>>>> >>>>> Eshell V5.10 (abort with ^G) >>>>> 1> erlang:float_to_list(1.0e300, [{decimals, 1}]). >>>>> Assertion failed: Value != am_internal_error in beam/beam_emu.c, line >>>>> 5317 >>>>> Aborted (core dumped) >>>>> >>>>> >>>>> I asked Bj?rn and Patrik since they have been here the longest: >>>>> - "How is exception internal_error handled, and what is special about >>>>> it?" >>>>> - "The what now?" >>>>> >>>>> Anyhow, >>>>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | EXF_PANIC) >>>>> where EXF_PANIC means uncatchable. >>>>> >>>>> My take on it is, it is literally meant to be an internal error and >>>>> should not be recovered from. Thus those test cases will result in >>>>> cores >>>>> in debug builds. Not great. More importantly, we can trigger this >>>>> from >>>>> bad input. >>>>> >>>>> I'm sorry, but I have revert my previous statement and return BADARG >>>>> instead. >>>>> >>>>> I'll update the code and put it in master-opu. >>>>> >>>>> // egil >>>>> >>>>> On 2013-01-21 04:17, Serge Aleynikov wrote: >>>>>> On 1/19/2013 8:40 PM, Bj?rn-Egil Dahlberg wrote:> I don't think the >>>>>> 'compact' option is doing what is says. See the following: >>>>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]). >>>>>>> "2.3333" >>>>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]). >>>>>>> "2.333333" >>>>>>> >>>>>> Egil, >>>>>> >>>>>> I repushed the fix for this issue along with your recommendation to >>>>>> limit the range of Decimals. The only thing - the valid range is >>>>>> not >>>>>> 0..255, but 0..249, since we need to keep in mind that a properly >>>>>> formatted number includes "X." (minimally one digit before the >>>>>> decimal >>>>>> point) and "e+YY" (in case of scientific notation). >>>>>> >>>>>> We still could get internal_error, when the number is too large >>>>>> irrespective of the number of decimals: >>>>>> >>>>>> float_to_list(1.0e+300, [{decimals, 1}]). >>>>>> >>>>>> Here the number doesn't fit in the buffer irrespective of the tail >>>>>> after >>>>>> the decimal point. This brings me back to the question you raised >>>>>> earlier in the thread if 256 is indeed a good default for the buffer >>>>>> size or it needs to be increased. I still think it's good as >>>>>> when one >>>>>> deals with formatting such large numbers, he should use scientific >>>>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do >>>>>> just >>>>>> fine. >>>>>> >>>>>> Added appropriate test cases. >>>>>> >>>>>> While trying one test case, there's a weird issue that I don't >>>>>> understand (or maybe it's too late now and I am failing to see >>>>>> something >>>>>> silly). Why am I not able to catch the internal_error exception? >>>>>> >>>>>> This is expected: >>>>>> 7> (catch float_to_list(1.0, [{decimals, 250}])). >>>>>> {'EXIT',{badarg,[{erlang,float_to_list, >>>>>> [1.0,[{decimals,250}]], >>>>>> []}, >>>>>> ...} >>>>>> >>>>>> This is not expected. I should see the same >>>>>> {'EXIT', {internal_error, _}} result, no? >>>>>> >>>>>> 8> (catch float_to_list(1.0e300, [{decimals, 1}])). >>>>>> >>>>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 === >>>>>> Error in process <0.40.0> with exit value: >>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ** exception exit: internal_error >>>>>> in function float_to_list/2 >>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>> >>>>>> This doesn't catch the exception either: >>>>>> >>>>>> 9> try float_to_list(1.0e300, [{decimals, 1}]) catch _:W -> W end. >>>>>> >>>>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 === >>>>>> Error in process <0.45.0> with exit value: >>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ** exception exit: internal_error >>>>>> in function float_to_list/2 >>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>> >>>>>> Any idea why? Is there something special about internal_error? I >>>>>> wanted a simple test case, but it fails due to uncaught exception: >>>>>> >>>>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300, >>>>>> [{decimals, 1}])) >>>>>> >>>>>> Serge > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From serge@REDACTED Tue Jan 22 15:04:05 2013 From: serge@REDACTED (Serge Aleynikov) Date: Tue, 22 Jan 2013 09:04:05 -0500 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50FE6BFD.3090900@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <50350268.8080704@erlang.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F979F9.2070903@aleynikov.org> <50F97C40.9030303@erlang.org> <50FA0EB5.3060900@aleynikov.org> <50FCB35C.1030402@aleynikov.org> <50FD4D39.3000407@erlang.org> <50FD500D.7050002@aleynikov.org> <50FD5102.80106@erlang.org> <50FD53BA.2050209@aleynikov.org> <50FE6501.7050102@erlang.org> <50FE6BFD.3090900@erlang.org> Message-ID: <50FE9C55.4080304@aleynikov.org> So erts_snprintf formats floats slightly differently on windows? Would you like me I adjust the test cases (there are 6 of them that would need to be made less strict) and repush or you can do it on your end? On 1/22/2013 5:37 AM, Bj?rn-Egil Dahlberg wrote: > Heh, so this is not your fault =) > > R15B03 has this behaviour, > R13B has this behaviour as well. > > Your new testcase is too strict. > > // Bj?rn-Egil > > > On 2013-01-22 11:08, Bj?rn-Egil Dahlberg wrote: >> Found an issue not caught in pu due to windows being down because of >> other issues in pu on windows. >> >> >> *** User 2013-01-21 22:53:27.711 *** >> num_bif_SUITE:t_float_to_list failed on line 126 >> Reason: {badmatch,"1.00000000000000000000e+000"} >> >> >> >> >> === Ended at 2013-01-21 22:53:27 >> === location [{num_bif_SUITE,t_float_to_list,126}, >> {test_server,ts_tc,1362}, >> {test_server,run_test_case_eval1,979}, >> {test_server,run_test_case_eval,928}] >> === reason = no match of right hand side value >> "1.00000000000000000000e+000" >> in function num_bif_SUITE:t_float_to_list/1 (num_bif_SUITE.erl, >> line 126) >> in call from test_server:ts_tc/3 (test_server.erl, line 1362) >> in call from test_server:run_test_case_eval1/6 (test_server.erl, >> line 979) >> in call from test_server:run_test_case_eval/9 (test_server.erl, line >> 928) >> >> >> 126: "1.00000000000000000000e+00" = float_to_list(1.0), <- this >> one >> >> This is on Windows XP. >> >> // Bj?rn-Egil >> >> >> On 2013-01-21 15:42, Serge Aleynikov wrote: >>> Thanks for expediting this for the upcoming release! >>> >>> Just to make sure that Lukas suggestion doesn't go unnoticed - the only >>> remaining point not included in the patch (that can be addressed in a >>> later release) is taking advantage of the float formatting speedup in >>> erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I >>> addressed in the attached email earlier in this thread. >>> >>> On 1/21/2013 9:30 AM, Bj?rn-Egil Dahlberg wrote: >>>> Great, I'll fetch and put into master-opu. >>>> >>>> Hopefully we have found all issues. *crossing fingers* >>>>> For your convenience I repushed the change with this fix, that >>>>> affected: >>>>> >>>>> bif.c >>>>> erlang.xml (documented reference to badarg instead of internal_error) >>>>> num_bif_SUITE.erl >>>>> Commit message >>>>> >>>>> Serge >>>>> >>>>> On 1/21/2013 9:14 AM, Bj?rn-Egil Dahlberg wrote: >>>>>> Ok, so regarding internal_error. >>>>>> >>>>>> It is clearly specially handled in the vm, and in the debug vm an >>>>>> asserts checks for it *not* to be set, i.e.: >>>>>> >>>>>> Eshell V5.10 (abort with ^G) >>>>>> 1> erlang:float_to_list(1.0e300, [{decimals, 1}]). >>>>>> Assertion failed: Value != am_internal_error in beam/beam_emu.c, line >>>>>> 5317 >>>>>> Aborted (core dumped) >>>>>> >>>>>> >>>>>> I asked Bj?rn and Patrik since they have been here the longest: >>>>>> - "How is exception internal_error handled, and what is special about >>>>>> it?" >>>>>> - "The what now?" >>>>>> >>>>>> Anyhow, >>>>>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | EXF_PANIC) >>>>>> where EXF_PANIC means uncatchable. >>>>>> >>>>>> My take on it is, it is literally meant to be an internal error and >>>>>> should not be recovered from. Thus those test cases will result in >>>>>> cores >>>>>> in debug builds. Not great. More importantly, we can trigger this >>>>>> from >>>>>> bad input. >>>>>> >>>>>> I'm sorry, but I have revert my previous statement and return BADARG >>>>>> instead. >>>>>> >>>>>> I'll update the code and put it in master-opu. >>>>>> >>>>>> // egil >>>>>> >>>>>> On 2013-01-21 04:17, Serge Aleynikov wrote: >>>>>>> On 1/19/2013 8:40 PM, Bj?rn-Egil Dahlberg wrote:> I don't think the >>>>>>> 'compact' option is doing what is says. See the following: >>>>>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]). >>>>>>>> "2.3333" >>>>>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]). >>>>>>>> "2.333333" >>>>>>>> >>>>>>> Egil, >>>>>>> >>>>>>> I repushed the fix for this issue along with your recommendation to >>>>>>> limit the range of Decimals. The only thing - the valid range is >>>>>>> not >>>>>>> 0..255, but 0..249, since we need to keep in mind that a properly >>>>>>> formatted number includes "X." (minimally one digit before the >>>>>>> decimal >>>>>>> point) and "e+YY" (in case of scientific notation). >>>>>>> >>>>>>> We still could get internal_error, when the number is too large >>>>>>> irrespective of the number of decimals: >>>>>>> >>>>>>> float_to_list(1.0e+300, [{decimals, 1}]). >>>>>>> >>>>>>> Here the number doesn't fit in the buffer irrespective of the tail >>>>>>> after >>>>>>> the decimal point. This brings me back to the question you raised >>>>>>> earlier in the thread if 256 is indeed a good default for the buffer >>>>>>> size or it needs to be increased. I still think it's good as >>>>>>> when one >>>>>>> deals with formatting such large numbers, he should use scientific >>>>>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do >>>>>>> just >>>>>>> fine. >>>>>>> >>>>>>> Added appropriate test cases. >>>>>>> >>>>>>> While trying one test case, there's a weird issue that I don't >>>>>>> understand (or maybe it's too late now and I am failing to see >>>>>>> something >>>>>>> silly). Why am I not able to catch the internal_error exception? >>>>>>> >>>>>>> This is expected: >>>>>>> 7> (catch float_to_list(1.0, [{decimals, 250}])). >>>>>>> {'EXIT',{badarg,[{erlang,float_to_list, >>>>>>> [1.0,[{decimals,250}]], >>>>>>> []}, >>>>>>> ...} >>>>>>> >>>>>>> This is not expected. I should see the same >>>>>>> {'EXIT', {internal_error, _}} result, no? >>>>>>> >>>>>>> 8> (catch float_to_list(1.0e300, [{decimals, 1}])). >>>>>>> >>>>>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 === >>>>>>> Error in process <0.40.0> with exit value: >>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ** exception exit: internal_error >>>>>>> in function float_to_list/2 >>>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>>> >>>>>>> This doesn't catch the exception either: >>>>>>> >>>>>>> 9> try float_to_list(1.0e300, [{decimals, 1}]) catch _:W -> W end. >>>>>>> >>>>>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 === >>>>>>> Error in process <0.45.0> with exit value: >>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ** exception exit: internal_error >>>>>>> in function float_to_list/2 >>>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>>> >>>>>>> Any idea why? Is there something special about internal_error? I >>>>>>> wanted a simple test case, but it fails due to uncaught exception: >>>>>>> >>>>>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300, >>>>>>> [{decimals, 1}])) >>>>>>> >>>>>>> Serge >> >> _______________________________________________ >> 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 egil@REDACTED Tue Jan 22 15:39:56 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 22 Jan 2013 15:39:56 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50FE9C55.4080304@aleynikov.org> References: <4D2D3FA8.1000009@aleynikov.org> <5035302F.1070405@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F979F9.2070903@aleynikov.org> <50F97C40.9030303@erlang.org> <50FA0EB5.3060900@aleynikov.org> <50FCB35C.1030402@aleynikov.org> <50FD4D39.3000407@erlang.org> <50FD500D.7050002@aleynikov.org> <50FD5102.80106@erlang.org> <50FD53BA.2050209@aleynikov.org> <50FE6501.7050102@erlang.org> <50FE6BFD.3090900@erlang.org> <50FE9C55.4080304@aleynikov.org> Message-ID: <50FEA4BC.5030502@erlang.org> On 2013-01-22 15:04, Serge Aleynikov wrote: > So erts_snprintf formats floats slightly differently on windows? yep > > Would you like me I adjust the test cases (there are 6 of them that > would need to be made less strict) and repush or you can do it on your end? This is sort of a separate issue. I'll fix the cases and move on. // egil > > On 1/22/2013 5:37 AM, Bj?rn-Egil Dahlberg wrote: >> Heh, so this is not your fault =) >> >> R15B03 has this behaviour, >> R13B has this behaviour as well. >> >> Your new testcase is too strict. >> >> // Bj?rn-Egil >> >> >> On 2013-01-22 11:08, Bj?rn-Egil Dahlberg wrote: >>> Found an issue not caught in pu due to windows being down because of >>> other issues in pu on windows. >>> >>> >>> *** User 2013-01-21 22:53:27.711 *** >>> num_bif_SUITE:t_float_to_list failed on line 126 >>> Reason: {badmatch,"1.00000000000000000000e+000"} >>> >>> >>> >>> >>> === Ended at 2013-01-21 22:53:27 >>> === location [{num_bif_SUITE,t_float_to_list,126}, >>> {test_server,ts_tc,1362}, >>> {test_server,run_test_case_eval1,979}, >>> {test_server,run_test_case_eval,928}] >>> === reason = no match of right hand side value >>> "1.00000000000000000000e+000" >>> in function num_bif_SUITE:t_float_to_list/1 (num_bif_SUITE.erl, >>> line 126) >>> in call from test_server:ts_tc/3 (test_server.erl, line 1362) >>> in call from test_server:run_test_case_eval1/6 (test_server.erl, >>> line 979) >>> in call from test_server:run_test_case_eval/9 (test_server.erl, line >>> 928) >>> >>> >>> 126: "1.00000000000000000000e+00" = float_to_list(1.0), <- this >>> one >>> >>> This is on Windows XP. >>> >>> // Bj?rn-Egil >>> >>> >>> On 2013-01-21 15:42, Serge Aleynikov wrote: >>>> Thanks for expediting this for the upcoming release! >>>> >>>> Just to make sure that Lukas suggestion doesn't go unnoticed - the only >>>> remaining point not included in the patch (that can be addressed in a >>>> later release) is taking advantage of the float formatting speedup in >>>> erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I >>>> addressed in the attached email earlier in this thread. >>>> >>>> On 1/21/2013 9:30 AM, Bj?rn-Egil Dahlberg wrote: >>>>> Great, I'll fetch and put into master-opu. >>>>> >>>>> Hopefully we have found all issues. *crossing fingers* >>>>>> For your convenience I repushed the change with this fix, that >>>>>> affected: >>>>>> >>>>>> bif.c >>>>>> erlang.xml (documented reference to badarg instead of internal_error) >>>>>> num_bif_SUITE.erl >>>>>> Commit message >>>>>> >>>>>> Serge >>>>>> >>>>>> On 1/21/2013 9:14 AM, Bj?rn-Egil Dahlberg wrote: >>>>>>> Ok, so regarding internal_error. >>>>>>> >>>>>>> It is clearly specially handled in the vm, and in the debug vm an >>>>>>> asserts checks for it *not* to be set, i.e.: >>>>>>> >>>>>>> Eshell V5.10 (abort with ^G) >>>>>>> 1> erlang:float_to_list(1.0e300, [{decimals, 1}]). >>>>>>> Assertion failed: Value != am_internal_error in beam/beam_emu.c, line >>>>>>> 5317 >>>>>>> Aborted (core dumped) >>>>>>> >>>>>>> >>>>>>> I asked Bj?rn and Patrik since they have been here the longest: >>>>>>> - "How is exception internal_error handled, and what is special about >>>>>>> it?" >>>>>>> - "The what now?" >>>>>>> >>>>>>> Anyhow, >>>>>>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | EXF_PANIC) >>>>>>> where EXF_PANIC means uncatchable. >>>>>>> >>>>>>> My take on it is, it is literally meant to be an internal error and >>>>>>> should not be recovered from. Thus those test cases will result in >>>>>>> cores >>>>>>> in debug builds. Not great. More importantly, we can trigger this >>>>>>> from >>>>>>> bad input. >>>>>>> >>>>>>> I'm sorry, but I have revert my previous statement and return BADARG >>>>>>> instead. >>>>>>> >>>>>>> I'll update the code and put it in master-opu. >>>>>>> >>>>>>> // egil >>>>>>> >>>>>>> On 2013-01-21 04:17, Serge Aleynikov wrote: >>>>>>>> On 1/19/2013 8:40 PM, Bj?rn-Egil Dahlberg wrote:> I don't think the >>>>>>>> 'compact' option is doing what is says. See the following: >>>>>>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]). >>>>>>>>> "2.3333" >>>>>>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]). >>>>>>>>> "2.333333" >>>>>>>>> >>>>>>>> Egil, >>>>>>>> >>>>>>>> I repushed the fix for this issue along with your recommendation to >>>>>>>> limit the range of Decimals. The only thing - the valid range is >>>>>>>> not >>>>>>>> 0..255, but 0..249, since we need to keep in mind that a properly >>>>>>>> formatted number includes "X." (minimally one digit before the >>>>>>>> decimal >>>>>>>> point) and "e+YY" (in case of scientific notation). >>>>>>>> >>>>>>>> We still could get internal_error, when the number is too large >>>>>>>> irrespective of the number of decimals: >>>>>>>> >>>>>>>> float_to_list(1.0e+300, [{decimals, 1}]). >>>>>>>> >>>>>>>> Here the number doesn't fit in the buffer irrespective of the tail >>>>>>>> after >>>>>>>> the decimal point. This brings me back to the question you raised >>>>>>>> earlier in the thread if 256 is indeed a good default for the buffer >>>>>>>> size or it needs to be increased. I still think it's good as >>>>>>>> when one >>>>>>>> deals with formatting such large numbers, he should use scientific >>>>>>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do >>>>>>>> just >>>>>>>> fine. >>>>>>>> >>>>>>>> Added appropriate test cases. >>>>>>>> >>>>>>>> While trying one test case, there's a weird issue that I don't >>>>>>>> understand (or maybe it's too late now and I am failing to see >>>>>>>> something >>>>>>>> silly). Why am I not able to catch the internal_error exception? >>>>>>>> >>>>>>>> This is expected: >>>>>>>> 7> (catch float_to_list(1.0, [{decimals, 250}])). >>>>>>>> {'EXIT',{badarg,[{erlang,float_to_list, >>>>>>>> [1.0,[{decimals,250}]], >>>>>>>> []}, >>>>>>>> ...} >>>>>>>> >>>>>>>> This is not expected. I should see the same >>>>>>>> {'EXIT', {internal_error, _}} result, no? >>>>>>>> >>>>>>>> 8> (catch float_to_list(1.0e300, [{decimals, 1}])). >>>>>>>> >>>>>>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 === >>>>>>>> Error in process <0.40.0> with exit value: >>>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ** exception exit: internal_error >>>>>>>> in function float_to_list/2 >>>>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>>>> >>>>>>>> This doesn't catch the exception either: >>>>>>>> >>>>>>>> 9> try float_to_list(1.0e300, [{decimals, 1}]) catch _:W -> W end. >>>>>>>> >>>>>>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 === >>>>>>>> Error in process <0.45.0> with exit value: >>>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ** exception exit: internal_error >>>>>>>> in function float_to_list/2 >>>>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>>>> >>>>>>>> Any idea why? Is there something special about internal_error? I >>>>>>>> wanted a simple test case, but it fails due to uncaught exception: >>>>>>>> >>>>>>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300, >>>>>>>> [{decimals, 1}])) >>>>>>>> >>>>>>>> Serge >>> _______________________________________________ >>> 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 mc@REDACTED Tue Jan 22 20:31:13 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Tue, 22 Jan 2013 14:31:13 -0500 Subject: [erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479) Message-ID: To recap and summarize a flurry of -1's on this feature that appeared on github: The removal of the check_inheritance code and other experimental features was much heralded, and exemplified the OTP team's understanding that Erlang does not need OOP or want incompatibilities. The addition of an undefined function handler, however, boiled down to it being a highly experimental feature that should not have been added or even documented, in many peoples opinion. Nearly 80% of the people responding to this patch did not agree that this implementation would add value to Erlang and worse could significantly degrade the ability to reason about code behaviour. In the end the only valid use case demonstrated for being able to call a function which is not defined is in the case of a database ORM where one would called Person:first_name(). In fact, this one use case (not at all sufficient to warrant this feature) can easily be implemented by actually generating code created from data tables schemas and not dynamically determining it. Experienced programmers will understand the noxious influence of spooky action at a distance and other idioms from the non-functional programming world and this simply begs to be used that way. There is just no room for this type of deferred judgement in a language specifically designed for the highest levels of program expectation, scalability and ease of code readability. Beyond all conceivable objections the most apparent reality is that calling a userland module function that does not exist is an error, and trying to "recover" that error is programming defensively. This very concept alone violates in some way at least half a dozen long standing Erlang programming rules and semantics [1].. Such as: 3.5 Don't make assumptions about what the caller will do with the results of a function 3.10 Try to eliminate side effects 3.11 Don't allow private data structure to "leak" out of a module 3.12 Make code as deterministic as possible 3.13 Do not program "defensively" 4.1 Separate error handling and normal case code 6.7 Exporting functions 7.6 Function names [1] http://www.erlang.se/doc/programming_rules.shtml#HDR11 -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From n.oxyde@REDACTED Tue Jan 22 21:24:59 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 22 Jan 2013 21:24:59 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> Message-ID: <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> Hi, I've added a commit that document output.mk.in as requested; please refetch. Anders, please tell me if things aren't clear enough and you want me to rewrite/detail. Regards, -- Anthony Ramine Le 19 janv. 2013 ? 12:15, Anthony Ramine a ?crit : > Hi, > > I've recreated the branch with two new commits, adding support of silent rules > in wx and when running ./otp_build tests. > > Please refetch. > > Regards, > > -- > Anthony Ramine > > Le 18 janv. 2013 ? 14:43, Bj?rn-Egil Dahlberg a ?crit : > >> Patch merged. >> Closing issue designated OTP-10726. >> >> // Bj?rn-Egil >> >> On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: >>> On 2013-01-15 21:46, Anthony Ramine wrote: >>>> I couldn't reproduce the bug here but apparently I've found the cause of it. >>> Looking good. >>> >>> Putting it into master-opu integration branch. >>> >>> Will be merged later this week if no other issues appear. >>> >>> // Bj?rn-Egil >>> >>>> >>>> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): >>>> >>>>> Using the MAKE variable has the same effect as using a ?+? character >>>>> at the beginning of the recipe line. See Instead of Executing the >>>>> Recipes. This special feature is only enabled if the MAKE variable >>>>> appears directly in the recipe: it does not apply if the MAKE variable >>>>> is referenced through expansion of another variable. In the latter >>>>> case you must use the ?+? token to get these special effects. >>>> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable >>>> >>>> Please refetch. >>>> >>>> Regards, >>>> >>> >>> _______________________________________________ >>> 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 ulf@REDACTED Wed Jan 23 11:27:36 2013 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 23 Jan 2013 11:27:36 +0100 Subject: [erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479) In-Reply-To: References: Message-ID: <5CBAEDAB-3EFA-4403-9FE6-E6832C506CEA@feuerlabs.com> On 22 Jan 2013, at 20:31, Pedram Nimreezi wrote: > Beyond all conceivable objections the most apparent reality is that > calling a userland module function that does not exist is an error, > and trying to "recover" that error is programming defensively. > This very concept alone violates in some way at least half a dozen > long standing Erlang programming rules and semantics [1].. Again (after which I will stop repeating myself), this is exactly what error_handler:undefined_function/3 has always done, and it's a cornerstone of Erlang's on-demand code loading. It was introduced by the very people who wrote the Erlang programming rules and semantics. ;-) The possibility to make this functionality local to a particular module simply allows for the possibility that (a) given that the existense of error_handler:undefined_function/3 is justified in the first place, (b) there are other potential implementations of that function that could serve a useful purpose. There have been attempts at modifying the error_handler hook before, several times in fact. The single most important argument against doing so is that it serves *all* code running in the VM, which means that the potential for inadvertently breaking someone else's code is extremely high. The argument that "you'd better know what you're doing" is a weak one, since there are plenty of areas where this applies. Off the top of my head, I'd say this is sage advice for anyone trying their hand at NIFs, Core Erlang, hand-written BEAM ASM code, patching mnesia internals, etc. Yet all these things are allowed. Having said this, I'm not necessarily advocating that this feature needs to be included. I feel fairly neutral on the subject, since: - It is obscurely named, and obviously doesn't *beg* to be used - The documentation will surely include stern warnings to the effect that you should really, really avoid messing with it unless you have a very good reason to. - It doesn't really introduce a new feature, as much as it re- packages an old one and makes it safer to experiment with. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From egil@REDACTED Wed Jan 23 12:20:36 2013 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 23 Jan 2013 12:20:36 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> Message-ID: <50FFC784.9020101@erlang.org> On 2013-01-22 21:24, Anthony Ramine wrote: > Hi, > > I've added a commit that document output.mk.in as requested; > please refetch. > > Anders, please tell me if things aren't clear enough and you want > me to rewrite/detail. For clarity, these are the changes: https://github.com/nox/otp/commit/78074428dd7545b837625c81e1840046031aeb03 > > Regards, > From hm@REDACTED Wed Jan 23 12:47:31 2013 From: hm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Wed, 23 Jan 2013 12:47:31 +0100 Subject: [erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479) In-Reply-To: <5CBAEDAB-3EFA-4403-9FE6-E6832C506CEA@feuerlabs.com> References: <5CBAEDAB-3EFA-4403-9FE6-E6832C506CEA@feuerlabs.com> Message-ID: On Wed, Jan 23, 2013 at 11:27 AM, Ulf Wiger wrote: > The argument that "you'd better know what you're doing" is > a weak one, since there are plenty of areas where this applies. > Off the top of my head, I'd say this is sage advice for anyone > trying their hand at NIFs, Core Erlang, hand-written BEAM ASM > code, patching mnesia internals, etc. Yet all these things are > allowed. Depends on what you mean with "allowed". With open source code you are "allowed" to do a lot. This does not necessarily mean that it is a good idea to do it. Patching the internals of any application is normally regarded as a bad practice. It should only be done as a last resort. Do it only if the maintainer rejects your code change. /H?kan From ulf@REDACTED Wed Jan 23 13:06:39 2013 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 23 Jan 2013 13:06:39 +0100 Subject: [erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479) In-Reply-To: References: <5CBAEDAB-3EFA-4403-9FE6-E6832C506CEA@feuerlabs.com> Message-ID: <60353A73-9709-467E-9C43-C45937F31253@feuerlabs.com> On 23 Jan 2013, at 12:47, H?kan Mattsson wrote: > Depends on what you mean with "allowed". With open source code > you are "allowed" to do a lot. This does not necessarily mean that > it is a good idea to do it. Nor that you *have* to do it. :) I think that Kenneth has presented a pretty good argument for why they want to introduce this functionality, and also reminded us that their past decision was received favourably. We should not feel forced to make clever uses of this new feature, just because the OTP team feels that it is needed at their level. Even so, if we do feel so compelled, you are definitely allowed to. ;-) BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com From fdmanana@REDACTED Wed Jan 23 14:33:01 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Wed, 23 Jan 2013 13:33:01 +0000 Subject: [erlang-patches] [PATCH] Use share flags for all file operations on Windows In-Reply-To: <50F7F463.2020800@erlang.org> References: <5087AF84.5040404@erlang.org> <50F7F463.2020800@erlang.org> Message-ID: On Thu, Jan 17, 2013 at 12:53 PM, Fredrik wrote: > Re-fetched. > The patch is currently under review. Any updates from the review? thanks > > BR Fredrik Gustafsson > Erlang OTP Team > > On 01/17/2013 12:29 PM, Filipe David Manana wrote: >> >> git fetch git://github.com/fdmanana/otp.git windows_file_share_delete > > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From fredrik@REDACTED Wed Jan 23 14:35:52 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 23 Jan 2013 14:35:52 +0100 Subject: [erlang-patches] [PATCH] Use share flags for all file operations on Windows In-Reply-To: References: <5087AF84.5040404@erlang.org> <50F7F463.2020800@erlang.org> Message-ID: <50FFE738.3020406@erlang.org> It is being graduated, soon viewable on github ;) BR Fredrik Gustafsson Erlang OTP Team On 01/23/2013 02:33 PM, Filipe David Manana wrote: > On Thu, Jan 17, 2013 at 12:53 PM, Fredrik wrote: >> Re-fetched. >> The patch is currently under review. > Any updates from the review? > > thanks > >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> On 01/17/2013 12:29 PM, Filipe David Manana wrote: >>> git fetch git://github.com/fdmanana/otp.git windows_file_share_delete >> > > From aronisstav@REDACTED Wed Jan 23 14:35:37 2013 From: aronisstav@REDACTED (Stavros Aronis) Date: Wed, 23 Jan 2013 14:35:37 +0100 Subject: [erlang-patches] Fwd: Small patches for Dialyzer In-Reply-To: References: Message-ID: Included: - proper support for the "fun(...)" syntax in specs - removal of two obsolete tests for modules within packages - update for the results of a test affected by removal of unused anonymous functions warnings. git fetch git://github.com/aronisstav/otp.git dialyzer-unknown-arity-funs Regards, Stavros -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Wed Jan 23 14:39:28 2013 From: fredrik@REDACTED (Fredrik) Date: Wed, 23 Jan 2013 14:39:28 +0100 Subject: [erlang-patches] Fwd: Small patches for Dialyzer In-Reply-To: References: Message-ID: <50FFE810.4060309@erlang.org> Thanks, Building it in master-pu right now. BR Fredrik Gustafsson Erlang OTP Team On 01/23/2013 02:35 PM, Stavros Aronis wrote: > Included: > > - proper support for the "fun(...)" syntax in specs > - removal of two obsolete tests for modules within packages > - update for the results of a test affected by removal of unused > anonymous functions warnings. > > git fetch git://github.com/aronisstav/otp.git > dialyzer-unknown-arity-funs > > Regards, > > Stavros > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aschultz@REDACTED Wed Jan 23 15:21:52 2013 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 23 Jan 2013 15:21:52 +0100 (CET) Subject: [erlang-patches] dialyzer from otp master getting stuck in build_plt In-Reply-To: <122078137.401308.1358950639169.JavaMail.root@tpip.net> Message-ID: <1278860784.401361.1358950912819.JavaMail.root@tpip.net> Hi, I have build and installed R16 from otp master branch. When trying to build a new plt file: 'dialyzer --build_plt --apps stdlib', dialyzer works hard (measured by CPU utilization) for about a minute, CPU usage for it then drops to 0, but it neither stops nor does it generate any additional output. The only output I get is: $ dialyzer --build_plt --apps stdlib Compiling some key modules to native code... Platform is Ubuntu 12.10 Any advise? 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 egil@REDACTED Wed Jan 23 15:27:42 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Wed, 23 Jan 2013 15:27:42 +0100 Subject: [erlang-patches] dialyzer from otp master getting stuck in build_plt In-Reply-To: <1278860784.401361.1358950912819.JavaMail.root@tpip.net> References: <1278860784.401361.1358950912819.JavaMail.root@tpip.net> Message-ID: <50FFF35E.4090407@erlang.org> In current master (cc8285ed57ad46fcbbbfb333535ff472dd57ec27), includes Revert "Merge branch 'nox/rm-reverse-eta-conversion/OTP-10682'" please refetch master and try again. // Bj?rn-Egil On 2013-01-23 15:21, Andreas Schultz wrote: > Hi, > > I have build and installed R16 from otp master branch. When trying > to build a new plt file: 'dialyzer --build_plt --apps stdlib', > dialyzer works hard (measured by CPU utilization) for about a minute, > CPU usage for it then drops to 0, but it neither stops nor does it > generate any additional output. > > The only output I get is: > $ dialyzer --build_plt --apps stdlib > Compiling some key modules to native code... > > Platform is Ubuntu 12.10 > > Any advise? > > Andreas From fdmanana@REDACTED Wed Jan 23 16:16:50 2013 From: fdmanana@REDACTED (Filipe David Manana) Date: Wed, 23 Jan 2013 15:16:50 +0000 Subject: [erlang-patches] [PATCH] Use share flags for all file operations on Windows In-Reply-To: <50FFE738.3020406@erlang.org> References: <5087AF84.5040404@erlang.org> <50F7F463.2020800@erlang.org> <50FFE738.3020406@erlang.org> Message-ID: On Wed, Jan 23, 2013 at 1:35 PM, Fredrik wrote: > It is being graduated, soon viewable on github ;) It's now visible on github's master branch. Thank you :) > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/23/2013 02:33 PM, Filipe David Manana wrote: >> >> On Thu, Jan 17, 2013 at 12:53 PM, Fredrik wrote: >>> >>> Re-fetched. >>> The patch is currently under review. >> >> Any updates from the review? >> >> thanks >> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >>> On 01/17/2013 12:29 PM, Filipe David Manana wrote: >>>> >>>> git fetch git://github.com/fdmanana/otp.git windows_file_share_delete >>> >>> >> >> > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." From egil@REDACTED Wed Jan 23 17:30:37 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Wed, 23 Jan 2013 17:30:37 +0100 Subject: [erlang-patches] new float_to_list/2 In-Reply-To: <50FEA4BC.5030502@erlang.org> References: <4D2D3FA8.1000009@aleynikov.org> <5035F382.5090203@erlang.org> <50EF81C7.4020703@aleynikov.org> <50EFD2DF.5000407@erlang.org> <50F01295.6010203@aleynikov.org> <50F01971.7070009@erlang.org> <50F01DAD.50101@aleynikov.org> <50F03359.1080800@erlang.org> <50F03609.6000809@aleynikov.org> <50F3CB77.8020508@erlang.org> <50F979F9.2070903@aleynikov.org> <50F97C40.9030303@erlang.org> <50FA0EB5.3060900@aleynikov.org> <50FCB35C.1030402@aleynikov.org> <50FD4D39.3000407@erlang.org> <50FD500D.7050002@aleynikov.org> <50FD5102.80106@erlang.org> <50FD53BA.2050209@aleynikov.org> <50FE6501.7050102@erlang.org> <50FE6BFD.3090900@erlang.org> <50FE9C55.4080304@aleynikov.org> <50FEA4BC.5030502@erlang.org> Message-ID: <5100102D.40107@erlang.org> Patch merged. Closing issue designated OTP-10752. On 2013-01-22 15:39, Bj?rn-Egil Dahlberg wrote: > On 2013-01-22 15:04, Serge Aleynikov wrote: >> So erts_snprintf formats floats slightly differently on windows? > yep >> >> Would you like me I adjust the test cases (there are 6 of them that >> would need to be made less strict) and repush or you can do it on >> your end? > This is sort of a separate issue. > > I'll fix the cases and move on. > > // egil >> >> On 1/22/2013 5:37 AM, Bj?rn-Egil Dahlberg wrote: >>> Heh, so this is not your fault =) >>> >>> R15B03 has this behaviour, >>> R13B has this behaviour as well. >>> >>> Your new testcase is too strict. >>> >>> // Bj?rn-Egil >>> >>> >>> On 2013-01-22 11:08, Bj?rn-Egil Dahlberg wrote: >>>> Found an issue not caught in pu due to windows being down because of >>>> other issues in pu on windows. >>>> >>>> >>>> *** User 2013-01-21 22:53:27.711 *** >>>> num_bif_SUITE:t_float_to_list failed on line 126 >>>> Reason: {badmatch,"1.00000000000000000000e+000"} >>>> >>>> >>>> >>>> >>>> === Ended at 2013-01-21 22:53:27 >>>> === location [{num_bif_SUITE,t_float_to_list,126}, >>>> {test_server,ts_tc,1362}, >>>> {test_server,run_test_case_eval1,979}, >>>> {test_server,run_test_case_eval,928}] >>>> === reason = no match of right hand side value >>>> "1.00000000000000000000e+000" >>>> in function num_bif_SUITE:t_float_to_list/1 (num_bif_SUITE.erl, >>>> line 126) >>>> in call from test_server:ts_tc/3 (test_server.erl, line 1362) >>>> in call from test_server:run_test_case_eval1/6 (test_server.erl, >>>> line 979) >>>> in call from test_server:run_test_case_eval/9 (test_server.erl, >>>> line >>>> 928) >>>> >>>> >>>> 126: "1.00000000000000000000e+00" = float_to_list(1.0), <- >>>> this >>>> one >>>> >>>> This is on Windows XP. >>>> >>>> // Bj?rn-Egil >>>> >>>> >>>> On 2013-01-21 15:42, Serge Aleynikov wrote: >>>>> Thanks for expediting this for the upcoming release! >>>>> >>>>> Just to make sure that Lukas suggestion doesn't go unnoticed - the >>>>> only >>>>> remaining point not included in the patch (that can be addressed in a >>>>> later release) is taking advantage of the float formatting speedup in >>>>> erts/lib_src/common/erl_printf_format.c suggested by Lukas, which I >>>>> addressed in the attached email earlier in this thread. >>>>> >>>>> On 1/21/2013 9:30 AM, Bj?rn-Egil Dahlberg wrote: >>>>>> Great, I'll fetch and put into master-opu. >>>>>> >>>>>> Hopefully we have found all issues. *crossing fingers* >>>>>>> For your convenience I repushed the change with this fix, that >>>>>>> affected: >>>>>>> >>>>>>> bif.c >>>>>>> erlang.xml (documented reference to badarg instead of >>>>>>> internal_error) >>>>>>> num_bif_SUITE.erl >>>>>>> Commit message >>>>>>> >>>>>>> Serge >>>>>>> >>>>>>> On 1/21/2013 9:14 AM, Bj?rn-Egil Dahlberg wrote: >>>>>>>> Ok, so regarding internal_error. >>>>>>>> >>>>>>>> It is clearly specially handled in the vm, and in the debug vm an >>>>>>>> asserts checks for it *not* to be set, i.e.: >>>>>>>> >>>>>>>> Eshell V5.10 (abort with ^G) >>>>>>>> 1> erlang:float_to_list(1.0e300, [{decimals, 1}]). >>>>>>>> Assertion failed: Value != am_internal_error in >>>>>>>> beam/beam_emu.c, line >>>>>>>> 5317 >>>>>>>> Aborted (core dumped) >>>>>>>> >>>>>>>> >>>>>>>> I asked Bj?rn and Patrik since they have been here the longest: >>>>>>>> - "How is exception internal_error handled, and what is special >>>>>>>> about >>>>>>>> it?" >>>>>>>> - "The what now?" >>>>>>>> >>>>>>>> Anyhow, >>>>>>>> EXC_INTERNAL_ERROR is defined by ((2 << 8) | EXC_ERROR | >>>>>>>> EXF_PANIC) >>>>>>>> where EXF_PANIC means uncatchable. >>>>>>>> >>>>>>>> My take on it is, it is literally meant to be an internal error >>>>>>>> and >>>>>>>> should not be recovered from. Thus those test cases will result in >>>>>>>> cores >>>>>>>> in debug builds. Not great. More importantly, we can trigger this >>>>>>>> from >>>>>>>> bad input. >>>>>>>> >>>>>>>> I'm sorry, but I have revert my previous statement and return >>>>>>>> BADARG >>>>>>>> instead. >>>>>>>> >>>>>>>> I'll update the code and put it in master-opu. >>>>>>>> >>>>>>>> // egil >>>>>>>> >>>>>>>> On 2013-01-21 04:17, Serge Aleynikov wrote: >>>>>>>>> On 1/19/2013 8:40 PM, Bj?rn-Egil Dahlberg wrote:> I don't >>>>>>>>> think the >>>>>>>>> 'compact' option is doing what is says. See the following: >>>>>>>>>> 25> erlang:float_to_list(7/3, [{decimals, 6}, compact]). >>>>>>>>>> "2.3333" >>>>>>>>>> 26> erlang:float_to_list(7/3, [{decimals, 6}]). >>>>>>>>>> "2.333333" >>>>>>>>>> >>>>>>>>> Egil, >>>>>>>>> >>>>>>>>> I repushed the fix for this issue along with your >>>>>>>>> recommendation to >>>>>>>>> limit the range of Decimals. The only thing - the valid range is >>>>>>>>> not >>>>>>>>> 0..255, but 0..249, since we need to keep in mind that a properly >>>>>>>>> formatted number includes "X." (minimally one digit before the >>>>>>>>> decimal >>>>>>>>> point) and "e+YY" (in case of scientific notation). >>>>>>>>> >>>>>>>>> We still could get internal_error, when the number is too large >>>>>>>>> irrespective of the number of decimals: >>>>>>>>> >>>>>>>>> float_to_list(1.0e+300, [{decimals, 1}]). >>>>>>>>> >>>>>>>>> Here the number doesn't fit in the buffer irrespective of the >>>>>>>>> tail >>>>>>>>> after >>>>>>>>> the decimal point. This brings me back to the question you >>>>>>>>> raised >>>>>>>>> earlier in the thread if 256 is indeed a good default for the >>>>>>>>> buffer >>>>>>>>> size or it needs to be increased. I still think it's good as >>>>>>>>> when one >>>>>>>>> deals with formatting such large numbers, he should use >>>>>>>>> scientific >>>>>>>>> notation, so float_to_list(1.0e+300, [{scientific, 1}]) would do >>>>>>>>> just >>>>>>>>> fine. >>>>>>>>> >>>>>>>>> Added appropriate test cases. >>>>>>>>> >>>>>>>>> While trying one test case, there's a weird issue that I don't >>>>>>>>> understand (or maybe it's too late now and I am failing to see >>>>>>>>> something >>>>>>>>> silly). Why am I not able to catch the internal_error exception? >>>>>>>>> >>>>>>>>> This is expected: >>>>>>>>> 7> (catch float_to_list(1.0, [{decimals, 250}])). >>>>>>>>> {'EXIT',{badarg,[{erlang,float_to_list, >>>>>>>>> [1.0,[{decimals,250}]], >>>>>>>>> []}, >>>>>>>>> ...} >>>>>>>>> >>>>>>>>> This is not expected. I should see the same >>>>>>>>> {'EXIT', {internal_error, _}} result, no? >>>>>>>>> >>>>>>>>> 8> (catch float_to_list(1.0e300, [{decimals, 1}])). >>>>>>>>> >>>>>>>>> =ERROR REPORT==== 20-Jan-2013::22:01:26 === >>>>>>>>> Error in process <0.40.0> with exit value: >>>>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,352}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ** exception exit: internal_error >>>>>>>>> in function float_to_list/2 >>>>>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>>>>> >>>>>>>>> This doesn't catch the exception either: >>>>>>>>> >>>>>>>>> 9> try float_to_list(1.0e300, [{decimals, 1}]) catch _:W -> W >>>>>>>>> end. >>>>>>>>> >>>>>>>>> =ERROR REPORT==== 20-Jan-2013::22:02:19 === >>>>>>>>> Error in process <0.45.0> with exit value: >>>>>>>>> {internal_error,[{erlang,float_to_list,[1.000000e+300,[{decimals,1}]],[]},{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,568}]},{erl_eval,try_clauses,8,[{file,"erl_eval.erl"},{line,759}]},{shell,exprs,7,[{file,"shell.erl"},{line,667}]},{shell,eval_exprs... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ** exception exit: internal_error >>>>>>>>> in function float_to_list/2 >>>>>>>>> called as float_to_list(1.0e300,[{decimals,1}]) >>>>>>>>> >>>>>>>>> Any idea why? Is there something special about >>>>>>>>> internal_error? I >>>>>>>>> wanted a simple test case, but it fails due to uncaught >>>>>>>>> exception: >>>>>>>>> >>>>>>>>> {'EXIT', {internal_error, _}} = (catch float_to_list(1.0e+300, >>>>>>>>> [{decimals, 1}])) >>>>>>>>> >>>>>>>>> Serge >>>> _______________________________________________ >>>> 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 egil@REDACTED Thu Jan 24 15:12:17 2013 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 24 Jan 2013 15:12:17 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <50FFC784.9020101@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <50FFC784.9020101@erlang.org> Message-ID: <51014141.40302@erlang.org> I have cherry-picked some commits and put it into the following branch: https://github.com/psyeugenic/otp/commits/nox/enable-silent-rules-doc This is now in master-opu. The other commits got the following: ./otp_build tests -a ... gmake[3]: Entering directory `/ldisk/egil/git/otp/lib/diameter/test' /usr/bin/install -c -d "/ldisk/egil/git/otp/release/tests/diameter_test/diameter_codec_SUITE_data" /usr/bin/install -c -m 644 diameter_codec_SUITE_data/avps.dia diameter_codec_SUITE_data/send.dia diameter_codec_SUITE_data/recv.dia diameter_codec_SUITE_data/diameter_test_unknown.erl "/ldisk/egil/git/otp/release/tests/diameter_test/diameter_codec_SUITE_data" gmake[3]: Leaving directory `/ldisk/egil/git/otp/lib/diameter/test' gmake /diameter_ct.erl /diameter_util.erl /diameter_enum.erl /diameter_compiler_SUITE.erl /diameter_codec_SUITE.erl /diameter_codec_test.erl /diameter_app_SUITE.erl /diameter_dict_SUITE.erl /diameter_reg_SUITE.erl /diameter_sync_SUITE.erl /diameter_stats_SUITE.erl /diameter_watchdog_SUITE.erl /diameter_gen_sctp_SUITE.erl /diameter_transport_SUITE.erl /diameter_capx_SUITE.erl /diameter_traffic_SUITE.erl /diameter_relay_SUITE.erl /diameter_tls_SUITE.erl /diameter_failover_SUITE.erl /diameter_dpr_SUITE.erl /diameter_event_SUITE.erl gmake[3]: Entering directory `/ldisk/egil/git/otp/lib/diameter/test' gmake[3]: *** [/diameter_ct.erl] Error 1 gmake[3]: *** Waiting for unfinished jobs.... gmake[3]: *** [/diameter_util.erl] Error 1 gmake[3]: *** [/diameter_enum.erl] Error 1 gmake[3]: Leaving directory `/ldisk/egil/git/otp/lib/diameter/test' gmake[2]: *** [release_tests_spec] Error 2 gmake[2]: Leaving directory `/ldisk/egil/git/otp/lib/diameter/test' gmake[1]: *** [release_tests] Error 2 gmake[1]: Leaving directory `/ldisk/egil/git/otp/lib/diameter/test' gmake: *** [lib/diameter/test] Error 2 Hence dropped. Further development will probably be stalled until after R16A or R16B depending on type of developments (bugfixes or features). // Bj?rn-Egil On 2013-01-23 12:20, Bj?rn-Egil Dahlberg wrote: > On 2013-01-22 21:24, Anthony Ramine wrote: >> Hi, >> >> I've added a commit that document output.mk.in as requested; >> please refetch. >> >> Anders, please tell me if things aren't clear enough and you want >> me to rewrite/detail. > For clarity, these are the changes: > > https://github.com/nox/otp/commit/78074428dd7545b837625c81e1840046031aeb03 > > >> >> Regards, >> > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > > From magnus@REDACTED Thu Jan 24 17:47:04 2013 From: magnus@REDACTED (Magnus Henoch) Date: Thu, 24 Jan 2013 16:47:04 +0000 Subject: [erlang-patches] Fix syntax highlighting of $\' in Emacs mode Message-ID: I just noticed that $\' (that is, a single quote as a character constant, written with a superfluous backslash) causes the following text to be coloured as an atom in the Emacs erlang-mode. Here is a patch for that: git fetch git://github.com/legoscia/otp.git fix-highlighting-dollar-backslash-singlequote https://github.com/legoscia/otp/compare/erlang:master...legoscia:fix-highlighting-dollar-backslash-singlequote https://github.com/legoscia/otp/compare/erlang:master...legoscia:fix-highlighting-dollar-backslash-singlequote.patch Regards, Magnus From fredrik@REDACTED Thu Jan 24 17:55:09 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 24 Jan 2013 17:55:09 +0100 Subject: [erlang-patches] Fix syntax highlighting of $\' in Emacs mode In-Reply-To: References: Message-ID: <5101676D.6060006@erlang.org> Hello Magnus, Your patch is being tested and merged with the others in 'master-pu'. Thanks, BR Fredrik Gustafsson Erlang OTP Team On 01/24/2013 05:47 PM, Magnus Henoch wrote: > I just noticed that $\' (that is, a single quote as a character > constant, written with a superfluous backslash) causes the following > text to be coloured as an atom in the Emacs erlang-mode. Here is a > patch for that: > > git fetch git://github.com/legoscia/otp.git fix-highlighting-dollar-backslash-singlequote > > https://github.com/legoscia/otp/compare/erlang:master...legoscia:fix-highlighting-dollar-backslash-singlequote > https://github.com/legoscia/otp/compare/erlang:master...legoscia:fix-highlighting-dollar-backslash-singlequote.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From alevandal@REDACTED Fri Jan 25 08:48:42 2013 From: alevandal@REDACTED (Rubber Cthulhu) Date: Fri, 25 Jan 2013 15:48:42 +0800 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 In-Reply-To: <50FD2484.5000604@erlang.org> References: <50ED49FC.8060106@erlang.org> <50FD2484.5000604@erlang.org> Message-ID: Hello Fredrik. I'm sorry for delay. I didn't deal with test system in erlang earlier and I had to see into it. Besides running tests for odbc was nontrivial. But now it's done. git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master That patch includes previous changes: https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch And that includes only testcases: https://github.com/RubberCthulhu/otp/commit/026d6778fdadce1eac8cdf486b159fa0d6669836 https://github.com/RubberCthulhu/otp/commit/026d6778fdadce1eac8cdf486b159fa0d6669836.patch 2013/1/21 Fredrik : > Hello again, > Could you provide a testcase for this patch? > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/11/2013 07:50 AM, Danil Onishchenko wrote: >> >> Hello, Fredrik. >> I rebased that patch on 'master' branch. The previous version was >> based on 'maint'. >> >> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master >> >> >> https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master >> >> https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch >> >> 2013/1/9 Fredrik: >>> >>> Hello Kernel! >>> Your patch is now cooking in the 'master-pu' branch. >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >>> On 01/09/2013 10:29 AM, Kernel Panic wrote: >>>> >>>> A little patch for odbc:param_query/3 and odbc:param_query/4. >>>> >>>> Issue: Calling odbc:param_query/3 and odbc:param_query/4 with >>>> unparameterized query string and empty parameters list causes error in >>>> pattern matching in function param_values/1. >>>> >>>> This patch fixes this problem and allow to do things such as >>>> odbc:param_query(ConRef, "select * from some_table", []). >>>> >>>> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params >>>> >>>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params >>>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch >>>> _______________________________________________ >>>> erlang-patches mailing list >>>> erlang-patches@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-patches >>> >>> > From fredrik@REDACTED Fri Jan 25 09:54:45 2013 From: fredrik@REDACTED (Fredrik) Date: Fri, 25 Jan 2013 09:54:45 +0100 Subject: [erlang-patches] odbc:param_query/3 and odbc:param_query/4 In-Reply-To: References: <50ED49FC.8060106@erlang.org> <50FD2484.5000604@erlang.org> Message-ID: <51024855.1080004@erlang.org> On 01/25/2013 08:48 AM, Rubber Cthulhu wrote: > Hello Fredrik. > I'm sorry for delay. I didn't deal with test system in erlang earlier > and I had to see into it. Besides running tests for odbc was > nontrivial. > But now it's done. > > git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master > > That patch includes previous changes: > > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master > https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch > > And that includes only testcases: > > https://github.com/RubberCthulhu/otp/commit/026d6778fdadce1eac8cdf486b159fa0d6669836 > https://github.com/RubberCthulhu/otp/commit/026d6778fdadce1eac8cdf486b159fa0d6669836.patch > > 2013/1/21 Fredrik: >> Hello again, >> Could you provide a testcase for this patch? >> >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> On 01/11/2013 07:50 AM, Danil Onishchenko wrote: >>> Hello, Fredrik. >>> I rebased that patch on 'master' branch. The previous version was >>> based on 'maint'. >>> >>> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params-master >>> >>> >>> https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master >>> >>> https://github.com/RubberCthulhu/otp/compare/erlang:master...odbc-empty-params-master.patch >>> >>> 2013/1/9 Fredrik: >>>> Hello Kernel! >>>> Your patch is now cooking in the 'master-pu' branch. >>>> >>>> BR Fredrik Gustafsson >>>> Erlang OTP Team >>>> >>>> On 01/09/2013 10:29 AM, Kernel Panic wrote: >>>>> A little patch for odbc:param_query/3 and odbc:param_query/4. >>>>> >>>>> Issue: Calling odbc:param_query/3 and odbc:param_query/4 with >>>>> unparameterized query string and empty parameters list causes error in >>>>> pattern matching in function param_values/1. >>>>> >>>>> This patch fixes this problem and allow to do things such as >>>>> odbc:param_query(ConRef, "select * from some_table", []). >>>>> >>>>> git fetch git@REDACTED:RubberCthulhu/otp.git odbc-empty-params >>>>> >>>>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params >>>>> https://github.com/RubberCthulhu/otp/compare/odbc-empty-params.patch >>>>> _______________________________________________ >>>>> erlang-patches mailing list >>>>> erlang-patches@REDACTED >>>>> http://erlang.org/mailman/listinfo/erlang-patches >>>> Hello, Re-fetched. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From mc@REDACTED Fri Jan 25 09:55:06 2013 From: mc@REDACTED (Pedram Nimreezi) Date: Fri, 25 Jan 2013 03:55:06 -0500 Subject: [erlang-patches] [otp] Merge branch 'bjorn/kernel/undefined-function-handler/OTP-10617' (209a479) In-Reply-To: <60353A73-9709-467E-9C43-C45937F31253@feuerlabs.com> References: <5CBAEDAB-3EFA-4403-9FE6-E6832C506CEA@feuerlabs.com> <60353A73-9709-467E-9C43-C45937F31253@feuerlabs.com> Message-ID: I will unfortunately repeat myself as for what seems years I've been complaining about the absurdity of parameterized modules and the facilitation of inheritance code in erlang. Furthermore, had these internal OTP development forums been available to the community or if there were an OTP channel on IRC or at least public notes on the direction OTP is going with this, it would be less of an issue or a shock. Since I couldn't even find the information on said presentation with out asking around and since it's apparent that no one commenting here https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d did either, I have to point out the incredible disconnect between the OTP team and the community.. However I can honestly say that since R13 when there was likely far less code reacting with Issue 4 there has been an increase in its use: - The board acknowledges that a lot of software relies on this feature although it's always been experimental. Just think if a property manager leaves a block of foreclosed homes empty for 5 years or more, how can they be surprised that they might be illegitimately occupied? And just like records not being a first class type, which makes records *indistinguishable* from tagged tuples; This problem was not less apparent a long time ago, and is only more apparent and tangled today. And it is *not* like this wasn't obvious at least 5 years ago with posts such as http://www.lshift.net/blog/2008/05/18/late-binding-with-erlang Advocating what can only be construed as a tumbling back slide into OO. - Error handler functionality that today supports inheritance will be slightly generalized, so that parameterized modules can contain stubs to facilitate inheritance. The functionality in the error handler will be documented. Facilitating inheritance is not the way to go, it is the way to integrate all the external problems of OOP by programmers who have yet to grasp why ROK [1] and Joe Armstrong [2] have stated Erlang is not OOP for a reason. Adding stubs for it, putting it on the table and saying don't use it around OO addicts *is* irresponsible. What people want to do should never relax what the OTP team demonstrably knows best about building high quality systems. They wrote these rules and semantics and if they change them now they will lose their loyal audience of understanding programmers to compromise with those who have yet to learn from their mistakes or embrace Erlang's established methodology for building systems. - A parse_transform handling source code implementing a parameterized module will be published in the public domain, free to use and include in any package needing it. It will however not be part of OTP. As it uses supported and documented functionality, it will however be expected to work for forthcoming releases as well, or at least to be possible to adopt to forthcoming releases. Requiring someone to override the global error handler to do this is more responsible, rather than putting out a yet to be released parameterized module parse transform that will be unsupported, but yet adding a feature hook to hang it on. To quote Charles H. Moore: "Do Not Speculate! Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite" This is how the undefined function should look... hack it to infinity, but on your own: undefined_function(Module, Func, Args) -> case ensure_loaded(Module) of {module, Module} -> case erlang:function_exported(Module, Func, length(Args)) of true -> apply(Module, Func, Args); false -> crash(Module, Func, Args) end; _Other -> crash(Module, Func, Args) end. - As I remember it we got mainly positive reactions regarding this decision and now we have implemented it exactly as said. I understand that, but how big was this audience? And where was it held? Was it perhaps posted on erlang.org with an interactive comments section? - As a consequence of removing parameterized modules from OTP we have changed the error_handler by removing a built in knowledge about parameterized modules Wonderful, this made me so happy. - and by adding a more general and useful functionality, the $handle_undefined_function feature. Ugh, this is syntactical sugar, it takes a step forward and then two backwards- this is sad. - This feature is useful in a number of situations where one was earlier forced to modify the global error_handler: To do unsupported things you naturally should be forced to modify the global error_handler and support it yourself. - Can support the parse-transform for parameterized modules (the -extends attribute) Since one is forced to transform their modules in an unsupported way anyway, you should have no trouble also using an unsupported error_handler supplied with an unsupported parse transform. I've said my peace, the majority of valid uses here are for testing and can be restricted to that.. A stern warning is not enough, theres a warning about using process dictionaries and yet they are used widely in Erlang itself and a lot of good can come from them, but not this. I hope people do not stay neutral on this subject and at least think take a moment and reflect on this situation. [1] Erlang is *NOT* an object oriented language. That's deliberate: the inventors of Erlang were well aware of OO and chose not to use it. http://erlang.org/pipermail/erlang-questions/2013-January/071901.html [2] Why OO was popular? Reason 1 ? It was thought to be easy to learn. Reason 2 ? It was thought to make code reuse easier. Reason 3 ? It was hyped. Reason 4 ? It created a new software industry. I see no evidence of 1 and 2. Reasons seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money. On Wed, Jan 23, 2013 at 7:06 AM, Ulf Wiger wrote: > > On 23 Jan 2013, at 12:47, H?kan Mattsson wrote: > >> Depends on what you mean with "allowed". With open source code >> you are "allowed" to do a lot. This does not necessarily mean that >> it is a good idea to do it. > > Nor that you *have* to do it. :) > > I think that Kenneth has presented a pretty good argument > for why they want to introduce this functionality, and also > reminded us that their past decision was received > favourably. > > We should not feel forced to make clever uses of this new > feature, just because the OTP team feels that it is needed > at their level. Even so, if we do feel so compelled, you are > definitely allowed to. ;-) > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > -- /* Sincerely -------------------------------------------------------------- Pedram Nimreezi - Chief Technology Officer */ // The hardest part of design ? is keeping features out. - Donald Norman From nico.kruber@REDACTED Fri Jan 25 16:33:44 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Fri, 25 Jan 2013 16:33:44 +0100 Subject: [erlang-patches] JInterface: don't compress external binary format if this increases the size Message-ID: <3359360.noqRQkiCIx@csr-pc40.zib.de> Hi all, recently, I noticed, that if I compress an erlang term from Java to external binary format, e.g. "[]" (empty list), it is larger than the result returned by term_to_binary/2 with compression activated, e.g. term_to_binary([], [compressed,6}]). I digged a bit deeper and saw that erts_term_to_binary in external.c covers that case and if a compressed external term would be bigger than the uncompressed version, it returns the uncompressed one. Please have a look: https://github.com/NicoK/otp/compare/maint...maint_jinterface.dont_compress_if_size_increased https://github.com/NicoK/otp/compare/maint...maint_jinterface.dont_compress_if_size_increased.patch Nico From magnus@REDACTED Fri Jan 25 18:01:39 2013 From: magnus@REDACTED (Magnus Henoch) Date: Fri, 25 Jan 2013 17:01:39 +0000 Subject: [erlang-patches] Improve error message for duplicate node name Message-ID: I'm sure you've seen this error message once too many: {error_logger,{{2013,1,25},{16,0,42}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1,[{file,"inet_tcp_dist.erl"},{line,70}]},{net_kernel,start_protos,4,[{file,"net_kernel.erl"},{line,1314}]},{net_kernel,start_protos,3,[{file,"net_kernel.erl"},{line,1307}]},{net_kernel,init_node,2,[{file,"net_kernel.erl"},{line,1197}]},{net_kernel,init,1,[{file,"net_kernel.erl"},{line,357}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,297}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}]} With this patch, you can get this message instead: {error_logger,{{2013,1,25},{16,40,41}},"Protocol: ~tp: the name foo@REDACTED seems to be in use by another Erlang node",["inet_tcp"]} git fetch git://github.com/legoscia/otp.git duplicate_name_error_message https://github.com/legoscia/otp/compare/erlang:master...legoscia:duplicate_name_error_message https://github.com/legoscia/otp/compare/erlang:master...legoscia:duplicate_name_error_message.patch Regards, Magnus From carlsson.richard@REDACTED Sat Jan 26 22:47:54 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Sat, 26 Jan 2013 22:47:54 +0100 Subject: [erlang-patches] break out assert macros from eunit Message-ID: <51044F0A.6070902@gmail.com> (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 From fredrik@REDACTED Mon Jan 28 10:26:53 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 28 Jan 2013 10:26:53 +0100 Subject: [erlang-patches] Improve error message for duplicate node name In-Reply-To: References: Message-ID: <5106445D.7010402@erlang.org> On 01/25/2013 06:01 PM, Magnus Henoch wrote: > git fetch git://github.com/legoscia/otp.git duplicate_name_error_message Your patch is now cooking in 'master-pu' branch. Thanks. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Jan 28 10:28:54 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 28 Jan 2013 10:28:54 +0100 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <51044F0A.6070902@gmail.com> References: <51044F0A.6070902@gmail.com> Message-ID: <510644D6.20704@erlang.org> On 01/26/2013 10:47 PM, Richard Carlsson wrote: > git fetch git://github.com/richcarl/otp.git break-out-asserts Your patch is now cooking in the 'master-pu' branch. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Mon Jan 28 11:00:18 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 28 Jan 2013 11:00:18 +0100 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <51044F0A.6070902@gmail.com> References: <51044F0A.6070902@gmail.com> Message-ID: <51064C32.3030309@erlang.org> 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? -- BR Fredrik Gustafsson Erlang OTP Team From carlsson.richard@REDACTED Mon Jan 28 11:27:35 2013 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Mon, 28 Jan 2013 11:27:35 +0100 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <51064C32.3030309@erlang.org> References: <51044F0A.6070902@gmail.com> <51064C32.3030309@erlang.org> Message-ID: <51065297.3060300@gmail.com> 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? > From fredrik@REDACTED Mon Jan 28 11:58:35 2013 From: fredrik@REDACTED (Fredrik) Date: Mon, 28 Jan 2013 11:58:35 +0100 Subject: [erlang-patches] break out assert macros from eunit In-Reply-To: <51065297.3060300@gmail.com> References: <51044F0A.6070902@gmail.com> <51064C32.3030309@erlang.org> <51065297.3060300@gmail.com> Message-ID: <510659DB.3060800@erlang.org> 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. -- BR Fredrik Gustafsson Erlang OTP Team From nico.kruber@REDACTED Mon Jan 28 20:13:16 2013 From: nico.kruber@REDACTED (Nico Kruber) Date: Mon, 28 Jan 2013 20:13:16 +0100 Subject: [erlang-patches] JInterface: don't compress external binary format if this increases the size In-Reply-To: <3359360.noqRQkiCIx@csr-pc40.zib.de> References: <3359360.noqRQkiCIx@csr-pc40.zib.de> Message-ID: <10877060.9jAMeuzdhF@csr-pc40.zib.de> On Friday 25 Jan 2013 16:33:44 you wrote: > Hi all, > recently, I noticed, that if I compress an erlang term from Java to external > binary format, e.g. "[]" (empty list), it is larger than the result > returned by term_to_binary/2 with compression activated, e.g. > term_to_binary([], [compressed,6}]). > > I digged a bit deeper and saw that erts_term_to_binary in external.c covers > that case and if a compressed external term would be bigger than the > uncompressed version, it returns the uncompressed one. > > Please have a look: > https://github.com/NicoK/otp/compare/maint...maint_jinterface.dont_compress_if_size_increased > https://github.com/NicoK/otp/compare/maint...maint_jinterface.dont_compress_if_size_increased.patch > > > Nico Turns out, it wasn't just as simple as I thought - but after my latest additions in the above-mentioned branches, everything should be fine again. And while I was at it, I also added a method where you can specify the compression level. Nico From anders.gs.svensson@REDACTED Tue Jan 29 09:32:17 2013 From: anders.gs.svensson@REDACTED (anders.gs.svensson@REDACTED) Date: Tue, 29 Jan 2013 09:32:17 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> Message-ID: <20743.35089.222677.596222@glorung.otp.ericsson.se> Anthony Ramine writes: > Hi, > > I've added a commit that document output.mk.in as requested; > please refetch. > > Anders, please tell me if things aren't clear enough and you want > me to rewrite/detail. Sorry for the slow reply. The description itself is fine but I can't say I think that manually specifying what should be echoed in each individual makefile is a good idea. If the verbosity is controlled by the value of V (if I understand correctly), why can't you implement something like this in otp.mk, by adding the appropriate command prefix to the relevant compiler macros? Anders > > Regards, > > -- > Anthony Ramine > > Le 19 janv. 2013 ? 12:15, Anthony Ramine a ?crit : > > > Hi, > > > > I've recreated the branch with two new commits, adding support of silent rules > > in wx and when running ./otp_build tests. > > > > Please refetch. > > > > Regards, > > > > -- > > Anthony Ramine > > > > Le 18 janv. 2013 ? 14:43, Bj?rn-Egil Dahlberg a ?crit : > > > >> Patch merged. > >> Closing issue designated OTP-10726. > >> > >> // Bj?rn-Egil > >> > >> On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: > >>> On 2013-01-15 21:46, Anthony Ramine wrote: > >>>> I couldn't reproduce the bug here but apparently I've found the cause of it. > >>> Looking good. > >>> > >>> Putting it into master-opu integration branch. > >>> > >>> Will be merged later this week if no other issues appear. > >>> > >>> // Bj?rn-Egil > >>> > >>>> > >>>> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): > >>>> > >>>>> Using the MAKE variable has the same effect as using a ?+? character > >>>>> at the beginning of the recipe line. See Instead of Executing the > >>>>> Recipes. This special feature is only enabled if the MAKE variable > >>>>> appears directly in the recipe: it does not apply if the MAKE variable > >>>>> is referenced through expansion of another variable. In the latter > >>>>> case you must use the ?+? token to get these special effects. > >>>> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable > >>>> > >>>> Please refetch. > >>>> > >>>> Regards, > >>>> > >>> > >>> _______________________________________________ > >>> 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 Tue Jan 29 09:45:54 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Jan 2013 09:45:54 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <20743.35089.222677.596222@glorung.otp.ericsson.se> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> Message-ID: <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> Do you mean actually including the prefix to CC, LD, ERLC and their friends? First that would make me unable to print ASN1 or YECC instead of ERLC when the target isn't a .beam file; second that would break the expectation of the users that CC, LD, ERLC and the other variables are just paths to compilers. -- Anthony Ramine Le 29 janv. 2013 ? 09:32, a ?crit : > Anthony Ramine writes: >> Hi, >> >> I've added a commit that document output.mk.in as requested; >> please refetch. >> >> Anders, please tell me if things aren't clear enough and you want >> me to rewrite/detail. > > Sorry for the slow reply. > > The description itself is fine but I can't say I think that manually > specifying what should be echoed in each individual makefile is a good > idea. If the verbosity is controlled by the value of V (if I > understand correctly), why can't you implement something like this in > otp.mk, by adding the appropriate command prefix to the relevant > compiler macros? > > Anders > > > >> >> Regards, >> >> -- >> Anthony Ramine >> >> Le 19 janv. 2013 ? 12:15, Anthony Ramine a ?crit : >> >>> Hi, >>> >>> I've recreated the branch with two new commits, adding support of silent rules >>> in wx and when running ./otp_build tests. >>> >>> Please refetch. >>> >>> Regards, >>> >>> -- >>> Anthony Ramine >>> >>> Le 18 janv. 2013 ? 14:43, Bj?rn-Egil Dahlberg a ?crit : >>> >>>> Patch merged. >>>> Closing issue designated OTP-10726. >>>> >>>> // Bj?rn-Egil >>>> >>>> On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: >>>>> On 2013-01-15 21:46, Anthony Ramine wrote: >>>>>> I couldn't reproduce the bug here but apparently I've found the cause of it. >>>>> Looking good. >>>>> >>>>> Putting it into master-opu integration branch. >>>>> >>>>> Will be merged later this week if no other issues appear. >>>>> >>>>> // Bj?rn-Egil >>>>> >>>>>> >>>>>> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): >>>>>> >>>>>>> Using the MAKE variable has the same effect as using a ?+? character >>>>>>> at the beginning of the recipe line. See Instead of Executing the >>>>>>> Recipes. This special feature is only enabled if the MAKE variable >>>>>>> appears directly in the recipe: it does not apply if the MAKE variable >>>>>>> is referenced through expansion of another variable. In the latter >>>>>>> case you must use the ?+? token to get these special effects. >>>>>> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable >>>>>> >>>>>> Please refetch. >>>>>> >>>>>> Regards, >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 fredrik@REDACTED Tue Jan 29 10:05:40 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 29 Jan 2013 10:05:40 +0100 Subject: [erlang-patches] JInterface: don't compress external binary format if this increases the size In-Reply-To: <10877060.9jAMeuzdhF@csr-pc40.zib.de> References: <3359360.noqRQkiCIx@csr-pc40.zib.de> <10877060.9jAMeuzdhF@csr-pc40.zib.de> Message-ID: <510790E4.20405@erlang.org> On 01/28/2013 08:13 PM, Nico Kruber wrote: > On Friday 25 Jan 2013 16:33:44 you wrote: >> Hi all, >> recently, I noticed, that if I compress an erlang term from Java to external >> binary format, e.g. "[]" (empty list), it is larger than the result >> returned by term_to_binary/2 with compression activated, e.g. >> term_to_binary([], [compressed,6}]). >> >> I digged a bit deeper and saw that erts_term_to_binary in external.c covers >> that case and if a compressed external term would be bigger than the >> uncompressed version, it returns the uncompressed one. >> >> Please have a look: >> https://github.com/NicoK/otp/compare/maint...maint_jinterface.dont_compress_if_size_increased >> https://github.com/NicoK/otp/compare/maint...maint_jinterface.dont_compress_if_size_increased.patch >> >> >> Nico > Turns out, it wasn't just as simple as I thought - but after my latest additions in the above-mentioned branches, everything should be fine again. > And while I was at it, I also added a method where you can specify the compression level. > > > Nico > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Your patch is now cooking in the 'master-pu' branch. -- BR Fredrik Gustafsson Erlang OTP Team From anders.gs.svensson@REDACTED Tue Jan 29 10:16:20 2013 From: anders.gs.svensson@REDACTED (anders.gs.svensson@REDACTED) Date: Tue, 29 Jan 2013 10:16:20 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> Message-ID: <20743.37732.95552.332115@glorung.otp.ericsson.se> Anthony Ramine writes: > Do you mean actually including the prefix to CC, LD, ERLC and their friends? Yes. > First that would make me unable to print ASN1 or YECC instead of ERLC when > the target isn't a .beam file; second that would break the expectation of You could sed something appropriate out of $@, or just echo the target. > the users that CC, LD, ERLC and the other variables are just paths to > compilers. That is ends with a path is an expectation, not sure how many assume that it's only a path. I just think that the support will degenerate and/or be inconsistently used as long as its maintained in application makefiles. Anders > > -- > Anthony Ramine > > Le 29 janv. 2013 ? 09:32, a ?crit : > > > Anthony Ramine writes: > >> Hi, > >> > >> I've added a commit that document output.mk.in as requested; > >> please refetch. > >> > >> Anders, please tell me if things aren't clear enough and you want > >> me to rewrite/detail. > > > > Sorry for the slow reply. > > > > The description itself is fine but I can't say I think that manually > > specifying what should be echoed in each individual makefile is a good > > idea. If the verbosity is controlled by the value of V (if I > > understand correctly), why can't you implement something like this in > > otp.mk, by adding the appropriate command prefix to the relevant > > compiler macros? > > > > Anders > > > > > > > >> > >> Regards, > >> > >> -- > >> Anthony Ramine > >> > >> Le 19 janv. 2013 ? 12:15, Anthony Ramine a ?crit : > >> > >>> Hi, > >>> > >>> I've recreated the branch with two new commits, adding support of silent rules > >>> in wx and when running ./otp_build tests. > >>> > >>> Please refetch. > >>> > >>> Regards, > >>> > >>> -- > >>> Anthony Ramine > >>> > >>> Le 18 janv. 2013 ? 14:43, Bj?rn-Egil Dahlberg a ?crit : > >>> > >>>> Patch merged. > >>>> Closing issue designated OTP-10726. > >>>> > >>>> // Bj?rn-Egil > >>>> > >>>> On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: > >>>>> On 2013-01-15 21:46, Anthony Ramine wrote: > >>>>>> I couldn't reproduce the bug here but apparently I've found the cause of it. > >>>>> Looking good. > >>>>> > >>>>> Putting it into master-opu integration branch. > >>>>> > >>>>> Will be merged later this week if no other issues appear. > >>>>> > >>>>> // Bj?rn-Egil > >>>>> > >>>>>> > >>>>>> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): > >>>>>> > >>>>>>> Using the MAKE variable has the same effect as using a ?+? character > >>>>>>> at the beginning of the recipe line. See Instead of Executing the > >>>>>>> Recipes. This special feature is only enabled if the MAKE variable > >>>>>>> appears directly in the recipe: it does not apply if the MAKE variable > >>>>>>> is referenced through expansion of another variable. In the latter > >>>>>>> case you must use the ?+? token to get these special effects. > >>>>>> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable > >>>>>> > >>>>>> Please refetch. > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Tue Jan 29 10:57:10 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Jan 2013 10:57:10 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <20743.37732.95552.332115@glorung.otp.ericsson.se> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> <20743.37732.95552.332115@glorung.otp.ericsson.se> Message-ID: V_CC and its friends are not valid shells commands as they may start with an @, I don't think CC itself should behave the same way. The maintainability shouldn't be a concern as only people in the know ever touch these makefiles anyway, and no one should modify them without looking at the other targets and commands for inspiration and code consistency. That being said, I won't take it personally if the patch is reverted, but Bjorn-Egil himself seems to quite like it :) -- Anthony Ramine Le 29 janv. 2013 ? 10:16, a ?crit : > Anthony Ramine writes: >> Do you mean actually including the prefix to CC, LD, ERLC and their friends? > > Yes. > >> First that would make me unable to print ASN1 or YECC instead of ERLC when >> the target isn't a .beam file; second that would break the expectation of > > You could sed something appropriate out of $@, or just echo the > target. > >> the users that CC, LD, ERLC and the other variables are just paths to >> compilers. > > That is ends with a path is an expectation, not sure how many assume > that it's only a path. > > I just think that the support will degenerate and/or be inconsistently > used as long as its maintained in application makefiles. > > Anders > > > >> >> -- >> Anthony Ramine >> >> Le 29 janv. 2013 ? 09:32, a ?crit : >> >>> Anthony Ramine writes: >>>> Hi, >>>> >>>> I've added a commit that document output.mk.in as requested; >>>> please refetch. >>>> >>>> Anders, please tell me if things aren't clear enough and you want >>>> me to rewrite/detail. >>> >>> Sorry for the slow reply. >>> >>> The description itself is fine but I can't say I think that manually >>> specifying what should be echoed in each individual makefile is a good >>> idea. If the verbosity is controlled by the value of V (if I >>> understand correctly), why can't you implement something like this in >>> otp.mk, by adding the appropriate command prefix to the relevant >>> compiler macros? >>> >>> Anders >>> >>> >>> >>>> >>>> Regards, >>>> >>>> -- >>>> Anthony Ramine >>>> >>>> Le 19 janv. 2013 ? 12:15, Anthony Ramine a ?crit : >>>> >>>>> Hi, >>>>> >>>>> I've recreated the branch with two new commits, adding support of silent rules >>>>> in wx and when running ./otp_build tests. >>>>> >>>>> Please refetch. >>>>> >>>>> Regards, >>>>> >>>>> -- >>>>> Anthony Ramine >>>>> >>>>> Le 18 janv. 2013 ? 14:43, Bj?rn-Egil Dahlberg a ?crit : >>>>> >>>>>> Patch merged. >>>>>> Closing issue designated OTP-10726. >>>>>> >>>>>> // Bj?rn-Egil >>>>>> >>>>>> On 2013-01-16 14:59, Bj?rn-Egil Dahlberg wrote: >>>>>>> On 2013-01-15 21:46, Anthony Ramine wrote: >>>>>>>> I couldn't reproduce the bug here but apparently I've found the cause of it. >>>>>>> Looking good. >>>>>>> >>>>>>> Putting it into master-opu integration branch. >>>>>>> >>>>>>> Will be merged later this week if no other issues appear. >>>>>>> >>>>>>> // Bj?rn-Egil >>>>>>> >>>>>>>> >>>>>>>> I've removed $(V_MAKE) and put back $(make_verbose)$(MAKE): >>>>>>>> >>>>>>>>> Using the MAKE variable has the same effect as using a ?+? character >>>>>>>>> at the beginning of the recipe line. See Instead of Executing the >>>>>>>>> Recipes. This special feature is only enabled if the MAKE variable >>>>>>>>> appears directly in the recipe: it does not apply if the MAKE variable >>>>>>>>> is referenced through expansion of another variable. In the latter >>>>>>>>> case you must use the ?+? token to get these special effects. >>>>>>>> http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable >>>>>>>> >>>>>>>> Please refetch. >>>>>>>> >>>>>>>> Regards, >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 tuncer.ayaz@REDACTED Tue Jan 29 11:01:22 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 29 Jan 2013 11:01:22 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <20121128163124.GA29480@circlewave.net> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> <20743.37732.95552.332115@glorung.otp.ericsson.se> Message-ID: On Tue, Jan 29, 2013 at 10:57 AM, Anthony Ramine wrote: > V_CC and its friends are not valid shells commands as they may start > with an @, I don't think CC itself should behave the same way. > > The maintainability shouldn't be a concern as only people in the > know ever touch these makefiles anyway, and no one should modify > them without looking at the other targets and commands for > inspiration and code consistency. > > That being said, I won't take it personally if the patch is > reverted, but Bjorn-Egil himself seems to quite like it :) So do I :). From egil@REDACTED Tue Jan 29 12:12:36 2013 From: egil@REDACTED (=?UTF-8?B?QmrDtnJuLUVnaWwgRGFobGJlcmc=?=) Date: Tue, 29 Jan 2013 12:12:36 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> <2 0743.37732.95552.332115@glorung.otp.ericsson.se> Message-ID: <5107AEA4.4080307@erlang.org> On 2013-01-29 10:57, Anthony Ramine wrote: > V_CC and its friends are not valid shells commands as they may start with an @, I don't think CC itself should behave the same way. > > The maintainability shouldn't be a concern as only people in the know ever touch these makefiles anyway, and no one should modify them without looking at the other targets and commands for inspiration and code consistency. > > That being said, I won't take it personally if the patch is reverted, but Bjorn-Egil himself seems to quite like it :) > I think Anders raise an important point of maintainability. If it can be implemented with higher maintainability, perhaps it should be. I like the feature and I do want it. I don't believe it makes that much more difficult to maintain makefiles, but any improvements help. // Bj?rn-Egil From tuncer.ayaz@REDACTED Tue Jan 29 12:31:09 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 29 Jan 2013 12:31:09 +0100 Subject: [erlang-patches] erts: unused fun and var Message-ID: git fetch git://github.com/tuncer/otp.git unused https://github.com/tuncer/otp/compare/master...unused https://github.com/tuncer/otp/compare/master...unused.patch From tuncer.ayaz@REDACTED Tue Jan 29 12:42:05 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 29 Jan 2013 12:42:05 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <5107AEA4.4080307@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> <5107AEA4.4080307@erlang.org> Message-ID: On Tue, Jan 29, 2013 at 12:12 PM, Bj?rn-Egil Dahlberg wrote: > On 2013-01-29 10:57, Anthony Ramine wrote: >> >> V_CC and its friends are not valid shells commands as they may >> start with an @, I don't think CC itself should behave the same >> way. >> >> The maintainability shouldn't be a concern as only people in the >> know ever touch these makefiles anyway, and no one should modify >> them without looking at the other targets and commands for >> inspiration and code consistency. >> >> That being said, I won't take it personally if the patch is >> reverted, but Bjorn-Egil himself seems to quite like it :) >> > I think Anders raise an important point of maintainability. If it > can be implemented with higher maintainability, perhaps it should > be. I like the feature and I do want it. I don't believe it makes > that much more difficult to maintain makefiles, but any improvements > help. I suggest to make such improvements without reverting what's already merged and working. From n.oxyde@REDACTED Tue Jan 29 12:44:55 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 29 Jan 2013 12:44:55 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <5107AEA4.4080307@erlang.org> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> <2 0743.37732.95552.332115@glorung.otp.ericsson.se> <5107AEA4.4080307@erlang.org> Message-ID: <66036E1F-7BA0-4AA7-BCA8-8C40BB1E5F2C@gmail.com> Honestly, the sole improvement that could be done to that feature is not replicating it and using Automake instead. As I said earlier, it would be insane to make CC and LD and ERLC handle silent rules themselves. -- Anthony Ramine Le 29 janv. 2013 ? 12:12, Bj?rn-Egil Dahlberg a ?crit : > On 2013-01-29 10:57, Anthony Ramine wrote: >> V_CC and its friends are not valid shells commands as they may start with an @, I don't think CC itself should behave the same way. >> >> The maintainability shouldn't be a concern as only people in the know ever touch these makefiles anyway, and no one should modify them without looking at the other targets and commands for inspiration and code consistency. >> >> That being said, I won't take it personally if the patch is reverted, but Bjorn-Egil himself seems to quite like it :) >> > I think Anders raise an important point of maintainability. If it can be implemented with higher maintainability, perhaps it should be. I like the feature and I do want it. I don't believe it makes that much more difficult to maintain makefiles, but any improvements help. > > // Bj?rn-Egil From fredrik@REDACTED Tue Jan 29 14:14:02 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 29 Jan 2013 14:14:02 +0100 Subject: [erlang-patches] erts: unused fun and var In-Reply-To: References: Message-ID: <5107CB1A.4030700@erlang.org> On 01/29/2013 12:31 PM, Tuncer Ayaz wrote: > git fetch git://github.com/tuncer/otp.git unused > > https://github.com/tuncer/otp/compare/master...unused > https://github.com/tuncer/otp/compare/master...unused.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Cooking in the 'master-pu' branch. Thanks. -- BR Fredrik Gustafsson Erlang OTP Team From fredrik@REDACTED Tue Jan 29 14:19:13 2013 From: fredrik@REDACTED (Fredrik) Date: Tue, 29 Jan 2013 14:19:13 +0100 Subject: [erlang-patches] erts: unused fun and var In-Reply-To: References: Message-ID: <5107CC51.3010806@erlang.org> On 01/29/2013 12:31 PM, Tuncer Ayaz wrote: > git fetch git://github.com/tuncer/otp.git unused > > https://github.com/tuncer/otp/compare/master...unused > https://github.com/tuncer/otp/compare/master...unused.patch > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Please rebase your patch upon current 'master' branch and fix conflicts. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From tuncer.ayaz@REDACTED Tue Jan 29 14:27:52 2013 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Tue, 29 Jan 2013 14:27:52 +0100 Subject: [erlang-patches] erts: unused fun and var In-Reply-To: <5107CC51.3010806@erlang.org> References: <5107CC51.3010806@erlang.org> Message-ID: On Tue, Jan 29, 2013 at 2:19 PM, Fredrik wrote: > On 01/29/2013 12:31 PM, Tuncer Ayaz wrote: >> >> git fetch git://github.com/tuncer/otp.git unused >> >> https://github.com/tuncer/otp/compare/master...unused >> https://github.com/tuncer/otp/compare/master...unused.patch > > Please rebase your patch upon current 'master' branch and fix > conflicts. Thanks, Looks like Patrik fixed those two months ago and you just pushed them to master. You can drop the branch as it's been obsoleted by Patrik's changes. From bengt.kleberg@REDACTED Tue Jan 29 16:10:19 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 29 Jan 2013 16:10:19 +0100 Subject: [erlang-patches] Question about building documentation as described in https://github.com/erlang/otp/wiki/Documentation Message-ID: <1359472219.4832.115.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, To submit a patch I need to build the documentation. This is just a single module, so I tried to build a single application (stdlib). That failed. It is possible to build all documentation. After that it works to build only stdlib. Perhaps this is the intention? Must I always build everything first? bengt From bengt.kleberg@REDACTED Tue Jan 29 16:50:52 2013 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 29 Jan 2013 16:50:52 +0100 Subject: [erlang-patches] How to get Data Types section in documentation? Message-ID: <1359474652.4832.125.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, What should I do to the module slave.erl to get a Data Types section in the documentation? I am updating the slave module documentation. I have added some data types. There is no Data Types section in the current documentation. As an example of how to do I am looking at the array module. It has a Data types section in the documentation. I can not find anything in array.erl that tells the documentation builder to add the Data Types section. How is it done? For slave.erl I do get a link from my type (lib/stdlib-1.19/doc/html/slave.html#type-start_options), but there is no target for that link. bengt From wallentin.dahlberg@REDACTED Tue Jan 29 19:20:35 2013 From: wallentin.dahlberg@REDACTED (=?ISO-8859-1?Q?Bj=F6rn=2DEgil_Dahlberg?=) Date: Tue, 29 Jan 2013 19:20:35 +0100 Subject: [erlang-patches] Implement ./otp_build configure --enable-silent-rules In-Reply-To: <66036E1F-7BA0-4AA7-BCA8-8C40BB1E5F2C@gmail.com> References: <22B4C91F-13C6-4899-9DD9-8A1566146848@gmail.com> <50F046A1.6010706@erlang.org> <254BBB42-469D-438E-A548-87EC6A23D7A2@gmail.com> <50F04E8C.1080800@erlang.org> <3E65AF14-8CF7-4724-BD4B-D6454D72EDB6@gmail.com> <50F05B1D.3090906@erlang.org> <3DAB7579-C3C8-4C76-AAF0-CCDDBCDC29B0@gmail.com> <50F4169F.1010703@erlang.org> <50F420AF.8080605@erlang.org> <8D86D323-37AB-4282-AD9C-FF7558F3F98C@gmail.com> <50F59AC1.6050403@erlang.org> <-4800465672858183043@unknownmsgid> <62AC0439-A8F4-4E6E-93D3-5A4D9E9AC014@gmail.com> <50F6B25C.6090006@erlang.org> <50F9516A.3080109@erlang.org> <6D2BFAC9-B017-42C1-A847-B345FB0F9606@gmail.com> <20743.35089.222677.596222@glorung.otp.ericsson.se> <739520E1-0216-4803-A4C9-5F7C598B13C9@gmail.com> <5107AEA4.4080307@erlang.org> <66036E1F-7BA0-4AA7-BCA8-8C40BB1E5F2C@gmail.com> Message-ID: This would be less of an issue if we didn't put all application eggs in one repository basket. I'm probably preaching that sentence to the choir here .. I've never suggested it should be reverted. I'm merely stating that if it *could* be sanely implemented in a more maintain friendly way, it should be. I'll let Anders and Anthony ponder this a bit. // Bj?rn-Egil 2013/1/29 Anthony Ramine > Honestly, the sole improvement that could be done to that feature is not > replicating it and using Automake instead. As I said earlier, it would be > insane to make CC and LD and ERLC handle silent rules themselves. > > -- > Anthony Ramine > > Le 29 janv. 2013 ? 12:12, Bj?rn-Egil Dahlberg a ?crit : > > > On 2013-01-29 10:57, Anthony Ramine wrote: > >> V_CC and its friends are not valid shells commands as they may start > with an @, I don't think CC itself should behave the same way. > >> > >> The maintainability shouldn't be a concern as only people in the know > ever touch these makefiles anyway, and no one should modify them without > looking at the other targets and commands for inspiration and code > consistency. > >> > >> That being said, I won't take it personally if the patch is reverted, > but Bjorn-Egil himself seems to quite like it :) > >> > > I think Anders raise an important point of maintainability. If it can be > implemented with higher maintainability, perhaps it should be. I like the > feature and I do want it. I don't believe it makes that much more difficult > to maintain makefiles, but any improvements help. > > > > // Bj?rn-Egil > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed Jan 30 15:16:49 2013 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 30 Jan 2013 15:16:49 +0100 Subject: [erlang-patches] Some cleanups in kernel files In-Reply-To: <50D31A63.9000706@erlang.org> References: <50D077FD.5060308@cs.ntua.gr> <50D31A63.9000706@erlang.org> Message-ID: <51092B51.6030102@cs.ntua.gr> On 12/20/2012 03:02 PM, Fredrik wrote: > Hello Kostis, > There has been raised some questions regarding this patch from the OTP team. > In this commit: > https://github.com/kostis/otp/commit/3a13b7a1e1bdd48b0293fc7366c3d133abf845bd > You are returning 'ok' from a case clause which does not an affect on > the returned value, > > {noreply, S}; > > We would like an explanation why this is so important. Replying to this mail has been long on my TODO list but was apparently low priority. Strictly this change is not necessary. However, it shuts off a dialyzer warning when the option -Wunmatched_returns is used (perhaps the name of the option is inaccurate in this case) and makes the code slightly cleaner in the following sense: In a functional language, all expressions have return values which, at least in principle, are produced in order to be consumed somewhere in the continuation. I.e. in a case statement in some function: foo() -> .... SOME CODE ... case ... of PATTERN_1 -> .... LAST_CALL_1; ... PATTERN_N -> .... LAST_CALL_N end, ... MORE CODE ... I think it's a good programming practice that the N branches return some value (such as 'ok') that makes it clear that the return (of the case expression) is to be ignored. This allows for e.g. a transformation that moves the case into some other function if needed, as e.g. in: foo() -> .... SOME CODE ... bar(...), ... MORE CODE ... bar(...) -> case ... of PATTERN_1 -> .... LAST_CALL_1; ... PATTERN_N -> .... LAST_CALL_N end. and does not result in unmatched return warnings. An alternative to the above is of course to "consume" the return value of the case statement as in: foo() -> .... SOME CODE ... _ = case ... of PATTERN_1 -> .... LAST_CALL_1; ... PATTERN_N -> .... LAST_CALL_N end, ... MORE CODE ... Hope this explains the issue. By the way, I do not have a strong opinion on whether this patch should be included as is, but I do have a request that at least the "main" OTP applications, such as kernel in this case, soon become free of unmatched return dialyzer warnings. This patch is just a step in this direction. Kostis > On 12/18/2012 03:04 PM, Kostis Sagonas wrote: >> The code in some kernel modules has been cleaned up so that functions >> do not return terms of wrong type by accident (most notably by having >> a call to !/2 in a return position) and so that language constructs >> that reflect in a more accurate way the program's intention are used. >> >> Please include: >> >> git fetch git://github.com/kostis/otp.git kernel-cleanup >> >> Kostis >> _______________________________________________ >> erlang-patches mailing list >> erlang-patches@REDACTED >> http://erlang.org/mailman/listinfo/erlang-patches > From jose.valim@REDACTED Wed Jan 30 19:07:47 2013 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Wed, 30 Jan 2013 11:07:47 -0700 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: <50EE9328.30402@erlang.org> References: <50EE8DB0.4020906@erlang.org> <50EE9328.30402@erlang.org> Message-ID: Hello OTP team, congratulations on the release! I have noticed that the cover bug fixes were not included in R16A. Is there something pending that I could do? Thank you, *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Thu, Jan 10, 2013 at 3:08 AM, Fredrik wrote: > Great, I'll re-fetch this. > Thanks for your contribution! > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 11:04 AM, Jos? Valim wrote: > > Anyway, here are the patches without ?line. > > git fetch git://github.com/josevalim/otp.git cover-patches-no-line > > https://github.com/josevalim/otp/compare/cover-patches-no-line > https://github.com/josevalim/otp/compare/cover-patches-no-line.patch > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jan 10, 2013 at 10:53 AM, Jos? Valim < > jose.valim@REDACTED> wrote: > >> I have added ?line to keep consistent with the remaining of the test >> file. Do you want me to go ahead and remove ?line from the whole * >> lib/tools/test/cover_SUITE.erl* file or this is something you have >> already done internally and I should remove just the ones in my patch? >> >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> On Thu, Jan 10, 2013 at 10:45 AM, Fredrik wrote: >> >>> Hello, >>> Your patch has been into review and the feedback you got back was that >>> everything looks good but you have to remove the '?line' macros, because >>> they are not used and thus has no effect anymore. >>> Please fix this and give me a notice when it is done >>> >>> BR Fredrik Gustafsson >>> Erlang OTP Team >>> >>> On 11/28/2012 02:11 PM, Jos? Valim wrote: >>> >>> Hello, >>> >>> I am sending a couple bug fixes for cover. >>> >>> I have broken those fixes into three granular commits. >>> The commit messages contains the rationale behind them. >>> >>> One of the commits changes cover to get the source from >>> "Module:module_info(compile)" if the current heuristic that >>> traverses directories fails. In my opinion, we could rely >>> solely on the source information and remove the heuristic >>> completely but I have kept the current heuristic as the first >>> mechanism in order to minimize the impact of the changes. >>> >>> As such, I would appreciate if those changes could be merged >>> into maint. :) >>> >>> git fetch git://github.com/josevalim/otp.git cover-patches >>> >>> https://github.com/josevalim/otp/compare/cover-patches >>> https://github.com/josevalim/otp/compare/cover-patches.patch >>> >>> Thank you, >>> >>> >>> *Jos? Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Lead Developer >>> >>> >>> >>> _______________________________________________ >>> erlang-patches mailing listerlang-patches@REDACTED://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 fredrik@REDACTED Thu Jan 31 09:48:57 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 31 Jan 2013 09:48:57 +0100 Subject: [erlang-patches] Bug fixes for cover In-Reply-To: References: <50EE8DB0.4020906@erlang.org> <50EE9328.30402@erlang.org> Message-ID: <510A2FF9.4040402@erlang.org> I just got clearance on the review so I will try to merge to a coming release. I'm sorry for the delay. On 01/30/2013 07:07 PM, Jos? Valim wrote: > Hello OTP team, congratulations on the release! > > I have noticed that the cover bug fixes were not included in R16A. > > Is there something pending that I could do? > > Thank you, > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Jan 10, 2013 at 3:08 AM, Fredrik > wrote: > > Great, I'll re-fetch this. > Thanks for your contribution! > > > BR Fredrik Gustafsson > Erlang OTP Team > On 01/10/2013 11:04 AM, Jos? Valim wrote: >> Anyway, here are the patches without ?line. >> >> git fetch git://github.com/josevalim/otp.git >> cover-patches-no-line >> >> https://github.com/josevalim/otp/compare/cover-patches-no-line >> https://github.com/josevalim/otp/compare/cover-patches-no-line.patch >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> On Thu, Jan 10, 2013 at 10:53 AM, Jos? Valim >> > > wrote: >> >> I have added ?line to keep consistent with the remaining of >> the test file. Do you want me to go ahead and remove ?line >> from the whole /lib/tools/test/cover_SUITE.erl/ file or this >> is something you have already done internally and I should >> remove just the ones in my patch? >> >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> On Thu, Jan 10, 2013 at 10:45 AM, Fredrik > > wrote: >> >> Hello, >> Your patch has been into review and the feedback you got >> back was that everything looks good but you have to >> remove the '?line' macros, because they are not used and >> thus has no effect anymore. >> Please fix this and give me a notice when it is done >> >> BR Fredrik Gustafsson >> Erlang OTP Team >> >> On 11/28/2012 02:11 PM, Jos? Valim wrote: >>> Hello, >>> >>> I am sending a couple bug fixes for cover. >>> >>> I have broken those fixes into three granular commits. >>> The commit messages contains the rationale behind them. >>> >>> One of the commits changes cover to get the source from >>> "Module:module_info(compile)" if the current heuristic that >>> traverses directories fails. In my opinion, we could rely >>> solely on the source information and remove the heuristic >>> completely but I have kept the current heuristic as the >>> first >>> mechanism in order to minimize the impact of the changes. >>> >>> As such, I would appreciate if those changes could be merged >>> into maint. :) >>> >>> git fetch git://github.com/josevalim/otp.git >>> cover-patches >>> >>> https://github.com/josevalim/otp/compare/cover-patches >>> https://github.com/josevalim/otp/compare/cover-patches.patch >>> >>> Thank you, >>> >>> >>> *Jos? Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Lead Developer >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> > > -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: