Juan - I think we will go for solution 2) (i.e. jc-omit-undefined-start_phases-3). Thanks! I've asked Henrik to include it in pu.<div>Regards</div><div><div>/siri<br><br><div class="gmail_quote">2012/1/13 Juan Jose Comellas <span dir="ltr"><<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Siri, I agree with making it more readable. This being my first commit<br>
to Erlang/OTP I wanted to make everything as unobtrusive and<br>
predictable as possible. I've changed the patch as you requested and I<br>
made two versions of it in the following branches:<br>
<br>
1) jc-omit-undefined-start_phases-2<br>
<br>
Using the style present in the original file for the case expression<br>
(i.e. case StartMod =:= undefined of true -> ....)<br>
<br>
Fetch with:<br>
git fetch git://<a href="http://github.com/jcomellas/otp.git" target="_blank">github.com/jcomellas/otp.git</a> jc-omit-undefined-start_phases-2<br>
Diff against 'maint':<br>
<a href="https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-2" target="_blank">https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-2</a><br>
<br>
<br>
2) jc-omit-undefined-start_phases-3<br>
<br>
Using the more modern Erlang style for case expressions that Tuncer<br>
suggested in his email (i.e. case StartMod of undefined -> ...)<br>
<br>
Fetch with:<br>
git fetch git://<a href="http://github.com/jcomellas/otp.git" target="_blank">github.com/jcomellas/otp.git</a> jc-omit-undefined-start_phases-3<br>
Diff against 'maint':<br>
<a href="https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-3" target="_blank">https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases-3</a><br>
<br>
I've also tested a release with both branches and the resulting .app<br>
files are exactly the same, as expected:<br>
<br>
e.g. With 'start_phases' unset in the original .app file:<br>
<br>
%% app generated at {2012,1,13} {10,15,39}<br>
<div>{application,sasl,<br>
[{description,"SASL CXC 138 11"},<br>
{vsn,"2.2"},<br>
{id,[]},<br>
{modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp,<br>
overload,rb,rb_format_supp,release_handler,<br>
release_handler_1,sasl,sasl_report,sasl_report_file_h,<br>
sasl_report_tty_h,si,si_sasl_supp,systools,<br>
systools_lib,systools_make,systools_rc,<br>
systools_relup]},<br>
{registered,[sasl_sup,alarm_handler,overload,release_handler]},<br>
{applications,[kernel,stdlib]},<br>
{included_applications,[]},<br>
{env,[{sasl_error_logger,tty},{errlog_type,all}]},<br>
{maxT,infinity},<br>
{maxP,infinity},<br>
{mod,{sasl,[]}}]}.<br>
<br>
</div>e.g. With 'start_phases' set to [] in the original .app file:<br>
<br>
%% app generated at {2012,1,13} {10,15,39}<br>
{application,etest,<br>
[{description,[]},<br>
{vsn,"2"},<br>
{id,[]},<br>
{modules,[etest_app,etest_sup]},<br>
{registered,[]},<br>
<div> {applications,[kernel,stdlib]},<br>
{included_applications,[]},<br>
</div> {env,[]},<br>
{maxT,infinity},<br>
{maxP,infinity},<br>
{mod,{etest_app,[]}},<br>
{start_phases,[]}]}.<br>
<br>
Let me know if any other change is required.<br>
<br>
Juanjo<br>
<div><div><br>
<br>
On Fri, Jan 13, 2012 at 6:55 AM, Siri Hansen <<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>> wrote:<br>
> Hi Juan!<br>
><br>
> Thanks for the patch - I had a look at your changes, and I have one comment:<br>
><br>
> There is no requirement of any specific order of the items in the .app file<br>
> and I therefore think it would be more readable to just add the start_phases<br>
> and mod items at the end of the list instead of merging them with the maxT<br>
> and maxP items.<br>
><br>
> I know that this change would make the result from this function differ<br>
> compared to earlier but it would still be correct, and I think that the<br>
> readability is quite important. What do you think?<br>
><br>
> Regards<br>
> /siri<br>
><br>
><br>
> 2012/1/12 Juan Jose Comellas <<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>><br>
>><br>
>> Siri, I have compiled the maint branch with my change and tested<br>
>> generating a release using rebar. The .app file I sent as an example<br>
>> before now looks like this:<br>
>><br>
>> %% app generated at {2012,1,12} {16,49,25}<br>
>> {application,sasl,<br>
>> [{description,"SASL CXC 138 11"},<br>
>> {vsn,"2.2"},<br>
>> {id,[]},<br>
>> {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp,<br>
>> overload,rb,rb_format_supp,release_handler,<br>
>><br>
>> release_handler_1,sasl,sasl_report,sasl_report_file_h,<br>
>> sasl_report_tty_h,si,si_sasl_supp,systools,<br>
>> systools_lib,systools_make,systools_rc,<br>
>> systools_relup]},<br>
>><br>
>> {registered,[sasl_sup,alarm_handler,overload,release_handler]},<br>
>> {applications,[kernel,stdlib]},<br>
>> {included_applications,[]},<br>
>> {env,[{sasl_error_logger,tty},{errlog_type,all}]},<br>
>> {maxT,infinity},<br>
>> {maxP,infinity},<br>
>> {mod,{sasl,[]}}]}.<br>
>><br>
>> You can see that now the .app file does not include the 'start_phases'<br>
>> entry. You can get this patch by running:<br>
>><br>
>> git fetch git://<a href="http://github.com/jcomellas/otp.git" target="_blank">github.com/jcomellas/otp.git</a><br>
>> jc-omit-undefined-start_phases<br>
>><br>
>> Juanjo<br>
>><br>
>><br>
>> On Thu, Jan 12, 2012 at 4:30 PM, Juan Jose Comellas <<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>><br>
>> wrote:<br>
>> > Siri, I have made the change. You can review it here:<br>
>> ><br>
>> ><br>
>> > <a href="https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases" target="_blank">https://github.com/jcomellas/otp/compare/erlang:maint...jcomellas:jc-omit-undefined-start_phases</a><br>
>> ><br>
>> > And you can fetch the changes with:<br>
>> ><br>
>> > git fetch git://<a href="http://github.com/jcomellas/otp.git" target="_blank">github.com/jcomellas/otp.git</a><br>
>> > jc-omit-undefined-start_phases<br>
>> ><br>
>> > I am recompiling the maint branch with this change and I intend to<br>
>> > test generating a release upgrade with it, but it's going to take a<br>
>> > while.<br>
>> ><br>
>> > Juanjo<br>
>> ><br>
>> ><br>
>> > On Thu, Jan 12, 2012 at 5:58 AM, Siri Hansen <<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>><br>
>> > wrote:<br>
>> >> Ok, thanks!<br>
>> >> Then I think that we will go for the solution where<br>
>> >> reltool_target:gen_app<br>
>> >> does not add the start_phases entry if<br>
>> >> #app_info.start_phases==undefined.<br>
>> >> And the default value for #app_info.start_phases shall still be<br>
>> >> 'undefined'.<br>
>> >> This will keep the backwards compatibility.<br>
>> >><br>
>> >> Will you do the change, Juan?<br>
>> >><br>
>> >> Regards<br>
>> >> /siri<br>
>> >><br>
>> >><br>
>> >> 2012/1/11 Juan Jose Comellas <<a href="mailto:juanjo@comellas.org" target="_blank">juanjo@comellas.org</a>><br>
>> >>><br>
>> >>> Siri, what you mention is exactly what was happening. I did all my<br>
>> >>> tests with rebar and what I experienced was that after performing a<br>
>> >>> 'rebar generate' reltool creates all the .app files in the release<br>
>> >>> with 'start_phases' set as 'undefined'. Here's an example:<br>
>> >>><br>
>> >>> %% app generated at {2012,1,11} {14,17,10}<br>
>> >>> {application,sasl,<br>
>> >>> [{description,"SASL CXC 138 11"},<br>
>> >>> {vsn,"2.2"},<br>
>> >>> {id,[]},<br>
>> >>> {modules,[alarm_handler,erlsrv,format_lib_supp,misc_supp,<br>
>> >>> overload,rb,rb_format_supp,release_handler,<br>
>> >>><br>
>> >>> release_handler_1,sasl,sasl_report,sasl_report_file_h,<br>
>> >>> sasl_report_tty_h,si,si_sasl_supp,systools,<br>
>> >>> systools_lib,systools_make,systools_rc,<br>
>> >>> systools_relup]},<br>
>> >>><br>
>> >>> {registered,[sasl_sup,alarm_handler,overload,release_handler]},<br>
>> >>> {applications,[kernel,stdlib]},<br>
>> >>> {included_applications,[]},<br>
>> >>> {env,[{sasl_error_logger,tty},{errlog_type,all}]},<br>
>> >>> {start_phases,undefined},<br>
>> >>> {maxT,infinity},<br>
>> >>> {maxP,infinity},<br>
>> >>> {mod,{sasl,[]}}]}.<br>
>> >>><br>
>> >>> The problem is that once you try to run 'rebar generate-upgrade' you<br>
>> >>> get all kinds of badmatch errors because the function that validates<br>
>> >>> the 'start_phases' entry in the generated .app files does not allow it<br>
>> >>> to be set to 'undefined'. Here's the relevant line:<br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> <a href="https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681" target="_blank">https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681</a><br>
>> >>><br>
>> >>> My thought was to set the 'start_phases' field to [] by default in the<br>
>> >>> #app_info record (in lib/reltool/src/reltool.hrl) to avoid this<br>
>> >>> problem. What you proposed (not adding the 'start_phases' entry if it<br>
>> >>> is set to 'undefined') is equally valid. Also, another option would be<br>
>> >>> to allow 'undefined' to be a valid value in the line I referenced from<br>
>> >>> Github above.<br>
>> >>><br>
>> >>> This seems to have been broken for over a year, and from what I can<br>
>> >>> see it was impossible to automatically generate releases and release<br>
>> >>> upgrades without triggering this error (at least with rebar).<br>
>> >>><br>
>> >>> Juanjo<br>
>> >>><br>
>> >>><br>
>> >>> On Wed, Jan 11, 2012 at 7:45 AM, Siri Hansen <<a href="mailto:erlangsiri@gmail.com" target="_blank">erlangsiri@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > Sorry for the delay, but finally I have had a look at this....<br>
>> >>> ><br>
>> >>> > As far as I can see the empty list used as default<br>
>> >>> > for #application.start_phase in systools.hrl will *never* come out<br>
>> >>> > in a<br>
>> >>> > real<br>
>> >>> > instance of the #application record. The fields of this record gets<br>
>> >>> > its<br>
>> >>> > values in systools_make:parse_application/4 (from get_items/2 -><br>
>> >>> > check_item/2) - which will give the start_phases field the value<br>
>> >>> > 'undefined'<br>
>> >>> > if there is no start_phases entry in the .app file. The only way<br>
>> >>> > start_phases can get the value [] here is if there is a<br>
>> >>> > {start_phases,[]}<br>
>> >>> > entry in the .app file, but this has nothing to do with the default<br>
>> >>> > value.<br>
>> >>> ><br>
>> >>> > I agree of course that systools.hrl is a bit misleading by stating a<br>
>> >>> > default<br>
>> >>> > value which is never used...<br>
>> >>> ><br>
>> >>> > reltool_server on the other hand does use the default value from<br>
>> >>> > reltool.hrl<br>
>> >>> > file when parsing - but (and this might be the real bug)<br>
>> >>> > reltool_target<br>
>> >>> > does<br>
>> >>> > the opposite operation - i.e. it takes information from #app_info<br>
>> >>> > records<br>
>> >>> > and generates app specifications where it takes the value of the<br>
>> >>> > start_phases field in the record and inserts it directly as a<br>
>> >>> > {start_phases,Phases} entry in the app specification. It then seems<br>
>> >>> > like<br>
>> >>> > this is written to a .app file during target installation. I am not<br>
>> >>> > 100%<br>
>> >>> > sure of this (and why), so any objections would be good... But<br>
>> >>> > anyway,<br>
>> >>> > if<br>
>> >>> > this is the case - there might be .app files containing<br>
>> >>> > {start_phases,undefined} in the target installation from reltool...<br>
>> >>> > And<br>
>> >>> > this<br>
>> >>> > can never be parsed by systools!!!<br>
>> >>> ><br>
>> >>> > Could this be what happens in your case, Juan?<br>
>> >>> ><br>
>> >>> > If so, I think the best correction of this would be to let<br>
>> >>> > reltool_target<br>
>> >>> > insert a {start_phases,Phases} entry in the app specification only<br>
>> >>> > if<br>
>> >>> > Phases=/=undefined... What do you think?<br>
>> >>> ><br>
>> >>> > Regards<br>
>> >>> > /siri<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > 2012/1/5 Ulf Wiger <<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> I would suggest that the special handling of {start_phases,<br>
>> >>> >> undefined}<br>
>> >>> >> be<br>
>> >>> >> removed, and documentation updated accordingly.<br>
>> >>> >><br>
>> >>> >> But this is a decision that OTP will have to make.<br>
>> >>> >><br>
>> >>> >> BR,<br>
>> >>> >> Ulf W<br>
>> >>> >><br>
>> >>> >> On 5 Jan 2012, at 16:04, Juan Jose Comellas wrote:<br>
>> >>> >><br>
>> >>> >> > Would it be an option to modify the function that validates the<br>
>> >>> >> > value<br>
>> >>> >> > assigned to 'start_phases' so that 'undefined' is considered an<br>
>> >>> >> > acceptable value? The relevant line is:<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > <a href="https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681" target="_blank">https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L681</a><br>
>> >>> >> ><br>
>> >>> >> > Juanjo<br>
>> >>> >> ><br>
>> >>> >> ><br>
>> >>> >> > On Tue, Jan 3, 2012 at 5:31 PM, Ulf Wiger <<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>><br>
>> >>> >> > wrote:<br>
>> >>> >> >><br>
>> >>> >> >> Not my call.<br>
>> >>> >> >><br>
>> >>> >> >> I can well understand if the reasons behind the special<br>
>> >>> >> >> treatment of<br>
>> >>> >> >> 'start_phases' have been forgotten by those maintaining the<br>
>> >>> >> >> code.<br>
>> >>> >> >><br>
>> >>> >> >> A closer analysis might reveal whether backward compatibility<br>
>> >>> >> >> has<br>
>> >>> >> >> already been sufficiently compromised that it is now time to<br>
>> >>> >> >> Make It<br>
>> >>> >> >> Right<br>
>> >>> >> >> (™).<br>
>> >>> >> >><br>
>> >>> >> >> Even the old AXD 301 project, for which the oddity was<br>
>> >>> >> >> introduced in<br>
>> >>> >> >> the first place, took the first opportunity to make the code<br>
>> >>> >> >> fully<br>
>> >>> >> >> compatible with the new semantics.<br>
>> >>> >> >><br>
>> >>> >> >> BR,<br>
>> >>> >> >> Ulf W<br>
>> >>> >> >><br>
>> >>> >> >> On 3 Jan 2012, at 21:22, Juan Jose Comellas wrote:<br>
>> >>> >> >><br>
>> >>> >> >>> I can make the change and add it to the branch I created, but<br>
>> >>> >> >>> the<br>
>> >>> >> >>> question is: should I? I'm not really that well informed about<br>
>> >>> >> >>> the<br>
>> >>> >> >>> history of this value. All I can say is that the parts that<br>
>> >>> >> >>> care<br>
>> >>> >> >>> about<br>
>> >>> >> >>> the 'start_phases' entry in reltool and systools assume that it<br>
>> >>> >> >>> will<br>
>> >>> >> >>> be an empty list when it is not set and fail otherwise.<br>
>> >>> >> >>><br>
>> >>> >> >>> Let me know if I have to modify my patch to make it acceptable<br>
>> >>> >> >>> for<br>
>> >>> >> >>> inclusion in OTP.<br>
>> >>> >> >>><br>
>> >>> >> >>> Juanjo<br>
>> >>> >> >>><br>
>> >>> >> >>><br>
>> >>> >> >>> On Tue, Jan 3, 2012 at 8:22 AM, Ulf Wiger <<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>><br>
>> >>> >> >>> wrote:<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Hmm, there's an old catch here. Someone will have to hollar if<br>
>> >>> >> >>>> it<br>
>> >>> >> >>>> is<br>
>> >>> >> >>>> no<br>
>> >>> >> >>>> longer relevant - but if it isn't, some documentation patch is<br>
>> >>> >> >>>> called<br>
>> >>> >> >>>> for.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> In<br>
>> >>> >> >>>><br>
>> >>> >> >>>><br>
>> >>> >> >>>> <a href="http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2" target="_blank">http://www.erlang.org/doc/apps/kernel/application.html#Module:start-2</a><br>
>> >>> >> >>>><br>
>> >>> >> >>>> StartType defines the type of start:<br>
>> >>> >> >>>><br>
>> >>> >> >>>> normal if it's a normal startup.<br>
>> >>> >> >>>> normal also if the application is distributed and started at<br>
>> >>> >> >>>> the<br>
>> >>> >> >>>> current<br>
>> >>> >> >>>> node due to a failover from another node, and the application<br>
>> >>> >> >>>> specification<br>
>> >>> >> >>>> key start_phases == undefined.<br>
>> >>> >> >>>> {takeover,Node} if the application is distributed and started<br>
>> >>> >> >>>> at<br>
>> >>> >> >>>> the<br>
>> >>> >> >>>> current<br>
>> >>> >> >>>> node due to a takeover from Node, either because<br>
>> >>> >> >>>> application:takeover/2 has<br>
>> >>> >> >>>> been called or because the current node has higher priority<br>
>> >>> >> >>>> than<br>
>> >>> >> >>>> Node.<br>
>> >>> >> >>>> {failover,Node} if the application is distributed and started<br>
>> >>> >> >>>> at<br>
>> >>> >> >>>> the<br>
>> >>> >> >>>> current<br>
>> >>> >> >>>> node due to a failover from Node, and the application<br>
>> >>> >> >>>> specification<br>
>> >>> >> >>>> key start_phases /= undefined.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Note that StartType = {failover, Node} is only used if<br>
>> >>> >> >>>> start_phases<br>
>> >>> >> >>>> /=<br>
>> >>> >> >>>> undefined. I will guess that it is for this reason that<br>
>> >>> >> >>>> start_phases<br>
>> >>> >> >>>> is<br>
>> >>> >> >>>> actually set to undefined as default. If it isn't, it was a<br>
>> >>> >> >>>> happy<br>
>> >>> >> >>>> coincidence, since it actually preserves backward<br>
>> >>> >> >>>> compatibility.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> This particular oddity was introduced many years ago, in the<br>
>> >>> >> >>>> 90s -<br>
>> >>> >> >>>> possibly<br>
>> >>> >> >>>> even before Erlang was released as Open Source, so the legacy<br>
>> >>> >> >>>> argument may<br>
>> >>> >> >>>> not be that relevant.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> OTOH, I don't think many people use the start_phases<br>
>> >>> >> >>>> attribute, so<br>
>> >>> >> >>>> even new<br>
>> >>> >> >>>> code might break if the Mod:start/2 function is suddenly<br>
>> >>> >> >>>> called<br>
>> >>> >> >>>> with<br>
>> >>> >> >>>> a<br>
>> >>> >> >>>> StartType that was never seen before.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> BR,<br>
>> >>> >> >>>> Ulf W<br>
>> >>> >> >>>><br>
>> >>> >> >>>><br>
>> >>> >> >>>> On 3 Jan 2012, at 05:21, Juan Jose Comellas wrote:<br>
>> >>> >> >>>><br>
>> >>> >> >>>> The default value for 'start_phases' in .app files should be<br>
>> >>> >> >>>> [],<br>
>> >>> >> >>>> but<br>
>> >>> >> >>>> it is incorrectly set to 'undefined' when generating a<br>
>> >>> >> >>>> release.<br>
>> >>> >> >>>> This<br>
>> >>> >> >>>> happens when the original .app file does not set a value for<br>
>> >>> >> >>>> 'start_phases' explicitly.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> The reltool application defines its own copy of a record to<br>
>> >>> >> >>>> handle<br>
>> >>> >> >>>> .app files (#app_info{}, defined in<br>
>> >>> >> >>>> lib/reltool/src/reltool.hrl)<br>
>> >>> >> >>>> that<br>
>> >>> >> >>>> has different default values than the one used by systools<br>
>> >>> >> >>>> (#application{}, defined in lib/sasl/src/systools.hrl). In<br>
>> >>> >> >>>> particular,<br>
>> >>> >> >>>> the 'start_phases' entry is assumed by all of OTP to be []<br>
>> >>> >> >>>> when it<br>
>> >>> >> >>>> is<br>
>> >>> >> >>>> not explicitly set but reltool sets it to 'undefined' by<br>
>> >>> >> >>>> default.<br>
>> >>> >> >>>> This<br>
>> >>> >> >>>> causes badmatch errors when trying to generate release<br>
>> >>> >> >>>> upgrades.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Without this patch, all of the rebar examples that generate<br>
>> >>> >> >>>> release<br>
>> >>> >> >>>> upgrades that I've found on the web will fail. The bug was<br>
>> >>> >> >>>> introduced<br>
>> >>> >> >>>> in R14A.<br>
>> >>> >> >>>><br>
>> >>> >> >>>> git fetch git://<a href="http://github.com/jcomellas/otp.git" target="_blank">github.com/jcomellas/otp.git</a><br>
>> >>> >> >>>> jc-fix-default-start-phases<br>
>> >>> >> >>>><br>
>> >>> >> >>>> Juanjo<br>
>> >>> >> >>>> _______________________________________________<br>
>> >>> >> >>>> erlang-patches mailing list<br>
>> >>> >> >>>> <a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
>> >>> >> >>>> <a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
>> >>> >> >>>><br>
>> >>> >> >>>><br>
>> >>> >> >><br>
>> >>> >><br>
>> >>> >> _______________________________________________<br>
>> >>> >> erlang-patches mailing list<br>
>> >>> >> <a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
>> >>> >> <a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
>> >>> ><br>
>> >>> ><br>
>> >><br>
>> >><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div>