From vinoski@REDACTED Tue Apr 1 02:53:40 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Mon, 31 Mar 2014 20:53:40 -0400 Subject: [erlang-patches] [erlang-bugs] Minor issue: Bad arity display for crypto:hash_update in R16-B03-1 In-Reply-To: <007301cf4d1c$ec4b13c0$c4e13b40$@luxoft.com> References: <007301cf4d1c$ec4b13c0$c4e13b40$@luxoft.com> Message-ID: On Mon, Mar 31, 2014 at 4:08 PM, Alexei Dodon wrote: > When using deprecated crypto functions, warnings are displayed suggesting > use of recommended functions. > > Use of crypto:hash_update/3 is recommended in a warning message , but > arity of crypto:hash_update is 2 (not 3). > > > > Example: > > Erlang R16B03-1 (erts-5.10.4) [source] [async-threads:10] > [kernel-poll:false] > > > > Eshell V5.10.4 (abort with ^G) > > 1> c(to_reproduce). > > to_reproduce.erl:5: Warning: crypto:md5_init/0 is deprecated and will be > removed in in a future release; use crypto:hash_init/1 > > to_reproduce.erl:6: Warning: crypto:md5_update/2 is deprecated and will be > removed in in a future release; use crypto:hash_update/3 > > {ok,to_reproduce} > > 2> to_reproduce:start(). > > <<1,35,69,103,137,171,205,239,254,220,186,152,118,84,50, > > 16,64,0,0,0,0,0,0,0,83,111,109,101,68,...>> > > 3> crypto:hash > > hash/2 hash_final/1 hash_init/1 hash_update/2 > > 3> crypto:hash > Here's a fix: https://github.com/erlang/otp/pull/322 --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothma@REDACTED Tue Apr 1 12:43:33 2014 From: jbothma@REDACTED (JD Bothma) Date: Tue, 1 Apr 2014 12:43:33 +0200 Subject: [erlang-patches] Fix erlang:now/0 to be bigger_than_last_time/0 Message-ID: This patch tries to improve the name of erlang:now/0 to make its behaviour a little more obvious for the sake of least surprise. It's a breaking change, but I really think it's worth it to reduce confusion. This is only the first step - if you think it looks ok I can do the rest. git fetch git://github.com/jbothma/otp.git fix-erlang-now-name https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name.patch All the best JD -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Tue Apr 1 13:26:26 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 1 Apr 2014 07:26:26 -0400 Subject: [erlang-patches] Fix erlang:now/0 to be bigger_than_last_time/0 In-Reply-To: References: Message-ID: <20140401112625.GD77980@ferdmbp.local> Why I agree: - Backwards compatibility and proper deprecation is annoying, not a convenience. It is far more confusing to have a function relating to time named 'now' than having breaking changes in your code, no matter how well-documented it is. - The name you chose is less descriptive than before (it no longer relates to time), which forces people to look inside docs, which is great. I love documentation. - You orphaned a bunch of names in other modules, namely: - timer:now_diff/2 - calendar:now_to_local_time/1 - calendar:now_to_universal_time/1 - calendar:now_to_datetime/1 Which logically now need to be renamed: - timer:bigger_than_last_time_diff/1 - calendar:bigger_than_last_time_to_local_time/1 - calendar:bigger_than_last_time_to_universal_time/1 - calendar:bigger_than_last_time_to_datetime/1 I always felt calendar had way too short names and believe this is an improvement for the better in the long term. - Today is the best day for this change to happen, definitely. Regards, Fred. On 04/01, JD Bothma wrote: > This patch tries to improve the name of erlang:now/0 to make its behaviour > a little more obvious for the sake of least surprise. It's a breaking > change, but I really think it's worth it to reduce confusion. > > This is only the first step - if you think it looks ok I can do the rest. > > git fetch git://github.com/jbothma/otp.git fix-erlang-now-name > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name.patch > > All the best > JD > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches From roberto.aloi@REDACTED Tue Apr 1 13:48:24 2014 From: roberto.aloi@REDACTED (Roberto Aloi) Date: Tue, 1 Apr 2014 13:48:24 +0200 (CEST) Subject: [erlang-patches] Fix erlang:now/0 to be bigger_than_last_time/0 In-Reply-To: <20140401112625.GD77980@ferdmbp.local> References: <20140401112625.GD77980@ferdmbp.local> Message-ID: <1492034023.420361.1396352904351.JavaMail.zimbra@erlang-solutions.com> Hi all, Since we're planning backward-incompatible changes to the calendar module, I'd like to use this opportunity to replace Gregorian seconds with Ulfian seconds. Even if the Gregorian calendar has been the unofficial global standard for decades, this would be a great sign of respect to Ulf Wiger, who gave so much to the Erlang community. "ulfian" is also shorter than "gregorian" and easier to type, even without a Dvorak keyboard. Finally, this would also be a crucial step in the process of de-Christianization of the Erlang programming language. Kind regards, Roberto Aloi ----- Original Message ----- > Why I agree: > > - Backwards compatibility and proper deprecation is annoying, not a > convenience. It is far more confusing to have a function relating to > time named 'now' than having breaking changes in your code, no matter > how well-documented it is. > - The name you chose is less descriptive than before (it no longer > relates to time), which forces people to look inside docs, which is > great. I love documentation. > - You orphaned a bunch of names in other modules, namely: > - timer:now_diff/2 > - calendar:now_to_local_time/1 > - calendar:now_to_universal_time/1 > - calendar:now_to_datetime/1 > Which logically now need to be renamed: > - timer:bigger_than_last_time_diff/1 > - calendar:bigger_than_last_time_to_local_time/1 > - calendar:bigger_than_last_time_to_universal_time/1 > - calendar:bigger_than_last_time_to_datetime/1 > I always felt calendar had way too short names and believe this is an > improvement for the better in the long term. > - Today is the best day for this change to happen, definitely. > > Regards, > Fred. > > On 04/01, JD Bothma wrote: > > This patch tries to improve the name of erlang:now/0 to make its behaviour > > a little more obvious for the sake of least surprise. It's a breaking > > change, but I really think it's worth it to reduce confusion. > > > > This is only the first step - if you think it looks ok I can do the rest. > > > > git fetch git://github.com/jbothma/otp.git fix-erlang-now-name > > > > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name > > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name.patch > > > > All the best > > JD > > > _______________________________________________ > > 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 jesper.louis.andersen@REDACTED Tue Apr 1 14:23:41 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 1 Apr 2014 14:23:41 +0200 Subject: [erlang-patches] Fix erlang:now/0 to be bigger_than_last_time/0 In-Reply-To: <1492034023.420361.1396352904351.JavaMail.zimbra@erlang-solutions.com> References: <20140401112625.GD77980@ferdmbp.local> <1492034023.420361.1396352904351.JavaMail.zimbra@erlang-solutions.com> Message-ID: While we are at it, I propose we alter the underlying NIF as well. For a long time, the precision of the soon-to-be-deprecated `erlang:now()` call is way too small. And while it properly compensates for leap seconds and other shenanigans, we can do better. I propose we add support for Hydrogen MASERs[0]. Since a MASER sells for about $235,000 the added precision will greatly enhance Erlang as a language. Once the code is applied, we can remove[1] the old imprecise code. While this might greatly diminish the number of future Erlang installations, I feel it is the right course of action going forward. [0] http://en.wikipedia.org/wiki/Hydrogen_maser [1] As per Fred's suggestion, the right course of action is instant removal since deprecation is a finer weapon for a distant age before Eternal September. On Tue, Apr 1, 2014 at 1:48 PM, Roberto Aloi < roberto.aloi@REDACTED> wrote: > Hi all, > > Since we're planning backward-incompatible changes to the calendar module, > I'd like to use this opportunity to replace Gregorian seconds with Ulfian > seconds. > Even if the Gregorian calendar has been the unofficial global standard for > decades, this would be a great sign of respect to Ulf Wiger, who gave so > much to the Erlang community. > "ulfian" is also shorter than "gregorian" and easier to type, even without > a Dvorak keyboard. > Finally, this would also be a crucial step in the process of > de-Christianization of the Erlang programming language. > > Kind regards, > > Roberto Aloi > > ----- Original Message ----- > > Why I agree: > > > > - Backwards compatibility and proper deprecation is annoying, not a > > convenience. It is far more confusing to have a function relating to > > time named 'now' than having breaking changes in your code, no matter > > how well-documented it is. > > - The name you chose is less descriptive than before (it no longer > > relates to time), which forces people to look inside docs, which is > > great. I love documentation. > > - You orphaned a bunch of names in other modules, namely: > > - timer:now_diff/2 > > - calendar:now_to_local_time/1 > > - calendar:now_to_universal_time/1 > > - calendar:now_to_datetime/1 > > Which logically now need to be renamed: > > - timer:bigger_than_last_time_diff/1 > > - calendar:bigger_than_last_time_to_local_time/1 > > - calendar:bigger_than_last_time_to_universal_time/1 > > - calendar:bigger_than_last_time_to_datetime/1 > > I always felt calendar had way too short names and believe this is an > > improvement for the better in the long term. > > - Today is the best day for this change to happen, definitely. > > > > Regards, > > Fred. > > > > On 04/01, JD Bothma wrote: > > > This patch tries to improve the name of erlang:now/0 to make its > behaviour > > > a little more obvious for the sake of least surprise. It's a breaking > > > change, but I really think it's worth it to reduce confusion. > > > > > > This is only the first step - if you think it looks ok I can do the > rest. > > > > > > git fetch git://github.com/jbothma/otp.git fix-erlang-now-name > > > > > > > > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name > > > > > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name.patch > > > > > > All the best > > > JD > > > > > _______________________________________________ > > > 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 > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Tue Apr 1 15:05:09 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Tue, 1 Apr 2014 15:05:09 +0200 Subject: [erlang-patches] Fwd: FW: Addition of AES-CFB8 cypher In-Reply-To: <58912684E2630B45963406CF7D8C52581C393E22@ESESSMB103.ericsson.se> References: <31E741CCEAAEA641930B48274B5C9840BFC27140@SVLITMX02.shoretel.com> <58912684E2630B45963406CF7D8C52581C393E22@ESESSMB103.ericsson.se> Message-ID: Thank you for your contribution! Since we have already passed the code stop for OTP 17.0, we are going to put this patch in the backlog for a future OTP release. Andreas Schumacher, Erlang/OTP, Ericsson AB *From:* erlang-patches-bounces@REDACTED [mailto: erlang-patches-bounces@REDACTED] *On Behalf Of *Bernie Duggan *Sent:* den 31 mars 2014 11:11 *To:* erlang-patches patches [erlang-patches@REDACTED] *Subject:* [erlang-patches] Addition of AES-CFB8 cypher Hi OTP folks, I recently had cause to use the AES-CFB8 cypher which is currently missing from the crypto module. The attached patch (and associate pull request) adds support for it (assuming there's no reason that it was omitted originally, of course): https://github.com/bernardd/otp/compare/erlang:maint...aes-cfb-8 https://github.com/bernardd/otp/compare/erlang:maint...aes-cfb-8.patch Cheers, Bernard ------------------------------ This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ erlang-patches mailing list erlang-patches@REDACTED http://erlang.org/mailman/listinfo/erlang-patches From me@REDACTED Tue Apr 1 14:59:38 2014 From: me@REDACTED (=?ISO-8859-1?Q?Rikard_Str=F6mmer?=) Date: Tue, 1 Apr 2014 14:59:38 +0200 Subject: [erlang-patches] Solved emacs erlang-mode load Error "File mode specification error:" Message-ID: Release version : latest x64, otp_win64_R16B03. Problem: When first opening an .erl file, you get the error "File mode specification error:" if you use the latest x64 version of Erlang. And the erlang-mode with syntax hi-lighting fails to load on first try. Error: unnecessary font dependency in erlang.el Solution: Line 1067 - 1077 in http://core.st/erlang/erlang.el The fixed file: http://core.st/erlang/erlang.el complete fix + all files for Emacs / Xemacs http://core.st/erlang/tools-2.6.13%20fixed%20erlang%20emacs%20mode.zip Best Regards -- Rikard Str?mmer VD White Falls AB Mobile: +46 73 2542143 www.white-falls.se We build a more fun, greener, richer, better future! Visit our daughter company www.uppdrag-ledning.se to learn how we can help you to create positive change in your business. From brian@REDACTED Wed Apr 2 00:11:46 2014 From: brian@REDACTED (Brian L. Troutwine) Date: Tue, 1 Apr 2014 15:11:46 -0700 Subject: [erlang-patches] Fix erlang:now/0 to be bigger_than_last_time/0 In-Reply-To: References: <20140401112625.GD77980@ferdmbp.local> <1492034023.420361.1396352904351.JavaMail.zimbra@erlang-solutions.com> Message-ID: Friends, I believe, firstly, that we must integrate MASER-accurate time values. This is vital for Erlang?s long-term survival as humanity moves outward into space aboard nuclear-fushion power spacecraft. All watches, in the Glorious Future, will contain cesium clocks and we don?t want to look silly, being less accurate than a wristwatch, do we? ?What use,? future people will ask, ?is this damn language if it loses microulfs of time, relative to my wristwatch?? I believe, secondly, that this patch is too timid. I propose the new name be: bigger_than_last_time_ps_locks_your_vm_hahahaha/0. As we all know, descriptive function names result in reliable software and the _most_ descriptive names are those which bind you to a certain implementation. On Apr 1, 2014, at 5:23, Jesper Louis Andersen wrote: > While we are at it, I propose we alter the underlying NIF as well. For a long time, the precision of the soon-to-be-deprecated `erlang:now()` call is way too small. And while it properly compensates for leap seconds and other shenanigans, we can do better. I propose we add support for Hydrogen MASERs[0]. > > Since a MASER sells for about $235,000 the added precision will greatly enhance Erlang as a language. Once the code is applied, we can remove[1] the old imprecise code. While this might greatly diminish the number of future Erlang installations, I feel it is the right course of action going forward. > > [0] http://en.wikipedia.org/wiki/Hydrogen_maser > [1] As per Fred's suggestion, the right course of action is instant removal since deprecation is a finer weapon for a distant age before Eternal September. > > > > On Tue, Apr 1, 2014 at 1:48 PM, Roberto Aloi wrote: > Hi all, > > Since we're planning backward-incompatible changes to the calendar module, I'd like to use this opportunity to replace Gregorian seconds with Ulfian seconds. > Even if the Gregorian calendar has been the unofficial global standard for decades, this would be a great sign of respect to Ulf Wiger, who gave so much to the Erlang community. > "ulfian" is also shorter than "gregorian" and easier to type, even without a Dvorak keyboard. > Finally, this would also be a crucial step in the process of de-Christianization of the Erlang programming language. > > Kind regards, > > Roberto Aloi > > ----- Original Message ----- > > Why I agree: > > > > - Backwards compatibility and proper deprecation is annoying, not a > > convenience. It is far more confusing to have a function relating to > > time named 'now' than having breaking changes in your code, no matter > > how well-documented it is. > > - The name you chose is less descriptive than before (it no longer > > relates to time), which forces people to look inside docs, which is > > great. I love documentation. > > - You orphaned a bunch of names in other modules, namely: > > - timer:now_diff/2 > > - calendar:now_to_local_time/1 > > - calendar:now_to_universal_time/1 > > - calendar:now_to_datetime/1 > > Which logically now need to be renamed: > > - timer:bigger_than_last_time_diff/1 > > - calendar:bigger_than_last_time_to_local_time/1 > > - calendar:bigger_than_last_time_to_universal_time/1 > > - calendar:bigger_than_last_time_to_datetime/1 > > I always felt calendar had way too short names and believe this is an > > improvement for the better in the long term. > > - Today is the best day for this change to happen, definitely. > > > > Regards, > > Fred. > > > > On 04/01, JD Bothma wrote: > > > This patch tries to improve the name of erlang:now/0 to make its behaviour > > > a little more obvious for the sake of least surprise. It's a breaking > > > change, but I really think it's worth it to reduce confusion. > > > > > > This is only the first step - if you think it looks ok I can do the rest. > > > > > > git fetch git://github.com/jbothma/otp.git fix-erlang-now-name > > > > > > > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name > > > > > > https://github.com/jbothma/otp/compare/erlang:maint...fix-erlang-now-name.patch > > > > > > All the best > > > JD > > > > > _______________________________________________ > > > 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 > > > > -- > J. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Ingela.Anderton.Andin@REDACTED Wed Apr 2 16:31:03 2014 From: Ingela.Anderton.Andin@REDACTED (Ingela Anderton Andin) Date: Wed, 2 Apr 2014 16:31:03 +0200 Subject: [erlang-patches] Fix SSL ETS table element leak and error cleanup Message-ID: <533C1F27.5000905@ericsson.com> Hi! Thank you very much for your effort, however I have already included the reaming part of your patch in 17.0, writing a test case for it myself. It happened to become prioritized and we had not heard anything from you in a long time. I apologizes for the information not reaching the github pull-request immediately, I thought it had (a miss in internal routines, we will make sure it does not happen again). If you had based your branch on master you would have seen it included, and I have thanked you in the release note for your participation. Regards Ingela Erlang/OTP team - Ericsson AB On 03/31/2014 01:58 PM, Henrik Nord wrote: > Thanks! > > As we are already passed the codestop for 17.0 we will put this in the backlog for 17.1. > > Thank you for your contribution! > > On 2014-03-31 13:38, Bernie Duggan wrote: >> Hi Henrik, >> I've trimmed the patch down to just the one remaining problem and (after much boggling over the SSL unit test system) added a unit test that checks the fix. I've rebased it to 'maint' and created a pull request. You can see the change at: >> >> https://github.com/bernardd/otp/compare/erlang:maint...ssl_cert_cache_fix >> https://github.com/bernardd/otp/compare/erlang:maint...ssl_cert_cache_fix.patch >> >> Cheers, >> >> Bernard >> ________________________________________ >> From: Henrik Nord [henrik@REDACTED] >> Sent: Thursday, 6 February 2014 3:27 AM >> To: Bernie Duggan; erlang patches >> Subject: Re: [erlang-patches] Fix SSL ETS table element leak and error cleanup >> >> Hi! >> >> Patch solves two problems, one (trap exit) is already solved in R16B03. >> >> The other part of the patch we do want, but it should be ammended nice >> with a test case. >> >> >> >> On 2013-12-10 05:44, Bernard Duggan wrote: >>> Hi list, >>> The SSL library maintains an internal table of CA certificates >>> (ssl_otp_cacertificate_db). This is supposed to be cleaned up when the >>> last connection using a certificate closes, however there's two problems >>> in R16B02 (and in the current master branch on github): >>> >>> * When CA certificates are provided as binary blobs, rather than by >>> filename (ie, #ssl_options.cacerts is set, but #ssl_options.cacertfile >>> is not) the cleanup never occurs due to an incorrect pattern match in >>> tls_connection:handle_trusted_certs_db/1. This causes the table to grow >>> unchecked because each connection adds a new entry. >>> >>> * When the process exits abnormally, tls_connection:terminate/1 is never >>> called because the trap_exit process flag is not set and so similarly >>> the table (and everything else cleaned in terminate/1, for that matter) >>> is not cleaned up. This doesn't affect "normal" termination caused by >>> the connection closing because terminate/1 is called explicitly from >>> handle_sync_event/4, rather that relying on gen_fsm's automatic calling. >>> >>> Fixes for both are here: >>> >>> git fetch git://github.com/bernardd/otp ssl_cert_cache_fix >>> https://github.com/bernardd/otp/compare/erlang:master...ssl_cert_cache_fix >>> >>> >>> Credit goes to my colleague Nick Marino for doing the initial legwork to >>> track this down. >>> >>> Cheers, >>> >>> Bernard >>> >>> ________________________________ >>> >>> This e-mail and any attachments are confidential. If it is not >>> intended for you, please notify the sender, and please erase and >>> ignore the contents. >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >> -- >> /Henrik Nord Erlang/OTP >> >> >> ________________________________ >> >> This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents. > From andreas@REDACTED Wed Apr 2 18:42:48 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Wed, 2 Apr 2014 18:42:48 +0200 Subject: [erlang-patches] Fwd: FW: Solved emacs erlang-mode load Error "File mode specification error:" In-Reply-To: <58912684E2630B45963406CF7D8C52581C39549C@ESESSMB103.ericsson.se> References: <58912684E2630B45963406CF7D8C52581C39549C@ESESSMB103.ericsson.se> Message-ID: Thank you for your contribution! However, please re-submit the patch, following the Erlang/OTP guidlines for sending patches [1]; e.g., sending the patch as an inline patch compatible with the format generated by git format-patch. Andreas Schumacher, Erlang/OTP, Ericsson AB [1] https://github.com/erlang/otp/wiki/Submitting-patches#sending-the-patch -----Original Message----- From: erlang-patches-bounces@REDACTED [mailto: erlang-patches-bounces@REDACTED] On Behalf Of Rikard Str?mmer Sent: den 1 april 2014 15:00 To: erlang-patches@REDACTED Subject: [erlang-patches] Solved emacs erlang-mode load Error "File mode specification error:" Release version : latest x64, otp_win64_R16B03. Problem: When first opening an .erl file, you get the error "File mode specification error:" if you use the latest x64 version of Erlang. And the erlang-mode with syntax hi-lighting fails to load on first try. Error: unnecessary font dependency in erlang.el Solution: Line 1067 - 1077 in http://core.st/erlang/erlang.el The fixed file: http://core.st/erlang/erlang.el complete fix + all files for Emacs / Xemacs http://core.st/erlang/tools-2.6.13%20fixed%20erlang%20emacs%20mode.zip Best Regards -- Rikard Str?mmer VD White Falls AB Mobile: +46 73 2542143 www.white-falls.se We build a more fun, greener, richer, better future! Visit our daughter company www.uppdrag-ledning.se to learn how we can help you to create positive change in your business. _______________________________________________ erlang-patches mailing list erlang-patches@REDACTED http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonas.falkevik@REDACTED Mon Apr 7 09:21:36 2014 From: jonas.falkevik@REDACTED (Jonas Falkevik) Date: Mon, 7 Apr 2014 09:21:36 +0200 Subject: [erlang-patches] Fix shell crash when in switch command mode Message-ID: <3C4551F6-47BE-47AA-8B5A-59AF606FA85B@mobilearts.com> Hi, there has been at least one known case where if accidentally hitting ctrl-y when in the shell switch mode (ctrl-g) which makes the user_drv process crash and it is not easily recovered. The crash is due to the switch mode using edlin to parse its input. And edlin uses the process dictionary to store its kill_buffer. Emacs look alike. However the kill_buffer is undefined if not initialized by edlin:init/0 and that makes the user_drv process crash if ctrl-y is hit, since edlin is calling list:reverse/2 with the atom undefined. The patch below is to prevent the crash from happening by initializing edin once. Jonas git fetch git://github.com/falkevik/otp.git erl_shell_switch_command_crash_fix https://github.com/falkevik/otp/compare/erlang:master...erl_shell_switch_command_crash_fix https://github.com/falkevik/otp/compare/erlang:master...erl_shell_switch_command_crash_fix.patch -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton@REDACTED Fri Apr 11 15:09:23 2014 From: colton@REDACTED (Colton Leekley-Winslow) Date: Fri, 11 Apr 2014 08:09:23 -0500 Subject: [erlang-patches] Patch for bug in snmp_test_manager.erl Message-ID: Hi, Recently I was familiarizing myself with the SNMP functionality of Erlang and decided to use the snmp_test_manager (lib/snmp/test/snmp_test_manager.erl) setup as a guide. During my endeavor I was unable to start_link an snmp_test_manager due to a badmatch occurring on line 133. See traceback here: http://pastebin.com/1eNYkGTz This is because on line 133 the snmp_test_manager module is expecting a tuple of {ok, Pid} from snmpm:start_link/0 . However, snmpm:start_link/0 will only return the atom ok. This causes a badmatch. By editing line 133 of snmp_test_manager.erl to only expect the atom ok, and editing line 136 to not reference the no longer existing Pid variable, I was able to fix the module. I also edited line 59 to remove the mgr key from the State record, as after these changes it was no longer being used. You can find my public repository here: https://github.com/telsacolton/otp and the branch with the fix is called snmp_test_manager_badmatch_pid -- Colton Leekley-Winslow Developer, Telsasoft (952) 707-8581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Tue Apr 15 16:32:12 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Tue, 15 Apr 2014 16:32:12 +0200 Subject: [erlang-patches] Fwd: Patch for bug in snmp_test_manager.erl In-Reply-To: <58912684E2630B45963406CF7D8C52581C3CAC2F@ESESSMB103.ericsson.se> References: <58912684E2630B45963406CF7D8C52581C3CAC2F@ESESSMB103.ericsson.se> Message-ID: Thank you for your contribution! However, before we continue working with this patch, please provide a better commit message, according to the following guidelines for "Writing good commit messages [1]. [1] https://github.com/erlang/otp/wiki/Writing-good-commit-messages Andreas Schumacher, Erlang/OTP, Ericsson AB *From:* erlang-patches-bounces@REDACTED [mailto: erlang-patches-bounces@REDACTED] *On Behalf Of *Colton Leekley-Winslow *Sent:* den 11 april 2014 15:09 *To:* erlang-patches@REDACTED *Subject:* [erlang-patches] Patch for bug in snmp_test_manager.erl Hi, Recently I was familiarizing myself with the SNMP functionality of Erlang and decided to use the snmp_test_manager (lib/snmp/test/snmp_test_manager.erl) setup as a guide. During my endeavor I was unable to start_link an snmp_test_manager due to a badmatch occurring on line 133. See traceback here: http://pastebin.com/1eNYkGTz This is because on line 133 the snmp_test_manager module is expecting a tuple of {ok, Pid} from snmpm:start_link/0 . However, snmpm:start_link/0 will only return the atom ok. This causes a badmatch. By editing line 133 of snmp_test_manager.erl to only expect the atom ok, and editing line 136 to not reference the no longer existing Pid variable, I was able to fix the module. I also edited line 59 to remove the mgr key from the State record, as after these changes it was no longer being used. You can find my public repository here: https://github.com/telsacolton/otp and the branch with the fix is called snmp_test_manager_badmatch_pid -- Colton Leekley-Winslow Developer, Telsasoft (952) 707-8581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From colton@REDACTED Tue Apr 15 17:15:58 2014 From: colton@REDACTED (Colton Leekley-Winslow) Date: Tue, 15 Apr 2014 10:15:58 -0500 Subject: [erlang-patches] Patch for bug in snmp_test_manager.erl In-Reply-To: References: <58912684E2630B45963406CF7D8C52581C3CAC2F@ESESSMB103.ericsson.se> Message-ID: Hi Andreas, Ahh sorry about that. I've amended my commit message, which is commit hash eadc39c5356692d8a093b835d884c8e11faf4c73 . On Tue, Apr 15, 2014 at 9:32 AM, Andreas Schumacher wrote: > Thank you for your contribution! However, before we continue working with > this patch, please provide a better commit message, according to the > following guidelines for "Writing good commit messages [1]. > > [1] https://github.com/erlang/otp/wiki/Writing-good-commit-messages > > Andreas Schumacher, Erlang/OTP, Ericsson AB > > > *From:* erlang-patches-bounces@REDACTED [mailto: > erlang-patches-bounces@REDACTED] *On Behalf Of *Colton Leekley-Winslow > *Sent:* den 11 april 2014 15:09 > *To:* erlang-patches@REDACTED > *Subject:* [erlang-patches] Patch for bug in snmp_test_manager.erl > > > > Hi, > > > > Recently I was familiarizing myself with the SNMP functionality of > Erlang and decided to use the snmp_test_manager > (lib/snmp/test/snmp_test_manager.erl) setup as a guide. During my endeavor > I was unable to start_link an snmp_test_manager due to a badmatch occurring > on line 133. See traceback here: http://pastebin.com/1eNYkGTz > > > > This is because on line 133 the snmp_test_manager module is expecting a > tuple of {ok, Pid} from snmpm:start_link/0 . However, snmpm:start_link/0 > will only return the atom ok. This causes a badmatch. By editing line 133 > of snmp_test_manager.erl to only expect the atom ok, and editing line 136 > to not reference the no longer existing Pid variable, I was able to fix the > module. I also edited line 59 to remove the mgr key from the State record, > as after these changes it was no longer being used. You can find my public > repository here: > > > > https://github.com/telsacolton/otp > > > > and the branch with the fix is called > snmp_test_manager_badmatch_pid > > > > -- > > Colton Leekley-Winslow > > Developer, Telsasoft > > (952) 707-8581 > > -- Colton Leekley-Winslow Developer, Telsasoft (952) 707-8581 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Wed Apr 16 14:54:22 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 16 Apr 2014 14:54:22 +0200 Subject: [erlang-patches] Supervisor shutdown reason when reaching max restarts In-Reply-To: References: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu> <12F2115FD1CCEE4294943B2608A18FA361B0B930@MAIL01.win.lbaum.eu> Message-ID: Hello Tobias and the list! This review has finally made its way up the backlog. Thanks for your patience! Is this use case still relevant? I've started looking at the compatibility issue. As far as I can see there shouldn't be a big problem upwards in a normal supervision tree, since this is internal to OTP. Downwards, however, there might be problems since exit trapping children will get {shutdown,Reason} instead of shutdown when a supervisor terminates due to a failed restart attempt. In the case of a gen_server or gen_fsm, this exit reason will be propagated to the callback module via Mod:terminate/2. The value 'shutdown', used when the supervisor orders termination, is documented for this callback function. For other proc_lib processes the receive statement is implemented individually, so even here the change will be exposed to the user (if matching the exit reason). Links and monitors across the supervision tree might also be a problem, of course. And the case when something other than a supervisor or the application_master is the parent of a supervisor - I don't know if this is very common, though, and I find the incompatibility downwards in the supervision tree most alarming. As you know, we need to be very careful with backwards incompatible changes in core functionality, so for the time being we would like to investigate the general need for this functionality and if there are other possible ways to go. Some questions for the list: 1. Is the use case described in the Tobias' previous mail a common one? If yes, how have you solved it? 2. Do you normally care about the exit reason in your Mod:terminate/2 function or in your proc_lib receive statement when getting an EXIT from the parent? 3. Any other comments on this? Thanks /siri 2013-08-23 14:17 GMT+02:00 Siri Hansen : > Tobias, thanks for a good explanation. I will post this into the ticket > and we'll take it into account when finishing the review. > Thanks again for your contribution! > /siri > > > 2013/8/23 Tobias Schlager > >> Hi Siri, >> >> glad to hear from you, I'll try to do my best to explain the use case I >> have in mind. >> >> Consider you have a one_for_one (or simple_one_for_one) supervisor A with >> a worker child B that dynamically adds children to A (using >> supervisor:start_child/2). Now consider these children also are supervisors >> of type C with various statically configured workers. I now would like to >> monitor supervisors of type C from worker B to be able to take some action >> when *something goes wrong* at one of the C supervisors (e.g. C crashed >> because of one of its subworkers). However, I can't differentiate between >> 'something went wrong' or a supervisor C just exited gracefully (e.g. the >> application was stopped) because supervisors only exit with reason normal >> or shutdown. It is arguable whether to use another restart type for C >> supervisors in order to propagate the exit. However, I don't want to crash >> the whole supervision just to be able to tell that something failed to >> restart somewhere down the supervision path. >> >> In general, the new exit reasons are visible to all processes linked with >> supervisors or monitoring them (so parent supervisors as well as the >> application master will see these reasons). This is why I chose the >> '{shutdown, Reason}' format, which must be supported (according to the >> documentation this is considered a normal exit reason). Thus, changing the >> exit reasons will not affect the behaviour of supervision hierarchies >> (verified by the test suite) or the application master (as far as I can >> tell). The backward incompatibilty is located in processes depending on the >> undocumented behaviour of supervisors always exiting with normal or >> shutdown and not with '{shutdown, Reason}'. >> >> I hope, that my explanation makes things a bit clearer (and not worse). >> >> Regards >> Tobias >> >> ------------------------------ >> *Von:* Siri Hansen [erlangsiri@REDACTED] >> *Gesendet:* Freitag, 23. August 2013 09:50 >> *An:* Tobias Schlager >> *Cc:* erlang-patches@REDACTED >> *Betreff:* Re: [erlang-patches] Supervisor shutdown reason when reaching >> max restarts >> >> Hi Tobias! >> Thank you for the patch. We have discussed this on OTP Technical Board, >> and have come to the conclusion that some more investigation is needed of >> the potential backwards incompatibility. I have written a ticket and the >> job will be prioritized into our backlog. Unfortunately we won't make it >> before the next release (R16B02). >> >> In order to help us a bit on the way, could you please provide some >> more information about your use case? You say that you are monitoring the >> supervisor from another process, do you mean other process than the >> supervisor's supervisor? If so, could you explain this architecture a bit >> more? >> >> Who else will see this exit reason? - application_master? - the parent >> supervisors? - other? >> >> Thanks again! >> Regards >> /siri >> >> >> >> 2013/7/4 Tobias Schlager >> >>> Hi, >>> >>> this patch changes the behaviour of supervisors to exit with a more >>> specific reason when exiting due to a maximum restart limit hit. This is >>> especially useful (or even necessary) to distinguish between normal and >>> erroneous process terminations when monitoring a supervisor from another >>> process. >>> >>> In the above case a supervisor would now exit with {shutdown, >>> {reached_max_restart_intensity, Child}} where Child is whatever is >>> available to describe the child, either a child id or in case of a >>> simple_one_for_one supervisor the offending child's process id. The patch >>> should not affect the OTP restart behaviour (also for cascaded supervisors) >>> since a subclass of 'normal' exit reasons is used. >>> >>> I'm aware that there is some potential backward incompatibility for >>> people that do not expect {shutdown, Reason} when monitoring a supervisor. >>> However, the feature of exiting normally with {shutdown, Reason} has been >>> around for quite a while now and I think this could be a sensible place to >>> use it. Let me know what you think. >>> >>> The patch does include tests and updated documentation. >>> >>> git fetch https://github.com/schlagert/otp.gitsupervisor_shutdown_reason >>> >>> >>> https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason >>> >>> https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason.patch >>> >>> Regards >>> Tobias >>> _______________________________________________ >>> erlang-patches mailing list >>> erlang-patches@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-patches >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Schlager@REDACTED Wed Apr 16 15:49:20 2014 From: Tobias.Schlager@REDACTED (Tobias Schlager) Date: Wed, 16 Apr 2014 13:49:20 +0000 Subject: [erlang-patches] Supervisor shutdown reason when reaching max restarts In-Reply-To: References: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu> <12F2115FD1CCEE4294943B2608A18FA361B0B930@MAIL01.win.lbaum.eu> , Message-ID: <12F2115FD1CCEE4294943B2608A18FA3D0E42BCC@MAIL01.win.lbaum.eu> Hi Siri, I already solved the problem for my use case. In my case the supervisors of type C never exit gracefully except for the case the application gets stopped, so I ended up 'disarming' the monitors of process B in an 'application:prep_stop/1' callback. Of course, this is a debatable patch because it introduces backwards incompatible behavior and I will not argue if it gets declined. I just thought that having differentiated exit reason of supervisors would be a good thing to have in general (and that according to the documentation {shutdown, Reason} exits must be supported by callback implementations anyways). Regards Tobias -- Lindenbaum GmbH Dipl.-Inform. Tobias Schlager, Software Engineer Erbprinzenstr. 4-12, 76133 Karlsruhe, Deutschland Tel: +49 721 48 08 48 - 000, Fax: +49 721 48 08 48 - 801, E-Mail: tobias.schlager@REDACTED Firmensitz: Erbprinzenstr. 4-12, Eingang A, 76133 Karlsruhe Registergericht: Amtsgericht Mannheim, HRB 706184 Gesch?ftsf?hrer: Dr. Ralf Nikolai Steuernummer: 35007/02060, USt. ID: DE 263797265 http://www.lindenbaum.eu ________________________________ Von: Siri Hansen [erlangsiri@REDACTED] Gesendet: Mittwoch, 16. April 2014 14:54 An: Tobias Schlager Cc: erlang-patches@REDACTED Betreff: Re: [erlang-patches] Supervisor shutdown reason when reaching max restarts Hello Tobias and the list! This review has finally made its way up the backlog. Thanks for your patience! Is this use case still relevant? I've started looking at the compatibility issue. As far as I can see there shouldn't be a big problem upwards in a normal supervision tree, since this is internal to OTP. Downwards, however, there might be problems since exit trapping children will get {shutdown,Reason} instead of shutdown when a supervisor terminates due to a failed restart attempt. In the case of a gen_server or gen_fsm, this exit reason will be propagated to the callback module via Mod:terminate/2. The value 'shutdown', used when the supervisor orders termination, is documented for this callback function. For other proc_lib processes the receive statement is implemented individually, so even here the change will be exposed to the user (if matching the exit reason). Links and monitors across the supervision tree might also be a problem, of course. And the case when something other than a supervisor or the application_master is the parent of a supervisor - I don't know if this is very common, though, and I find the incompatibility downwards in the supervision tree most alarming. As you know, we need to be very careful with backwards incompatible changes in core functionality, so for the time being we would like to investigate the general need for this functionality and if there are other possible ways to go. Some questions for the list: 1. Is the use case described in the Tobias' previous mail a common one? If yes, how have you solved it? 2. Do you normally care about the exit reason in your Mod:terminate/2 function or in your proc_lib receive statement when getting an EXIT from the parent? 3. Any other comments on this? Thanks /siri 2013-08-23 14:17 GMT+02:00 Siri Hansen >: Tobias, thanks for a good explanation. I will post this into the ticket and we'll take it into account when finishing the review. Thanks again for your contribution! /siri 2013/8/23 Tobias Schlager > Hi Siri, glad to hear from you, I'll try to do my best to explain the use case I have in mind. Consider you have a one_for_one (or simple_one_for_one) supervisor A with a worker child B that dynamically adds children to A (using supervisor:start_child/2). Now consider these children also are supervisors of type C with various statically configured workers. I now would like to monitor supervisors of type C from worker B to be able to take some action when *something goes wrong* at one of the C supervisors (e.g. C crashed because of one of its subworkers). However, I can't differentiate between 'something went wrong' or a supervisor C just exited gracefully (e.g. the application was stopped) because supervisors only exit with reason normal or shutdown. It is arguable whether to use another restart type for C supervisors in order to propagate the exit. However, I don't want to crash the whole supervision just to be able to tell that something failed to restart somewhere down the supervision path. In general, the new exit reasons are visible to all processes linked with supervisors or monitoring them (so parent supervisors as well as the application master will see these reasons). This is why I chose the '{shutdown, Reason}' format, which must be supported (according to the documentation this is considered a normal exit reason). Thus, changing the exit reasons will not affect the behaviour of supervision hierarchies (verified by the test suite) or the application master (as far as I can tell). The backward incompatibilty is located in processes depending on the undocumented behaviour of supervisors always exiting with normal or shutdown and not with '{shutdown, Reason}'. I hope, that my explanation makes things a bit clearer (and not worse). Regards Tobias ________________________________ Von: Siri Hansen [erlangsiri@REDACTED] Gesendet: Freitag, 23. August 2013 09:50 An: Tobias Schlager Cc: erlang-patches@REDACTED Betreff: Re: [erlang-patches] Supervisor shutdown reason when reaching max restarts Hi Tobias! Thank you for the patch. We have discussed this on OTP Technical Board, and have come to the conclusion that some more investigation is needed of the potential backwards incompatibility. I have written a ticket and the job will be prioritized into our backlog. Unfortunately we won't make it before the next release (R16B02). In order to help us a bit on the way, could you please provide some more information about your use case? You say that you are monitoring the supervisor from another process, do you mean other process than the supervisor's supervisor? If so, could you explain this architecture a bit more? Who else will see this exit reason? - application_master? - the parent supervisors? - other? Thanks again! Regards /siri 2013/7/4 Tobias Schlager > Hi, this patch changes the behaviour of supervisors to exit with a more specific reason when exiting due to a maximum restart limit hit. This is especially useful (or even necessary) to distinguish between normal and erroneous process terminations when monitoring a supervisor from another process. In the above case a supervisor would now exit with {shutdown, {reached_max_restart_intensity, Child}} where Child is whatever is available to describe the child, either a child id or in case of a simple_one_for_one supervisor the offending child's process id. The patch should not affect the OTP restart behaviour (also for cascaded supervisors) since a subclass of 'normal' exit reasons is used. I'm aware that there is some potential backward incompatibility for people that do not expect {shutdown, Reason} when monitoring a supervisor. However, the feature of exiting normally with {shutdown, Reason} has been around for quite a while now and I think this could be a sensible place to use it. Let me know what you think. The patch does include tests and updated documentation. git fetch https://github.com/schlagert/otp.git supervisor_shutdown_reason https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason https://github.com/schlagert/otp/compare/erlang:master...supervisor_shutdown_reason.patch Regards Tobias _______________________________________________ erlang-patches mailing list erlang-patches@REDACTED http://erlang.org/mailman/listinfo/erlang-patches -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.karlsson@REDACTED Mon Apr 21 15:03:30 2014 From: roland.karlsson@REDACTED (Roland Karlsson) Date: Mon, 21 Apr 2014 15:03:30 +0200 Subject: [erlang-patches] bug fix patch for revert map_field_assoc in syntax_tools Message-ID: <20140421150328.FC11.69B9F832@proxel.se> In tag OTP-17.0 there is a bug in syntax_tools Example: 2> erl_syntax:revert_forms( [{tree,map_field_assoc,{attr,16,[],none},{map_field_assoc,{atom,17,key},{var,18,'Value'}}}]). [{map_field_assoc,16,{atom,17,key},{atom,17,key}}] As you can see, the key field is duplicated, replacing the value field. I have made a patch fixing this bug. It can be extracted with git clone https://github.com/rolkar/otp.git The fix is found in the branch fixing-revert-bug https://github.com/rolkar/otp/tree/fixing-revert-bug The patch contains two commits. The first adds a test case that fails. The second fixes the problem in the code. -- Roland Karlsson