From n.oxyde@REDACTED Thu Aug 1 02:14:40 2013 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 1 Aug 2013 02:14:40 +0200 Subject: [erlang-patches] Forbid returning a match context in beam_validator Message-ID: <142461CA-86A4-4226-88B6-AF26987DF438@gmail.com> Hello, The compiler doesn't check whether a match context is returned by the given BEAM assembly in beam_validator, this patch fixes that. git fetch https://github.com/nox/otp.git match-context-return https://github.com/nox/otp/compare/erlang:maint...match-context-return https://github.com/nox/otp/compare/erlang:maint...match-context-return.patch Regards, -- Anthony Ramine From yura.beznos@REDACTED Thu Aug 1 07:40:44 2013 From: yura.beznos@REDACTED (Yura Beznos) Date: Thu, 1 Aug 2013 09:40:44 +0400 Subject: [erlang-patches] crypto: Add IGE mode for AES Message-ID: Hello, I'd like to submit this patch to add two new functions to the crypt library. Repo branch: https://github.com/Zhiz0id/otp/tree/aes_ige_crypt Compare: https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt Why this new feature? It allows to use OpenSSL aes_ige_encrypt function. Risks / uncertain artifacts None. How did you solve it? Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt . Thanks. -- Yura -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Thu Aug 1 10:20:20 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 1 Aug 2013 10:20:20 +0200 Subject: [erlang-patches] crypto: Add IGE mode for AES In-Reply-To: References: Message-ID: <51FA1A44.4060401@erlang.org> On 08/01/2013 07:40 AM, Yura Beznos wrote: > Hello, > > I'd like to submit this patch to add two new functions to the crypt > library. > > Repo branch: https://github.com/Zhiz0id/otp/tree/aes_ige_crypt > Compare: > https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt > > Why this new feature? > > It allows to use OpenSSL aes_ige_encrypt function. > > Risks / uncertain artifacts > > None. > > How did you solve it? > > Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt . > > > Thanks. > > > -- > Yura > > > > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello Yura, I've assigned this patch to be reviewed by responsible, you will get feedback as soon as this is done. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik@REDACTED Thu Aug 1 10:31:28 2013 From: fredrik@REDACTED (Fredrik) Date: Thu, 1 Aug 2013 10:31:28 +0200 Subject: [erlang-patches] Forbid returning a match context in beam_validator In-Reply-To: <142461CA-86A4-4226-88B6-AF26987DF438@gmail.com> References: <142461CA-86A4-4226-88B6-AF26987DF438@gmail.com> Message-ID: <51FA1CE0.201@erlang.org> On 08/01/2013 02:14 AM, Anthony Ramine wrote: > Hello, > > The compiler doesn't check whether a match context is returned by the given BEAM assembly in beam_validator, this patch fixes that. > > git fetch https://github.com/nox/otp.git match-context-return > > https://github.com/nox/otp/compare/erlang:maint...match-context-return > https://github.com/nox/otp/compare/erlang:maint...match-context-return.patch > > Regards, > Hello Anthony, I've fetched your patch it is cooking in the 'pu' branch. Added primary bootstrap. Thanks, -- BR Fredrik Gustafsson Erlang OTP Team From davidnwelton@REDACTED Mon Aug 5 17:42:44 2013 From: davidnwelton@REDACTED (David Welton) Date: Mon, 5 Aug 2013 17:42:44 +0200 Subject: [erlang-patches] xmerl_ug one word documentation fix Message-ID: Change "wright" to "write". --- a/lib/xmerl/doc/src/xmerl_ug.xmlsrc +++ b/lib/xmerl/doc/src/xmerl_ug.xmlsrc @@ -409,9 +409,9 @@ Data = specification but the basic functionality. For all details see the reference manual

First, some words about the xmerl_xs functionality:

-

You need to wright template functions to be able to control +

You need to write template functions to be able to control what kind of output you want. Thus if you want to encapsulate a - bike element in <p> tags you simply wright a + bike element in <p> tags you simply write a function:

 template(E = #xmlElement{name='bike'}) ->

Thanks,
-- 
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/


From fredrik@REDACTED  Tue Aug  6 12:25:45 2013
From: fredrik@REDACTED (Fredrik)
Date: Tue, 6 Aug 2013 12:25:45 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: 
References: 
Message-ID: <5200CF29.50703@erlang.org>

On 08/05/2013 05:42 PM, David Welton wrote:
> Change "wright" to "write".
>
> --- a/lib/xmerl/doc/src/xmerl_ug.xmlsrc
> +++ b/lib/xmerl/doc/src/xmerl_ug.xmlsrc
> @@ -409,9 +409,9 @@ Data =
>         specification but the basic functionality. For all details see
>         thereference manual

>       
First, some words about the xmerl_xs functionality:

> -
You need to wright template functions to be able to control
> +
You need to write template functions to be able to control
>         what kind of output you want. Thus if you want to encapsulate a
> -bike  element in<p> tags you simply wright a
> +bike  element in<p> tags you simply write a
>         function:

>       
>   template(E = #xmlElement{name='bike'}) ->
>
> Thanks,
Hello,
Could you please read 
https://github.com/erlang/otp/wiki/submitting-patches ,
A pull-request would be perfect for this type of changes!

-- 

BR Fredrik Gustafsson
Erlang OTP Team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From n.oxyde@REDACTED  Tue Aug  6 12:47:25 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Tue, 6 Aug 2013 12:47:25 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: <5200CF29.50703@erlang.org>
References: 
 <5200CF29.50703@erlang.org>
Message-ID: <82ECBCEE-AC53-421E-AF90-CD362DFA92F2@gmail.com>

What's the point of segregating patches?

Will I need to use the damn pull request form if I want to submit a small patch?

-- 
Anthony Ramine

Le 6 ao?t 2013 ? 12:25, Fredrik a ?crit :

> On 08/05/2013 05:42 PM, David Welton wrote:
>> Change "wright" to "write".
>> 
>> --- a/lib/xmerl/doc/src/xmerl_ug.xmlsrc
>> +++ b/lib/xmerl/doc/src/xmerl_ug.xmlsrc
>> @@ -409,9 +409,9 @@ Data =
>>        specification but the basic functionality. For all details see
>>        the reference manual

>>      
First, some words about the xmerl_xs functionality:

>> -    
You need to wright template functions to be able to control
>> +    
You need to write template functions to be able to control
>>        what kind of output you want. Thus if you want to encapsulate a
>> -      bike element in <p> tags you simply wright a
>> +      bike element in <p> tags you simply write a
>>        function:

>>      
>>  template(E = #xmlElement{name='bike'}) ->
>> 
>> Thanks,
>> 
> Hello,
> Could you please read https://github.com/erlang/otp/wiki/submitting-patches , 
> A pull-request would be perfect for this type of changes!
> 
> -- 
> 
> BR Fredrik Gustafsson
> Erlang OTP Team
> 
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches



From n.oxyde@REDACTED  Tue Aug  6 13:12:35 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Tue, 6 Aug 2013 13:12:35 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: <82ECBCEE-AC53-421E-AF90-CD362DFA92F2@gmail.com>
References: 
 <5200CF29.50703@erlang.org> <82ECBCEE-AC53-421E-AF90-CD362DFA92F2@gmail.com>
Message-ID: <397D4B90-910E-4228-B362-CDCFDFF496C7@gmail.com>

Also, your link says nothing about a segregation of small or big patches.

-- 
Anthony Ramine

Le 6 ao?t 2013 ? 12:47, Anthony Ramine a ?crit :

> What's the point of segregating patches?
> 
> Will I need to use the damn pull request form if I want to submit a small patch?
> 
> -- 
> Anthony Ramine
> 
> Le 6 ao?t 2013 ? 12:25, Fredrik a ?crit :
> 
>> On 08/05/2013 05:42 PM, David Welton wrote:
>>> Change "wright" to "write".
>>> 
>>> --- a/lib/xmerl/doc/src/xmerl_ug.xmlsrc
>>> +++ b/lib/xmerl/doc/src/xmerl_ug.xmlsrc
>>> @@ -409,9 +409,9 @@ Data =
>>>       specification but the basic functionality. For all details see
>>>       the reference manual

>>>     
First, some words about the xmerl_xs functionality:

>>> -    
You need to wright template functions to be able to control
>>> +    
You need to write template functions to be able to control
>>>       what kind of output you want. Thus if you want to encapsulate a
>>> -      bike element in <p> tags you simply wright a
>>> +      bike element in <p> tags you simply write a
>>>       function:

>>>     
>>> template(E = #xmlElement{name='bike'}) ->
>>> 
>>> Thanks,
>>> 
>> Hello,
>> Could you please read https://github.com/erlang/otp/wiki/submitting-patches , 
>> A pull-request would be perfect for this type of changes!
>> 
>> -- 
>> 
>> BR Fredrik Gustafsson
>> Erlang OTP Team
>> 
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
> 



From fredrik@REDACTED  Tue Aug  6 14:24:21 2013
From: fredrik@REDACTED (Fredrik)
Date: Tue, 6 Aug 2013 14:24:21 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: <82ECBCEE-AC53-421E-AF90-CD362DFA92F2@gmail.com>
References: 
 <5200CF29.50703@erlang.org> <82ECBCEE-AC53-421E-AF90-CD362DFA92F2@gmail.com>
Message-ID: <5200EAF5.4060304@erlang.org>

On 08/06/2013 12:47 PM, Anthony Ramine wrote:
> What's the point of segregating patches?
>
> Will I need to use the damn pull request form if I want to submit a small patch?
>
No need for cursing ;)
There has been people asking about pull requests a while now so we 
thought that it was a positive decision to accept this, though your 
input does not prove this.
You don't have to use it. You can submit your patch by sending the 
ordinary git-fetch mail.

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From n.oxyde@REDACTED  Tue Aug  6 14:30:26 2013
From: n.oxyde@REDACTED (Anthony Ramine)
Date: Tue, 6 Aug 2013 14:30:26 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: <5200EAF5.4060304@erlang.org>
References: 
 <5200CF29.50703@erlang.org> <82ECBCEE-AC53-421E-AF90-CD362DFA92F2@gmail.com>
 <5200EAF5.4060304@erlang.org>
Message-ID: <811BD084-E78E-481F-B075-C2EB17724670@gmail.com>

Yeah sorry, but this form makes me angry. Nice to know we can continue submitting through here.

-- 
Anthony Ramine

Le 6 ao?t 2013 ? 14:24, Fredrik a ?crit :

> No need for cursing ;)



From davidnwelton@REDACTED  Tue Aug  6 15:48:33 2013
From: davidnwelton@REDACTED (David Welton)
Date: Tue, 6 Aug 2013 15:48:33 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: <5200CF29.50703@erlang.org>
References: 
 <5200CF29.50703@erlang.org>
Message-ID: 

Hi,

I don't think cloning all of OTP for a few bytes worth of simple
changes in documentation makes much sense.

I mean, this is such a small change that it's easy to describe in English:

1. Open lib/xmerl/doc/src/xmerl_ug.xmlsrc with your favorite editor.
2. Replace all instances of "wright" with "write".

This could be done in less time than it takes to reply to this email.

I understand that actually code changes of any significance would be
better off going through version control in order to better track
them, and will be sure to do so should I ever have occasion to submit
other patches.

Thank you,
-- 
David N. Welton

http://www.dedasys.com/

3. For bonus points, you could search for 'wright' in other bits of
OTP.  It does exist in English, but it's a word that's not likely to
be found in OTP.


From fredrik@REDACTED  Tue Aug  6 15:53:21 2013
From: fredrik@REDACTED (Fredrik)
Date: Tue, 6 Aug 2013 15:53:21 +0200
Subject: [erlang-patches] xmerl_ug one word documentation fix
In-Reply-To: 
References: 
 <5200CF29.50703@erlang.org>
 
Message-ID: <5200FFD1.4060404@erlang.org>

On 08/06/2013 03:48 PM, David Welton wrote:
> Hi,
>
> I don't think cloning all of OTP for a few bytes worth of simple
> changes in documentation makes much sense.
>
> I mean, this is such a small change that it's easy to describe in English:
>
> 1. Open lib/xmerl/doc/src/xmerl_ug.xmlsrc with your favorite editor.
> 2. Replace all instances of "wright" with "write".
>
> This could be done in less time than it takes to reply to this email.
>
> I understand that actually code changes of any significance would be
> better off going through version control in order to better track
> them, and will be sure to do so should I ever have occasion to submit
> other patches.
>
> Thank you,
Yes, I understand what you are saying, I just thought that you wanted 
the credit (the changing commit) for this.
I'll make the proper changes.
Thanks,

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From olgeni@REDACTED  Wed Aug  7 14:39:04 2013
From: olgeni@REDACTED (Jimmy Olgeni)
Date: Wed, 7 Aug 2013 14:39:04 +0200 (CEST)
Subject: [erlang-patches] Misc. fixes for erl_driver(3) man page
Message-ID: 


Hello,

This patch fixes a few things in erl_driver(3) (typos, and an 
incorrect function name).

git fetch git://github.com/olgeni/otp.git erl_driver-man-fixes

https://github.com/olgeni/otp/compare/erlang:maint...erl_driver-man-fixes
https://github.com/olgeni/otp/compare/erlang:maint...erl_driver-man-fixes.patch

-- 
jimmy


From fredrik@REDACTED  Wed Aug  7 14:45:42 2013
From: fredrik@REDACTED (Fredrik)
Date: Wed, 7 Aug 2013 14:45:42 +0200
Subject: [erlang-patches] Misc. fixes for erl_driver(3) man page
In-Reply-To: 
References: 
Message-ID: <52024176.90504@erlang.org>

On 08/07/2013 02:39 PM, Jimmy Olgeni wrote:
>
> Hello,
>
> This patch fixes a few things in erl_driver(3) (typos, and an 
> incorrect function name).
>
> git fetch git://github.com/olgeni/otp.git erl_driver-man-fixes
>
> https://github.com/olgeni/otp/compare/erlang:maint...erl_driver-man-fixes
> https://github.com/olgeni/otp/compare/erlang:maint...erl_driver-man-fixes.patch 
>
>
Hello Jimmy,
Could you please squash these changes to one single commit?
Thanks,

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From olgeni@REDACTED  Wed Aug  7 14:53:19 2013
From: olgeni@REDACTED (Jimmy Olgeni)
Date: Wed, 7 Aug 2013 14:53:19 +0200 (CEST)
Subject: [erlang-patches] Misc. fixes for erl_driver(3) man page
In-Reply-To: <52024176.90504@erlang.org>
References: 
 <52024176.90504@erlang.org>
Message-ID: 


Hello,

On Wed, 7 Aug 2013, Fredrik wrote:

> Could you please squash these changes to one single commit?

Done - squashed on the same branch as before.

-- 
jimmy


From fredrik@REDACTED  Wed Aug  7 15:08:43 2013
From: fredrik@REDACTED (Fredrik)
Date: Wed, 7 Aug 2013 15:08:43 +0200
Subject: [erlang-patches] Misc. fixes for erl_driver(3) man page
In-Reply-To: 
References: 
 <52024176.90504@erlang.org>
 
Message-ID: <520246DB.6040308@erlang.org>

On 08/07/2013 02:53 PM, Jimmy Olgeni wrote:
>
> Hello,
>
> On Wed, 7 Aug 2013, Fredrik wrote:
>
>> Could you please squash these changes to one single commit?
>
> Done - squashed on the same branch as before.
>
Fetched.
Thanks,

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From sverker.eriksson@REDACTED  Tue Aug 13 14:43:38 2013
From: sverker.eriksson@REDACTED (Sverker Eriksson)
Date: Tue, 13 Aug 2013 14:43:38 +0200
Subject: [erlang-patches] crypto: Add IGE mode for AES
In-Reply-To: <51FA1A44.4060401@erlang.org>
References: 
 <51FA1A44.4060401@erlang.org>
Message-ID: <520A29FA.9080602@erix.ericsson.se>

Fredrik wrote:
> On 08/01/2013 07:40 AM, Yura Beznos wrote:
>> Hello,
>>
>> I'd like to submit this patch to add two new functions to the crypt
>> library.
>>
>> Repo branch: https://github.com/Zhiz0id/otp/tree/aes_ige_crypt
>> Compare:
>> https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt
>>
>> Why this new feature?
>>
>> It allows to use OpenSSL aes_ige_encrypt function.
>>
>> Risks / uncertain artifacts
>>
>> None.
>>
>> How did you solve it?
>>
>> Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt .
>>
>>
>> Thanks.
>>
>>
>> -- 
>> Yura
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
> Hello Yura,
> I've assigned this patch to be reviewed by responsible, you will get 
> feedback as soon as this is done.
> Thanks,

Looks good, Yura. Two objections though:

1. Do not export the aes_ige_256_encrypt/decrypt functions. Users should 
only use block_encrypt/4 and block_decrypt/4.

2. Documentation updates is missing (of block_encrypt/4 and 
block_decrypt/4).


/Sverker, Erlang/OTP



From yura.beznos@REDACTED  Tue Aug 13 17:40:03 2013
From: yura.beznos@REDACTED (Yura Beznos)
Date: Tue, 13 Aug 2013 19:40:03 +0400
Subject: [erlang-patches] crypto: Add IGE mode for AES
In-Reply-To: <520A29FA.9080602@erix.ericsson.se>
References: 
 <51FA1A44.4060401@erlang.org> <520A29FA.9080602@erix.ericsson.se>
Message-ID: 

Updated:
https://github.com/Zhiz0id/otp/commit/0d77985af825e9e419d28a502e6116339af076e6
1. fixed, no export
2. added docs.

--
Yura


On Tue, Aug 13, 2013 at 4:43 PM, Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:

> Fredrik wrote:
>
>> On 08/01/2013 07:40 AM, Yura Beznos wrote:
>>
>>> Hello,
>>>
>>> I'd like to submit this patch to add two new functions to the crypt
>>> library.
>>>
>>> Repo branch: https://github.com/Zhiz0id/**otp/tree/aes_ige_crypt
>>> Compare:
>>> https://github.com/Zhiz0id/**otp/compare/erlang:master...**aes_ige_crypt
>>>
>>> Why this new feature?
>>>
>>> It allows to use OpenSSL aes_ige_encrypt function.
>>>
>>> Risks / uncertain artifacts
>>>
>>> None.
>>>
>>> How did you solve it?
>>>
>>> Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt .
>>>
>>>
>>> Thanks.
>>>
>>>
>>> --
>>> Yura
>>>
>>>
>>>
>>> ______________________________**_________________
>>> erlang-patches mailing list
>>> erlang-patches@REDACTED
>>> http://erlang.org/mailman/**listinfo/erlang-patches
>>>
>> Hello Yura,
>> I've assigned this patch to be reviewed by responsible, you will get
>> feedback as soon as this is done.
>> Thanks,
>>
>
> Looks good, Yura. Two objections though:
>
> 1. Do not export the aes_ige_256_encrypt/decrypt functions. Users should
> only use block_encrypt/4 and block_decrypt/4.
>
> 2. Documentation updates is missing (of block_encrypt/4 and
> block_decrypt/4).
>
>
> /Sverker, Erlang/OTP
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From yura.beznos@REDACTED  Tue Aug 13 21:31:49 2013
From: yura.beznos@REDACTED (Yura Beznos)
Date: Tue, 13 Aug 2013 23:31:49 +0400
Subject: [erlang-patches] crypto: Add IGE mode for AES
In-Reply-To: <520A29FA.9080602@erix.ericsson.se>
References: 
 <51FA1A44.4060401@erlang.org> <520A29FA.9080602@erix.ericsson.se>
Message-ID: 

On Tue, Aug 13, 2013 at 4:43 PM, Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:

> Fredrik wrote:
>
>> On 08/01/2013 07:40 AM, Yura Beznos wrote:
>>
>>> Hello,
>>>
>>> I'd like to submit this patch to add two new functions to the crypt
>>> library.
>>>
>>> Repo branch: https://github.com/Zhiz0id/**otp/tree/aes_ige_crypt
>>> Compare:
>>> https://github.com/Zhiz0id/**otp/compare/erlang:master...**aes_ige_crypt
>>>
>>> Why this new feature?
>>>
>>> It allows to use OpenSSL aes_ige_encrypt function.
>>>
>>> Risks / uncertain artifacts
>>>
>>> None.
>>>
>>> How did you solve it?
>>>
>>> Added two functions: aes_ige_256_decrypt, aes_ige_256_encrypt .
>>>
>>>
>>> Thanks.
>>>
>>>
>>> --
>>> Yura
>>>
>>>
>>>
>>> ______________________________**_________________
>>> erlang-patches mailing list
>>> erlang-patches@REDACTED
>>> http://erlang.org/mailman/**listinfo/erlang-patches
>>>
>> Hello Yura,
>> I've assigned this patch to be reviewed by responsible, you will get
>> feedback as soon as this is done.
>> Thanks,
>>
>
> Looks good, Yura. Two objections though:
>
> 1. Do not export the aes_ige_256_encrypt/decrypt functions. Users should
> only use block_encrypt/4 and block_decrypt/4.
>
> 2. Documentation updates is missing (of block_encrypt/4 and
> block_decrypt/4).
>
>
> /Sverker, Erlang/OTP
>
>

Compare url:
https://github.com/Zhiz0id/otp/compare/erlang:master...aes_ige_crypt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From fredrik@REDACTED  Tue Aug 20 12:19:31 2013
From: fredrik@REDACTED (Fredrik)
Date: Tue, 20 Aug 2013 12:19:31 +0200
Subject: [erlang-patches] Fix httpd config option 'erl_script_nocache'
In-Reply-To: <20130622183700.GA8171@molb.org>
References: <20130622183700.GA8171@molb.org>
Message-ID: <521342B3.1080002@erlang.org>

On 06/22/2013 08:37 PM, Johannes Wei?l wrote:
> Hello!
>
> This patch fixes the usage of the httpd configuration option
> 'erl_script_nocache', which got ignored before.
>
> git fetch git://github.com/weisslj/otp.git fix-httpd-erl-script-nocache
>
> https://github.com/weisslj/otp/compare/erlang:maint...fix-httpd-erl-script-nocache
> https://github.com/weisslj/otp/compare/erlang:maint...fix-httpd-erl-script-nocache.patch
>
> Greetings,
>
> Johannes Wei?l
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
Hello Johannes,
Could you please provide a testcase for this particular issue in your patch?

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From vinoski@REDACTED  Wed Aug 21 15:45:44 2013
From: vinoski@REDACTED (Steve Vinoski)
Date: Wed, 21 Aug 2013 09:45:44 -0400
Subject: [erlang-patches] patch to add option to set schedulers by percentage
Message-ID: 

For applications where measurements show enhanced performance from the use
of a non-default number of emulator scheduler threads, having to accurately
set the right number of scheduler threads across multiple hosts each with
different numbers of logical processors is difficult because the erl +S
option requires absolute numbers of scheduler threads and scheduler threads
online to be specified.

To address this issue, this patch adds a +SP option to erl, similar to the
existing +S option but allowing the number of scheduler threads and
scheduler threads online to be set as percentages of logical processors
configured and logical processors available, respectively. For example,
"+SP 50:25" sets the number of scheduler threads to 50% of the logical
processors configured, and the number of scheduler threads online to 25% of
the logical processors available.

https://github.com/erlang/otp/pull/58

--steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tomas.abrahamsson@REDACTED  Wed Aug 21 22:35:28 2013
From: tomas.abrahamsson@REDACTED (Tomas Abrahamsson)
Date: Wed, 21 Aug 2013 22:35:28 +0200
Subject: [erlang-patches] [PATCH] Make the Emacs Erlang mode TRAMP-aware
	when compiling
Message-ID: <1377117328-16124-1-git-send-email-tomas.abrahamsson@gmail.com>

In Emacs it is possible to remotely edit a file, by opening for
example /ssh:somehost.com:/path/to/file.erl.  In Emacs, the feature
that makes this possible, is called TRAMP.  When compiling such a file,
by typing C-c C-k, an inferior Erlang shell is opened on the remote
host, but the compilation expression that was evaluated in the remote
Erlang shell was:

   c("/ssh:somehost.com:/path/to/file", [...]).

which resulted in a "no such file or directory" error.
This commit changes the compilation expression into:

   c("/path/to/file", [...]).

for files opened remotely via TRAMP.  The file name is adjusted
similarly when compiling .yrl and .xrl files.

In a buffer opened remotely, the Elisp function buffer-file-name
returns the full path with TRAMP syntax.  In this example it would
be "/ssh:somehost.com:/path/to/file.erl".  A new function,
erlang-local-buffer-file-name, has been introduced, which peels off
the TRAMP syntax on remotely opened files, while for locally opened
files, it just calls buffer-file-name.
---
 lib/tools/emacs/erlang.el | 44 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 37 insertions(+), 7 deletions(-)

diff --git a/lib/tools/emacs/erlang.el b/lib/tools/emacs/erlang.el
index b5da9e7..6589047 100644
--- a/lib/tools/emacs/erlang.el
+++ b/lib/tools/emacs/erlang.el
@@ -5286,7 +5286,7 @@ There exists two workarounds for this bug:
   (inferior-erlang-prepare-for-input)
   (let* ((dir (inferior-erlang-compile-outdir))
 ;;; (file (file-name-nondirectory (buffer-file-name)))
-	 (noext (substring (buffer-file-name) 0 -4))
+	 (noext (substring (erlang-local-buffer-file-name) 0 -4))
 	 (opts (append (list (cons 'outdir dir))
 		       (if current-prefix-arg
 			   (list 'debug_info 'export_all))
@@ -5324,7 +5324,7 @@ unless the optional NO-DISPLAY is non-nil."
 (defun inferior-erlang-compile-outdir ()
   "Return the directory to compile the current buffer into."
   (let* ((buffer-dir (directory-file-name
-		      (file-name-directory (buffer-file-name))))
+		      (file-name-directory (erlang-local-buffer-file-name))))
 	 (parent-dir (directory-file-name
 		      (file-name-directory buffer-dir)))
          (ebin-dir (concat (file-name-as-directory parent-dir) "ebin"))
@@ -5342,11 +5342,11 @@ unless the optional NO-DISPLAY is non-nil."
 	(res (inferior-erlang-compute-erl-compile-command module-name opts))
 	ccfn-entry
 	done)
-    (if (not (null (buffer-file-name)))
+    (if (not (null (erlang-local-buffer-file-name)))
 	(while (and (not done) (not (null ccfn)))
 	  (setq ccfn-entry (car ccfn))
 	  (setq ccfn (cdr ccfn))
-	  (if (string-match (car ccfn-entry) (buffer-file-name))
+	  (if (string-match (car ccfn-entry) (erlang-local-buffer-file-name))
 	      (let ((c-fn (cdr ccfn-entry)))
 		(setq done t)
 		(if (not (null c-fn))
@@ -5378,7 +5378,7 @@ unless the optional NO-DISPLAY is non-nil."
 	 tmpvar tmpvar tmpvar2)))))
 
 (defun inferior-erlang-compute-leex-compile-command (module-name opts)
-  (let ((file-name        (buffer-file-name))
+  (let ((file-name        (erlang-local-buffer-file-name))
 	(erl-compile-expr (inferior-erlang-remove-any-trailing-dot
 			   (inferior-erlang-compute-erl-compile-command
 			    module-name opts))))
@@ -5397,7 +5397,7 @@ unless the optional NO-DISPLAY is non-nil."
 	    erl-compile-expr)))
 
 (defun inferior-erlang-compute-yecc-compile-command (module-name opts)
-  (let ((file-name        (buffer-file-name))
+  (let ((file-name        (erlang-local-buffer-file-name))
 	(erl-compile-expr (inferior-erlang-remove-any-trailing-dot
 			   (inferior-erlang-compute-erl-compile-command
 			    module-name opts))))
@@ -5448,6 +5448,36 @@ unless the optional NO-DISPLAY is non-nil."
       (setq strs (cdr strs)))
     result))
 
+(defun erlang-local-buffer-file-name ()
+  ;; When editing a file remotely via tramp,
+  ;; the buffer's file name may be for example
+  ;; "/ssh:host.example.com:/some/path/x.erl"
+  ;;
+  ;; If I try to compile such a file using C-c C-k, an
+  ;; erlang shell on the remote host is automatically
+  ;; started if needed, but for it to successfully compile
+  ;; the file, the c(...)  command that is sent must contain
+  ;; the file name "/some/path/x.erl" without the
+  ;; tramp-prefix "/ssh:host.example.com:".
+  (cond ((null (buffer-file-name))
+	 nil)
+	((erlang-tramp-remote-file-p)
+	 (erlang-tramp-get-localname))
+	(t
+	 (buffer-file-name))))
+
+(defun erlang-tramp-remote-file-p ()
+  (and (fboundp 'tramp-tramp-file-p)
+       (tramp-tramp-file-p (buffer-file-name))))
+
+(defun erlang-tramp-get-localname ()
+  (let ((tramp-info (tramp-dissect-file-name (buffer-file-name))))
+    (if (fboundp 'tramp-file-name-localname)
+	(tramp-file-name-localname tramp-info)
+      ;; In old versions of tramp, it was `tramp-file-name-path'
+      ;; instead of the newer `tramp-file-name-localname'
+      (tramp-file-name-path tramp-info))))
+
 ;; `next-error' only accepts buffers with major mode `compilation-mode'
 ;; or with the minor mode `compilation-minor-mode' activated.
 ;; (To activate the minor mode is out of the question, since it will
@@ -5482,7 +5512,7 @@ Capable of finding error messages in an inferior Erlang buffer."
   "Make the inferior Erlang change directory.
 The default is to go to the directory of the current buffer."
   (interactive)
-  (or dir (setq dir (file-name-directory (buffer-file-name))))
+  (or dir (setq dir (file-name-directory (erlang-local-buffer-file-name))))
   (or (inferior-erlang-running-p)
       (error "No inferior Erlang is running"))
   (inferior-erlang-display-buffer)
-- 
1.8.3.1



From fredrik@REDACTED  Thu Aug 22 14:48:51 2013
From: fredrik@REDACTED (Fredrik)
Date: Thu, 22 Aug 2013 14:48:51 +0200
Subject: [erlang-patches] [PATCH] Make the Emacs Erlang mode TRAMP-aware
 when compiling
In-Reply-To: <1377117328-16124-1-git-send-email-tomas.abrahamsson@gmail.com>
References: <1377117328-16124-1-git-send-email-tomas.abrahamsson@gmail.com>
Message-ID: <521608B3.1000502@erlang.org>

On 08/21/2013 10:35 PM, Tomas Abrahamsson wrote:
> In Emacs it is possible to remotely edit a file, by opening for
> example /ssh:somehost.com:/path/to/file.erl.  In Emacs, the feature
> that makes this possible, is called TRAMP.  When compiling such a file,
> by typing C-c C-k, an inferior Erlang shell is opened on the remote
> host, but the compilation expression that was evaluated in the remote
> Erlang shell was:
>
>     c("/ssh:somehost.com:/path/to/file", [...]).
>
> which resulted in a "no such file or directory" error.
> This commit changes the compilation expression into:
>
>     c("/path/to/file", [...]).
>
> for files opened remotely via TRAMP.  The file name is adjusted
> similarly when compiling .yrl and .xrl files.
>
> In a buffer opened remotely, the Elisp function buffer-file-name
> returns the full path with TRAMP syntax.  In this example it would
> be "/ssh:somehost.com:/path/to/file.erl".  A new function,
> erlang-local-buffer-file-name, has been introduced, which peels off
> the TRAMP syntax on remotely opened files, while for locally opened
> files, it just calls buffer-file-name.
> ---
>   lib/tools/emacs/erlang.el | 44 +++++++++++++++++++++++++++++++++++++-------
>   1 file changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/lib/tools/emacs/erlang.el b/lib/tools/emacs/erlang.el
> index b5da9e7..6589047 100644
> --- a/lib/tools/emacs/erlang.el
> +++ b/lib/tools/emacs/erlang.el
> @@ -5286,7 +5286,7 @@ There exists two workarounds for this bug:
>     (inferior-erlang-prepare-for-input)
>     (let* ((dir (inferior-erlang-compile-outdir))
>   ;;; (file (file-name-nondirectory (buffer-file-name)))
> -	 (noext (substring (buffer-file-name) 0 -4))
> +	 (noext (substring (erlang-local-buffer-file-name) 0 -4))
>   	 (opts (append (list (cons 'outdir dir))
>   		       (if current-prefix-arg
>   			   (list 'debug_info 'export_all))
> @@ -5324,7 +5324,7 @@ unless the optional NO-DISPLAY is non-nil."
>   (defun inferior-erlang-compile-outdir ()
>     "Return the directory to compile the current buffer into."
>     (let* ((buffer-dir (directory-file-name
> -		      (file-name-directory (buffer-file-name))))
> +		      (file-name-directory (erlang-local-buffer-file-name))))
>   	 (parent-dir (directory-file-name
>   		      (file-name-directory buffer-dir)))
>            (ebin-dir (concat (file-name-as-directory parent-dir) "ebin"))
> @@ -5342,11 +5342,11 @@ unless the optional NO-DISPLAY is non-nil."
>   	(res (inferior-erlang-compute-erl-compile-command module-name opts))
>   	ccfn-entry
>   	done)
> -    (if (not (null (buffer-file-name)))
> +    (if (not (null (erlang-local-buffer-file-name)))
>   	(while (and (not done) (not (null ccfn)))
>   	  (setq ccfn-entry (car ccfn))
>   	  (setq ccfn (cdr ccfn))
> -	  (if (string-match (car ccfn-entry) (buffer-file-name))
> +	  (if (string-match (car ccfn-entry) (erlang-local-buffer-file-name))
>   	      (let ((c-fn (cdr ccfn-entry)))
>   		(setq done t)
>   		(if (not (null c-fn))
> @@ -5378,7 +5378,7 @@ unless the optional NO-DISPLAY is non-nil."
>   	 tmpvar tmpvar tmpvar2)))))
>
>   (defun inferior-erlang-compute-leex-compile-command (module-name opts)
> -  (let ((file-name        (buffer-file-name))
> +  (let ((file-name        (erlang-local-buffer-file-name))
>   	(erl-compile-expr (inferior-erlang-remove-any-trailing-dot
>   			   (inferior-erlang-compute-erl-compile-command
>   			    module-name opts))))
> @@ -5397,7 +5397,7 @@ unless the optional NO-DISPLAY is non-nil."
>   	    erl-compile-expr)))
>
>   (defun inferior-erlang-compute-yecc-compile-command (module-name opts)
> -  (let ((file-name        (buffer-file-name))
> +  (let ((file-name        (erlang-local-buffer-file-name))
>   	(erl-compile-expr (inferior-erlang-remove-any-trailing-dot
>   			   (inferior-erlang-compute-erl-compile-command
>   			    module-name opts))))
> @@ -5448,6 +5448,36 @@ unless the optional NO-DISPLAY is non-nil."
>         (setq strs (cdr strs)))
>       result))
>
> +(defun erlang-local-buffer-file-name ()
> +  ;; When editing a file remotely via tramp,
> +  ;; the buffer's file name may be for example
> +  ;; "/ssh:host.example.com:/some/path/x.erl"
> +  ;;
> +  ;; If I try to compile such a file using C-c C-k, an
> +  ;; erlang shell on the remote host is automatically
> +  ;; started if needed, but for it to successfully compile
> +  ;; the file, the c(...)  command that is sent must contain
> +  ;; the file name "/some/path/x.erl" without the
> +  ;; tramp-prefix "/ssh:host.example.com:".
> +  (cond ((null (buffer-file-name))
> +	 nil)
> +	((erlang-tramp-remote-file-p)
> +	 (erlang-tramp-get-localname))
> +	(t
> +	 (buffer-file-name))))
> +
> +(defun erlang-tramp-remote-file-p ()
> +  (and (fboundp 'tramp-tramp-file-p)
> +       (tramp-tramp-file-p (buffer-file-name))))
> +
> +(defun erlang-tramp-get-localname ()
> +  (let ((tramp-info (tramp-dissect-file-name (buffer-file-name))))
> +    (if (fboundp 'tramp-file-name-localname)
> +	(tramp-file-name-localname tramp-info)
> +      ;; In old versions of tramp, it was `tramp-file-name-path'
> +      ;; instead of the newer `tramp-file-name-localname'
> +      (tramp-file-name-path tramp-info))))
> +
>   ;; `next-error' only accepts buffers with major mode `compilation-mode'
>   ;; or with the minor mode `compilation-minor-mode' activated.
>   ;; (To activate the minor mode is out of the question, since it will
> @@ -5482,7 +5512,7 @@ Capable of finding error messages in an inferior Erlang buffer."
>     "Make the inferior Erlang change directory.
>   The default is to go to the directory of the current buffer."
>     (interactive)
> -  (or dir (setq dir (file-name-directory (buffer-file-name))))
> +  (or dir (setq dir (file-name-directory (erlang-local-buffer-file-name))))
>     (or (inferior-erlang-running-p)
>         (error "No inferior Erlang is running"))
>     (inferior-erlang-display-buffer)
Hello Tomas,
Thanks for the patch. I've applied it and assigned it to be reviewed by 
responsible developers.


-- 

BR Fredrik Gustafsson
Erlang OTP Team



From lukas@REDACTED  Thu Aug 22 16:11:54 2013
From: lukas@REDACTED (Lukas Larsson)
Date: Thu, 22 Aug 2013 16:11:54 +0200
Subject: [erlang-patches] patch to add option to set schedulers by
	percentage
In-Reply-To: 
References: 
Message-ID: <52161C2A.7010601@erlang.org>

Hello Steve,

Have you given any thoughts on what should happen if you chain multiple 
+SP commands? i.e.

erl +S 16:16 +SP 50:50 +SP 50:50

Our view right now is that this should give [8:8] and not [4:4] as it 
currently does in the patch.

Related to this we also do not think that the order to +S vs +SP 
commands should matter. i.e.

erl +S 16:16 +SP 50:50 +S 16:16

should give [8:8] and not [16:16].

What do you think? These things are for sure odd cases to think about, 
but if it is possible someone will for sure do it....

Lukas

On 21/08/13 15:45, Steve Vinoski wrote:
> For applications where measurements show enhanced performance from the 
> use of a non-default number of emulator scheduler threads, having to 
> accurately set the right number of scheduler threads across multiple 
> hosts each with different numbers of logical processors is difficult 
> because the erl +S option requires absolute numbers of scheduler 
> threads and scheduler threads online to be specified.
>
> To address this issue, this patch adds a +SP option to erl, similar to 
> the existing +S option but allowing the number of scheduler threads 
> and scheduler threads online to be set as percentages of logical 
> processors configured and logical processors available, respectively. 
> For example, "+SP 50:25" sets the number of scheduler threads to 50% 
> of the logical processors configured, and the number of scheduler 
> threads online to 25% of the logical processors available.
>
> https://github.com/erlang/otp/pull/58
>
> --steve
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vinoski@REDACTED  Thu Aug 22 18:55:27 2013
From: vinoski@REDACTED (Steve Vinoski)
Date: Thu, 22 Aug 2013 12:55:27 -0400
Subject: [erlang-patches] patch to add option to set schedulers by
	percentage
In-Reply-To: <52161C2A.7010601@erlang.org>
References: 
 <52161C2A.7010601@erlang.org>
Message-ID: 

Hi Lukas,

Thanks for the feedback. After our IRC conversation today covering the
details of this issue, I agree it's clearer if this patch doesn't introduce
order dependencies between +S and +SP options or introduce accumulated
effects of multiple +SP options. I'll change my branch to do the following:

* ensure that later +SP options on the command line completely replace any
previous +SP options, so there's no accumulated effects between them (which
implies "+SP 100:100" can undo any previous +SP options)

* keep interactions between +S and +SP options, but remove ordering
dependencies, thus your example "+S 16:16 +SP 50:50 +S 16:16" would result
in [8:8] as you've specified, as would both "+SP 50:50 +S 16:16" and "+S
16:16 +SP 50:50"

* document and add tests for the already-existing feature that +S 0:0
undoes any prior +S options, resetting scheduler thread and scheduler
thread online counts to their defaults for the host

* document and add tests for the already-existing feature that specifying
negative numbers for +S results in the specified values being subtracted
from the scheduler thread and scheduler thread online counts

I'll send another email when the branch is ready with these changes. Any
other concerns, please let me know.

thanks,
--steve



On Thu, Aug 22, 2013 at 10:11 AM, Lukas Larsson  wrote:

>  Hello Steve,
>
> Have you given any thoughts on what should happen if you chain multiple
> +SP commands? i.e.
>
> erl +S 16:16 +SP 50:50 +SP 50:50
>
> Our view right now is that this should give [8:8] and not [4:4] as it
> currently does in the patch.
>
> Related to this we also do not think that the order to +S vs +SP commands
> should matter. i.e.
>
> erl +S 16:16 +SP 50:50 +S 16:16
>
> should give [8:8] and not [16:16].
>
> What do you think? These things are for sure odd cases to think about, but
> if it is possible someone will for sure do it....
>
> Lukas
>
>
> On 21/08/13 15:45, Steve Vinoski wrote:
>
>  For applications where measurements show enhanced performance from the
> use of a non-default number of emulator scheduler threads, having to
> accurately set the right number of scheduler threads across multiple hosts
> each with different numbers of logical processors is difficult because the
> erl +S option requires absolute numbers of scheduler threads and scheduler
> threads online to be specified.
>
>  To address this issue, this patch adds a +SP option to erl, similar to
> the existing +S option but allowing the number of scheduler threads and
> scheduler threads online to be set as percentages of logical processors
> configured and logical processors available, respectively. For example,
> "+SP 50:25" sets the number of scheduler threads to 50% of the logical
> processors configured, and the number of scheduler threads online to 25% of
> the logical processors available.
>
>  https://github.com/erlang/otp/pull/58
>
>  --steve
>
>
> _______________________________________________
> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vinoski@REDACTED  Thu Aug 22 20:58:31 2013
From: vinoski@REDACTED (Steve Vinoski)
Date: Thu, 22 Aug 2013 14:58:31 -0400
Subject: [erlang-patches] patch to add option to set schedulers by
	percentage
In-Reply-To: 
References: 
 <52161C2A.7010601@erlang.org>
 
Message-ID: 

I've amended the commit on my branch as described in my previous message,
please refetch.

https://github.com/erlang/otp/pull/58

thanks,
--steve



On Thu, Aug 22, 2013 at 12:55 PM, Steve Vinoski  wrote:

> Hi Lukas,
>
> Thanks for the feedback. After our IRC conversation today covering the
> details of this issue, I agree it's clearer if this patch doesn't introduce
> order dependencies between +S and +SP options or introduce accumulated
> effects of multiple +SP options. I'll change my branch to do the following:
>
> * ensure that later +SP options on the command line completely replace any
> previous +SP options, so there's no accumulated effects between them (which
> implies "+SP 100:100" can undo any previous +SP options)
>
> * keep interactions between +S and +SP options, but remove ordering
> dependencies, thus your example "+S 16:16 +SP 50:50 +S 16:16" would result
> in [8:8] as you've specified, as would both "+SP 50:50 +S 16:16" and "+S
> 16:16 +SP 50:50"
>
> * document and add tests for the already-existing feature that +S 0:0
> undoes any prior +S options, resetting scheduler thread and scheduler
> thread online counts to their defaults for the host
>
> * document and add tests for the already-existing feature that specifying
> negative numbers for +S results in the specified values being subtracted
> from the scheduler thread and scheduler thread online counts
>
> I'll send another email when the branch is ready with these changes. Any
> other concerns, please let me know.
>
> thanks,
> --steve
>
>
>
> On Thu, Aug 22, 2013 at 10:11 AM, Lukas Larsson  wrote:
>
>>  Hello Steve,
>>
>> Have you given any thoughts on what should happen if you chain multiple
>> +SP commands? i.e.
>>
>> erl +S 16:16 +SP 50:50 +SP 50:50
>>
>> Our view right now is that this should give [8:8] and not [4:4] as it
>> currently does in the patch.
>>
>> Related to this we also do not think that the order to +S vs +SP commands
>> should matter. i.e.
>>
>> erl +S 16:16 +SP 50:50 +S 16:16
>>
>> should give [8:8] and not [16:16].
>>
>> What do you think? These things are for sure odd cases to think about,
>> but if it is possible someone will for sure do it....
>>
>> Lukas
>>
>>
>> On 21/08/13 15:45, Steve Vinoski wrote:
>>
>>  For applications where measurements show enhanced performance from the
>> use of a non-default number of emulator scheduler threads, having to
>> accurately set the right number of scheduler threads across multiple hosts
>> each with different numbers of logical processors is difficult because the
>> erl +S option requires absolute numbers of scheduler threads and scheduler
>> threads online to be specified.
>>
>>  To address this issue, this patch adds a +SP option to erl, similar to
>> the existing +S option but allowing the number of scheduler threads and
>> scheduler threads online to be set as percentages of logical processors
>> configured and logical processors available, respectively. For example,
>> "+SP 50:25" sets the number of scheduler threads to 50% of the logical
>> processors configured, and the number of scheduler threads online to 25% of
>> the logical processors available.
>>
>>  https://github.com/erlang/otp/pull/58
>>
>>  --steve
>>
>>
>> _______________________________________________
>> erlang-patches mailing listerlang-patches@REDACTED://erlang.org/mailman/listinfo/erlang-patches
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From erlangsiri@REDACTED  Fri Aug 23 09:50:08 2013
From: erlangsiri@REDACTED (Siri Hansen)
Date: Fri, 23 Aug 2013 09:50:08 +0200
Subject: [erlang-patches] Supervisor shutdown reason when reaching max
	restarts
In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu>
References: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu>
Message-ID: 

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 lukas@REDACTED  Fri Aug 23 10:39:58 2013
From: lukas@REDACTED (Lukas Larsson)
Date: Fri, 23 Aug 2013 10:39:58 +0200
Subject: [erlang-patches] patch to add option to set schedulers by
	percentage
In-Reply-To: 
References: 
 <52161C2A.7010601@erlang.org>
 
 
Message-ID: <52171FDE.2030909@erlang.org>

Hello,

This looks great! I'll add it to our tests during the weekend and if 
nothing pops up merge it next week.

Lukas

On 22/08/13 20:58, Steve Vinoski wrote:
> I've amended the commit on my branch as described in my previous 
> message, please refetch.
>
> https://github.com/erlang/otp/pull/58
>
> thanks,
> --steve
>
>
>
> On Thu, Aug 22, 2013 at 12:55 PM, Steve Vinoski  > wrote:
>
>     Hi Lukas,
>
>     Thanks for the feedback. After our IRC conversation today covering
>     the details of this issue, I agree it's clearer if this patch
>     doesn't introduce order dependencies between +S and +SP options or
>     introduce accumulated effects of multiple +SP options. I'll change
>     my branch to do the following:
>
>     * ensure that later +SP options on the command line completely
>     replace any previous +SP options, so there's no accumulated
>     effects between them (which implies "+SP 100:100" can undo any
>     previous +SP options)
>
>     * keep interactions between +S and +SP options, but remove
>     ordering dependencies, thus your example "+S 16:16 +SP 50:50 +S
>     16:16" would result in [8:8] as you've specified, as would both
>     "+SP 50:50 +S 16:16" and "+S 16:16 +SP 50:50"
>
>     * document and add tests for the already-existing feature that +S
>     0:0 undoes any prior +S options, resetting scheduler thread and
>     scheduler thread online counts to their defaults for the host
>
>     * document and add tests for the already-existing feature that
>     specifying negative numbers for +S results in the specified values
>     being subtracted from the scheduler thread and scheduler thread
>     online counts
>
>     I'll send another email when the branch is ready with these
>     changes. Any other concerns, please let me know.
>
>     thanks,
>     --steve
>
>
>
>     On Thu, Aug 22, 2013 at 10:11 AM, Lukas Larsson      > wrote:
>
>         Hello Steve,
>
>         Have you given any thoughts on what should happen if you chain
>         multiple +SP commands? i.e.
>
>         erl +S 16:16 +SP 50:50 +SP 50:50
>
>         Our view right now is that this should give [8:8] and not
>         [4:4] as it currently does in the patch.
>
>         Related to this we also do not think that the order to +S vs
>         +SP commands should matter. i.e.
>
>         erl +S 16:16 +SP 50:50 +S 16:16
>
>         should give [8:8] and not [16:16].
>
>         What do you think? These things are for sure odd cases to
>         think about, but if it is possible someone will for sure do it....
>
>         Lukas
>
>
>         On 21/08/13 15:45, Steve Vinoski wrote:
>>         For applications where measurements show enhanced performance
>>         from the use of a non-default number of emulator scheduler
>>         threads, having to accurately set the right number of
>>         scheduler threads across multiple hosts each with different
>>         numbers of logical processors is difficult because the erl +S
>>         option requires absolute numbers of scheduler threads and
>>         scheduler threads online to be specified.
>>
>>         To address this issue, this patch adds a +SP option to erl,
>>         similar to the existing +S option but allowing the number of
>>         scheduler threads and scheduler threads online to be set as
>>         percentages of logical processors configured and logical
>>         processors available, respectively. For example, "+SP 50:25"
>>         sets the number of scheduler threads to 50% of the logical
>>         processors configured, and the number of scheduler threads
>>         online to 25% of the logical processors available.
>>
>>         https://github.com/erlang/otp/pull/58
>>
>>         --steve
>>
>>
>>         _______________________________________________
>>         erlang-patches mailing list
>>         erlang-patches@REDACTED  
>>         http://erlang.org/mailman/listinfo/erlang-patches
>
>
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Aleksander.Nycz@REDACTED  Fri Aug 23 10:22:10 2013
From: Aleksander.Nycz@REDACTED (Aleksander Nycz)
Date: Fri, 23 Aug 2013 10:22:10 +0200
Subject: [erlang-patches] New index type in mnesia (new feature)
In-Reply-To: <51CD63FF.1070303@erlang.org>
References: <51C1E19C.2070000@comarch.pl> <51CD63FF.1070303@erlang.org>
Message-ID: <52171BB2.3030909@comarch.pl>

W dniu 2013-06-28 12:22, Fredrik pisze:
> On 06/19/2013 06:51 PM, Aleksander Nycz wrote:
>> Hello,
>>
>> Mnesia gives possibility to create table indexes, when
>> the user wants to frequently use some other field
>> than the key field to look up records.
>>
>> Current index solution in mnesia uses ets table (type bag or 
>> duplicated_bag) to maintain mapping:
>> Indexed field value -> Primary key value.
>>
>> Unfortunatelly current solution has very significant disadvantage:
>> operation performance (loading table, insert new records,
>> delete records, etc.) is very low when index is set on 
>> 'Low-cardinality column'
>>
>> http://en.wikipedia.org/wiki/Cardinality_%28SQL_statements%29
>>
>> In such case operation complexity is O(n) when n is number
>> of Primary Key Values. For small n performance can be acceptable for 
>> some application,
>> but when n is the hundreds, thousands or even more such index
>> are useless. New index type provides O(1) complexity.
>>
>> This patch introduces new index type in mnesia database.
>> Main concept is to maintain all Primary Key Values not direcly in
>> bag/duplicated_bag ets but in set of ets.
>> For each Indexed field value new ets is created
>> and Primary Key Values are strored in this ets.
>> For 'Low-cardinality column' there is only a few Indexed key value 
>> (eg. isActive (true/false), state (new/pending/suspended/active), ...)
>> so memory overhead for ets is not significant.
>>
>> Standard index:
>>     Indexed field value -> [Primary key value]
>>
>> New index based on ets:
>>     Indexed field value -> ets, that contains Primary key value
>>
>> Restrictions:
>>
>> 1. New index can be created on disc_copies or ram_copies tables only. 
>> Tables disc_only_copies are not supported.
>> 2. Index type can't be changed. The only way to change existing index 
>> idx_list to idx_ets and vice versa
>>      is to delete existing index and create new one by 
>> mnesia:add_table_index/3 (new function, see below)
>>
>>
>> New API:
>>
>> 1. Define index type when table is created:
>>
>> create_table(Name, TabDef) -> {atomic, ok} | {aborted, Reason}
>>
>> New TabDef value:
>> {index_type, [{atom() | int(), 'idx_std' | 'idx_ets'}]} - 'idx_std' 
>> is default when index is created
>>
>> Example:
>>
>> -type(poolId() :: integer()).
>> -type(bucketId() :: integer()).
>> -type(resourceState() :: free | reserved | gracePeriod).
>>
>> -record(rmResource, {id                                 :: {poolId(), 
>> any()}
>>                     ,state                              :: {poolId(), 
>> bucketId(), resourceState()}
>>                     ,availableFrom                      :: integer()
>>                     ,availableTo                        :: integer()
>>                     ,requestorId                        :: any()
>>                     ,reservedFrom                       :: integer()
>>                     ,reservedTo                         :: integer()
>>                     ,isDeleted      = false             :: boolean()
>>                     ,mTime                              :: integer()}).
>>
>>      {atomic,ok} = mnesia:create_table(tRMResources
>>                                       ,[
>>                                          {disc_copies, []}
>>                                         ,{ram_copies, [node()]}
>>                                         ,{type,set}
>> ,{attributes,record_info(fields, rmResource)}
>>                                         ,{record_name, rmResource}
>>                                         ,{index, [state, requestorId, 
>> mTime]}
>>                                         ,{index_type, [{state, 
>> idx_ets}, {requestorId, idx_std}]}
>>                                        ]),
>>
>> 2. Add new index to existing table:
>>
>> mnesia:add_table_index(Tab, AttrName, IndexOpts) -> {aborted, R} | 
>> {atomic, ok}
>>
>> This function creates a index on Mnesia table called Tab on AttrName
>> field according to the argument IndexOpts.
>> This list must be a list of {Item, Value} tuples, currently only one
>> option is allowed:
>>      {index_type, 'idx_std' | 'idx_ets'}
>>
>> Example:
>>
>> mnesia:add_table_index(tRMResources, isDeleted, [{index_type, 
>> 'idx_ets'}])
>>
>> 3. New match_object/4, dirty_match_object/3 functions:
>>
>> match_object(Tab, Pat, Limit, LockKind) -> [Record] | transaction abort.
>> dirty_match_object(Tab, Pat, Limit) -> [Record] | exit({aborted, 
>> Reason}).
>>
>> Similar to match_object/3 and dirty_match_object/2, but returns no 
>> more than Limit records.
>>
>>
>> 4. New index_match_object/5, dirty_index_match_object/4 functions:
>>
>> index_match_object(Tab, Pat, Attr, Limit, LockKind) -> [Record] | 
>> transaction abort.
>> dirty_index_match_object(Tab, Pat, Attr, Limit) -> [Record] | 
>> exit({aborted, Reason}).
>>
>> Similar to index_match_object/4, dirty_index_match_object/3 but 
>> returns no more than Limit records.
>>
>>
>> 5. New index_read/4, dirty_index_read/4 functions:
>>
>> index_read(Tab, Key, Attr, Limit) -> [Record] | transaction abort.
>> dirty_index_read(Tab, Key, Attr, Limit) -> [Record] | exit({aborted, 
>> Reason}).
>>
>> Similar to index_read/3, dirty_index_read/3 but returns no more than 
>> Limit records.
>>
>>
>> 6. New select_limit/3, select_limit/4, dirty_select/3 functions;
>>
>> select_limit(Tab, MatchSpec, NObjects [, Lock]) -> [Object] | 
>> transaction abort.
>>
>> Similar to select(Tab, MatchSpec [, Lock]) but returns maximum NObjects
>> records, of course empty list can also be returned.
>> Continuation (see select/4) is not possible. This function can also use
>> indexes to find matching records
>> as contrasted with select/4.
>>
>> dirty_select(Tab, Spec, Limit) -> [Object] | exit({aborted, Reason}.
>>
>> Similar to dirty_select/2 but returns no more than Limit records.
>>
>> And git links:
>>
>> git fetch git://github.com/nyczol/otp.git mnesia_new_index
>>
>> https://github.com/nyczol/otp/compare/erlang:master...mnesia_new_index
>> https://github.com/nyczol/otp/compare/erlang:master...mnesia_new_index.patch 
>>
>>
>> Regards,
>> Aleksander Nycz
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
> Hello,
> Please rebase this patch upon current maint. No mergeing ;)
> Thanks,
>
> -- 
>
> BR Fredrik Gustafsson
> Erlang OTP Team

Hello,

It lasts quite long but finally is done.
I move mnesia_new_index functionality to maint.

Below git links:

git fetch git://github.com/nyczol/otp.git mnesia_new_index2

https://github.com/nyczol/otp/compare/erlang:maint...mnesia_new_index2
https://github.com/nyczol/otp/compare/erlang:maint...mnesia_new_index2.patch

Best regards
Aleksadner Nycz

-- 
Aleksander Nycz
Senior Software Engineer
Telco_021 BSS R&D
Comarch SA
Phone:  +48 12 646 1216
Mobile: +48 691 464 275
website: www.comarch.pl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2182 bytes
Desc: Kryptograficzna sygnatura S/MIME
URL: 

From Tobias.Schlager@REDACTED  Fri Aug 23 12:26:28 2013
From: Tobias.Schlager@REDACTED (Tobias Schlager)
Date: Fri, 23 Aug 2013 10:26:28 +0000
Subject: [erlang-patches] Supervisor shutdown reason when reaching max
 restarts
In-Reply-To: 
References: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu>,
 
Message-ID: <12F2115FD1CCEE4294943B2608A18FA361B0B930@MAIL01.win.lbaum.eu>

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 erlangsiri@REDACTED  Fri Aug 23 14:17:21 2013
From: erlangsiri@REDACTED (Siri Hansen)
Date: Fri, 23 Aug 2013 14:17:21 +0200
Subject: [erlang-patches] Supervisor shutdown reason when reaching max
	restarts
In-Reply-To: <12F2115FD1CCEE4294943B2608A18FA361B0B930@MAIL01.win.lbaum.eu>
References: <12F2115FD1CCEE4294943B2608A18FA361B08906@MAIL01.win.lbaum.eu>
 
 <12F2115FD1CCEE4294943B2608A18FA361B0B930@MAIL01.win.lbaum.eu>
Message-ID: 

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 jonas.falkevik@REDACTED  Thu Aug 29 11:00:14 2013
From: jonas.falkevik@REDACTED (Jonas Falkevik)
Date: Thu, 29 Aug 2013 11:00:14 +0200
Subject: [erlang-patches] Fix race in mnesia_monitor - lost/ignored node-up
	event
Message-ID: <73250AF1-7E71-4AAB-98C7-4F59EE40E64A@mobilearts.com>

Hi,
if network goes down during a short period, approx 40s, a node_down event is generated followed by a node_up event, which is not handled properly.
The node_down & node_up events can be received before the remote linked process by mnesia_monitor is generating an EXIT-message.
And since the mnesia_monitor is handling the node_up event only after the EXIT-message, and some logic to set the mnesia node as down, we have a race. 
Hence network partition is not detected for all cases.

To reproduce the problem I have used two virtual machines and unplugging the cable during approx. 40s.
While doing a net_adm:ping/1 between the nodes. 
I haven't been able to do any automated test-case... yet. 

Please have a look at the following patch to fix the problem, there are most certainly a better way of fixing the race if you dig deeper into or know the mnesia internals.
I can rebase the patch on maint-branch if needed, currently it is based on the master branch.

git fetch git://github.com/falkevik/otp.git mnesia_monitor_nodedown_race_fix
https://github.com/falkevik/otp/compare/master...mnesia_monitor_nodedown_race_fix
https://github.com/falkevik/otp/compare/master...mnesia_monitor_nodedown_race_fix.patch


BRs,
Jonas

From fredrik@REDACTED  Thu Aug 29 11:43:18 2013
From: fredrik@REDACTED (Fredrik)
Date: Thu, 29 Aug 2013 11:43:18 +0200
Subject: [erlang-patches] Fix race in mnesia_monitor - lost/ignored
 node-up event
In-Reply-To: <73250AF1-7E71-4AAB-98C7-4F59EE40E64A@mobilearts.com>
References: <73250AF1-7E71-4AAB-98C7-4F59EE40E64A@mobilearts.com>
Message-ID: <521F17B6.4020909@erlang.org>

On 08/29/2013 11:00 AM, Jonas Falkevik wrote:
> Hi,
> if network goes down during a short period, approx 40s, a node_down event is generated followed by a node_up event, which is not handled properly.
> The node_down&  node_up events can be received before the remote linked process by mnesia_monitor is generating an EXIT-message.
> And since the mnesia_monitor is handling the node_up event only after the EXIT-message, and some logic to set the mnesia node as down, we have a race.
> Hence network partition is not detected for all cases.
>
> To reproduce the problem I have used two virtual machines and unplugging the cable during approx. 40s.
> While doing a net_adm:ping/1 between the nodes.
> I haven't been able to do any automated test-case... yet.
>
> Please have a look at the following patch to fix the problem, there are most certainly a better way of fixing the race if you dig deeper into or know the mnesia internals.
> I can rebase the patch on maint-branch if needed, currently it is based on the master branch.
>
> git fetch git://github.com/falkevik/otp.git mnesia_monitor_nodedown_race_fix
> https://github.com/falkevik/otp/compare/master...mnesia_monitor_nodedown_race_fix
> https://github.com/falkevik/otp/compare/master...mnesia_monitor_nodedown_race_fix.patch
>
>
> BRs,
> Jonas
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
Hello Jonas,
I've fetched your patch and assigned your patch to be reviewed by 
responsible developer.
Thanks,

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From roberto.aloi@REDACTED  Thu Aug 29 17:22:31 2013
From: roberto.aloi@REDACTED (Roberto Aloi)
Date: Thu, 29 Aug 2013 17:22:31 +0200 (CEST)
Subject: [erlang-patches] Do not attempt to detect lists of printable
	characters in Data
In-Reply-To: <1704903797.74057.1377789490705.JavaMail.zimbra@erlang-solutions.com>
Message-ID: <1882791087.74134.1377789751908.JavaMail.zimbra@erlang-solutions.com>

Hi all,

Do not attempt to detect lists of printable characters in Data.
This is to avoid outputting something like "\"%\f" instead of [34,37,12] in the XML, if you have lot of tests.

git fetch git://github.com/robertoaloi/otp.git ra-fix-surefire

https://github.com/robertoaloi/otp/compare/erlang:maint...ra-fix-surefire
https://github.com/robertoaloi/otp/compare/erlang:maint...ra-fix-surefire.patch

Kind regards,

Roberto Aloi
---
Erlang Solutions Ltd.
www.erlang-solutions.com


From snaky@REDACTED  Fri Aug 30 08:50:36 2013
From: snaky@REDACTED (Yuri Lukyanov)
Date: Fri, 30 Aug 2013 10:50:36 +0400
Subject: [erlang-patches] [erlang-questions]  cover & export_all
In-Reply-To: 
References: 
 
 
 <51DD171D.2090802@erlang.org>
 
Message-ID: 

Hi Peti,

Did you have a chance to push your fix to the main repo?

On Wed, Jul 10, 2013 at 12:34 PM, Peti G?m?ri  wrote:
> Hi Fredrik,
>
> sorry, what about this one (maybe it was a wrong ?)
>
> git fetch git://github.com/gomoripeti/otp.git pg?-cover-export-all
>
> On Wed, Jul 10, 2013 at 9:11 AM, Fredrik  wrote:
>>
>> On 07/10/2013 03:19 AM, Peti G?m?ri wrote:
>>
>> Hi OTP team,
>>
>> here is a patch that addresses the problem Yuri described.
>> (I haven't added any tests or docs though)
>>
>> is it true that now you also accept pull requests?
>>
>>
>>
>> git fetch git://github.com/gomoripeti/otp.git pg?-cover-export-all
>>
>>
>> https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all
>>
>> https://github.com/gomoripeti/otp/compare/erlang:maint...pg?-cover-export-all.patch
>>
>>
>> br
>> Peter
>>
>> On Wed, Jul 10, 2013 at 12:34 AM, Peti G?m?ri 
>> wrote:
>>>
>>> Hi Yuri,
>>>
>>> You are right, while cover compiling from source works (you can use this
>>> as a workaround):
>>> > cover:compile(cover_test, UserOptions = [export_all, debug_info]).
>>> {ok,cover_test}
>>> > cover_test:test().
>>> ok
>>>
>>> (because UserOptions from the arguments is taken when cover recompiles
>>> the instrumented forms)
>>> when cover compiling from beam UserOptions = [] is taken.
>>> This could be fixed in cover by taking the compile options from the beam
>>> file as you assumed how it works.
>>>
>>> Actually the documentation still says that "Only options defining include
>>> file directories and macros are passed to compile:file/2, everything else is
>>> ignored." apparently a patch from Tobias Schlager added export_all to the
>>> allowed options of cover:compile for the exact same use case as you had. But
>>> this is missing from cover:compile_beam.
>>>
>>> May be I try to come up with a patch
>>>
>>> br
>>> Peter
>>>
>>>
>>>
>>> On Tue, Jul 9, 2013 at 11:56 AM, Yuri Lukyanov  wrote:
>>>>
>>>> It seems that there is no way to cover-compile modules with export_all.
>>>> Here is a simple example:
>>>>
>>>> cover_test.erl:
>>>>
>>>> -module(cover_test).
>>>> test() -> ok.
>>>>
>>>>
>>>> $ erl
>>>> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:4:4]
>>>> [async-threads:0] [hipe] [kernel-poll:false]
>>>>
>>>> Eshell V5.9.1  (abort with ^G)
>>>> 1> c(cover_test, [debug_info,export_all]).
>>>> {ok,cover_test}
>>>> 2> cover_test:test().
>>>> ok
>>>> 3> cover:compile_beam(cover_test).
>>>> {ok,cover_test}
>>>> 4> cover_test:test().
>>>> ** exception error: undefined function cover_test:test/0
>>>> 5>
>>>>
>>>>
>>>> Could someone explain why it is like this? Is it done on purpose?
>>>> Maybe it's a bug?
>>>> The reason I want modules to be cover-compiled with +export_all is
>>>> that it is sometimes convinient to have unit tests outside of a
>>>> module. Before unit tests are run the modules get compiled with
>>>> +export_all for tests to be able to access private functions. But the
>>>> situation is that it is not possibe in this case to enable coverage
>>>> analysys.
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
>>
>> Hello Peti,
>> I am getting, fatal: Couldn't find remote ref pg?-cover-export-all when I
>> am trying to fetch.
>> Yes pull requests are accepted.
>>
>> --
>>
>> BR Fredrik Gustafsson
>> Erlang OTP Team
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


From fredrik@REDACTED  Fri Aug 30 09:29:01 2013
From: fredrik@REDACTED (Fredrik)
Date: Fri, 30 Aug 2013 09:29:01 +0200
Subject: [erlang-patches] Do not attempt to detect lists of printable
 characters in Data
In-Reply-To: <1882791087.74134.1377789751908.JavaMail.zimbra@erlang-solutions.com>
References: <1882791087.74134.1377789751908.JavaMail.zimbra@erlang-solutions.com>
Message-ID: <522049BD.3020100@erlang.org>

On 08/29/2013 05:22 PM, Roberto Aloi wrote:
> Hi all,
>
> Do not attempt to detect lists of printable characters in Data.
> This is to avoid outputting something like "\"%\f" instead of [34,37,12] in the XML, if you have lot of tests.
>
> git fetch git://github.com/robertoaloi/otp.git ra-fix-surefire
>
> https://github.com/robertoaloi/otp/compare/erlang:maint...ra-fix-surefire
> https://github.com/robertoaloi/otp/compare/erlang:maint...ra-fix-surefire.patch
>
> Kind regards,
>
> Roberto Aloi
> ---
> Erlang Solutions Ltd.
> www.erlang-solutions.com
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches
Hello Roberto,
I've fetched your patch and assigned it to be reviewed by responsible 
developers.
Thanks,

-- 

BR Fredrik Gustafsson
Erlang OTP Team



From jargon@REDACTED  Sat Aug 31 04:21:28 2013
From: jargon@REDACTED (Johannes =?utf-8?B?V2Vpw59s?=)
Date: Sat, 31 Aug 2013 04:21:28 +0200
Subject: [erlang-patches] Fix httpd config option 'erl_script_nocache'
In-Reply-To: <521342B3.1080002@erlang.org>
References: <20130622183700.GA8171@molb.org>
 <521342B3.1080002@erlang.org>
Message-ID: <20130831022128.GA788@molb.org>

Hello Fredrik,

> Could you please provide a testcase for this particular issue in your patch?

I wrote a test which checks the functionality of the nocache directives,
and also that they can be used independently (mod_cgi <-> mod_esi). I
pushed the commit on the branch of the fix and also opened a pull
request.

https://github.com/erlang/otp/pull/64

git fetch git://github.com/weisslj/otp.git fix-httpd-erl-script-nocache

https://github.com/weisslj/otp/compare/erlang:maint...fix-httpd-erl-script-nocache
https://github.com/weisslj/otp/compare/erlang:maint...fix-httpd-erl-script-nocache.patch


Greetings,

Johannes Wei?l