From erlangsiri@REDACTED Wed Sep 3 13:50:04 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 3 Sep 2014 13:50:04 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: Hello! It looks like we have reached consensus regarding the default values :) Thanks again for all input! Over the summer we have had some internal reviews of the documentation and I got some feedback on the naming. Specifically, questions are raised about the keys 'name', 'intensity' and 'period'. With the old tuple format, these three values are named Id, MaxR and MaxT respectively, and the questions are if they should be changed at all and if so, are the suggested names "the best"... Personally, I think that changing Id to 'name' might not be necessary. Partly because this value is discussed as the "child identifier" everywhere in the documentation and partly because the type definition of it is term() (and not atom() or string()). So my suggestion is to change this key to 'id'. The reasoning about 'intensity'/MaxR and 'period'/MaxT is more complex, I think. I agree that the old variable names (at least MaxT), are not super good. One reason for keeping to something similar to this is, however, that these names are used when describing the mechanism of restart escalation in some of the erlang books that already exist. And if you are familiar with the old format, then switching to the new format will of course be easier if the key names are easy to map. But on the other hand, if we could find really good names to use instead, then maybe it would be worth the change in order to ease the introduction for newcomers. Again personally, I am not sure that 'intensity' and 'period' are so much better than the old names... What we are talking about here is some kind of "restart frequency", although it is not really a frequency either - at least not a constant frequency. It's the limit for the number of restarts within a time window... Are the names max_restarts or restart_limit better than intensity. Is period ok, or time_frame, time_window ... ? Or should we stick to max_time to keep close to the old names? Would it make sense to put both values into a tuple using only one key (restart_frequency, ...?) in the map? So many questions... naming is hard! Any thoughts? /siri 2014-07-04 12:13 GMT+02:00 Siri Hansen : > I have pushed the current status of this job to github. Comments still > welcome! > /siri > > > https://github.com/sirihansen/otp/compare/erlang:980d7fa32128d43d36fb9527df1967eff801be9c...siri/sup-spec-maps/OTP-11043 > > > 2014-07-03 20:24 GMT+02:00 DeadZen : > > +1 on the latest revision >> >> On Thu, Jul 3, 2014 at 9:57 AM, Siri Hansen wrote: >> > Hello, >> > >> > thanks for the feedback! We have decided to take your comments into >> account >> > and change the default values as follows: >> > >> > Intensity/Perior: 1/5 >> > Shutdown for worker: 5000 >> > Shutdown for supervisor: infinity >> > >> > The reasoning behind it is that >> > >> > 1. as a few of you commented, it is probably not a good idea to have a >> > default without restarts, as restarts is a very important property of >> the >> > supervisor tree. Using 1 restart in 5 seconds was a compromise between >> my >> > first intention of "being extreme" and the suggestions from the list... >> And >> > also - if a process can not be restarted on the first attempt, then >> maybe it >> > is not so great a chance that it will succeed on the second attempt >> either. >> > And 5 seconds is a very good number!! >> > >> > 2. to avoid the confusion of why the terminate function is not >> executed, we >> > decided not to use 'brutal_kill'. Which number to use is probably not >> that >> > important, so we chose 5000 - which we all know is proven to be "the >> best >> > timeout value" ;) >> > >> > 3. the recommended shutdown value for supervisors is 'infinity', and I >> think >> > that should be reflected in the default. Having the same (integer) >> value as >> > for workers can give very strange results. >> > >> > Further comments are still welcome... :) >> > >> > /siri >> > >> > >> > >> > >> > >> > >> > >> > 2014-07-01 14:43 GMT+02:00 Daniel Luna : >> > >> >> I have to mention that I think brutal_kill is a really bad choice for a >> >> default. >> >> >> >> It breaks the expectation in Erlang that supervisors can never crash. >> An >> >> expectation that is in the core of what makes Erlang the great >> language that >> >> it is. >> >> >> >> Dangling process trees are not fun to deal with (and don't happen on a >> VM >> >> crash). >> >> >> >> To preserve the correctness and trust of supervision trees the default >> >> should be either infinity or depend on the child type. >> >> >> >> For worker children brutal_kill is fine. For supervisor children >> infinity >> >> is the only sensible choice. >> >> >> >> On Jul 1, 2014 7:06 AM, "Lo?c Hoguin" wrote: >> >>> >> >>> Just wanted to say I agree with everything Jos? said, except 3. the >> >>> different defaults for different process types. It makes things too >> hard to >> >>> keep track of. >> >>> >> >>> I think brutal_kill is a great choice because it makes it easier for >> the >> >>> user to stumble upon cold-start issues when restarting their >> >>> application/release. The VM may crash so there's never a guarantee to >> run >> >>> shutdown functions anyway, and too few people forget to test cases >> when >> >>> these didn't run, leading to potential production disasters. >> >>> >> >>> On 06/30/2014 04:37 PM, Jos? Valim wrote: >> >>>> >> >>>> I have some feedback based on my experience in writing and teaching >> >>>> Erlang/Elixir. >> >>>> >> >>>> 1. I would always require the supervision strategy. When I am >> >>>> prototyping, it is usually hard for me to reason about the intensity >> and >> >>>> restarts, but I can always reason about the supervision strategy. All >> >>>> teaching materials I know of also discuss the supervision right >> away, so >> >>>> having it explicit shouldn't hurt those cases. >> >>>> >> >>>> For such cases, maybe we should use the format of {{strategy(), >> map()}, >> >>>> [children()]} (which is similar to what we have today). >> >>>> >> >>>> 2. I also agree with Richard. Having a default of 0 restarts may >> cause >> >>>> confusion and forcing people to define them won't help when they >> still >> >>>> have no idea of what values they should use (because it is >> prototyping / >> >>>> early deploys). I usually fine tune those values based on the >> production >> >>>> system reports so having saner defaults, like Ulf's, may make more >> >>>> sense. >> >>>> >> >>>> 3. The child_spec defaults are great and similar to the ones we use >> in >> >>>> Elixir with the only difference being the shutdown value. We have a >> >>>> default of 5000, which is the one usually recommended, but we set it >> to >> >>>> "infinity" if the type is a "supervisor" (which is the OTP docs >> >>>> recommendation if I remember correctly). >> >>>> >> >>>> Regarding 3., if the recommendation and the consensus in actual >> systems >> >>>> is to use brutal_kill for shutdown, I will gladly change Elixir to >> make >> >>>> it consistent with OTP defaults. >> >>>> >> >>>> Thanks for opening the changes for discussion! >> >>>> >> >>>> *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 >> >>>> >> >>> >> >>> -- >> >>> Lo?c Hoguin >> >>> http://ninenines.eu >> >>> _______________________________________________ >> >>> 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 essen@REDACTED Wed Sep 3 14:07:42 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 03 Sep 2014 14:07:42 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: <5407048E.40802@ninenines.eu> On 09/03/2014 01:50 PM, Siri Hansen wrote: > Personally, I think that changing Id to 'name' might not be necessary. > Partly because this value is discussed as the "child identifier" > everywhere in the documentation and partly because the type definition > of it is term() (and not atom() or string()). So my suggestion is to > change this key to 'id'. Agree. > The reasoning about 'intensity'/MaxR and 'period'/MaxT is more complex, > I think. I agree that the old variable names (at least MaxT), are not > super good. One reason for keeping to something similar to this is, > however, that these names are used when describing the mechanism of > restart escalation in some of the erlang books that already exist. And > if you are familiar with the old format, then switching to the new > format will of course be easier if the key names are easy to map. But on > the other hand, if we could find really good names to use instead, then > maybe it would be worth the change in order to ease the introduction for > newcomers. Again personally, I am not sure that 'intensity' and 'period' > are so much better than the old names... > > What we are talking about here is some kind of "restart frequency", > although it is not really a frequency either - at least not a constant > frequency. It's the limit for the number of restarts within a time > window... Are the names max_restarts or restart_limit better than > intensity. Is period ok, or time_frame, time_window ... ? Or should we > stick to max_time to keep close to the old names? > > Would it make sense to put both values into a tuple using only one key > (restart_frequency, ...?) in the map? What about 'max_restarts' and simply 'time' (allow up to max_restarts over time seconds). Or perhaps even just 'seconds'? It'd make it more obvious what the value represents. -- Lo?c Hoguin http://ninenines.eu From jose.valim@REDACTED Wed Sep 3 14:21:28 2014 From: jose.valim@REDACTED (=?UTF-8?Q?Jos=C3=A9_Valim?=) Date: Wed, 3 Sep 2014 14:21:28 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: > Personally, I think that changing Id to 'name' might not be necessary. > Agreed. Changing it to name could also cause confusion with the actual process name (given on supervisor/gen_server/etc's start_link). > Would it make sense to put both values into a tuple using only one key > (restart_frequency, ...?) in the map? > In Elixir we use: ? max_restarts - the maximum amount of restarts allowed in a time frame. ? max_seconds - the time frame in which max_restarts applies. I would avoid calling it just "time" or "period" because those do not make clear what is the time unit. *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Wed Sep 3 15:43:27 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Wed, 3 Sep 2014 15:43:27 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: On Wed, Sep 3, 2014 at 1:50 PM, Siri Hansen wrote: > Hello! > > It looks like we have reached consensus regarding the default values :) > Thanks again for all input! > > Over the summer we have had some internal reviews of the documentation and > I got some feedback on the naming. Specifically, questions are raised about > the keys 'name', 'intensity' and 'period'. With the old tuple format, these > three values are named Id, MaxR and MaxT respectively, and the questions > are if they should be changed at all and if so, are the suggested names > "the best"... > > Personally, I think that changing Id to 'name' might not be necessary. > Partly because this value is discussed as the "child identifier" everywhere > in the documentation and partly because the type definition of it is term() > (and not atom() or string()). So my suggestion is to change this key to > 'id'. > > The reasoning about 'intensity'/MaxR and 'period'/MaxT is more complex, I > think. I agree that the old variable names (at least MaxT), are not super > good. One reason for keeping to something similar to this is, however, that > these names are used when describing the mechanism of restart escalation in > some of the erlang books that already exist. And if you are familiar with > the old format, then switching to the new format will of course be easier > if the key names are easy to map. But on the other hand, if we could find > really good names to use instead, then maybe it would be worth the change > in order to ease the introduction for newcomers. Again personally, I am not > sure that 'intensity' and 'period' are so much better than the old names... > > What we are talking about here is some kind of "restart frequency", > although it is not really a frequency either - at least not a constant > frequency. It's the limit for the number of restarts within a time > window... Are the names max_restarts or restart_limit better than > intensity. Is period ok, or time_frame, time_window ... ? Or should we > stick to max_time to keep close to the old names? > > Would it make sense to put both values into a tuple using only one key > (restart_frequency, ...?) in the map? > > So many questions... naming is hard! Any thoughts? > > /siri > Would it make sense to have a single property "max_restart_frequency" whose value is a tuple {R, T} ? > > 2014-07-04 12:13 GMT+02:00 Siri Hansen : > > I have pushed the current status of this job to github. Comments still >> welcome! >> /siri >> >> >> https://github.com/sirihansen/otp/compare/erlang:980d7fa32128d43d36fb9527df1967eff801be9c...siri/sup-spec-maps/OTP-11043 >> >> >> 2014-07-03 20:24 GMT+02:00 DeadZen : >> >> +1 on the latest revision >>> >>> On Thu, Jul 3, 2014 at 9:57 AM, Siri Hansen >>> wrote: >>> > Hello, >>> > >>> > thanks for the feedback! We have decided to take your comments into >>> account >>> > and change the default values as follows: >>> > >>> > Intensity/Perior: 1/5 >>> > Shutdown for worker: 5000 >>> > Shutdown for supervisor: infinity >>> > >>> > The reasoning behind it is that >>> > >>> > 1. as a few of you commented, it is probably not a good idea to have a >>> > default without restarts, as restarts is a very important property of >>> the >>> > supervisor tree. Using 1 restart in 5 seconds was a compromise between >>> my >>> > first intention of "being extreme" and the suggestions from the >>> list... And >>> > also - if a process can not be restarted on the first attempt, then >>> maybe it >>> > is not so great a chance that it will succeed on the second attempt >>> either. >>> > And 5 seconds is a very good number!! >>> > >>> > 2. to avoid the confusion of why the terminate function is not >>> executed, we >>> > decided not to use 'brutal_kill'. Which number to use is probably not >>> that >>> > important, so we chose 5000 - which we all know is proven to be "the >>> best >>> > timeout value" ;) >>> > >>> > 3. the recommended shutdown value for supervisors is 'infinity', and I >>> think >>> > that should be reflected in the default. Having the same (integer) >>> value as >>> > for workers can give very strange results. >>> > >>> > Further comments are still welcome... :) >>> > >>> > /siri >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > 2014-07-01 14:43 GMT+02:00 Daniel Luna : >>> > >>> >> I have to mention that I think brutal_kill is a really bad choice for >>> a >>> >> default. >>> >> >>> >> It breaks the expectation in Erlang that supervisors can never crash. >>> An >>> >> expectation that is in the core of what makes Erlang the great >>> language that >>> >> it is. >>> >> >>> >> Dangling process trees are not fun to deal with (and don't happen on >>> a VM >>> >> crash). >>> >> >>> >> To preserve the correctness and trust of supervision trees the default >>> >> should be either infinity or depend on the child type. >>> >> >>> >> For worker children brutal_kill is fine. For supervisor children >>> infinity >>> >> is the only sensible choice. >>> >> >>> >> On Jul 1, 2014 7:06 AM, "Lo?c Hoguin" wrote: >>> >>> >>> >>> Just wanted to say I agree with everything Jos? said, except 3. the >>> >>> different defaults for different process types. It makes things too >>> hard to >>> >>> keep track of. >>> >>> >>> >>> I think brutal_kill is a great choice because it makes it easier for >>> the >>> >>> user to stumble upon cold-start issues when restarting their >>> >>> application/release. The VM may crash so there's never a guarantee >>> to run >>> >>> shutdown functions anyway, and too few people forget to test cases >>> when >>> >>> these didn't run, leading to potential production disasters. >>> >>> >>> >>> On 06/30/2014 04:37 PM, Jos? Valim wrote: >>> >>>> >>> >>>> I have some feedback based on my experience in writing and teaching >>> >>>> Erlang/Elixir. >>> >>>> >>> >>>> 1. I would always require the supervision strategy. When I am >>> >>>> prototyping, it is usually hard for me to reason about the >>> intensity and >>> >>>> restarts, but I can always reason about the supervision strategy. >>> All >>> >>>> teaching materials I know of also discuss the supervision right >>> away, so >>> >>>> having it explicit shouldn't hurt those cases. >>> >>>> >>> >>>> For such cases, maybe we should use the format of {{strategy(), >>> map()}, >>> >>>> [children()]} (which is similar to what we have today). >>> >>>> >>> >>>> 2. I also agree with Richard. Having a default of 0 restarts may >>> cause >>> >>>> confusion and forcing people to define them won't help when they >>> still >>> >>>> have no idea of what values they should use (because it is >>> prototyping / >>> >>>> early deploys). I usually fine tune those values based on the >>> production >>> >>>> system reports so having saner defaults, like Ulf's, may make more >>> >>>> sense. >>> >>>> >>> >>>> 3. The child_spec defaults are great and similar to the ones we use >>> in >>> >>>> Elixir with the only difference being the shutdown value. We have a >>> >>>> default of 5000, which is the one usually recommended, but we set >>> it to >>> >>>> "infinity" if the type is a "supervisor" (which is the OTP docs >>> >>>> recommendation if I remember correctly). >>> >>>> >>> >>>> Regarding 3., if the recommendation and the consensus in actual >>> systems >>> >>>> is to use brutal_kill for shutdown, I will gladly change Elixir to >>> make >>> >>>> it consistent with OTP defaults. >>> >>>> >>> >>>> Thanks for opening the changes for discussion! >>> >>>> >>> >>>> *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 >>> >>>> >>> >>> >>> >>> -- >>> >>> Lo?c Hoguin >>> >>> http://ninenines.eu >>> >>> _______________________________________________ >>> >>> 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 ulf@REDACTED Wed Sep 3 18:33:03 2014 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 3 Sep 2014 18:33:03 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: On 03 Sep 2014, at 13:50, Siri Hansen wrote: > Over the summer we have had some internal reviews of the documentation and I got some feedback on the naming. Specifically, questions are raised about the keys 'name', 'intensity' and 'period'. With the old tuple format, these three values are named Id, MaxR and MaxT respectively, and the questions are if they should be changed at all and if so, are the suggested names "the best"? Ah, how did I miss this? Time for me to mention, again, the supervisor extension I made back in 2001: http://erlang.2086793.n4.nabble.com/Supervisor-shutdown-td4663655.html Just as some added input. ;-) BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 10 16:48:00 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 10 Sep 2014 16:48:00 +0200 Subject: [erlang-patches] (no subject) Message-ID: Let Java compiler output all warnings These help detecting possible problems in the code. There will be many at the moment, a new pull request will be submitted that fixes them. > git fetch git://github.com/vladdu/otp.git junit_enable_warnings > > https://github.com/vladdu/otp/compare/erlang:maint...junit_enable_warnings > https://github.com/vladdu/otp/compare/erlang > :maint...junit_enable_warnings.patch regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Sep 10 17:50:49 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 10 Sep 2014 17:50:49 +0200 Subject: [erlang-patches] Jinterface code cleanup Message-ID: This fixes all the compilation warnings in the Java code. There are several commits that address (mostly) one kind of warning each. This makes PR #202 obsolete. > git fetch git://github.com/vladdu/otp.git jinterface_code_cleanup > > https://github.com/vladdu/otp/compare/erlang > :maint...jinterface_code_cleanup > https://github.com/vladdu/otp/compare/erlang > :maint...jinterface_code_cleanup.patch regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Fri Sep 12 12:34:04 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 12 Sep 2014 12:34:04 +0200 Subject: [erlang-patches] jinterface: small fixes Message-ID: a couple of fixes for possible problems, found by FindBugs > git fetch git://github.com/vladdu/otp.git jinterface_findbugs > > https://github.com/vladdu/otp/compare/erlang:maint...jinterface_findbugs > https://github.com/vladdu/otp/compare/erlang > :maint...jinterface_findbugs.patch regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Wed Sep 17 12:30:49 2014 From: henrik@REDACTED (Henrik Nord) Date: Wed, 17 Sep 2014 12:30:49 +0200 Subject: [erlang-patches] Optimise io requests for long message queues In-Reply-To: References: Message-ID: <541962D9.2080800@erlang.org> On 2014-06-27 19:07, Magnus Henoch wrote: > This patch reduces the run time of non-raw I/O when the calling process > has a long message queue, by using the monitor reference to trigger the > selective receive optimisation. > > Here is a little test program: > https://gist.github.com/legoscia/e0ac1bd1f640c9489609 > > Without my change, the run time of the call to file:write/2 increases as > the message queue length increases, while with my patch, the run time > stays constant. > > I was a bit unsure about removing the 'EXIT' clause from the receive, > but I've mostly convinced myself that this case should be fully handled > by the 'DOWN' clause, as the process in question is being monitored. > > git fetch git://github.com/legoscia/otp.git io-message-queue-optimisation > > https://github.com/legoscia/otp/compare/legoscia:io-message-queue-optimisation > https://github.com/legoscia/otp/compare/legoscia:io-message-queue-optimisation.patch > > Regards, > Magnus > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hi! we would like a test case which ensures that the optimization is not broken: An example of such test can be found in gen_server_SUITE:call_with_huge_message_queue The documentation needs a minor fix in the part that talks about "a more complicated client" - maybe something similar to this: "The io module monitors the I/O server, and uses the monitor reference as the ReplyAs datum. A more complicated client could have several outstanding I/O requests to the same I/O server and would then use different references (or something else) to differentiate among the incoming IO replies." When you have addressed the issues above could you also create a pull-request for this? -- /Henrik Nord Erlang/OTP From erlangsiri@REDACTED Wed Sep 17 15:30:57 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 17 Sep 2014 15:30:57 +0200 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: Thanks again for the input :) So, I'll definitely change 'name' back to 'id'. However, regarding 'intensity' and 'period' I think I found the reason why these names were used in the first place. These are the names used internally in the supervisor module (for variables names and fields in the state record), but more importantly, they are used in error messages - 'invalid_intensity', 'invalid_period' (and 'reached_max_restart_intensity'... :-P ). Considering the backwards compatibility we do not want to change these error messages, so now I'm back to thinking that maybe 'intensity' and 'period' are not so bad after all... ?? Or rather, there are pros and cons for everything, but maybe this would give the most consistent feel to the complete interface. /siri 2014-09-03 18:33 GMT+02:00 Ulf Wiger : > > On 03 Sep 2014, at 13:50, Siri Hansen wrote: > > Over the summer we have had some internal reviews of the documentation and > I got some feedback on the naming. Specifically, questions are raised about > the keys 'name', 'intensity' and 'period'. With the old tuple format, these > three values are named Id, MaxR and MaxT respectively, and the questions > are if they should be changed at all and if so, are the suggested names > "the best"? > > > Ah, how did I miss this? > > Time for me to mention, again, the supervisor extension I made back in > 2001: > > http://erlang.2086793.n4.nabble.com/Supervisor-shutdown-td4663655.html > > Just as some added input. ;-) > > BR, > Ulf W > > Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. > http://feuerlabs.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Fri Sep 19 20:11:58 2014 From: magnus@REDACTED (Magnus Henoch) Date: Fri, 19 Sep 2014 19:11:58 +0100 Subject: [erlang-patches] Optimise io requests for long message queues In-Reply-To: <541962D9.2080800@erlang.org> (Henrik Nord's message of "Wed, 17 Sep 2014 12:30:49 +0200") References: <541962D9.2080800@erlang.org> Message-ID: Henrik Nord writes: > we would like a test case which ensures that the optimization is not > broken: An example of such test can be found in > gen_server_SUITE:call_with_huge_message_queue > > The documentation needs a minor fix in the part that talks about "a more > complicated client" - maybe something similar to this: > > "The io module monitors the I/O server, and uses the monitor reference > as the ReplyAs datum. A more complicated client could have several > outstanding I/O requests to the same I/O server and would then use > different references (or something else) to differentiate among the > incoming IO replies." > > When you have addressed the issues above could you also create a > pull-request for this? I added a test, and updated the documentation. The pull request can be found here: https://github.com/erlang/otp/pull/478 Regards, Magnus From henrik@REDACTED Mon Sep 22 07:57:49 2014 From: henrik@REDACTED (Henrik Nord) Date: Mon, 22 Sep 2014 07:57:49 +0200 Subject: [erlang-patches] Optimise io requests for long message queues In-Reply-To: References: <541962D9.2080800@erlang.org> Message-ID: <541FBA5D.1080306@erlang.org> Thank you! On 2014-09-19 20:11, Magnus Henoch wrote: > Henrik Nord writes: > >> we would like a test case which ensures that the optimization is not >> broken: An example of such test can be found in >> gen_server_SUITE:call_with_huge_message_queue >> >> The documentation needs a minor fix in the part that talks about "a more >> complicated client" - maybe something similar to this: >> >> "The io module monitors the I/O server, and uses the monitor reference >> as the ReplyAs datum. A more complicated client could have several >> outstanding I/O requests to the same I/O server and would then use >> different references (or something else) to differentiate among the >> incoming IO replies." >> >> When you have addressed the issues above could you also create a >> pull-request for this? > I added a test, and updated the documentation. The pull request can be > found here: > > https://github.com/erlang/otp/pull/478 > > Regards, > Magnus -- /Henrik Nord Erlang/OTP From andrew.j.stone.1@REDACTED Mon Sep 22 20:17:09 2014 From: andrew.j.stone.1@REDACTED (Andrew Stone) Date: Mon, 22 Sep 2014 14:17:09 -0400 Subject: [erlang-patches] Add os:isatty/1 Message-ID: Hi All, I've added support for the posix 'isatty' function to the os module. This is a relatively minor addition, however it makes me wonder if there is more interest from the OTP team in adding other useful posix functions. I know personally, I'd love to have access direct from erlang for more posix functions. Let me know what you think. *https://github.com/erlang/otp/pull/480 * Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- # Why do we need this feature? The posix libc function, isatty(), is a useful function that will tell you if a file descriptor is attached to a terminal. If for instance you want to write a program that uses ansi color codes, it is not enough to just check $TERM because the output could be redirected to a file. In that case you would end up with the escape codes in the file making it harder to read and parse. By calling os:isatty/1 with stdout as it's parameter the program can ensure that it never writes escape codes to log files. # Risks or Uncertain Artifacts It uses a posix function that should be available on all platforms including Windows. The call is deprecated in favor of the C++ standard _isatty() call on Windows though. # How did you solve it? I added a bif to the os module. This seems to be the only reasonable way to do it, as the call must be in the same os process of the caller. From deadzen@REDACTED Tue Sep 23 16:27:21 2014 From: deadzen@REDACTED (DeadZen) Date: Tue, 23 Sep 2014 10:27:21 -0400 Subject: [erlang-patches] allow use of proplists in supervisor start specs In-Reply-To: References: <4F036F13.8040506@gmail.com> <53B29622.1010103@ninenines.eu> Message-ID: Once you find the reason for something, it always makes more sense.. The fact that you're reconsidering changing intensity/period now is prudent and respectable. On Wed, Sep 17, 2014 at 9:30 AM, Siri Hansen wrote: > Thanks again for the input :) > > So, I'll definitely change 'name' back to 'id'. However, regarding > 'intensity' and 'period' I think I found the reason why these names were > used in the first place. These are the names used internally in the > supervisor module (for variables names and fields in the state record), but > more importantly, they are used in error messages - 'invalid_intensity', > 'invalid_period' (and 'reached_max_restart_intensity'... :-P ). Considering > the backwards compatibility we do not want to change these error messages, > so now I'm back to thinking that maybe 'intensity' and 'period' are not so > bad after all... ?? Or rather, there are pros and cons for everything, but > maybe this would give the most consistent feel to the complete interface. > > /siri > > > > 2014-09-03 18:33 GMT+02:00 Ulf Wiger : >> >> >> On 03 Sep 2014, at 13:50, Siri Hansen wrote: >> >> Over the summer we have had some internal reviews of the documentation and >> I got some feedback on the naming. Specifically, questions are raised about >> the keys 'name', 'intensity' and 'period'. With the old tuple format, these >> three values are named Id, MaxR and MaxT respectively, and the questions are >> if they should be changed at all and if so, are the suggested names "the >> best"? >> >> >> Ah, how did I miss this? >> >> Time for me to mention, again, the supervisor extension I made back in >> 2001: >> >> http://erlang.2086793.n4.nabble.com/Supervisor-shutdown-td4663655.html >> >> Just as some added input. ;-) >> >> BR, >> Ulf W >> >> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. >> http://feuerlabs.com >> >> >> >